Re: inconsistent behavior of >FLOAT

Elizabeth D Rather wrote:
Stephen Pelc wrote:
On Tue, 12 May 2009 18:35:30 GMT, anton@xxxxxxxxxxxxxxxxxxxxxxxxxx
(Anton Ertl) wrote:

If the application programmer wants to have a strictly-checked syntax
for FP numbers, he has to implement the checker by himself; this makes
sense, as it would be surprising if the syntax specified for >FLOAT
matches exactly the syntax that the program wants to have checked.

Which is the real problem. Words in the standard should be useful to
real-world application programmers.

However, it might be useful to have a companion word to >FLOAT, that
checks the syntax exactly (and without blanks or empty strings).

So, you're suggesting that >FLOAT be implemented as wrapper aound
a useful word? :-/

My recollection is that folks reported being handed arbitrary data in text form to read (I've had that experience, and I bet you have, too). They couldn't enforce formatting on that data, because it originated outside their sphere of control. The intent of >FLOAT is to do its best to convert anything even remotely convertible. The standard's *implicit* number conversion has much stronger rules, because it governs things like FP numbers in source or user input, where it's more realistic to impose formatting rules on input.

Cheers,
Elizabeth


While a word that can convert nearly anything thrown at it can be useful
in practice, IMO it does not belong in the standard simply because it is
hard to specify its behavior in a precise way. This leads to differences in
interpretation and inconsistencies between implementations, as has happened
in the case of >FLOAT. The remedy for >FLOAT now is fairly obvious; specify
the behavior or declare ambiguity for the cases of string of blanks, empty
string, strings with leading and trailing blanks.

Krishna
.

Relevant Pages

  • Re: inconsistent behavior of >FLOAT
    ... What "serious consequence" would tightening>FLOAT have? ... The current flap about leading/trailing blanks, all blanks, etc. is ... will accept the all blanks situation should your app need it. ... You didn't mention empty strings but others will. ...
    (comp.lang.forth)
  • Re: CComboBox-Droplist: float values?
    ... Store the float in the ... a trick, however: you can't cast a float to an LPARAM without causing ... Why not just use atof() on the strings and compare the results? ...
    (microsoft.public.vc.mfc)
  • Re: a few thoughts for ruby...
    ... I'm not in favour, for Robert Klemme's reasons. ... to normally use strings to get BigDecimal values to avoid precision errors. ... so I'd agree that encouraging Float -> BigDecimal conversions ...
    (comp.lang.ruby)
  • Re: CComboBox-Droplist: float values?
    ... Store the float in the ... a trick, however: you can't cast a float to an LPARAM without causing it ... Why not just use atof() on the strings and compare the results? ...
    (microsoft.public.vc.mfc)
  • Re: Why doesnt Float() work the same as Integer()?
    ... Michael W. Ryder wrote: ... ran into a problem with converting Strings. ... later converting the Float to an Integer. ...
    (comp.lang.ruby)