sin(...)

0

wie ktos moze dlaczego w delphi5 (nie wiem jak w pozniejszych) fuknkcja sin dla wartosci PI zwraca wartosc :
-5,42101086242752E-20
?? kiedy dla sin(3.14) mamay wynik = 0,00159265291648695 (??)

0

-5,42101086242752E-20
bo to sie rowna prawie zero. Roznica wynika z tego, ze funkcja Pi zwraca wartosc przyblizona
?? kiedy dla sin(3.14) mamay wynik = 0,00159265291648695
bo 3.14 to bardzo kiepskie przyblizenie

0

A wartość sin przyporządkowujesz zmiennej typu Extended? Jeżeli nie, to po prostu brakuje dokładności. Też kiedyś to miałem.

0

wartosc jest przypisywana do extended.
co prawda podziwiam "dokladnosc" obliczen ale w punkcie w ktorym wiadomo ze funkcja ma wartosc 0, wiec powinno byc zwracane zero bez wzgledu na to jakiemu typowi jest ona przypisywana.

0

wartosc jest przypisywana do extended.
co prawda podziwiam "dokladnosc" obliczen ale w punkcie w ktorym wiadomo ze funkcja ma wartosc 0, wiec powinno byc zwracane zero bez wzgledu na to jakiemu typowi jest ona przypisywana.

zero byloby zwracane gdyby Pi bylo dokladne. A nie jest.

0

Więc troszkę oszukaj :)

var
S: Extended;
begin
S := sin(Pi);
ShowMessage(FloatToStrF(S, ffFixed, 7, 8));
end;

A tak w ogóle to może poszukaj na bdn. Może coś o tym jest. Jak nie to zgłoś ten błąd.

0

nie o to chodzi (oszukanie) analizujac funkcje np
1/sin(pi)
powinnienem dostac (co jest zrozumiale blad) a mimo to dostaje wartosci :
-1,84467440737096E19 ( do tego ujemna ?? )
... tak wiec jest to sprzeczne z analiza mat tej funkcji, a to znaczy ze jest to bardzo powazny błada :) ??
dodatkowo ujemna wartosc swiadczy o tym ze sin(pi)

0
  1. zle zapisana wartosc PI w delphi (??)

No to jest chyba oczywiste. Na skonczonej liczbie bitow typu Extended nie mozesz w zaden sposob zapisac dokladnie liczby, ktora ma nieskonczone rozwiniecie i nie daje sie wyrazic jako iloraz innych liczb.

0

odkrywcze :-) ale chodzi mi o to ze nawet jezeli jest to wartosc nieskonczona to jej przyblizenie powinno dawac wartosc rowną 0, dodatkowo skoro daje wartosc mniesza od zera to znaczy ze wpisana wartosc jest wieksza niz wartosc pi a tu juz jest blad przyblizenia jak zloto :-)

oki sprostowanie szybkie :-)
chodzi mi o to ze jezeli wywoluje funkcje sin z argumentem Pi zwracanym przez delphi to powinienem (!!!) dostawac ZERO i koniec :-)

0

Sinus jest wyliczany w troszkę śmieszny (ale sprytny sposób).
Oczywiście jest wykorzystywany szereg (ale oczywiście skończony).
Żeby obliczyć sin lub cos dla dowolnej wartości wystarczy wyznaczyć ją dla przedziału 0..2Pi. Zajmijmy się teraz tylko sinusem (dla kosinusa bedzie analogicznie). sin Pi..2Pi to jest taka sama wartość jak dla 0..Pi tylko z minusem. Wobec tego można wyliczyć jedynie dla tego przedziału sinusa. Dalej możemy ten przedział podzielić na 0..Pi/2, ponieważ sin (Pi - a) = sin (a). Czyli wystarczy policzyć ten mały przedział. Wiedząc, że sin (Pi/2-a) = cos (a) i mając wzór na cos możemy rozpatrywać jedynie przedział 0..Pi/4.
I tak właśnie wyliczane są funkcje trygonometryczne. Dlatego też szybciej wychodzi wyliczenie sin i cos tych samych kątów na raz niż oddzielnie. Ponieważ jest stosowana skończona precyzja (FPU o ile pamiętam operuje jedynie na 80-bitowych danych) to i sinus nie jest idealny. To właśnie różnica pomiędzy matematyką a informatyką. Tutaj są przybliżenia.

0
<font color="green"> wartosc jest przypisywana do extended. co prawda podziwiam "dokladnosc" obliczen ale w punkcie w ktorym wiadomo ze funkcja ma wartosc 0, wiec powinno byc zwracane zero bez wzgledu na to jakiemu typowi jest ona przypisywana. </span>

