float 128 bit

Odpowiedz Nowy wątek
wil
2011-09-16 22:42
wil

Rejestracja: 14 lat temu

Ostatnio: 1 rok temu

0

Jakieś biblioteki do obliczeń z poczwórną precyzją (z 30 cyfr).

Może coś w stylu podwójnych double - jak complex, ale inaczej:
w górnym double mamy liczbę z precyzją 2^-53, czyli 53 bity, a w dolnym drugie 53.

Przykładowo.
double x = 1.0, y = 1e-25, z;

z = x + y; // z = 1; bo w double jest tylko z 15 cyfr, a tu potrzeba 25.

Ale gdy mam dwa double na liczbę, wtedy jest git.

nawet tak może być:
1.0 + 1e-100 = (1, 1e-100); i tyle, nie muszą tego dodawać...

Chodzi o operacje na takich liczbach, żeby można było normalnie obliczać, o tak:

float128 x(1.58878786565454, 4.34544e-16), y(5, 1e-22), z;

x += y;
x++;
z = xx + yy;

z.sqrt(); // chlastamy pierwiastek z precyzją 107 bitów (53*2 + 1).

Taką precyzję ma ten kalkulator z windows (~32 cyfry dziesiętne).

Ja bym spróbował gmp. - Zjarek 2011-09-16 22:49

Pozostało 580 znaków

2011-09-16 22:47
Moderator

Rejestracja: 12 lat temu

Ostatnio: 10 godzin temu

2011-09-16 22:55

Rejestracja: 9 lat temu

Ostatnio: 8 lat temu

1
  1. long double
  2. gmplib.org

Pozostało 580 znaków

wil
2011-09-17 04:49
wil

Rejestracja: 14 lat temu

Ostatnio: 1 rok temu

0

long double jest za krótkie - z 19 cyfr zaledwie.

A te biblioteki są na oparte na całkowitoliczbowych manipulacjach - jakby emulatory FPU?

Takie coś będzie chyba strasznie wolne...
To tak jakby np. mnożyć dwa double: 8 bajtów i 53 bity precyzji, bez koprocesora.
Pewnie z 50 razy wolniej wyjdzie, średnio licząc - arytmetyka, a funkcje ln, exp, sin,... znacznie gorzej.

Używając tej reprezentacji za pomocą dwóch double (czy nawet kilku) mogę używać FPU, np. obliczenie pierwiastka:
procesor obliczy szybko 53 bity (nawet 64, ale to jest zbyteczne), a potem tylko to sobie doprecyzowujemy - wystarczy jeden krok algorytmu Newtona!
Podobnie inne funkcje załatwiamy.

Natomiast proste operacje arytm. będą realizowane z 4 razy dłużej, nie 20, czy 50, bo tu używamy FPU.
Koprocesory numeryczne znacznie szybciej takie rzeczy robią, bo przecież były latami doskonalone specjalnie w celu wykonywania tylko takich operacji.

Pozostało 580 znaków

2011-09-17 07:25
Moderator

Rejestracja: 12 lat temu

Ostatnio: 10 godzin temu

0

To skoro wiesz to po co się pytasz? Podaliśmy ci rozwiązanie dla liczb praktycznie nieskończenie dużych jeśli chodzi o zmiennoprzecinkowe i całkowite. Więc w czym problem?


Pozostało 580 znaków

2011-09-17 10:21

Rejestracja: 8 lat temu

Ostatnio: 7 godzin temu

1

Jak zwykle kłania się Wujek Google albo bardziej precyzyjnie Wikipedia:

http://en.wikipedia.org/wiki/[...]ecision_floating-point_format

gcc: __float128 - 128 bitów
gcc: long double - 128 bitów (tylko na PowerPC, Sparc)
gcc: long double - 80 bitów (x86-64)
intel: long double - 80 bitów (x86-64, /Qlong‑double)
intel: _Quad - 128 bitów

W vc++ nie ma prawdziwego long double, ale można sobie to włączyć (otrzyma się wtedy 80 bitów):
http://baumdevblog.blogspot.c[...]precision-floating-point.html

W gcc znalazłem procedury do obsługi 128-bitowych obliczeń, ale prawdopodobnie wykorzystują one jakieś inne funkcje z gcc:
http://www.opensource.apple.c[...]onfig/rs6000/darwin-ldouble.c

Boost wskazuje jeszcze na NTL:
http://shoup.net/ntl/

(robię ten research bo też zajmuję się numerkami w C++)


Szacuje się, że w Polsce brakuje 50 tys. programistów
edytowany 4x, ostatnio: vpiotr, 2011-09-17 10:43

Pozostało 580 znaków

2011-09-17 11:28

Rejestracja: 8 lat temu

Ostatnio: 6 lat temu

1

Musisz się zastanowić do czego potrzebujesz takich liczb. Jeżeli do kalkulatora o wysokiej precyzji to dostałeś już odpowiedzi. A jak np. potrzebujesz tego do jakiś obliczeń naukowych, to jak brak precyzji zmienia wynik to spróbuj zmienić algorytm na bardziej numerycznie poprawny, dobrze działający na typie double.

Inna kwestia jest w grafice obliczeniowej, tam często żeby stosować szybkie algorytmy musisz mieć dokładne obliczenia nawet z pierwiastkami, więc stosuje się naprawdę skomplikowane typy liczbowe. Możesz o tym poczytać na stronie CGALa, jednej z dwóch dobrych bibliotek do grafiki obliczeniowej (inna jest LEDA, ale koszty jej są ogromne). W grafice 3d stosuje się liczby o zdecydowanie mniejszej precyzji, często mniejszej niż liczby pojedynczej precyzji, ponieważ wydajność się liczy bardziej niż dokładność. Podstawą jest, żeby nie kumulować błędów.

Pozostało 580 znaków

wil
2011-09-17 17:01
wil

Rejestracja: 14 lat temu

Ostatnio: 1 rok temu

0
winerfresh napisał(a)

To skoro wiesz to po co się pytasz? Podaliśmy ci rozwiązanie dla liczb praktycznie nieskończenie dużych jeśli chodzi o zmiennoprzecinkowe i całkowite. Więc w czym problem?

Nie wiem, może jest dobre.
Ile czasu tam trwa mnożenie z precyzją 32 cyfr, czyli ze 110 bitów precyzji?

Zjarek napisał(a)

Musisz się zastanowić do czego potrzebujesz takich liczb. Jeżeli do kalkulatora o wysokiej precyzji to dostałeś już odpowiedzi. A jak np. potrzebujesz tego do jakiś obliczeń naukowych, to jak brak precyzji zmienia wynik to spróbuj zmienić algorytm na bardziej numerycznie poprawny, dobrze działający na typie double.

Głównie do równań różniczkowych.
double jest za krótki w wielu przypadkach.

Np. w symulacji orbit planet wychodzą nieduże błędy r (zgodnie z precyzją double), ale za to błąd fazy jest na poziomie 10^-8, czyli sqrt(1e-16), co znaczy że błąd fazy rośnie z kwadratem czasu obliczeń (bezpośrednio z praw Keplera to wynika).

I tego żaden algorytm nie wyeliminuje - tu błędy są skorelowane ze sobą i tyle.
Dopiero gdy użyjemy liczb z precyzją 10-32, czyli z 32 cyfry, wtedy błąd fazy będzie na poziomie 10-16.

Pozostało 580 znaków

2011-09-17 17:42

Rejestracja: 8 lat temu

Ostatnio: 6 lat temu

1

To możesz spróbować użyć liczb o bardzo dużej precyzji i sprawdzić, czy wydajność jest akceptowalna. Do tego zastanawiałbym się czy taka precyzja jest potrzebna. Mówisz o ruchu planet, ale czy masz odpowiednio dokładne dane oraz czy wszystkie oddziaływania które bierzesz pod uwagę wystarczają na tak dokładne obliczenia. Z drugiej strony równania różniczkowe szczególnie nie lubią złej precyzji.

Pozostało 580 znaków

2011-09-17 17:49

Rejestracja: 17 lat temu

Ostatnio: 1 rok temu

Lokalizacja: Katowice

Tak się troszeczkę pobawiłem gmp i wyszło, że na 3.2 GHz z -O2 mnożenie dwóch liczb mpf_class o precyzji 128 bit milion razy trwa 0.98s, czyli około 1ns na iterację. Taki test to żadna wyrocznia, ale wydaje mi się, że 128 bitów dla gmp to nie problem.


"(...) otherwise, the behavior is undefined".

Pozostało 580 znaków

wil
2011-09-17 20:29
wil

Rejestracja: 14 lat temu

Ostatnio: 1 rok temu

0
Zjarek napisał(a)

To możesz spróbować użyć liczb o bardzo dużej precyzji i sprawdzić, czy wydajność jest akceptowalna. Do tego zastanawiałbym się czy taka precyzja jest potrzebna. Mówisz o ruchu planet, ale czy masz odpowiednio dokładne dane oraz czy wszystkie oddziaływania które bierzesz pod uwagę wystarczają na tak dokładne obliczenia. Z drugiej strony równania różniczkowe szczególnie nie lubią złej precyzji.

W tym przypadku poczwórna precyzja jest koniczna.
Przykładowo: słynna precesja peryhelium Merkurego 570'' / 100 lat,
i w tym jest ponoć około 40'' niezgodne z Newtonem.

Porównajmy to z błędami obliczeń:
40/100 lat < 0.1 / orbitę, orbita to pełny kąt, zatem: 0.1/1296000 < 8e-8;
jak widać na double jest to nierozróżnialne od błędów obliczeń.

Ja używam równań newtona trochę w inny sposób, dokładne obliczenie nie jest taka ważna, ze względu na to, że stan końcowy nie ma znaczenia. Interesuje mnie stan układu podczas obliczeń, głównie efekty zewnętrzne lub uśrednione po wszystkich elementach (np. ciśnienie, temperatura). - Zjarek 2011-09-17 20:50
Precesja orbity jest właśnie takim uśrednionym efektem wpływu innych planet (oraz z ruchu Słońca, który od wieków ignorują w astronomii). - wil 2011-09-19 01:34

Pozostało 580 znaków

Odpowiedz

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