I don't know is this mentioned, but something like JavaScript's Math.sumPrecise may be an inspiration? IIRC it is usually implement with Shewchuk's Grow-Expansion.
This is not the same thing. Algebraic methods on floats allows the implementation to return a number of possible values, depending on how the operations are rearranged. This proposal would make the final result a single value on all supported platforms.
(It would allow algebraic optimizations on the infinite-precision intermediate operations, but not such optimizations on floating point operations)
1 Like
C has shown that C's promotion rules are confusing.
C is uniquely bad at this with footguns like mixing ints and floats causing silent truncation, vaguely defined platform-specific sizes, changing unsigned to signed with potential UB on top. These are unforced errors that C has, but aren't inherent to the problem space.
I don't support the particular proposal in this thread, but I want to push back against using C as an example, because it leads to wrong conclusions.
Similarly, C++ has shown that references are dangerous, closures are full of footguns, smart pointers have unavoidable overheads, and yet we have robust versions of these things in Rust.
3 Likes
Ah, p-adic numbers strike again. 
Thanks; my concerns are resolved then.
1 Like
i wouldn't say it is a good idea to mention ramanunjan sums as "easy to see". by doing ramanunjan summation, you can "easily see" that -7/12=-13/12, which is not very convenient if you want to do any math ever.
mentionning p-adic numbers from the start would be a much more reasonable argument that isn't likely to mislead users not necessarily very experienced with the complexities of infinite summation
1 Like