EFT overflows

[munrocket]

@JeffreySarnoff in one rust package https://docs.rs/safeeft/0.0.5/safeeft/ I found new safe EFT.
They said that M.Kashiwagi in his paper (in japanese) found special cases where twoSum and twoProducts not safe enough with IEEE 747-2008 floats. What do you think about that?

twosum ( 3 . 5 6 3 0 6 2 4 4 4 4 8 7 4 5 3 9 e +307 ,
−1 .7976931348623157 e +308)
( −1 .4413868904135704 e +308 , nan )
twoproduct ( 6 . 9 2 9 0 0 1 7 1 3 8 6 9 9 3 6 e +236 ,
2 . 5 9 4 4 4 7 5 2 5 1 9 5 2 0 0 3 e+71)
( 1 . 7 9 7 6 9 3 1 3 4 8 6 2 3 1 5 7 e +308 , i n f )

[dpsanders]

This is very interesting and exactly what we need for IntervalArithmetic.jl.

What is the license on that package? Would you like to port it to Julia?

[dpsanders]

This seems to be the repo, with MIT license!

https://github.com/GNQG/safeeft

[munrocket]

Actually good old EFT just works in most of the cases, especially for usage in graphics. It is possible that nobody found this problem since 1970? Just curious.

[JeffreySarnoff]

I am aware of these outlier cases. I will take a look at the repo code and opine.

[JeffreySarnoff]

AccurateArithmetic.jl is no longer current (though I try). The best code for eft stuff is ErrorfreeArithmetic.jl in my github space.

[munrocket]

Sorry, probably opened issue in wrong place.

[JeffreySarnoff]

safetwosum_branch from the rust repo is < 20% slower than two_sum, the straight line version is much more time consuming.

• [ ]

[JeffreySarnoff]

safetwoproduct_fma from the rust repo is the same as two_prod.
So I could easily add a safe_two_sum that uses the branch logic.
@dpsanders does this work for you?

[JeffreySarnoff]

oic (in the paper) there are also versions of add, sqrt, mul, div that round up and versions round down [but they are not entirely correct :<]

[JeffreySarnoff]

read too quickly (my Japanese is rusty at best [google translate is difficult to read because there are overlapping sections in the translation]. https://translate.google.com/translate?hl=en&sl=ja&u=http://verifiedby.me/adiary/pub/kashi/image/201406/nas2014.pdf&prev=search

The rounded-up and rounded-down routines are intended to deliver Float64 results using two_xxx routines internally. They do work correctly for that @dpsanders they use pretty much the same approach we have used in FastRounding. I could play with recoding that for you. after New Years

[dpsanders]

That sounds great. I don't read Japanese but may be able to get some help with that.

[munrocket]

In Julia you also have emulated fma instruction with EFT too.

[JeffreySarnoff]

yes .. however hardware fma for Float64 and Float32 is widespread, so much so that all of DoubleFloats is built upon the presumption of its presence [and there have been no issues with that decision]. The additional time required absent hardware fma is so great that to require that implementation is to remove one of the essential qualities that others find worthwhile in the pkg.

[munrocket]

So... This is just an overflow problem. If some value overflows, we can say that result become unexpected, that’s all.