by **oliver** » Mon Oct 21, 2013 9:45 pm

->Q is pretty cheaply implemented and it's easy to have it produce sub-optimal results. I wouldn't call this an error per se. In the example you give the sub-optimal result is still accurate to 9 digits. (In comparison to a 50g, this implementation will sometimes be worse, sometimes be better, depending on the concrete input.)

If you need a higher quality result, there's a way: try ->CF, eval

->CF converts into a continuous fraction, which is way more expensive and gives a way better result. Non-truncated CFs convert to a fraction when you evaluate them. (Truncated CFs, indicated with a "..." extension, convert to a BigFloat, where the precision you set via setBigFPrecision determines how many digits the result will have.)

Tried on your decimal ->CF eval will actually return the expected fraction.

Hope that helps.