Discussion:
Zaokrąglanie w real (double), a extended. FormatFloat('0.000000000000000000000', 0,003 * 5) = 0,01499999999 - A W KALKULATORZE WINDOWS JEST 0,015.
(Wiadomość utworzona zbyt dawno temu. Odpowiedź niemożliwa.)
KatMPBSoft
2012-12-23 20:48:04 UTC
Permalink
Witam,

Mam poważny problem z Delphi 7 i zaokrąglaniem liczb.

Otóż:

FormatFloat('0.000000000000000000000', 0,003 * 5) = 0,01499999999
lub
FormatFloat('0.00', 0,003 * 5) = 0,014

A W KALKULATORZE WINDOWS JEST 0,015 i to jest prawidłowa dana bardzo ważna dla FAKTUR VAT.


Co więcej gdy:
var
a: extended;
b: double; //lub real
begin
a := 0,003 * 5;
b := 0,003 * 5;
end;
To w a jest prawidłowa dana, a w b jest ta błędna;


Jak sobie z tym fantem poradzić.
Wiem mógłbym zmienić wszystko na extended, ale tego zrobić nie mogę bo mój klient ma program z 1000 klientów i 1000 faktur z już ustawionym double.
I teraz wysyłam jemu uaktualnienie i musi być double, bo nie można zmieniać struktury plików.

Poz,
KatMPB
www.katmpbsoft.pl
Arivald
2012-12-23 21:29:59 UTC
Permalink
Post by KatMPBSoft
Witam,
Mam poważny problem z Delphi 7 i zaokrąglaniem liczb.
FormatFloat('0.000000000000000000000', 0,003 * 5) = 0,01499999999
lub
FormatFloat('0.00', 0,003 * 5) = 0,014
A W KALKULATORZE WINDOWS JEST 0,015 i to jest prawidłowa dana bardzo ważna dla FAKTUR VAT.
var
a: extended;
b: double; //lub real
begin
a := 0,003 * 5;
b := 0,003 * 5;
end;
To w a jest prawidłowa dana, a w b jest ta błędna;
Jak sobie z tym fantem poradzić.
Wiem mógłbym zmienić wszystko na extended, ale tego zrobić nie mogę bo mój klient ma program z 1000 klientów i 1000 faktur z już ustawionym double.
I teraz wysyłam jemu uaktualnienie i musi być double, bo nie można zmieniać struktury plików.
Poz,
KatMPB
www.katmpbsoft.pl
Kara za liczenie w zmiennprzecinkowych, zamiast stałoprzecinkowego
Currency ;-)

Pozostaje Ci zaimplementowanie własnych wersji funkcji
Round/Trunc/Floor/Ceil/FormatFloat.
--
Arivald
Przemek O
2012-12-23 22:09:53 UTC
Permalink
Post by KatMPBSoft
Witam,
Mam poważny problem z Delphi 7 i zaokrąglaniem liczb.
Nic nowego, 5sekund z google i jest rozwiązanie. Przecież to znana
przypadłość.
Post by KatMPBSoft
var
a: extended;
b: double; //lub real
begin
a := 0,003 * 5;
b := 0,003 * 5;
end;
To w a jest prawidłowa dana, a w b jest ta błędna;
Jak sobie z tym fantem poradzić.
Po pierwsze czytać dokumentacje ze zrozumieniem, używać typów do tego
przeznaczonych - hint: currency
Post by KatMPBSoft
Wiem mógłbym zmienić wszystko na extended, ale tego zrobić nie mogę bo mój klient ma program z 1000 klientów i 1000 faktur z już ustawionym double.
I teraz wysyłam jemu uaktualnienie i musi być double, bo nie można zmieniać struktury plików.
Wiesz, z doświadczenia wiem że nic nie "musi być", co najwyżej ktoś nie
potrafi/nie chce tego zrobić. Przecież uaktualnienie może zmienić sobie
typ i przekonwertować pliki, co w tym niewykonalnego?

Możesz się bawić w pisanie własnych zaokrągleń jak proponował Arivald,
ale jak znam życie, to to się nie do końca sprawdzi i ten babol i tak
gdzieś wyjdzie w podsumowaniach czy czymkolwiek innym, choć zależy jak
do tego podejdziesz.

I tak na koniec, co to jest tysiąc faktur to przekonwertowania, nawet
tysiąc klientów po tysiąc faktur to nic wielkiego. Jakbym miał takie
podejście to chyba nigdy bym w trakcie życia programu nie zmieniał
struktury bazy/plików.

Ja wybrałbym zmianę typu i rozwiązał problem raz a poprawnie, reszta to
tzw. leczenie syfu pudrem.

pozdrawiam,
Przemek O.
wloochacz
2012-12-23 23:48:46 UTC
Permalink
Post by KatMPBSoft
A W KALKULATORZE WINDOWS JEST 0,015 i to jest prawidłowa dana bardzo ważna dla FAKTUR VAT.
Taaa... kalkulator Windows...
Skoro on taki poprawny to wpisz w nim coś takiego:
2+2*2
i enter
Ile Ci podaje?
Mo właśnie...
Ale!
Jak przełączysz się w tryb "programisty" lub "naukowy" to jest już OK :)

PS.
I to jest przykład na to, że bajery (tu: wynik od razu po wpisaniu
działania i wartości) nie zawsze mają sens...
--
wloochacz
wloochacz
2012-12-23 23:51:05 UTC
Permalink
Post by KatMPBSoft
Witam,
Mam poważny problem z Delphi 7 i zaokrąglaniem liczb.
FormatFloat('0.000000000000000000000', 0,003 * 5) = 0,01499999999
lub
FormatFloat('0.00', 0,003 * 5) = 0,014
A W KALKULATORZE WINDOWS JEST 0,015 i to jest prawidłowa dana bardzo ważna dla FAKTUR VAT.
var
a: extended;
b: double; //lub real
begin
a := 0,003 * 5;
b := 0,003 * 5;
end;
To w a jest prawidłowa dana, a w b jest ta błędna;
To już koledzy wyjaśnili...
Post by KatMPBSoft
Jak sobie z tym fantem poradzić.
Poprawić.
Post by KatMPBSoft
Wiem mógłbym zmienić wszystko na extended,
Źle!
Post by KatMPBSoft
ale tego zrobić nie mogę bo mój klient ma program z 1000 klientów i 1000 faktur z już ustawionym double.
I co z tego?
Post by KatMPBSoft
I teraz wysyłam jemu uaktualnienie i musi być double, bo nie można zmieniać struktury plików.
Przepraszam, jakich plików??
I nawet jeśli są to pliki o jakich myślę, to co to znaczy "nie można"?
Oczywiście, że można - trzeba tylko chcieć.
--
wloochacz
KatMPBSoft
2012-12-23 23:57:02 UTC
Permalink
Dzięki nic nowego się nie dowidziałem (poza wypowiedzią "Przemek"), ale za to utwierdziłem się w moim myśleniu i jego słuszności.

Najprawdopodobniej skorzystam z tego co mówił Arivald, już nawet mam dobre rozwiązanie.
Skorzystam z tego dlatego, bo tylko w jednym unit-cie jest problem, fakt ponad 10 000 linii kodu ale da rade.

Co do rozwiązania: "Przemek", to nigdy tego nie robiłem na plikach binarnych, zawsze update robiłem na bazach danych i dało radę, ale z tymi plikami binarnymi to ciekawe, tylko jakość ogarnąć tego nie mogę.

P.S.: Tak Panowie/Panie Currency, Currency, macie racje.
Arivald
2012-12-24 07:19:27 UTC
Permalink
Post by KatMPBSoft
Dzięki nic nowego się nie dowidziałem (poza wypowiedzią "Przemek"), ale za to utwierdziłem się w moim myśleniu i jego słuszności.
Najprawdopodobniej skorzystam z tego co mówił Arivald, już nawet mam dobre rozwiązanie.
Skorzystam z tego dlatego, bo tylko w jednym unit-cie jest problem, fakt ponad 10 000 linii kodu ale da rade.
Co do rozwiązania: "Przemek", to nigdy tego nie robiłem na plikach binarnych, zawsze update robiłem na bazach danych i dało radę, ale z tymi plikami binarnymi to ciekawe, tylko jakość ogarnąć tego nie mogę.
A w czym problem? W kodzie do konwersji musisz mieć klasę/funcję do
czytania starego formatu, i do zapisywania w nowym. Ja to robię tak że
stary sposób kopiuję i zmieniam mu nazwę (czy to była funkcja czy obiekt).

Potem po prostu czytasz plik w starym formacie, a potem zapisujesz w
nowym. Ważne jest żeby przed zapisem nowego, stary przenieść gdzieś na
tym samym dysku (mv zmienia tylko strukturę katalogów, nie przenosi
zawartości, co jest bardzo szybkie), żeby mieć kopię bezpieczeństwa na
wszelki wypadek.
--
Arivald
KatMPBSoft
2012-12-24 00:05:29 UTC
Permalink
I jeszcze jedno do Waś Państwa:

Bo troszkę zamieszałem i źle zostałem zrozumiały.

Tu bardziej chodzi nie o przechowywanie danych, bo to jest ok, mogą być real, double i inne - sprawdziłem działa dobrze (bo sam się zdenerwowałem).

Tu chodzi o coś takiego:
ShowMessage(FormatFloat('0.000000000000000000000', 0,003 * 5))
= 0,01499999999

Jak zrobić, żeby w Message pokazało się 0,015. - O TO DOKŁADNIE CHODZI.
wloochacz
2012-12-24 00:09:27 UTC
Permalink
Post by KatMPBSoft
Bo troszkę zamieszałem i źle zostałem zrozumiały.
Ale doskonale zostałeś zrozumiany.
Post by KatMPBSoft
Tu bardziej chodzi nie o przechowywanie danych, bo to jest ok
Nie, nie jest OK.
Wpisz dane typu REAL do bazy danych, najlepiej ciut dużo.
Potem wykonaj obliczenia bezpośrednio SQL; obliczenia typu:
Select sum(netto) / count(*) from tabela.

Zapewniam Cię, że będziesz miał podobne problemy...
Post by KatMPBSoft
mogą być real, double i inne - sprawdziłem działa dobrze (bo sam się zdenerwowałem).
Mogą, ale nie powinny być używane do tego celu.
Post by KatMPBSoft
ShowMessage(FormatFloat('0.000000000000000000000', 0,003 * 5))
= 0,01499999999
Jak zrobić, żeby w Message pokazało się 0,015. - O TO DOKŁADNIE CHODZI.
Dostałeś odpowiedź - napisać własną funkcję round.
--
wloochacz
Jan Drawski
2012-12-24 05:47:37 UTC
Permalink
Post by KatMPBSoft
ShowMessage(FormatFloat('0.000000000000000000000', 0,003 * 5))
= 0,01499999999
Jak zrobić, żeby w Message pokazało się 0,015. - O TO DOKŁADNIE CHODZI.
ShowMessage(FormatFloat('0.000', (0.003 * 5) + 0.00001));
--
Pozdrawiam
Jan Drawski
Borneq
2012-12-24 07:22:04 UTC
Permalink
Post by KatMPBSoft
Jak zrobić, żeby w Message pokazało się 0,015. - O TO DOKŁADNIE CHODZI.
Można pomnożyć przez 1000, zaokrąglić, najpierw wyświetlić podzielone
stałoprzecinkowo przez div, co nam da efekt Trunc, potem po przecinku modulo
1000
darekm
2012-12-24 09:49:57 UTC
Permalink
Post by KatMPBSoft
FormatFloat('0.000000000000000000000', 0,003 * 5) = 0,01499999999
lub
FormatFloat('0.00', 0,003 * 5) = 0,014
A W KALKULATORZE WINDOWS JEST 0,015 i to jest prawidłowa dana bardzo ważna dla FAKTUR VAT.
raczej powinno być 0.02, kwoty w Polsce podaje się z dokładnością do
grosza i zaokrągla 0.5 w górę (ale też są takie kwoty które zaokrągla
się inaczej)
Post by KatMPBSoft
var
a: extended;
b: double; //lub real
begin
a := 0,003 * 5;
b := 0,003 * 5;
end;
To w a jest prawidłowa dana, a w b jest ta błędna;
Na fakturze powinno być
a = 0.02
b = 0.02

