Strange rounding problem
Jp Calderone
exarkun at intarweb.us
Sat Mar 15 13:56:08 EST 2003
On Sat, Mar 15, 2003 at 01:14:02PM -0500, Peter Hansen wrote:
> Grant Edwards wrote:
> >
> > In article <TrCcnZMtctRJ_u6jXTWc3Q at comcast.com>, Marc wrote:
> > > So I still don't understand that if I enter a number to be an exact value of
> > > .00000096, why it can't be stored as 9.60000000e-007?
> >
> > Becausing you entered it in base 10, and it's stored in base 2. Just
> > because it's an exact value in base 10 it doesn't mean it can be represented
> > exactly in base 2.
>
> And it might help to envision a base 3 representation, in which
> the value 1/3 *could* be represented exactly, but values like 1/2
> could not! In fact, here's a case where a different base than 10
> can handle values that base 10 cannot handle...
I believe the rule is generally expressable - a base can exactly represent
fractions which can be expressed as sums of the inverses of powers of
factors of the base. This makes bases with many relatively prime factors
able to express more fractions exactly. 2 and 3 are poor, because they have
only powers of 1/2 and 1/3 respectively. 4 is just as bad, since it has no
factors that are relatively prime to any factors of 2 (All bases that are
powers of two are equally inexpressive. Bye bye, hexidecimal).
15 is the next best base after 10, and 30 after that. Of course, no base
can exactly represent any fraction, and this doesn't even take into
consideration bases which are, themselves, fractional ;)
Jp
(PS - I worked this all out years ago, and only really remember the part
about the relatively prime factors - if the general expression of the rule
is wrong, I hope it is only because I incorrectly deduced it from the parts
I do remember. Corrections welcome :)
--
1.79 x 10^24 furlongs per picofortnight - It's not just a good idea,
It's the law!
--
up 12 days, 9:59, 9 users, load average: 1.08, 1.02, 0.79
More information about the Python-list
mailing list