Użytkownik "PK" napisał w wiadomości grup
dyskusyjnych:s...@n...notb-home.
..

>Akurat nie brakuje speców od numeryki, którym wszyscy na tej grupie
>moglibyśmy najwyżej temperować ołówki, a którzy mogliby C od Fortrana

Po pierwsze, to ja używam ołówka automatycznego, wkłady 0.7 mm, nie wymaga
temperowania. Więc nie skorzystam z oferty.

Po drugie, cytując za (wersja on-line jest łatwo dostępna
http://www.nr.com ) "Numerical Recipes Electronic, the on-line version of
the 2007 Third Edition in C++", książce napisanej przez Press'a,
Teukolsky'ego, Vetterling'a i Flannery'ego, wydanej (w postaci książkowej)
przez CUP (chyba Cambridge jest trochę wyżej w rankingach niż większość
polskich uczelni), a która jest powszechnie uznanym podręcznikiem
przeglądowo pokazujących możliwości metod numerycznych, jest napisane na
stronie 157:

"Alas, times do change; with the exception of two of the most modest
formulas ("extended trapezoidal rule," equation 4.1.11, and "extended
midpoint rule," equation 4.1.19; see 4.2), the classical formulas are almost
entirely useless. They are museum pieces, but beautiful ones; we now enter
the museum."

do góry

Użytkownik "bartekltg" napisał w wiadomości grup
dyskusyjnych:k7rnqu$8nd$...@n...news.atman.pl...

>Nie. Schrzanił implementację.

Tzn. co konkretnie?

Jeżeli nie potrafisz wskazać co i jak - to może ty "schrzaniłeś
implementację" - i dlatego masz przewagę Simpsona nad trapezami...???

do góry

Użytkownik "AK" napisał w wiadomości grup
dyskusyjnych:k7t3ao$67k$...@n...task.gda.pl...

>PS: Wlasciwie po Twym poscie powinno z wiadomej strony nastapic milczenie.
> Nie liczylby jednak na to. Te duet (slawek, kenobi) jest wyjatkowo
> odporny na fakty :)

Nareszcie coś do ciebie dotarło - to mianowicie, iż jakiekolwiek twoje chęci
są wyłącznie twoimi chęciami.

Czas poprawić to i owo - zauważyłem coś użytecznego (nie napiszę co, bo i
tak to dla was za trudne, po co męczyć wam mózgi myśleniem) - rzeczywiście
jest pewien problem z /implementacjami/ - nie zastanawiałem się nad tym do
tej pory, a trzeba było. Nie ma to większego wpływu na matematykę problemu,
ale nie mogę wykluczyć, że nie ma wpływu na wyniki - a skoro można zrobić
lepiej, to dlaczego robić gorzej? Chociaż (patrz nieszczęsny epsilon w
okolicy 1E-16) przy 10E4 punktów dokładność nie powinna polecieć dalej niż o
jakieś 3-4 miejsca dziesiętne, czyli za mało aby by itd.

Na razie macie cytat z dzieła uznanych autorytetów (błe nie lubię tak, ale
nie mogłem się powstrzymać) - jest tam coś o jakimś muzeum i ogólnie w
temacie. Poszukajcie sobie w wątku - czasem jednak warto czytać choćby
jakieś e-booki.

Z harcerskim pozdrowieniem dla leśnych dziadków ;)

do góry

Użytkownik "Roman W" napisał w wiadomości grup
dyskusyjnych:4c699929-26e9-484c-a399-c34765287e83@go
oglegroups.com...

>Poprawnie zaimplementowany Simpson (wg.
>http://en.wikipedia.org/wiki/Simpson%27s_rule#Compo
site_Simpson.27s_rule)
>daje wartosc, dla Twoich danych, 0.5022749400837603, czyli >znacznie blizej
>prawdziwej wartosci niz Twoje trapezy.

Primo, nie pisze się zaimków osobowych wielką literą, wyjątek może być dla
czasem w tekstach religijnych.

Secundo, ciekawy sposób stosowania szablonów - wiem, wskaźniki do funkcji
zanikło w C++... (z drugiej strony to ani to, ani to do niczego nie
potrzebne w tak małym przykładzie).

Tertio, popatrzmy co mamy, 1000 przedziałów, 500 przedziałów, czy może 2000
przedziałów? Przedziałów czy węzłów? Ale to chyba nie w tym przyczyna...

