W dniu wtorek, 6 listopada 2012 20:06:23 UTC użytkownik slawek napisał:

> Zupełnie szczerze zapytam - to w bankach (polskich?) nie używa się BCD -
>
> tylko zwykłych "floatsów"?!

Zalezy do czego. Do wyceny derywatow, czy nawet rozliczania ich platnosci, wszyscy
normalni ludzie uzywaja double. Bo hedge fund sie nie bedzie czepial, ze dostali
?400,000.02 zamiast ?400,000.01 przelewem. Natomiast do prowadzenia konta pana
Zdzisia pewnie uzywa sie BCD.

RW

do góry

On 06.11.2012 21:03, slawek wrote:
> 2. Nie jest dobra implementacja, w której a = b nie gwarantuje potem a
> == b. Oczywiście to samo dla a = b, c = b, sprawdzamy a == c . Zła
> implementacja - i nawet "protezy" w rodzaju "epsilonowania" każdego
> porównania liczb rzeczywistych niewiele pomagają.

Udajesz, że nie rozumiesz problemu. ;)

Jeżeli a==b i c==b to a==c. Ale jeżeli a, b i c to wyniki trzech różnych
obliczeń których wartością jest ta sama liczba rzeczywista a niektóre
wyniki pośrednie nie są reprezentowane _dokładnie_ w użytym typie danych
otrzymujesz trzy wartości różne binarnie, ale równe logicznie. Od tego
jest "epsilonowanie", żeby w toku obliczeń też były traktowane jako równe.

--
Pozdrawiam
Michoo

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
dyskusyjnych:k7aqdb$2if$...@m...internetia.pl...
> NIE jest, nie trolluj. Już ci podawałem fragment standardu, w którym
> wyraźnie stoi, że DBL_EPSILON zawiera dodatnią różnicę między 1.0 a
> następną wartością reprezentowalną w typie double.

No przecież piszę - że nie jest.

Tzn. że problem nie jest z DBL_EPSILON (jak myślałem na początku) - tylko z
zepsutą arytmetyką na double.

> Jeżeli dokładność jest większa to nie jest to problem, chyba, że

Jest problem. Duży. Po prostu wyniki przestają być przewidywalne i
powtarzalne.

Wystarczy że ten sam program ktoś skompiluje trochę inaczej, ba, może to być
nawet ten sam kompilator ale w nieco nowszej wersji. Raz jest dobrze (bo
miałeś "trochę lepiej") - a potem nagle okaże się, że jednak jest źle (bo
tym razem nie chciało być "trochę lepiej").

do góry

W dniu 2012-11-06 20:49, AK pisze:
> Użytkownik "Roman W" <r...@g...com> napisał:


> 7.Marza mi sie na tej grupie "wojny algorytmiczne" i rozmowy/wojny o
> prawdziwych _merytorycznych_
> problemach i mimo ze nie pamietam juz wzrorow na pierwiastki
> kwadratowe to chetnie podjalbym i dzis
> rekawicę hm.. np. w numerycznuym znajdowaniu pierwiastkow wielomianu
> zespolonego.
> Nie ma _najmniejszego znaczenia_ czy bym przegral lub wygral.
> Wazne ze _znow_ bym sie (i mam nadzieje tez inni tez) czegos
> nauczyl/wyniosl i na chwile zaspokoil
> starczy juz nalog :).

Bywają. Raz na ruski rok, ale są. Ostatnio np były zmagania z pewnym
problemem, któy okazał się simplexem, był wątek o sortowaniu,
gdzie leciały jakieś wyniki. Jak coś ceikawetgo zaproponujesz,
pewnie się ktoś dołączy.

A jak nie, za dwa tygodnie potyczki algorytmiczne;)

> (nie nie!. Algorytm chyba Legurrea wcale _w praktyce_ nie byl
> najlepszy.. ani najszybszy ani
> najstabilniejszy/"najzbiezniejszy". o ! tam to dopiero byla zabawa z
> H-ami i EPS-ami wszelkimi:).
> 8. Wiem ze to marzenie "scietej glowy", a grupa znow utonie w
> "assemblerowych problemach" firow
> i w chamstwie/prymitywizmie tudziez DBL_EPS-ilonowatosci
> "niebieskich" slawkow

Jakoś sobie z nimi radzimy.

pzdr
bartekltg

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
dyskusyjnych:k7bs5k$6o1$...@m...internetia.pl...
> Walnąłeś jak dzik w sosnę. Tu nie potrzeba BCD (chociaż oczywiście można
> je użyć) a jedynie reprezentacji fixed point.

Skoro można - to dlaczego ich nie używać? Zwykłe fixed point z base 2 będą
kłopotliwe. BCD ułatwią sztywne trzymanie się głupawek w rodzaju:
"zaokrąglamy w górę do pełnych 10 gr". I oczywiście CPU ma pełen zestaw
instrukcji obsługujących BCD. Ale oczywiście - można też po prostu zapisywać
wszystko jako zwykły tekst (XML ?!)

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
dyskusyjnych:k7bsn2$97b$...@m...internetia.pl...
> otrzymujesz trzy wartości różne binarnie, ale równe logicznie. Od tego
> jest "epsilonowanie", żeby w toku obliczeń też były traktowane jako równe.