A teraz zsumuj a+b tab aby wyszło 0.04
Post by KatMPBSoft
Jak sobie z tym fantem poradzić.
Wiem mógłbym zmienić wszystko na extended, ale tego zrobić nie mogę bo mój klient ma program z 1000 klientów i 1000 faktur z już ustawionym double.
I teraz wysyłam jemu uaktualnienie i musi być double, bo nie można zmieniać struktury plików.
Wprowadzić własne funkcje zaokrąglania i wyświetlania liczb. Co więcej
powinny być odrębne dla każdej klasy liczb, tzn odrębne dla ilości,
odrębne dla cen, odrębne dla wartości (i tak dalej, zależne od dziedziny
programu) wtedy nie będzie większym problemem dopasowanie się do
nowego/zmienionego systemu zaokrągleń.
--
Darek
wloochacz
2012-12-24 10:32:54 UTC
Permalink
Post by darekm
raczej powinno być 0.02, kwoty w Polsce podaje się z dokładnością do
grosza i zaokrągla 0.5 w górę (ale też są takie kwoty które zaokrągla
się inaczej)
A kurs waluty jest kwota czy nie?
--
wloochacz
darekm
2012-12-24 12:32:18 UTC
Permalink
Post by wloochacz
Post by darekm
raczej powinno być 0.02, kwoty w Polsce podaje się z dokładnością do
grosza i zaokrągla 0.5 w górę (ale też są takie kwoty które zaokrągla
się inaczej)
A kurs waluty jest kwota czy nie?
w jakim kontekście?
--
Darek
Przemek O
2012-12-24 11:08:35 UTC
Permalink
Post by darekm
Post by KatMPBSoft
Jak sobie z tym fantem poradzić.
Wiem mógłbym zmienić wszystko na extended, ale tego zrobić nie mogę bo
mój klient ma program z 1000 klientów i 1000 faktur z już ustawionym
double.
I teraz wysyłam jemu uaktualnienie i musi być double, bo nie można
zmieniać struktury plików.
Wprowadzić własne funkcje zaokrąglania i wyświetlania liczb. Co więcej
powinny być odrębne dla każdej klasy liczb, tzn odrębne dla ilości,
odrębne dla cen, odrębne dla wartości (i tak dalej, zależne od dziedziny
programu) wtedy nie będzie większym problemem dopasowanie się do
nowego/zmienionego systemu zaokrągleń.
Napisać własne Delphi, lub przynajmniej przepisać "niepasujące" nam
klasy. Dziwne podejście...

MSPANC,
Przemek O.
R.e.m.e.K
2012-12-24 11:37:52 UTC
Permalink
Post by Przemek O
Post by darekm
Wprowadzić własne funkcje zaokrąglania i wyświetlania liczb. Co więcej
powinny być odrębne dla każdej klasy liczb, tzn odrębne dla ilości,
odrębne dla cen, odrębne dla wartości (i tak dalej, zależne od dziedziny
programu) wtedy nie będzie większym problemem dopasowanie się do
nowego/zmienionego systemu zaokrągleń.
Napisać własne Delphi, lub przynajmniej przepisać "niepasujące" nam
klasy. Dziwne podejście...
O ile pamietam z ostatniego (nomen omen) zlotu to chyba u Darka dosc
klasyczne rozwiazanie. Pytanie tylko czy poza jego frameworkiem ma ono sens.
--
pozdro
R.e.m.e.K
darekm
2012-12-24 12:31:14 UTC
Permalink
Post by R.e.m.e.K
Post by Przemek O
Post by darekm
Wprowadzić własne funkcje zaokrąglania i wyświetlania liczb. Co więcej
powinny być odrębne dla każdej klasy liczb, tzn odrębne dla ilości,
odrębne dla cen, odrębne dla wartości (i tak dalej, zależne od dziedziny
programu) wtedy nie będzie większym problemem dopasowanie się do
nowego/zmienionego systemu zaokrągleń.
Napisać własne Delphi, lub przynajmniej przepisać "niepasujące" nam
klasy. Dziwne podejście...
O ile pamietam z ostatniego (nomen omen) zlotu to chyba u Darka dosc
klasyczne rozwiazanie. Pytanie tylko czy poza jego frameworkiem ma ono sens.
Co to ma wspólnego z jakimkolwiek frameworkiem?

