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