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

>> Co mi sie zdaje ze zwyczajnie stulasz z tym bledem dzielenia.
>
> Wydaje ci się. Raz jeszcze był ten błąd: ale tylko gdy dzieliło się unsigned long
int przez
> singned short int (lub coś w ten deseń).

A gdy dzielilo sie unsigned long int przez unsigned int to juz nie ?
Stulasz wasc hrabio i zmyslasz !.
Konkret (kawalek kodu) prosze.

>> No.. Juz minelo ok 20 lat, a dzis Asseco to wlasciwie koncern miedzynarodowy
>
> Gdzie ja czytałem, że właśnie położyło przetarg?

A ja "gdzies" cztalem ze wlasnie wygralo przetarg. :)
Slawciu ty jednak jestes supoer burakiem :)

PS: Tak Ci wrzuce nastepny z fp.
Przed praca dla Asseco programowalem przez ponad pol roku
system placowy dla Zelmeru. Problem byl potezny.
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 :)
No i znow wszystko bylo oparte na double.
Wpierw napisane w Aztech C, potem w Borlandzie.
Zapewniam cie ze maly blad zaokraglen na 2miejsccu po przecinku
skutkowal by powazniejszymi konsekwencjami niz taka pomylka
w bilansie banku. Jak myslisz. Dlaczego ?
No ale jeszcze "dycham" wiec chyba jednak jakos te "Płace" dzialaly
(a moze i jeszcze dzialaja). No i ?
PS: Ta praca to byla moja prawdziwa "inicjacja zawodowa".
20ścia Pań "od płac" i nas dwóch biednych/skazańców.
Uj cieżko nam było coś JEDNOZNACZNIE ustalić ;)
No ale potem już niczego sie w "informatyce" nie bałem ;)

>> Domyslasz sie po co ?
> Po to aby niedouczony programista nie musiał używać uint64_t ?

Na 16 bitowym DOSie miales jakis odpowiednik uit64 ?
Oj boroku boroku :)

AK

do góry

On 06.11.2012 23:25, Stachu 'Dozzie' K. wrote:
> On 2012-11-06, Michoo<m...@v...pl> wrote:
>> On 06.11.2012 21:22, slawek wrote:
>>>
>>> Użytkownik "Roman W"<r...@g...com> napisał w wiadomości
>>> grup dyskusyjnych:fee65c5e-a1cb-46eb-937f-d76ea835b36f@go
oglegroups.com...
>>>> Zgoda. Ale nadal twierdze, ze wyciaganie pierwiastka z ujemnej liczby
>>>> to zly pomysl.
>>>
>>> Dobry pomysł panocku, ino nijak nie idzie rozeznać, który potem wybrać.
>>
>> Jeżeli musisz wybierać to bardzo ZŁY.
>>
>> Założenie jest takie, że mówiąc po prostu o pierwiastkach ma się na
>> myśli _nieujemny_ pierwiastek _całkowitego_ stopnia _nieujemnej_ liczby
>> rzeczywistej.
>
> Uwaga na nisko przelatujące przypadki egzotyczne. Pierwiastki
> arytmetyczne stopni nieparzystych są dobrze określone również dla liczb
> ujemnych.

Parzyste też, tyle, że wynik jest zespolony. Śmiesznie się robi dopiero
przy niewymiernych.

>
>> Pierwiastkiem kwadratowym z 4 jest i 2 i -2 co wybierasz?
>
> Źle myślisz. Pierwiastek (algebraiczny) stopnia całkowitego n z liczby
> k to tak naprawdę *zbiór* n-elementowy

O, rly?

> (liczb zespolonych).

W przypadków dziedziny R+ przeciwdziedzina to też R+. Liczby zespolone
są uogólnieniem tego co było początkowo definiowane na R+.

> To nie jest
> tak że "wybierasz" któryś z nich żeby był wynikiem działania.

Ale czep się sławka - ja właśnie napisałem, że jak coś "wybiera" to coś
nie halo.


>
> Tylko że chyba niewiele kodu numerycznego przewiduje pracę z funkcjami
> o sygnaturze f:R->2^R.
>

Skąd wracamy do tego, że interesuje nas "domyślnie" R+. R- i n
nieparzyste jest specyficznym przypadkiem rozpatrywanym na podstawie
nthroot(-r,n)==-1*nthroot(r,n).

--
Pozdrawiam
Michoo

do góry

On 06.11.2012 23:57, slawek wrote:
>
> I nie pisz "ma się na
> myśli" - jeżeli nie słyszysz co ja i/lub Fir myślimy.

Na szczęście nie wiem.

"ma się na myśli" == "większość ludzi wiedzących czym jest pierwiastek
ma na myśli..." Lepiej?

--
Pozdrawiam
Michoo

do góry

On 06.11.2012 21:39, slawek wrote:
>> Jeżeli dokładność jest większa to nie jest to problem, chyba, że
>
> Jest problem. Duży. Po prostu wyniki przestają być przewidywalne i
> powtarzalne.
[...]
>
> Wystarczy że ten sam program ktoś skompiluje trochę inaczej, ba, może to
> być nawet ten sam kompilator ale w nieco nowszej wersji. Raz jest dobrze
> (bo miałeś "trochę lepiej") - a potem nagle okaże się, że jednak jest
> źle (bo tym razem nie chciało być "trochę lepiej").

