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

#300 - Correct usage of IntervalArithmetic #316

Merged
merged 4 commits into from
Apr 3, 2018
Merged

#300 - Correct usage of IntervalArithmetic #316

merged 4 commits into from
Apr 3, 2018

Conversation

mforets
Copy link
Member

@mforets mforets commented Apr 3, 2018

Closes #300.

@mforets
Copy link
Member Author

mforets commented Apr 3, 2018

This section illustrates why before we didn't have problems in the tests and now i had to change them, since are using @interval instead of IntervalArithmetic.Interval.

julia> using IntervalArithmetic

julia> Interval(Float32(1.0), Float32(2.0))

[1, 2]

julia> typeof(ans)
IntervalArithmetic.Interval{Float32}

julia> @interval(Float32(1.0), Float32(2.0))
ERROR: MethodError: Cannot `convert` an object of type IntervalArithmetic.Interval{Float64} to an object of type Float32
This may have arisen from a call to the constructor Float32(...),
since type constructors fall back to convert methods.
Stacktrace:
 [1] Float32(::IntervalArithmetic.Interval{Float64}) at ./sysimg.jl:77

julia> @interval(1.0, 2.0)
[1, 2]

julia> typeof(ans)
IntervalArithmetic.Interval{Float64}

julia> setprecision(Interval, precision(Float32))
24

julia> @interval(1.0, 2.0)
[1, 2]₂₄

julia> typeof(ans)
IntervalArithmetic.Interval{BigFloat}

Copy link
Member

@schillic schillic left a comment

Choose a reason for hiding this comment

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

Well done!

# for use with other precision, use
# setprecision(IntervalArithmetic.Interval, precision(N))
# however, this will use BigFloat's of given number of bits, which is a
# different numeric type than d, so this will triggeer a MethodError
Copy link
Member

Choose a reason for hiding this comment

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

"triggeer"

@@ -40,9 +40,12 @@ for N in [Float64, Float32] # TODO Rational{Int}
@test d.array[1] isa Hyperrectangle && test_directions(d.array[1])
d = decompose(b, set_type=HPolygon, ɛ=to_N(N, 1e-2))
@test d.array[1] isa HPolygon && test_directions(d.array[1])

if N == Float64
d = decompose(b, set_type=LazySets.Interval, blocks=ones(Int, 6))
Copy link
Member

Choose a reason for hiding this comment

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

indent?

@schillic
Copy link
Member

schillic commented Apr 3, 2018

Actually, the idea of @interval is to create an interval from numerals (as in the tests). In the source code, it does not help because we already have floating point numbers. But let us keep it.

Does that mean that we cannot create Intervals of type Rational{Int} anymore? Can we provide constructors for different types at least? We should add a note to the docs of the Interval type.

👍 for using import. This could (I did not try) have removed the warnings mentioned in #194.

@mforets
Copy link
Member Author

mforets commented Apr 3, 2018

👍 for using import. This could (I did not try) have removed the warnings mentioned in #194.

yes, i think so.


Does that mean that we cannot create Intervals of type Rational{Int} anymore?

Hmmm...

julia> Interval(0, 1)
LazySets.Interval{Float64,IntervalArithmetic.Interval{Float64}}([0, 1])

julia> Interval(0//1, 2//1)
LazySets.Interval{Float64,IntervalArithmetic.Interval{Float64}}([0, 2])

This is not great. At least as you say we should provide constructors. I will ask IntervalArithmetic developers. (Since yesterday, there is #intervals in https://julialang.slack.com/).

@@ -42,8 +41,8 @@ for N in [Float64, Float32] # TODO Rational{Int}
@test d.array[1] isa HPolygon && test_directions(d.array[1])

if N == Float64
Copy link
Member

Choose a reason for hiding this comment

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

Can be removed again, right?

@mforets mforets merged commit 24c5ad2 into master Apr 3, 2018
@mforets mforets deleted the mforets/300 branch April 3, 2018 17:25
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.

2 participants