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 == 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 -- Glenn ===== Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
