Various differences for extreme cases

[dpsanders]

Using FastRounding for IntervalArithmetic tests shows up various different behaviours from standard rounding mode changes for extreme cases:

https://travis-ci.org/JuliaIntervals/IntervalArithmetic.jl/jobs/224924934

Maybe these are known / expected.

[JeffreySarnoff]

I made some changes in two of the three or all three pkgs. Caught a couple of subtle bugs. Please rerun those tests. At least some of the errors would be fixed by adding ifelse( extremal value , .. , ..) which is possible -- with some speed hit. Let's see if the current adjustments have helped or not.

[dpsanders]

There doesn't seem to be much difference -- the same tests are failing,
in particular, the division ones like

   Expression: Interval(-30.0, 0.0) / Interval(-Inf, -3.0) --> Interval(0.0, 10.0)
      Expected: [0, 10]
      Occurred: [4.940656458e-324, 10]

[dpsanders]

You can run the tests locally via

Pkg.test("IntervalArithmetic")

with your packages checkouted to master.

[dpsanders]

Ah, that seems to be another ErrorfreeArithmetic issue:

julia> using ErrorfreeArithmetic

julia> divide_accurately(1., Inf)
(0.0, NaN)

which maybe requires a similar ifelse treatment to JeffreySarnoff/ErrorfreeArithmetic.jl#5

[dpsanders]

Basically any NaN in the second argument should be replaced by 0.0?

[JeffreySarnoff]

hi, lo = 1.0 / Inf (0.0, NaN) while unhelpful to you (and so it will be brought into line), it is not "wrong" once the hi part is zero, the lo part cannot be 0.0 because with errorfree transformations the significant bits of hi and lo do not overlap so, the lo part must not be zero and the lo part cannot not be zero (0.0, NaN) QED-ish

…

On Thu, Apr 27, 2017 at 3:13 PM, David P. Sanders ***@***.***> wrote: Basically any NaN in the second argument should be replaced by 0.0? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABmqxv2yBMZ0HLeYxCk1wiPBijYtHX1Cks5r0Oi8gaJpZM4NFe4p> .

[dpsanders]

I would say that 0.0 does not have any significant bits, so (0.0, 0.0) doesn't overlap. If you sum 0.0 and 0.0 with add_errorfree, the result is (0.0, 0.0), no? On 27 Apr 2017 5:22 p.m., "Jeffrey Sarnoff" <[email protected]> wrote:

…

hi, lo = 1.0 / Inf (0.0, NaN) while unhelpful to you (and so it will be brought into line), it is not "wrong" once the hi part is zero, the lo part cannot be 0.0 because with errorfree transformations the significant bits of hi and lo do not overlap so, the lo part must not be zero and the lo part cannot not be zero (0.0, NaN) QED-ish On Thu, Apr 27, 2017 at 3:13 PM, David P. Sanders < ***@***.***> wrote: > Basically any NaN in the second argument should be replaced by 0.0? > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/JeffreySarnoff/FastRounding. jl/issues/6#issuecomment-297811506>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ ABmqxv2yBMZ0HLeYxCk1wiPBijYtHX1Cks5r0Oi8gaJpZM4NFe4p> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALtTlI8Rgh4nO1cB_PUweVJV6WTn7a7ks5r0RUJgaJpZM4NFe4p> .

[JeffreySarnoff]

(rook takes queens pawn, bishop to kings bishop 3, knight to knightsbridge, bishop takes lunch)
As a finite IEEE754-2008 binary floating point value, zero(Float64) has 53 significant bits (one implict).

In all of the _errorfree arithmetic routines, wherever a result is such that hi==0.0, the lo is opaque. Any floating point value that may be occupying lo is not a part of the errorfree outcome -- in the same way that where hi==Inf, the lo is opaque. This manner of / approach to use has been with my errorfree work all along. The double-double code I wrote would see hi==zero and not palaver with lo. It turns out that results propogate accurately and arith-logic keeps on working when that is done throughout.

So, that is why it is so. Nonetheless, I am delighted to have these corner cases resolve as you expect. You know what you want things to do -- If you would make those behaviors do as you prefer by PRing some ErrorfreeArithmetic, then that would isolate the remaining corner cases, which I expect involve values similar to 1.0e-308. I know how rejigger those so they match nextfloat, prevfloat -- the reason they do not match now for some (actually very few, but always the tested ones) is I chose speed at each turn over matchy matchy behavior [as did the authors of those papers]. Splitting the implementation into two is reasonable.

[dpsanders]

I need a drop-in replacement alternative for "changing the rounding-mode" operations, with exactly the same behaviour in all cases, but with the maximum attainable speed-up. (The speed-up could be non-uniform for extreme cases though.)

Surely this is too stringent a requirement for other uses, as you suggest.

Basically it seems like we need "FastestPossibleRounding" and "CorrectFastRounding", or at least two sets of corresponding functions.

[dpsanders]

But the division issue, for example, just boils down to "don't round if you have already found an exact result". The problem is just detecting that the result is already exact.

[JeffreySarnoff]

Someone proved that there is no error-free transformation for floating point division without much more computation. So we have accurate_division, which is as accurate as possible using arithmetic operations at the given precision. I'll use Sunday to write code. I agree. We need "CorrectFastRounding" (faster correct rounding) where each result matches definition. And we need "FastestPossibleRounding" (fastest stable rounding) where non-extremal operands yield correct results and all operands behave as specified.

…

On Fri, Apr 28, 2017 at 9:35 AM, David P. Sanders ***@***.***> wrote: But the division issue, for example, just boils down to "don't round if you have already found an exact result". The problem is just detecting that the result is already exact. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABmqxgR1B2-76aqjhjnRpZG7otpanlb4ks5r0esrgaJpZM4NFe4p> .

[dpsanders]

Most of these seem to have been fixed.