Użytkownik "slawek" <s...@h...pl> napisał:

> Moim zdaniem jest to wręcz modelowy przykład kogoś, kogo nie chcielibyśmy mieć w
zespole.

O ! :) To przegapilem. Slawciu.
W zespole w ktorym ty jestes pod zadnymi warunkami nie chcialbym pracowac :)
To jest po prostu z zasady (mojej zasady:) niemozliwe.

AK

do góry

Dnia Thu, 15 Nov 2012 19:22:14 +0100, AK napisał(a):


> Tyle tylko, ze wtedy alternatywa jest tylko jedna.
> Definitywne "odpuszczenie" sobie usenetu (sklaniam sie "powoli" ku temu).

Uuuu, to bylaby wyzerka dla obu trolli... lata w szczesciu, sytosci i
przekonaniu o swojej racji.
Nie rob tego innym.

--
pozdro
R.e.m.e.K

do góry

Użytkownik "AK" <n...@n...com> napisał:

> FLOAT i jakos sie dalo.

Autopoprawka: Ups :) REAL (chyba:). Dokladniej REAL*4 (tez chyba:)

AK

do góry

W dniu 2012-11-15 20:30, AK pisze:
> Użytkownik "slawek" <s...@h...pl> napisał:
>
>> To wydaje się - na pierwszy rzut szklanym okiem - dobre.
>
> Ano wlasnie. Na pierwszy rzut oka.
>
>> Ale czy przypadkiem wtedy nie robią się z tego totalnie trapezy...?!
>
> Ano robia.

Nie, nie robią. Po pierwsze, stworzyliście kwadraturę,
która ma błąd rzędu h! Gratulacje:)

Następnym razem będzie propozycja "return 42;" ;)


> To jest ten jeden z tych przypadkow o ktorym wspominalem
> Bartkowi.

Zapomnieliście uzupełnić końcówek. Jak się je uzupełni,
trapezem lub 'półsipmsonem' i doda wersje z poprawką na
początku i końcu, wyjdzie.

[ kilka dziwnych liczb ] 6 6 6 6 6 6 6 6 6 6 [kilka dziwnych cyfr].

I ta kwadratura będzie zbiegać jak h^4.
Dla _odpowiednio_gładkiej_funkcji_.
Dlaczego? Bo kurde mamy kilka wzorków całkowych,
bo znamy błąd wyrażający się przez pochodne _na brzegach_,
i umiemy to skompensować. I te liczby to kompensują.

http://en.wikipedia.org/wiki/Trapezoidal_rule#Error_
analysis
Wzorek na dale akapitu.
błąd = stałe * h^2 * [ f'(b) - f'(a)] + O(h^3)

Te 'dziwne końcówki' dają poprawkę kasującą
główny człon błędu: stała * h^2 * [ f'(b) - f'(a)]
Z trapezowego h^2 robi się h^3 (albo i lepiej).


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?

Nie, to musi być zwykły troll.

> Bledem jest zalozenie. Bledem jest samo takie "przesuwanie" i
> "usrednianie".

Błędem jest zapomnienie o załatani brzegów. Błądem jest
niezrobienie analizy błędu, czy choćby eksperymentu.

> Po prostu obniza ono stopien wielomianu interpolacyjnego.

Nie, nie obniża. Nie może. Jeśli |A-I|<eps i |B-I|<eps,
to też |B+A|/2<eps. Dlaczego "wygląda jak trapez", a działa
lepiej, napisałem powyżej. Nie lekceważyć końcówek.


Ta metoda jest gorsza, bo poprawka rzędu jest "globalna"
każda nieciągłość którejś tam pochodnej oddala nas od wyniki,
a simpson jest 'dobry lokalnie'. Ale dla odpowiednio gładkich
funkcji suma takiego _poprawnego_ załatanego po prawej Simpsona
z _poprawnie_ załatanym lewostronnie simpsonem będzie miała
taki sam rząd jak gorsza z wejściowych metod (czyli h^3 jak załatamy
trapezem, h^4 jak pobawimy się parabolami).

> PS: O ile prawidlowo pamietam to tyczy nie tylko Simpsona, ale i
> podobnych metod
> "przesuwajaco"/"usredniajacych" dla wielomianow wyzszych rzedow -
> powstalych z rozwiniecia Lagrangea

Ale bezkolizyjnie przesuwać można jedynie dla funkcji okresowej.
A dlaczego te całkują się znakomicie nawet kartoflem, było już mówione.

pzdr
bartekltg

do góry

Dnia 15.11.2012 AK <n...@n...com> napisał/a:
> Nikogo nie nazywam idiota poza "hrabia" slawkiem.
> Nie wpieraj mi wiec niewypowiedzianych slow.
> Bede go nazywal idiota, chamem, palantem , gnojem i sk..lem dopuki
> nie przeprosi Bartka za chamskie obrazenie jego siostry.

