Re: demonic numbers !
From: Cameron MacKinnon (cmackin+nn_at_clearspot.net)
Date: 02/10/05
- Next message: Rahul Jain: "Re: demonic problem descriptions"
- Previous message: Peter Seibel: "Re: defmacro and intern"
- In reply to: Rahul Jain: "Re: demonic numbers !"
- Next in thread: Rahul Jain: "Re: demonic numbers !"
- Reply: Rahul Jain: "Re: demonic numbers !"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 10 Feb 2005 16:00:14 -0500
Rahul Jain wrote:
> 0.11111 is interpreted [in quantitative science] as any number
> between 0.111105 and 0.111115. Is that we should respecify the lisp
> reader to do? Because I'm sure a chemist who thought like you would
> claim that.
There's a good argument to be made for that. The point is, most people
would want the computer to operate on either your interpretation above
with error bounds carried through the calculation, or exactly the number
the user entered. Few people expect the computer to carry out
approximate calculations with very strange rounding rules and no
corresponding calculation of error intervals. Even those schooled in the
art, who claim that that is exactly what they are expecting,
occasionally get bitten, and badly.
> Are you saying that non-specialists and non-compilers read code on a
> regular basis?
I say that non-specialists WRITE code on a regular basis. You can define
non-specialist as either someone with no formal computer science
education or someone with a CS degree but no numerical analysis
training, it doesn't matter to me. If a person is coding floating point
but is incapable of performing the error analysis, that person is a
non-specialist.
> Computers do math. They are _computing_ machines, particularly when
> it comes to numbers.
Not really. It is possible to mathematically express what the computer
does when it evaluates (+ float1 float2), but it's PAGES of math, and if
you showed it to a mathematician, he'd declare it not aesthetically
pleasing. When it comes to FP, it would be more accurate to say that
math can model what computers do.
> Most importantly, they are mostly used for engineering or financial
> math. Small rounding differences are insignificant compared to speed
> in those applications. If my calculation says to use 153.222m instead
> of 153.221m of wire on a bridge, is that a big deal? If my
> calculation tells me to buy some stock at 15.53 instead of 15.531 is
> that a big deal? The important thing, especially for the financial
> situation, is to get the result _fast_ so that the people doing the
> work can get on with it and make money.
> Most financial data is the result of approximate solving of large
> matrix equations or of partial differential equations. Time is also
> rounded, sometimes to the nanosecond, sometimes to the millisecond,
> sometimes to the second, sometimes to the minute, sometimes to the
> day, sometimes to the year... and probably off from UTC by as much as
> a second or two if it claims to be rounded to the millisecond...
> sometimes worse.
Finance first, since I happen to be wearing an Algorithmics shirt today.
Since antiquity, the vast majority of practitioners of financial math
have preferred exact accuracy over speed, and the few who didn't were
often subjected to punitive measures. Even today, the majority wouldn't
know e the natural logarithm base from E the musical note. Yes, quants
in the money centers, amateur quants at home and risk managers
everywhere are using some pretty fancy math, but it was all invented
after computers were, and computers were the enabler. Those people,
those computers and that math represent a small percentage of computers'
use in finance (though undoubtedly a large percentage of the actual
numerical operations performed, on about fifty computers worldwide). The
majority of financial data is still boring old tuples like
date,quantity,price
date,account,amount
date,open,high,low,close,volume
Duane Rettig has pointed out that he has customers in finance who don't
like float rounding.
Time: In the business world, time rounding is done according to law or
custom. Business users do not think of the values in their date fields
as mere approximations of the exact time. They are, for legal purposes,
the time the transaction was done. Any simple arithmetic on dates which
doesn't take law and custom into account is likely to be wrong. Science
is different, obviously, so the question comes down to what percentage
of time field data is business and what percentage scientific. But the
whole time thing is another red herring (like yesterday's number
theoretic excursion) unless people are entering times as decimal numbers
rather than formatted strings.
For any engineering result you give me with what you believe to be an
acceptable error (say 1mm) I can give a plausible next use of that
number which will multiply the error into the unacceptable range. "Small
rounding differences are insignificant compared to speed?" I don't think
so. In engineering, if you're worried about speed, it must be because
you're doing millions or billions of calculations, which usually means
finite element modeling and rigorous error analysis, meaning calling in
the professionals or using somebody else's numerics package, or both.
Smaller problems finish more or less instantaneously, meaning our number
formats could get quite a bit less efficient before the users noticed.
And error analysis is taken quite a bit more seriously in engineering
than you seem to believe.
- Next message: Rahul Jain: "Re: demonic problem descriptions"
- Previous message: Peter Seibel: "Re: defmacro and intern"
- In reply to: Rahul Jain: "Re: demonic numbers !"
- Next in thread: Rahul Jain: "Re: demonic numbers !"
- Reply: Rahul Jain: "Re: demonic numbers !"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|