Stream: contributing

Topic: `Num.pi == 3` in REPL

Declan Joseph Maguire (Dec 12 2023 at 10:26):

So I just found an amusing bug. I was thinking of writing a proposal to change the trig functions to accept tagged values like Degs 180 or Rads Num.pi/2, as this can easily lead to mistakes (with more explicitly named functions if you don't want to tag things), and I discovered that Num.pi == 3 in the REPL.

Now I know engineers like to approximate, but I think that's bit silly.

Declan Joseph Maguire (Dec 12 2023 at 10:43):

Adding an issue on github, just amusing enough I thought it was worth mentioning here

Folkert de Vries (Dec 12 2023 at 10:44):

lol. Not sure what's happening there, the definition is ... more accurate

## Archimedes' constant (π)
pi : Frac *
pi = 3.14159265358979323846264338327950288419716939937510

Declan Joseph Maguire (Dec 12 2023 at 10:44):

I checked, and putting Num.pi == 3 into repl returns Bool.true

Folkert de Vries (Dec 12 2023 at 10:44):

Num.tau actually runs into a repl error that I'll fix

Folkert de Vries (Dec 12 2023 at 10:44):

yes, if you just put in Num.pi is shows 3 too

Folkert de Vries (Dec 12 2023 at 10:45):

so it must get truncated somewhere

Declan Joseph Maguire (Dec 12 2023 at 10:45):

I was checked because I wanted to be sure it wasn't a display thing

Folkert de Vries (Dec 12 2023 at 10:45):

maybe because of the large number of decimal digits

Declan Joseph Maguire (Dec 12 2023 at 10:47):

Bug submitted. Do you think that making trig accept tagged values is a good idea? Whether the input is degrees of radians (or other units) is effectively a strange sort of type in my mind, because a trig function ultimately acts on an angle, not a number

Folkert de Vries (Dec 12 2023 at 10:52):

not sure. elm had a cool thing here where it did something like cos (radians x) or cos (degrees x) where radians is just the identity function and degrees actually converts to radians

Folkert de Vries (Dec 12 2023 at 10:57):

so, it turns out that there is no Dec.mulWrap, but what should that function even do? We use mulWrap to indicate "this will not overflow, go as fast as possible) but I think the actual behavior is just unspecified here (similar for floats)

Declan Joseph Maguire (Dec 12 2023 at 11:04):

I asssume mulWrap is just the standard wrapping multiplication for ints. Perhaps replace it with a saturate version? For floats that would naturally allow things to hit infinity

Declan Joseph Maguire (Dec 12 2023 at 11:05):

It's also odd to have numerical constants as Dec type, they should really be Frac. It's an irrational number, it's not going to have nice digits in ANY base

Folkert de Vries (Dec 12 2023 at 11:07):

dec stands for decimal (point). it has nothing to do with base 10 in particular

Folkert de Vries (Dec 12 2023 at 11:08):

hah, it is actually the large number of digits that makes it truncate

Declan Joseph Maguire (Dec 12 2023 at 11:08):

My understanding was it was a datatype specifically existing for decimal representation, i.e. base 10, so that stuff like recording a bank balance as $10.2 wouldn't be subject to float approximations

Declan Joseph Maguire (Dec 12 2023 at 11:09):

Because we already have Frac for that purpose, if we just wanted to represent non-integer values

Declan Joseph Maguire (Dec 12 2023 at 11:11):

Unless the documentation is VERY out of date and Dec now includes floats

Folkert de Vries (Dec 12 2023 at 11:11):

Dec is a fixed-point type, that uses base10 in practice but that is not really what it's about

Folkert de Vries (Dec 12 2023 at 11:12):

frac covers numbers with a point (that is, fractions), so covers both Dec, F64 and F32

Declan Joseph Maguire (Dec 12 2023 at 11:15):

I think I'd misunderstood what you'd said earlier, yes, that matches my understanding. I'm pretty sure that choosing a base for a fixed-point type still imposes limits on which values are exactly representable or not, so Dec is still tied to its base intimately

Declan Joseph Maguire (Dec 12 2023 at 11:16):

Does using a very very precise Dec for something like pi, instead of an F64 have a reason? Because it feels like it should naturally be a float.

Folkert de Vries (Dec 12 2023 at 11:22):

pi is defined as a frac in the standard library. in the repl we pick Dec as the default concrete type. For most purposes that is probably fine, but for performance using F64 definitely makes more sense

Folkert de Vries (Dec 12 2023 at 11:22):

note btw that Dec = Frac Decimal, and F64 = Frac Float64, they use some type trickery

Declan Joseph Maguire (Dec 12 2023 at 11:23):

I know enough about Roc number type magic to know that I do not know how Roc number type magic works

Declan Joseph Maguire (Dec 12 2023 at 11:28):

I wonder if there's some way to force pi to default to float in repl, because having it be a dec just feels wrong. It's not terribly important, but it's got a kind of smell, you know?

Folkert de Vries (Dec 12 2023 at 13:14):

no? dec is the better type for a repl. you don't do serious work there, and float imprecision is just annoying

Richard Feldman (Dec 12 2023 at 13:44):

we could actually generate different versions of pi depending on the type it specializes to

Richard Feldman (Dec 12 2023 at 13:45):

like give it the maximum number of digits possible for Dec, F64, and F32 depending on which of those it ends up monomorphizing to

Richard Feldman (Dec 12 2023 at 13:45):

same with tau

Declan Joseph Maguire (Dec 12 2023 at 13:49):

I had thought of that but I assumed it'd be too much of a pain to implement. I like that.

But yes the too-many-digits truncation glitch is hillarious and goofy.

Brendan Hansknecht (Dec 12 2023 at 15:51):

I think we should just fix the truncation glitch

Brendan Hansknecht (Dec 12 2023 at 15:51):

Cause someone is gonna write a too long constant for a Dec one day

Brendan Hansknecht (Dec 12 2023 at 15:51):

That should either error or just work

Brendan Hansknecht (Dec 12 2023 at 15:51):

I prefer just work and warm on lost precision

Brendan Hansknecht (Dec 12 2023 at 15:53):

When is pi actually parsed to a Dec? Does it use our zig parsing logic or is parsed in the rust in the compiler?

Declan Joseph Maguire (Dec 12 2023 at 23:01):

Brendan Hansknecht said:

I think we should just fix the truncation glitch

Oviously, yeah, lets get that fixed before anything else.

Brendan Hansknecht (Dec 12 2023 at 23:08):

Key word is "just". I don't think we should do any of the other stuff mentioned here.

Last updated: Jul 26 2025 at 12:14 UTC