W dniu 2012-11-15 19:45, AK pisze:
>>
>
> Mozna roznie.
> Ja jednak pamietam, ze przy nawet zwyklym "sumowaniu" trzeba
> pamietac o pewnych innych rzeczach.
> Przeciez np . ortogonalne wielomiany Gramma wymyslono tylko
> po to aby uniknac tzw "kumulacji bledow" calkowicie falszujacej
> wynik przy zle uwarunkowanych zadaniach/problemach.

Hmm,
http://en.wikipedia.org/wiki/Discrete_Chebyshev_poly
nomials

To chyba ładna nazwa tego, co znam pod nazwą
baza Lagrange'a (baza kanoniczna).

W sumie się zgadza, robi się tak po to, bo interpolując
wielomian w bazie naturalnej (1,x,x^2...) dostajemy
brzydko uwarunkowaną macierz
http://pl.wikipedia.org/wiki/Macierz_Vandermonde%27a

> Zamiast chrzanic bez sensu o DBL_EPSILON to slawek powinien ten
> problem poruszyc. A on wystepuje jak najbardziej jesli ilosc probek
> bedzie duza a "aplituda" wartosci rowniez (ostatecznie mantysa to zaledwie


Ale to też same podstawy numeryki:

http://osilek.mimuw.edu.pl/index.php?title=MN09#Wyb.
C3.B3r_bazy_wielomianowej

Ok, problem nie jest zbadany, ale przynajmniej zasygnalizowany.

pzdr
bartekltg

do góry

W dniu 2012-11-15 14:40, Baranosiu pisze:
> poznał. Teoretycznie (czy w MathLabie) to wszystko wychodzi fajnie,

Mathlab to jeszcze inny program, tambo było bez h;)

> ale jak ma być na przykład implementacja algorytmu w konkretnym
> urządzeniu, w którym procesor nie ma na przykład zmiennoprzecinkowego
> FPU (tani oscyloskop) i operujemy tylko na liczbach całkowitych, to
> może taki przykład da się znaleźć :D

Ja się jednak zajmuję ciut większymi maszynkami,
nawet na STM32 ma ładnie hulający koprocesor:)

Ktoś już podawał. Jeśli nie boli nas zbieranie danych,
np 8 czy 12 bitowych i kumulowanie ich w odpowiednio
szerokiej zmiennej (taki 32 bitowy int na atmega to też
niebyle co:), to nie będzie nas boleć i zbieranie co
drugiego do innego kontenera. A potem się przesunie bitowo
jeden z tych kontenerów;) Jeśli raportować dalej musimy
rzadko, dodatkowe operacje nie będą nam przeszkadzać.
Jeśli 'co pomiar', brr, pewnie lepiej pchać dalej surowe dane.

O, jak w końcu znajdę czas pobawić się żyroskopem możę
sprawdzę, czy tam wystąpi jakaś różnica (szumi potężnie,
więc wątpię).

Z tym, że przy tak małej liczbie cyfr znaczących pewnie
dodatkowa zabawa nie ma po prostu sensu.

Ale powtarzam, ja wzdrygam się jedynie na twierdzenia
(które wczoraj padło po raz kolejny) jakoby dla funkcji
odpowiednio gładkich (nasz sin *exp) zabawki wyższego
rzędu działają tak samo jak trapez.


pzdr
bartekltg

do góry

Dnia 16.11.2012 bartekltg <b...@g...com> napisał/a:
> W dniu 2012-11-15 14:40, Baranosiu pisze:
>> poznał. Teoretycznie (czy w MathLabie) to wszystko wychodzi fajnie,
>
> Mathlab to jeszcze inny program, tambo było bez h;)
>

Ok, mój błąd :D Na co dzień nie używam ani jednego ani drugiego :D

>> ale jak ma być na przykład implementacja algorytmu w konkretnym
>> urządzeniu, w którym procesor nie ma na przykład zmiennoprzecinkowego
>> FPU (tani oscyloskop) i operujemy tylko na liczbach całkowitych, to
>> może taki przykład da się znaleźć :D
>
> Ja się jednak zajmuję ciut większymi maszynkami,
> nawet na STM32 ma ładnie hulający koprocesor:)

