Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

comparisons require BigFloat #40

Closed
stevengj opened this issue Jan 29, 2025 · 3 comments · Fixed by #41
Closed

comparisons require BigFloat #40

stevengj opened this issue Jan 29, 2025 · 3 comments · Fixed by #41

Comments

@stevengj
Copy link
Member

stevengj commented Jan 29, 2025

Comparisons seem to involve BigFloat conversions, which makes them way slower than Base.Irrational

julia> @btime 3.0  pi
  1.287 ns (0 allocations: 0 bytes)
true

julia> @btime 3.0  invsqrt2
  471.291 ns (8 allocations: 352 bytes)
false

This seems to be causing JuliaMath/SpecialFunctions.jl#484

In contrast, it's way faster to compare after conversion of the irrational value to floating point:

julia> @btime 3.0  oftype(3.0, invsqrt2)
  1.287 ns (0 allocations: 0 bytes)
false

I'm guessing this is some type of pedantry where you want to check that the exact rational floating-point value is the exact irrational value? Even so, can't you just compare to the RoundDown conversion?

(Why didn't you just use Base.Irrational, anyway?)

@devmotion
Copy link
Member

(Why didn't you just use Base.Irrational, anyway?)

Base.Irrational is internal, by design definitions of new irrationals of type Base.Irrational (with or without the @irrational macro) are type piracy. The Julia documentation even warns against it.

@devmotion
Copy link
Member

Note that it wouldn't have helped anyway since JuliaLang/julia#55886 moved the effect annotations only to the known Irrational subtypes in base, so also other Irrationals would miss those. I had suggested at some point to add these definitions automatically in the Base @irrational macro, so you would also get them for new Irrationals defined with the macro: JuliaLang/julia#55886 (comment) But there didn't seem any interest in such a change.

@devmotion
Copy link
Member

#41 fixes this issue (and #37 which seem to be the same). However, probably #36 has to be approved and merged first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants