Re: Proposal: Arbitrary precision native scalar type

Oh, I just realized that I used the wrong word, so let me rephrase that: What's the name of the library you're talking about? Maybe the *pros* of a core implementation can be highlighted if we can see the limitations of a user-land approach. Best, Erick Em ter., 12 de dez. de 2023 às 18:52, Erick de Azevedo Lima < ericklima.comp@gmail.com> escreveu: > Hi Jordan. > > What's the name of the library you're talking about? Maybe the cons of a > core implementation can be highlighted if we can see the limitations of a > user-land approach. > > Best, > Erick > > Em ter., 12 de dez. de 2023 às 18:35, Jordan LeDoux < > jordan.ledoux@gmail.com> escreveu: > >> 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 >> >