-
Data: 2012-11-15 10:42:17
Temat: Re: RSM i spline
Od: bartekltg <b...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]W dniu 2012-11-15 07:37, Baranosiu pisze:
> Dnia 14.11.2012 bartekltg <b...@g...com> napisał/a:
>> W dniu 2012-11-14 12:31, Michoo pisze:
>>
>>>> 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.
>>>
>>> A taka sytuacja miałby zajść w jakim przypadku praktycznym?
>>
>> Zrobiłem kilka testów.
>>
>> Ta sama funkcja, sin(x)exp(-x) na [0,5],
>> te same metody, puszczone na okolice 10000,
>> 1000 i 100 węzłów.
>>
>> Tym razem dodajemy jednak do każdego punktu szum:)
>> Wartość losową z rozkładu gaussa o zadanym
>> odchyleniu standardowym (zwanym dalej poziomem szumu).
>>
>> Tradycyjnie, manipulujemy poziomem szumu w przedziale
>> 1 do 10^-15 i badamy jakość przybliżenia wartości dokładnej.
>>
>> Ponieważ mamy odczynienia z wartością statystyczną, dla
>> każdego zestawu metoda-poziom szumy obliczenie zostaje powtórzone
>> 1000 razy, a jako wynik bierzemy średnią kwadratową różnic
>> względem wartości analitycznej.
>
> No tak to można wszystko wykazać (dodać szum i to Gaussa, żeby go
> potem "odszumić" średnią :D).
To będzie prawdziwe dla każdego modelu szumu z zerową średnią.
Gaussa akurat mam w bibliotece i łatwiej się liczy jego skutki
niż jednostajnego na odcink [-a,a].
> Ale potraktujmy ten wektor węzłów
> sin(x)*exp(-x) z dodanymi "odchyłkami" jako dane dokładne (na przykład
Tak zrobiłem!
Wyliczyłem sin(x)*exp(-x) i w każdym punkcie dodałem liczbę
losową ~N(0,sd^2). Teraz w te dane walnąłem całkowaczem,
powstał wynik. Ten wynik porównuje z wartością dokładną,
to 'błąd metody'.
Dopiero tak uzyskanie wyniku powtarzam 1000 razy.
Jako ostateczny wynik wypisuje średnią kwadratową tych
1000 błędów metody.
Nie, nie uśredniałem po punktach przed całkowaniem:D
> jako pochodzące z samplera audio o zerowym szumie) i dla tych
> danych trapez z wszystkich próbek wyjdzie dokładniej, niż simpson z co
> dziesiątej czy N-C z co setnej próbki i myślę że to Sławek miał na
> myśli pisząc o "lepszości trapezów w niektórych przypadkach". Owszem,
Oczywista oczywistość. Błąd pochodzący z 'dokładnej' części może
być nawet mniejszy, ale błąd "statystyczny" będzie sqrt(10) raza
większy.
Ale ja nie rozmawiam o urojeniach i poprawnych przewidywaniach
sławka, tylko zastanowiłem się nad problemem, czy aby przypadkiem
metody wyższego rzędu nie są bardziej wrażliwe na szum.
Taka była moja intuicja: Skoro interpretujemy nierównomierność
wag węzłów jako poprawkę szacującą wpływ pochodnej, to czy szum
nie wpływa na nią bardziej.
Oczywiście, porównując przypadki tej samej liczby węzłów,
wartości funkcji.
> można i Simpsopna czy N-C policzyc po wszystkich węzłach, ale obliczeń
> "nieco" więcej a wynik niekoniecznie lepszy, bo nie wiemy jakie jest
Nie jest nieco więcej, bo porównywałem taką samą liczbę węzłów,
nie taką sama liczbę kwadratur podstawowych. Mnożenie w co drugim
okresie przez inną liczbę też da się wyeliminować.
> "exact", chyba że wiemy, ale na przykład pisząc firmware oscyloskopu,
> które ma liczyć RMS przebiegu, nie możemy robić jakichś szczególnych
> założeń co do źródła sygnału, do jakiego oscyloskop jest podłączony a
A co ma znajomość exact do tego? Na tym polega problem, ze exact
nie znamy;) I na tym polegają takie proste testy, że obserwujemy,
jak numerki radza sobie z zadaniem, dla którego rozwiązanie znamy.
> konwerter analogowo-cyfrowy jest powiedzmy 16-bitowy więc jaki jest
> sens stosowania "lepszych" (dokładniejszych) metod?
Dokładnie to, co napisałem na końcu posta i co widać na wykresie.
-Nie wiemy, jaki jest szum.
-Jeśli jest duży, wszytki metody oparte na tych samych węzłach
dadzą ten sam wynik. To jest podstawowy wynik. Im bardziej
się nad tym zastanawiam, tym oczywistszy;)
Jeśli jest mały, lepsze metody dadzą lepszy wynik.
Zresztą, ani słowa nie powiedziałem o RMS. Pisałem o gładkiej
funkcji z pomiarami zaburzonymi w taki a taki sposób;)
pzdr
bartekltg
Następne wpisy z tego wątku
- 15.11.12 11:04 slawek
- 15.11.12 11:17 e...@g...com
- 15.11.12 11:17 slawek
- 15.11.12 11:23 AK
- 15.11.12 11:26 slawek
- 15.11.12 11:35 AK
- 15.11.12 11:37 AK
- 15.11.12 11:43 Michoo
- 15.11.12 11:46 Michoo
- 15.11.12 11:50 AK
- 15.11.12 11:53 AK
- 15.11.12 11:59 e...@g...com
- 15.11.12 12:07 bartekltg
- 15.11.12 14:21 Baranosiu
- 15.11.12 14:40 Baranosiu
Najnowsze wątki z tej grupy
- 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
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
Najnowsze wątki
- 2024-11-25 Karty przedpłacone (podarunkowe) Google Play - pytanie do korzystających
- 2024-11-26 wina Tóska
- 2024-11-26 Rewolucja/Rewelacja!
- 2024-11-25 grupa ożyła ;)
- 2024-11-24 Być jak Clint
- 2024-11-24 Rura kanalizacja konceptu Franke = problem
- 2024-11-25 Wrocław => Lead Java EE Developer <=
- 2024-11-25 Warszawa => Business Development Manager - Network and Network Securit
- 2024-11-25 Kraków => Programista Full Stack (.Net Core) <=
- 2024-11-25 Lublin => Senior PHP Developer <=
- 2024-11-25 Karlino => Konsultant wewnętrzny SAP (FI/CO) <=
- 2024-11-25 Warszawa => ECM Specialist / Consultant <=
- 2024-11-25 Katowice => Regionalny Kierownik Sprzedaży (OZE) <=
- 2024-11-25 Warszawa => Senior Frontend Developer (React + React Native) <=
- 2024-11-25 Lublin => Inżynier Serwisu Sprzętu Medycznego <=