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

[C++] Make Decimal representations consistent #29258

Closed
asfimport opened this issue Aug 12, 2021 · 4 comments
Closed

[C++] Make Decimal representations consistent #29258

asfimport opened this issue Aug 12, 2021 · 4 comments

Comments

@asfimport
Copy link

asfimport commented Aug 12, 2021

Right now Decimal128 is represented as two 64-bit integers (in native endian order) and Decimal256 is represented as a std::array (in native endian order). We could make these consistent (presumably there should be no performance impact). It may also make it easier to extract a common base class or other niceties.

Reporter: David Li / @lidavidm
Assignee: Antoine Pitrou / @pitrou

Related issues:

PRs and other links:

Note: This issue was originally created as ARROW-13617. Please see the migration documentation for further details.

@asfimport
Copy link
Author

Yibo Cai / @cyb70289:
Just FYI. I did a superficial investigation of unifying decimal128/256 (ARROW-13439). I abandoned the task as my approach is not very satisfying.
But I do think it's beneficial to combined decimal128/256.

@asfimport
Copy link
Author

David Li / @lidavidm:
Aha, I thought I had seen someone try this before. Thanks for providing the reference.

@asfimport
Copy link
Author

David Li / @lidavidm:
Another reason why this would be good: nominally Decimal is the same as FixedSizeBinary, however, in compute kernels, currently they need separate handling because their scalar representations are different (Decimal vs Buffer). You could imagine trying to work with all these types via util::string_view or const uint8_t*, however, the representation for BasicDecimal128 makes this hard; there is no native-endian representation that we can just create a pointer to. (Well, the fields in BasicDecimal128 are in native-endian order so you can reinterpret_cast a pointer to the right field, but it would be a little cleaner to have both implementations of native_endian_array() return a std::array& instead of a std::array).

@asfimport
Copy link
Author

Antoine Pitrou / @pitrou:
Issue resolved by pull request 12134
#12134

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants