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

>> MonreCarlo w poblizu "miejsca chwilowego postoju".
>
> Monte Carlo. I tych metod Monte Carlo też jest więcej niż jedna.

No cos podobnego ? !
Naprawde ?

>
>> Ciagle sie sprawdzalo jakis roznice, kroki itp (sorry malo co pamietam
>> bylo to 30 lat temy tak tak, jeszcze na Odrze :)
>
> 30 lat temu był już i CDC6000 (MINUIT) i PDP-11.
> Ale oczywiście mogłeś się z tym sprzętem nie stykać.

Alez oczywiscie ze z tym drugim sie spotkalem _w praktyce_ (a ten pierwszy mial
9bitowy
bajt i byl bardzo Algolowaty :).
RTX zeby wybijal, ale np. PDP-11 mialo naprawde swietny (strukturalny) Basic i nie
tylko.

AK

do góry

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

> O, ciekawe, ciekawe... widać że "expert" potrafi obrabiać powierzchnie idealnie na
glacę i to bez
> nadtapiania.

Alez owszem palancie.

Zanim zostalem programista, pracowalem ponad rok
na obrabiarkach numerycznych w WSK-Rzeszow.
Ok 20% tych prac to byly rzeczy dla Pratt&Withney.
Reszta dla sovietow (pomine milczeniem wiec:)

Pikanterii sprawie dodaje fakt ze po przejsciu do ETO
(nie chcialem jednak cale zycie spedzic przy obrabiarce -
nawet numerycznej:) i piszac m.in. programy (postprocerory itp)
na te obrabiarki zarabialem dokladnie 3 razy mniej niz jako akordowy wyrobnik :)
To taki wtret dla tych dzisiejszych roznych lemingow/siekierowskich/palikmiotow
co dzis czuja znow miete do komuny wszelakiej tudziez "cywilizacji wschodniej" :))

AK

do góry

On 06.11.2012 21:50, slawek wrote:
>
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
> dyskusyjnych:k7bs5k$6o1$...@m...internetia.pl...
>> Walnąłeś jak dzik w sosnę. Tu nie potrzeba BCD (chociaż oczywiście
>> można je użyć) a jedynie reprezentacji fixed point.
>
> Skoro można - to dlaczego ich nie używać?

Bo zazwyczaj zajmują więcej miejsca i gorzej się pakują w bazy danych.
Jak masz wsparcie od bazy danych to nie ma problemu, ale jak nie masz to
robią się jazdy żeby liczyć proste rzeczy w bazie.

> Zwykłe fixed point z base 2
> będą kłopotliwe.

BCD też będą.

> BCD ułatwią sztywne trzymanie się głupawek w rodzaju:
> "zaokrąglamy w górę do pełnych 10 gr".

Musisz do tego napisać funkcję. Czy będzie ona dla BCD, czy dla FP - to
już niewielka różnica.

> I oczywiście CPU ma pełen zestaw
> instrukcji obsługujących BCD.

Gorzej ze wsparciem. Do tego nie byłbym taki pewien, czy ten system
będzie uruchamiany na x86, albo czy tylko na x86.

> Ale oczywiście - można też po prostu
> zapisywać wszystko jako zwykły tekst (XML ?!)

Co jest chyba najgłupszym pomysłem zaraz po kodowaniu termometrowym.

--
Pozdrawiam
Michoo

do góry

On 2012-11-06, Michoo <m...@v...pl> wrote:
>> Ale oczywiście - można też po prostu
>> zapisywać wszystko jako zwykły tekst (XML ?!)
>
> Co jest chyba najgłupszym pomysłem zaraz po kodowaniu termometrowym.

XEP któryś-tam (nie pamiętam numeru) postulował, żeby dane przesyłane
protokołem XMPP kodować binarnie w XML-u: za pomocą <one/> i <zero/>.
Jedną z zalet miała być genialna wprost kompresowalność tak zapisanych
danych.

--
Secunia non olet.
Stanislaw Klekot

do góry

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.

Pierwiastkiem kwadratowym z 4 jest i 2 i -2 co wybierasz?

--
Pozdrawiam
Michoo

do góry

Użytkownik "kenobi" <p...@g...com> napisał;

>> A BCD buraku cokolwiek ci gwarantuja ?
>
>żeby sparafrazowac AL 'kolega to chyba powinien jednak siedziec w zoo'

Wiesz co firku ? Zanim znow ci sie czyms niestrawnym nie odbije,
obok tego dzis trupka Borlanda zainstaluj sobie Pythnona i sprawdz
w praktyce ta przez was ze slawkiem wychwalana/wybajana niezawodnosc
i idealnosc reprezentacji decymalnej w stosunku do fp.

PS: Poniewaz moze ci to zajac tygodnie "na szybko" pomoge:

>>> from decimal import Decimal
>>> a = Decimal("1.0")
>>> b = Decimal("3.0")
>>> a/b*b
Decimal('0.9999999999999999999999999999')
>>> (a/b*b) == a
False
>>> a1 = 1.0
>>> b1 = 3.0
>>> (a1/b1*b1) == a1
True

Wyniki (w tym przypadku na korzysc zwyklego fp) jakby przecza kolejnej
waszej "jedynie slusznej" buraczanej teorii.
No ale poczekam, az rozkimisz to w assembler i przepchniesz do ogla :)

AK

do góry

Użytkownik "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid> napisał:

>> Co jest chyba najgłupszym pomysłem zaraz po kodowaniu termometrowym.
>
> XEP któryś-tam (nie pamiętam numeru) postulował, żeby dane przesyłane
> protokołem XMPP kodować binarnie w XML-u: za pomocą <one/> i <zero/>.
> Jedną z zalet miała być genialna wprost kompresowalność tak zapisanych
> danych.

Whuhehehe :) Dobre ! :))

AK

do góry

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.

> 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 (liczb zespolonych). To nie jest
tak że "wybierasz" któryś z nich żeby był wynikiem działania.

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

--
Secunia non olet.
Stanislaw Klekot

do góry

Użytkownik "AK" <n...@n...com> napisał w wiadomości grup
dyskusyjnych:k7c2fg$oj2$...@n...task.gda.pl...
> Wiesz co firku ? Zanim znow ci sie czyms niestrawnym nie odbije,
> obok tego dzis trupka Borlanda zainstaluj sobie Pythnona i sprawdz
> w praktyce ta przez was ze slawkiem wychwalana/wybajana niezawodnosc
> i idealnosc reprezentacji decymalnej w stosunku do fp.

Czy istnieje język Pythnon ?

> No ale poczekam, az rozkimisz to w assembler i przepchniesz do ogla :)

Zdziwisz się jeżeli napiszę, że pooglądałem wynik kompilacji 1.0+x > 1.0,
tj. rozkazy dla procesora jakie generuje kompilator MS?

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości grup
dyskusyjnych:k7c2nh$7ob$...@m...internetia.pl...
> 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.

Łatwiej mi z C niż z R. Po konturach można liczyć. I nie pisz "ma się na
myśli" - jeżeli nie słyszysz co ja i/lub Fir myślimy.

> Pierwiastkiem kwadratowym z 4 jest i 2 i -2 co wybierasz?

Oba.

do góry