Front page | perl.perl6.language |
Postings from October 2001
RE: NaN semantics
October 9, 2001 03:30
RE: NaN semantics
Message ID: 5D0C92E65C29D311A24D0090273C216803692875@BRKXMTCH02_b
Piers Cawley [mailto:email@example.com] on 9 October 2001 09:02 wrote:
> But there are going to be problems in some cases if we change the
> behaviour of NaN to the perl semantics. There are cases where the IEEE
> behaviour is *useful* dammit.
Indeed, we certainly don't want sqrt(-1) == sqrt(-2) being true.
> The problem here is that you can't simply do:
> until $inflation;
> Because 0 isn't true.
> Hmmm... just had a thought. How does this sound:
> +'non_numeric_string' becomes 'NaN is undefined'
> sqrt(-1) becomes 'NaN is defined'
> Then, if you're doing loop control you'd do
> until defined(+$inflation)
> And when you're doing numeric calculation type stuff you get the
> useful IEEE behaviour.
> Why do I have the horrible feeling that *nobody* is going to like this
<randomish thoughts about this...>
I think this is the right track but not necessarily the right "values"...
What I would like is to be able to have different results from (ignoring any
inbuilt support for complex numbers that may have been proposed):
$x = sqrt(-2); # $x is now one form of NaN
$x += 1; # $x should still be NaN
$y = +"a string"; # $x is another form of NaN such that
$y += 1; # now $y is 1.
Which would lead to something like:
$y = +"a string";
leading to $y being "NaN is undef"
$y = sqrt(-1);
leading to $y being "NaN is NaN".
And thus in either case $y.IsNum being false while further arithmetic could
preceed in the expected manner (most tools seem to largely treat
string->number as 0 where string doesn't start with a digit) which is often
useful behavior. While making is easy to check whether you really had a
Alternatively, perhaps this is actually the wrong approach, and both should
simple by NaN, but the initial usage is in error:
Damian Conway <firstname.lastname@example.org> wrotes:
> print "Inflation rate: " and $inflation = +<>
> until $inflation != NaN;
I think this is putting the cart before the horse... you're getting a number
and then asking if it was a number... a little rewrite:
print "Inflation rate: " and $inflation = +<>
should be easier to understand (and allows IEEE semantics for NaN which do
make sense but are not terribly clear to the un-initiated in tri-valued
logic) as well as avoiding the double-negative.
Senior Software Developer
Dell Technology Online
All opinions and statements mine and do not in any way (unless expressly
stated) imply anything at all on behalf of my employer