johnad / decimal128 Goto Github PK

Just a quick reminder that it might be necessary to use this library in a multithreaded context for example for accounting software with work split across one core per year.

In that case trivial types like arrays should be preferred over sequences if possible, for example here:

This also avoids memory allocation which might be a bottleneck if done regularly and which is also problematic for long-running processes as it might lead to memory fragmentation.

• == Equality. Specifically, an equality check that ignores significant digits. For equality checks that take significance into account, there is already the === operator.
• != Not Equality.
• + Addition.
• - Subtraction.
• * Multiplication.
• / Division.
• div Integer Division.
• mod Modulo.
• < Less-than.
• <= Less-than-or-equal.
• > Greater-than.
• >= Greater-than-or-equal.

While encoding/decoding and simple import/export from native data types is supported, the basic ability to do math with the library is missing.

These functions cannot resort to simply converting to either float64 or int64 since those types lack both the precision and the needed scale for the math to properly work.

I've started a document that explains, in the context of this library, how significance and rounding should be handled. See https://github.com/JohnAD/decimal128/blob/master/explaining-op-significance.rst I'm not a mathematician and all coments are welcome regarding it.

While I have written some of the (Densely Packed Decimal) DPD code for storing the coefficient, it is far from tested. At the moment, attempts to encode or decode using that technique will raise an error.

See nim-lang/RFCs#308

I'm planning on adding generic decimal type to the standard library and have general approval. As such, this project will very likely disappear (eventually) in deference to that one. I plan on still supporting the ideas of this library, including accurately supporting significance and scale/precision.

As a bonus, I'm going to attempt to support the IEEE spec natively as well: the variable will only use 128bits of RAM instead of the big variant type this one uses.

• newDecimal128(string)
• newDecimal128(int)
• newDecimal128(float)
• add getPrecision
• add getScale
• add setPrecision (returns a new Decimal128)
• add setScale

This issue came from the discussion in issue #1

For each of the newDecimal128([T]) procs, add two optional parameters:

precision to set the absolute precision of the decimal, regardless of what is seen in the incoming number. That is, this will artificially set the number of significant digits. Any value greater than 34 is treated as 34.

scale to set the precision of the decimal, regardless of what is seen in the incoming number, to enable a fixed number of decimal places of the fractional part. This can be a negative number, though that is not a common use of it.

Example:

assert $newDecimal128("43.2") == "43.2"
assert newDecimal128("43.2").getPrecision == 3
assert newDecimal128("43.2").getScale == 1

assert $newDecimal128("43.2", precision=5) == "43.200"
assert newDecimal128("43.2", precision=5).getPrecision == 5
assert newDecimal128("43.2", precision=5).getScale == 3

assert $newDecimal128("43.2", scale=2) == "43.20"
assert newDecimal128("43.2", scale=2).getPrecision == 4
assert newDecimal128("43.2", scale=2).getScale == 2

assert $newDecimal128("43.2", scale=-1) == "4E+1"
assert newDecimal128("43.2", scale=-1).getPrecision == 1
assert newDecimal128("43.2", scale=-1).getScale == -1

Any rounding is based on bankers rounding aka "round-up-to-even".