To wynika tych samych zasad co generyki: indywidualne typy do każdego
zastosowania.


Jaki jest koszt napisania/używania funkcji

function FormatPrice (x):string;
begin
result:=FormatFloat('0.00', x);
end;

function FormatQuantity (x):string;
begin
result:=FormatFloat('0.0000', x);
end;

Jakie są niepożądane efekty uboczne?

Może któryś z Was odpowie?


Co otrzymujemy w zamian:
w razie gdy program musi wypisywać kwoty bez ułamków (np. liczymy w
jenach) zmieniamy funkcję tylko w jednym miejscu i wiemy że nie będzie
to miało wpływu na wypisywanie ilości, kursów, pomiarów itp.

Chyba że ktoś pracuje na godziny albo cały program mieści się na jednej
kartce papieru, wtedy to oczywiście strzelanie z armaty do muchy.
--
Darek
Arivald
2012-12-24 12:40:27 UTC
Permalink
Post by darekm
Post by R.e.m.e.K
Post by Przemek O
Post by darekm
Wprowadzić własne funkcje zaokrąglania i wyświetlania liczb. Co więcej
powinny być odrębne dla każdej klasy liczb, tzn odrębne dla ilości,
odrębne dla cen, odrębne dla wartości (i tak dalej, zależne od dziedziny
programu) wtedy nie będzie większym problemem dopasowanie się do
nowego/zmienionego systemu zaokrągleń.
Napisać własne Delphi, lub przynajmniej przepisać "niepasujące" nam
klasy. Dziwne podejście...
O ile pamietam z ostatniego (nomen omen) zlotu to chyba u Darka dosc
klasyczne rozwiazanie. Pytanie tylko czy poza jego frameworkiem ma ono sens.
Co to ma wspólnego z jakimkolwiek frameworkiem?
To wynika tych samych zasad co generyki: indywidualne typy do każdego
zastosowania.
Jaki jest koszt napisania/używania funkcji
function FormatPrice (x):string;
begin
result:=FormatFloat('0.00', x);
end;
function FormatQuantity (x):string;
begin
result:=FormatFloat('0.0000', x);
end;
Jakie są niepożądane efekty uboczne?
Może któryś z Was odpowie?
w razie gdy program musi wypisywać kwoty bez ułamków (np. liczymy w
jenach) zmieniamy funkcję tylko w jednym miejscu i wiemy że nie będzie
to miało wpływu na wypisywanie ilości, kursów, pomiarów itp.
Akurat to jest dla mnie WTF. U mnie dla kwot i kursów robi to komponent,
i zmienia zachowanie na podstawie metadanych o walucie. Zmienienie kodu
tylko dlatego że zmienia się waluta, to jest WTF.