Masz rację.

Jednak ta racja odnosi się do "interpretacji logicznej" (robione z
dokładnością 1%, trzy pomiary 4.02, 4.01, 4.04 są w granicach tolerancji
identyczne).

Mi chodziło o interpretację "formalną" - tj. mam dwie liczby double, jedna
a, druga b, wiem że nie mogą zachodzi jednocześnie ani dwie, ani trzy, z
trzech relacji a > b, a == b, a < b.

Mogę np. sortować "po double". Wiem, że jeżeli a == b w jakimś miejscu
programu oraz gdy c = a, d = b to c == d itd.

Kwestia interpretacji nie jest istotna na tym poziomie abstrakcji. Po prostu
język (C/Algol/cokolwiek) ma operację porównywania "floatsów" - więc
porównywanie "floatsów" jest dobrze określone w danym języku. Wolno je robić
i musi mieć jednoznacznie określone rezultaty - nawet jeżeli nie ma sensu
(jak np. porównywanie liczby chomików z temperaturą w lipcu).

do góry

Użytkownik "slawek" <s...@h...pl> napisał:

>> konstrukcji skutkowalo tym, ze takie ponaglenia w systemie "defBank"
pojawialy sie
>> rzadko...
>
> Zupełnie szczerze zapytam - to w bankach (polskich?) nie używa się BCD - tylko
zwykłych
> "floatsów"?!

A BCD buraku cokolwiek ci gwarantuja ?
Czy _cokolwiek_ gwaranutuje ci dokladne obliczenia w/g nietrywialnych wzorow
gdzie z natury rzeczy mantysa jest ograniczona (chocby niala i 1000) cyfr znaczacych?
Nie gwarantuja tych rzeczy ani bcd ani fixed points ani fp ani nawet decimal.
Owszem np. zwlaszcza decimal baaardzo pomagaja (bo pozwalaja "trzymac"
dokladna reprezentacje dziesietna i wykonywac trywialne dzialania bez bledow),
ale kilka potegowan, z jeden logarytm, kilka malych dzielonek i juz masz kaszane
bo jakis tam bit/digit jednak moze obciac.

PS: Tak sie sklada ze w czasach gdy powstawal Assecowy defBank
to byl sobie skromny Borland TC1.0 (jeszcze 16 bitowy ) w ktorym byl on pisany.
(duze uklony i dzis po latach dla autorow), a taki MS C to byl zupelnie w powijakach
(masa bledow).
(wiesz o tym palancie ze MS mial wtedy jeszze swoj wcale niezgodny z IEEE format fp ?
wiesz ze takie koprocesory Weitek (kiedys potega) tez mialy "swoje" rozwiazania ?)
Cala arytmetyka/"hipoteka" w defBank byla na zwyklym double bo _nie bylo nic innego
do uzycia_. Mysle ze do dzis jest wlasnie na tych samych double (ot zaszlosci).
Jak widac Asseco nie upadlo jakos :) i defBank tez z tego powodu sie nie posypal.
Bo buraku fp trzeba naprawde i po prostu _umiec uzywac_.
Gdy sie to umie i czuje to mozna ich uzywac nawet jako dokladnych integers /80bits
to zawsze wiecej niz wtedy 16/32/ a dzis 64 :)
Ja sie tego nauczylem na wysmiewanej przez ciebie Odrze i mimo ze zaczalem nawet
pisac
nieco (drobiazgi) w Planie to formatu Odrowych fp ani wtedy ani dzis nie znam
(mimo ze "na Odrze" siedzialem cale studia) bo mi to _nigdy do niczego nie bylo
potrzebne_.
No ale ja sie wychowalem na ksiazce Macieja Sysły "Algorytmy optymalizacjiw jezyku
Algol"
gdzie juz w pierwszym algorytmie (simplex) stalo jak byk cos w rodzaju:
if abs(a-b) <= EPS then return
i nie byl zadnego magicznego DBL_EPSILONA

AK

do góry

Użytkownik "Michoo" <m...@v...pl> napisał:

> otrzymujesz trzy wartości różne binarnie, ale równe logicznie. Od tego jest
"epsilonowanie", żeby
> w toku obliczeń też były traktowane jako równe.

Swietnie to ujales. Sedno.

AK

do góry

>
>
> A BCD buraku cokolwiek ci gwarantuja ?
>

żeby sparafrazowac AL 'kolega to chyba powinien jednak siedziec w zoo'

do góry

Użytkownik "slawek" <s...@h...pl> napisał:

> Poczytaj do czego służą liczby BCD - przyda się tobie i twojemu bankowi.

Oj buraczku niedouczony :) /wciaz czekam az przeprosisz Bartka/.
_Co_ niby gwarantuje ci system dzesietny miast dwojkowego ?
Nawet przy tak trywialnnym podzieleniu 1/3.0 ?
Nie bedzie zadnego "obciecia" ?
Jak myslisz ? Moze w tym przypadu zwykle standardowe fp double bedzie lepsze ?
Moze nawet 32-bitowe float bedzie lepsze (dokladniejesze) od twych wybajanych
decimali ?
Hę ?

AK

do góry