a wiec tak
funkcje trygonometryczne przez kooporcesor wyliczane są z szeregu maclaurina (czy jakos tak)
i jest to suma ułamków ( nie napisze dokładnie co tam jest bo nie pamiętam), i chodzi o to
że ten szereg daje idealne wyniki przy nieskonczonej liczbie tych ułamków. Ponieważ
kooprocesorek nie moze liczyc bez konca to po pewnej liczbie tych operacji przestaje ,
i nie wylicza tego do konca,
co gorsza tam jest stała liczba tych operacji niezaleznie od wartosci dla której ma on to policzyc,
a w zaleznosci od tego dla jakiej liczby ma to policzyc i dla stałego błedu dla danej
funkcji powinien on to zrobic różna liczbę razy. przez co są liczby dla których
popełniny jest mały błąd a są liczby dla których popełniany jest duży bład.

dodatkowo jest tak ze ten szereg to suma elemetów które są raz dodatnie , raz ujemne,
i dla takiego PI sinus po ssumowaniu tej nieskonczonej liczby elementów będzie wynosił zero ( w przypadku matmy ),
ale kazdy następny element jest mniejszy od poprzedniego ,
i tu czai sie nastepny problem bo jezeli odejmujemy od siebie dwie liczby o róznych 'cechach'
to wtedy kooprocesor wyrównuje ich 'cechy', prze co jedna z 'mantys' (ta która ma mniejsza cechę) traci na dokładności

0

ale i tak uwazam ze powinni zrobic zwracanie 0 :-)

0

<font color="green">oki sprostowanie szybkie
chodzi mi o to ze jezeli wywoluje funkcje sin z argumentem Pi zwracanym przez delphi to powinienem (!) dostawac ZERO i koniec </span>

Nieprawda.. wtedy delphi musiało by mieć jakieś specialne szablony (gotowce), że jak ktoś tak poda, to tak mu wyjdzie - on to liczy na żywo i się nie dziw - matematyka to dziwny przedmiot... nie da się dokładnie wyliczyć, że sin(pi) = 0, bo nie otrzymasz nigdy dokładnej wartości Pi.

0

no dobra wszyscy oczywiscie macie racje i zgadzam sie z tym ... ale i tak powinno byc 0... i koniec [hurra]
pozdrawiam

0

cay problem polega na tym, ze zarowno funkcje sin() i arcsin()/ktora jest uzywana do obliczenia wartosci PI/ sa implementowane jako rozwiniecieMaclauren'a w zerze. Do tego nanalizuje sie jedynie kilka pierwszych najbardziej znaczacych elementow tego nieskonczonego rozwiniecia. Jest bardzo prawdopodobne, ze dokladnosc obliczania pochodnych funkcji wchodzacych w sklad rozwiniecia jest zbyt malaw poblizu zera i stad pojawiaja sie bledy. Nie jest to wynikiem bedu w delphi, ale efektem przyjecia takiego a nie innego algorytmu obliczeniowego. Bardziej zainteresowanym polecam lekture "Metody Numeryczne w Delphi 4" tam to zjawisko jest takze opisane.
[browar]

0

Pozwolilem sobie odblokowac ten temat, bo zaobserwowalem ciekawa rzecz bawiac sie w asm wlasnie z sinusem.
Otoz obliczajac sinus (cosinus takze) w asm z wykorzystaniem koprocesora (fsin, fcos) i wpisujac recznie wartosc pi, otrzymywalem poprawny wynik (0) juz przy wartosci 3.141592653 (czyli 9 miejsc po przecinku). Delphi wyswietla wartosc Pi z dokladoscia do 14 miejsc po przecinku. Wiec cos jednak w Delphi jest nie tak, a nie w sposobie wyliczania (bo raczej wykorzystuje koprocesor, a nie wlasny algorytm).

0

Kolega otrzymał wynik -5,cośtam.
Niedokładność obliczeń ?! Bzdura!
Jakie wartości może przyjąć sinus ? czyżby nie <-1,1> ? Skąd tam -5 ?!

/* -5,xxxe-20, czyli -0,000000000000000000005xxx :) */

// hmm.. no fakt :).. niedopatrzenie.. [nuda]

0

jesli kogos to nadla interesuje to w Delphi 1 :) mamy dla wartosci PI zwroconej przez funkcje PI wartosci sin prawidlowa sin(0)=0 ale jelsi liczyc PI jako 4arctan(1) to otrzymamy sin( 4arctan(1) )= 1,22514845490862E-16, przenoszac sie fo Delphi 5 mamy sytuacje taka jak juz przedstawilem dla wartosci zwroconej przez PI ale dla drugiej metody otrzymamy sin(4*arctan(1))=1,22460635382238E-16... widac delikata roznice. taki sam jak dla D5 mamy wynik w D4 wiecej nie sprawdzalem :)
im wyzej tym dalej od zera :)

ps. zwracam uwage na E :) pozdrawiam

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