A metadane są w bazie, klient może sobie dowolnie je ustawić.
Post by darekm
Chyba że ktoś pracuje na godziny albo cały program mieści się na jednej
kartce papieru, wtedy to oczywiście strzelanie z armaty do muchy.
--
Arivald
darekm
2012-12-24 13:28:32 UTC
Permalink
Post by Arivald
Post by darekm
Post by R.e.m.e.K
Post by Przemek O
Post by darekm
Wprowadzić własne funkcje zaokrąglania i wyświetlania liczb. Co więcej
powinny być odrębne dla każdej klasy liczb, tzn odrębne dla ilości,
odrębne dla cen, odrębne dla wartości (i tak dalej, zależne od dziedziny
programu) wtedy nie będzie większym problemem dopasowanie się do
nowego/zmienionego systemu zaokrągleń.
Napisać własne Delphi, lub przynajmniej przepisać "niepasujące" nam
klasy. Dziwne podejście...
O ile pamietam z ostatniego (nomen omen) zlotu to chyba u Darka dosc
klasyczne rozwiazanie. Pytanie tylko czy poza jego frameworkiem ma ono sens.
Co to ma wspólnego z jakimkolwiek frameworkiem?
To wynika tych samych zasad co generyki: indywidualne typy do każdego
zastosowania.
Jaki jest koszt napisania/używania funkcji
function FormatPrice (x):string;
begin
result:=FormatFloat('0.00', x);
end;
function FormatQuantity (x):string;
begin
result:=FormatFloat('0.0000', x);
end;
Jakie są niepożądane efekty uboczne?
Może któryś z Was odpowie?
w razie gdy program musi wypisywać kwoty bez ułamków (np. liczymy w
jenach) zmieniamy funkcję tylko w jednym miejscu i wiemy że nie będzie
to miało wpływu na wypisywanie ilości, kursów, pomiarów itp.
Akurat to jest dla mnie WTF. U mnie dla kwot i kursów robi to komponent,
i zmienia zachowanie na podstawie metadanych o walucie. Zmienienie kodu
tylko dlatego że zmienia się waluta, to jest WTF.
Nie rozumiesz. Może być odrębny komponent, może być odrębna procedura.
Wszystko jedno aby mieć wyraźnie odznaczone użycia, które w razie
potrzeby łatwo będzie można zidentyfikować i przerobić. Można pobierać
parametry z kontekstu, konfiguracji czy też z bazy danych. Można też na
początek wpisać jako literał
Post by Arivald
A metadane są w bazie, klient może sobie dowolnie je ustawić.
I to jest właściwa rada dla początkującego: aby się pozbyć problemu z
zaokrągleniami zbuduj cały framework do przechowywania i edycji
parametrów wypisywania kwot w bazie tak aby każdy klient mógł sobie je
dowolnie ustawiać, następnie utwórz odpowiednie komponenty które z tego
korzystają i użyj ich w odpowiednich miejscach.
Post by Arivald
Post by darekm
Chyba że ktoś pracuje na godziny albo cały program mieści się na jednej
kartce papieru, wtedy to oczywiście strzelanie z armaty do muchy.
--
Darek
Arivald
2012-12-24 12:34:19 UTC
Permalink
Post by darekm
Post by KatMPBSoft
Jak sobie z tym fantem poradzić.
Wiem mógłbym zmienić wszystko na extended, ale tego zrobić nie mogę bo
mój klient ma program z 1000 klientów i 1000 faktur z już ustawionym
double.
I teraz wysyłam jemu uaktualnienie i musi być double, bo nie można
zmieniać struktury plików.
Wprowadzić własne funkcje zaokrąglania i wyświetlania liczb. Co więcej
powinny być odrębne dla każdej klasy liczb, tzn odrębne dla ilości,
odrębne dla cen, odrębne dla wartości (i tak dalej, zależne od dziedziny
programu) wtedy nie będzie większym problemem dopasowanie się do
nowego/zmienionego systemu zaokrągleń.
Najlepiej to jak by się dało wprowadzić własne typy danych, np.
kwota/kurs. I tak np. typ "kwota" trzymał by reprezentację
stałoprzecinkowo, zaokrąglał odpowiednio, formatował tekst, miał
operatory matematyczne, i miał operatory konwersji do currency/double.

