Re: inconsistent behavior of >FLOAT

Jonah Thomas wrote:
Krishna Myneni <krishnamyneni@xxxxxxxxxxxxx> wrote:

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.

You have pointed out the good choices for >FLOAT without suggesting
which of them to take. I also don't have a strong opinion about this.
But I do have some preferences.


As much as I dislike the idea of >FLOAT converting a string of blanks
to a fp zero, I think it is too late for >FLOAT to rescind the strong suggestion in its spec that this "should" be the case. My own practical experience has been that when such a case is encountered, it is because something has gone unexpectedly, e.g. the input stream has been incorrectly parsed. As long as the spec is tightened to require that a string of blanks must be treated as a valid zero, a programmer would know to filter such a case, if needed, before it is passed to >FLOAT.

I think ignoring leading and trailing blanks may be reasonable for >FLOAT, as long as it does not violate the current spec. The last issue is not clear to me, based on the test code posted by Ed.

There is sufficient disagreement on the empty string case that it should
be declared to be an ambiguous condition. Such a declaration would warn a programmer to test for this case and deal with it in a manner appropriate for the application.

These fixes will help standardize the behavior, even if the behavior is
not my personal preference. IMHO, >FLOAT should eventually be deprecated and replaced by a word that treats blank and empty strings as invalid input. Backward compatibility can be achieved by defining >FLOAT as a wrapper around the new word.

If >FLOAT gets a string that contains precisely one nonblank substring,
I'd find it most convenient if it tries to convert the nonblank
substring as a floating point number. If I have to be careful to remove
leading and trailing blanks then that's one more thing to deal with, but
I can do it if that's how it comes out.

I'd prefer to get a throw code for zero-length string than a floating
zero. I have the prejudice that if I pass a zero-length string to >FLOAT
then it's far more likely to be an error than a request for a zero. If I
actually do want a zero from that I can fix it, but more likely I'll be
fixing a bug.



And I'd prefer to get a different throw code for a string of blanks for
the same reason. In the tradition I have the most experience with, a
blank field or a . means "missing data" and takes special treatment
anyway. If it silently converts blanks to zeroes then I might not find
out about the problem. But if I want zeroes then it looks reasonably
easy to fix, something on the order of:

: >FLOAT1
['] >FLOAT CATCH CASE
0 OF ENDOF
-422 OF S" 0e0" EVALUATE ENDOF
THROW
ENDCASE ;

If my data or code is doing something I don't expect I'd rather find out
about it so I can see what to do, than have it just do something in the
hope it's the right thing.


Yes, standard words should be as predictable as possible. There will always
be ambiguous conditions, but such conditions must be declared so the code
makes no unwarranted assumptions about the input. Generating different error
codes for different error conditions is often useful, but this is typically
done at the application level. Such a feature is probably overkill for a low-level word.

Krishna
.

Relevant Pages

  • Re: Bug in Safari Javascript?
    ... trailing blanks should be found within RegExp.$1, ... trimmed string is desired. ... It should fail if there is no "Hello" with zero or more ... of the OP's regular expression, ...
    (comp.lang.javascript)
  • Re: Bug in Safari Javascript?
    ... regular expression processing can return success, ... quantifier allows (either zero or) one of these. ... trailing blanks should be found within RegExp.$1, ... trimmed string is desired. ...
    (comp.lang.javascript)
  • Re: inconsistent behavior of >FLOAT
    ... There is exactly one space between the quote characters in the above line, which should represent a string of zero length. ... makes the behavior of>FLOAT ambiguous in the case of a zero length string, leading to unintended consequences, e.g. ... I'm wondering, whether or not there is an advantage to specifying the behavior, such as with the example Marcel provided earlier, compared to allowing and stating that there is an ambiguity. ...
    (comp.lang.forth)
  • Re: inconsistent behavior of >FLOAT
    ... empty string, strings with leading and trailing blanks. ... You have pointed out the good choices for>FLOAT without suggesting ... then it's far more likely to be an error than a request for a zero. ...
    (comp.lang.forth)
  • inconsistent behavior of >FLOAT
    ... The word>FLOAT from the floating point word set appears to have inconsistent behavior on different Forth systems for the case of a string with zero length: ... There is exactly one space between the quote characters in the above line, which should represent a string of zero length. ... The return value on top of the data stack is a flag, with true indicating that the string represents a valid floating point number. ...
    (comp.lang.forth)