Użytkownik "Mariusz Marszałkowski" <b...@N...gazeta.pl> napisał w
wiadomości grup dyskusyjnych:h4h98b$q6j$...@i...gazeta.pl...
> Szczerze to też doznałem szoku. Ale gdy zrozumiałem że tyle samo traci
> "pod górkę" co zyskuje "z górki" to szok minął. :)

Nie, to nie tak. Po prostu algorytm z trapezami (I) i algorytm ze splinami
(II) dają dla danego przedziału (a,b) liczby różne od wyniku analitycznie
otrzymanego U o odpowiednio -epsilon i +epsilon, gdzie epsilon jest funkcją
kroku h. Oczywiście, że dla (0,pi/2) jest trochę np. nadmiar a dla (pi/2,pi)
jest niedomiar w danej metodzie, więc się znosi - to też jest, ale nie o to
chodzi. Chodzi o to, że dwa zupełnie różne algorytmy dają wartość odchylenia
od wyniku takie same co do wartości bezwzględej (z różnicą do około 1%) dla
różnych kroków itd. - tylko znaki są różne. Czyli średnia z obu metod jest
dużo dokładniejsza i błąd jej malej znacznie szybciej niż O(h^2). Patrz
http://drop.io/aqtdw2y - dla małych h, czyli dużych n wynik jest 10 tysięcy
razy dokładniejszy! Błąd jest rzędu O(h^3) - wykres to ładnie prezentuje.

> Nie wiem, dlaczego wtedy jest źle?

Niekoniecznie źle być musi. Po prostu "cały wielki program" liczy y[j+1]
jako funkcję poprzednich y[1],y[2],...,y[j] - całki i takie tam. Możliwe
jest, że y[j] leci do nieskończoności. Biorąc dużo punktów opóźnia się
moment wykrycia takiej rozbieżności - procedura wygładza zachowanie funkcji,
która w pobliżu osobliwości mało przypomina grzeczny wielomian. To trochę
bardziej skomplikowane - bo to i układ równań jest, i jeszcze y jest
zespolone i parę jeszcze zagwozdek po drodze.

slawek