Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:

> Jakie ma znaczenie, co ja proponuję? Mówimy o kursach na renomowanych uczelniach
amerykańskich.
> One zakładają co najmniej, że student skończył szkołę średnią i że był "dobry z
matmy".

Z tym sie zgadzam w pelni.

AK

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:

> Owszem, są to jzyki oparte na scheme, ale chyba żaden z nich nie ma
> pełnego zestawu ficzerów Scheme-a

Czyli jednak Lisp. Wiec do kosza z nim.

AK

do góry

Dnia Thu, 26 Jul 2012 08:30:11 +0000, Stachu 'Dozzie' K. napisal:

> Nie. Brak kwantyfikatora egzystencjalnego oznacza, że twierdzenie jest
> ogólnie prawdziwe, czyli dotyczy *wszystkiego*, co wtedy opracowano.

Jak w zdaniu "koty są kapryśne"? Przestań.

Edek

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Dnia Thu, 26 Jul 2012 09:10:25 +0200, AK napisal:
> Nie byłem po marysze jak chciałem napisać własny parser. Follow-sets
> były szybko oczywiste, zacząłem bottom-up, doszedłem do różnic
> pomiędzy LALR(1) i LR(1), być może nie wszystkich, i do parse dag
> w GLR. Potem dopiero przeczytałem, co to jest bottom-up i że
> to ma takie fikuśne nazwy jak LR(1) i ze ładnie się to
> przedstawia w postaci tabelek. GLR jest z 1984.

No to i tak jestes do przodu bardzo bo ja nie znam nawet podstaw
formalnych zarowno LALR(1) czy innego LR czy LL(1/n), a nawet GLR
ale znam skutki z nich wynikajace dla parsera i dlatego piszac swoje
parsery korzystam z metody GLR (a nawet scannerless GLR).

> Niektórzy mam wrażenie mają lekko psychopatyczne podejście
> do nauki programowania, niczym "Jasiu, nie pobawisz się klockami
> Lego, bo nie znasz rachunku tensorowego naprężeń. Przecież ty
> nawet nie będziesz wiedział, dlaczego klocki Lego się trzymają
> złączone"

No.. tu sie zgadzam w 100%.
Nie ma co demonizowac programowania.

Zawsze (moze to A.L. potwierdzic) wyraznie rozroznialem informatyka
(tego od "tensorow") od programisty (co nie znaczy ze z rachunkiem
tensorowym nie trzeba bylo sie nieco kiedys zaznajomic: mechanika
na studiach u prof.Lambera + programowanie zwiazane dosc scisle
z wytrzymaloscia materialow).
Programista musi byc _otwarty_ na nauke nawet skomplikowanej
matematyki (jak zreszta wszytskiego:), ale nie ma co robic z niego
kogos kto "rzuca dowodami matematycznymi" z rekawa.
Ta szersza/teoretyczna wiedze niekoniecznie trzeba od razu miec
(zwlaszcza dzis gdy programowanie spsialo i 99% roboty to
przemiatanie rekordami i ekranami), ale trzeba umiec szybko ja
nabyc gdy zaistnieje potrzeba.

PS: Slowem: dla programisty najwazniejsze jest _umiec maksymalnie
skorzystac_ z wiedzy i pracy innych/madrzejszych (no i oczywiscie
samemu juz wylacznie spic smietanke w postaci sowitej wyplaty -
ta ostatnia uwaga dedykowana szczegolnie dla naszegoKochanego Fira ;)

AK

do góry

W dniu 2012-07-26 10:29, AK pisze:
> Użytkownik "Piotr Chamera" <p...@p...onet.pl> napisał:
>> (setq r
>> (let* ((a 8)
>> (b (+ a 7))
>> (c 12)
>> (d 2))
>> (* (+ a b) (- c d))))
>
> Ano wlasnie. Klucz to let* (wymusza sekwencyjnosc)
> Tylko:
> 1. wytlumacz to poczatkujacemu
> 2. Czy nie moglby sobie sam Szanowny Kompilator sprawdzic
> zaleznosci i wylaczyc te ktore sa od siebie zalezne ze
> swej "rownoleglosci" ?
>
>> A teraz może podaj odpowiednik tego kodu w Pythonie,
>> bo to poniżej to nie jest to samo:
>>
>> a = 8
>> b = a + 7
>> c = 12
>> d = 2
>> r = a + b * c + d
>
> A dlaczegoz to Kolega zgubil nawiasy i (pomylil znak, rozumiem ze typo) ?
> Przeciez to wbrew matematyce
> Winno byc: r = (a + b) * (c - d)

