Float compression [Re: floating point math results question]

[François Pinard]

[Jonathan Hogg]

> [...] who needs a space-efficient representation anymore?  Given that
> memory is cheap and non-aligned/bitwise operations are expensive.

Despite CPUs are fast and memory inexpensive, many of us stay interested in
algorithms and representations which are either speedy and memory economical.
Even in these days, we see `.gz' or even `.bz2' files :-).

> What we need is a 'rational' type, in a similar vein to the existing
> 'complex' type:
>     n = rational( 8, 10 )

I may send you the one I have, just ask! :-) In fact, my constructor for
the rational type does a fractional approximation, if given float arguments.
Be aware that rational computations are _not_ memory economical, you might
get numerators and denominators to grow very quickly, in simple things like:

    sum = 0
    for counter in range(maximum):
        sum = sum + rational(1, counter)

> A more interesting problem is an efficient algorithm for refactoring an
> arbitrary rational number into a sequence of the form:

>     ... + 100.k[2] + 10.k[1] + k[0] + k[-1]/10 + k[-2]/100 + ...

> where 0 <= k[i] < 10, which you would want for printing out the
> representation as a normal floating point number. [Of course noting that
> many rationals are non-terminating as floats.]

I would guess that `str()' has been implemented with some care about
efficiency.  Couldn't you just use it?

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard