Re: Proposal: Arbitrary precision native scalar type

On Tue, Dec 12, 2023 at 1:26 PM Larry Garfield <larry@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