| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
terminalElement (the element _after_ the last one!) was used to terminate foreach loops and sums of non-standard instances of Numeric. Unfortunately, this could result in the end wrapping around and hitting the beginning again, making the first element bad.
This patch fixes the behavior by altering the loop to end after the last element is encountered. The particular flavor was chosen out of a few possibilities because it gave the best microbenchmarks on both large and small ranges.
Test written. While testing, a bug was also uncovered in NumericRange, and was also fixed. In brief, the logic around sum is rather complex since division is not unique when you have overflow. Floating point has its own complexities, too.
Also updated incorrect test t4658 that insisted on incorrect answers (?!) and added logic to make sure it at least stays self-consistent, and fixed the range.scala test which used the same wrong (overflow-prone) formula that the Range collection did.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It makes me a bit nervous that NumericRange[Int] will
get different wrong values in overflow situations compared
to Range due to the missing toLong though.
It could probably need some investigation if reordering the
operations can rule out wrong values, e. g. only fail when
the fold also fails.
Apart from that, it might make sense to just throw an exception
if an overflow happens instead of silent overflow.
|
|
|
Partially fixes SI-4658. NumericRange stays slow, thanks to the brilliant idea that Numeric doesn't need a division operation.
|
