W dniu 2012-11-07 00:41, AK pisze:
> Użytkownik "slawek" <s...@h...pl> napisał:
>
>> Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
>> dyskusyjnych:k7c0hi$jp4$...@n...task.gda.pl...
>>> Metoda zmiennej metryki Wolfa-Broydena-Davidona byla wtedy
>>> i wierze ze jest i dzis) jedna z najwydajniejszych ogolnych metod
>>> optymalizacji.
>>
>> Nie ma większego znaczenia, czy uzyska się wynik w 200 krokach czy
>> tylko 42.
>
> 1. W/w stwierdzeniem zwyczajnie osmieszasz sie.
> 2. Prosilem wyraznie o podanie tych "topowych" metod optymalizacji
> w stosunku do tych w/g ciebie przereklamowanych zm.metryki.
> Jestes w stanie podac konkretne nazwy i namiary ? (tylko daruj
> sobie jakies
> zlote podzialy czy inne richardsony:)


Rozmawiasz z facetem, który przez tydzień, mimo wysiłków
grupy, nie dał sobie wytłumaczyć i uparcie twierdził, że
"jakość" całki numerycznej nie zależy od rzędu kwadratury
(Newtona-Cotesa, czyli tych zwykłych, kawałkami wielomianów).
Wszytko rzędu wyższego niż "trapezy" miało być przereklamowanymi
akademickimi bredniami nie dającymi poprawy wyniku względem
metody trapezów:)

pzdr
bartekltg

do góry

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

>>A gdy dzielilo sie unsigned long int przez unsigned int to juz nie ?
>
> Tylko z jedną kombinacją, b. dziwaczną, typu parametrów - ktoś pomylił się (?!)
pisząc kompilator.
> Był do tego wydany, AFAIR, patch.

Pytam sie jeszcze raz czy z blad byl rowniez wtedy gdy dzielilo sie
unsigned long int przez unsigned int czy tylko dla short ?
Prosze o namiar na tego patcha.
Kiedy patche/bledy borlanda znalem na pamiec.
W dalszym ciagu podtrzymujesz ze konfabulujesz.

>>Wtedy ok 7000 tys pracownikiw, ok 200 skladnikow
>>placowych (pametam do dzis ze chyba byly 4rodzaje mydla
>>ktore oczywiscie odliczalo sie od placy brutto itp smaczki :)
>
> Ciekawe, czyli 10% Polek i Polaków pracujących... pracowało w firmie Zelmer?
Ciekawe.

Alez z ciebie Bardzo Uczony Czlowiek ! (w skrocie BUC).

> Nota bene, takie przykłady pokazują jak ważna jest "inżynieria programowania" i
umiejętność
> abstrakcyjnego myślenia. Sam chyba przyznasz, że mając dzisiejsze narzędzia i
doświadczenie - tego
> rodzaju Kadry-Płace można stworzyć znacząco mniejszym wysiłkiem. Choćby dlatego, że
zupełnie
> inaczej można rozmawiać o wymaganiach programu.

Nie.
Gdyz stworzenie plac (i nie tylko) tak naprawde bardzo malo zalezy od narzedzi
i tzw inzynierii programowania (no fakt ze dzis uzylbym po prostu Pythona jako
embedded jezyka do algorytmow placowych, a nie tego ktory byl -
dosc paskudny:) ale to szczegol).
W 90% powodzenie zalezy od organizacji w firmie, jej charakteru (akord czy dniowka)
itp
sposobu naliczania plac (czy np placa z biezacego miesiaca zalezy od tego czy
pracownik
3 lata temu wzial pozyczke z kasy zapomogowej i zuzyl 2 czy 3 sztuki pasty BHP)
itp, itd. naprawde wielu _merytorycznych_ rzeczy.
Ty zwyczajnie _nie masz zielonego pojecia_ o praktyce programowania w tzw dziedzinie
szumnie dzis nazywanej ERP.
Siedz lepiej do konca zycia na tej uczelni bo w _prawdziwej uzytkowj informatyce_
zginiesz marnie.

> Jak były młode i ładne - ale nie były?...

Byly, byly :))))
Tyle, ze ja raczej Shreka przypominam a swoja Fione tez juz wtedy mialem :)
Zreszta to wdroznie baaardzo zcemetowalo nasze malzentwo (Fiona jest tylko
jedna i cale szczescie nie zamierza klonowac:)

>>Na 16 bitowym DOSie miales jakis odpowiednik uit64 ?
>
> Na 16 bitowych PC-AT z DOS 3.3 był NDP Fortran. Zgadnij ilu bitowy i dlaczego...

Nie ucz mnie chlopie o NDP bo do dzis mam wciaz caly zestawik NDP (F i Pascal i C)
mimo ze firmy (MicroWay) juz dawno nie ma.
Wlasnie ten NDP swietnie wspolpracowal/byl dedykowany dla koproc. Weitek
gdzie Twoje "problemy" DBL_EPSILON wzielo by w leb calkiem.
Nie ucz mnie tez o protected-extenderach bo zeby zjadlem na wszelkich PharLapach
PowerPackach (Borlandowski extender, najlepszy jaki spotkalem, PharLap sie chowa)
go32, gw itp. Osmieszasz sie chlopie po raz kolejny
To byly czasy gdy _nie bylo jeszcze 386 w ogole_, a ATka 12MHz (slynne turbo) byla
marzeniem :)
PS: Jakosc kompilatorow NDP w stosunku do Borlanda i MS wtedy to bylo tak
ok min 10/1

> A na 8-bitowych ZX dało się mieć - nie żartuję - liczby całkowite dwubajtowe!
Normalnie cud jakiś
> i niemożebność, lol

No cos podobnego ! Mnie sie udalo juz wtedy miec W C/C++
liczby calkowite bez ograniczen dlugosci (takie jak ma Python).
Burku jeden, problem byl nie w tym co masz w pamieci, ale w tym
ze bazy danych mialy swe ograniczenia na 16 bit os.

AK

do góry

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

> Jak wszytko jest liniowe, to prosto.

Rozumiem.
Wiezy, czyli po prostu ograniczenia.

Fakt. Simplex, (w najgorszym przypadku pogramowanie hiperboliczbne itp.)
dla problemow liniowych. Eleganckosc maksymalna.
Gorzej z calkowitoliczboowym.
Przyznam sie bez bicia, ze juz Gomory mnie nieco przerosl wiec stosowalem
nagminie rozne "poprawiane" pod problem metody podzialu i ograniczen.
No ale jakos wystarczaly mimo ze tasma niezle krecilo z powodu "lekkiego"
nadmiaru sukcesorow :) (akurat ta Odra zwyczajnie nie miala dyskow...:(

To prawda ze w ogolnym przypadku (nieliniowych funkcji, a juz nie daj Boze
nieliniowych ograniczen) jest zabawa i elegenckosc metod/rozwiazan nieco
szlag trafia (chocby metody funkcji kary itp), ze o efektywnosci/wydajnosci
juz nie wspomne.

AK

do góry

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

> Rozmawiasz z facetem, który przez tydzień, mimo wysiłków
> grupy, nie dał sobie wytłumaczyć i uparcie twierdził, że
> "jakość" całki numerycznej nie zależy od rzędu kwadratury
> (Newtona-Cotesa, czyli tych zwykłych, kawałkami wielomianów).
> Wszytko rzędu wyższego niż "trapezy" miało być przereklamowanymi
> akademickimi bredniami nie dającymi poprawy wyniku względem
> metody trapezów:)

No kurde popatrz :), ze ja tego nie wiedzialem juz na studiach :) ?

Wtedy bym olal wyprowadzanie i zastosowanie metod
wspolczynnikow zwezajacych (np. ksiazka Burlish-Stoer chyba,
albo Janowski czy Ralston, juz nie pamietam) dla splineow
i wielomianow wyzszego stopnia itp. dla transformat
Fouriera w celu "rozplatania" widm rentgenowskich i pozostal
przy trapezach :)
Slawciowi sie popierdzilo chyba z tym, ze te "funcje zwezajace"
dalo sie faktycznie "wyciagnac przed nawias" (co bylo clue sprawy)
gdyz mnozna bylo uzyc zwyklej (a wiec liniowej/trapezowej)
FFT (wiadomo , wydajnosc/liniwosc skali) a potem wynikowe
dane "przemnozyc" przez (wcale nie trywialna) funkcje zwezajaca.
Jednak twierdzenie ze taki wynik jest co do dokladnosci ten sam co
dla trapezow mnie.. oslabilo :) (zwlaszcza w poblizu czestotliowosci
Nyquista :)

