-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Promotion rules for overflow reduction #167
Comments
Let's break my proposal into two steps:
I don't think 1. needs to break the existing Item 2. is the more controversial issue, and I'm not interested in working on 1. unless we can come to some kind of consensus. I have thought most about 3 options:
For the last two options, once you get to an The last two differ on what you want out of the system: Conversely, Of course we can write NaNIntegers and see what happens; moreover, if we take step 1. then it becomes possible to support them with this package. But we do have to decide the arithmetic rules, and there a choice is necessary. |
That's a beautiful diagram. Can you explain it a bit? |
I think the rules are really practical, but too ad-hoc. FixedPointNumbers is in JuliaMath, not in JuliaGraphics or JuliaImages, so the behavior is somewhat strange from a neutral point of view. |
If you're going to promote, you have to get to a fixed point wrt the type system very quickly. If your diagram proposes a scheme whereby In my mind, there are basically two sensible options: "don't widen" and "widen all the way immediately." My proposal falls in the latter camp, where "all the way" is defined as something with twice the number of bits. (We could go to machine precision, e.g., |
I agree with you. I showed "bad" examples to clarify the negative aspects of the promotion.
The above diagram does not clearly distinguish signed
Thus, the "Always" rule is a nightmare. I think at least the promotion chain should be broken somewhere. My hope is that it will take place on the 0-th stage, not the first stage. 😄 |
Yeah, the "Always" rule is definitely not viable, and we can discard it now. (Consider a container s = first(a)
for x in Iterators.drop(a, 1)
s += x
end Quiz question: what type is Of the remainder, IIUC they don't promote at all for most types, right? |
For loops, the rules of promoting only once are also problematic. What is the intent of taking a loop quiz here? If you allow the promotion one time, that is just "ad-hoc".
That's right. The chained promotions are never good. Non-cascading "Floating-Point" variants are logically possible options, but Anyway, the important thing is not to convince me, but to make FixedPointNumbers better. |
We do have union-splitting, so when there are only 2 choices it wouldn't be a disaster, but the better way to write that loop would be s = plustype(first(a)) # `plustype(x)` equivalent result to `x + zero(x)`
for x in Iterators.drop(a, 1)
s += x
end You can't even implement a useful form of
Agreed that one has to pay attention somewhere. The issue is that when you're doing interactive data analysis
Agreed & reciprocated. I'm not trying to pretend this is a clear-cut decision even to me. Of the options I listed in #167 (comment) (updated), I think the first, second, and fourth are relatively viable. The NaNIntegers route scares me from a performance standpoint and I'd rather we didn't have to do that. I can live with the status quo (the first option), I just wonder if it's a missed opportunity to make the whole ecosystem better. |
Another reason the second option is "ad-hoc", is that it is only reasonable with addition/subtraction. For image processing, it may not be a problem. However, if we take up image processing, I think that higher-level packages (e.g. ColorVectorSpace) should handle it. FixedPointNumbers is only part of the ecosystem. It's never bad that low-level packages have low functionality. |
That bothers me too. I recently added the fourth option, promote to
I hadn't considered the idea of having different promotion rules for arithmetic on |
As mentioned in #166 (comment), I will change the arithmetic functions in v0.9.0. The changes will include |
This discussion seems to be stale. I will start improving the arithmetic functions (cf. PR #190). They may move to another package (something like FixedPointArithmetic) in the future. |
We plan to implement the overflow-checked arithmetic to mitigate the overflow problem (cf. #41, #152).
The checked arithmetic prevents numerical errors which the users do not intend, but it is up to the users to correct them. There are two major issues.
Normed
cannot represent negative numbers, so we will easily encounterOverflowError
in subtraction.To solve the former, signed
Normed
is proposed in PR #143.I don't agree with the introducing
Normed{<:Signed}
because of the huge impact on compatibility. However, I think signedNormed
is not so bad unless it breaks the existingNormed
.For the latter, PR #143 also proposes type promotions.
I don't consider the latter a fatal problem, as it's up to the users what operations and types they want. On the other hand, the type promotion has some problems.
Perhaps you might think that the type promotion frees you from the overflow problems.
But I think it is an illusion. To turn and face reality, let's decide the promotion rules.
Of course, the preferred promotion rule for me is "not to promote".
The text was updated successfully, but these errors were encountered: