At 01:46 PM 6/13/2003 +1200, you wrote:
>Ah, be careful here.  MOST people are not computer programmers,
>and are more likely to understand fractions than floating point numbers.
>Let's face it, if most people were comfortable with floating-point
>numbers, we wouldn't have any of this ISO prefix nonsense;
>instead of papers talking about consumers wasting so many milliwatts
>(mW) when they mean megawatts (MW) they'd talk about 2.5e6 W, and
>there certainly would have been no point in inventing "yotto" and
>"zeppo" or whatever the new prefixes are.

Yes, displaying numbers really should be decoupled from their internal representation. But I'm still not sure that 3 1/2 is more natural for people than 3.5. Money is almost always represented in decimal, and when it isn't it makes me suspicious: Coke is "on sale" at $7 for 2 cases of 12 cans, but Pepsi is "regular priced" at $3.39 or $3.49 for 1 case. Stuff like that fairly jumps out at me, but it must not for most other people or they'd stop doing it.

>I think it would be a serious mistake to make the results of basic
>arithmetic operations depend in any way on a context.  (PL/I programmers
>have horror stories to tell about this, and I've had some nasty experiences
>in APL, thanks to []CT.  I've also seen some really horrible things in an
>IBM mainframe dialect of Prolog where two numbers might or might not
>unify depending on whereabouts you asked.)

Well, I agree that it would be nice if context didn't matter, but there is no getting around the fact that it frequently does. If my program is doing anything that has to do with money then I want decimal numbers--real decimals that handle 0.1 properly. If I am doing signal processing, then I am willing to trade off a loss in precision for speed. But, just in general, if I ask for 1 divided by 3 I want the /right/ answer, not an approximation.

I'll admit that dynamic scoping of computational setting does /sound/ scary, but I think it could be pulled off. You would, of course, have the option of /not/ letting certain computations be dynamically influenced, or limiting the extent of the influence. For example, there are algorithms that are only valid for integer numbers.

>In my defence, I'd like to point out that if you can't tell whether
>x+y is going to round up, round down, truncate, or round to nearest,
>you're in exactly the kind of swamp that IEEE arithmetic was supposed
>to save us from.  While IEEE rounding and precision may be *implemented*
>as a global mode in the FPU, the intent is that they should be *used*
>locally; it's part of several ABIs that a function which alters any of
>the IEEE modes should put them back the way they were before exiting.

Hmmm, as I envision my proposal you would /always/ know whether x+y is going to round up, round down, truncate, or round to nearest. If that were not possible, I wouldn't consider the proposal workable.

david
--
David Farber
dfarber at numenor.com