Re: demonic numbers !
From: Rahul Jain (rjain_at_nyct.net)
Date: 02/10/05
- Next message: Jens Axel Søgaard: "Re: Continuations in Common Lisp (with apologies)"
- Previous message: Michael Kappert: "Re: demonic numbers !"
- In reply to: Cameron MacKinnon: "Re: demonic numbers !"
- Next in thread: William Bland: "Re: demonic numbers !"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 10 Feb 2005 16:35:39 -0500
Cameron MacKinnon <cmackin+nn@clearspot.net> writes:
> 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.
Which few? The ones writing software or the ones not?
> Even those schooled in the art, who claim that that is exactly what
> they are expecting, occasionally get bitten, and badly.
Sure, but at least it makes their project feasible. At least they got
1500 rockets off even if it means that 1 went off on a bad trajectory.
Otherwise, they'd have never gotten even 1 off.
>> 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.
Then they're either not doing enough math for rounding errors to
accumulate or they're not using a wide enough range of magnitudes. FP
will be fine for them as long as they print out the number with the
precision they expect it to have.
> 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.
They don't need more than 53 bits of precision to store those values.
Any computations done with them won't span many orders of magnitude,
either. The entire trading on NASDAQ isn't even enough to cause more
than a few pennies of error if you add up each share's trading price
separately to compute total dollar volume in a day. In the bond market,
the numbers are bigger, but the values are in the 1000s, so you have the
same relative magnitudes. And then they round those numbers to the
nearest $1000 in the end anyway.
> 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.
Yes, exactly. That was my point. It doesn't make sense to use FP for
times because you're not adding numbers here. You're moving around in a
multi-dimensional space with intricate topology. Was 5/15/1986 a valid
settlement date for an equities trade? In Japan or the US?
> 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.
And go figure, it's those professionals (either hired for the task or to
write the library) are the ones writing the most numerically- and
performance-sensitive code.
> Smaller problems finish more or less instantaneously, meaning our number
> formats could get quite a bit less efficient before the users noticed.
And smaller problems use fewer numbers, meaning FP roundoffs and
magnitude differences don't have time to accumulate.
> And error analysis is taken quite a bit more seriously in engineering
> than you seem to believe.
You mean they care if they're off by 100 baryons when they compute the
number of baryons in the universe? (Sorry to be so pedantically precise,
but "particle" just doesn't cut it here.)
FP is more precise than their measurements, I guarantee it.
The only issue I've seen other than foolishly using programmer-oriented
output routines for user interfaces is non-portability in results that
is actually insignificant (10ths of a penny, even on the largest trades
in history... and at that point they don't exactly care about pennies,
let alone dollars... they'd gladly buy the trader a $30 lunch to get the
deal through).
-- Rahul Jain rjain@nyct.net Professional Software Developer, Amateur Quantum Mechanicist
- Next message: Jens Axel Søgaard: "Re: Continuations in Common Lisp (with apologies)"
- Previous message: Michael Kappert: "Re: demonic numbers !"
- In reply to: Cameron MacKinnon: "Re: demonic numbers !"
- Next in thread: William Bland: "Re: demonic numbers !"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
