W dniu czwartek, 14 listopada 2013 09:05:04 UTC+1 użytkownik firr napisał:
> W dniu czwartek, 14 listopada 2013 07:55:16 UTC+1 użytkownik Tomasz Kaczanowski
napisał:
>
> > W dniu 2013-11-13 19:29, firr pisze:
>
> >
>
> > > juz pare razy sie zastanawialem cze gdyby
>
> > > zdefiniowac sobie liczbe jako pare integerow
>
> > > licznik i mianownik (najlepiej jako i64
>
> > > a nie i32 bo dla 32 bit chyba szybko mogloby
>
> > > dochodzic do przepelnienia) to czy takie
>
> > > rachunki nie mialyby szansy byc lepszymi
>
> > > od floata/double
>
> >
>
> > >
>
> >
>
> > > zalety sa np takie
>
> >
>
> > >
>
> >
>
> > > 1) jest to szybkie tj arytmetyka calkowita bez dzielenia w wiekszosci operacji
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > To, że jest to arytmetyka całkowita, wcale nie oznacza, że będzie
>
> > szybka, tym bardziej, że trzeba wykonywać dodatkowe operacje.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > > 2) byloby to (poki sie nie wywali z powodu
>
> > > przepelnienia0 scisłe, tj nie traci informacji
>
> >
>
> >
>
> >
>
> > Przepełnienie nastapi szybko przy dodawaniu liczb ułamkowych o różnych
>
> > mianownikach....
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > > 3) pozwala opoznic dzielenie, floaty wykonuja
>
> > > dzielenia z kazdym znakiem / - taka liczba o wiele
>
> > > rzadziej np przy wydruku na ekran reprezentacji dziesietnej
>
> >
>
> >
>
> >
>
> > Dla optymalizacji zamiast dzielenia będzie szukanie najlepszego
>
> > mianownika przy dodawaniu.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > > wady - nie wiem czy to wogole by dzialalo tj
>
> > > boje sie ze szybko by sie przepelniało (ale moze
>
> > > dla i64 nie tak szybko?)
>
> >
>
> >
>
> >
>
> > Tak samo szybko.... (no ciut wolniej)
>
> >
>
> >
>
> >
>
> > > ktos moglby rozwinac jakos ten temat i powiedzic
>
> >
>
> > > cos na temat tej opcji?
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Tak swojego czasu bawiłem się, zabawa przednia, ale jeśli chodzi o
>
> >
>
> > szybkość działań i szybkość przepełnień, to po za miejscem, gdzie takich
>
> >
>
> > operacji potrzebujemy jest to duzo wolniejsze i dodatkowo szybko się
>
> >
>
> > przepełnia.
>
> >
>
> >
>
>
>
> fajnie by bylo wiedziec jednak nieco wiecej
>
> na ten temat, ciekawe na przyklad 1 czy nie ma jednak jakichs przypadkow gdy to by
sie
>
> jednak sprawdzalo 2 jak dzilalalo by np
>
> takie trywialne skracanie ze licznik i mianownik
>
> przesuwamy w prawo o ta sama ilosc bitów,
>
> czy niosloby to jakis wielki blad
>
> na przyklad mamy ulamek
>
>
>
> 10010101011101010100110010100101001001001010101001
>
> / 10010010010001001001010010111111010100001010
>
>
>
> czy po prostu obciacie licznika i mianownika np o 10 bitow nioslo by duzy blad czy
tez tego typu arytmetyka dzialalaby dla realnych zastosowan
>
> (tego typu skracanie jest technicznie o niebo szybsze niz algorytm do dzielenia -
widomo ze
>
> dzielenie jest akcelerowane ale sama istota
>
> tej prostoty tutaj wydaje mi sie ew ciekawa)

mozna tez przemyslec wersje takich liczb z
ruchomym przecinkiem tj mantysa-cecha, ale
ten podstawowy przypadek jest prostszy do
zastanawiania sie jakby to dzialalo,

ogolnie zaleta wydaje mi sie jest taka ze
np jakis dlugi ciag dodawan odejmowan mnozen
i dzielen w takiej reprezentacji jest
fizycznie o wiele prostszy nic na floacie
typu mantysa cecha (jesli to drugie by symulowac
softem to chybbylo by widac) a dzielenie jest
wogole wykluczane, chyba dopiero do momentu
gdy trzeba wypisac reprezentacje dziesietna
na ekranie (?)

do góry

Użytkownik "Tomasz Kaczanowski" <kaczus@dowyciecia_poczta.onet.pl> napisał w
wiadomości news:528485cf$0$2179$65785112@news.neostrada.pl...
>W dniu 2013-11-14 09:03, Robert Winkler pisze:
>> Ale żeby nie było tak pesymistycznie.
>> Jest jedno zastosowanie gdzie stosowanie liczba zmiennoprzecinkowych
>> jest niedopuszczalne i gdzie od dziesięcioleci stosuje się zapis podobny
>> do proponowanego przez ciebie, czyli liczby stałoprzecinkowe,
>> a domeną są finanse.
>> Z tego powody bazy danych, niektóre języki programowania i biblioteki
>> oferują typy danych rodzaju money czy decimal do przechowywania kwot.
>> Przyjmuje się tam jednak stała wartość mianownika,
>> jedną z wielokrotności liczby 10,
>> na przykład 10000, zapewnia to 4 miejsca po przecinku,
>> co wystarczy aby prawidłowo opisać problem zaokrągleń,
>> przy założeniu że minimalną wartością jaką można operować
>> jest cent, grosz lub ich odpowiednik z innych systemów walutowych.
>
> Niestety tak przygotowane liczby nie przydają się aż tak bardzo w
> zastosowaniach finansowych. Bzdurne ograniczenie do 4 liczb po przecinku
> bierze w łeb, gdy zaczynamy działać na więcej niż jednej walucie, a gdy
> dojdą do tego procenty, są wręcz szkodliwe... Dlatego nie wiem do czego
> można stosować przykładowo TCurrency z Delphi nie przydaje się do niczego
> sensownego, ponad proste działania....

Do przechowywania nadaje sie idealnie, co do obliczen, wystarczy minimalnie
wieksza precyzja celem wlasciwej realizacji zaokraglen.

do góry

W dniu czwartek, 14 listopada 2013 09:44:53 UTC+1 użytkownik firr napisał:
> W dniu czwartek, 14 listopada 2013 09:05:04 UTC+1 użytkownik firr napisał:
>
> > W dniu czwartek, 14 listopada 2013 07:55:16 UTC+1 użytkownik Tomasz Kaczanowski
napisał:
>
> >
>
> > > W dniu 2013-11-13 19:29, firr pisze:
>
> >
>
> > >
>
> >
>
> > > > juz pare razy sie zastanawialem cze gdyby
>
> >
>
> > > > zdefiniowac sobie liczbe jako pare integerow
>
> >
>
> > > > licznik i mianownik (najlepiej jako i64
>
> >
>
> > > > a nie i32 bo dla 32 bit chyba szybko mogloby
>
> >
>
> > > > dochodzic do przepelnienia) to czy takie
>
> >
>
> > > > rachunki nie mialyby szansy byc lepszymi
>
> >
>
> > > > od floata/double
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > zalety sa np takie
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > 1) jest to szybkie tj arytmetyka calkowita bez dzielenia w wiekszosci
operacji
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > To, że jest to arytmetyka całkowita, wcale nie oznacza, że będzie
>
> >
>
> > > szybka, tym bardziej, że trzeba wykonywać dodatkowe operacje.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > > 2) byloby to (poki sie nie wywali z powodu
>
> >
>
> > > > przepelnienia0 scisłe, tj nie traci informacji
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Przepełnienie nastapi szybko przy dodawaniu liczb ułamkowych o różnych
>
> >
>
> > > mianownikach....
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > > 3) pozwala opoznic dzielenie, floaty wykonuja
>
> >
>
> > > > dzielenia z kazdym znakiem / - taka liczba o wiele
>
> >
>
> > > > rzadziej np przy wydruku na ekran reprezentacji dziesietnej
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Dla optymalizacji zamiast dzielenia będzie szukanie najlepszego
>
> >
>
> > > mianownika przy dodawaniu.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > > wady - nie wiem czy to wogole by dzialalo tj
>
> >
>
> > > > boje sie ze szybko by sie przepelniało (ale moze
>
> >
>
> > > > dla i64 nie tak szybko?)
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Tak samo szybko.... (no ciut wolniej)
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > > ktos moglby rozwinac jakos ten temat i powiedzic
>
> >
>
> > >
>
> >
>
> > > > cos na temat tej opcji?
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Tak swojego czasu bawiłem się, zabawa przednia, ale jeśli chodzi o
>
> >
>
> > >
>
> >
>
> > > szybkość działań i szybkość przepełnień, to po za miejscem, gdzie takich
>
> >
>
> > >
>
> >
>
> > > operacji potrzebujemy jest to duzo wolniejsze i dodatkowo szybko się
>
> >
>
> > >
>
> >
>
> > > przepełnia.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> >
>
> >
>
> > fajnie by bylo wiedziec jednak nieco wiecej
>
> >
>
> > na ten temat, ciekawe na przyklad 1 czy nie ma jednak jakichs przypadkow gdy to
by sie
>
> >
>
> > jednak sprawdzalo 2 jak dzilalalo by np
>
> >
>
> > takie trywialne skracanie ze licznik i mianownik
>
> >
>
> > przesuwamy w prawo o ta sama ilosc bitów,
>
> >
>
> > czy niosloby to jakis wielki blad
>
> >
>
> > na przyklad mamy ulamek
>
> >
>
> >
>
> >
>
> > 10010101011101010100110010100101001001001010101001
>
> >
>
> > / 10010010010001001001010010111111010100001010
>
> >
>
> >
>
> >
>
> > czy po prostu obciacie licznika i mianownika np o 10 bitow nioslo by duzy blad
czy tez tego typu arytmetyka dzialalaby dla realnych zastosowan
>
> >
>
> > (tego typu skracanie jest technicznie o niebo szybsze niz algorytm do dzielenia -
widomo ze
>
> >
>
> > dzielenie jest akcelerowane ale sama istota
>
> >
>
> > tej prostoty tutaj wydaje mi sie ew ciekawa)
>
>
>
> mozna tez przemyslec wersje takich liczb z
>
> ruchomym przecinkiem tj mantysa-cecha, ale
>
> ten podstawowy przypadek jest prostszy do
>
> zastanawiania sie jakby to dzialalo,
>
>
>
> ogolnie zaleta wydaje mi sie jest taka ze
>
> np jakis dlugi ciag dodawan odejmowan mnozen
>
> i dzielen w takiej reprezentacji jest
>
> fizycznie o wiele prostszy nic na floacie
>
> typu mantysa cecha (jesli to drugie by symulowac
>
> softem to chybbylo by widac) a dzielenie jest
>
> wogole wykluczane, chyba dopiero do momentu
>
> gdy trzeba wypisac reprezentacje dziesietna
>
> na ekranie (?)

tj w sumie dodawanie ulamokow byloby bardziej
zlozone (tez w sumie nie wiem dokladnie jak
kosztowne sa dodawanie udejmowanie mnozenie
rozpisane softem na floatach bo moze nie
az tak - wartoby napisac sobie softowe
symulacje obu wersji) ale za to dodawania
takich rzeczy jak 1/3 + 1/7 bylyby scisle
- wydaje sie to jednak ciekawy pomysl
i szkoda ze nie mam czegos takiegio w typach prostych do popisania na tym i
posprawdzania jak to dziala

do góry

Nie wiem czy dziś w czasach wszechobecnych kalkulatorów,
w szkole podstawowej nadal tego uczą,
ale za moich czasów aby dodać dwa ułamki należało sprowadzić
oba do wspólnego mianownika.
Oznaczało to rozłożenia obu mianowników na czynniki pierwsze,
co wiązało się ze znaczną liczbą bardzo kosztownych czasowo
operacji dzielenia przez wszystkie kolejne liczby pierwsze,
a potem wymnożenie ich przez siebie.
Z prostego dodawania robi się więc bardzo skomplikowana operacja.

/Robert

do góry

W dniu 2013-11-14 09:05, firr pisze:
> fajnie by bylo wiedziec jednak nieco wiecej
> na ten temat, ciekawe na przyklad 1 czy nie ma jednak jakichs przypadkow gdy to by
sie
> jednak sprawdzalo 2 jak dzilalalo by np

Na przykład Derive używa ułamków, tyle że licznik i mianownik nie są
intami a liczbami całkowitymi o dowolnej precyzji. Zaleta - mamy
dokładne obliczenia, przybliżenie dopiero na końcu gdy dzielimy jedno
przez drugie.

do góry

W dniu czwartek, 14 listopada 2013 10:03:01 UTC+1 użytkownik firr napisał:

Z ciekawostek, to moj ulubiony Guile Scheme dostarcza:
- arytmetyki dowolnej precyzji (kiedy wartosc przestaje miescic sie
w rejestrach, po prostu korzysta z zewnetrznej pamieci, dopoki ta sie
nie wyczerpie)
- arytmetyki liczb wymiernych (rowniez dowolnej precyzji).
- arytmetyki liczb zespolonych (w precyzji double)

W swojej implementacji korzysta z biblioteki GNU GMP dla C:
http://gmplib.org/

Dziala to bardzo ladnie, aczkolwiek nigdy nie mierzylem, jakie
to ma implikacje dla wydajnosci. Z jednej strony, nigdy nie mialem
praktycznych problemow z wydajnoscia, ale z drugiej strony raczej
bym sie bal uzywac tego w krytycznych aplikacjach bez przygladania
sie algorytmom numerycznym, z ktorych korzystam (w praktyce wole
wowczas ograniczyc precyzje obliczen)

do góry

W dniu 2013-11-13 19:29, firr pisze:
> juz pare razy sie zastanawialem cze gdyby
> zdefiniowac sobie liczbe jako pare integerow
> licznik i mianownik (najlepiej jako i64
> a nie i32 bo dla 32 bit chyba szybko mogloby
> dochodzic do przepelnienia) to czy takie
> rachunki nie mialyby szansy byc lepszymi
> od floata/double
>
> zalety sa np takie
>
> 1) jest to szybkie tj arytmetyka calkowita bez dzielenia w wiekszosci operacji
> 2) byloby to (poki sie nie wywali z powodu
> przepelnienia0 scisłe, tj nie traci informacji
> 3) pozwala opoznic dzielenie, floaty wykonuja
> dzielenia z kazdym znakiem / - taka liczba o wiele
> rzadziej np przy wydruku na ekran reprezentacji dziesietnej
>
> wady - nie wiem czy to wogole by dzialalo tj
> boje sie ze szybko by sie przepelniało (ale moze
> dla i64 nie tak szybko?)
>
> ktos moglby rozwinac jakos ten temat i powiedzic
> cos na temat tej opcji?

potestuj sobie :), np. w CommonLispie:

CL-USER> (/ 1/33313331783667 (+ 1/3 1/2 4/1234 (* 5/7867562461 4263585/11)))

106794292845614/2977136610572588858592722693

do góry

W dniu 2013-11-14 09:59, Ghost pisze:
[...]
>> Niestety tak przygotowane liczby nie przydają się aż tak bardzo w
>> zastosowaniach finansowych. Bzdurne ograniczenie do 4 liczb po
>> przecinku bierze w łeb, gdy zaczynamy działać na więcej niż jednej
>> walucie, a gdy dojdą do tego procenty, są wręcz szkodliwe... Dlatego
>> nie wiem do czego można stosować przykładowo TCurrency z Delphi nie
>> przydaje się do niczego sensownego, ponad proste działania....
>
> Do przechowywania nadaje sie idealnie, co do obliczen, wystarczy
> minimalnie wieksza precyzja celem wlasciwej realizacji zaokraglen.

Jaka precyzja jest potrzebna to już z reguły wynika z konkretnych
uregulowań prawnych.

--
Paweł Kierski
n...@p...net

do góry

W dniu czwartek, 14 listopada 2013 10:22:37 UTC+1 użytkownik Robert Winkler napisał:
> Nie wiem czy dziś w czasach wszechobecnych kalkulatorów,
>
> w szkole podstawowej nadal tego uczą,
>
> ale za moich czasów aby dodać dwa ułamki należało sprowadzić
>
> oba do wspólnego mianownika.
>
> Oznaczało to rozłożenia obu mianowników na czynniki pierwsze,
>
> co wiązało się ze znaczną liczbą bardzo kosztownych czasowo
>
> operacji dzielenia przez wszystkie kolejne liczby pierwsze,
>
> a potem wymnożenie ich przez siebie.
>
> Z prostego dodawania robi się więc bardzo skomplikowana operacja.
>

chodzi na przyklad o taki przyklad (lub jakies podobne)

x = (1/3 + 3/7 + 15)*5/7

algorytm dzielenia 'binarnego' (tj ten zwykly)
jest chyba dosyc kosztowny (niestety naet nie wiem dokladnie co on tam obejmuje ale
costam
obejmuje) tymszasem wymnozenie tego na ulamkach
daloby jakas spora liczbe ktora jednak albo zmiescilaby sie w i64/i64 albo tez mona
by ja
obciac - a algorytm dzielanie bylby odlozony do
konca (moze nawet jesli ta liczba jest potrzebna
tylko do jakiegos porownania albo do dzielenia ktore ma dac tylko zgrubny wynik (np
jako wspolrzedna calkowita pixela na ekranie mozna by ogole sie bez niego obyc)
na wspolczesnych kompach zreszta calkowite dzielenia sa chyba niezle
podoptymalizowane i
zajmuja dosyc malo (w sumie nie wiem ile mnozen
kosztuje dzielenie na wspolczesnych kompach ale
nie tak wiele - ale jesli chodzi o istote
upraszczania operacji to takie unikanie dzielenia
mogloby byc uzyteczne - jak mysle

co do porownywania to trzebaby porownywac
albo dwie softowe wersje fpu vs ulamki albo
dwie sprzetowe (zrobione na podobnym poziomie)

do góry

On Thu, 14 Nov 2013 10:22:37 +0100, Robert Winkler <n...@n...org>
wrote:

>Nie wiem czy dziś w czasach wszechobecnych kalkulatorów,
>w szkole podstawowej nadal tego uczą,
>ale za moich czasów aby dodać dwa ułamki należało sprowadzić
>oba do wspólnego mianownika.
>Oznaczało to rozłożenia obu mianowników na czynniki pierwsze,
>co wiązało się ze znaczną liczbą bardzo kosztownych czasowo
>operacji dzielenia przez wszystkie kolejne liczby pierwsze,
>a potem wymnożenie ich przez siebie.
>Z prostego dodawania robi się więc bardzo skomplikowana operacja.
>

Chyba naprawde dawno konczyl Pan szkole podstawowa...

A.L.

do góry