W dniu poniedziałek, 12 listopada 2012 10:47:02 UTC+1 użytkownik AK napisał:
> Użytkownik "slawek" <s...@h...pl> napisał:
>
>
> Poza tym to co zamiesciles to nie zadne C
>
> Top jakis potworek programisty niedouka.
>

ciekawe moze by bylo uslyszec co z tym kodem
jest nie tak, ale szczerze mowiac nie
podejrzewam że tak sie wyraże 'możliwosci
sensownej odpowiedzi w tym temacie'

(Imo jest to kawałek zupełnie normalnego/dobrego kodu w c

do góry

Dnia 13.11.2012 kenobi <p...@g...com> napisał/a:
> nie moja dzialka :O, mam co innego do roboty :o
> (ostatnio troche czytam o shaderach - i moge powiedziec ze troche
> beznadziejne oneż są)

To sprawdź różne języki shaderów, nie samym DirectX (HLSL) żyje
człowiek :D Mi bardziej podchodzi GLSL (ten z OpenGL) no i przy okazji
GLSL jest bardziej "przenośny" (Windows, Linux, czy nawet tablety z
nowszymi ARM-ami i Androidem) a HLSL jakby nie patrzeć przywiązuje do
jednego systemu operacyjnego (i pewnie są też zwolennicy HLSL - ok, ja
po prostu subiektywnie wybrałem GLSL na zasadzie "coś wybrać trzeba,
bo wszystkiego dobrze poznać się nie da").

A co do numeryki (w tym całkowania), to można mieć różne podejścia,
albo zagłębić się w matematyczną stronę i mieć pełne zrozumienie
"dlaczego", albo zaufać fachowym opracowaniom i tylko wiedzieć "jak"
dany algorytm działa (bez wnikania w teorię dlaczego akurat tak a nie
inaczej) - przykładowo aby z powodzeniem stosować tw. Pitagorasa wcale
nie trzeba znać dowodu tego twierdzenia (nie trzeba wiedzieć dlaczego
jest prawdziwe), wystarczy znać założenia (kiedy można je stosować) i
tezę (wzorek).

do góry

W dniu 2012-11-13 23:33, kenobi pisze:
> W dniu poniedziałek, 12 listopada 2012 10:47:02 UTC+1 użytkownik AK napisał:
>> Użytkownik "slawek" <s...@h...pl> napisał:
>>
>>
>> Poza tym to co zamiesciles to nie zadne C
>>
>> Top jakis potworek programisty niedouka.
>>
>
> ciekawe moze by bylo uslyszec co z tym kodem
> jest nie tak, ale szczerze mowiac nie
> podejrzewam że tak sie wyraże 'możliwosci
> sensownej odpowiedzi w tym temacie'
>
> (Imo jest to kawałek zupełnie normalnego/dobrego kodu w c

"Normalny", bo się kompiluje. Ale nie jest poprawny.

Błąd jest tutaj:

> #define NPTS 10000 /* NPTS must be even! */

> double x[NPTS+1];
> double y[NPTS+1];

Tak, liczba przedziałów ma być parzysta.
Tak, to oznacza, że liczba punktów powinna
być o jeden większa. Tyle, że sławek następnie
konsekwentnie używa wyłącznie zmiennych x[1]..x[NPTS]
W żadnej jogo funkcji nie użył x[0].

Pomylił się czy przepisał bezrefleksyjnie z języka o tablicach
indeksowanych od 1, nieistotne. Skutek jest taki:

Mamy 999 przedziałów!

x[1] = a //OK
x[n] = b //ok

Funkcje całkujące są niby poprawne, ale przez nieparzystą
liczbę przedziałów dwie ostatni wagi są zawyżone!
Funkcja jest tam lekko ujemna, stąd przekłamanie wyniku.

Chętni mogą łatwo oszacować o ile:)
sin(5)exp(-5)=-0.00646


Drobna poprawka i wszystko bangla:

#define NPTS 10001 /* NPTS must be even! */

double x[NPTS+1];
double y[NPTS+1];

i mamy

exact 0.5022749400837604
tapez 0.5022749194248539
simpson 0.5022749400837597

exact od simpsona różni się o 7 na ostatniej
wypluwanej liczbie:) 7*10^-16 !

Kod, kompilator i wynik:
http://codepad.org/ohuGkmiC


OT, literówka, ale wykłócać się na grupie, że oto
obalił to i owo to mógł.

pzdr
bartekltg

do góry

Użytkownik "bartekltg" <b...@g...com> napisał:

> Tyle, że sławek następnie konsekwentnie używa wyłącznie
> zmiennych x[1]..x[NPTS]
> W żadnej jogo funkcji nie użył x[0].

:) Kpilem sobie jawnie z jego fortranowych nalecialosci (indeksy od 1) i też się "nie
kapnął"
gdzie popełnił gruby błąd.