oczywiście...
wklepałem to na szybko, żeby pokazać przykład, w którym
a,b,c,d są ,,globalne" - nie wiem, jak to zapisać w Pythonie tak, aby
nie były widoczne poza zasięgiem, w którym są potrzebne i żeby nadal
było czytelnie.

> Troche bardziej skomplikowane wyrazenia w Lispie wygladaja _koszmarnie_
> (wiem co mowie bo conieco - bardzo malo - "robilem" w Lispie do AutoCada

mogę się zgodzić, chociaż bardziej skomplikowane wyrażenia matematyczne
wyglądają źle w prawie każdym języku programowania...

> PS: W samych poczatkach mego programowania spotkalem sie z programowalnymi
> kalkulatoramio HP (nie te "reczne" ale takie wielkosci dzisiejszego PCta
> z tzw.
> cartridges jako medium). Tam wszytsko bylo w odwrotnej notacji polskiej
> (wiadomo z jakiego powodu) a i programy byly naprawde nietrywialne
> (glownie numeryka oczywiscie). Jednak _w zyciu_ nie polecil bym tego
> poczatkujacym ktorzy znaja normalna arytmetyke/matematyke.
>
> PS1: To wbrew pozorom tez tyczy "modelowania rzeczywistosci".
> Arytmetyka w Pythonie czy Javie czy inny C++ nawet "modeluje"
> dobrze rzeczywistosc (czyli normalna matematyke), a Lisp wprowadza
> abstrakt (owszem wtedy jest "spojnosc skladniowo/paradygmatowa"
> tylko ze ana tylko sama sobie sie chyba podoba :)

utożsamianie matematyki i arytmetyki komputerów to jest takie budowanie
na złudzeniach, potem ludzie dziwią się, że:
>>> 10.0 - 9.0 == 1.0
True
>>> 10.0 * (1.0 - 0.9) == 1.0
False

do góry

Piotr Chamera <p...@p...onet.pl> wrote:
> W dniu 2012-07-26 10:29, AK pisze:
>> Użytkownik "Piotr Chamera" <p...@p...onet.pl> napisał:
>>> (setq r
>>> (let* ((a 8)
>>> (b (+ a 7))
>>> (c 12)
>>> (d 2))
>>> (* (+ a b) (- c d))))
>>
>> Ano wlasnie. Klucz to let* (wymusza sekwencyjnosc)
>> Tylko:
>> 1. wytlumacz to poczatkujacemu
>> 2. Czy nie moglby sobie sam Szanowny Kompilator sprawdzic
>> zaleznosci i wylaczyc te ktore sa od siebie zalezne ze
>> swej "rownoleglosci" ?
>>
>>> A teraz może podaj odpowiednik tego kodu w Pythonie,
>>> bo to poniżej to nie jest to samo:
>>>
>>> a = 8
>>> b = a + 7
>>> c = 12
>>> d = 2
>>> r = a + b * c + d
>>
>> A dlaczegoz to Kolega zgubil nawiasy i (pomylil znak, rozumiem ze typo) ?
>> Przeciez to wbrew matematyce
>> Winno byc: r = (a + b) * (c - d)
>
> oczywiście...
> wklepałem to na szybko, żeby pokazać przykład, w którym
> a,b,c,d są ,,globalne" - nie wiem, jak to zapisać w Pythonie tak, aby
> nie były widoczne poza zasięgiem, w którym są potrzebne i żeby nadal
> było czytelnie.
... wpakowac to do procedury;-) Z powazaniem
Adam Przybyla

do góry

On Thursday, 26 July 2012 09:33:23 UTC+1, AK wrote:
>
> Czyli jednak Lisp. Wiec do kosza z nim.

Z przekonaniami religijnymi nie dyskutuję.

do góry

Użytkownik "Piotr Chamera" <p...@p...onet.pl> napisał:

> a,b,c,d są ,,globalne" - nie wiem, jak to zapisać w Pythonie tak, aby
> nie były widoczne poza zasięgiem, w którym są potrzebne i żeby nadal było
czytelnie.

Dokladnie tak jak wyzej. Wtedy widoczne sa tylko w aktualnym zasiegu.
Aby byly traktowane jako globalne trzeba by je wczesniej zadeklarowac
instrukcja: global

> utożsamianie matematyki i arytmetyki komputerów to jest takie budowanie
> na złudzeniach, potem ludzie dziwią się, że:
> >>> 10.0 - 9.0 == 1.0
> True
> >>> 10.0 * (1.0 - 0.9) == 1.0
> False

