Użytkownik "Mariusz Marszałkowski" <b...@g...pl> napisał w
wiadomości grup dyskusyjnych:h39a3q$rpe$...@i...gazeta.pl...
> No właśnie ciekawość mnie zżerała i się pobawiłem i przyjrzałem
> dokładniej.
> Wyniki, no cóż, w zależności od całkowanej funkcji. Trapezy czasami

Właśnie dziś rano przypomniałem sobie, co mi nie pasowało z trapezami: dla
funkcji wypukłych (tzn. mamy funkcję rzeczywistą zmiennej rzeczywistej)
ZAWSZE dają nieco za mało. Funkcje sklejane z kawałków wielomianów takich
jak np. a x^3+b x^2 +c x + d niekoniecznie. Co przy funkcji oscylującej:
dla trapezów zawsze niedomiar przez 1/2 okresu i nadmiar przez kolejne 1/2
okresu. A takie cuś powinno generować coś w rodzaju "siły wymuszającej".

> metod. Poniżej wyniki:

Wic w tym, że ja zbieram wyniki z 8 cyframi znaczącymi, a liczę z... 64
bitami, czyli mantysa 52 bity czyli nieco ponad 15 cyfr po przecinku (choć
FPU ma 80 bitów i niektóre rzeczy liczy wewnętrznie nieco dokładniej) . Te
które masz to 10 cyfr, ale w większości - nieznaczących (same zera). Ale
widać że im wyższy stopień tym lepiej - czyli że (teoretycznie) spliny są
dużo lepsze niż trapezy.

Teraz przepisuję procedurę całkowania na nowo - aby była "idiotoodporna" -
dany jest wektor y oraz krok dla x - a całka jest brana od a do b (które są
rzeczywiste): czasem daje to np. a pomiędzy znanymi wartościami, czasem może
to dać np. b poza znanymi y-kami (ekstrapolacja). Do tego patologiczne
sytuacje - gdy np. długość wektora y wynosi 1 - czego nie da się w
konkretnym zastosowaniu ominąć.

Tak to robię, że pomiędzy całkowitymi wartościami a/h oraz b/h jest
całkowanie splinem (które jest gotowe). Ewentualne niedoróbki załatwić ma
kubiczny wielomian (ale już nie spline). Oczywiście - jeżeli da się obliczyć
kubiczny wielomian. Bo jeżeli nie - to parabola. Jeżeli nie parabola - to
kawałek prostej. Jak skończę - to wrócę do dyskusji z konkretnymi danymi
(tzn. "nowa metoda" vs. trapezy vs. dokładna wartość).

slawek