The code for irrationals.jl in base defines:
zero(::AbstractIrrational) = false
zero(::Type{<:AbstractIrrational}) = false
one(::AbstractIrrational) = true
one(::Type{<:AbstractIrrational}) = true
So, then, for example:
julia> zero(π)
false
julia> one(π)
true
This was unexpected.
What is the reasoning behind this choice?
AbstractIrrational <: Real, so zero and one should return some kind of real number with the numerical value 0 and 1.
The docs of false states:
Moreover, false acts as a
multiplicative "strong zero":
julia> false == 0
true
julia> true == 1
true
julia> 0 * NaN
NaN
julia> false * NaN
0.0
It’s likely that is the motivation for returning Bool values.
I think that this result is not correct. According to the docs, zero(T::Type) and one(T::Type) return the additive and multiplicative identities for T, respectively. But in this case that’s not true:
julia> zero(π) + π == π
false
julia> one(π) * π == π
false
That is expected - julia is not a CAS and trying to preserve the Irrational types in particular quickly leads to trying to make julia one.
The particular choice here is also intentional, see @edit ==((zero(π) + π), π):
# Irrationals, by definition, can't have a finite representation
# equal them exactly
==(x::AbstractIrrational, y::Real) = false
==(x::Real, y::AbstractIrrational) = false
since mathematical operations on irrationals lead to them being “Realized” to the corresponding precision.
To be clear you could add methods like
julia> Base.:+(x::Bool, y::Irrational) = x ? 1 + y : y
julia> false + π === π
true
to make Irrationals behave a little better.
But that’s the problem with Irrational, there’s always something that could be improved a little bit. Maybe you want a specialized method to make sin(π) return 0 instead of 1.2246467991473532e-16? That’s easy to add as well. What about sin(2π), maybe not as easy but doable with some more type tricks. Continuing along this road leads you to a full blown Computer Algebra System, which would be completely unrealistic to build into Julia Base.
Actually:
julia> zero(π) + π ≈ π
true
julia> 0.0 + π == π
false
julia> one(π) * π ≈ π
true
That’s interesting, is that a warning, or is this wanted?
Is that from some (older?) Julia version? Julia 1.8.1 (for me, and should for all, I believe no portability issue) DOES return 0.0 exactly (I think they tried reall hard for that to happen unlike for other multiples of π). But not for bitstring(sin(2π)), nor even sin(-π), does for sin(0) though. There’s a reason for sinpi.
But if
julia> zero(π) + π == π
false
then there’s an argument that either this should be fixed, or methods for one and zero should be removed.
There may be a blurry line somewhere between what should be included and what shouldn’t, but I don’t think that line should lie between the existence of zero(::AbstractIrrational) and the correct behavior of zero(π) + π.
I found this related issue, in case this conversation leads to something actionable:
That’s very much intentional, see the bottom of section Mathematical Operations and Elementary Functions · The Julia Language.
Yes, I was still on 1.7. Apparently it was decided to implement exactly that for 1.8:
julia> @which sin(π)
sin(::Irrational{:π}) in Base.MathConstants at mathconstants.jl:126
I don’t have a strong opinion on the line for irrationals, but I suspect that removing zero and one would break a lot of things in the presence of irrationals.
Yes, but I thought the polynominal might have been changed, but apparently not:
julia> sin(Float64(π))
1.2246467991473532e-16
So just making sure for:
Base.sin(::Irrational{:π}) = 0.0
Base.cos(::Irrational{:π}) = -1.0
Base.sincos(::Irrational{:π}) = (0.0, -1.0)
Base.tan(::Irrational{:π}) = 0.0
Base.cot(::Irrational{:π}) = -1/0
unlike for:
julia> cos(Float64(π)) #even exact with: bitstring(cos(Float16(π)))
-1.0
julia> typeof(-π) # so not possible for it currently (or would there have been some possible workaround to get sin(-π) exact?)
Float64
There’s already:
I think 2π (as a literal constant) could have been changed to a separate “2π” irrational, and made exact, maybe not good under that name, since variables/constants cant start with number, rather twopi, or simply tau. I think they simply (wisely) chose to not do it in Julia, since can be done in a package; it was maybe a mistake to include any irrationals in Julia, this is a can of worms, and Julia itself doesn’t need them.
Unary minus on irrationals could also have been defined on irrationals, to give their mirrors, and then you have at least 4 pi-related irrationals. At some point it will be surprising, e.g. that 3π or simply 2.0π. So you would have to multiply again by 2 (at least), the number of irrational types, to support float (well Float64 only).
Naturally, removing one and zero is not an option. But handling *(::Bool, ::AbstractIrrational), etc., seems like a decent possibility, despite the ‘slippery slope’ argument (I actually think the slippery part lies between those two options). Unless, of course, that too would break stuff.
Thanks for the Knuth reference (just adds one more obscure trivia you need to know for [IEEE] floating point; not sure it applies to Post floating point, and its NaR).
Since false as “strong zero” is meant to disable propagation of NaN, when intended, explicitly used, is it then a bug related to irrationals (false and true, had other reasons for them there, related to Float64 or no other type good enough), to silently disable NaN propagation (which is a good thing, except when you want to turn it off)?
julia> faraway_calculation_results_in = NaN
julia> faraway_calculation_results_in*zero(π) # not sure how often this, or similar, would be done in practice though.
0.0
unlike:
julia> faraway_calculation_results_in*zero(Float64(π))
NaN
[File a (separate) bug? Or is it simply a known issue, part of the other open bug linked from this thread?]
This might have to do with it (didn’t look into it carefully):
Isn’t one(π) * π != π a bona fide bug, then?
help?> one
Return a multiplicative identity for x: a value such that one(x)*x == x*one(x) == x.
It’s not just a question of improving numerical precision, the definitions of one and zero are that they should be identities.
Couldn’t there be an Irrational{true/false} representing this?
Some more methods would be needed to make it work properly, but something like this could be one way to handle zero/one identities?
julia> Base.zero(::AbstractIrrational) = Irrational{false}()
julia> Base.zero(::Type{<:AbstractIrrational}) = Irrational{false}()
julia> Base.one(::AbstractIrrational) = Irrational{true}()
julia> Base.one(::Type{<:AbstractIrrational}) = Irrational{true}()
julia> Base.:+(a::Irrational{false}, b::AbstractIrrational) = b
julia> Base.:+(a::AbstractIrrational, b::Irrational{false}) = b
julia> Base.:*(a::Irrational{true}, b::AbstractIrrational) = b
julia> Base.:*(a::AbstractIrrational, b::Irrational{true}) = b
julia> Base.Float64(::Irrational{false}) = zero(Float64)
julia> Base.Float64(::Irrational{true}) = one(Float64)
julia> zero(π) + π == π
true
julia> one(π) * π == π
true
julia> one(π) + π == π
false
julia> zero(π) * π == π
false
Isn’t
one(π) * π != πa bona fide bug, then?
No, or this is tricky, where is the bug? one(π) == true (meaning “1”) IS the multiplicative identity of π, just regular math).
The “bug” if you will then happens with true * π no longer being an irrational (also for false). That (and for false) seemingly could be fixed, but not for true + π (while false + π could be made to work).
julia> one(π) * π ≉ π # EDIT: !(one(π) * π ≈ π) # I didn't locate an \notapprox operator, is there one?
false
\napprox
Well, I would say that if true isn’t the multiplicative identity of pi, then one(pi) shouldn’t return true. So the bug is in one.
I think these issues come down to two basic issues:
Perhaps Irrational shouldn’t ever have been a type, instead a better design (given the above limitations and expectations of consistency with the rest of Julia) might have been to make each irrational constant a function that takes a <:Real type.
Something like this:
irrational_pi(Float64) # evaluates to 3.1...
or this:
irrational(:pi, Float64) # evaluates to 3.1...