Significant digit control

[alexforencich]

Seems like fastnum has rescale and quantize operations for moving the decimal point around, with rescale taking an integer and quantize using the exponent of another fastnum type. But, these are both absolute operations relative to the decimal point. It would be useful I think to have some additional operations along similar lines.

Relative shift of the decimal point: basically a fast multiply/divide by 10, like Python's decimal scaleb(). I think this would basically just adjust the exponent without touching the coefficient.

Relative digit shift: more or less the same thing, but applied to the coefficient, like Python's decimal shift().

Integer log10: verilog has $clog2(), which computes ceil(log2(x)) and tells you how many address lines you need for a given number of elements ($clog2(8) == $clog2(7) == 3). Might be useful to have a clog10 that does something similar here, and would be much faster to compute than a true log10. I think this would be ceil(log10(coefficient)) + exponent.

Get number of significant digits: in a similar vein, provide a function which will return the number of significant digits in the coefficient, which will be independent of the exponent. I think this would just be ceil(log10(coefficient)). I guess this is already implemented as digits_count.

Set number of significant digits: provide a function which will rescale the coefficient to provide the specified number of significant digits, fixing the exponent accordingly so the value is the same (aside from potential truncation).

I think most of this would be relatively simple wrappers on top of existing functionality. It's also possible I've missed some stuff in the documentation, and most of this is already doable.

Incidentally, I think you can rework your ln/log10/log2 implementations to split apart the exponent and coefficient and handle those parts separately, which should significantly reduce the number of reduce operations. Basically ln(x*10^y) = ln(x) + y*ln(10). Unless of course I am missing something about the implementation.

[alexforencich]

For an example of where this sort of thing would be useful, here is some code I wrote for displaying values with SI prefixes with a specific resolution:

const SI_PREFIX: &[&str] = &[
    "q", // 0, 10**-30
    "r", // 1, 10**-27
    "y", // 2, 10**-24
    "z", // 3, 10**-21
    "a", // 4, 10**-18
    "f", // 5, 10**-15
    "p", // 6, 10**-12
    "n", // 7, 10**-9
    "μ", // 8, 10**-6
    "m", // 9, 10**-3
    "",  // 10, 10**0
    "k", // 11, 10**3
    "M", // 12, 10**6
    "G", // 13, 10**9
    "T", // 14, 10**12
    "P", // 15, 10**15
    "E", // 16, 10**18
    "Z", // 17, 10**21
    "Y", // 18, 10**24
    "R", // 19, 10**27
    "Q", // 20, 10**30
];

pub fn si_unit_format_d128(mut val: D128, unit: &str, prec: i32) -> String {
    let prefix;

    if val == D128::ZERO || !val.is_finite() {
        prefix = "";
    } else {
        let decade = (val.abs().log10() / D128::THREE)
            .clamp(-D128::TEN, D128::TEN)
            .floor()
            .to_i32()
            .unwrap_or(0);
        prefix = SI_PREFIX[(decade + 10) as usize];
        val = val * D128::TEN.powi(-decade * 3);
        val = val.rescale((decade * 3 - prec) as i16);
    };

    format!("{} {}{}", val, prefix, unit).trim().to_string()
}

The idea is you can call this like si_unit_format(dec128!(0.0012345678), 's', -6) and you'll get a result like 1.235 ms.

The combination of multiply by 10.powi then rescale seems to be the only way to do that right now, but I think it would be a bit nicer to do swap the order and instead set the precision on the base unit and then do something like Python's scaleb() to move the decimal point without changing the precision. The problem with multiplying by 10.powi is that it does not remove digits after the decimal point when moving the decimal point to the right, leaving a bunch of trailing zeros beyond the requested prec.

Also, why is it that powi takes an i32 while rescale takes an i16?

[alexforencich]

Also, it would be nice if there was a way to perform a quantize/decimal point shift operation on something non-finite without having to worry about invalid operations if the initial value was NaN, inf, etc. It turns something that could be a one-liner or easily chained into something that requires a handful of lines of code to skip the operation when one of these corner-cases is potentially in play.

[alexforencich]

Turns out that the fastnum log10 is horribly, horribly, horribly slow. It's much faster to convert to f32 and use the float log10 than it is to use the fastnum log10. But all I need to know is the location of the most significant digit relative to the decimal point, so some sort of integer log10 would probably be a much better solution than converting to floating point. However I have not been able to find a workaround for this so far as it seems like there isn't any way to directly access the scale/exponent.

[neogenie]

@alexforencich

log10 is horribly, horribly, horribly slow

Yes, this is indeed the case, because ultimately, despite all optimizations, we need to compute the logarithm using Taylor series, which is very slow.

However, I don't quite understand the problem. There are several methods that can help:

• .digits() - returns the coefficient.
• .ilog10() - for the coefficient, a rapid method!
• .digits_count() - returns the number of decimal digits in the coefficient, similarly .ilog10() for the coefficient.
• .fractional_digits_count() - returns the exponent (inverted).

You can use something like this:

#[inline(always)]
pub(crate) const fn decimal_power(&self) -> i32 {
    self.digits_count() as i32 - self.cb.get_scale() as i32
}

[alexforencich]

I did try

    let decade =
        ((val.digits_count() as i16 - val.fractional_digits_count()) / 3).clamp(-10, 10);

but this did not return the correct result.

But I just tried it again, and I think the actual problem is related to the divide by three as int / 3 is quite different from floor(float / 3) especially around zero.

But this seems like some of this sort of stuff would be an easy addition to the library because getting it right is slightly nontrivial, especially if it involves messing with internals like digits() and cb.

[alexforencich]

Seems like this works properly:

pub fn si_unit_format_d128(mut val: D128, unit: &str, prec: i16) -> String {
    let prefix;

    if val == D128::ZERO || !val.is_finite() {
        prefix = "";
    } else {
        let decade = ((val.digits_count() as i16 - val.fractional_digits_count() + 29) / 3 - 10)
            .clamp(-10, 10);

        prefix = SI_PREFIX[(decade + 10) as usize];
        val = val * D128::TEN.powi((-decade * 3) as i32);
        val = val.rescale(decade * 3 - prec);
    };

    format!("{} {}{}", val, prefix, unit).trim().to_string()
}