On 27.03.2013 09:47, M.M. wrote:
> W dniu środa, 27 marca 2013 08:55:41 UTC+1 użytkownik AK napisał:
>> Nie ! NIE licza tak samo !.
>> Nie w koprocesorach pisze sie programy.
> Albo liczą zawsze tak samo (poza patologią), albo nie. To
> czy program napisze się na kartce papieru, w asemblerze, czy w C++
> nie ma na to wpływu.

W gcc masz np -ffloat-store -fexcess-precision=standard żeby kompilator
trzymał się standardu (wooolne). Natomiast jeżeli chcesz pisać szybki
kod a nie trzymać się kurczowo standardu -funsafe-math-optimizations,
-fassociative-math, -fno-signed-zeros i spółka.

--
Pozdrawiam
Michoo

do góry

Użytkownik "M.M." <m...@g...com> napisał:

>> Nie w koprocesorach pisze sie programy.

>Albo liczą zawsze tak samo (poza patologią), albo nie. To
>czy program napisze się na kartce papieru, w asemblerze,
>czy w C++nie ma na to wpływu.

Otoz ma !.
W szczegolnosci jezyk prpogramowania (jego biblioteka)
w ogole moze nie uzywac koprocesora, a jesli uzywa
(oczywiscie tak jest dzis prawie zawsze - ale tylko prawie
np systemy embedded) to moze go sobie uzywac
w rozny sposob i w roznym stopniu.

AK

do góry

W dniu 2013-03-26 15:41, M.M. pisze:
> W dniu wtorek, 26 marca 2013 14:42:06 UTC+1 użytkownik darekm napisał:
>> W dniu 2013-03-26 12:25, M.M. pisze:
>>
>>> W dniu wtorek, 26 marca 2013 10:21:52 UTC+1 u�ytkownik darekm napisa�:
>>
>>>> W dniu 2013-03-25 19:36, M.M. pisze:
>>
>>>
>>
>>>> Dlaczego funkcj� pow() mia�o by liczy� r�nie dla r�nych argument�w.
>>
>>>> Oczywi�cie mo�na sobie wyobrazi� optymalizacj� (redukcj� do
mno�enia)
>>
>>>> dla wyk�adnika 2,3,4 ... ale dla wi�kszo�ci przypadk�w to b�dzie
>>
>>>> zamieniane na logarytmy (wielomiany itp) st�d problem z zaokr�gleniami.
>>
>>>
>>
>>> Niczego to nie zmienia. Logarytm tez mozna policzyc na mantysie o 2 bity
>>> dluzszej (np. na precyzji 66bitow) i wynik bylby dokladny. Jesli jakis
>>> procesor tego nie robi, to byc moze uzasadnia to moje podejrzenie, ze
>>> dziala dzieki temu troche szybciej. W koncu obliczenia na 66bitach sa
>>> wolniejsze niz na 64.
>
>> Propozycja jest nieefektywna.
> Bo to nie była propozycja.
>
>> r�wnie dobrze mo�esz sobie sam (lub u�ywana biblioteka) zaokr�gli� (albo
>> wystartowa� od 80 lub 128 bit�w) i b�dziesz mia� dok�adnie,
>> i wtedy masz wyb�r: albo szybko (64bity) albo precyzyjnie (80bit�w) albo
>> dok�adnie (80bit�w i na koniec zaokr�glone do 64)
> Czyli teraz z tego że mogę sam sobie zaokrąglić wynika, że
> 2+2=4.0001 jest bardziej dokładne niż 2+2=4 ? Jaja jakieś.
>

Przyjąłeś złą definicję dokładności.
Dokładne mogą być liczby rzeczywiste, w komputerze nie masz takich,
tylko ich zmiennoprzecinkową reprezentację obarczoną określonym błędem (
nie wspominając o ograniczonym zakresie).
Dalej przy prowadzeniu obliczeń równolegle szacujesz błąd (może się
kumulować albo znosić), im bardziej złożone obliczenia tym trudniejsze
szacowanie błędu. Zasady takie same jak np. w miernictwie.