Quarto, porównaj z wynikiem "mojego Simpsona" - jeżeli "mój Simpson" był
gorszy niż "moje trapezy", to oznacza że "twój Simpson" jest dokładniejszy
niż "mój Simpson" (bo "mój Simpson" gorszy niż "moje trapezy") - a to
oznacza, że masz inne wyniki dlatego, że masz inny komputer i/lub nie masz
tablicy wartości (czyli liczysz na 80-bitach zamiast na 64-bitach). Spróbuj
najpierw władować wszystkie wartości do tablicy liczb double (tzn. np.
właśnie 1000 liczb, co da 999 przedziałów) - i dopiero potem, po tej
modyfikacji, policz co daje "twój Simpson".

Quinto, jest istotnie pewien problem - Bartek go przeskoczył, bo użył
Matlab'a (tj. nie był świadomy na czym ten problem polega, a Matlab
automatycznie daje w tym konkretnym przypadku - a przynajmniej powinien
dawać - pewną przewagę w dokładności obliczeń). Ja muszę nad tym trochę
popracować. Być może to jest "nieznaczące" - a być może nie. W każdym razie
ładnie wyjaśniałoby, dlaczego metody wielopunktowe są pozornie
dokładniejsze... choć naprawdę są równie (lub nawet mniej) dokładne w
porównaniu z ordynarnym sumowaniem (żadne tam trapezy - zwykła suma).

do góry

Użytkownik "slawek" <h...@s...pl> napisał w wiadomości
news:k7tbmv$6se$1@zeus.man.szczecin.pl...
> Primo, nie pisze się zaimków osobowych wielką literą, wyjątek może być dla
> czasem w tekstach religijnych.

NIe trolluj, choć jak tak ci zależy, mogę pisać o tobie małą literą.

> popracować. Być może to jest "nieznaczące" - a być może nie. W każdym
> razie ładnie wyjaśniałoby, dlaczego metody wielopunktowe są pozornie
> dokładniejsze... choć naprawdę są równie (lub nawet mniej) dokładne w
> porównaniu z ordynarnym sumowaniem (żadne tam trapezy - zwykła suma).

Ordynarne sumowanie dałoby nie gorsze wyniki tylko w przypadku gdyby punkty
miały chaotyczną wartość, ale przeważnie funkcja jest ciągła a nawet gładka
w przeważającej częśći przedziału.

do góry

Użytkownik "slawek" <h...@s...pl> napisał:

> Totalne niezrozumienie problemu: tobie nadal wydaje się, że możesz sam sobie
określać ile razy i w
> jakich "węzłach" wywołasz sobie funkcję f(x). A tym razem problem był i jest taki,
że masz z góry
> zadany ciąg par (x,y), dla ułatwienia x[n] = n * h.

Glupi chamowaty palancie :) To zalozenie to sam sobie wymysliles chyba.

Ale..
Gdybys mial choc troche rozumu to zauwazylbyc, ze w tym przypadku
_tym bardziej_ twoja uber alles metoda trapezow jest do kitu.

Przeciez cale to calkowanie sprowadza sie do tego, ze ty
posrednio twierdzisz iz interpolacja funkcji przez trapezy jest lepsza
(dokladniejsza) niz przez parabole czy wielomiany wyzszego rzedu.
A to bylo, jest i bedzie (poza szczegolnymi przypadkami) g.. prawda.

Przeciez Bartek wyraznie ci pokazal ze metody te (wyzszych stopni)
sa szybciej zbiezne (wystarczy mniejsza liczba punktow do osiagniecia tej samej
dokladnosci) niz przeswietne trapezy.
BTW: W przypadku danych otrzynanych z pomiarow, (a wiec obardzonych
bledem) w ogole nie stosuje sie tego typu interppolacji, ale aproksymacje
i jesli juz "surowymi" wielomianami to przynajmniej poprzez jakis
nawet najprymitywniejsze "wygladzanie" danych (chcby wielomianami Gramma
z - co bardzo wazne - "automatycznyn"/statystycznym doborem stopnia).

