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

good, 4 bad.

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