Implement numerically stable sum of floats about num-traits HOT 4 OPEN

I see, this is from src/libtest/stats.rs.

I'm not sure about using an intermediate object like that. Can it just be an associated function?

trait Float {
...
   fn stable_sum<I: IntoIterator<Item = Self>(iter: I) -> Self { ... }
}

from num-traits.

From @vks on June 29, 2017 7:52

It could be an associated function, but then it would be less general:
incremental calculations would not be possible.

On Thu, Jun 29, 2017, 03:30 Josh Stone [email protected] wrote:

I see, this is from src/libtest/stats.rs
https://github.com/rust-lang/rust/blob/69c65d29615c391c958ebf75dd65258ec23e175c/src/libtest/stats.rs#L164-L196
.

I'm not sure about using an intermediate object like that. Can it just be
an associated function?

trait Float {
...
fn stable_sum<I: IntoIterator<Item = Self>(iter: I) -> Self { ... }
}

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
rust-num/num#309 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACCtIKZpUXsAvKzyGu7ZsffLK9fKU0kks5sIv4xgaJpZM4OGjrD
.

from num-traits.

I believe the proposed implementation will give incorrectly-rounded results on some inputs. The function

    fn sum(&self) -> f64 {
        self.partials.iter().fold(0., |p, q| p + *q)
    }

sums the partials naively. Why this is a problem is explained here: https://code.activestate.com/recipes/393090/#c16

I've found a testcase that shows the difference: the vector [1e-16, 1.0, 1e16] should sum to 1.0000000000000002e+16, but instead sums to 1.0000000000000000e+16. This error is masked somehow by the 10,000x looping. Is there a reason the current testcase does this?

I'm not familiar enough with Rust to suggest a fix with confidence, but Python's fsum gives the correct result. Its source can be found here: https://hg.python.org/cpython/file/tip/Modules/mathmodule.c#l1112, with the interesting bit starting on line 1199 (The correct line number may change over time; I can't tell how to make a working permanent link.)

from num-traits.

A note about the N times looping: for the [1e-16, 1, 1e16] case, N <= 2048 correctly causes the assertion to fail, but N > 2048 doesn't. It's a little late in the evening for me to pin down why things change at that power of two. I suspect a rounding error somewhere.

from num-traits.