Co do twoich ksiezycowych idiotyzmow odnosnie bezkosztowego
"liczenia funkcji" to dwa sa "dwa swiaty":
1. baaardzo kosztowne obliczanie funkcji (patrz planowanie eksperymentu
majace na celu mimalizacje ilosci "probek"). Tu jak najbatdziej
wazne jest aby metoda interpolacyjna/ekstrapolacyjna byla najszybciej
zbiezna. Tu tez trapezy sa do kitu.
2. bezkosztowe liczenie funkcji, ale za to "dosc szybkie". Tak szybkie
ze nie nadazysz z "wyliczaniem" online "poprawek" np do korekcji
przyslowiowego narzedzia skrawajacego dla twoich 10 000 punktow.
Tu _tez_ kluczem jest jak najlepsza zbieznosc metody po to aby
moc maksymalnie zmniejszyc ilosc "probke" przy zachowaniu
zalozonej dokladnosci metody. Tu _tez_(co Bartek
dobitnie na wykresach pokazal) twoje trapezy czy prostokaty
sa w tyle.

PS: Nie twierdze ze kwadratury Newtona-Coatsa sa super.
Nie sa. daleko im do tego.
Chocby dlatego, ze sa nieciagle w wezlach.
Chocby dlatego ze sa interpoplacyjne (a wiec nadaja sie badziej
wlasnei do obliczania calek finkcji o znanej analitycznie postaci).
Ale ta wade maja zarowno trapezy jak i Simpson, 3/8 i wyzsze.
Z tej nie idealnej rodziny, to jednak prostokaty czy trapezy sa gorsze.
PS1: tak naprawde to wiekszosc poruszanych tu rzeczy to prostota i wrecz
podstawy/abc wrecz elementarnej numeryki.
No ale slawki wszelkie musza na nowo udowadniac, ze kolo jest
kwadratowe :( i robic ludziom wode z mozgu.

AK

do góry

Użytkownik "zdumiony" napisał w wiadomości grup
dyskusyjnych:k7tcca$p6a$...@n...news.atman.pl...

>Ordynarne sumowanie dałoby nie gorsze wyniki tylko w przypadku gdyby punkty
>miały chaotyczną wartość, ale przeważnie funkcja jest ciągła a nawet gładka
>w przeważającej częśći przedziału.

Po pierwsze, to funkcja jest fraktalem - tzn. ta funkcja o którą naprawdę
chodzi - czasami jest fraktalem, a czasami gładka. I nie wiadomo kiedy
zechce frelować.

Po drugie, niezłym modelem jest zapis audio PCM przy 44kHz jakieś 5 sekund
jakiegoś wizgotu i szumów - a z tego chcemy policzyć wartość skuteczną i RMS

Czyli bycie funkcją gładką... nie podpada.

Jeszcze raz powtarzam, co na temat jest w literaturze:

http://www.nr.com "Numerical Recipes Electronic, the on-line version of the
2007 Third Edition in C++", Press & Teukolsky & Vetterling & Flannery'ego,
str. 157.:

"Alas, times do change; with the exception of two of the most modest
formulas ("extended trapezoidal rule," equation 4.1.11, and "extended
midpoint rule," equation 4.1.19; see 4.2), the classical formulas are almost
entirely useless. They are museum pieces, but beautiful ones; we now enter
the museum."

I zauważ, że to nie jakaś dyskusja w necie, tylko książka wydana w
angielskim Cambridge, przez tych specjalistów, którym ktoś chciał ołówki
temperować... Jak na poważny podręcznik sformułowanie "almost entirely
useless" jest 1000x mocniejsze niż wszystkie "nei" pisane przez AK czy
dyżurne forumowe trolle. (Niemniej jednak Press et al. mogą się mylić -
nawet ja nie jestem nieomylny (sic/lol) - dlatego drążę temat i może kiedyś
dodrążę się do jakiś konkretnych konkretów.)

do góry

W dniu wtorek, 13 listopada 2012 11:01:15 UTC użytkownik slawek napisał:
> Użytkownik "PK" napisał w wiadomości grup
> Po drugie, cytując za (wersja on-line jest łatwo dostępna
> http://www.nr.com ) "Numerical Recipes Electronic, the on-line version of
> the 2007 Third Edition in C++", książce napisanej przez Press'a,
> Teukolsky'ego, Vetterling'a i Flannery'ego, wydanej (w postaci książkowej)
> przez CUP (chyba Cambridge jest trochę wyżej w rankingach niż większość
> polskich uczelni), a która jest powszechnie uznanym podręcznikiem
> przeglądowo pokazujących możliwości metod numerycznych, jest napisane na
> stronie 157:
>
> "Alas, times do change; with the exception of two of the most modest
> formulas ("extended trapezoidal rule," equation 4.1.11, and "extended
> midpoint rule," equation 4.1.19; see 4.2), the classical formulas are almost
> entirely useless. They are museum pieces, but beautiful ones; we now enter
> the museum."

http://www.lysator.liu.se/c/num-recipes-in-c.html#ba
d

RW

do góry

W dniu wtorek, 13 listopada 2012 11:42:24 UTC uzytkownik slawek napisal:
> Udz?ytkownik "Roman W" napisadz? w wiadomodz?ci grup
> dyskusyjnych:4c699929-26e9-484c-a399-c34765287e83@go
oglegroups.com...
>
> >Poprawnie zaimplementowany Simpson (wg.
> >http://en.wikipedia.org/wiki/Simpson%27s_rule#Compo
site_Simpson.27s_rule)
> >daje wartosc, dla Twoich danych, 0.5022749400837603, czyli >znacznie blizej
> >prawdziwej wartosci niz Twoje trapezy.
>
> Primo, nie pisze sidz? zaimkdz?w osobowych wielkdz? literdz?, wyjdz?tek modz?e
bydz? dla
> czasem w tekstach religijnych.

Robilem to z grzecznosci, ale jezeli ciebie to krepuje, to przestaje.

> Tertio, popatrzmy co mamy, 1000 przedziadz?dz?w, 500 przedziadz?dz?w, czy modz?e
2000
> przedziadz?dz?w? Przedziadz?dz?w czy wdz?zdz?dz?w? Ale to chyba nie w tym
przyczyna...

Moja implementacja uzywa prawie tyle samo wartosci funkcji co twoja (10001 zamiast
10000).
Roznica powinna byc zaniedbywalna, jezeli obie implementacje byly poprawne.

> Quarto, pordz?wnaj z wynikiem "mojego Simpsona" - jedz?eli "mdz?j Simpson" bydz?
> gorszy nidz? "moje trapezy", to oznacza dz?e "twdz?j Simpson" jest dokdz?adniejszy
> nidz? "mdz?j Simpson" (bo "mdz?j Simpson" gorszy nidz? "moje trapezy") - a to
> oznacza, dz?e masz inne wyniki dlatego, dz?e masz inny komputer i/lub nie masz
> tablicy wartodz?ci (czyli liczysz na 80-bitach zamiast na 64-bitach). Sprdz?buj
> najpierw wdz?adowadz? wszystkie wartodz?ci do tablicy liczb double (tzn. np.
> wdz?adz?nie 1000 liczb, co da 999 przedziadz?dz?w) - i dopiero potem, po tej
> modyfikacji, policz co daje "twdz?j Simpson".

OK, point taken: sprawdzilem wersje z tablica (kod ponizej). Wynik jest nadal
0.5022749400837603, czyli praktycznie tyle samo, co analityczny rezultat.

Sorry, masz zla implementacje. Moze sam po swojemu zaimplementuj wersje z Wiki,
a potem pogadamy?

RW

------

Kod:

#include <cmath>
#include <iostream>
#include <iomanip>
#include <vector>

double function(double x)
{
return sin(x) * exp(-x);
}

template <class F>
double integrate_simpson(F f, double x0, double x1, size_t k)
{
const size_t n = 2 * k;
const double h = (x1 - x0) / n;
std::vector<double> y(n + 1);
for (size_t j = 0; j <= n; ++j) {
y[j] = f(x0 + j * h);
}
double sum = y[0] + y[n];
for (size_t j = 1; j < k; ++j) {
sum += 2 * y[2 * j];
}
for (size_t j = 1; j <= k; ++j) {
sum += 4 * y[2 * j - 1];
}
return h * sum / 3.0;
}

int main()
{
std::cout << std::setprecision(16) << integrate_simpson(function, 0.0, 5.0, 10000/2)
<< std::endl;
}

do góry

W dniu wtorek, 13 listopada 2012 12:58:58 UTC użytkownik Roman W napisał:
[snip]

Poniewaz w miedzyczasie slawek zmienil zdanie co do liczby punktow ktore
chcial brac w calkowaniu (kod w pierwszym poscie definiowal NPTS jako 10000,
a teraz slawek mowi o braniu 1000 wartosci), to puscilem swoj kod na 1000
przedzialach. Wynik wynosi teraz 0.5022749400767844, czyli nadal znacznie
dokladniej niz skaszaniona slawkowa implementacja.

Sorry mate.

RW

do góry