-
Notifications
You must be signed in to change notification settings - Fork 33
[RFC] Acceptable input ranges #156
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
Comments
BTW, I do not fully understand the original intent of this test. ( FixedPointNumbers.jl/test/fixed.jl Lines 95 to 100 in 7ad0f0c
Edit: |
For the time being, I decided to allow the wider range than [ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When fixing the issue #102 (PR #131), I changed the acceptable input range for
Normed
as follows:FixedPointNumbers.jl/src/normed.jl
Lines 69 to 74 in 7ad0f0c
(typemax(T)-rawone(U))/rawone(U)+1
essentially meanstypemax(T)/rawone(U)
.The decision is based, for example, on the idea that the range of
N0f8
should be [0, 1]. In particular, regarding the lower bound, I believe that theNormed
s should not accept negative inputs since the currentNormed
s are unsigned types.However, the following is also true:
So, I don't know whether the acceptable input range of
Q0f7
should be [-1, 127/128] , or [-128.5/128, 127.5/128).Accepting inputs less than
typemin
or greater thantypemax
causes a bit confusing, and it is nonsense especially if the input type is not based on the binary numeral system. On the other hand, it seems to be a desirable property that the difference between the upper and lower bounds is a power of two.The text was updated successfully, but these errors were encountered: