"Krishna Myneni" <krishnamyneni@[EMAIL PROTECTED]
> wrote in message
news:CtvHj.15797$%15.11063@[EMAIL PROTECTED]
>
> 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.
When I asked the same question once before, someone suggested
it derived from Fortran practice.
BTW a null string can be considered a substring of a blank string
- in which case the rule of returning fp zero would apply. Thus the
"blanks" rule automatically resolves the situation for null strings.
(c.f. null strings in COMPARE SEARCH )
>FLOAT is a primitive. As such it has to cater for what is deemed
to be common practice in programming. If an application doesn't
want empty or blank strings to return fp zero, it only has to test and/or
process the string beforehand.
|
