[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: small integers, numerical efficiency
- To: "David A. Moon" <moon@cambridge.apple.com>
- Subject: Re: small integers, numerical efficiency
- From: kanderso@BBN.COM
- Date: Fri, 30 Oct 92 09:45:36 -0500
- Cc: John Lewis <zilla@ccrl.nj.nec.com>, info-dylan@cambridge.apple.com
- In-reply-to: Your message of Thu, 29 Oct 92 15:56:46 -0500. <9210292055.AA10318@cambridge.apple.com>
Date: Thu, 29 Oct 92 15:56:46 EST
From: "David A. Moon" <moon@cambridge.apple.com>
To: John Lewis <zilla@ccrl.nj.nec.com>
Subject: Re: small integers, numerical efficiency
Cc: info-dylan@cambridge.apple.com
...
What I said was that I think a Dylan implementation would be better off
leaving out floating point entirely than putting in floating point but not
doing it efficiently.
Then from a language point of view, we could decide that few implementations
will want to bother doing floating point efficiently, and therefore remove it
from the language, or we could make it optional in the language, or we could
leave the language the way it is and some implementations could announce that
they only support a subset. Personally I prefer making it optional over
either extreme. Floating point is not the only thing in the Dylan book that
ought to be optional.
Does "optional" mean one would not be able to use floats in a portable way?
Also, C's integer numeric system is half-baked, but its floating-point numeric
system is not particularly bad. I say enough bad things about C that you
don't need to misquote me disparaging a part of C that doesn't bother me!
Perhaps we should order the numerical classes on page 147 by frequency of use.
Then we could use this to focus our attention on performance, or which
classes to prune from the language.