Przepraszam jeśli to zabrzmiało jako "wciskanie słów w Twoje usta",
pisałem o swoim podejściu, nie o Twoim. Co do Twojego podejścia do
Sławka, to Twoja prywatna sprawa i nic mi do tego.

do góry

Dnia 15.11.2012 AK <n...@n...com> napisał/a:
> Użytkownik "Baranosiu" <r...@w...pl> napisał:
>
>> 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
>
> Przeciez w Simpsonie masz w 100% "integerowe" mnozenie przez 2 i 4.
> Pozornym problemem moze byc podzielenie przez 3, ale naprawde
> da sie to zrobic dla sumy (rejestru) typu integer.

Owszem, da się, ale "a to dzielenie przez 3", "a to poprawka przy
nieparzystej liczbie przedziałów" itd. i... algorytm nadal jest
prosty, ale już przestaje być trywialny i zapisywalny w 5-ciu
instrukcjach maszynowych, dla mnie to żadna różnica, ale jak się ktoś
uprze, to może być argument "za" trapezem :D

do góry

Dnia 15.11.2012 slawek <s...@h...pl> napisał/a:
>
> Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
> dyskusyjnych:k83eg0$qg6$...@n...task.gda.pl...
>> slawciu. Po prostu ten DBL_EPS pod wzgledem znaczenia dla numeryki
>> to klasyczny "problem zastepczy".
>
> Moim zdaniem - problem nr 1 "numeryki" to brak tanich i dostępnych
> procesorów 128 bitowych (tj. FPU) liczący na REAL16. Sprzętowo.

Oj tam, już w 1995 roku można było kupić Suna z procesorem SPARCv9
(tylko jakieś 2 razy droższy od markowego PC x86) a SPARCv9 do
desktopów miał FPU posiadające 16 zmiennoprzecinkowych rejestrów
128-bitowych (z możliwością przełączenia na 32 rejestry 64-bitowe) i
CPU miało 160 rejestrów 64-bitowych (w większości ortogonalnych,
grupowanych w 32-rejestrowe ramki). Obecnie Intel tak na prawdę
dogania swoja konkurencję sprzed wielu lat (którą wyparł z rynku
dzięki dobremu marketingowi i "zmowie" z kilkoma firmami). Sparc
przegrał z x86 walkę o komputery "popularne", może za niedługi czas
ARM wreszcie wprowadzi procesory RISC do komputerów domowych :D

do góry

Użytkownik "Baranosiu" <r...@w...pl> napisał:

> Obecnie Intel tak na prawdę dogania swoja konkurencję sprzed wielu lat

Dokladnie tak.
Hint: Wpominane tu juz koprocesory Weitek (wczesne lata 90te).
Tyle, ze slawek o tym wie (dzialal przeciez na FDP Fortran) tylko sciemnia zwyczajnie

AK

do góry

Użytkownik "AK" <n...@n...com> napisał:

> (dzialal przeciez na FDP Fortran)

NDP Fortran

AK

do góry

Użytkownik "AK" <n...@n...com> napisał:

> Dokladnie tak.
> Hint: Wpominane tu juz koprocesory Weitek (wczesne lata 90te).

http://pl.wikipedia.org/wiki/Lista_koprocesor%C3%B3w
_x86

Weitek[edytuj]
Koprocesor Weitek
Koprocesory dla x86 oferowała także firma Weitek. Ciekawostką był fakt, że lista
rozkazów procesora
Weitek nie była zgodna z listą x87. Koprocesor można było instalować w niektórych
płytach głównych
obok istniejącego 80387. Z koprocesora Weitek potrafiły skorzystać nieliczne programy
(AutoCAD,
Lotus 123, Mathematica). Jeśli system posiadał zarówno 80387 i koprocesor Weitek, to
możliwe było
równoległe prowadzenie obliczeń na obu jednostkach. Koprocesory Weitek miały
kilkunastokrotnie większą moc obliczeniową od układów FPU 80387 i jednostki
zintegrowanej z i486.
Był rzadko spotykany z uwagi na znikomą przydatność dla przeciętnego
^^^^^^^^^^^^^
użytkownika (korzystały z niego tylko specjalistyczne wybrane programy) i bardzo
wysoką cenę.
Obsługa koprocesora Weitek była uwzględniona w sterowniku EMM386.EXE dostarczanym z
systemem MS DOS
(od wersji 5.0).

PS: Jako ciekawostke moge podac fakt, ze koprocesow ten "naprawial" (byl pelny opis w
instrukcji do
Weiteka) kilka bledow wystepujacych w tym czasie w intelowkich.

AK

do góry