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

[BUG] cardinal_t is the worst name #1193

Closed
DenisYaroshevskiy opened this issue Jan 22, 2022 · 5 comments
Closed

[BUG] cardinal_t is the worst name #1193

DenisYaroshevskiy opened this issue Jan 22, 2022 · 5 comments
Labels
bug Something isn't working

Comments

@DenisYaroshevskiy
Copy link
Collaborator

For the second time I expect cardinal_t<T> give me expected_cardinal_t<T>
I mean that's quite confusing rly.
Let's delete it.

@DenisYaroshevskiy DenisYaroshevskiy added the bug Something isn't working label Jan 22, 2022
@jfalcou
Copy link
Owner

jfalcou commented Jan 23, 2022

There is an old issue a out that already. We need something that return scalar cardinal for dcalr and correct cardinal or wide anyway.

Remember I alos want to move fixed from type to NTTP so maybe we can have a deep thought on that at this moment.

@jfalcou
Copy link
Owner

jfalcou commented Jan 23, 2022

Duplicate of #886

@jfalcou jfalcou marked this as a duplicate of #886 Jan 23, 2022
@jfalcou
Copy link
Owner

jfalcou commented Jan 23, 2022

After mulling over it, here's a proposal:

  • remove scalar_cardinal as it is used mostly nowhere and adapt simd_value accordingly
  • remove cardinal_* and use T::size() everywhere it should have been
  • rename T::size() to T::lanes()
  • rename expected/fundamental_cardinal to something based on lanes

By doing this, it also prepare the change to NTTP lanes in wide type.
What do you think of this ?

@DenisYaroshevskiy
Copy link
Collaborator Author

I do not mind size() or lanes().
This will affect quite some usage links but w/e - we agreed that's what we do.
I don't see why we need scalar cardinal.

@jfalcou
Copy link
Owner

jfalcou commented Jan 23, 2022

It was used at one point, then we discard 99% of its use case when we reworked load/store.
We need to rewrite simd_value and it can be eliminated

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants