Dnia 07.11.2012 AK <n...@n...com> napisał/a:
[...]
> Np zanika tak cos "drzewiej" podstwowego jak dokladny dobry
> _projekt techniczny_ systemu pisany _zanim_ sie rzucalo na klawiature.
> Dzis czesto jest to tylko analityk (a nawet jego czesto brak) a potem
> zgraja "sprytnych" programistow rzucajacych sie z miejsca na
> klawiature/kod i grzejacych sciany na tych spotkaniach scrumowych

Oczywiście są projekty i "projekty" ale generalnie przy robieniu
systemu o bardzo dużej złożoności model kaskadowy tworzenia
oprogramowania (czyli najpierw pełny i dokładny projekt a potem
implementacja bez jakichkolwiek modyfikacji projektu) po prostu się
nie sprawdził - nie da się teoretycznie przewidzieć wszystkiego,
dlatego stosuje się model iteracyjny, czyli projekt techniczny
ewoluuje razem z implementacją. Tak po prostu działa świat, nie da się
zrobić pełnego projektu dojechania samochodem z Krakowa do Warszawy
typu jedź 10s prosto, potem skręć kierownicę o 7 stopni w prawo
itd. zbyt wiele nieprzewidywalnych rzeczy wydarzy się po drodze.
Model kaskadowy wygląda pięknie na wykładach z inżynierii
oprogramowania (też byłem tego uczony w latach 90-tych) ale po prostu
nie działa (chyba, że podejdzie się do sprawy tak jak Donald Knuth,
czyli brak ograniczenia czasowego na powstanie programu - TeX
powstawał 10 lat :D).

Inna rzecz to niedbałość czy kiepskie zarządzanie. Bywa że manager
robi takie ciśnienie (wszystko jest "na wczoraj"), że ktoś kto przez 2
tygodnie nie napisze linijki kodu wylatuje z pracy (bo poświęcił czas
na projektowanie czy na przykład dokształcenie się z dziedziny, w
której ma chodzić system, a przecież klient płaci za kod a nie za
"pierdoły"). Znam też firmę, w której prezes ma podejście typu
"jedynym działem dochodowym to dział sprzedaży, reszta to tylko
koszty" - prowadzi to oczywiście do tego o czym napisałeś poniżej,
czyli "aby tylko sprzedać, a po nas choćby potop", no ale złe wieści
szybko się rozchodzą i poświęcanie długoterminowej "renomy" na rzecz
chwilowego zysku powoduje, że firma szybko ginie z rynku (utapiając
przy okazji część swoich klientów).

> No i oczywicie dokumentacja to czesto zbedna rzecz itp.

Zależy od klienta, czasem klient płaci za "czarną skrzynkę" i nie
wnika w zawartość, a czasem klient płaci za platformę na której buduje
swoje rzeczy i wtedy dokumentacja jest częścią produktu równie ważną
jak kod.

> Slowem inna odmiana metody "po nas chocby potop".

Odejście od modelu kaskadowego często przynosi poprawę jakości
produktu ale oczywiście podejście "płacimy za kod, resztę
minimalizujemy jak się tylko da, bo to marnowanie czasu programisty"
to droga do nikąd.

do góry

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

> Tak, dla całkiem sporej rodziny funkcji wyniki będą te same.
> Np liniowych;) czy sinusa po pełnym okresie. Tylko co z tego.
> Dla każdej funkcji ciaglej znajdziesz kwadrature jednopunktową,
> dająca dokładny wynik. Liczy się ogolna sprawność metody
> dla funkcji danej klasy.

Alez oczywista !

> Podobnie argumentował slawek. I jest to właśnie nasza bzdura;)

Alez nigdy nie twierdzilem inaczej :)!
Bzdura jest wlasnie przyjecie zalozenia, ze sobie bierzemy
tylko jeden kawalek z wielomianu czastkowego.
Co znaczy ze bledne jest samo zalozenie slawka
(a tylko przy tym zalozeniu moze miec racje).

> Ale co w tym dziwnego, skoro dla takich funkcji całki po okresie
> z kolejnych pochodnych wynoszą 0:)

Sedno :)

> Dywagacje dywagacjami, a metody wyższego rzędu działają lepiej;)

Alez jasne. Naprawde mialem w tym temacie drzewiej
"nieco" praktyki i lez (i wyprowadzen) przy tym wylalem, a poniewaz
do idiotyvcznie pracowitych nie naleze (a nawet wiecej:), wiec
NAPEWNO bym sie nie meczyl wiedzac, ze trapez jest uber alles :)
Po prostu napisalem to (a nie czytalem watku w ktorym
dyskutowaliscie) bo pomyslalem, ze takie zalozenie
z przesuwaniem wielomain u i braniem calki tylko
w jednego srodkowego h przyjal slawek.
Bo tylko wtedy (tak jak piszesz) wyrazy sie znosza i
kwadratura zlozona sprowadza sie do trepezow.

> [oczywiście dla odpowiednio gładkich funkcji, simpson da ciała
> na nieciągłości pochodnej, i z uwagą, że N-S przy rzędzie chyba
> coś koło 8 przestaje być stabilny - pojawiają się się ujemne wagi].

A stoi cos na przeszkodzie dobierac stopien czaskowo tak tak
sie to robi przy wygladzaniu funkcji wielmianami tego goscia eee..
no kurde zapomnialem :(

> BTW, kwadratura romberga oparta ejst na tych samych węzłach,
> a zbiega jak szalona (dla funkcji gładkich). A to przecież
> tylko średnia ważona kilku trapezów.

Poddaje sie calkiem. Nazwisko kojarze oczywiscie , ale
wiecej szczegolow utonelo w 20letnim przemiataniu
rekordami i ekranami :(

Co do nieciaglosci pochodnej przy wszelkich zlozonych Simpsonach.
Dlateczo nie uzyc splajnow aby tych niecaglosci uniknac w wezlach
miast parabolek/wielomanow.
Ale chyba i tak metoda Gaussa jest lepsza od wszelkich Simpsonow ?
Myle sie ?

PS: Nie przeceniaj mnie Bartek. Nie jestem zadnym matematykiem.
Wszysko co tu pisze nauczylem sie wlasciwie hobbystycznie
"szkolac" sie na przyszlego programiste "pol wieku temu" gdy
wylecialem ze studiow, a w tej chwili to naprawde nie poamietam
juz wzroru na calke z wielomianu :( Szlag... SKS..
Nie jestem wiec w stanie naprawde powaznie uczestniczyc
w "wojnach algorytmicznych", ale oczywiscie chetnie bym
kibicowal/byl na widowni :)

AK

do góry

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

>> Slowem inna odmiana metody "po nas chocby potop".
>
> Odejście od modelu kaskadowego często przynosi poprawę jakości
> produktu ale oczywiście podejście "płacimy za kod, resztę
> minimalizujemy jak się tylko da, bo to marnowanie czasu programisty"
> to droga do nikąd.

Powiem powazniej.
Tak jak kiedys przeintelektualizowane/przeteoretyzowane
byly wszelkie GOFy, i UMLe (i to bylo przyczyna ich ..) tak teraz
jest _wyrazne_ przegiecie w druga strone.
Wszelkie odchylenia i silver bullets sa zle.

A tak naprawde liczy sie (jak zawsze) dobre sumienne rzemioslo
i pomyslenie o tych co przejma Twoj kod, a _nade wszystko_ ciagle
myslenie o uzerze i powazne jego traktowanie. Baardzo powazne.
Ja tak zawsze robie mimo, ze nie zdarzylo mi sie zaznac wzajemnosci
(zwlaszcza od mlodych:) i mimo ze _rzadko_ mi sie to oplaca.
Ot taka stara Odrowa/Algolowa szkola :(

PS: Powiem Ci tylko ze prowadzac przed laty kilka lat wlasna DG
programistyczna ze zdziwieniem sie dzis dowiaduje
ze stosowalem nagminnie TDD a moze i BDD zanim jeszcze sie urodzily ;)
Tyle ze wtedy to byly zwykle codzienne/cotygodniowe rozmowy/ustalenia
z userami zleceniodawcy i nazywalo sie to zwyklym wdrazaniem, a dzis zwie
sie to jakimis iteracjami itp ;)

AK

do góry

On 07.11.2012 19:50, e...@g...com wrote:
> A moze tak przy okazji ktos (moze OP?) wytlumaczy, jak sie
> liczy blad maszynowy wyrazenia sin(b/a) dla a=100 i powiedzmy
> b=549.755813887? Najlepiej na postawie tego DBL_EPS.
>
W typowym wypadku patrzy się do dokumentacji i czyta, że gwarantowana
dokładność dla sin to AFAIK 1e-10.

W "specjalnym" przypadku:
549.755813887 się nie reprezentuje nawet w long double, mamy więc już na
początku przedział:
549.75581388699998797164880670607089996337890625L,
549.7558138870000021825035219080746173858642578125L
o szerokości 1.42109e-14 i względnym błędzie 2.58494e-17

Wykonujemy dzielenie i otrzymujemy
5.49756 z przedziałem 1.42681e-16 i dokładnością 2.59535e-17

Teraz jakąś prostą metodą liczymy sinus, np. Taylorem, do czasu aż
reszta będzie w tej samej okolicy co błąd obliczeń. Otrzymujemy
lower:
-0.7072686935699425367384853002850064740414381958544
254302978515625
upper: -0.7072686935699250790777342645654357511375565081834
7930908203125
interval: 1.74577e-14 interval rel: 2.46832e-14

Jeżeli chcemy teraz mieć pewność, że nasz przedział rzeczywiście zawiera
poszukiwaną wartość to powinniśmy go jeszcze skorygować o resztę z
rozwinięcia funkcji w szereg. W tym wypadku wydaje mi się, że możemy po
prostu go podwoić, bo sinusa przybliżyliśmy z resztą nie większą od
szerokości przedziału.

kod:
http://grota.be/~michoo/smieci/interval.cpp

P.S.
Wszelkie uwagi mile widziane. Kod zmontowany na szybko z na podstawie
starego projektu, więc jakieś błędy mogły się wkraść.

--
Pozdrawiam
Michoo

do góry

Dnia 08.11.2012 AK <n...@n...com> napisał/a:
[...]
> PS. Powiem Ci tylko ze prowadzac przed laty kilka lat wlasna DG
> programistyczna ze zdziwieniem sie dzis dowiaduje
> ze stosowalem nagminnie TDD a moze i BDD zanim jeszcze sie urodzily ;)
> Tyle ze wtedy to byly zwykle codzienne/cotygodniowe rozmowy/ustalenia
> z userami zleceniodawcy i nazywalo sie to zwyklym wdrazaniem, a
> dzis zwie sie to jakimis iteracjami itp ;)

Wcale się nie dziwię, bo prędzej czy później chyba każdy dochodzi do
wniosku, że takie podejście jest najbardziej naturalne.
Swoją drogą model iteracyjno-przyrostowy był już "sformalizowany" w
połowie lat 80-tych XX wieku ale w latach 90-tych nadal uczono
(przynajmniej mnie) modelu kaskadowego jako "wzorowego" a na
przedmiotach typu "inżynieria oprogramowania" czy "programowanie
zespołowe" był niestety "jedynym słusznym" podejściem :D

do góry

Po pierwsze dzieki. Nie jestes OP, ale OP ma wazniejsze tematy niz epsilon.

W dniu czwartek, 8 listopada 2012 15:07:49 UTC-5 użytkownik Michoo napisał:
> On 07.11.2012 19:50, e...@g...com wrote:
> > A moze tak przy okazji ktos (moze OP?) wytlumaczy, jak sie
> > liczy blad maszynowy wyrazenia sin(b/a) dla a=100 i powiedzmy
> > b=549.755813887? Najlepiej na postawie tego DBL_EPS.
> W typowym wypadku patrzy się do dokumentacji i czyta, że gwarantowana
> dokładność dla sin to AFAIK 1e-10.

Zawsze mnie zastanawialo, kiedy sie konczy typowy a zaczyna sin(1e20).

> W "specjalnym" przypadku:
> 549.755813887 się nie reprezentuje nawet w long double, mamy więc już na
> początku przedział:
>
> 549.75581388699998797164880670607089996337890625L,
> 549.7558138870000021825035219080746173858642578125L
> o szerokości 1.42109e-14 i względnym błędzie 2.58494e-17

> Wykonujemy dzielenie i otrzymujemy
> 5.49756 z przedziałem 1.42681e-16 i dokładnością 2.59535e-17

> Teraz jakąś prostą metodą liczymy sinus, np. Taylorem, do czasu aż
> reszta będzie w tej samej okolicy co błąd obliczeń. Otrzymujemy
> lower:
>
> -0.7072686935699425367384853002850064740414381958544
254302978515625
>
> upper: -0.7072686935699250790777342645654357511375565081834
7930908203125
> interval: 1.74577e-14 interval rel: 2.46832e-14

> Jeżeli chcemy teraz mieć pewność, że nasz przedział rzeczywiście zawiera
> poszukiwaną wartość to powinniśmy go jeszcze skorygować o resztę z
> rozwinięcia funkcji w szereg. W tym wypadku wydaje mi się, że możemy po
> prostu go podwoić, bo sinusa przybliżyliśmy z resztą nie większą od
> szerokości przedziału.

Z tego co wiem (nie sprawdzalem, obliczenia numeryczne sa dla mnie mocno
chlodne) ieee 764 (oidp numer) okresla nawet blad dla sinusa z bardzo wielkich
liczb (dla 1e30 krok x zaczyna sie robic spory). Co ciekawe, uzywa sie tego
do weryfikacji platformy w roznych @Home - o ile wyniki sa zupelnie bez sensu
to jednak weryfikuja zgodnosc, bo zawsze sa takie same.

To rozwiniecie wziales z definicji bledu sin() czy tak jak mogloby/powinno byc?

> kod:
> http://grota.be/~michoo/smieci/interval.cpp

Ja jestem bezsilny, podobnie jak OP.

> P.S.
> Wszelkie uwagi mile widziane. Kod zmontowany na szybko z na podstawie
> starego projektu, więc jakieś błędy mogły się wkraść.

Jeszcze raz dzieki. Jak sie do tego ma ten DBL_EPS?

--
Edek

do góry

On 08/11/2012 19:49, AK wrote:
>
> A tak naprawde liczy sie (jak zawsze) dobre sumienne rzemioslo
> i pomyslenie o tych co przejma Twoj kod, a _nade wszystko_ ciagle
> myslenie o uzerze i powazne jego traktowanie. Baardzo powazne.

Przecież to wszystko jest w agile.

do góry

On 07/11/2012 21:59, AK wrote:
> Użytkownik "slawek" <s...@h...pl> napisał:
>
>> Inżynieria to nie Pajton czy Algol 60. Ale trudno wymagać od leśnego
>> dziadka aby naraz wskoczył w agile.
>
> Agile nazywasz inzynieria oprogramowania ?
> Czlowieku :) Bredzisz coraz bardziej :)
> Nie mowiaz juz o tym, ze te dzisiejsze Agile TDD, BDD itp
[...]
> Np zanika tak cos "drzewiej" podstwowego jak dokladny dobry
> _projekt techniczny_ systemu pisany _zanim_ sie rzucalo na klawiature.

W Agile też się robi, tylko że mały i prosty. Właśnie przede wszystkim w
ten sposób uzyskuje się to, że jest on dobry.

> Dzis czesto jest to tylko analityk (a nawet jego czesto brak) a potem

Nie w każdym projekcie jest potrzebny analityk. I nie w każdym
projekcie, który potrzebuje analityka, musi on być członkiem zespołu
developerskiego.

> zgraja "sprytnych" programistow rzucajacych sie z miejsca na
> klawiature/kod i grzejacych sciany na tych spotkaniach scrumowych
> No i oczywicie dokumentacja to czesto zbedna rzecz itp.

Często jest zbędna.

> Slowem inna odmiana metody "po nas chocby potop".
> Wez ty slawus nie wypiowiadaj sie o swiecie o ktorym nic nie wiesz.
> Rob sobie te numerki na uczelni i sie ciesz ze ci Kudrycka za DBL_EPS
> myto placi.

...natomiast jaki jest związek tego wszystkiego z DBL_EPS to nie bardzo
kojarzę.

do góry

On Thu, 8 Nov 2012 09:23:32 +0100, "slawek" <h...@s...pl> wrote:
> Newtonowskie s ok, ale ciekawe mog by np. genetyczne lub z
rojem, bo
> chyba trudniej zaci im si na ekstremum lokalnym. Czasem nie ma
> pochodnych, czasem np. moe by wiele procesorów.

Nie miao by ciekawe, miao dobrze dziaa :)
Z algorytmami genetycznymi jest pewnie ten sam problem co z
symulacjami Monte Carlo - pochodne wyników po parametrach s czsto
niestabilne.

RW

do góry

On 09.11.2012 00:04, e...@g...com wrote:
>
> To rozwiniecie wziales z definicji bledu sin() czy tak jak mogloby/powinno byc?

Sin liczony z szeregu Taylora wygląda tak:
sin(x)=x - x^3/3! + x^5/5! - x^7/7! -...
bierzemy kolejne liczby nieparzyste, co drugi składnik ma + a co drugi -.
Jak byśmy sumowali z 100% dokładnością w nieskończoność to dostaniemy
wynik dokładny. Ale ponieważ sumujemy tylko n początkowych wyrazów mamy
jeszcze resztę Lagrange'a na końcu. Żeby nie komplikować bardziej można
zauważyć, że kolejne wyrazy są malejące i na przemian
dodawane/odejmowane, więc a_n dla n-tej sumy częściowej może być
traktowany jako dobry upper bound na błąd.

>
>> P.S.
>> Wszelkie uwagi mile widziane. Kod zmontowany na szybko z na podstawie
>> starego projektu, więc jakieś błędy mogły się wkraść.
>
> Jeszcze raz dzieki. Jak sie do tego ma ten DBL_EPS?
>

Nie ma się wcale. EPS jest pewną poglądową jednostką dokładności liczby
zmiennoprzecinkowej w odniesieniu do 1, natomiast można z niego
wyciągnąć wniosek, że "błędy epilonowe" są w double około 16 miejsc
dziesiętnych za wartością. I rzeczywiście różnica pomiędzy 100 a
następną liczbą wynosi 1.42109e-14.


--
Pozdrawiam
Michoo

do góry