[Greg Ewing]
> Maybe Python should use decimal FP as the *default* representation
> for fractional numbers, with binary FP available as an option for
> those who really want it.
NumPy users would scream bloody murder.
> Unadorned FP literals would give you decimal FP, as would float().
> There would be another syntax for binary FP literals (e.g. a 'b'
> suffix) and a bfloat() function.
Ditto.
> My first thought was that binary FP literals should have to be
> written in hex or octal. ("You want binary FP? Then you can jolly
> well learn to THINK in it!") But that might be a little extreme.
"A little"? Yes <wink>. Note that C99 introduces hex fp notation, though,
as it's the only way to be sure you're getting the bits you need (when it
really matters, as it can, e.g., in accurate implementations of math
libraries).
> By the way, what if CPU designers started providing decimal FP
> in hardware? Could scientists and ordinary mortals then share the
> same FP system and be happe?
Sure! Countless happy users of scientific calculators are evidence of
that -- virtually all calculators use decimal fp, for the obvious human
factors reasons ("obvious", I guess, to everyone except most post-1960's
language designers <wink>).
> The only disadvantage I can think of for the scientists is that a
> bit more memory would be required, but memory is cheap nowadays. Are
> there any other drawbacks that I haven't thought of?
See the Kahan paper I referenced yesterday (also the FAQ mentioned below).
He discusses it briefly. Base 10 HW fp has small additional speed costs, and
makes error analysis a bit harder (at the boundaries where an exponent goes
up, the gaps between representable fp numbers are larger the larger the
base -- in a sense, e.g., whenever a decimal fp number ends with 5, it's
"wasting" a couple bits of potential precision; in that sense, binary fp is
provably optimal).
Mike Cowlishaw (REXX's father) is currently working hard in this area:
http://www2.hursley.ibm.com/decimal/
That's an excellent resource for people curious about decimal fp.
REXX has many users in financial and commerical fields, where binary fp is a
nightmare to live with (BTW, REXX does use decimal fp). An IBM study
referenced in the FAQ found that less than 2% of the numeric fields in
commercial databases contained data of a binary float type; more than half
used the database's form of decimal fp; the rest were of integer types. It's
reasonable to speculate that much of the binary fp data was being used simply
because it was outside the dynamic range of the database's decimal fp type --
in which case even the tiny "< 2%" is an overstatement.
Maybe 5 years ago I asked Cowlishaw whether Python could "borrow" REXX's
software decimal fp routines. He said sure. Ironically, I had more time to
pursue it then than I have now ...
less-than-zero-in-an-unsigned-type-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4