Skip to content
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] Reserving aliases for unsigned Fixed and signed Normed #228

Open
kimikage opened this issue Sep 14, 2020 · 2 comments
Open

[RFC] Reserving aliases for unsigned Fixed and signed Normed #228

kimikage opened this issue Sep 14, 2020 · 2 comments
Labels

Comments

@kimikage
Copy link
Collaborator

As noted in #199, unsigned Fixed and signed Normed are mathematically definable, but we still have some preparations to implement them.

Although those types are certainly not used often, but in fact, I occasionally use unsigned Fixed in private projects. In that case, I give those types redundant names.

However, when we handle concrete Fixed/Normed numbers, we often use the aliases (e.g., Q0f7, N0f8). If we have the predetermined aliases for unsigned Fixed and signed Normed, they can be used to make the future migration easier.

See also #51

Candidates

unsigned Fixed

  • UQxfy (Unsigned Q)
  • Qxfy (x+y == 8sizeof(T))
  • Uxfy (Unsigned)
  • Rxfy (following Q)
  • Fxfy (Fixed)
  • Xxfy (fiXed)

signed Normed

Renaming Nxfy to UNxfy is a consistent practice, but it defeats the purpose of making the migration easier.

@kimikage
Copy link
Collaborator Author

During the discussion https://discourse.julialang.org/t/rfc-what-should-the-arithmetic-within-the-fixedpointnumbers-be/46697, some cases were mentioned where fixed-point types with bit widths that were not 8, 16 or 32 were used.

It's hard to support those types right now, but they imply that the way to distinguish between signed/unsigned according to the number of bits (i.e. x+y == 8sizeof(T)/1+x+y == 8sizeof(T)) is a bad idea.

Therefore, I am beginning to think that using two letters (i.e. UQxfy/SNxfy) is a better option.

@tthrift
Copy link

tthrift commented Oct 3, 2020

Therefore, I am beginning to think that using two letters (i.e. UQxfy/SNxfy) is a better option.

Personally, I think it declaring S and/or U is a good direction (instead of only implying it with the sum of x and y being 1 bit smaller than the intended width).
We use S in the comments of embedded c code to document signed. [S3, 4] [1, 15] [S31, 0]

WRT scaling fixed point numbers: some people interpret y as a binary/radix point, instead of strictly the number of fractional bits. The value of the binary point having a wider range. It can be negative or larger than the number of bits in the underlying type. This gives more scaling flexibility to the underlying bits being used.

BTW, Thanks for working on fixed point number support for Julia!

@kimikage kimikage added this to the 0.9 milestone Dec 23, 2020
@kimikage kimikage removed this from the 0.9 milestone Apr 6, 2024
@kimikage kimikage added the doc label Apr 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants