Do you have a place I can read about how the implementation of that one was intended?
No sorry, it was discussed/requested when the library was reviewed that's all. There are some alternative implementations on the net, but I can't find them right now :-( John.
I think the differences between the 2 should be in the implementation details and not in the interfaces.
The idea behind keeping the Qnum was to maximise the usable numbers in the mantissa. In an scenario where the Q (num and denim) stabilises, the useful representable values of the mantissa is as large as possible. While in the other approach, suppose that the Q should stabilise at 1500/1501 then, Qdenom is 1501, but 1500 is present multiplier of every mantissa. This way you waste 1499 every 1500 numbers in the mantissa representation and probably need to increase the size of the mantissa (or not, depends on the use case). In the other side, finding Qnum is not necessarily easy, it increases the quantity of computation needed to find the common factor between 2 operands and may increase the quantity of disagreements (1/3 and 2/3 are now not in agreement).
Regards, Damian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost