The heading is misleading I think. Fractions have been in other programming languages for decades. There is nothing new about fractions. It is a basic feature of number systems in programming languages. It often helps with being precise in calculations. I've been using them for a long time in Scheme dialects.
The heading should be: "Finally a Golang library that retrofits Golang with a fractions datatype." -- relating only to Golang, instead of creating the wrong impression, that this is anything new in programming.
1.67 != 1 2/3
Equating these two is just an approximation ... and based on the example, one that was carried out without any obvious accuracy requirement.
So why not 1 65/97 which is more accurate or 1 67/100 which is perfectly accurate?
Messing around with fractions is still only an approximation at best so it's hard to see how this really buys you much of anything except lost efficiency. Why not just use floats and format as a fraction for display/output if this is what "floats" your boat?
From the source code:
The typical implementation in other languages calls this a rational, and does That makes the code easier. Is there a reason for keeping the integer part around?Also, for FloatToFrac, you may want to look into continued fractions. They make it extremely easy to find better and better rational approximations to any number (https://en.wikipedia.org/wiki/Continued_fraction#Best_ration...)
This example also reminds me of why golang won’t soon become my favorite language. It’s just not expressive enough for this kind of stuff. If you’re using rationals, you really want to be able to write
and get 149/208 as output.