No ARM-y to wypas, nawet Intel zrobił swojego klona (XScale :D), ale
czasem trzeba takie rzeczy "wyrzeźbić" na jakimś małym
mikrokontrolerze PIC czy TinyAVR (chociażby ze względu na przykład na
oszczędzanie zasilania w urządzeniu bateryjnym, gdzie nie można
zastosować "wypasionego prądożercy", ale wtedy najczęściej całkuje sie
analogowo z wykorzystaniem wzmacniacza operacyjnego a tylko gotowy
wynik się sampluje :D).

> Ktoś już podawał. Jeśli nie boli nas zbieranie danych,
> np 8 czy 12 bitowych i kumulowanie ich w odpowiednio
> szerokiej zmiennej (taki 32 bitowy int na atmega to też
> niebyle co:), to nie będzie nas boleć i zbieranie co
> drugiego do innego kontenera. A potem się przesunie bitowo
> jeden z tych kontenerów;) Jeśli raportować dalej musimy
> rzadko, dodatkowe operacje nie będą nam przeszkadzać.
> Jeśli 'co pomiar', brr, pewnie lepiej pchać dalej surowe dane.

Masz na myśli AVR32 czy ATmegi? Atmegi mają 8-bitowe rejestry i
ewentualną możliwość łączenia niektórych rejestrów w pary w celu
zrobienia 16-bitowego dodawania jedną instrukcją, ale to tylko
oszczędność pamięci programu, bo czas działania jest taki sam, jak dwóch
wykonanych po sobie dodawań 8-bitowych (no i dodawanie 16-bitowe można
zrealizowac tylko z daną natychmiastową, coś za coś, instrukcja tak na
prawdę użyteczna do inkrementacji rejetrów indeksowych).

[...]
> Ale powtarzam, ja wzdrygam się jedynie na twierdzenia
> (które wczoraj padło po raz kolejny) jakoby dla funkcji
> odpowiednio gładkich (nasz sin *exp) zabawki wyższego
> rzędu działają tak samo jak trapez.

Na pewno nie działają tak samo, a dla "funkcji odpowiednio gładkich"
na pewno zabawki wyższego rzędu działają lepiej, ale jak ktoś się bawi
na przykład w mierniki mocy szumu, to może być różnie (inna
rzecz, że lepiej taki pomiar zrealizować analogowo i tylko samplować
gotowy wynik).

do góry

Użytkownik "bartekltg" <b...@g...com> napisał w wiadomości grup
dyskusyjnych:k83vmb$3hq$...@n...news.atman.pl...
> Ech, czy sławek naprawdę dalej chce udowadniać,
> że trapez dla gładkich funkcji działa tak samo jak
> metody wyższego rzędu? Mimo, że nawet jego program
> (po poprawieniu błędów) pokazuje co trzeba?

Weźmy taką ciąg y-ków (dla x ze stałym krokiem h): { 0, 0, 0, 0, 0, 1, 0,
2, 0, 2, 0, 3, 0, 3, 0, 3, 0, ..., 2, 0, 2, 0, 1, 0, 0, 0, 0, 0 }

"Simpson" z tego wynosi tyle a tyle, jednakże gdy zaczniemy liczyć z
offsetem równym 1 - np. w buforze cyklicznym - to wartość całki "Simpsonem"
zmieni się dwukrotnie.

Natomiast wynik jaki da wzór trapezów pozostanie bez zmian.

Nie twierdzę, że to dowodzi "wyższości trapezów" - ale że coś należałoby
zrobić z "simpsonen", aby tak nie było.

do góry

Użytkownik "bartekltg" <b...@g...com> napisał w wiadomości grup
dyskusyjnych:k85pjr$5vi$...@n...news.atman.pl...
> Hmm,

Tu jest dopiero hmmmmmm - na końcu tekstu w "conclusions"

http://www.math.ethz.ch/~waldvoge/Projects/nispaper.
pdf

do góry