On Tue, Dec 12, 2023 at 1:26 PM Larry Garfield <la...@garfieldtech.com> wrote:
> On Tue, Dec 12, 2023, at 1:03 PM, G. P. B. wrote: > > > The issue is that I don't think having arbitrary precision decimals as a > > core language feature is a necessity compared to rational types. > > A cast from rational to float wouldn't produce a large round trip, > whereas > > trying to figure out arbitrary precision is more difficult. > > But in any case, having a declare/INI or whatever that changes the > > behaviour of the engine/language is not a good design choice. > > I don't have strong feelings about arbitrary precision decimals either > way, but I do strongly agree with this point. Having the language behavior > (including the precision of numbers) change with an ini setting is > long-understood to be a bad idea, and we've been trying to phase it out. A > decimal feature that relies on a language-affecting ini setting is just not > going to fly these days, IMO, and rightly so. > > I am curious, GB, if you're proposing an actual `rational` type, which > stores values internally as just numerator and denominator separately until > some point when it renders down to a float (eg, on print)? That sounds > neat, though I am nowhere near expert enough in that area to say what ugly > edge cases that might run into. > > --Larry Garfield > I agree that an INI setting or declare is wrong for this. The ugly edge cases on a native rational type tend to be in complex algorithms, which many libraries deal with by converting the rational to a float or decimal for those complex algorithms and just avoiding the issue. (Algorithms like `sin()`, `atan()`, or `exp()`). It's not an unsolveable problem if you really want rational types. There are libraries that do it. But unless there's someone here volunteering, it's probably a non-starter, as that's something I won't touch. Jordan
