BigDecimal vs Rational

[littledan]

In #2, the README describes advantages of BigDecimal over Rational. Let's continue the discussion in this thread. Are there further factors we should consider?

[littledan]

For stability, some thoughts on Rational from the draft README, explaining my current point of view.

---

Many languages in the Lisp tradition include fractions of arbitrary-size integers as a basic data type, alongside IEEE-754 64-bit binary floating point numbers. We're not proposing fractions as a built-in type for JavaScript for a couple reasons:

• Representation of trailing zeroes: These are important to be considered logically a part of the decimal number, as described in the decimal FAQ. If rationals didn't normalize, they would quickly get way too big, so it's unclear to see how they could be extended to support trailing zeroes.
• Efficiency: Simple operations like addition of fractions requires use of a greatest-common-denominator (GCD) algorithm to normalize the fraction. At the same time, even with that, the denominator can get pretty big with just a few operations if care isn't taken.
• Still limited expressiveness: Rationals still cannot express most polynomial or trigonometric values, so the exactness benefits still fall away in most cases. It's not clear how often practical programs actually need preciseness in fractions but not those other issues.

[MaxGraey]

Most popular decimal libraries on npm written by one person:
https://www.npmjs.com/package/bignumber.js
https://www.npmjs.com/package/big.js
https://www.npmjs.com/package/decimal.js

And fraction / rational:
https://www.npmjs.com/package/fraction.js
https://www.npmjs.com/package/big-rat
https://www.npmjs.com/package/num2fraction
https://www.npmjs.com/package/big-rational
https://www.npmjs.com/package/fractional
https://www.npmjs.com/package/fracty

[LeszekSwirski]

I would consider striking "still limited expressiveness" from the reasoning, since it is a concern for literally any finite sized representation of real numbers and thus could be used to shut down any alternative (including, symmetrically, this one). Fractions may be limited relative to, say, arbitrary polynomial solutions, but they are still a strict superset of decimals (trailing zeros aside).

"Efficiency" is also an interesting concern when viewed as being relative to the efficiency of being implemented as a library. It seems to me that BigDecimal is effectively BigInt + dot position (where dot position is preserved on addition and added on multiplication), and it's trivial to e.g. store dollars as 100s of cents, while BigRational would require a user-space GCD implementation which is not able to introspect the BigInt numerator/denominator values.

"Trailing zeros" is a valid concern if this is an important aspect of the semantics, but conversely it raises a lot of semantics questions (already around arithmetic, comparisons, and toString) where there is no clear answer, and likely no one-size-fits-all semantics (I already see conflicting semantics in the motivation, see #26 (comment)).

[LeszekSwirski]

I should add that anecdatally, I've found need for arbitrary precision fractions in the past (most recently for exact probability calculations) but I've not yet found need for arbitrary precision decimals that wasn't satisfied by something similar to counting cents instead of dollars.

That said, I'm acutely aware that there are more programmers out there than me and there are use-cases that I haven't predicted or appreciated, so consider this a single vote rather than an attempt at an authoritative statement.

[boenrobot]

What about rationals as not two, but three big integers under the hood? Numerator, denominator, and precision, to store significant trailing zeroes.

The precision will always be the bigger number between BigDecimal values participating in a computation, and can be reduced by rounding. In literals, it would be determined by the number of fractional digits, including trailing zeroes. The precision value will be used to determine formatting with toString(), or to cut irrational divisions at that point (with no rounding), e.g.

(1m / 3m).toString() === '0'
(1.00m / 3m).toString() === '0.33'
(1m / 3.00m).toString() === '0.33'
(1.00m / 3.00m).toString() === '0.33'
(1.00m / 3.0000m).toString() === '0.3333'

IMHO, this is intuitive from a user's point of view, and addresses the trailing zeroes problem (not sure about the "limited expressiveness"), as well as the division operator. I agree with @LeszekSwirski that "efficiency" should not be a deterrent if implementing this in userland would be measurably slower.

[scottfr]

We would prefer rationals for our case. We build an application that can execute user defined mathematical equations (think of it a little like Excel). Users expect these calculations to be carried out precisely.

• BigDecimal is probably not usable for our use case as we don't know the correct precision the user wants for division operations.
• Decimal128 is an improvement over JavaScript's built-in number and if it is adopted by browsers we will switch to it. However it still may hit imprecisions issues.

The issues flagged above for rationals aren't a problem for us. Trailing zeros are a non-issue, and the number chained operations in our use case is small enough that the performance impacts of rationals are not problematic for us.

Any sort of online-calculator that executes user defined mathematical operations probably has a similar use for rationals.

[stiff]

Any decimal can be represented as rational with power of 10 denominator. So having rationals that support preserving denominator after math operations would give decimals for free.

[padenot]

Web Codecs would have liked or will have a use for a Rational type, fwiw.

w3c/webcodecs#122 (comment) is a good summary of the situation by @chcunningham, but @sandersdan has also been thinking about this a lot. I distinctively remember @jernoble talking about this in standards meetings more than once in the context of media APIs.

It's very common to use rational when dealing with multimedia content, because (e.g.) the frame rate of video in the NTSC standard is defined to be precisely 30 / (1001 / 1000), which is approximately 29.97, but not exactly, and cannot be represented with a floating point number (even with double precision, you end up having issues eventually).

Time in professional video software (and in APIs that are intended to be used to implement those piece of software) is often using a frame count and a time base (example of the rational number type from ffmpeg, Microsoft Windows WMF, Apple's Core Media, to cite what is used o the three major desktop platforms).

Because videos can be very long, precision matters: depending on various factors, this can cause audio/video desynchronization, video frame drop, and otherwise causes some confusions, for example having the audio track shorter than the video track, in the same media file, because of rounding issues, or uncertainty about the temporal position of a certain event in a video, but this is certainly not an exhaustive list.

[Rudxain]

Quoting @boenrobot :

What about rationals as not two, but three big integers under the hood? Numerator, denominator, and precision, to store significant trailing zeroes.

We could do the same with non-rational BigFloats and BigDecimals. By using internal metadata to save memory, the library will follow the "as-if" principle, so the code and the devs will still "see" trailing zeros, which is very convenient when chaining multiple operations and expecting to get the most accurate result for any given precision implicitly, without the need to explicitly specify the desired precision every time a function is called. This also means that computing the integer ctz of any Decimal can be done in O(1) depending on which radix (base) the ctz is being calculated (it also depends on whether the dev is using a BigFloat or a BigDecimal, because of different bases)

[jessealama]

@scottfr Regarding the first point above, it seems like we could address your issue if we were to allow an "unlimited" option for specifying the number of decimal digits?

[littledan]

@jessealama What would that mean?

[Rudxain]

"unlimited" option

That's a bad idea, because (correct me if I'm wrong) BigFloats are expected to "just work" when passed to methods like sqrt.

Math.sqrt(2m) requires infinite memory in "unbounded mode", because it's irrational. Even 1.0m / 3.0m would be an instant OOM...

Unless... trailing zeros in the literal set the precision of the calculation (that's how Unix bc works). Examples:

const lil_third = 1.0m / 3.0m //0.3m

const BIG_third = 1.000000000000000000000000000m / 3.000000000000000000000000000m //0.333333333333333333333333333m

But that is no longer "unbounded", it's "arbitrary-precision", literally

This still begs the question "what to do if the precision of each BigFloat doesn't match?". The "obvious" solution is to choose the max:

const third = 1.0m / 3.00m * 1.000m //0.333m