Re: NaN semantics
Nicholas Clark <[EMAIL PROTECTED]> wrote: > I had a think about this a few days ago. I can't see how to do fractions > in Roman Numerals. > integers and exponents in E notation should all be easy, shouldn't they? No major problem for fractions. As for irrational numbers... Mark.
Re: NaN semantics
RaFaL Pocztarski wrote: > I haven't got any contact with NaN before, but when Tim pointed that > NaN!=NaN is true in IEEE I thought that it does make sense. I see pros > and cons and it's not so ugly and non-intuitive as it can look. When > comparing $a and $b as numbers there is no need for $a==$b!=NaN, if > NaN!=NaN then $a==$b is ok for any values of $a and $b, it would be true > only if $a and $b are numbers and they are equal. If NaN==NaN is true, > then the longer $a==$b!=NaN is needed. So when comparing two scalars as > numbers NaN!=NaN being true makes it easier. But then "until $inflation > != NaN" would be useless as NaN!=anything is always true (NaN!=NaN, and > NaN!=anynumber). With NaN!=NaN some other way like $x.isNaN or $x.isnum > would be needed. Or maybe NaN evaluates to 'NaN' in string context and > +$x eq 'NaN' (or +$x eq NaN) could be used? NaN==NaN being false is in > fact very intuitive for me, as NaN is something without any numerical > meaning, so numerically compared to anything doesn't make sense (as == > means numerical equality, not just equality). Maybe it should be undef > instead of false? I'm coming to this thread after nearly a week of everyone weighing in their opinions, and fully expect to see what I'm about to type in stated by someone else, days ago, a little further down the long list of posts. What if not-a-number stringifies to NaN, but numerically always compares to false, so the conditional in the example could CLEARLY be written while $inflation ne NaN; -- David Nicol 816.235.1187 1,3,7-trimethylxanthine
Re: NaN semantics
David Nicol wrote: > RaFaL Pocztarski wrote: > > Or maybe NaN evaluates to 'NaN' in string context and > > +$x eq 'NaN' (or +$x eq NaN) could be used? NaN==NaN being false is in > > fact very intuitive for me, as NaN is something without any numerical > > meaning, so numerically compared to anything doesn't make sense (as == > > means numerical equality, not just equality). Maybe it should be undef > > instead of false? > > I'm coming to this thread after nearly a week of everyone weighing in > their opinions, and fully expect to see what I'm about to type in > stated by someone else, days ago, a little further down the long list > of posts. Actually you have just quoted me when I said that.. :) > What if not-a-number stringifies to NaN, but numerically always compares > to false, so the conditional in the example could CLEARLY be written > > while $inflation ne NaN; It should be: while +$inflation ne NaN; because $inflation itself can be (and probably is) some other string than 'NaN', so +$inflation evaluates to NaN, and when ne operator provides a string context it then evaluates to 'NaN'. - RaFaL Pocztarski, [EMAIL PROTECTED]
RE: NaN semantics
> > > First this thread tells me that "123foo" will be 123 in numeric > > > context. Now I find myself wondering what "123indigo" evaluates > > > to! > > > > It would evaluate to 123. If "use complex" is in effect, it would > > evaluate to 123i. At least that's the position I'm taking at the > > moment ;-) > > 123i unless of course we use nano prefix (postfix?), then it would be > 0.00123i of course. ;) In which case "123foo" is 123e-15 (femto). If we are going to have all these postfixes, then we would probably want invalid ones to evaluate to NaN instead of truncating them. We can always have a standard fn/method that strips the invalid characters off the end if the string: my $string = "1.23Ki4b2XXX". my $a = +string; # NaN my $b = +$string.numeric_prefix; # 1230 + 16i my $c = +$string.real_prefix;# 1230 my $d = +$string.integer_prefix; # 1 or some such thing. Dave.
Re: NaN semantics
Buddha Buck wrote: > As someone else pointed out, the "e" notation is good for powers of > 10. How about a corresponding "b" notation for binary > exponents? 4_294_967_296 == 4b30? I really like that idea, it makes the floating point (scientific?) notation symmetric and consistent with X/Xi SI prefixes. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
David Whipp wrote: > > So the imaginary numbers would be standard literals? Like > > > > $x=2+10i; > > > > Great idea, as well as sqrt(-1) returning 1i istead of raising the > > exception. BTW, I was thinking once that numeral literals > > like 4k or 10G > > (meaning 4*2**10, 10*2**30) would be very nice. What do you think? > > > > - RaFaL Pocztarski, [EMAIL PROTECTED] > > First this thread tells me that "123foo" will be 123 in numeric > context. Now I find myself wondering what "123indigo" evaluates > to! I have a strange felling that I should just shut up, as my ideas only cause a lot of chaos... :) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Jonathan Scott Duff wrote: > On Wed, Oct 10, 2001 at 10:21:38AM -0700, David Whipp wrote: > > First this thread tells me that "123foo" will be 123 in numeric > > context. Now I find myself wondering what "123indigo" evaluates > > to! > > It would evaluate to 123. If "use complex" is in effect, it would > evaluate to 123i. At least that's the position I'm taking at the > moment ;-) 123i unless of course we use nano prefix (postfix?), then it would be 0.00123i of course. ;) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Glenn Linderman wrote: > An excellant idea. I was unaware of that standard, but was trying to head that > direction in my last posting. > > Someone thought it wouldn't work with imaginary numbers, but there actually is > no ambiguity if the imaginary i must immediately follow the number, and the > metric suffix follow that, if both exist. You're right, I was assuming that the imaginary i must be in the very end of literal, and was even thinking about using j instead. :) OK, that seems to be the nicest solution. So we have: 5Gmeans 5 * 10**9, 5 giga 5Gi means 5 * 2**30, 5 gibi 5iG means 5 * 10**9 * i, 5i giga 5iGi means 5 * 2**30 * i, 5i gibi (I really like those binary prefixes names!) Very nice, unambiguous, compatible with SI standard, no need for any pragmas, I'm really impressed! - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
On Wed, Oct 10, 2001 at 10:21:38AM -0700, David Whipp wrote: > First this thread tells me that "123foo" will be 123 in numeric > context. Now I find myself wondering what "123indigo" evaluates > to! It would evaluate to 123. If "use complex" is in effect, it would evaluate to 123i. At least that's the position I'm taking at the moment ;-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: prefix-postfix [was Re: NaN semantics]
On Wed, Oct 10, 2001 at 06:28:42PM +0200, raptorVD wrote:
> U mean something like 'term' (or how this thing is called 'bareword' ? )
> So I can say :
> # $x = 10k;
> my sub operator:number is postfix(k) ($num) {
> return $num * 1000
> }
I think that would be
sub operator:K is postfix prec(\&operator:-($)) ($num) {
return $num * 1000;
}
but yeah, that's the idea. And it would live in a module so that
users would have to do
use BinaryMetric; # or some such
to get it.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
prefix-postfix [was Re: NaN semantics]
U mean something like 'term' (or how this thing is called 'bareword' ? )
So I can say :
# $x = 10k;
my sub operator:number is postfix(k) ($num) {
return $num * 1000
}
# $x = 10K;
my sub operator:number is postfix(K) ($num) {
return $num * 1024
}
#u can say later print $x if $x?; :")
my sub operator:var is postfix:(?) ($var) {
$num > 10 ?? 1 :: 0;
}
my sub operator:sub is prefix:(U) () {
uc @params
}
very oversimplified of course... It become funny :") isn't it...
=
iVAN
[EMAIL PROTECTED]
=
| On Wed, Oct 10, 2001 at 05:21:02PM +0200, raptor wrote:
| > | So the imaginary numbers would be standard literals? Like
| > |
| > | $x=2+10i;
| > |
| > | Great idea, as well as sqrt(-1) returning 1i istead of raising the
| > | exception. BTW, I was thinking once that numeral literals like 4k or
10G
| > | (meaning 4*2**10, 10*2**30) would be very nice. What do you think?
| >
| > I like the idea ... this is one of the ways to suspend the calculations
to
| > the last moment...
| > But one probelm comes to my mind, what the k,G etc mean
| > 1000 or 1024
| > or k => 1000, K => 1024
| >
| > Or probably the best way will be to have a hook so that we can specify
what
| > is a Number and how it has to be calculated down to the real
number...!!!
|
| How about we let users define their own postfix operators such that
| they can make 10K, 10M, 10G mean whatever they want. Perhaps this is
| also where the postfix "?" and "!" from Ruby can come in.
|
| I'd still advocate supporting imaginary numbers in core somehow
| though. With a pragma would be best I think so that exceptions are
| thrown on sqrt(-1) unless they really want imaginaries.
RE: NaN semantics
> So the imaginary numbers would be standard literals? Like > > $x=2+10i; > > Great idea, as well as sqrt(-1) returning 1i istead of raising the > exception. BTW, I was thinking once that numeral literals > like 4k or 10G > (meaning 4*2**10, 10*2**30) would be very nice. What do you think? > > - RaFaL Pocztarski, [EMAIL PROTECTED] First this thread tells me that "123foo" will be 123 in numeric context. Now I find myself wondering what "123indigo" evaluates to! Dave.
Re: NaN semantics
At 07:01 PM 10/10/2001 +0200, Bart Lateur wrote: >On Wed, 10 Oct 2001 11:52:16 -0400, Dan Sugalski wrote: > > >>If people want base 10, let them use "e" syntax. > >> > >>1e3 = 1000 > >>1k = 1024 > > > >I'll leave that for Larry to decide. I'm just thinking of all the 60G hard > >drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm > >resistors that are really 1000 ohms. (Well, give or take a bit for ambient > >temperature...) > >You optimist! The precision of such resistors is often no better than 5 >or 10%. That is more than 24 ohm. Hey, I never said *which* bit. Bit 5 would be about the right one. :-P Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
On Wed, 2001-10-10 at 17:32, Dan Sugalski wrote: > At 05:12 PM 10/10/2001 +0200, RaFaL Pocztarski wrote: > > >BTW, I was thinking once that numeral literals like 4k or 10G > >(meaning 4*2**10, 10*2**30) would be very nice. What do you think? > > I think the meaning of the suffices are sufficiently vague as to make me > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case > for both, and that's never a good sign. I must say I'd like it too, and I don't care which one you choose, this would mostly be used by sysadmins to sort the output of du and the likes, so it really doesn't matter. Michel Rodriguez Perl & XML http://www.xmltwig.com
Re: NaN semantics
On Wed, Oct 10, 2001 at 06:38:05PM +0200, RaFaL Pocztarski wrote: > I prefer powers of 1024 because it help a lot more than powers of 1000. > But if you think that the ambiguity is the only problem then use kbin; / > use kdec; or use k1000; / use k1024; pragmas could solve it. $K = 2**10; $M = $K * 1000; $G = $M * 1000; print "These files are $(20 * $k) each\n"; print "The disk has $(2 * $M) left of $(80 * $G)!\n"; It seems to me that these things should be in a module rather than as pragmas. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: NaN semantics
On Wed, 10 Oct 2001 11:52:16 -0400, Dan Sugalski wrote: >>If people want base 10, let them use "e" syntax. >> >>1e3 = 1000 >>1k = 1024 > >I'll leave that for Larry to decide. I'm just thinking of all the 60G hard >drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm >resistors that are really 1000 ohms. (Well, give or take a bit for ambient >temperature...) You optimist! The precision of such resistors is often no better than 5 or 10%. That is more than 24 ohm. But anyway... I hope a kg is still 1000 grams, not 1024 grams? -- Bart.
Re: NaN semantics
Trond Michelsen wrote: > There's always the possibility of supporting SI's binary prefixes ;) > > http://physics.nist.gov/cuu/Units/binary.html An excellant idea. I was unaware of that standard, but was trying to head that direction in my last posting. Someone thought it wouldn't work with imaginary numbers, but there actually is no ambiguity if the imaginary i must immediately follow the number, and the metric suffix follow that, if both exist. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: NaN semantics
Dan Sugalski wrote: > At 04:42 PM 10/10/2001 +0100, Sam Vilain wrote: > >On Wed, 10 Oct 2001 11:32:02 -0400 > >Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > > > >Great idea, as well as sqrt(-1) returning 1i istead of raising the > > > >exception. > > > If we do them, yep. Currently no promises there. > > > >If you do that, make sure it has to be enabled with a pragma. Having > >complex numbers showing up in the middle of bad code is a scary concept :) > > Yeah, but is the code actually *wrong* if it does a sqrt(-1)? (I know, > don't go there... :) I strongly recommend that if NaN exist, that it have IEEE semantics. I personally think the subset of people that understand NaN is larger than a few handfuls. And it has beneficial utility, so I recommend having it. And Apo2, regarding Infinities and NaNs (RFC 038) says: > This is likely to slow down numeric processing in some locations. Perhaps it could >be turned off when desirable. We need to be > careful not to invent something that is guaranteed to run slower than IEEE floating >point. We should also try to avoid defining a > type system that makes translation of numeric types to Java or C# types problematic. > > That being said, standard semantics are a good thing, and should be the default >behavior. > Note that just because NaN == NaN never produces a true value (numerical inequality), that that doesn't prevent other matching operators from considering NaN and NaN equivilant. Switch, for example, could have an option for choosing NaN as one case, and executing that case when the input datum is NaN. > > > I think the meaning of the suffices are sufficiently vague as to make me > > > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good > > > case for both, and that's never a good sign. > > > >If people want base 10, let them use "e" syntax. > > > >1e3 = 1000 > >1k = 1024 > > I'll leave that for Larry to decide. I'm just thinking of all the 60G hard > drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm > resistors that are really 1000 ohms. (Well, give or take a bit for ambient > temperature...) The reminder of the "e" (scientific notation) syntax reminds me that the whole issue is really one of choosing a syntax to be unambiguous with regards to its semantics. Of course the metric system defines quite a few prefixes (http://physics.nist.gov/cuu/Units/prefixes.html), all of which would be handy to practitioners in various sciences. Micro would, of course, require Unicode support. We could probably omit "hecto", "deka", "deci" and maybe "centi" prefixes, due to infrequent usage. Note that the prefixes are _case sensitive_ and that 1000 is represented by "k", not "K"!!! (although it isn't one of the case ambiguous ones, so perhaps we could include the common "K" as well). So since the metric system truly is based on base 10, it seems only reasonable that that standard be conformed to, so I propose allowing the Symbols from the above web page as numerical suffixes with the definitions found therein. However, for convenience in programming with powers of 2, I propose allowing a further suffix of "2" to mean the 1024 instead of 1000 for each of the symbols that are powers of 1000. So we would have: 1k == 1000 1k2 == 1024 1M == 100 1M2 == 1048576 ... 1m == 1e-3 1m2 == (1/1k2) 1µ == 1e-6 1µ2 == (1/1M2) ... Perhaps we only need to support the positive powers with the binary suffix, as the computer industry hasn't dealt much in fractions of bytes :) Other syntax variations may be more acceptable than the suffix "2"--maybe a suffix "b" (for binary) resulting in 1024 == 1kb -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: NaN semantics
Dan Sugalski wrote: > I'll leave that for Larry to decide. I'm just thinking of all the 60G hard > drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm > resistors that are really 1000 ohms. (Well, give or take a bit for ambient > temperature...) I prefer powers of 1024 because it help a lot more than powers of 1000. But if you think that the ambiguity is the only problem then use kbin; / use kdec; or use k1000; / use k1024; pragmas could solve it. I would prefer to use k1024 by default (with warning. and maybe with use strict the default would not be allowed, i.e. user have to choose one to use it. but I would like the default 1024 to work with one-liners) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Trond Michelsen wrote: > >> BTW, I was thinking once that numeral literals like 4k or 10G > >> (meaning 4*2**10, 10*2**30) would be very nice. What do you think? > > I think the meaning of the suffices are sufficiently vague as to make me > > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case > > for both, and that's never a good sign. > > There's always the possibility of supporting SI's binary prefixes ;) I thought about it but it wouldn't work with imaginary numbers. :) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
On Wed, Oct 10, 2001 at 06:20:31PM +0200, Trond Michelsen wrote: > >> BTW, I was thinking once that numeral literals like 4k or 10G > >> (meaning 4*2**10, 10*2**30) would be very nice. What do you think? > > I think the meaning of the suffices are sufficiently vague as to make me > > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case > > for both, and that's never a good sign. > > There's always the possibility of supporting SI's binary prefixes ;) > > http://physics.nist.gov/cuu/Units/binary.html I'm not really fond of 1K meaning anything, but if it's deemed appropos, I vote for the binary meaning. Question on the NIST definitions though: What does 1eie1i mean? I *think* that that's 2^60 times ten to the 1i... correct? Do we have precidence in mind, here? Can I say 1iei? Does anyone *do* that? -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF "Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew." -Queen/_'39_
Re: NaN semantics
On Wed, Oct 10, 2001 at 05:21:02PM +0200, raptor wrote: > | So the imaginary numbers would be standard literals? Like > | > | $x=2+10i; > | > | Great idea, as well as sqrt(-1) returning 1i istead of raising the > | exception. BTW, I was thinking once that numeral literals like 4k or 10G > | (meaning 4*2**10, 10*2**30) would be very nice. What do you think? > > I like the idea ... this is one of the ways to suspend the calculations to > the last moment... > But one probelm comes to my mind, what the k,G etc mean > 1000 or 1024 > or k => 1000, K => 1024 > > Or probably the best way will be to have a hook so that we can specify what > is a Number and how it has to be calculated down to the real number...!!! How about we let users define their own postfix operators such that they can make 10K, 10M, 10G mean whatever they want. Perhaps this is also where the postfix "?" and "!" from Ruby can come in. I'd still advocate supporting imaginary numbers in core somehow though. With a pragma would be best I think so that exceptions are thrown on sqrt(-1) unless they really want imaginaries. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: NaN semantics
>> BTW, I was thinking once that numeral literals like 4k or 10G >> (meaning 4*2**10, 10*2**30) would be very nice. What do you think? > I think the meaning of the suffices are sufficiently vague as to make me > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case > for both, and that's never a good sign. There's always the possibility of supporting SI's binary prefixes ;) http://physics.nist.gov/cuu/Units/binary.html -- Trond Michelsen
Re: NaN semantics
| So the imaginary numbers would be standard literals? Like | | $x=2+10i; | | Great idea, as well as sqrt(-1) returning 1i istead of raising the | exception. BTW, I was thinking once that numeral literals like 4k or 10G | (meaning 4*2**10, 10*2**30) would be very nice. What do you think? I like the idea ... this is one of the ways to suspend the calculations to the last moment... But one probelm comes to my mind, what the k,G etc mean 1000 or 1024 or k => 1000, K => 1024 Or probably the best way will be to have a hook so that we can specify what is a Number and how it has to be calculated down to the real number...!!! = iVAN [EMAIL PROTECTED] =
Re: NaN semantics
At 04:42 PM 10/10/2001 +0100, Sam Vilain wrote: >On Wed, 10 Oct 2001 11:32:02 -0400 >Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > >Great idea, as well as sqrt(-1) returning 1i istead of raising the > > >exception. > > If we do them, yep. Currently no promises there. > >If you do that, make sure it has to be enabled with a pragma. Having >complex numbers showing up in the middle of bad code is a scary concept :) Yeah, but is the code actually *wrong* if it does a sqrt(-1)? (I know, don't go there... :) > > I think the meaning of the suffices are sufficiently vague as to make me > > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good > > case for both, and that's never a good sign. > >If people want base 10, let them use "e" syntax. > >1e3 = 1000 >1k = 1024 I'll leave that for Larry to decide. I'm just thinking of all the 60G hard drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm resistors that are really 1000 ohms. (Well, give or take a bit for ambient temperature...) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
Dan Sugalski wrote: > At 05:12 PM 10/10/2001 +0200, RaFaL Pocztarski wrote: > > >BTW, I was thinking once that numeral literals like 4k or 10G > >(meaning 4*2**10, 10*2**30) would be very nice. What do you think? > > I think the meaning of the suffices are sufficiently vague as to make me > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case > for both, and that's never a good sign. I was thinking about powers of 1024, as powers of 1000 are of course easy to write in decimal system (4e9, 4_000_000_000, but 4_294_967_296 and 4*2**30). - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
On Wed, 10 Oct 2001 11:32:02 -0400 Dan Sugalski <[EMAIL PROTECTED]> wrote: > >Great idea, as well as sqrt(-1) returning 1i istead of raising the > >exception. > If we do them, yep. Currently no promises there. If you do that, make sure it has to be enabled with a pragma. Having complex numbers showing up in the middle of bad code is a scary concept :) > I think the meaning of the suffices are sufficiently vague as to make me > uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good > case for both, and that's never a good sign. If people want base 10, let them use "e" syntax. 1e3 = 1000 1k = 1024 Sam.
Re: NaN semantics
At 05:12 PM 10/10/2001 +0200, RaFaL Pocztarski wrote: >Dan Sugalski wrote: > > > At 08:37 AM 10/9/2001 -0700, Brent Dax wrote: > > >For consistency, I'd prefer to use is: 3+(2 is i). > > > > Well, the convention is suffixing an imaginary number with an i. I don't > > think we'd be too well served to go a different route. > >So the imaginary numbers would be standard literals? Like > > $x=2+10i; > >Great idea, as well as sqrt(-1) returning 1i istead of raising the >exception. If we do them, yep. Currently no promises there. >BTW, I was thinking once that numeral literals like 4k or 10G >(meaning 4*2**10, 10*2**30) would be very nice. What do you think? I think the meaning of the suffices are sufficiently vague as to make me uncomfortable supporting them. Is 1K 1024 or 1000? I can make a good case for both, and that's never a good sign. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
Dan Sugalski wrote: > At 08:37 AM 10/9/2001 -0700, Brent Dax wrote: > >For consistency, I'd prefer to use is: 3+(2 is i). > > Well, the convention is suffixing an imaginary number with an i. I don't > think we'd be too well served to go a different route. So the imaginary numbers would be standard literals? Like $x=2+10i; Great idea, as well as sqrt(-1) returning 1i istead of raising the exception. BTW, I was thinking once that numeral literals like 4k or 10G (meaning 4*2**10, 10*2**30) would be very nice. What do you think? - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Damian Conway wrote: >> But I assume that == means numerically equal (and here I could be >> wrong). If what I assume is true however, then anything which doesn't >> have any numerical meaning, numerically compared to anything (even to >> itself) should not return the misleading result that the two compared >> values are numerically equal. >> >> Then again, if you tell me that == operator doesn't mean "numerically >> equal", I will agree that NaN==NaN should be true even considering that >> 'cat'=='dog' will also be true. > > But 'cat'=='dog' *is* true. Numerically, they *are* equal. > They are equally not numbers. One should certainly get a warning > (and one will if warnings are enabled), but this > expression shouldn't return false. OK, now I see your point even better. The difference in our points is that I suggested that numerical comparison of NaNs shouldn't make sense. But yes, two NaNs are equally not numbers. Now the question is if being a NaN should be the special case of numerical meaning or the lack of any numerical meaning. I don't think that the one idea is more correct than another, maybe that's the matter of taste, however they are mutually exclusive, so one of them has to be chosen. I joined this thread, because I thought that assuming that NaN!=NaN idea is just ugly and thus not worth deeper discussion, was oversimplifying and the problem deserves a little more of controversy. However I wasn't suspecting that NaN semantics will grow to one of the most important threads here. > Sigh. I *do* see your point of view (Laziness), but I still have immense > difficulty with the notion that: > > $x == NaN > > doesn't return true if $x contains NaN. Well, Laziness is very important to me, but here it won't be hurt much, as in fact $x==$y!=NaN wouldn't be used very often. Only when numerically comparing two unknown values, and I can't remember when I did it last time. Maybe when sorting but with sorting it doesn't matter if every NaN is equal or not. Hmmm, maybe NaN==NaN would make starship operator simpler..? Anyway, even with NaN==NaN 'text'!=0, unlike Perl 5, where 'text'==0, which could've been the main problem with == operator. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Tim suggested: > How about punting by using nan (all lowercase) > as a boolean logic not-a-number, leaving NaN > for someone to (later) create an IEEE style > tristate not-a-number. Err, I think not. Having C and C that differ so markedly in behaviour is probably a Recipe For Disaster. Better to have a totally different name if we must cowtow to the IEEE. Besides, I know you just want this so you can: write nan and pop; ;-) Damian
Re: NaN semantics
Tim suggested: > I *like* the proposed Perl6 semantics; it's DWIMier. The problem is > just the name collision. Why not 'inval' (for invalid), or some > such (badval?). This would preserve NaN in its IEEE sense for the > numerical algorithm crew to use. And thus we circle back towards C. I'll mention this to Larry (who's probably watching silently over us anyway). Damian
RE: NaN semantics
Dave observed: > > but I still have immense difficulty with the notion that: > > > > $x == NaN > > > > doesn't return true if $x contains NaN. > > Anyone with a hardware background should have no difficulty with > this concept. Yep. You, me, and the (comparative) handful of others in that category. ;-) Damian
Re: NaN semantics
Nicholas wrote: > I had a think about this a few days ago. I can't see how to do fractions > in Roman Numerals. Take a look at how Lingua::Romana::Perligata (and, incidentally, the ancient Romans) did it. Damianus
Re: NaN semantics
A quarter-baked idea: How about punting by using nan (all lowercase) as a boolean logic not-a-number, leaving NaN for someone to (later) create an IEEE style tristate not-a-number. Later: $foo == NaN; # NaN literal is not same as nan literal use NaN; NaN(expr);
Re: NaN semantics
Damian Conway wrote: > > Sigh. I *do* see your point of view (Laziness), but I still have immense > difficulty with the notion that: > > $x == NaN > > doesn't return true if $x contains NaN. I *like* the proposed Perl6 semantics; it's DWIMier. The problem is just the name collision. Why not 'inval' (for invalid), or some such (badval?). This would preserve NaN in its IEEE sense for the numerical algorithm crew to use. I see the next problem, though; profusion of 'false' values. 0, "", undef, inval, NaN, ... ??? There was a long thread that touched on this in the context of tristate logic in discussion of and around RFC 263, I think. -- -- Tim Conrow [EMAIL PROTECTED] |
RE: NaN semantics
Damian Conway wrote:
> but I still have immense difficulty with the notion that:
>
> $x == NaN
>
> doesn't return true if $x contains NaN.
Anyone with a hardware background should have no difficulty with
this concept. All common HDLs have multi-valued logic systems,
including values like '0', '1' and 'x' (Some systems distinguish
9 different values!).
The language Verilog has 2 equality operators. The most common is
"a == b", which returns false if a and/or b contains 'x'. But it
also provides "a === b"; which will return true if a and b are
identical (thus true if a and b are 'x').
The correct value of "NaN == NaN" should, of course, be "NaN".
This value should exponentially spread through the code:
if ('cat' == 'dog')
{
$foo = 1
}
else
{
$foo = 0
}
assert($foo.isNaN); # true!
However, Perl6 is not a hardware simulator, so I have no expectation
that these semantics will be supported.
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
RE: NaN semantics
At 08:37 AM 10/9/2001 -0700, Brent Dax wrote: >Jonathan Scott Duff ># On Tue, Oct 09, 2001 at 10:17:26AM -0400, Dan Sugalski wrote: ># > Depending on what Larry's planning, we may weld in support ># for imaginary ># > numbers. While they're mind-warping, in some ways they're ># better than ># > having a line labeled "Beyond here be dragons" or something. ># ># Neat. It'd be nice to have the "i" syntax as well: 3+2i ># ># I can hear the crys now though "Oh no! First ``x'', then ``v'', now ># ``_'' and ``i''. Sheesh! When will it end?!?" ;-) > >For consistency, I'd prefer to use is: 3+(2 is i). Well, the convention is suffixing an imaginary number with an i. I don't think we'd be too well served to go a different route. > Well, either way, >this is a good thing for properties to handle. GO PROPERTIES! ;^) I'm not sure about that. I think the imaginary part of a number rates a little higher than the property section. It really is a core piece of the number, after all. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: NaN semantics
Jonathan Scott Duff # On Tue, Oct 09, 2001 at 10:17:26AM -0400, Dan Sugalski wrote: # > Depending on what Larry's planning, we may weld in support # for imaginary # > numbers. While they're mind-warping, in some ways they're # better than # > having a line labeled "Beyond here be dragons" or something. # # Neat. It'd be nice to have the "i" syntax as well: 3+2i # # I can hear the crys now though "Oh no! First ``x'', then ``v'', now # ``_'' and ``i''. Sheesh! When will it end?!?" ;-) For consistency, I'd prefer to use is: 3+(2 is i). Well, either way, this is a good thing for properties to handle. GO PROPERTIES! ;^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Re: NaN semantics
At 09:33 AM 10/9/2001 -0500, Jonathan Scott Duff wrote: >On Tue, Oct 09, 2001 at 10:17:26AM -0400, Dan Sugalski wrote: > > Depending on what Larry's planning, we may weld in support for imaginary > > numbers. While they're mind-warping, in some ways they're better than > > having a line labeled "Beyond here be dragons" or something. > >Neat. It'd be nice to have the "i" syntax as well: 3+2i > >I can hear the crys now though "Oh no! First ``x'', then ``v'', now >``_'' and ``i''. Sheesh! When will it end?!?" ;-) r. When we allow Roman Numerals for constants we're doomed. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
On Tue, Oct 09, 2001 at 10:17:26AM -0400, Dan Sugalski wrote: > Depending on what Larry's planning, we may weld in support for imaginary > numbers. While they're mind-warping, in some ways they're better than > having a line labeled "Beyond here be dragons" or something. Neat. It'd be nice to have the "i" syntax as well: 3+2i I can hear the crys now though "Oh no! First ``x'', then ``v'', now ``_'' and ``i''. Sheesh! When will it end?!?" ;-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: NaN semantics
At 05:29 AM 10/9/2001 -0500, [EMAIL PROTECTED] wrote: >Piers Cawley [mailto:[EMAIL PROTECTED]] 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. Depending on what Larry's planning, we may weld in support for imaginary numbers. While they're mind-warping, in some ways they're better than having a line labeled "Beyond here be dragons" or something. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
> "Damian" == Damian Conway <[EMAIL PROTECTED]> writes: Damian> Sigh. I *do* see your point of view (Laziness), but I still have immense Damian> difficulty with the notion that: Damian> $x == NaN Damian> doesn't return true if $x contains NaN. Just think of it as a quantum number that hasn't collapsed. :) "No two NaNs are alike!" Read it as "one of many non-numbers, chosen at random". -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: NaN semantics
On Tue, Oct 09, 2001 at 04:39:47PM +1000, Damian Conway wrote:
> Sigh. I *do* see your point of view (Laziness), but I still have immense
> difficulty with the notion that:
>
> $x == NaN
>
> doesn't return true if $x contains NaN.
I agree. The difficulty I have is that it is the comparison that IEEE
define to return false. Which means
if ('cat' != 'dog')
would not yeild the same result as
unless('cat' == 'dog')
Which I think would lead to a lot of confusion when debugging.
Graham.
RE: NaN semantics
Piers Cawley [mailto:[EMAIL PROTECTED]] 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... > 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 <[EMAIL PROTECTED]> 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 employer
Re: NaN semantics
Damian Conway <[EMAIL PROTECTED]> writes: > >> But I assume that == means numerically equal (and here I could be > >> wrong). If what I assume is true however, then anything which > doesn't > >> have any numerical meaning, numerically compared to anything > (even to > >> itself) should not return the misleading result that the two > compared > >> values are numerically equal. >> >> Then again, if you tell me that == operator doesn't mean > "numerically > >> equal", I will agree that NaN==NaN should be true even > considering that > >> 'cat'=='dog' will also be true. > > But 'cat'=='dog' *is* true. Numerically, they *are* equal. > They are equally not numbers. One should certainly get a warning > (and one will if warnings are enabled), but this > expression shouldn't return false. > > Sigh. I *do* see your point of view (Laziness), but I still have > immense > > difficulty with the notion that: > > $x == NaN > > doesn't return true if $x contains NaN. 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. 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...
Re: NaN semantics
> But I assume that == means numerically equal (and here I could be > wrong). If what I assume is true however, then anything which doesn't > have any numerical meaning, numerically compared to anything (even to > itself) should not return the misleading result that the two compared > values are numerically equal. > > Then again, if you tell me that == operator doesn't mean "numerically > equal", I will agree that NaN==NaN should be true even considering that > 'cat'=='dog' will also be true. But 'cat'=='dog' *is* true. Numerically, they *are* equal. They are equally not numbers. One should certainly get a warning (and one will if warnings are enabled), but this expression shouldn't return false. Sigh. I *do* see your point of view (Laziness), but I still have immense difficulty with the notion that: $x == NaN doesn't return true if $x contains NaN. Damian
Re: NaN semantics
Dan Sugalski wrote: > At 09:07 AM 10/8/2001 +1000, Damian Conway wrote: > >I see your (and others') point here, but I view NaN as a *marker* indicating > >a non-numeric result. Markers should always compare equal to themselves. > >(Frankly, *everything* should compare equal to itself -- which is where > >IEEE 754 goes horribly wrong.) > > FWIW, I've always viewed NaN as equivalent to SQL's NULL, and treated it as > such. (Of course, proper support for either would require me to build in > three-value logic to Parrot, and I'm not sure I'm willing to go quite that > far... :) Well, I was hoping that three-value logic will be supported by Parrot (at least I hope it will be still supported by Perl, but without support in Parrot it surely won't be so easy and efficient). It's a superset of Boolean logic so it doesn't collide with any strict Boolean arithmetic. Maybe it would be possible to define what kind of logic the user wants? Boolean, three-value, fuzzy logic - that would be very nice. In a similar way you define meaning of other things in Parrot to match different languages. What do you think about that? - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
At 09:07 AM 10/8/2001 +1000, Damian Conway wrote: >I see your (and others') point here, but I view NaN as a *marker* indicating >a non-numeric result. Markers should always compare equal to themselves. >(Frankly, *everything* should compare equal to itself -- which is where >IEEE 754 goes horribly wrong.) FWIW, I've always viewed NaN as equivalent to SQL's NULL, and treated it as such. (Of course, proper support for either would require me to build in three-value logic to Parrot, and I'm not sure I'm willing to go quite that far... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: NaN semantics
Damian Conway wrote: > RaFaL asked: > >> So OK, tell me if I get it right, and how (and why) it will look in Perl >> 6. From Exegesis I see that NaN==NaN, but that's not stated in >> Apocalypse (or I just missed it). > > No, it's not stated there. But I hope that Perl 6 will follow the lead of > other high level languages and reject the non-identity of NaN. OK, I see what's your point (from your answer to Piers). I don't like NaN==NaN returning true for practical reasons (I'm to lazy to type $x==$y!=NaN when I could just $x==$y). I personally would like NaN to return undef (not plain false) in any numerical comparison (so also NaN==NaN would return undef). I think that we don't agree because I see == operator as numerical comparison, not just comparison. If it was just comparison then of course I agree that anything compared to itself should return true, it wouldn't make sense otherwise. But I assume that == means numerically equal (and here I could be wrong). If what I assume is true however, then anything which doesn't have any numerical meaning, numerically compared to anything (even to itself) should not return the misleading result that the two compared values are numerically equal. Then again, if you tell me that == operator doesn't mean "numerically equal", I will agree that NaN==NaN should be true even considering that 'cat'=='dog' will also be true. I know that == is also used for comparing references but they have numerical meaning. So please tell me if I'm wrong assuming that == operator means numerical equality. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
> > Let me make it clear: AFAIK Perl NaN's will not be IEEE 754 > > compliant. That was certainly my intention in suggesting them to > > Larry. I share the view of a number of other language designers that > > the non-self-identity of IEEE NaN is (to slightly misquote Tim) > > "ugly, non-intuitive and ugly; and non-intuitive too". > > But NaN could already be argued to be ugly, non intuitive and ugly. > When you compare two indeterminate quantities (if quantity is even the > right word) then expecting them to be equal is somewhat surprising. I see your (and others') point here, but I view NaN as a *marker* indicating a non-numeric result. Markers should always compare equal to themselves. (Frankly, *everything* should compare equal to itself -- which is where IEEE 754 goes horribly wrong.) > Maybe NaN is a misnomer, since NaN already has a defined meaning in > this context, the IEEE sense. Changing its semantics in a perl context > is surely a recipe for confusion (assuming you're not already confused > by the IEEE behaviour). I suspect the number of people who know and understand the current IEEE semantics is relatively small, compared to the number of people who would be freshly confused if we honoured it in Perl 6. I would dread to have to explain why: $value == NaN; produces the opposite value to: $value.isNaN; (and only in the important case). > Trouble is, I'm not entirely sure what a good name for this would be. C is a good name. We just have to wrest it back from the corrupting clutches of the bit-twiddlers! Though, I confess, I wouldn't be averse to seeing a C value in Perl. ;-) Damian
Re: NaN semantics
RaFaL asked: > So OK, tell me if I get it right, and how (and why) it will look in Perl > 6. From Exegesis I see that NaN==NaN, but that's not stated in > Apocalypse (or I just missed it). No, it's not stated there. But I hope that Perl 6 will follow the lead of other high level languages and reject the non-identity of NaN. > BTW, I really like the direction of Perl 6 development, all of you are > doing really great job here. I was very surprised when I saw the > negative feedback on Slashdot, and I thought that if my enthusiasm is so > abnormal, than maybe it's a sign that I should join your team. :) > Really, I'd love to help with Perl 6 development if I can be useful > somehow. You're already doing it. Rather than more cooks, we need more food critics: as many people as possible working through the ramifications and inconsistencies of the design. Damian
Re: NaN semantics
Tim wrote: > > Err. Are you *sure*? That's an C, not a C, you realize? > > Yes. I had to use all my fingers and toes to keep everything straight, > but I think I did. :-) In the semantics you show (different from IEEE > semantics) "NaN==NaN" is true, so "NaN!=NaN" is false, which is why the > loop continues until a valid number is entered. Uh huh. As I pointed out, I had missed your assumption of IEEE semantics. Damian
Re: NaN semantics
Damian Conway <[EMAIL PROTECTED]> writes: > >> His point was that the NaN IEEE came up with is defined to have >> NaN != NaN, and that it might be confusing if Perl's behavior >> wasn't consistent with that. Not that I think NaN != NaN is a >> particularly good idea, but consistency with other languages >> may be. If NaN != NaN, then his example is correct. > > Sorry. I was focused on the Perl 6 semantics and missed that > implication. > > Let me make it clear: AFAIK Perl NaN's will not be IEEE 754 > compliant. That was certainly my intention in suggesting them to > Larry. I share the view of a number of other language designers that > the non-self-identity of IEEE NaN is (to slightly misquote Tim) > "ugly, non-intuitive and ugly; and non-intuitive too". But NaN could already be argued to be ugly, non intuitive and ugly. When you compare two indeterminate quantities (if quantity is even the right word) then expecting them to be equal is somewhat surprising. Maybe NaN is a misnomer, since NaN already has a defined meaning in this context, the IEEE sense. Changing its semantics in a perl context is surely a recipe for confusion (assuming you're not already confused by the IEEE behaviour). Trouble is, I'm not entirely sure what a good name for this would be. -- Piers
RE: NaN semantics
> His point was that the NaN IEEE came up with is defined to have NaN != > NaN, and that it might be confusing if Perl's behavior wasn't consistent > with that. Not that I think NaN != NaN is a particularly good idea, but > consistency with other languages may be. If NaN != NaN, then his > example is correct. Sorry. I was focused on the Perl 6 semantics and missed that implication. Let me make it clear: AFAIK Perl NaN's will not be IEEE 754 compliant. That was certainly my intention in suggesting them to Larry. I share the view of a number of other language designers that the non-self-identity of IEEE NaN is (to slightly misquote Tim) "ugly, non-intuitive and ugly; and non-intuitive too". ;-) > P.S. Congratulations to you and Larry for waking up perl6-language. I > had seen almost no traffic on it in weeks, and was starting to get a bit > worried that thoughts on the languages were coughing, sputtering and > dying. :^) Just one of many eyes in Hurricane Perl, I assure you! ;-) Damian
Re: NaN semantics
John Siracusa wrote: > On 10/7/01 4:19 PM, RaFaL Pocztarski wrote: > > I was very surprised when I saw the negative feedback on Slashdot > > Heh, did you just discover Slashdot recently? ;) Well, maybe I was so excited about everything I read about Perl 6 that I thought everyone will share my enthusiasm. But hey, that's very optimistic, when most people won't learn Perl 6, then I'll be relatively smarter! :) - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
On 10/7/01 4:19 PM, RaFaL Pocztarski wrote: > I was very surprised when I saw the negative feedback on Slashdot Heh, did you just discover Slashdot recently? ;) -John
Re: NaN semantics
Tim Conrow wrote: > Damian Conway said: >> > > print "Inflation rate: " and $inflation = +<> >> > > until $inflation != NaN; >> > >> > This requires that C be false, causing the loop to >> > continue until a valid numeric string is entered. > > > Err. Are you *sure*? That's an C, not a C, you realize? > > Yes. I had to use all my fingers and toes to keep everything straight, > but I think I did. :-) In the semantics you show (different from IEEE > semantics) "NaN==NaN" is true, so "NaN!=NaN" is false, which is why the > loop continues until a valid number is entered. Hi, This is my first post here, so don't laugh if I say something stupid. :) I haven't got any contact with NaN before, but when Tim pointed that NaN!=NaN is true in IEEE I thought that it does make sense. I see pros and cons and it's not so ugly and non-intuitive as it can look. When comparing $a and $b as numbers there is no need for $a==$b!=NaN, if NaN!=NaN then $a==$b is ok for any values of $a and $b, it would be true only if $a and $b are numbers and they are equal. If NaN==NaN is true, then the longer $a==$b!=NaN is needed. So when comparing two scalars as numbers NaN!=NaN being true makes it easier. But then "until $inflation != NaN" would be useless as NaN!=anything is always true (NaN!=NaN, and NaN!=anynumber). With NaN!=NaN some other way like $x.isNaN or $x.isnum would be needed. Or maybe NaN evaluates to 'NaN' in string context and +$x eq 'NaN' (or +$x eq NaN) could be used? NaN==NaN being false is in fact very intuitive for me, as NaN is something without any numerical meaning, so numerically compared to anything doesn't make sense (as == means numerical equality, not just equality). Maybe it should be undef instead of false? So OK, tell me if I get it right, and how (and why) it will look in Perl 6. From Exegesis I see that NaN==NaN, but that's not stated in Apocalypse (or I just missed it). BTW, I really like the direction of Perl 6 development, all of you are doing really great job here. I was very surprised when I saw the negative feedback on Slashdot, and I thought that if my enthusiasm is so abnormal, than maybe it's a sign that I should join your team. :) Really, I'd love to help with Perl 6 development if I can be useful somehow. - RaFaL Pocztarski, [EMAIL PROTECTED]
Re: NaN semantics
Damian Conway said: > > > print "Inflation rate: " and $inflation = +<> > > > until $inflation != NaN; > > > > This requires that C be false, causing the loop to continue > > until a valid numeric string is entered. > Err. Are you *sure*? That's an C, not a C, you realize? Yes. I had to use all my fingers and toes to keep everything straight, but I think I did. :-) In the semantics you show (different from IEEE semantics) "NaN==NaN" is true, so "NaN!=NaN" is false, which is why the loop continues until a valid number is entered. > >The example can be rewritten > > > > print "Inflation rate: " and $inflation = +<> > > while $inflation != $inflation; > Err. No it can't. I meant, if we used IEEE semantics rather than those you showed, the example could be correctly written as ... And did I mention it's ugly this way? Brent Dax said: > His point was that the NaN IEEE came up with is defined to have NaN != > NaN, and that it might be confusing if Perl's behavior wasn't consistent > with that. Not that I think NaN != NaN is a particularly good idea, but > consistency with other languages may be. If NaN != NaN, then his > example is correct. Thank you Brent. Brevity and clarity; what concepts! I must try them sometime. -- Tim Conrow
RE: NaN semantics
Damian Conway: #> The example can be rewritten #> #>print "Inflation rate: " and $inflation = +<> #> while $inflation != $inflation; # # Err. No it can't. His point was that the NaN IEEE came up with is defined to have NaN != NaN, and that it might be confusing if Perl's behavior wasn't consistent with that. Not that I think NaN != NaN is a particularly good idea, but consistency with other languages may be. If NaN != NaN, then his example is correct. P.S. Congratulations to you and Larry for waking up perl6-language. I had seen almost no traffic on it in weeks, and was starting to get a bit worried that thoughts on the languages were coughing, sputtering and dying. :^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Re: NaN semantics
> Semantic confusion alert! Aroogha! Aroogha! All crew to clarification stations! > EX3 (great document!) Thank-you. > sez: > > > print "Inflation rate: " and $inflation = +<> > > until $inflation != NaN; > > This requires that C be false, causing the loop to continue > until a valid numeric string is entered. Err. Are you *sure*? That's an C, not a C, you realize? > The example can be rewritten > >print "Inflation rate: " and $inflation = +<> > while $inflation != $inflation; Err. No it can't. > That is ugly, non-intuitive and ugly; and non-intuitive too. But > inconsistency with a long accepted standard is also ungood. Perhaps we > need to write it thus: > >print "Inflation rate: " and $inflation = +<> > while $inflation.isnan; > > or some such? Or: print "Inflation rate: " and $inflation = +<> while $inflation == NaN; which is: print "Inflation rate: " and $inflation = +<> while !($inflation != NaN); which is: print "Inflation rate: " and $inflation = +<> until ($inflation != NaN); which is exactly what I wrote. ;-) Damian
NaN semantics
Semantic confusion alert!
EX3 (great document!) sez:
> print "Inflation rate: " and $inflation = +<>
> until $inflation != NaN;
This requires that C be false, causing the loop to continue
until a valid numeric string is entered. For IEEE-type NaN semantics,
that isn't so: C is true! Try:
/* x86 Linux + gcc */
#include
main()
{
double nan = sqrt(-1);
if(! (nan == nan)) printf("%f == %f is false\n",nan,nan);
if( nan != nan) printf("%f != %f is true\n",nan,nan);
}
Perl6 can, of course, define any semantics for NaN that it chooses, but
there will be some confusion and dissonance if the choice above is made;
i.e. to make C false.
The example can be rewritten
print "Inflation rate: " and $inflation = +<>
while $inflation != $inflation;
That is ugly, non-intuitive and ugly; and non-intuitive too. But
inconsistency with a long accepted standard is also ungood. Perhaps we
need to write it thus:
print "Inflation rate: " and $inflation = +<>
while $inflation.isnan;
or some such?
-- Tim Conrow