Dalej: dokładna funkcja nie nie tylko taka, która na niektórych
argumentów podaj dokładne wyniki. Zawsze mnie śmieszy tekst księgowych:
"bilans się zupełnie nie zgadza" - bo wychodzi różnica (1000, 1 ...
0.01) Dla księgowych zaokrąglenia są abstrakcją a niedokładnośc to
"wykluczający błąd". Natomiast w obliczeniach przyrodniczych wartości
dokładne praktycznie nie występują, może tylko w zakresie obiektów
policzalnych.

Odchyłka wyniku otrzymanego od teoretycznego nie jest jedynym możliwym
błędem. Równie ważna jest ciągłość wartości funkcji. I Twoje
x=pow(2.0,2.0);
e // odpowiednio mała liczba dodatnia
y=pow(2.0,2.0+e);

i relacja pomiędzy x i y może zostać zachwiana, co może być tragiczne w
skutkach.



>

>
>>>> wa�ny pow�d"?
>>>> je�eli masz
>>>> x = 0;
>>>> y = -x;
>>>> if (x == y) // mo�e przesta�/zacz�� dzia�a�
>>> Niezrozumiales pytania, albo kontekstu. Chodzilo o wazny powod z ktorego
>>> procesor nie moze poprawnie wykonac tego kodu,
>> mo�e tak:
>> bo jest zgodny z IEE754,
> Głupoty. W IEE754 można przechować dokładnie wynik pow(2.0,2.0), to nie
> jest żaden powód, a gdzie dopiero ważny powód.

W IEE754 zero można zapisać na dwa sposoby, póki nie zmienisz standardu
tak będzie.




>
>


--
Darek

do góry

W dniu środa, 27 marca 2013 11:16:03 UTC+1 użytkownik AK napisał:
> Otoz ma !.
> W szczegolnosci jezyk prpogramowania (jego biblioteka)
> w ogole moze nie uzywac koprocesora, a jesli uzywa
> (oczywiscie tak jest dzis prawie zawsze - ale tylko prawie
> np systemy embedded) to moze go sobie uzywac
> w rozny sposob i w roznym stopniu.

Biblioteka, jezyk programowania, kompilator, a nawet
ustawione flagi procesora (jesli takowe flagi procesor ma)
maja wplyw na wyniki obliczen. Ale procesor liczy jak
liczy, albo tak, albo siak, alby wszytkie procesory licza
tak samo, albo kazdy inaczej...
Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Biblioteka, jezyk programowania, kompilator, a nawet
> ustawione flagi procesora (jesli takowe flagi procesor ma)
> maja wplyw na wyniki obliczen. Ale procesor liczy jak
> liczy, albo tak, albo siak, alby wszytkie procesory licza
> tak samo, albo kazdy inaczej...

Po pierwsze. NIE ! Koprocesor liczy tak jak "ty" mu kazes.
Po drugie: zalezy co liczy, bo nie wszytsko jest w standardzie IEEE
scisle wymagane. Tam jest "nieco" rekomendacji jeno.
Np. nikt nikt nie zabroni kompilatorowi liczyc po swojemu sin
(tak jak np czynil\dotychczas) zamiast uzywac x87-ego fsina.
Po drugie: Jezyki programowania, kompilatory, a nawet programisci
moga decydowac nie tylko jak ma liczyc koprocesor (np poprzez flagi),
ale moga tez decydowac o formacie danych typu double
(wiez juz chyba, bo pisalem nieraz - ze MS do chyba 1992-3 roku
mial wlasny format liczb fp. Nawet dzisiaj nie ma zbyt wiele kompilatorow
realizujacy pelny standard IEEE 754 2008).
Czy ten MS-owy kompilator C++ i Fortran-u byl niezgodny ze
standardem C++ i Fortranu 77 ? Ano byl ! MImo ze nei byl zgodny z IEEE 754.

Powtorze wiec jeszcze raz: programy pisz siee w _jezykach programownia_
(i ich standardach/specyfikacjach innych formalizmach) a nie w
standardzie koprocesora.

AK

do góry

W dniu środa, 27 marca 2013 12:39:07 UTC+1 użytkownik AK napisał:

