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
If I have a 24-bit fixed-point number x I might represent it as a Fixed{Int32, 23}. If I later wanted to widen it to a 32-bit number to get extra precision, I might try convert(Fixed{Int32, 31}, x, but that doesn't currently have a method. We could implement it just as a left shift.
I'm not sure what the best overflow checking behavior would be - in this case we'd worry about any values over 1 that would get lost. For a right-shift we'd get extra headroom but lose precision. Currently the float-to-fixed behavior is to throw an InexactError on an overflowing conversion but not when losing precision, so we could match that behavior and only need to check on left-shifts.
The text was updated successfully, but these errors were encountered:
hah, I was just checking to see if there was an issue filed for this and it turns out I already filed one.
Does this seem like a good idea in general? I could probably put together a PR.
My general thought process is that if we suppose convert(::Type{Fixed}, x::FloatingPoint) it would make sense by analogy to support convert(::Type{Fixed}, x::Fixed}) which tries to represent the same value with the different representation.
Yes, having such conversion methods would be great. Do keep in mind the distinction between Fixed and Normed, what you describe may only be applicable to Fixed. It would be fine to only implement the methods for that case.
If I have a 24-bit fixed-point number
x
I might represent it as aFixed{Int32, 23}
. If I later wanted to widen it to a 32-bit number to get extra precision, I might tryconvert(Fixed{Int32, 31}, x
, but that doesn't currently have a method. We could implement it just as a left shift.I'm not sure what the best overflow checking behavior would be - in this case we'd worry about any values over 1 that would get lost. For a right-shift we'd get extra headroom but lose precision. Currently the float-to-fixed behavior is to throw an
InexactError
on an overflowing conversion but not when losing precision, so we could match that behavior and only need to check on left-shifts.The text was updated successfully, but these errors were encountered: