paupino/rust-decimal

The diesel MySQL FromSql<Numeric, Mysql> impl in src/mysql.rs always reads the value as UTF-8 text: let s = std::str::from_utf8(numeric.as_bytes())?; Decimal::from_str(s) diesel keeps the server's native binary type for Numeric when the column or expression is an integer or float type, for example SUM(double_col), COUNT(*) or SELECT 1. Then: a LongLong 42 fails with "A character could not represent a Decimal instance" a Double 1.5 fails with "invalid utf-8" a Long 825307441 (bytes b"1111") silently returns 1111 diesel's own BigDecimal impl branches on value.value_type(); doing the same here would fix it.

float_option::serialize and arbitrary_precision_option::serialize write the inner value directly for Some, without calling serialize_some. Self-describing formats like JSON don't notice, but others lose the value: #[derive(Serialize, Deserialize)] struct Opt { #[serde(with = "rust_decimal::serde::float_option")] value: Option<Decimal>, } let bytes = bincode::serialize(&Opt { value: Some(dec!(1.5)) }).unwrap(); bincode::deserialize::<Opt>(&bytes); // Ok(Opt { value: None }) RON reports "Expected option" instead. str_option already calls serialize_some. Separately, with the serde-str feature also enabled, float_option can't read a JSON number: {"value": 1.5} fails with "invalid type: floating point 1.5". OptionDecimalVisitor::visit_some delegates to Decimal::deserialize, which becomes deserialize_str under serde-str. Because Cargo unifies features, any dependency enabling serde-str breaks this. Calling deserialize_any(DecimalVisitor) there would fix it.

Decode double-rounds values with more than 28 significant digits. The fractional digit groups are added one at a time with checked_add, which rounds at every step: // 99999999999999999999.0000000050000001::numeric (dscale 16), wire bytes as hex let bytes = hex_decode("0009000400000010270f270f270f270f270f0000000013880001"); Decimal::from_sql(&Type::NUMERIC, &bytes); // Ok(99999999999999999999.00000000), expected …00000001 About 0.1% of random canonical inputs are off by one unit in the last place. Accumulating an exact mantissa and rounding once would fix it. Zero loses its scale on encode. Decimal::from_str("0.00") is encoded with dscale 0, so it reads back as 0. PostgreSQL itself keeps dscale for zero. The encoder in src/postgres/common.rs hard-codes scale: 0 for zero; this affects both the postgres-types and diesel paths.

Against a reference suite computed with Python's decimal at 250 digits (the exact result correctly rounded to the representation a Decimal would use), the worst errors on master, in units in the last place, are: Function Worst error sqrt 3 ln 31 log10 30 exp 88 powu 1,203 powd (fractional exponent) 61,576 tan about 8 significant digits sin, cos, tan above 2π no meaningful accuracy The trig functions reduce large arguments with the 28-digit Decimal::TWO_PI, so the error grows with the argument. For example sin(1e20) has no correct digits, and between 1e3 and 1e15 only about 14 digits are correct. ln is off by 19 ulps for ln(1e-28) alone because of the 28-digit LN10 constant. exp accumulates the error in the 28-digit Decimal::E through repeated squaring. Related: #690 (powd).

(-Decimal::ZERO).sqrt(); // None, expected Some(0) (-Decimal::ZERO).ln(); // panics: "Unable to calculate ln for negative numbers", rather than the zero message Negative zero comes out of ordinary operations such as trunc, ceil and multiplication, so this can be hit without constructing -0 directly. sqrt checks is_sign_negative() before is_zero(), and the panic branches of ln and log10 do the same. Checking is_zero() first would fix it.