Walkthrough

Introduces new fixed-point decimal types Decimal64, Decimal128, and Decimal256 with arithmetic, scaling, conversion, and formatting APIs; a Knuth-based divider; extensive JMH benchmarks for add/subtract/multiply/divide/round across 128/256-bit types vs BigDecimal; random decimal generators in Rnd; a redesigned NumericException; a small interface addition; and a minor Maven config tweak.

Changes

Sequence Diagram(s)

sequenceDiagram
  participant JMH as JMH Runner
  participant BM as *Decimal256DivideBenchmark*
  participant D256 as Decimal256
  participant KD as DecimalKnuthDivider

  JMH->>BM: invoke decimal256Divide()
  BM->>D256: copyFrom(dividend)
  BM->>D256: divide(divisor, scale, roundingMode)
  D256->>KD: instance().ofDividend(...).ofDivisor(...).divide(...)
  KD-->>D256: sink(quotient, scale)
  D256-->>BM: result
  BM-->>JMH: return result

sequenceDiagram
  participant App as Calling code
  participant NE as NumericException
  participant Sink as CharSink

  App->>NE: NumericException.instance()
  App->>NE: position(0).put("Error: ").put(42).put(' ')
  App->>Sink: new StringSink()
  NE->>Sink: toSink(sink)
  Sink-->>App: "Error: 42 "

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~90 minutes

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Hi, where can I ask questions at the global level? #1565 ? #4504 ? questdb/roadmap#89 ? Or another, or is it ok if i ask here?

I believe your thinking might be the same, but wanted to say hi and double check.

Q: in the task above called "automatic scale", do you mean
a. having the Decimal160 work with a parametric compatible scale, as opposed to current efficient but hardcoded scale? (algo wise; independent on where scale is stored),
b. or do you consider encoding the scale in the value itself, instead of in the column type?

What I mean to ask is are you considering math ops between numbers with different scale?

I'm thinking that potential disadvantages to scale encoded in each value (vs encoded in column type), at bit lengths from 32 to 256, include

• potential math speed & complexity drawbacks between numbers of potentially different scale
• some loss of precision due to storing scale metadata (though at 160 bits & scale <= 32, this loss is minimal)

isn't it? But you would know better, pls lemme know.

Especially since for money in particular (the origin of the business request i saw, may be missing other use cases), they would likely be ok with scale defined at column level, isnt' it?

eg MONEY == DECIMAL38(22) where 38 = precision and 20 = scale,
so sign + 10^18 the integer part (1 trillion USD in Iranian RIAL) + 20 after decimal point, where

on int:     DECIMAL9(4)   → sign + 5 digits before, 4 after decimal point
on long:    DECIMAL19(4)  → sign + 15 digits before, 4 after decimal point
on long128: DECIMAL38(s) 
on long160: DECIMAL47(s)
on long256: DECIMAL76(s) 

or we could use the postgres DECIMAL(p, s) but only accept precision <= 76, what do you think?

Also it was probably considered but double double ie double128 or double160 could be an alternative? Though the encoding scale in value is a drawback.

Alternatively could we emit such types of different widths and scale when fixed for a type as bytecode at runtime like we do for JIT?

[PR Coverage check]

😍 pass : 1927 / 1934 (99.64%)

file detail