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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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, 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 amp; XML http://www.xmltwig.com
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
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.
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: 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]
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: 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
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
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
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
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
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
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
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
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
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 Cfail. I'll mention this to Larry (who's probably watching silently over us anyway). Damian
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 CNaN and Cnan 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
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] URL: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
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 CNaN != NaN be false, causing the loop to continue until a valid numeric string is entered. Err. Are you *sure*? That's an Cuntil, not a Cwhile, 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
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
Tim wrote: Err. Are you *sure*? That's an Cuntil, not a Cwhile, 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
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
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. CNaN 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 Cfail value in Perl. ;-) Damian
