BTC/PLN jak zapisujecie dane

[1911pablo]

Cześć,

W jakim formacie utrzymujecie walute BTC w swoich bazach a w jakim PLN ?

int64 dla BTC a jak PLN ?

Z wiadomego powodu nie pracujemy z double/float - co wybraliście u siebie?

[1911pablo]

Widze, że wszystko owiane tajemnicą Nikt nic nie chce mówić..

No cóż,

u siebie:
BTC trzymam w SATOSHI ( BIGINT )
PLN trzymam w GROSZACH (BIGINT (tu można by zjechać niżej, ale nie widzę na razie z tym problemów ))

w kodzie uint64_t dla satoshi/grosze
Ktoś mnie gdzieś priv pytał o kod

Kod: Zaznacz cały

    // Convert BITCOIN to SATOSHIs
    static uint64_t BTC2SATOSHI(const double& value)
    {
        return static_cast<uint64_t>((value * 1e8 + (value < 0.0 ? -.5 : .5)));
    }
    
    // Convert SATOSHIS to BITCOIN
    static double SATOSHI2BTC(const uint64_t& value)
    {
        return static_cast<double>((value/1e8));
    }
    
    // Convert GROSZE to PLN
    static double GROSZE2PLN(const uint64_t& value)
    {
        return static_cast<double>((value/100));
    }
    
    // Convert PLN to GROSZE
    static uint64_t PLNtoGROSZE(const double& value)
    {
        return static_cast<uint64_t>((value * 100));
    }

[quakociaptockh]

W aplikacjach finansowych standardem jest stosowanie dokładności do czwartego miejsca po przecinku, tzn. jedna dziesięciotysięczna grosza.

[1911pablo]

@quakociaptockh
1. Nie moge Ci odpisac PRV (nie mam tam nawet opcji 'odpisz')
2. Zapis podany przeze mnie powyzej zda calkowicie egzamin - czyz nie?


Ex.

Liczba Satoshi w portfelu:

<MESSAGE,PORTFOLIO,1432560113,0,100000000>

Liczba Groszy w portfelu:

<MESSAGE,PORTFOLIO,1432560103,1500,0>

Kwestia prezentacji tego w stylu user's friendly, to juz inna bajka - pisalem o wewnatrz systemowej interpretacji.


Złożenie orderu

<LIMITORDER, 0.5BTC, 100PLN, 2SELL>

<lo,0.5,100,2>
<MESSAGE,NEWORDER,1432560262,2>
<MESSAGE,YOURORDERS,1432560264,2,50000000,10000,1,2>

[ShadowOfHarbringer]

Pisałem kiedyś pół-profesjonalny silnik giełdy, więc mogę ci odpowiedzieć:
- W bazie Mariadb/MySQL ciągi były zapisane w formacie DECIMAL
- Na liczbach operowałem za pomocą specjalnych funkcji do kalkulacji liczb o dowolnej precyzji (w php BCMath)
- Przy obliczeniach operowałem naturalnie na STRINGach, używanie typów zmiennoprzecinkowych FLOAT/DOUBLE itp jest w finansach surowo zabronione i niebezpieczne, bo takie typy gubią precyzję
- Dla Bitcoinów precyzja wynosiła 16 lub 20 miejsc po przecinku, dla złotówek 4 miejsca po przecinku
- Przy obliczeniach zdaje się że stosowałem dokładność 32 miejsc po przecinku, po czym zaokrąglałem

Oczywiście mój silnik miał mocno przesadzone parametry, zwykle precyzja zmiennoprzecinkowa do 4 miejsc po przecinku dla walut (czyli grosze + 2 miejsca) i 12 miejsc po przecinku dla BTC (czyli do satoshi + 4 miejsca) powinna w zupełności wystarczyć aby nikt nie czuł się pokrzywdzony.

Oczywiście użytkownicy nie widzą pełnej precyzji tylko zaokrągloną, ale obliczenia pod spodem muszą odbywać w odpowiednio większej precyzji, w przeciwnym wypadku prowadzi to do problemów.

[1911pablo]

@ShadowOfHarbringer

nie do konca rozumiem dlaczego dla satoshi masz 12 miejsc po przecinku / dla grosza +2 ?

