-
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
atman.pl!wsisiz.edu.pl!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-s
po-a-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
From: "slawek" <s...@h...pl>
Newsgroups: pl.comp.programming
References: <509ee300$0$26682$65785112@news.neostrada.pl>
<k7olf5$rpm$1@news.task.gda.pl> <k7oo6p$3ut$1@news.task.gda.pl>
<50a082a2$0$1301$65785112@news.neostrada.pl>
<k7qgii$cqo$1@news.task.gda.pl>
<f...@g...com>
<k7ujqc$2gh$1@node1.news.atman.pl> <k7ukdi$1nb$1@news.task.gda.pl>
In-Reply-To: <k7ukdi$1nb$1@news.task.gda.pl>
Subject: Re: Simpson vs. Niski Cotes
Date: Wed, 14 Nov 2012 12:02:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Newsreader: Microsoft Windows Live Mail 14.0.8117.416
X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416
Lines: 47
Message-ID: <50a37a59$0$1313$65785112@news.neostrada.pl>
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 62.69.202.124
X-Trace: 1352890969 unt-rea-a-02.news.neostrada.pl 1313 62.69.202.124:63639
X-Complaints-To: a...@n...neostrada.pl
Xref: news-archive.icm.edu.pl pl.comp.programming:200826
[ ukryj nagłówki ]
Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
dyskusyjnych:k7ukdi$1nb$...@n...task.gda.pl...
> :) Kpilem sobie jawnie z jego fortranowych nalecialosci (indeksy od 1) i
> też się "nie kapnął"
> gdzie popełnił gruby błąd.
W Matlabie indeksy idą od?
To jeszcze doucz się, że w Fortanie /można/ mieć indeksy od 0 - tak,
dzisiejszy Fortran jest jednak /trochę/ inny niż kiedyś.
Błąd naprawdę był - tzn. liczba punktów była parzysta, a miała być parzysta
liczba przedziałów. To zresztą jest podstawowy problem z "Simpsonem" - nie
da się go ładnie zastosować do dowolnej liczby punktów/przedziałów. Co
ciekawe, po poprawieniu wynik zgadza się z analitycznym co do... 1.11E-14
procenta, czyli... znowu mamy "zły epsilon". lol
Szkoda, trzeba będzie poszukać innej funkcji - może x**13 w przedziale
[1001.0, 1001.69], może nawet takiej, że jest równa zero wszędzie poza
punktami w których x*k+q jest całkowite, ale tylko wtedy gdy A < x < B, choć
całkowana w [a,b] takim że a < A oraz B < b. Ta pierwsza ma czwartą pochodną
13*12*11*10*x**9, co dla x > 1000.0 daje wartości większe niż 1.0E31 i
powinno "rozwalić Simpsona". (Ale trzeba będzie uważać, aby nie zaszkodzić
trapezom.) Ta druga jest czuła na przesunięcie "o jeden piksel" i będzie
dawać zupełnie inne rezultaty dla różnych q - choć powinna dawać identyczne
jeżeli suport nie jest poza [a,b].
Cały problem jaki rzeczywiście jest, to brak dobrej metody "obliczania RMS"
która mogłaby operować na zmieniającej się ilości danych. Np. z przetwornika
otrzymuje się co 1/1000 sekundy nową parę (x,y) - a to ma się odzwierciedlać
w dokładniejszym RMS. Jeżeli używać innych metod niż całkowanie trapezami -
to każdy kolejny punkt zmienia sposób w jaki poprzednio już istniejące
punkty zostaną użyte w obliczeniach. Nie da się liczyć "nowego RMS" jako
"stare RMS" + poprawka, gdyż przeskakują wagi wzdłuż osi odciętych. Podobnie
jest niestety i ze spline'ami - zmiana w jednym miejscu pociąga za sobą
nielokalnie cały spline.
Do tego jeszcze jeden problem: jeżeli są to punkty x[i], y[i], mające być
danymi określonymi z niepewnościami dx[i], dy[i], gdzie i = 1,..., n, to z
reguły Simpsona wynika, iż gdy uda się nam dokładniej mierzyć dla parzystych
to będzie z tego znacznie lepsza poprawa dokładności całki niż w przypadku
dokładniejszych nieparzystych. Ok, dokładniejszy rachunek musiałby
uwzględniać korelacje, ale jeżeli np. mierzymy szum - to korelacji może nie
być.
Następne wpisy z tego wątku
- 14.11.12 12:05 Michoo
- 14.11.12 12:07 slawek
- 14.11.12 12:28 slawek
- 14.11.12 12:31 slawek
- 14.11.12 12:31 Michoo
- 14.11.12 12:41 slawek
- 14.11.12 12:46 Roman W
- 14.11.12 12:47 slawek
- 14.11.12 12:52 bartekltg
- 14.11.12 13:09 slawek
- 14.11.12 13:41 kenobi
- 14.11.12 13:49 bartekltg
- 14.11.12 15:55 kenobi
- 14.11.12 15:57 bartekltg
- 14.11.12 17:24 slawek
Najnowsze wątki z tej grupy
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
Najnowsze wątki
- 2025-02-06 PROGRAM DOPŁAT DO AUT ELEKTRYCZNYCH TO ABSURD. ZA ŚRODKI Z KPO KUPIMY NIEMIECKIE I CHIŃSKIE AUTA
- 2025-02-05 ceny OC
- 2025-02-05 Re: ceny OC
- 2025-02-05 Re: ceny OC
- 2025-02-07 Smar do video
- 2025-02-06 Litowe baterie AA Li/FeS2 a alkaliczne
- 2025-02-07 Gliwice => Business Development Manager - Network and Network Security
- 2025-02-07 Warszawa => System Architect (Java background) <=
- 2025-02-07 Warszawa => System Architect (background deweloperski w Java) <=
- 2025-02-07 Warszawa => Solution Architect (Java background) <=
- 2025-02-07 Gliwice => Ekspert IT (obszar systemów sieciowych) <=
- 2025-02-07 Lublin => Programista Delphi <=
- 2025-02-07 Warszawa => Architekt rozwiązań (doświadczenie w obszarze Java, AWS
- 2025-02-07 Dęblin => Node.js / Fullstack Developer <=
- 2025-02-07 Bieruń => Spedytor Międzynarodowy (handel ładunkami/prowadzenie flo