Talk About Network



Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Forth > Re: >FLOAT beha...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 2 of 8 Topic 3980 of 4065
Post > Topic >>

Re: >FLOAT behavior with null string

by Bruce McFarling <agila61@[EMAIL PROTECTED] > Mar 29, 2008 at 11:19 AM

On Mar 29, 2:01 pm, Krishna Myneni <krishnamyn...@[EMAIL PROTECTED]
>
wrote:
> The specification of >FLOAT in DPANS94 suggests that it treat a string
> of blanks as a representation of zero (below). Common practice among
> Forth systems (pfe, gforth, bigforth) appears to extend this suggested
> behavior to  null strings as well, e.g.
>
> s" " >FLOAT
>
> returns a true flag on the stack, and fp zero on the floating point
> stack. Is there a strong argument for considering a null string to be a
> valid representation of fp zero. I would have implemented the conversion
> to return a false flag. Also, I don't much like the idea of treating a
> string of blanks as a valid representation for 0E either, but perhaps
> there was some valid reason for suggesting this behavior.
>
> Krishna
> --
>
> 12.6.1.0558 >FLOAT
> to-float FLOATING
>
>         ( c-addr u -- true | false ) ( F: -- r |  )
>         or ( c-addr u -- r true | false)
>
> An attempt is made to convert the string specified by c-addr and u to
> internal floating-point representation. If the string represents a valid
> floating-point number in the syntax below, its value r and true are
> returned. If the string does not represent a valid floating-point number
> only false is returned.
>
> A string of blanks should be treated as a special case representing
zero.
>
> The syntax of a convertible string := <significand>[<exponent>]
>
> <significand> := [<sign>]{<digits>[.<digits0>] |
> .<digits> }
> <exponent>    := <marker><digits0>
> <marker>      := {<e-form> | <sign-form>}
> <e-form>      := <e-char>[<sign-form>]
> <sign-form>   := { + | - }
> <e-char>      := { D | d | E | e }
>
> See: A.12.6.1.0558 >FLOAT

I wouldn't want 0 for an empty cell, I'd want to keep track of it as
an N/A. For example, if in working with elasticities I do in fact want
to impute a dummy value for an N/A, it would only be 0 if working in
lognormal form and with no proxy ready at hand ... in explicit
elasticities with no other available proxy the dummy value would be 1.

Unless an explicit N/A or -0 is guaranteed to be available, I'd want a
false flag and then go and see why.

And N/A will quite often come out of a normal csv file of public data
as simply an empty cell. Its more convenient for the creator of the
data to just add a row or column of new information, put an
explanatory note reference in the descriptive label, and start adding
the new data at the point that it is available.




 8 Posts in Topic:
>FLOAT behavior with null string
Krishna Myneni <krishn  2008-03-29 13:01:12 
Re: >FLOAT behavior with null string
Bruce McFarling <agila  2008-03-29 11:19:12 
Re: >FLOAT behavior with null string
Elizabeth D Rather <er  2008-03-29 08:22:04 
Re: >FLOAT behavior with null string
Krishna Myneni <krishn  2008-03-29 17:03:18 
Re: >FLOAT behavior with null string
mhx@[EMAIL PROTECTED] (M  2008-03-29 22:54:13 
Re: >FLOAT behavior with null string
Bruce McFarling <agila  2008-03-29 16:45:12 
Re: >FLOAT behavior with null string
"Ed" <nospam  2008-03-30 13:14:19 
Re: >FLOAT behavior with null string
Bruce McFarling <agila  2008-03-29 21:53:24 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Sat May 17 5:06:14 CDT 2008.