From:

Date:

October 9, 2001 03:30Subject:

RE: NaN semanticsMessage ID:

5D0C92E65C29D311A24D0090273C216803692875@BRKXMTCH02_bPiers Cawley [mailto:pdcawley@bofh.org.uk] 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 > proposal... > <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 verses $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" While $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 number. Alternatively, perhaps this is actually the wrong approach, and both should simple by NaN, but the initial usage is in error: Damian Conway <damian@mail.csse.monash.edu.au> 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 = +<> until $inflation.IsNum 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. Richard Cox 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 employerThread Previous | Thread Next

- NaN semantics by Tim Conrow
- RE: NaN semantics by Damian Conway
**RE: NaN semantics**by Richard_Cox- RE: NaN semantics by Dan Sugalski
- Re: NaN semantics by Jonathan Scott Duff
- RE: NaN semantics by Dan Sugalski
- Re: NaN semantics by Dan Sugalski
- Re: NaN semantics by Bart Lateur
- Re: NaN semantics by Dan Sugalski
- Re: NaN semantics by Glenn Linderman
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by Jonathan Scott Duff
- Re: NaN semantics by Dan Sugalski
- Re: NaN semantics by Michel Rodriguez
- Re: NaN semantics by Sam Vilain
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by Trond Michelsen
- Re: NaN semantics by Aaron Sherman
- Re: NaN semantics by Glenn Linderman
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by RaFaL Pocztarski
- RE: NaN semantics by David Whipp
- Re: NaN semantics by RaFaL Pocztarski
- NaN+NaNi by David Nicol
- Re: NaN+NaNi by Dan Sugalski
- Re: NaN+NaNi by Jonathan Scott Duff
- Re: NaN+NaNi by RaFaL Pocztarski
- Re: NaN+NaNi by raptor
- Re: NaN+NaNi by RaFaL Pocztarski
- Re: NaN+NaNi by Aaron Sherman
- Re: NaN+NaNi by Jonathan Scott Duff
- 3.243F6A888+C0FFEe-4i by David Nicol
- Re: NaN+NaNi by RaFaL Pocztarski
- Re: NaN+NaNi by Glenn Linderman
- Re: NaN+NaNi by RaFaL Pocztarski
- Re: NaN+NaNi by RaFaL Pocztarski
- Re: NaN+NaNi by RaFaL Pocztarski
- Re: NaN+NaNi by RaFaL Pocztarski
- Re: NaN semantics by Jonathan Scott Duff
- Re: NaN semantics by RaFaL Pocztarski
- RE: NaN semantics by David Whipp
- Re: NaN semantics by raptor
- Re: NaN semantics by Jonathan Scott Duff
- RE: NaN semantics by Brent Dax
- Re: NaN semantics by Dan Sugalski
- Re: NaN semantics by Nicholas Clark
- Re: NaN semantics by Mark
- Re: NaN semantics by Damian Conway
- RE: NaN semantics by Damian Conway
- Re: NaN semantics by Dan Sugalski
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by Damian Conway
- Re: NaN semantics by Piers Cawley
- Re: NaN semantics by Damian Conway
- RE: NaN semantics by Brent Dax
- Re: NaN semantics by Damian Conway
- Re: NaN semantics by Tim Conrow
- Re: NaN semantics by Damian Conway
- Re: NaN semantics by Damian Conway
- RE: NaN semantics by David Whipp
- Re: NaN semantics by Graham Barr
- Re: NaN semantics by Piers Cawley
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by Damian Conway
- Re: NaN semantics by Tim Conrow
- Re: NaN semantics by Damian Conway
- Re: NaN semantics by Me
- Re: NaN semantics by merlyn
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by John Siracusa
- Re: NaN semantics by RaFaL Pocztarski
- Re: NaN semantics by David Nicol
- Re: NaN semantics by RaFaL Pocztarski

nntp.perl.org: Perl Programming lists via nntp and http.

Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About