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

[WIP / RFC] Configuration mechanism for directed rounding and fast powers #388

Closed
wants to merge 30 commits into from

Conversation

dpsanders
Copy link
Member

@dpsanders dpsanders commented Jun 6, 2020

This is a proposal for a better configuration mechanism for changing the directed rounding method (tight or accurate) and for choosing the type of powers (fast or tight).

Usage:

IntervalArithmetic.configure!(directed_rounding=:fast, powers=:tight)

This would fix several outstanding issues (that I won't list right now).

This is the minimal thing that makes sense to me. The syntax is nasty enough that it feels like something a casual user should not do (unlike the previous setrounding(Interval, :tight)); in particular I am proposing not to export configure!), but light enough that it is not unusable. In any case this is designed to be used a very minimal number of times in any given piece of code.

Tests and docs need updating but I would appreciate feedback.

cc-ing interested parties: @lbenet, @Kolaru, @gwater, @JeffBezanson, @mforets

fixes #103

@dpsanders dpsanders changed the title Rework configuration mechanism [WIP / RFC] Rework configuration mechanism Jun 6, 2020
@dpsanders dpsanders changed the title [WIP / RFC] Rework configuration mechanism [WIP / RFC] Configuration mechanism for directed rounding and fast powers Jun 6, 2020
@dpsanders
Copy link
Member Author

Note that the mechanism itself is still the same: globally redefine all functions according to the selected mode. There does not seem to be a workable alternative to this.

@Kolaru
Copy link
Collaborator

Kolaru commented Jun 7, 2020

I think this is conceptually fine. One way of another, changing the behavior of function must somehow be a redefinition anyway.

For our own testing purpose, I think it would be good to have a do-block syntax available, as it will likely make tests more readable and safer.

@dpsanders
Copy link
Member Author

@Kolaru Thanks for the feedback.

I agree that having a do-block syntax would be good for testing purposes. I'm not sure I'll manage that in this PR though.

@mforets
Copy link
Contributor

mforets commented Apr 8, 2021

Bump 😄 Is this "only" needing to add testing and docs?

@dpsanders
Copy link
Member Author

And probably other rounding modes, yes.

@OlivierHnt
Copy link
Member

What is the current state of this PR?

@lucaferranti
Copy link
Member

@lbenet I have fixed the merge conflicts so this should be ready for review / merge.

Couple of points

  • the PR uses fast power by default, I think we should use tight by default (because it's the current behavior, because otherwise it would be a breaking change and for coherence for the rounding mode, which is tight by default)
  • Does the rounding with FastRounding disappear in this PR? based on these lines
  • tests for fast power and non-tight modes missing. A good to have test for fast is the one in Bug in power of large numbers #491 (btw that seems to work now on this branch, so that issue probably can be closed)

@lucaferranti
Copy link
Member

Does the rounding with FastRounding disappear in this PR? based on these lines

however looking at the rounding.jl file it seems to be still there and the docstring is just outdated

@lucaferranti
Copy link
Member

fixes #14

@lucaferranti lucaferranti linked an issue Oct 11, 2022 that may be closed by this pull request
@lucaferranti lucaferranti mentioned this pull request Oct 11, 2022
Copy link
Member

@lbenet lbenet left a comment

Choose a reason for hiding this comment

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

Thanks a lot @lucaferranti for dealing with rebasing to current master.

In general, LGT. Still, Ileft few comments, the important ones related to testing this (instead of commenting the tests), and also about changing the defaults. I think the actual only requirement is to bump to the next minor version.

Comment on lines 13 to 17
function cbrt(a::Interval{T}) where T
isempty(a) && return a

@round(cbrt(a.lo), cbrt(a.hi))
end
Copy link
Member

Choose a reason for hiding this comment

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

cbrt is obtained through CRlibm, right? That's the reason to delete it here, isn't it?

Comment on lines 22 to 24
a = _normalisezero(a)
b = _normalisezero(b)

Copy link
Member

Choose a reason for hiding this comment

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

Is this file changing with respect to master? It shouldn't, right?

Comment on lines +15 to +16
@eval ^(::PowerType{:tight}, a::Interval{Float64}, x::$T) = atomic(Interval{Float64}, bigequiv(a)^x)
@eval ^(::PowerType{:tight}, a::Interval{Float32}, x::$T) = atomic(Interval{Float64}, bigequiv(a)^x)
Copy link
Member

Choose a reason for hiding this comment

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

Should we impose that a::Interval{T} and x::T?

Comment on lines +34 to +37
# name mismatch
if directed_rounding == :fast
directed_rounding = :accurate
end
Copy link
Member

Choose a reason for hiding this comment

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

We should only use one of them, say :accurate...

const allowed_values = Dict(:directed_rounding => (:tight, :fast, :none),
:powers => (:tight, :fast))

function configure!(; directed_rounding=nothing, powers=nothing)
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 fixing the defaults here, instead of nothings ...?

Copy link
Member

Choose a reason for hiding this comment

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

Rebump question...

@@ -80,7 +81,7 @@ export

export showfull

import Base: rounding, setrounding, setprecision
import Base: setprecision
Copy link
Member

Choose a reason for hiding this comment

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

Since we are getting rid of rounding and setrounding, shouldn't we amend (in parallel) the docs? Similarly, we should add the corresponding docs of IntervalArithmetic.set_directed_rounding

Comment on lines +20 to +21
const configuration = Dict(:directed_rounding => :tight,
:powers => :fast)
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 we should have as default configuration that both defaults are :tight; It seems to me a bit unnatural to have (:directed_rounding => :tight and :powers => :fast. Note that tests change to this mode.

end

"""
setrounding(Interval, rounding_type::Symbol)
set_directed_rounding(rounding_type::Symbol)
Copy link
Member

Choose a reason for hiding this comment

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

@@ -10,6 +10,6 @@ include("linear_algebra.jl")
include("loops.jl")
include("parsing.jl")
# include("rounding_macros.jl")
include("rounding.jl")
#include("rounding.jl")
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't we adapt the tests to the changes implemented here?

@OlivierHnt
Copy link
Member

Superseded by PR #593. Let us re-visit this PR if the power mechanism fails to address all the concerns.

@OlivierHnt OlivierHnt closed this Dec 13, 2023
@OlivierHnt OlivierHnt deleted the dps/config branch May 23, 2024 07:52
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.

Power ^ allocates Make fast powers (pow) the default
6 participants