AK

do góry

W dniu 2012-11-07 13:15, AK pisze:
> Użytkownik "bartekltg" <b...@g...com> napisał:
>
>> Jak wszytko jest liniowe, to prosto.
>
> Rozumiem.
> Wiezy, czyli po prostu ograniczenia.
>
> Fakt. Simplex, (w najgorszym przypadku pogramowanie hiperboliczbne itp.)
> dla problemow liniowych. Eleganckosc maksymalna.

Właśnie o to chodzi, że jak jest liniowe (od biedy kwadratowe
lub choćby wypukłe), to nie jest źle.
A ogólnie jest znacznie gorzej.

> Gorzej z calkowitoliczboowym.

A tu zupełnie inna rzecz;)
>
> To prawda ze w ogolnym przypadku (nieliniowych funkcji, a juz nie daj Boze
> nieliniowych ograniczen) jest zabawa i elegenckosc metod/rozwiazan nieco
> szlag trafia (chocby metody funkcji kary itp), ze o efektywnosci/wydajnosci
> juz nie wspomne.

I o tym mówił Roman.

pzdr
bartekltg

do góry

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

> A ogólnie jest znacznie gorzej.

To prawda.
Zwlaszcza gdy sie "ugrzeznie" w "lejku" ograniczen (niewypuklosc).
Cala teoria i sztuka jak z niego wyjsc.
To czesto przypoimina sytuację gdy ma Fiona ukryje mi "Perłę - niepasteryzowane"
i algorytmem "ciepło/zimno" naprowadza na wlasciwa ściezke...

AK

do góry

W dniu środa, 7 listopada 2012 00:55:43 UTC+1 użytkownik kenobi napisał:
> wogole fpu ( i ipu) to ciekawy ale i raczej szeroki temat, mozna porozwazac wiele
opcji i pomyslow np sprzetowe sygnaly na wszystko co powoduje obciecie informacji
(lub
>
> niekontrolowane np mozna by wprowadzic dwa rodzaje operatorow dzielenia stratnego i
bezstratnego itd - wogole fpu to raczej szeroku temat, podszkole sie w tym z czasem

okazuje sie ze jest cos takiego, bit5 w control word - wyjatki 'inexact', no prosze

to czy takie rzeczy robic na stale czy robic maszyny stanow to inna kwestia

do góry

W dniu środa, 7 listopada 2012 06:57:57 UTC-5 użytkownik bartekltg napisał:
> Rozmawiasz z facetem, który przez tydzień, mimo wysiłków
>
> grupy, nie dał sobie wytłumaczyć i uparcie twierdził, że
>
> "jakość" całki numerycznej nie zależy od rzędu kwadratury
>
> (Newtona-Cotesa, czyli tych zwykłych, kawałkami wielomianów).
>
> Wszytko rzędu wyższego niż "trapezy" miało być przereklamowanymi
>
> akademickimi bredniami nie dającymi poprawy wyniku względem
>
> metody trapezów:)

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.

--
Edek

do góry

Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
dyskusyjnych:k7dilq$dcv$...@n...task.gda.pl...
> Gdyz stworzenie plac (i nie tylko) tak naprawde bardzo malo zalezy od
> narzedzi
> i tzw inzynierii programowania (no fakt ze dzis uzylbym po prostu Pythona
> jako
> embedded jezyka do algorytmow placowych, a nie tego ktory byl -
> dosc paskudny:) ale to szczegol).

Inżynieria to nie Pajton czy Algol 60. Ale trudno wymagać od leśnego dziadka
aby naraz wskoczył w agile.

> Wlasnie ten NDP swietnie wspolpracowal/byl dedykowany dla koproc. Weitek
> gdzie Twoje "problemy" DBL_EPSILON wzielo by w leb calkiem.

No cóż, niektórzy mieli naście T-800. Zazdrościłbyś.

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
dyskusyjnych:k7dcs5$7of$...@m...internetia.pl...
> "ma się na myśli" == "większość ludzi wiedzących czym jest pierwiastek ma
> na myśli..." Lepiej?

Niebardzolepiej.

Większość uważała że Kopernik nie miała racji (bo była kobietą!) I co
robimy?!

do góry