------art_125442_1034427.1147903319766
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Without knowing your hardware and software, I can only guess, but when you
subtract two numbers that are as far apart as 1.0 and Epsilon, the operation
has a tendency to throw away most or all of the significant digits.

On 5/17/06, Joel VanderWerf <vjoel / path.berkeley.edu> wrote:
>
> Joel VanderWerf wrote:
> > polypus wrote:
> >> how do i get the greatest float smaller than 1.0?
> >>
> >> thanks
> >>
> >
> > Something like this maybe?
> >
> > irb(main):006:0> [0.9999999999999999].pack "G"
> > => "?\357\377\377\377\377\377\377"
> >
> > (that was just to find out what floats look like in memory, big-endian).
> >
> > irb(main):012:0> x = ("?\357" + "\377"*100).unpack "G"
> > => [1.0]
> > irb(main):013:0> "%30f" % x
> > => "0.999999999999999888977697537484"
> >
> > Dunno if that's safe on all platforms...
>
> That was completely wrong, please ignore.
>
> irb(main):059:0> y = 1e-305
> => 1.0e-305
> irb(main):060:0> [y].pack "G"
> => "\000\234\026\305\305%5t"
> irb(main):061:0> [y].pack("G").unpack("G")
> => [1.0e-305]
>
> It's the exponent that needs to be chosen, not just the mantissa.
>
> Still, it leaves the question open why Float::EPSILON is nowhere near
> this exponent.
>
> --
>       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
>
>

------art_125442_1034427.1147903319766--