Przeciez skoro wszystko lecisz w int'ach (operacje dodawania/...) a ostatecznie przedstawiasz wartosci;

btc 0.00000000
pln 0.00

gdzie te dodatkowe miejsca byly ci potrzebne?

[Chancellor]

Przeciez skoro wszystko lecisz w int'ach (operacje dodawania/...)

Jeżeli masz zakup sumy w BTC z 8 miejscami po przecinku po kursie w PLN wyrażonym z dokładnością do 2 miejsc po przecinku, to już masz 10 miejsc po przecinku...

[1911pablo]

Ok, jeszcze raz - albo jest za późno albo nie zrozumiałem.

1) Wszystkie operacje na BTC i PLN dokonywane są na uint64_t (0-18446744073709551615)
gdzie BTC sa liczone jako SATOSHI a PLN jako GROSZE. Czyli skladajac order podajesz liczbe całkowitą w satoshi / groszach.
W bazie trzymam je jako BIGINT(20)

2) Jedyne miejsce w którym widzisz to w postaci liczby po przecinku to end-user-interface w którym :

Zamieniasz ilość SATOSHI ze swojego portfela na BTC via:

Kod: Zaznacz cały

 return static_cast<double>((value/1e8));

Zamieniasz ilość GROSZY ze swojego portfela na ZŁOTÓWKI via:

Kod: Zaznacz cały

return static_cast<double>((value/100));

Gdzie tu możesz coś 'stracić' / 'zyskać' ?


Pytanie czy wygodne jest podawanie przy orderach satoshi/groszy - to inna kwestia ( na systemie tradeują głównie automaty ).

[Chancellor]

To ja też jeszcze raz. Mam na koncie 200 PLN = 20000 groszy. Kupuję 0,12345678 BTC (12345678 satoshi) po 876,54 PLN (87654 grosze). W związku z tym z konta trzeba mi zdjąć – licząc w groszach i satoshi – 12345678 * 87654 / 100000000 = 10821,48059412 groszy. I teraz co robisz, albo zaokrąglasz na korzyść mnie, ucinając część ułamkową, albo zaokrąglasz na korzyść giełdy, odliczając z salda złotówkowego 10822 grosze. Jeżeli już pisałbym w ten sposób, to musiałbym uważnie pamiętać o tym, żeby każdą operację zaokrąglać finalnie na korzyść giełdy.

A to jest dopiero początek kłopotów. Dorzućmy do tego wyliczanie prowizji dla giełdy, albo – nie daj Boże – handel z dźwignią i liczenie opłat...

[ShadowOfHarbringer]

To ja też jeszcze raz. Mam na koncie 200 PLN = 20000 groszy. Kupuję 0,12345678 BTC (12345678 satoshi) po 876,54 PLN (87654 grosze). W związku z tym z konta trzeba mi zdjąć – licząc w groszach i satoshi – 12345678 * 87654 / 100000000 = 10821,48059412 groszy. I teraz co robisz, albo zaokrąglasz na korzyść mnie, ucinając część ułamkową, albo zaokrąglasz na korzyść giełdy, odliczając z salda złotówkowego 10822 grosze. Jeżeli już pisałbym w ten sposób, to musiałbym uważnie pamiętać o tym, żeby każdą operację zaokrąglać finalnie na korzyść giełdy.

A to jest dopiero początek kłopotów. Dorzućmy do tego wyliczanie prowizji dla giełdy, albo – nie daj Boże – handel z dźwignią i liczenie opłat...

Dlatego właśnie zawsze lepiej sobie dodać kilka ekstra miejsc po przecinku, aby nie zaokrąglać w ogóle.

Jeżeli są co najmniej o 2 miejsca po przecinku za dużo, to operacje takie jak mnożenie, dzielenie, pierwiastkowanie i inne złożone działania nie powodują powstania _żadnego_, nawet minimalnego błędu na rachunkach userów.

[rav3n_pl]

Dokładnie, odcinasz 2 miejsca dalej niż "trzeba" i tyle ;]

[grzem]

Zaokrąglania może i da się uniknąć, ale skarg klientów, ze im się nie zgadzają grosze na raportach już nie.

[powered]