Masz po prostu błędny program jeżeli drobne błędy przybliżeń związane z
użytym typem danych sprawiają, że raz on działa a raz nie.

--
Pozdrawiam
Michoo

do góry

Użytkownik "AK" napisał w wiadomości grup
dyskusyjnych:k7d6sa$cqc$...@n...task.gda.pl...

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

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

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.

>No ale jeszcze "dycham" wiec chyba jednak jakos te "Płace" dzialaly

No, taki Zelmer to ogólnie wiodąca firma na rynku, słyszałem że wykupi
Hoovera.

>PS: Ta praca to byla moja prawdziwa "inicjacja zawodowa".
>20ścia Pań "od płac" i nas dwóch biednych/skazańców.

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

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

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

do góry

W dniu wtorek, 6 listopada 2012 20:36:36 UTC użytkownik Michoo napisał:
> On 06.11.2012 21:03, slawek wrote:
>
> > 2. Nie jest dobra implementacja, w której a = b nie gwarantuje potem a
>
> > == b. Oczywiście to samo dla a = b, c = b, sprawdzamy a == c . Zła
>
> > implementacja - i nawet "protezy" w rodzaju "epsilonowania" każdego
>
> > porównania liczb rzeczywistych niewiele pomagają.
>
>
>
> Udajesz, że nie rozumiesz problemu. ;)
>
>
>
> Jeżeli a==b i c==b to a==c. Ale jeżeli a, b i c to wyniki trzech różnych
>
> obliczeń których wartością jest ta sama liczba rzeczywista a niektóre
>
> wyniki pośrednie nie są reprezentowane _dokładnie_ w użytym typie danych
>
> otrzymujesz trzy wartości różne binarnie, ale równe logicznie. Od tego
>
> jest "epsilonowanie", żeby w toku obliczeń też były traktowane jako równe.

Co - powtorze sie - nie zawsze jest tym, co chcemy osiagnac.

RW

do góry

W dniu wtorek, 6 listopada 2012 21:47:36 UTC użytkownik AK napisał:
> Użytkownik "slawek" <s...@h...pl> napisał w wiadomości:
>
>
>
> > Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
>
> > dyskusyjnych:k7bbgo$pth$...@n...task.gda.pl...
>
> >> PS: jeszcze pamietam, ze np w metodach optymaliacji gradientowych
>
> >
>
> > Zdecydowanie przereklamowanych.
>
>
>
> Metoda zmiennej metryki Wolfa-Broydena-Davidona byla wtedy
>
> i wierze ze jest i dzis) jedna z najwydajniejszych ogolnych metod optymalizacji.
>
> Jest przewage/pierwszenstwo w tej rodzinie nad innymi udowodnino nawet
>
> teoretycznie.
>
> Przynajmniej tak pisali Panowie Szymanowsk Findeisen i Wierzbicki.
>
> Poza tym ze bylo to metody kwadratowe w stosunku do zwyklego gradientu
>
> to jeszcze naprawde przykladowo wrecz eleganckie matematycznie.
>
>
>
> Nie twierdze ze tak jest dzis, ale poprosze o _konkretny przyklad_
>
> lepszych dzis numerycznych metod optymalizacji w stosunku do tych
>
> "przereklamowanych".

Ja sie na tym slabo znam, ale zdaje sie ze ktora metoda jest lepsza, to zalezy od
problemu. Jakis czas temu ktos mi polecal (nie pamietam dlaczego) metode
Gaussa-Newtona.

Zdaje sie, ze naprawde ciekawe sa problemy z wiezami, a tam jest duzo trudniej...

RW

do góry

W dniu wtorek, 6 listopada 2012 23:29:46 UTC użytkownik slawek 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.

Moze na uniwersytecie nie ma.

RW

do góry

Użytkownik "Roman W" <r...@g...com> napisał:

> Ja sie na tym slabo znam, ale zdaje sie ze ktora metoda jest lepsza, to zalezy od
problemu.

Alez oczywiscie. Rzeklbym nawet BAARDZO/SCISLE zalezy.
Tylko ze slawcio mysli "uniwersalnie" :). Jak z tym DBL_EPSILON.

> Zdaje sie, ze naprawde ciekawe sa problemy z wiezami, a tam jest duzo trudniej...

Wiezami ? Nie rozumiem (zapomnialem juz kompletnie i matme i numeryke).

AK

do góry

W dniu 2012-11-07 12:32, AK pisze:
> Użytkownik "Roman W" <r...@g...com> napisał:
>> Zdaje sie, ze naprawde ciekawe sa problemy z wiezami, a tam jest duzo
>> trudniej...
>
> Wiezami ? Nie rozumiem (zapomnialem juz kompletnie i matme i numeryke).

Szukasz ekstremum F(x), przy założeniach
G(x)=0 i h(x)>=0

Jak wszytko jest liniowe, to prosto.

Tylko z pierwszym warunkiem można próbować zmienić
układ współrzędnych na zgodny z G (czasem się da).

Jeśli zbiór dozwolony z warunków h i g jest spójny i wypukły,
nadal nie jest źle... ;-)

pzdr
bartekltg

do góry