-
Notifications
You must be signed in to change notification settings - Fork 185
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
Switch PluralRules to use FixedDecimal #190
Comments
@sffc how do you envision this working?
|
I envision an To implement the conversion, you'd use |
Is there a reason to remove support for |
I don't think so. |
we can compare performance and if the |
It might be nice to remove FromStr for PluralOperands, since we are developing a more thoroughly tested code path for that feature in #270, but I think it's harmless to keep |
Thanks for explaining. Another question: is there a reason that FixedDecimal does not have a way to extract the integer part and the fractional part, but can rather extract only digit-wise? |
This ticket is all about adding a way to convert the FixedDecimal to PluralOperands, which implies separating the integer and fraction part. FixedDecimal is a super simple representation that maps from magnitudes to digits. See #190 (comment):
|
Understood, but that is not quite the answer to my question. I was interested as to why |
This will allow us to convert FixedDecimal representation without loss of precision into PluralOperands, for correct plural selection. For example, a number `25` may sometimes be pluralized differently from `25.0`. Added the benchmarks for the conversion, though without a baseline it is not just as useful yet. (Until we try to reimplement.) See issue unicode-org#190.
What type do you envision that those functions would return?
|
I would use a compatible scale. It is possible to set the internal representation of a FixedDecimal such that the fractional part is zero. Move other internal representation bits to match. I wanted to use this modified FixedDecimal because I'd be able to use the internal structures of FixedDecimal to compute the integer and fractional parts, faster than relying on digit_at to iterate over specific digits.
We could signal an overflow. That said, for purposes of plural rules matching, most of the time only significant digits matter, and the exponents matter less so. It would be a different story for spellout, for example. Either way, overflow is a realistic possibility for FixedDecimal even today, given that digits are stored in an 8-byte array. |
That said, let me check in a benchmark first, then I can do an experiment to figure out if this even makes sense. Top level info that I'd appreciate is whether |
As usual, new APIs should solve problems. I don't see what problem |
If you don't want to widen the API on |
There's really only one algorithm you need, which is:
My mental model has been that this pattern is short and simple enough to put at the call site. It doesn't need its own method in FixedDecimal. |
This will allow us to convert FixedDecimal representation without loss of precision into PluralOperands, for correct plural selection. For example, a number `25` may sometimes be pluralized differently from `25.0`. Added the benchmarks for the conversion, though without a baseline it is not just as useful yet. (Until we try to reimplement.) See issue unicode-org#190.
* Implements From<FixedDecimal> for PluralOperands This will allow us to convert FixedDecimal representation without loss of precision into PluralOperands, for correct plural selection. For example, a number `25` may sometimes be pluralized differently from `25.0`. Added the benchmarks for the conversion, though without a baseline it is not just as useful yet. (Until we try to reimplement.) See issue #190. * Rewrite eq() to branchless * Adds a test for eq() We needed to add a custom implementation for eq() to account for loss of precision in PluralOperands. * fixup:first * Clean up the code for From * Adds more illustrative naming in From * Makes clippy happy * Pulls num_fractional_digits out of the loop It is possible to compute it based on the low end of the magnitude range. No performance change per benchmark. * fixup: benchmark was wrong * fixup: moves new operand tests to json Defines new tests for the data model for conversion, and places them into the JSON files instead of inline with the tests. * fixup: moves the benchmark loop in This allows criterion to run the benchmark loop with a specific time limit. * fixup: formatting * fixup: adds individual sample measurements Helps smoke out specific performance regressions.
Fixed by #278. |
I'm having trouble linking #278 to this issue. Can someone else try? |
I also cannot |
At landing time
PluralRules
create operands from primitive types. We'd like to switch that to supportFixedDecimal
.The text was updated successfully, but these errors were encountered: