bugs in d2c ratio.dylan
Author Message
bugs in d2c ratio.dylan

Quote:

> > > Unfortunately, since Gwydion doesn't have fractions I needed another
> > > 47
> > > lines of support code.  Well I guess I'll put a cleaned up and more
> > > complete version into the Gwydion libraries sometime soon, in which
> > > case
> > > Gwydion *will* support fractions... :-)

> > It has them already.  See src/d2c/runtime/dylan/ratio.dylan for the
> > implementation.

> Oops!  So it does!

> Turns out that:

> - it uses bignums, not machine integers.  We'll see how fast those are...

> - you have to import it from the Extensions module, it's not in the
> normal Common-Dylan.

> - you need to explicitly create a ratio, then contagion takes hold after
> that.  Normal division will never give you one.

> - equal-hash(<ratio>) isn't defined so I can't use them in a hash table.

> A few minutes work ahead to use this...

Well, it's going to be far more than a "few minutes".  Turns out
ratio.dylan is buggy.

On the nineNines problem it fails because it tries to do something with
a fraction equal to 0/0.  This is generated first by (0/1) / (171/1),
which should produce 0/1 but produces 0/0.

It turns out that ratio(0/171) produces 0/0 !!!!

And, worse, so do:

0/129
0/131
0/133
0/135
0/137

But it's not just odd denominators.  It is odd denominators and only odd
denominators until 0/255, but then you get:

0/258
0/259
0/262
0/263
0/266
0/267

etc.  2 good, 2 bad.  Until 0/510, 0/511.  Then it's 512,513,514 OK,
515,516,517,519 bad, 3 good, 5 bad etc.  Then at 768 it changes to 4

I'm baffled at the moment.  Obviously related to patterns in the lower
bits, but how?

aaaarrrrggghhhh!

I think the problem has to be in either truncate/(<extended-integer>,
<extended-integer>) or gcd(<extended-integer>, <extended-integer>).

It's OK .. it's under control.  Just venting :-)  Did no one ever test
this stuff?

-- Bruce

Sun, 06 Jun 2004 14:12:43 GMT

 Page 1 of 1 [ 1 post ]

Relevant Pages