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

Fix roundoff bugs in prevpow/nextpow #45067

Merged
merged 4 commits into from
May 5, 2022

Conversation

mikmoore
Copy link
Contributor

@mikmoore mikmoore commented Apr 23, 2022

This PR fixes a bug where prevpow(2.0,prevfloat(1024.0)) == 1024.0 and a matching bug for nextpow. The previous implementation didn't cover all the possible cases of roundoff in the logarithm, (eg: didn't consider that log(2.0,prevfloat(1024.0))==10.0, which floors to 10 instead of the mathematically correct 9).

It also adds a DomainError in the case that the input is beyond the range of the returned type. Previously, for example, prevpow(Int8(4),200) == 0 was a silent incorrect result. The only exception is a base of 2::Integer for any Integer, which has its own special case. One could technically only throw an error when the result is out-of-range (eg, prevpow(Int8(4),200) could correctly return 64 even though 200>typemax(Int8)), but that was more complicated (and the previous behavior was to return 0).

It also adds an OverflowError to nextpow when the result is not representable. Previously, nextpow(Int8(4),65) == 0.

The added errors could be considered breaking. It's hard to imagine anybody was intentionally using this behavior, but they could be split off if controversial.

@ViralBShah
Copy link
Member

Welcome @milkmoore. Great to have you contribute to Julia!

wp = a^n
wp > p || throw(OverflowError("result is beyond the range of type of the base"))
wp >= x && return wp
wwp = a^(n+1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about wp*a powers are relatively expensive.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered that but it's only valid for integers. For floats there's no guarantee that x*x^n == x^(n+1).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, that's unfortunate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For IEEEFloat types, bases that are powers of 2 can be done very efficiently with some bit-twiddling. I'll get around to it sooner or later but for now I was focused on correctness.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can possibly do stuff both correct and fast with a modification of the pow implimentation which uses Double-double internally. It would be a bit of a pain though.

@StefanKarpinski
Copy link
Sponsor Member

Given @oscardssmith's approval, should we merge this? Any remaining concerns?

@mikmoore
Copy link
Contributor Author

mikmoore commented May 5, 2022

Unless somebody had suggestions, there wasn't anything else I had plans to do.

@oscardssmith oscardssmith merged commit 670f713 into JuliaLang:master May 5, 2022
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 this pull request may close these issues.

None yet

4 participants