Front page | perl.perl6.language |
Postings from October 2001
Re: NaN semantics
From: Glenn Linderman
October 10, 2001 09:46
Re: NaN semantics
Message ID: 3BC47B69.B044356F@netzero.net
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 <firstname.lastname@example.org> 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
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 == 1000000
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
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.