Ano jasne, ze pewna wiedze programistyczana trzeba miec
(nie mowie o Tobie :) mowie ogolnie).
To nie sa zludzenia tylko wlasnie zwykly brak dosc podstawowej
wiedzy programistycznej (skutkujacy nieskonczonymi dyskusjami jakie
to float jest be itp).
Tymczasem w pierwszej ksiazce jaka o programowaniu przeczytalem:
chyba "Algorytmy numeryczne w jezyku Algol60" prof. Sysło
na chyba drugiej stronie w algorytmie symplex stalo jak byk
abs(a - b) <= EPS.
Od lat tez gdzie moge to "sieję" ta wiedze na usenecie, ze floatow
nie mozna porownywac wprost (i to bez wzgledu na ich format)
_z powodu ich natury_ (dwojkowosc, skonczona/ogramiczona dokladnosc).
Czyli z floatami/doublami i innymi realami tylko tak:

nie tak
a == b abs(a - b) <= EPS
a != b abs(a - b) > EPS
a < b (a - b) < -EPS
a <= b (a - b) <= EPS
a > b (a - b) > EPS
a >= b (a - b) >= -EPS

Python posiada jednak standardowy typ decymalny:
>>> Decimal('10.0') * (Decimal('1.0') - Decimal('0.9')) == Decimal('1.0')
True

AK

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:

>> Czyli jednak Lisp. Wiec do kosza z nim.

> Z przekonaniami religijnymi nie dyskutuję.

Wlasnie z powodu przekonania religijnego, ze "Lisp jest super"
(choc rzeczywistosc temu przeczy) proponuję wyrzycic ten jezyk do kosza.
Zwlaszcza poczatkujacym

AK

do góry

AK <n...@n...com> napisał(a):

> Użytkownik "Edek Pienkowski" <e...@g...com> napisał:
>
> > Dnia Thu, 26 Jul 2012 09:10:25 +0200, AK napisal:
> > Nie byłem po marysze jak chciałem napisać własny parser. Follow-sets
> > były szybko oczywiste, zacząłem bottom-up, doszedłem do różnic
> > pomiędzy LALR(1) i LR(1), być może nie wszystkich, i do parse dag
> > w GLR. Potem dopiero przeczytałem, co to jest bottom-up i że
> > to ma takie fikuśne nazwy jak LR(1) i ze ładnie się to
> > przedstawia w postaci tabelek. GLR jest z 1984.
>
> No to i tak jestes do przodu bardzo bo ja nie znam nawet podstaw
> formalnych zarowno LALR(1) czy innego LR czy LL(1/n), a nawet GLR
> ale znam skutki z nich wynikajace dla parsera i dlatego piszac swoje
> parsery korzystam z metody GLR (a nawet scannerless GLR).
>
> > Niektórzy mam wrażenie mają lekko psychopatyczne podejście
> > do nauki programowania, niczym "Jasiu, nie pobawisz się klockami
> > Lego, bo nie znasz rachunku tensorowego naprężeń. Przecież ty
> > nawet nie będziesz wiedział, dlaczego klocki Lego się trzymają
> > złączone"
>
> No.. tu sie zgadzam w 100%.
> Nie ma co demonizowac programowania.
>
> Zawsze (moze to A.L. potwierdzic) wyraznie rozroznialem informatyka
> (tego od "tensorow") od programisty (co nie znaczy ze z rachunkiem
> tensorowym nie trzeba bylo sie nieco kiedys zaznajomic: mechanika
> na studiach u prof.Lambera + programowanie zwiazane dosc scisle
> z wytrzymaloscia materialow).
> Programista musi byc _otwarty_ na nauke nawet skomplikowanej
> matematyki (jak zreszta wszytskiego:), ale nie ma co robic z niego
> kogos kto "rzuca dowodami matematycznymi" z rekawa.
> Ta szersza/teoretyczna wiedze niekoniecznie trzeba od razu miec
> (zwlaszcza dzis gdy programowanie spsialo i 99% roboty to
> przemiatanie rekordami i ekranami), ale trzeba umiec szybko ja
> nabyc gdy zaistnieje potrzeba.
>
> PS: Slowem: dla programisty najwazniejsze jest _umiec maksymalnie
> skorzystac_ z wiedzy i pracy innych/madrzejszych (no i oczywiscie
> samemu juz wylacznie spic smietanke w postaci sowitej wyplaty -
> ta ostatnia uwaga dedykowana szczegolnie dla naszegoKochanego Fira ;)
>
kwestia wątpliwą jest słowo 'naszego' ;-) bo o ile ktos umialby napisac
cos z sensem na temat to moglbym ew tez popisac na temat,
z kolei poswiecanie mojej dalszej uwagi tutejszym tluczkom raczej nie
wchodzi mi w rachube ;-) -

drugie scisle rzecz biorac nie wyklucza pierwszego ale jest jeszcze
kwestia czy faktycznie nie lepiej bym zrobil poswiecajac swoj czas
jakims madrzejszym zajeciom niz tutaj :O


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry