You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
and all the other types with a negative number of fractional bits available, when range demands are high, precision demands are low and you want to distribute the available values uniformly in the range or want to use integer arithmetic (so floating points are not an option).
This would not really match the packet's name as they are not really fixed-point numbers (with the "point" being outside of the represented bits). On the other hand, an implementation of these numbers (scaled integers) seems to be completely identical in representing the type (struct) and should cover both positive and negative numbers of fractional bits if some methods are generalized or their domain restrictions are relaxed.
So what would these scaled integers be? Would they use a slightly generalized version of Fixed, would they be a ScaledInteger within the FixedPointNumbers.jl package or would they be the topic of a ScaledIntegers.jl package?
My main preference for ScaledIntegers.jl is that it seems more intuitive to the user than what a negative bits might mean.
Indeed, it would. However, we most likely want to have (also) a type which allows both positive and negative scaling. So I guess the question is whether a negatively scaled integer is more intuitive than a negative number of fractional bits. It probably is, but I guess at least in the beginning both take a bit of time to use them intuitively.
It's also interesting, how much this is a matter of perspective. One valid view of floating point numbers is that all the integers in the mantissa are scaled to be between 0 and 1 (or between 1 and 2) and these then again are scaled by the power (resulting from the exponent).
Here, it does not matter whether the power scales positively or negatively, we always call it "floating point" even if there is no "point" inside of the representation (as in Float32(4)). In that sense, it would be totally valid if not even advisable to use the name fixed point value for negative scaling, too.
FixedPointNumbers.jl serves as one of the cornerstones of the Julia ecosystem, including ColorTypes among others.
This is just my personal opinion, but I believe this package should prioritize working well in common use cases over comprehensive coverage.
By limiting the valid range of f, it is sometimes possible to eliminate edge cases that cause bugs or enable better optimization.
I think it would be beneficial to add a couple of abstract types by v1.0 for the other variant packages and their downstream packages.
Activity
mkitti commentedon Nov 25, 2025
That's pretty neat. I'm leaning towards a ScaledIntegers.jl package, but it seems possible to implement here.
My main preference for ScaledIntegers.jl is that it seems more intuitive to the user than what a negative bits might mean.
PatrickHaecker commentedon Nov 27, 2025
Indeed, it would. However, we most likely want to have (also) a type which allows both positive and negative scaling. So I guess the question is whether a negatively scaled integer is more intuitive than a negative number of fractional bits. It probably is, but I guess at least in the beginning both take a bit of time to use them intuitively.
It's also interesting, how much this is a matter of perspective. One valid view of floating point numbers is that all the integers in the mantissa are scaled to be between 0 and 1 (or between 1 and 2) and these then again are scaled by the power (resulting from the exponent).
Here, it does not matter whether the power scales positively or negatively, we always call it "floating point" even if there is no "point" inside of the representation (as in
Float32(4)). In that sense, it would be totally valid if not even advisable to use the name fixed point value for negative scaling, too.kimikage commentedon Sep 13, 2026
FixedPointNumbers.jlserves as one of the cornerstones of the Julia ecosystem, includingColorTypesamong others.This is just my personal opinion, but I believe this package should prioritize working well in common use cases over comprehensive coverage.
By limiting the valid range of
f, it is sometimes possible to eliminate edge cases that cause bugs or enable better optimization.I think it would be beneficial to add a couple of abstract types by v1.0 for the other variant packages and their downstream packages.
nhz2 commentedon Sep 22, 2026
I think we need the overflow bug fix in JuliaLang/julia#63283 for this to work.