PS: Dobrze, żę problem nie jest dwywymiarowy bo by "poleciał" po kolumnach :).
W klasycznym Fortranie (F4, F77) macierze ułożone są w pamięci kolumnami a nie
tak
jak w Algolu czy C/C++/Javie/C#/VB wierszami

AK

do góry

W dniu 2012-11-14 00:17, AK pisze:
> Użytkownik "bartekltg" <b...@g...com> napisał:
>
>> Tyle, że sławek następnie konsekwentnie używa wyłącznie
>> zmiennych x[1]..x[NPTS]
>> W żadnej jogo funkcji nie użył x[0].
>
> :) Kpilem sobie jawnie z jego fortranowych nalecialosci (indeksy od 1) i
> też się "nie kapnął"
> gdzie popełnił gruby błąd.

Zastanawiam się, czy to nie jest jeden wielki trolling;)


> PS: Dobrze, żę problem nie jest dwywymiarowy bo by "poleciał" po
> kolumnach :).
> W klasycznym Fortranie (F4, F77) macierze ułożone są w pamięci
> kolumnami a nie tak
> jak w Algolu czy C/C++/Javie/C#/VB wierszami

Ja tam zawsze sprawdzam;)

>> reshape(1:9,3,3)
ans =
1 4 7
2 5 8
3 6 9

O, ukryty Fortran!
:)


Jeśli dobrze pamiętam, BLAS może przechowywać i tak i tak,
w zależności od tego odpala odpowiedni algorytm.
W sumie to nie jest żadna łaska, skoro i tak funkcje przyjmują
parametr mówiący, czy nie traktować macierzy jak transponowanej.


pzdr
bartekltg

do góry

W dniu środa, 14 listopada 2012 00:06:53 UTC+1 użytkownik bartekltg napisał:
> W dniu 2012-11-13 23:33, kenobi pisze:
>
> > W dniu poniedziałek, 12 listopada 2012 10:47:02 UTC+1 użytkownik AK napisał:
>
> >> Użytkownik "slawek" <s...@h...pl> napisał:
>
> >>
>
> >>
>
> >> Poza tym to co zamiesciles to nie zadne C
>
> >>
>
> >> Top jakis potworek programisty niedouka.
>
> >>
>
> >
>
> > ciekawe moze by bylo uslyszec co z tym kodem
>
> > jest nie tak, ale szczerze mowiac nie
>
> > podejrzewam że tak sie wyraże 'możliwosci
>
> > sensownej odpowiedzi w tym temacie'
>
> >
>
> > (Imo jest to kawałek zupełnie normalnego/dobrego kodu w c
>
>
>
> "Normalny", bo się kompiluje. Ale nie jest poprawny.
>
>
>
> Błąd jest tutaj:
>
>
>
> > #define NPTS 10000 /* NPTS must be even! */
>
>
>
> > double x[NPTS+1];
>
> > double y[NPTS+1];
>
>
>
> Tak, liczba przedziałów ma być parzysta.
>
> Tak, to oznacza, że liczba punktów powinna
>
> być o jeden większa. Tyle, że sławek następnie
>
> konsekwentnie używa wyłącznie zmiennych x[1]..x[NPTS]
>
> W żadnej jogo funkcji nie użył x[0].
>
>
>
> Pomylił się czy przepisał bezrefleksyjnie z języka o tablicach
>
> indeksowanych od 1, nieistotne. Skutek jest taki:
>
>
>
> Mamy 999 przedziałów!
>
>
>
> x[1] = a //OK
>
> x[n] = b //ok
>
>
>
> Funkcje całkujące są niby poprawne, ale przez nieparzystą
>
> liczbę przedziałów dwie ostatni wagi są zawyżone!
>
> Funkcja jest tam lekko ujemna, stąd przekłamanie wyniku.
>
>
>
> Chętni mogą łatwo oszacować o ile:)
>
> sin(5)exp(-5)=-0.00646
>
>
>
>
>
> Drobna poprawka i wszystko bangla:
>
>
>
> #define NPTS 10001 /* NPTS must be even! */
>
>
>
> double x[NPTS+1];
>
> double y[NPTS+1];
>
>
>
> i mamy
>
>
>
> exact 0.5022749400837604
>
> tapez 0.5022749194248539
>
> simpson 0.5022749400837597
>
>
>
> exact od simpsona różni się o 7 na ostatniej
>
> wypluwanej liczbie:) 7*10^-16 !
>
>
>
> Kod, kompilator i wynik:
>
> http://codepad.org/ohuGkmiC
>
>
>
>
>
> OT, literówka, ale wykłócać się na grupie, że oto
>
> obalił to i owo to mógł.
>

bład błedem ale mi chodziło o to ze jest to
dobry (nawet fajnie zwarty) kod w c, (ja bym
tylko zmienil definy na const int, [jako ze preprocesor tak naprawde w pewnym sensie
nie jest czescia c i byl raczej tak traktowany nawet przez ritchiego jedynie jako
zewnetrzne narzedzie, (co mozna wyczytac w
historycznej nocie ritchiego*]

(przy tym jak ktos zrobi merytoryczny bład to
nie dureń nie jełopi z tego powodu)

fir (finite impulse response)

* "Many other changes occurred around 1972-3, but the most important was the
introduction of the preprocessor, partly at the urging of Alan Snyder [Snyder 74],
but also in recognition of the utility of the the file-inclusion mechanisms available
in BCPL and PL/I. Its original version was exceedingly simple, and provided only
included files and simple string replacements: #include and #define of parameterless
macros. Soon thereafter, it was extended, mostly by Mike Lesk and then by John
Reiser, to incorporate macros with arguments and conditional compilation. The
preprocessor was originally considered an optional adjunct to the language itself.
Indeed, for some years, it was not even invoked unless the source program contained a
special signal at its beginning. This attitude persisted, and explains both the
incomplete integration of the syntax of the preprocessor with the rest of the
language and the imprecision of its description in early reference manuals."

do góry

pozatym ew troche cos dziwnie z tymi
nawiasami, chyba dodalbym tu pare spacji *
i byloby czytelniej, (ale pozatym mz jest to
dobry kod)

(sam jak patrze na swoje kody to czasem
rozstrzelam wyrazenia z operatorami a czasem
nie, zalezy od sytuacji, jak niektore zbitki
rażą to chyba wtedy, (choc ja sam pewnie nie pisze moze bynajmniej wzorcowego kodu,
ale chyba w miare ok )

do góry

W dniu wtorek, 13 listopada 2012 23:54:20 UTC+1 użytkownik Baranosiu napisał:
> Dnia 13.11.2012 kenobi <p...@g...com> napisał/a:
>
> > nie moja dzialka :O, mam co innego do roboty :o
>
> > (ostatnio troche czytam o shaderach - i moge powiedziec ze troche
>
> > beznadziejne oneż są)
>
>
>
> To sprawdź różne języki shaderów, nie samym DirectX (HLSL) żyje
>
> człowiek :D Mi bardziej podchodzi GLSL (ten z OpenGL) no i przy okazji
>
> GLSL jest bardziej "przenośny" (Windows, Linux, czy nawet tablety z
>
> nowszymi ARM-ami i Androidem) a HLSL jakby nie patrzeć przywiązuje do
>
> jednego systemu operacyjnego (i pewnie są też zwolennicy HLSL - ok, ja
>
> po prostu subiektywnie wybrałem GLSL na zasadzie "coś wybrać trzeba,
>
> bo wszystkiego dobrze poznać się nie da").
>

no wlasnie przegladam tutoriale do glsl'a
i nizbyt mi sie to podoba, do tego cos
zaslyszalem ze sa spore niekompatybilnosci
miedzy roznymi kartami, do tego pewne
'sciezki wykonania' sa podobno
niepodopracowywane na niektorych kartach
(i dzialaja ale wolno) tak ze odnosze
nie za dobre wrazenie o tym wszystkim :/

do góry

Użytkownik "kenobi" <p...@g...com> napisał w wiadomości
news:e438ba6a-15c4-4f60-bdb9-f6a8c1beff68@googlegrou
ps.com...
W dniu środa, 14 listopada 2012 00:06:53 UTC+1 użytkownik bartekltg napisał:
> W dniu 2012-11-13 23:33, kenobi pisze:

"
> fundamentalne problemy ze soba to ma grupowa dresiarnia, ja sie po prostu k-jowo
czuje po
> boreliozie, nie sposob o tym nie pisac bo to ciagly i silny ból - pisanie o tym to
jedna

I to ci przeszkadza wykazac _minimum_ szacunku dla grupy/innych i wycinac cytaty ?
Byles o to proszony dziesiatki juz chyba razy.
Jestes czlowieku zwyczajnym rozkapryszonym, zlosliwym w stosunku do innych dupkiem,
a twoja choroba (w ktora wierze) ma sie nijak do tego.
Jestem przekonany ze bez niej zachowywal bys sie tak samo, bo to kwestia charakteru
i elementarnej przyzwoitosci.

AK
"

do góry

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ć.

do góry