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

Remove pi_interval #285

Closed
Tracked by #271
dpsanders opened this issue May 12, 2019 · 15 comments
Closed
Tracked by #271

Remove pi_interval #285

dpsanders opened this issue May 12, 2019 · 15 comments

Comments

@dpsanders
Copy link
Member

pi_interval(T) is the same as Interval{T}(pi).

cc @yashrajgupta

@dpsanders
Copy link
Member Author

Also we can use oftype(a, pi) if a is an Interval.

@yashrajgupta
Copy link
Contributor

yashrajgupta commented May 12, 2019

Seems like something is different,

julia> pi_interval(Float64)
Interval(3.141592653589793, 3.1415926535897936)
julia> Interval{Float64}(pi)
Interval(3.141592653589793, 3.141592653589793)

@dpsanders
Copy link
Member Author

Ah, oops. Could you fix this please?

@dpsanders
Copy link
Member Author

(Please quote code inside triple backticks with jl after the first set.)

```jl
(code)
```

@yashrajgupta
Copy link
Contributor

I think pi_interval is a function which we have defined but Interval{T}(pi) is a type conversion of a rational number pi in to an Interval of type T. So what do we want at the end? Is it that pi_interval should be interval of one absolute value of pi or should it an interval containing pi and nearby values.

@dpsanders
Copy link
Member Author

dpsanders commented May 12, 2019

Of course we want it to be the smallest interval containing pi, which is obtained currently from

julia> convert(Interval, pi)
Interval(3.141592653589793, 3.1415926535897936)

(although who knows how efficient that is).

[Please quote code inline as `(code)`.]

@dpsanders
Copy link
Member Author

The idea is always that interval arithmetic should give results that are guaranteed to contain the true results. In this case pi is an irrational (not rational, as you wrote) number, which is not representable exactly in floating point. So any interval calculations with pi must use an interval containing pi, preferably the smallest possible one.

@dpsanders
Copy link
Member Author

Hmmm. It seems that convert here is slow. Maybe we should retain pi_interval(T) and just calculate the interval once and for all statically.

@yashrajgupta
Copy link
Contributor

yashrajgupta commented May 12, 2019

Sorry about the typo. Yes we should retain pi_interval function until we find a smaller interval for pi moreover I think Interval{T}(pi) does not contain the pi value since it is just a single value interval.

@dpsanders
Copy link
Member Author

I am saying that this is the smallest interval for Float64:

julia> x = convert(Interval{Float64}, pi)
Interval(3.141592653589793, 3.1415926535897936)

You can test this:

julia> nextfloat(x.lo) == x.hi
true

@dpsanders
Copy link
Member Author

Ah, I see that pi_interval already does what I was suggesting -- defines it once and for all.

@dpsanders
Copy link
Member Author

But we should define Interval{Float64}(pi) and Interval(pi) to do the same thing.

@lbenet
Copy link
Member

lbenet commented May 12, 2019

I think pi_interval here is ok; the version for Float64 uses atomic(Interval{Float64}, pi) which is more efficient than convert. Perhaps this should be better explained in the documentation.

@Kolaru
Copy link
Collaborator

Kolaru commented Aug 19, 2019

In #271 I plan to get rid of pi_interval by defining (for each flavor but here is the version for Interval)

Interval{T}(::Irrational{:π}) where T = atomic(Interval{T}, π)
Interval(::Irrational{:π}) = Interval{Float64}(π)

If further optimisation is required, the methods are specific enough to have them there.

@lbenet
Copy link
Member

lbenet commented Mar 8, 2020

Closed by #338

@lbenet lbenet closed this as completed Mar 8, 2020
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

No branches or pull requests

4 participants