Elizabeth D Rather wrote:
> Krishna Myneni 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
>> --
>
> To my best (fading) recollection, this was a recognition of existing
> common practice in the FP implementations we looked at. The thought was
> that illegal characters could invalidate the conversion, but nothing
else.
>
> Cheers,
> Elizabeth
>
Ok. There are instances, in practice, in which one is expecting a string
representation of an fp number from some source, be it a file or other
device,
and a string of blanks or a null string indicates a failure. For such
cases, the
following conversion word is more useful:
\ ( c-addr u -- true | false ) ( F: -- r | ) or ( c-addr u -- r true |
false)
: >FLOAT-STRICT -TRAILING DUP 0= IF NIP ELSE >FLOAT THEN ;
Krishna
|
