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.
Adding an issue on github, just amusing enough I thought it was worth mentioning here
lol. Not sure what's happening there, the definition is ... more accurate
## Archimedes' constant (π)
pi : Frac *
pi = 3.14159265358979323846264338327950288419716939937510
I checked, and putting Num.pi == 3 into repl returns Bool.true
Num.tau
actually runs into a repl error that I'll fix
yes, if you just put in Num.pi
is shows 3 too
so it must get truncated somewhere
I was checked because I wanted to be sure it wasn't a display thing
maybe because of the large number of decimal digits
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
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
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)
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
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
dec stands for decimal (point). it has nothing to do with base 10 in particular
hah, it is actually the large number of digits that makes it truncate
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
Because we already have Frac for that purpose, if we just wanted to represent non-integer values
Unless the documentation is VERY out of date and Dec now includes floats
Dec is a fixed-point type, that uses base10 in practice but that is not really what it's about
frac covers numbers with a point (that is, fractions), so covers both Dec, F64 and F32
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
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.
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
note btw that Dec = Frac Decimal
, and F64 = Frac Float64
, they use some type trickery
I know enough about Roc number type magic to know that I do not know how Roc number type magic works
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?
no? dec is the better type for a repl. you don't do serious work there, and float imprecision is just annoying
we could actually generate different versions of pi
depending on the type it specializes to
like give it the maximum number of digits possible for Dec
, F64
, and F32
depending on which of those it ends up monomorphizing to
same with tau
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.
I think we should just fix the truncation glitch
Cause someone is gonna write a too long constant for a Dec one day
That should either error or just work
I prefer just work and warm on lost precision
When is pi actually parsed to a Dec? Does it use our zig parsing logic or is parsed in the rust in the compiler?
Brendan Hansknecht said:
I think we should just fix the truncation glitch
Oviously, yeah, lets get that fixed before anything else.
Key word is "just". I don't think we should do any of the other stuff mentioned here.
Last updated: Jul 06 2025 at 12:14 UTC