Rozwiązanie problemu z dostępem do pola w klasie rodzica ze strony klasy dziecka

0

Mam klasę ,,rodzica" gdzie mam zmienną prywatną double price. W klasie dziedziczącej po tej klasie, czyli klasie dziecka, nie mam dostępu do tej zmiennej bezpośrednio, ale mogę ją pobrać lub ustawić za pomocą metod publicznych. Czy w takim przypadku lepiej jest po prostu zostawić tak jak jest, czy lepiej jest ustawić ja jako protected ?

0

Dobrze radze - skasuj to pole.
Naprawdę, nie chcesz wiedzieć jakiego demona przyzywasz, kiedy trzymasz ceny (price) w zmiennych typu double (lub float).

0
jarekr000000 napisał(a):

Dobrze radze - skasuj to pole.
Naprawdę, nie chcesz wiedzieć jakiego demona przyzywasz, kiedy trzymasz ceny (price) w zmiennych typu double (lub float).

Niby dlaczego? Skoro to jest złe, to chcę wiedzieć dlaczego.
A w jaki sposób niby trzymać cenę czegoś w złotówkach, co zawiera też grosze?

2

Decimal. A dlaczego? Floating pointy są niedokładne i już dla trywialnych liczb jak 0.1 potrafią robić cuda. Popatrz sobie na te wyniki: https://ideone.com/KgEIRq
Tłumacz potem komuś w banku czemu nagle zniknęły mu jakieś grosze, albo czemu niektórzy klienci mają więcej niż powinni :D

0
Shalom napisał(a):

Decimal. A dlaczego? Floating pointy są niedokładne i już dla trywialnych liczb jak 0.1 potrafią robić cuda. Popatrz sobie na te wyniki: https://ideone.com/KgEIRq
Tłumacz potem komuś w banku czemu nagle zniknęły mu jakieś grosze, albo czemu niektórzy klienci mają więcej niż powinni :D

To gdzie są te cuda?
https://drive.google.com/open?id=1s2Yq710RxmKsM5tO-sdigYh8cCgBKWiI

1

aaaaaaa xD xD Brak mi słów. Po pierwsze kompilator ci to zoptymalizuje więc takie wypisywanie stałej to idiotyzm. Jak popatrzysz na to co się tam w ogóle wykonało, to w kodzie będzie print true ;]
Odpal ten kod który podałem. Po drugie nawet intellij ci podkreślił ten kod, bo nie wolno tak porównywać floatów. Nie wierzę że to nie jest jakiś troll i zarzutka. Mamy rok 2020, ludzie nie mogą być tacy głupi.

0
Shalom napisał(a):

aaaaaaa xD xD Brak mi słów. Po pierwsze kompilator ci to zoptymalizuje więc takie wypisywanie stałej to idiotyzm. Jak popatrzysz na to co się tam w ogóle wykonało, to w kodzie będzie print true ;]
Odpal ten kod który podałem. Po drugie nawet intellij ci podkreślił ten kod, bo nie wolno tak porównywać floatów. Nie wierzę że to nie jest jakiś troll i zarzutka. Mamy rok 2020, ludzie nie mogą być tacy głupi.

Pytam szczerze, więc nie rozumiem dlaczego od razu wyzywasz mnie od głupków. Widziałem ten kod. Widziałem, że co jakiś czas tak jest, że zaokrągla, ale większość liczb wypisuje normalnie. Ja w tym kodzie dodałbym metodę String.format() do wyświetlania tego.

1

Ja w tym kodzie dodałbym metodę String.format() do wyświetlania tego.

o_O No świetnie, ale chyba rozumiesz że jak zsumujesz wystarczająco dużo liczb bo te błędy będą sie NAKŁADAĆ? Więc formatowanie wyniku nie ma żadnego znaczenia. Widzę ześ niedowiarek to skompiluj sobie:

double x = 0.1;
double sum = 0;
long n = 1000000000L;
for(long i=0;i<n;i++){
    sum+=x;
}
System.out.println(n/10);
System.out.println(sum);
System.out.println(n/10-sum);
System.out.println(sum-n/10);

I zastanów się nad wynikami. Możesz jeszcze podbic sobie n do większych wartości i obserwować co się dzieje.

edit: i jeszcze drugi kod poglądowy, zeby nie było że to tylko problem z zakresem:

        double x = 0.1;
        double errors = 0;
        long n = 10000000000L;
        for(long i=0;i<n;i++){
            double sum = 0;
            for(int j=0;j<10;j++) {
                sum += x;
            }
            errors+=(1-sum);
        }
        System.out.println(errors);

Trzymanie tego zawsze jako grosze w int, bez ułamków (albo jako Decimal, co w sumie do jednego sie sprowadza), nie powoduje żadnych z takich problemów.

1

Jak zaokrąglisz dużo razy (setki faktur), to się może okazać, że na koniec roku nie zgadza się w bilansie 1 grosz. Szukanie tego grosza to czasem bardzo zabawna sprawa. To najdroższe grosze na świecie.

Przy ratach kredytów itp. rozbieżnošci wychodzą jeszcze szybciej.

0
jarekr000000 napisał(a):

Jak zaokrąglisz dużo razy (setki faktur), to się może okazać, że na koniec roku nie zgadza się w bilansie 1 grosz. Szukanie tego grosza to czasem bardzo zabawna sprawa. To najdroższe grosze na świecie.

Przy ratach kredytów itp. rozbieżnošci wychodzą jeszcze szybciej.

Czyli jeśli dobrze rozumiem to banki nie mają pieniędzy zapisanych w double'ach tylko w int'ach albo long'ach ?

1

Albo BigDecimal

2

W czym mają to jedna sprawa. W czym powinny to inna.
BidDecimal, MonetaryAmount to lepsi kandydaci. Int, long też bywa (ale to upierdliwe). Sprawa nie dotyczy tylko banków. Ogólnie każdego software, który liczy pieniadze. Wyjątki to ewentuanie symulacje, prognozy itp.gdzie wyniki obliczeń są z natury przybliżone, nie są operacjami finansowymi.

Poza tym w bankach masz setki systemów. Bazy SQL i COBOL domyślnie robią obliczenia dziesiętnie, stałopozycyjnie. To często ratuje sytuacje...

0 użytkowników online, w tym zalogowanych: 0, gości: 0