> Po pierwsze. NIE ! Koprocesor liczy tak jak "ty" mu kazes.
> Po drugie: zalezy co liczy, bo nie wszytsko jest w standardzie IEEE
> scisle wymagane. Tam jest "nieco" rekomendacji jeno.
> Np. nikt nikt nie zabroni kompilatorowi liczyc po swojemu sin
> (tak jak np czynil\dotychczas) zamiast uzywac x87-ego fsina.
> Po drugie: Jezyki programowania, kompilatory, a nawet programisci
> moga decydowac nie tylko jak ma liczyc koprocesor (np poprzez flagi),
> ale moga tez decydowac o formacie danych typu double
> (wiez juz chyba, bo pisalem nieraz - ze MS do chyba 1992-3 roku
> mial wlasny format liczb fp. Nawet dzisiaj nie ma zbyt wiele kompilatorow
> realizujacy pelny standard IEEE 754 2008).
> Czy ten MS-owy kompilator C++ i Fortran-u byl niezgodny ze
> standardem C++ i Fortranu 77 ? Ano byl ! MImo ze nei byl zgodny z IEEE 754.
> Powtorze wiec jeszcze raz: programy pisz siee w _jezykach programownia_
> (i ich standardach/specyfikacjach innych formalizmach) a nie w
> standardzie koprocesora.

Nie wiem już co mam odpisać, nie wiem o co się spieramy. Generalnie wiem o
czym piszesz, nie sa to dla mnie nowe rzeczy, a drobiazgowych szczegolow
standardu IEEE754 nigdy sie nie uczylem. Programujac w C/C++ powinienem
znac drobiazgowe szczegoly?
Pozdrawiam




>
>
>
> AK

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Programujac w C/C++ powinienem znac drobiazgowe szczegoly?

Programujac w C++ powinienes olac "cieplym moczem" IEEE itp
bo jak na razie standard C++ _nigdzie_ nie mowi ze fp w C++
ma byc zgodne z IEEE czy czymkolwiek innym.
Moze kiedys tak sie stanie (nie bedzie mnie juz na tym chorym
dwukrzyzykowym swiecie ;) ale "na teraz" nie.
Poniewaz standard C++ nie okresla blizej ani formatu ani "sposobow liczenia"
na fp itp itd, wiec nalezy od nich ZUPELNIE ABSTACHOWAC i stosowac
stare dobre UNIWERSALNE sposoby z EPS i to wcale nie tylko w programach
numerycznych, ale w kazdych ktore zechca z tego fp skorzystac. Tyle.

AK

do góry

On 27.03.2013 14:32, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
>> Programujac w C/C++ powinienem znac drobiazgowe szczegoly?
>
> Programujac w C++ powinienes olac "cieplym moczem" IEEE itp
> bo jak na razie standard C++ _nigdzie_ nie mowi ze fp w C++
> ma byc zgodne z IEEE czy czymkolwiek innym.

static constexpr bool is_iec559;
True if and only if the type adheres to IEC 559 standard.
Meaningful for all floating point types.


--
Pozdrawiam
Michoo

do góry

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

> static constexpr bool is_iec559;
> True if and only if the type adheres to IEC 559 standard.
> Meaningful for all floating point types.

Probuję:
#include <limits>
std::is_iec559 = true;
i albo pisze, ze objecta niet, albo ze nielzia.
No i ?

PS: Doradzam wiec po raz kolejny.
Olac "cieplym m.." i stosowac stare dobre EPS.
AK

do góry

On 27.03.2013 17:08, AK wrote:
> Użytkownik "Michoo" <m...@v...pl> napisał:
>
>> static constexpr bool is_iec559;
>> True if and only if the type adheres to IEC 559 standard.
>> Meaningful for all floating point types.
>
> Probuję:
> #include <limits>
> std::is_iec559 = true;
> i albo pisze, ze objecta niet, albo ze nielzia.
> No i ?

Spróbuj:
std::cout<<std::numeric_limits<long double>::is_iec559<<std::endl;

--
Pozdrawiam
Michoo

do góry