Tyle że w Delphi praca z obiektami jest mocno upośledzona... W C++, C#
czy Javie nowy typ liczbowy wprowadza się bezproblemowo.
--
Arivald
darekm
2012-12-24 13:41:43 UTC
Permalink
Post by Arivald
Post by darekm
Post by KatMPBSoft
Jak sobie z tym fantem poradzić.
Wiem mógłbym zmienić wszystko na extended, ale tego zrobić nie mogę bo
mój klient ma program z 1000 klientów i 1000 faktur z już ustawionym
double.
I teraz wysyłam jemu uaktualnienie i musi być double, bo nie można
zmieniać struktury plików.
Wprowadzić własne funkcje zaokrąglania i wyświetlania liczb. Co więcej
powinny być odrębne dla każdej klasy liczb, tzn odrębne dla ilości,
odrębne dla cen, odrębne dla wartości (i tak dalej, zależne od dziedziny
programu) wtedy nie będzie większym problemem dopasowanie się do
nowego/zmienionego systemu zaokrągleń.
Najlepiej to jak by się dało wprowadzić własne typy danych, np.
kwota/kurs. I tak np. typ "kwota" trzymał by reprezentację
stałoprzecinkowo, zaokrąglał odpowiednio, formatował tekst, miał
operatory matematyczne, i miał operatory konwersji do currency/double.
da się i to lepiej niż myślisz.
wystarczy opakować taki typ prosty w rekord, a potem dodać pożądane
właściwości (metody, przeładowanie operatorów itp). Otrzymujemy dalej
typ prosty bez jakiegokolwiek narzutu obiektu, ani w sensie zajętości
pamięci ani alokacji na stercie,
pełną szybkością jak dla typów prostych
z pełną kontrolą używalności
a w razie potrzeby w pełni wymienialny na podstawowy typ prosty (nie
przewraca całej aplikacji do góry nogami)
Post by Arivald
Tyle że w Delphi praca z obiektami jest mocno upośledzona... W C++, C#
czy Javie nowy typ liczbowy wprowadza się bezproblemowo.
To wprowadź w javie nowy typ z double ( z prymitywu, nie z Double).
--
Darek
k***@wp.pl
2012-12-27 08:08:30 UTC
Permalink
Post by KatMPBSoft
FormatFloat('0.000000000000000000000', 0,003 * 5) = 0,01499999999
lub
FormatFloat('0.00', 0,003 * 5) = 0,014
A W KALKULATORZE WINDOWS JEST 0,015 i to jest prawidłowa dana bardzo ważna
dla FAKTUR VAT.
raczej powinno być 0.02, kwoty w Polsce podaje się z dokładnością do grosza i
zaokrągla 0.5 w górę (ale też są takie kwoty które zaokrągla się inaczej)
Czy widział ktoś poważny naukowy artykuł uzasadniający tezę zaokrąglania 5 w
górę, to nie jest aksiomat.
W większości artykułów, które przejrzałem w internecie jest 5 w górę i pokazane
tak jak w wikipedi http://pl.wikipedia.org/wiki/Zaokr%C4%85glanie i wielu innych
stronach,
poruszane jest zaokrąglanie typu 0,1,2,3,4 w dół, a 5,6,7,8,9 w górę.

Dlaczego wątpliwość?
W Polsce liczy od 1, a nie zera, zera się nie zaokrągla i powyższe rozumowanie
jest wielce wątpliwe.



PS:
Cytat z wikipedi:
"W rachunkowości zaokrąglanie kwot do pełnych złotych polega na tym, że
końcówki kwot wynoszące mniej niż 50 groszy pomija się, a końcówki kwot
wynoszące 50 i więcej groszy podwyższa do pełnych złotych. Sposób ten odpowiada
zaokrąglaniu do najbliższej wartości z powyższej tabeli."
k***@wp.pl
2012-12-27 08:54:46 UTC
Permalink
Post by k***@wp.pl
Czy widział ktoś poważny naukowy artykuł uzasadniający tezę zaokrąglania 5 w
górę, to nie jest aksiomat.
W większości artykułów, które przejrzałem w internecie jest 5 w górę i
pokazane tak jak w wikipedi http://pl.wikipedia.org/wiki/Zaokr%C4%85glanie i
wielu innych stronach,
poruszane jest zaokrąglanie typu 0,1,2,3,4 w dół, a 5,6,7,8,9 w górę.
Znalazłem, norma PN-70/N-O2120 ale normy są płatne (może ktoś ma :-D, lub
dysponuje w miarę tanim (sms) dostępem za normę, pomijając te 3 biblioteki w
kraju)

przykładem problemów i krótkim opisem może być link http://www.bzg.pl/node/52 i
pojawia się coraz więcej wątpliwości co stosować.
Ze sporej liczby linków, wynika (konkluzja) że kiedyś można było zaokrąglać w
górę lub w dół, szukam oficjalnego dokumentu regulującego to (zaokrąglanie
matematyczne 5 w górę).


Artykuł 63 ustawy - Ordynacja podatkowa - odnosi się tylko do podatków, nawet
nie do podstawy podatku tylko do kwot wpłacanych na konta Państwa.
Loading...