IntervalArithmetic.jl icon indicating copy to clipboard operation
IntervalArithmetic.jl copied to clipboard

Complete libieeep1788_class.jl

Open krish8484 opened this issue 5 years ago • 6 comments

krish8484 avatar Jul 02 '20 15:07 krish8484

interval(Inf, Inf), interval(-Inf, -Inf) and Interval(NaN, NaN) are returning argument errors now (according to the tests)

krish8484 avatar Jul 02 '20 16:07 krish8484

Coverage Status

Coverage increased (+0.1%) to 90.27% when pulling c6537a35381bfeb28328ec0389a98aff5a38ba9e on krish8484:class into d3a318c6356515ee2d2a0c47ab7af419dea106ea on JuliaIntervals:master.

coveralls avatar Jul 02 '20 16:07 coveralls

@decorated responds to setprecision now Master

julia> typeof(@decorated(1, 2))
DecoratedInterval{Float64}

julia> setprecision(Interval, 256)
256

julia> typeof(@decorated(1, 2))
DecoratedInterval{Float64}

Branch

julia> typeof(@decorated(1, 2))
DecoratedInterval{Float64}

julia> setprecision(Interval, 256)
256

julia> typeof(@decorated(1, 2))
DecoratedInterval{BigFloat}

@decorated now throws an ArgumentError just like @interval for improper inputs

Branch

julia> @decorated(2, -1)
ERROR: ArgumentError: `[2.0, -1.0]` is not a valid interval. Need `a ≤ b` to construct `interval(a, b)`.
Stacktrace:
 [1] interval(::Float64, ::Float64) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\intervals\intervals.jl:107
 [2] top-level scope at REPL[2]:1

julia> @decorated("[  -1.0  , 1.0]_fooo") #this was one of ITF1788 Test
ERROR: LoadError: ArgumentError: Cannot process fooo as decoration
Stacktrace:
 [1] parse(::Type{DecoratedInterval{Float64}}, ::String) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\parsing.jl:48
 [2] @decorated(::LineNumberNode, ::Module, ::Vararg{Any,N} where N) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\decorations\intervals.jl:138
in expression starting at REPL[3]:1

Better string handling for @interval and @decorated

Branch


julia> @decorated("[ Nai  ]") == nai()
true

julia> @decorated("[-1.0, +infinity]_def") == DecoratedInterval(Interval(-1.0, Inf), def)
true

julia> @test_throws ArgumentError @interval("[ -inf ,  INF ]_com")
Test Passed
      Thrown: ArgumentError

However, these are some tests that are still failing, any suggestions on how can we solve them?

julia>  @interval("[1.0E+400 ]") == @interval(0x1.fffffffffffffp+1023, Inf)
ERROR: ArgumentError: Unable to process string [1.0E+400 ] as interval
Stacktrace:
 [1] parse(::Type{Interval{Float64}}, ::String) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\parsing.jl:297
 [2] atomic(::Type{Interval{Float64}}, ::String) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\intervals\conversion.jl:75
 [3] top-level scope at REPL[30]:1
caused by [exception 1]
Base.Meta.ParseError("overflow in numeric constant \"1.0e+400\"")

julia> @interval("10?3e380") == @interval(0x1.fffffffffffffp+1023, Inf)
ERROR: ArgumentError: cannot parse "7.0e380" as Float64
Stacktrace:
 [1] _parse_failure(::Type, ::String, ::Int64, ::Int64) at .\parse.jl:370 (repeats 2 times)
 [2] #tryparse_internal#348 at .\parse.jl:366 [inlined]
 [3] tryparse_internal at .\parse.jl:364 [inlined]
 [4] #parse#349 at .\parse.jl:376 [inlined]
 [5] parse at .\parse.jl:376 [inlined]
 [6] parse(::Type{Interval{Float64}}, ::String) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\parsing.jl:212
 [7] atomic(::Type{Interval{Float64}}, ::String) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\intervals\conversion.jl:75
 [8] top-level scope at REPL[31]:1

julia> @decorated("10?1800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000_com") == DecoratedInterval(Interval(-Inf, Inf), dac)
ERROR: LoadError: ArgumentError: cannot parse "1800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e-0" as Float64
Stacktrace:
 [1] _parse_failure(::Type, ::String, ::Int64, ::Int64) at .\parse.jl:370 (repeats 2 times)
 [2] #tryparse_internal#348 at .\parse.jl:366 [inlined]
 [3] tryparse_internal at .\parse.jl:364 [inlined]
 [4] #parse#349 at .\parse.jl:376 [inlined]
 [5] parse at .\parse.jl:376 [inlined]
 [6] parse(::Type{Interval{Float64}}, ::SubString{String}) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\parsing.jl:119
 [7] parse(::Type{DecoratedInterval{Float64}}, ::String) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\parsing.jl:42
 [8] @decorated(::LineNumberNode, ::Module, ::Vararg{Any,N} where N) at C:\Users\ASUS\.julia\dev\IntervalArithmetic\src\decorations\intervals.jl:138
in expression starting at REPL[32]:1

julia>  @decorated("[ -inf ,  INF ]_com") == nai()
false

julia>  @decorated("[ -inf ,  INF ]_com")
DecoratedInterval(Interval(-Inf, Inf), com)

There are few more which more failing because of strict rounding.

Edit: I have added the test file in this Branch and commented the failing tests(for now)

krish8484 avatar Jul 07 '20 15:07 krish8484

There are multiple tests in this file like

@interval("10?3e380") == @interval(0x1.fffffffffffffp+1023, Inf)

These tests expect Interval(floatmax(), Inf) as output when the input(like in the above case) exceeds floatmax(). This is not ideal since

julia> floatmax()
1.7976931348623157e308

which is very less than the desired input which is 7e380 and 13e380.

How should we handle this in IntervalArithmetic.jl? @dpsanders @lbenet

krish8484 avatar Jul 11 '20 21:07 krish8484

As you say the maximum representable Float64 is around 1e308 so that is the correct result (as specified in the tests). There's nothing better that can be done within the realm of Float64.

dpsanders avatar Jul 11 '20 21:07 dpsanders

All the tests from this file except two are passing now. Those 2 tests are failing because it is related to issue #395.

krish8484 avatar Jul 14 '20 18:07 krish8484