Z double i float mogą wyjść różne kwiatki.
No ale jeżeli z góry określimy dokładną precyzję liczby zmiennoprzecinkowej:
w mysql np: decimal(20,12) to żadnych problemów nie będzie pod warunkiem że nie będą zapisywane jakieś ogromne kwoty. Bitcoinów jest 21 milionów więc się zmieszczą wszystkie

[ShadowOfHarbringer]

Z double i float mogą wyjść różne kwiatki.
No ale jeżeli z góry określimy dokładną precyzję liczby zmiennoprzecinkowej:
w mysql np: decimal(20,12) to żadnych problemów nie będzie pod warunkiem że nie będą zapisywane jakieś ogromne kwoty. Bitcoinów jest 21 milionów więc się zmieszczą wszystkie

Zgadza się, ale drobna korekta: typ DECIMAL w bazie danych to nie jest zwykła liczba zmiennoprzecinkowa "FLOAT". To są kompletnie dwie różne rzeczy.
FLOAT gubi dokładność, DECIMAL nie. DECIMAL został stworzony właśnie po to, aby można było przechowywać liczby nie gubiąc żadnej precyzji.

Alternatywnie można też po prostu zapisywać liczby w stringach (w bazie: CHAR, BINARY), ale będzie to wolniejsze od DECIMAL. Celowo pominąłem VARCHARa/VARBINARY, bo są do dupy i nigdzie tego nie używam.

[grzem]

To ja może prościej, na przykładzie:
Klient wystawił zlecenie sprzedaży 1 BTC po 1000 PLN.
Zostało zrealizowane w trzech transakcjach:
30000400 sat
30000400 sat
39999200 sat

Jak ten problem rozwiąże decimal?
Co zobaczy klient (jakie trzy transakcje i jaką sumę) na wyciągu?

[ShadowOfHarbringer]

To ja może prościej, na przykładzie:
Klient wystawił zlecenie sprzedaży 1 BTC po 1000 PLN.
Zostało zrealizowane w trzech transakcjach:
30000400 sat
30000400 sat
39999200 sat

Jak ten problem rozwiąże decimal?
Co zobaczy klient (jakie trzy transakcje i jaką sumę) na wyciągu?

To do mnie pytanie ? Jeżeli tak, to nie rozumiem pytania. Odpowiem inaczej:

W decimalu możesz zapisać te 3 liczby jako
0,30000400 BTC
0,30000400 BTC
0,39999200 BTC

Pełna precyzja będzie zachowana. DECIMAL to tylko sposób zapisu liczb w bazie danych MariaDB/MySQL. Na pewno mówimy o tym samym ?

[grzem]

Odpowiedz zatem na drugie pytanie jeśli nie widzisz problemu.
Klient widzi trzy transakcje i saldo po operacji, jakie?

[ShadowOfHarbringer]

Odpowiedz zatem na drugie pytanie jeśli nie widzisz problemu.
Klient widzi trzy transakcje i saldo po operacji, jakie?

Kod: Zaznacz cały

<?php

$liczba1 = '0.30000400';
$liczba2 = '0.30000400';
$liczba3 = '0.39999200';

$wynik1 = bcadd($liczba1, $liczba2, 12);
$wynik2 = bcadd($wynik1, $liczba3, 12);

var_dump($wynik2);

Wynik:
string(14) "1.000000000000"

Wracając do DECIMALA, w MariaDB musisz utworzyć pole DECIMAL o precyzji 12-znakowej, zdaje się, że to będzie DECIMAL(22,12), gdzie 22 - całkowita liczba znaków, 12 - liczba znaków po przecinku.

[grzem]

Powinno być około 1000 PLN z trzech transakcji.
Klient raczej nie potrzebuje oglądać 12 miejsc, skoro realnie istnieje 8.

[ShadowOfHarbringer]

Powinno być około 1000 PLN z trzech transakcji.

Jakie PLN, ja Ci podaję wynik w BTC.

Klient raczej nie potrzebuje oglądać 12 miejsc, skoro realnie istnieje 8.

Chciałeś realny wynik, a nie to co pokazujemy klientowi.

Wynik jest w pełnej precyzji, a klientowi pokazujemy zaokrąglone.