Increase Scale for Currency manager for two-digit values

[aka13-404]

Hello, right now the "Scale" field on the currency manager allows 9 as the largest value.
I have not looked into the codebase, but assuming that it is only an input limitation, I would love to have thjje ability to enter more than 9.

Use-case - I want to track my Monero (XMR) transactions. Monero operates with 12 decimals after the comma, so anything less leads to undesired behavior and different non-elegant rounding mistakes.

[vomikan]

Unfortunatly we can't fix it without DB structure change. Initially the scale is integer value stored as X^Y
1
10
100
1 000
10 000
....
1 000 000 000

MAX value for int is 2 147 483 647

[vomikan]

This fix is working for me

INTEGER type affinity in SQLite can hold any assigned integer number (positive or negative) from 1 byte to maximum 8 bytes.

-- Describe CURRENCYFORMATS_V1
CREATE TABLE CURRENCYFORMATS_V1(
CURRENCYID integer primary key
, CURRENCYNAME TEXT COLLATE NOCASE NOT NULL UNIQUE
, PFX_SYMBOL TEXT
, SFX_SYMBOL TEXT
, DECIMAL_POINT TEXT
, GROUP_SEPARATOR TEXT
, UNIT_NAME TEXT COLLATE NOCASE
, CENT_NAME TEXT COLLATE NOCASE
, SCALE integer
, BASECONVRATE numeric
, CURRENCY_SYMBOL TEXT COLLATE NOCASE NOT NULL UNIQUE
);

This fix may be implemented but the DB_Table_Currencyformats_V1.h auto generated.

 *          AUTO GENERATED at 2020-05-04 17:41:56.665000.
 *          DO NOT EDIT!
 */```

[vomikan]

#include <iostream>
#include <cmath>

double round(double r) {
    return (r > 0.0) ? std::floor(r + 0.5) : std::ceil(r - 0.5);
}

double floor_to_zero(double f) {
    return (f > 0.0) ? std::floor(f) : std::ceil(f);
}

double sign(double s) {
    return (s < 0.0) ? -1.0 : 1.0;
}

int frac(double f, int prec) {
    return round((f - floor_to_zero(f)) * prec) * sign(f);
}

int main() {
    double a = 1.2345;
    double b = -34.567;
    std::cout << frac(a, 100) << " " << frac(b, 100) << std::endl; // 23 57
}

[vomikan]

INTEGER type affinity in SQLite can hold any assigned integer number (positive or negative) from 1 byte to maximum 8 bytes.

[vomikan]

MMEX can't handle big values like this:
12345678901234.090
it became the following value:
12345802358024,0898437500000000

Seems we need to restrict entered values on input.

[github-actions]

This issue is stale because it has been open 365 days with no activity. Please update if you want to keep the issue open

[aka13-404]

Well, while nothing has happened, and I guess it's stale, it's still an uncomfortable issue.
I still have rounding errors with my monero balances.

[tactilis]

@aka13-404

Monero operates with 12 decimals after the comma

How many digits would you expect MMEX to handle before the decimal comma?

DDDDDD,dddddddddddd

The above example with 6 before and 12 after exceeds the precision of IEEE 754 double-precision binary floating-point format.

[aka13-404]

Good question.
Right now there are about 18 mil XMR in circulation.
Usually XMR is used for transactions, less freqently for storage.

I have no satisfactory answer to your question.

[vomikan]

In general, the task is not easy.
To increase the bit depth, you will have to store whole and fractional parts separately.

[aka13-404]

Yes, I remember our conversation. I just saw the 1.6.0 release, and decided to bump the issue, since I remembered it again :)
No worries, no hard feelings, no pressure, just a friendly bump that this issue still exists.