Add explicitly wrapping versions of integer arithmetic#50790
Conversation
|
In order to decide what to do about JuliaLang/JuliaSyntax.jl#408, I think we need to have the syntax debate here in JuliaLang/julia @jakobnissen Looking through the files, I can see various cases where I'm not sure it deserves its own syntax though, and I'd like to discuss other possibilities: A macroWe could have a macro (eg,
Code example from PR where it's cleaner: s4::UInt64 = s0 +% (3 *% s1) +% (5 *% s2) +% (7 *% s3), # internal splitmix state
# vs
s4::UInt64 = @modular s0 + (3 * s1) + (5 * s2) + (7 * s3), # internal splitmix stateUsing unicode subscriptsFor example
s4::UInt64 = s0 +% (3 *% s1) +% (5 *% s2) +% (7 *% s3), # internal splitmix state
# vs
s4::UInt64 = s0 +ₘ (3 *ₘ s1) +ₘ (5 *ₘ s2) +ₘ (7 *ₘ s3), # internal splitmix statePlain old function names
Special syntax
SummaryConsidering the above, I'm somewhat favoring the idea of a (What if, as a future extension |
|
I would still like to this. Tagging for triage to decide on direction. |
|
I'm sure it was intentional but I don't see it explicitly stated yet, so just for posterity: Zig uses this syntax for this purpose (https://ziglang.org/documentation/master/#Wrapping-Operations) |
|
Triage likes. We really should semantically be distinguishing between intentionally wrapping arithmetic and arithmetic that isn't expected to wrap. The biggest issue is that actually implementing error on overflow everywhere wrapping isn't supposed to happen seems like it will be expensive... so it gets put into a hypothetical |
Keno
changed the title
|
I'm not sure I understand all the proposed usages in Base. most seem at best unnecessary. as one random example:
I think would be the opposite of holding "an explicit semantic expectation that [overflow] is expected and correct," as your aggregate timing estimator will be quite sad if some overflowed value skews it |
|
I had GPT 5.5 go through and examine each site, telling it to err on the side of switching to wrapping arithmetic (since that's the non-breaking option under the flag). In this particular example, it was concerned about overflow on a system with uptime of >584 years and reasoned that a bad print was better than an error. That said, there's also an issue with |
This adds operators `+%`, `-%`, `*%`, which are equivalent to the non-`%` versions, but indicate an explicit semantic expectation that twos completement wrapping behavior is expected and correct. As discussed at JuliaCon 2014 and every year since, users have often requested a way to opt into explicit overflow checking of arithmetic, whether for debugging or because they have regulatory or procedural requirements that expect to be able to do this. Having explicit operators for overflowing semantics allows use cases that depend on overflow behavior for correct functioning to explicitly opt-out of any such checking. I want to explicitly emphasize that there are no plans to change the default behavior of arithmetic in Julia, neither by introducing error checking nor by making it undefined behavior (as in C). The general consensus here is that while overflow checking can be useful, and would be a fine default, even if hardware supported it efficiently (which it doesn't), the performance costs of performing the check (through inhibition of other optimization) is too high. In our experience it also tends to be relatively harmless, even if it can be a very rude awakeing to users coming from Python or other languages with big-default integers. The idea here is simply to give users another tool in their arsenal for checking correctness. Think sanitizers, not language change. This PR includes a macro `@Base.Experimental.make_all_arithmetic_checked`, that will define overrides to make arithmetic checked, but does not include any mechanism (e.g. #50239) to make this fast. What is included in this PR: - Flisp parser changes to parse the new operators - Definitions of the new operators - Some basic replacements in base to give a flavor for using the new operator and make sure it works Still to be done: - [] Parser changes in JuliaSyntax - [] Correct parsing for `+%` by itself, which currently parses as `+(%)` The places to change in base were found by using the above-mentioned macro and running the test suite. I did not work through the tests exhaustively. We have many tests that explicitly expect overflow and many others that we should go through on a case by case basis. The idea here is merely to give an idea of the kind of changes that may be required if overflow checking is enabled. I think they can broadly be classed into: - Crypto and hashing code that explicitly want modular arithmetic - Bit twidelling code for arithmetic tricks (though many of these, particularly in Ryu, could probably be replaced with better abstractions). - UInt8 range checks written by Stefan - Misc
A machine audit of the sites `make_all_arithmetic_checked` would turn
into checked operations (encode each guarded call with an SMT solver,
enumerate every wrapping add/sub/mul/neg it reaches, and
satisfiability-check each site's overflow condition) found three
unconverted sites whose overflow is reachable on VALID inputs, i.e.
calls that are correct today through wrap-cancellation but would throw
under the checked mode:
* `mod(x::T, y::T)` — `x - fld(x, y) * y`: the floored quotient times
`y` lies in `(x - y, x + y]`, so both the product and the subtraction
can wrap; `mod(typemin(Int), 3)` is the simplest instance (`mod1` and
`rem(x, y, RoundDown)` reach the same formula):
julia> Base.checked_sub(typemin(Int), Base.checked_mul(fld(typemin(Int), 3), 3))
ERROR: OverflowError: -3074457345618258603 * 3 overflowed for type Int64
* `mod(x::BitSigned, y::Unsigned)` — `remval + (remval < 0)*y` re-wraps
the negative remainder into the unsigned domain by design; witness
`(-7928727881474113536, 0x6e2be66802e200c0)`.
* `divrem(a, b, RoundDown/RoundUp)` — `a - d*b` with the floored/ceiled
quotient; witnesses `(-8070450533858541568, 2305843009750564864)` and
`(9223371103813285121, 2198967713920)`.
Add `BitSigned`-specialized methods carrying `-%`/`*%` (and `+%` for
the mixed-sign addition), leaving the generic `Integer` methods on
plain operators: arbitrary-precision integers cannot overflow there and
custom `Integer` types have no wrapping-operator methods to dispatch
to. The `RoundToZero` branch stays on checkable operators because the
truncated quotient satisfies `|d*b| <= |a|` — that, and the analogous
products in `fld`, `cld`, `fld1` and all sixteen arithmetic sites of
`divrem(_, _, RoundNearest)`, were machine-proved unable to overflow on
valid inputs, so they are safe for the checked mode as-is.
`rem(x, y, RoundUp) = mod(x, -y)` is intentionally not converted: its
`-y` overflow at `y == typemin` is a genuine bug (the result disagrees
with `divrem` and the documented interval), fixed separately.
Behavior is unchanged; only the future checked mode is affected.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| return xp | ||
| end | ||
| xd, yd = divgcd(promote(x.den, y.den)...) | ||
| Rational(+%(+*(x.num,yd), +*(y.num,xd)), +*(x.den,yd)) |
There was a problem hiding this comment.
| Rational(+%(+*(x.num,yd), +*(y.num,xd)), +*(x.den,yd)) | |
| Rational(+%(+%(x.num,yd), +%(y.num,xd)), +%(x.den,yd)) |
|
wasn't sure if the easiest format was to leave a bunch of inline comments or just one here, I chose the latter, with claude assistance for the bulleted list details IMO the timing & counting functions should not use wrapping arithmetic, because I disagree with
(although maybe that's just my bias from my professional domain) which would mean the changes to
should remain normal arithmetic. there are also several functions which appear to have been refactored to avoid wrapping operations in the first place, which seems like a reasonable / good thing, but might be worth extracting to their own PR:
|
I think these could go either way. The result will still be correct on overflow for the first 500 years, so maybe that's better?
I agree
No, these start at an arbitrary hash value - overflow is expected:
Could be factored out, not sure it's necessary. |
GPT 5.5 argues that explicitly the only guarantee documented is that it's monotonic mod 2^64, with no guarantees on the starting point. I think that argument is convincing, so I will leave this as is. If we want something different, I think we need to strengthen the guarantees of this function first (maybe it should return UInt128?). |
|
fair enough, I trust the combined judgement of keno + machine 😂 just providing counterpoint |
|
An extra set of eyes is always appreciated! |
Fix rational wrapping addition to use wrapping multiplication for cross-products, restore ordinary arithmetic for Dict mutation age counters, and correct a typo caught by the typos workflow. CI failure: https://github.com/JuliaLang/julia/actions/runs/28849713753/job/85561793991 Co-authored-by: OpenAI <noreply@openai.com>
6 participants
This adds operators
+%,-%,*%, which are equivalent to the non-%versions, but indicate an explicit semantic expectation that twos completement wrapping behavior is expected and correct. As discussed at JuliaCon 2014 and every year since, users have often requested a way to opt into explicit overflow checking of arithmetic, whether for debugging or because they have regulatory or procedural requirements that expect to be able to do this. Having explicit operators for overflowing semantics allows use cases that depend on overflow behavior for correct functioning to explicitly opt-out of any such checking.I want to explicitly emphasize that there are no plans to change the default behavior of arithmetic in Julia, neither by introducing error checking nor by making it undefined behavior (as in C). The general consensus here is that while overflow checking can be useful, and would be a fine default, even if hardware supported it efficiently (which it doesn't), the performance costs of performing the check (through inhibition of other optimization) is too high. In our experience it also tends to be relatively harmless, even if it can be a very rude awakeing to users coming from Python or other languages with big-default integers.
The idea here is simply to give users another tool in their arsenal for checking correctness. Think sanitizers, not language change. This PR includes a macro
@Base.Experimental.make_all_arithmetic_checked, that will define overrides to make arithmetic checked, but does not include any mechanism (e.g. #50239) to make this fast.What is included in this PR:
Still to be done:
+%by itself, which currently parses as+(%)The places to change in base were found by using the above-mentioned macro and running the test suite. I did not work through the tests exhaustively. We have many tests that explicitly expect overflow and many others that we should go through on a case by case basis. The idea here is merely to give an idea of the kind of changes that may be required if overflow checking is enabled. I think they can broadly be classed into:
That said, I'm not sure I'll have the time to actually finish this, so I'd be grateful if someone else wanted to take this over to push it through.