🚀 go-pugleaf

> Ktoś tu zagląda,

Tak.

> czy trzeba szukać jakiegoś forum?

Nie wiem, nie korzystam.

> Zaczynam z Pythonem i badam grunt gdzie by tu można podpytać o podstawy 
> podstaw. :-)

Podstawy podstaw są w podręcznikach i wielu miejscach w sieci (np na StackOverflow - jeśli znasz trochę angielski - bo bez tego było by ciężko).
Gdy tam nie znajdziesz odpowiedzi to pytaj tu śmiało.

> Właśnie jadę do księgarni zobaczyć czy coś kupię od ręki z półki.

Błąd! Teraz szuka się książek na stronach wydawnictw (Helion i PWN) - bo tam jest największy wybór...

W dniu 2018-02-09 o 11:05, szykcech@gmail.com pisze:
> Teraz szuka się książek na stronach wydawnictw (Helion i PWN)
Przeglądałem i coś znalazłem. Ale chcę ją zaraz i dlatego księgarnia.
Helionu widziałem jakąś pozycję. Ja osobiście wolę papierową książkę.
Tak w ogóle to chcę pomóc synowi (11 lat) a ja zatrzymałem się na 
Basic-u w ZX Spectrum. :-)

Robert

On Fri, 9 Feb 2018 11:22:12 +0100,
Robert Wańkowski <robwan@wp.pl> wrote:
> W dniu 2018-02-09 o 11:05, szykcech@gmail.com pisze:
>> Teraz szuka się książek na stronach wydawnictw (Helion i PWN)
> Przeglądałem i coś znalazłem. Ale chcę ją zaraz i dlatego księgarnia.
> Helionu widziałem jakąś pozycję. Ja osobiście wolę papierową książkę.
> Tak w ogóle to chcę pomóc synowi (11 lat) a ja zatrzymałem się na 
> Basic-u w ZX Spectrum. :-)
>
> Robert

Biorąc pod uwagę ile jest doskonałych materiałów w sieci na temat
Pythona po angielsku (tutoriale na YT) może lepszą pomocą
byłyby korepetycje z języka angielskiego niż książa nt Pythona?

Pozdrawiam,
-A.

On Fri, 9 Feb 2018 11:22:12 +0100, Robert Wańkowski wrote:

>> Teraz szuka się książek na stronach wydawnictw (Helion i PWN)
> Przeglądałem i coś znalazłem. Ale chcę ją zaraz i dlatego księgarnia.
> Helionu widziałem jakąś pozycję. Ja osobiście wolę papierową książkę.
> Tak w ogóle to chcę pomóc synowi (11 lat) a ja zatrzymałem się na 
> Basic-u w ZX Spectrum. :-)

Akurat dziś do północy na Helionie jest promo na chyba dobrą pozycję dla
Was:

https://helion.pl/ksiazki/przewodnik-po-pythonie-dobre-praktyki-i-praktyczne-narzedzia-kenneth-reitz-tanya-schlusser,przepy.htm

ps. syn coś już kuma czy start z poziomu zero?

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-02-09 o 12:55, Roman Tyczka pisze:
> On Fri, 9 Feb 2018 11:22:12 +0100, Robert Wańkowski wrote:
> 
>>> Teraz szuka się książek na stronach wydawnictw (Helion i PWN)
>> Przeglądałem i coś znalazłem. Ale chcę ją zaraz i dlatego księgarnia.
>> Helionu widziałem jakąś pozycję. Ja osobiście wolę papierową książkę.
>> Tak w ogóle to chcę pomóc synowi (11 lat) a ja zatrzymałem się na
>> Basic-u w ZX Spectrum. :-)
> 
> Akurat dziś do północy na Helionie jest promo na chyba dobrą pozycję dla
> Was:
> 
> https://helion.pl/ksiazki/przewodnik-po-pythonie-dobre-praktyki-i-praktyczne-narzedzia-kenneth-reitz-tanya-schlusser,przepy.htm
> 
> ps. syn coś już kuma czy start z poziomu zero?

Dziękuję za link.
Raczej poziom zero. Z tego co widziałem po pierwszym dniu, to w oknie 
(graficznym?) widziałem jakieś przyciski, które zliczały kliknięcia. :-) 
Czyli jakaś pętla.

Martwi mnie to, że oczekuje szybkich postępów. Chce już widzieć jakąś 
grafikę.
Mi z czasów ZX Spectrum dawało ogromną satysfakcję napisanie programu na 
obliczanie powierzchni prostokąta. :-)

Robert

On Fri, 9 Feb 2018 13:11:39 +0100, Robert Wańkowski wrote:

>> ps. syn coś już kuma czy start z poziomu zero?
> 
> Dziękuję za link.
> Raczej poziom zero. Z tego co widziałem po pierwszym dniu, to w oknie 
> (graficznym?) widziałem jakieś przyciski, które zliczały kliknięcia. :-) 
> Czyli jakaś pętla.
> 
> Martwi mnie to, że oczekuje szybkich postępów. Chce już widzieć jakąś 
> grafikę.
> Mi z czasów ZX Spectrum dawało ogromną satysfakcję napisanie programu na 
> obliczanie powierzchni prostokąta. :-)

Mój syn, teraz 10 letni, ze dwa lata temu też zapragnął "programować", ale
nie pchałem go w takie rzeczy jak basic czy nawet python, to dobre na drugi
etap. Na początek, tak jak piszesz, oni chcą od razu grafikę.
Kiedyś było Logo, ale jakby zapomniał o nim świat. Za to teraz są inne
możliwości. Jest Baltie i Scratch. Tego pierwszego nie tykałem, ale drugi
jest całkiem fajny. Programowanie polega na układaniu klocków będących
elementami programowania, czyli klocek JEŻELI, klocek PĘTLA itd.

Na początek pozwala zrozumieć o co chodzi i myśleć jak programista, jak to
zakuma to z Pythonem czy czymkolwiek innym będzie z górki (o ile starczy
cierpliwości! mojemu zabrakło ;-)

https://scratch.mit.edu/

zakładasz konto i tworzycie z poziomu www lub instalujesz zintegrowane
środowisko w systemie, do wyboru. Materiałów jest full, ponadto z tego co
mi wiadomo zaczynają też w szkołach tego uczyć.

-- 
pozdrawiam
Roman Tyczka

W dniu 2018-02-09 o 13:33, Roman Tyczka pisze:
> On Fri, 9 Feb 2018 13:11:39 +0100, Robert Wańkowski wrote:
> 
>>> ps. syn coś już kuma czy start z poziomu zero?
>>
>> Dziękuję za link.
>> Raczej poziom zero. Z tego co widziałem po pierwszym dniu, to w oknie
>> (graficznym?) widziałem jakieś przyciski, które zliczały kliknięcia. :-)
>> Czyli jakaś pętla.
>>
>> Martwi mnie to, że oczekuje szybkich postępów. Chce już widzieć jakąś
>> grafikę.
>> Mi z czasów ZX Spectrum dawało ogromną satysfakcję napisanie programu na
>> obliczanie powierzchni prostokąta. :-)
> 
> Mój syn, teraz 10 letni, ze dwa lata temu też zapragnął "programować", ale
> nie pchałem go w takie rzeczy jak basic czy nawet python, to dobre na drugi
> etap. Na początek, tak jak piszesz, oni chcą od razu grafikę.
> Kiedyś było Logo, ale jakby zapomniał o nim świat. Za to teraz są inne
> możliwości. Jest Baltie i Scratch. Tego pierwszego nie tykałem, ale drugi
> jest całkiem fajny. Programowanie polega na układaniu klocków będących
> elementami programowania, czyli klocek JEŻELI, klocek PĘTLA itd.
> 
> Na początek pozwala zrozumieć o co chodzi i myśleć jak programista, jak to
> zakuma to z Pythonem czy czymkolwiek innym będzie z górki (o ile starczy
> cierpliwości! mojemu zabrakło ;-)
> 
> https://scratch.mit.edu/
> 
> zakładasz konto i tworzycie z poziomu www lub instalujesz zintegrowane
> środowisko w systemie, do wyboru. Materiałów jest full, ponadto z tego co
> mi wiadomo zaczynają też w szkołach tego uczyć.
> 
  Też zaczynaliśmy w Logo, Small Basic teraz Python.
Scratch znamy w szkole będą mieli. Ale ta informatyka w szkole... ehh.

Robert

Może to co powiem jest nie popularne w dzisiejszych czasach, ale mimo wszystko...
Jeśli chcesz synowi "otworzyć oczy" na to "jak komputer działa", to jedyna sensowna opcja to Asembler. Po tym C++, którego bez Asemblera zrozumieć nie można, bo trzeba kojarzyć co to jest adres w pamięci (czyli tzw. wskaźnik w C++). Jak te 2 języki opanuje, to każdy inny też zakuma (z wyjątkami takimi jak ADA).
A jeśli chodzi by zrobić byle co i byle jak i byle gdzie, to w zasadzie nie ma znaczenia jaki język skryptowy wybierzesz, bo to i tak nie da pojęcia jak działa komputer.

Tak, przy okazji: naukę można oprzeć o "wyświetlaniu czegoś na ekranie" - i nie ma w tym nic złego. Jednak dobrze jest tą naukę zaplanować i uzgodnić jej cele, zakres i terminy realizacji. A gdy to zostanie sformułowane to starać się zachęcać dziecko do możliwie pełnej realizacji planu (np. rocznego na początek).   Jest tak, gdyż dzieci mają duży potencjał, jednak łatwo się zniechęcają, dlatego warto wiedzieć co powinny robić i zachęcać je do wysiłku realizacji kompleksowego planu. W przypadku programowania ma to ogromnie pozytywny charakter, w mojej rodzinie jest przykładowo wiolonczelistka (co jest bez sensu) ale właśnie rodzina ją inspiruje do dalszego wysiłku w naukę gry na tym instrumencie - z programowaniem jest podobnie, pierwsze brzdąknięcia dają dużo radości, ale mistrzostwo wymaga więcej pracy i wysiłku, dlatego ważne jest zaangażowanie rodzica by umiejętnie wspierał i zachęcał do dalszej nauki.

Co do podręcznika, to na początek polecałbym coś o Asemblerze x86/x64 - im cieńszy tym lepszy (najlepszy znany mi podręcznik to "Asembler nie tylko dla orłów" Grzegorza Michałka - ale chyba od dawna nie ma jej w sprzedaży).
Co do C++ to wszystkie są cegłami, ale najlepsze są podręczniki Jerzego Grębosza (najnowsza to "Opus Magnum").
Na etapie nauki Asemblera i C++ można rysować coś na ekranie i mieć z tego radochę. Po za tym tworzone są "normalne" programy binarne, a nie skrypty wymagające interpretera (lub co gorsza wirtualnej maszyny).
Po jako takim opanowaniu C++ warto przerobić podstawowe algorytmy. Tu bezkonkurencyjna jest książeczka "Zaprzyjaźnij się z algorytmami" Jacka Tomasiewicza. Jest bardzo dobrze przemyślana. W każdym rozdziale jest krótkie wprowadzenie do zagadnienia, ćwiczenie i 3 zadania o rosnącym stopniu trudności. Programy będące rozwiązaniami zadań można sprawdzić (przetestować) w internetowym serwisie https://main2.edu.pl/ . Na koniec każdego rozdziału są wskazówki/wyjaśnienia niezbędne do prawidłowego zakodowania rozwiązania.

Jest to inna droga rozwoju zdolności programowania, ale myślę, że poważniejsza. I taka powinna ona być, gdyż dla chwilowego kaprysu nie ma znaczenia, czy to będzie Python, czy PHP, czy JS, czy Java, czy C#... bo to i tak na nic.

Oczywiście jeśli "zatrzymałeś się na Spectrum" to będzie Ci trudno "dźwignąć" swoją wiedzę do Asemblera i C++ (tak by wspierać swojego syna). Ale może razem byście się czegoś nauczyli...

On Friday, February 9, 2018 at 8:59:46 AM UTC-5, szyk...@gmail.com wrote:
> Może to co powiem jest nie popularne w dzisiejszych czasach, ale mimo wszystko...
> Jeśli chcesz synowi "otworzyć oczy" na to "jak komputer działa", to jedyna sensowna opcja to Asembler. Po tym C++, którego bez Asemblera zrozumieć nie można, bo trzeba kojarzyć co to jest adres w pamięci (czyli tzw. wskaźnik w C++). Jak te 2 języki opanuje, to każdy inny też zakuma (z wyjątkami takimi jak ADA).
> A jeśli chodzi by zrobić byle co i byle jak i byle gdzie, to w zasadzie nie ma znaczenia jaki język skryptowy wybierzesz, bo to i tak nie da pojęcia jak działa komputer.
> 
> Tak, przy okazji: naukę można oprzeć o "wyświetlaniu czegoś na ekranie" - i nie ma w tym nic złego. Jednak dobrze jest tą naukę zaplanować i uzgodnić jej cele, zakres i terminy realizacji. A gdy to zostanie sformułowane to starać się zachęcać dziecko do możliwie pełnej realizacji planu (np. rocznego na początek).   Jest tak, gdyż dzieci mają duży potencjał, jednak łatwo się zniechęcają, dlatego warto wiedzieć co powinny robić i zachęcać je do wysiłku realizacji kompleksowego planu. W przypadku programowania ma to ogromnie pozytywny charakter, w mojej rodzinie jest przykładowo wiolonczelistka (co jest bez sensu) ale właśnie rodzina ją inspiruje do dalszego wysiłku w naukę gry na tym instrumencie - z programowaniem jest podobnie, pierwsze brzdąknięcia dają dużo radości, ale mistrzostwo wymaga więcej pracy i wysiłku, dlatego ważne jest zaangażowanie rodzica by umiejętnie wspierał i zachęcał do dalszej nauki.
> 
> Co do podręcznika, to na początek polecałbym coś o Asemblerze x86/x64 - im cieńszy tym lepszy (najlepszy znany mi podręcznik to "Asembler nie tylko dla orłów" Grzegorza Michałka - ale chyba od dawna nie ma jej w sprzedaży).
> Co do C++ to wszystkie są cegłami, ale najlepsze są podręczniki Jerzego Grębosza (najnowsza to "Opus Magnum").
> Na etapie nauki Asemblera i C++ można rysować coś na ekranie i mieć z tego radochę. Po za tym tworzone są "normalne" programy binarne, a nie skrypty wymagające interpretera (lub co gorsza wirtualnej maszyny).
> Po jako takim opanowaniu C++ warto przerobić podstawowe algorytmy. Tu bezkonkurencyjna jest książeczka "Zaprzyjaźnij się z algorytmami" Jacka Tomasiewicza. Jest bardzo dobrze przemyślana. W każdym rozdziale jest krótkie wprowadzenie do zagadnienia, ćwiczenie i 3 zadania o rosnącym stopniu trudności. Programy będące rozwiązaniami zadań można sprawdzić (przetestować) w internetowym serwisie https://main2.edu.pl/ . Na koniec każdego rozdziału są wskazówki/wyjaśnienia niezbędne do prawidłowego zakodowania rozwiązania.
> 
> Jest to inna droga rozwoju zdolności programowania, ale myślę, że poważniejsza. I taka powinna ona być, gdyż dla chwilowego kaprysu nie ma znaczenia, czy to będzie Python, czy PHP, czy JS, czy Java, czy C#... bo to i tak na nic.
> 
> Oczywiście jeśli "zatrzymałeś się na Spectrum" to będzie Ci trudno "dźwignąć" swoją wiedzę do Asemblera i C++ (tak by wspierać swojego syna). Ale może razem byście się czegoś nauczyli...

Tu są moje dwa grosze: jeśli syn ma smkykałkę w kirunku podstawowej elektroniki to lepszym rozwiązaniem będzie zaczęcie od systemów wbudowanych. Najlatwiesze Andruino ale mozna też wziąść cos bardziej ambitnego np TI MSP432, TI MSP430 lub STM32F4 - tzw "discovery kit" są tanie. Ostatecznie Rasberry PI lub BeagleBone. Osobiście bym wystartował o normalnego C idąc w kierunku nowoczesnego C++. Zaczynanie od asemblera wspólcześnoie mija sie z celem - nowoczesne kompilatory naprawde robia dobra robote optymalizujac kod.

> Zaczynanie od asemblera wspólcześnoie mija sie z celem - nowoczesne kompilatory naprawde robia dobra robote optymalizujac kod.

Nie chodzi o optymalizację, tylko o zrozumienie działania procesora... A po za tym ktoś pisze biblioteki używające MMX/SSE/3DNow! A tego nie da się zautomatyzować, a przyspieszenia mogą być o rzędy wielkości...
W czasach Dos-a można było dodatkowo zrozumieć zasadę współdziałania procesora i kart graficznej i muzycznej, co teraz przykrywa system operacyjny... Uważam to za plus mojej edukacji w tamtych czasach.

> Tu są moje dwa grosze: jeśli syn ma smkykałkę w kirunku podstawowej elektroniki to lepszym rozwiązaniem będzie zaczęcie od systemów wbudowanych.

To może był by dobry trop, gdyby nie to, że pierwsze "widzialne" efekty były by po długim czasie nauki... A jego syn chce "od razu" "widzieć" coś na ekranie... Co jak już pisałem nie jest niczym złym... Sam zaczynałem od wyświetlenia swojego własnego logo zaprojektowanego jako ASCII-art.

On Friday, February 9, 2018 at 11:16:14 AM UTC-5, szyk...@gmail.com wrote:
> > Zaczynanie od asemblera wspólcześnoie mija sie z celem - nowoczesne kompilatory naprawde robia dobra robote optymalizujac kod.
> 
> Nie chodzi o optymalizację, tylko o zrozumienie działania procesora... A po za tym ktoś pisze biblioteki używające MMX/SSE/3DNow! A tego nie da się zautomatyzować, a przyspieszenia mogą być o rzędy wielkości...
> W czasach Dos-a można było dodatkowo zrozumieć zasadę współdziałania procesora i kart graficznej i muzycznej, co teraz przykrywa system operacyjny... Uważam to za plus mojej edukacji w tamtych czasach.

W takim przypadku polecal bym pocwiczyc jakis bardzo prosty asembler np. MOS6502 (sa nawet symulatory), MOTO 68K lub MIPS - wszyskie naucza zasad dzialania processora bez konieznosci cwiczenia paskudnego asemblera Intela

On Friday, February 9, 2018 at 11:19:28 AM UTC-5, szyk...@gmail.com wrote:
> > Tu są moje dwa grosze: jeśli syn ma smkykałkę w kirunku podstawowej elektroniki to lepszym rozwiązaniem będzie zaczęcie od systemów wbudowanych.
> 
> To może był by dobry trop, gdyby nie to, że pierwsze "widzialne" efekty były by po długim czasie nauki... A jego syn chce "od razu" "widzieć" coś na ekranie... Co jak już pisałem nie jest niczym złym... Sam zaczynałem od wyświetlenia swojego własnego logo zaprojektowanego jako ASCII-art.

Do wiekszoci podanych systemow mozna niskim kosztem dodac wyswietlacz i bawic sie grafika (znacznie latwiej niz na duzym systemie).

> Do wiekszoci podanych systemow mozna niskim kosztem dodac wyswietlacz i bawic sie grafika (znacznie latwiej niz na duzym systemie).

Tyle, że to już inna architektura. W sumie zawsze się dziwiłem, po co ludzie się bawią jednoukładowymi komputerkami (czy też sterownikami mikroprocesorowymi) skoro wszystko można zrobić na PC? Dlatego moim zdaniem nauka programowania to jedna sprawa, a układy mikroprocesorowe to druga. I tak z resztą jest też w programach nauczania na politechnikach. Układy mikroprocesorowe wprowadza się tam gdzie znane są już podstawy elektroniki (analogowej i cyfrowej - 2 przedmioty) i programowania (Asembler x86/x64 i C++). To jest kolejny logiczny krok po tych 4 przedmiotach.
W tego typu inwestycje (zakup sterowników mikroprocesorowych) można się bawić gdy się wie już co chce się osiągnąć, bo tak "by zobaczyć co to jest" i porzucić, to moim zdaniem zbędny koszt...
Poza tym dochodzą też kwestie wsparcia. PC jest i będzie wspierany, a sterowniki mikroprocesorowe dziś są wspierane, a jutro jest zagadką...

Użytkownik "Robert Wańkowski" <robwan@wp.pl> napisał w wiadomości 
news:5a7d8ff9$0$675$65785112@news.neostrada.pl...

> Martwi mnie to, że oczekuje szybkich postępów. Chce już widzieć jakąś grafikę.

Standardowy tkinter

PS: Dobra rada:
Skup sie tylko na Pythonie3 i to od wersji min. 3.5
O Pythonie2 zapomnij natychmiast :)

AK 

W dniu 2018-02-10 o 11:37, AK pisze:
> Skup sie tylko na Pythonie3 i to od wersji min. 3.5
Pisałem o tym wyżej. Książkę mamy dla wersji 3.x
Python-a 3.6

Robert

Użytkownik "Robert Wańkowski" <robwan@wp.pl> napisał w wiadomości 
news:5a7ecdd6$0$577$65785112@news.neostrada.pl...

>W dniu 2018-02-10 o 11:37, AK pisze:
>> Skup sie tylko na Pythonie3 i to od wersji min. 3.5
> Pisałem o tym wyżej.

A fakt. Nie zauwazylem/przegapilem Twoj post.

Co do "niezwykle madrych rad" typu ASM/C/systemy embedded to spokojnie mozesz wrzuci je do kosza.
Bardziej niz Pythona2 :)
Zostan z synem przy Pythonie i nie daj sie zwiesc _nikomu_! z tej drogi

Np:

> Może to co powiem jest nie popularne w dzisiejszych czasach, ale mimo wszystko...

To nie tyle jest niepopularne co zwyczajnie bezdennie glupie :(

> Jeśli chcesz synowi "otworzyć oczy" na to "jak komputer działa", to jedyna sensowna opcja to 
> Asembler.

Ten co to pisze powinien puknac sie zwyczajnie w łeb :(

AK (Piszacy w C/C++ 30+ lat w tym w czystym ASM86 tez kilka (nie liczac spotkania z MacroAsemblerem
       z IBM360 czy Plan-u z ICL1900 czy peek/poke-owania na C64)

> > Może to co powiem jest nie popularne w dzisiejszych czasach, ale mimo wszystko...
> 
> To nie tyle jest niepopularne co zwyczajnie bezdennie glupie :(

Tylko co w tym głupiego, by wiedzieć jak na prawdę działa komputer?!? Jakie są instrukcje atomowe procesora?!? Ja znam wiele osób które nie mają pojęcia o Asemblerze ani o C++ i próbowały być programistami - bez skutecznie, bo nie miały pojęcia co to jest komputer. Nauka Asemblera daje dobre pojęcie na ten temat. Same if-y for-y i while to za mało by rozumieć z czym ma się do czynienia...
 
> > Jeśli chcesz synowi "otworzyć oczy" na to "jak komputer działa", to jedyna sensowna opcja to 
> > Asembler.
> 
> Ten co to pisze powinien puknac sie zwyczajnie w łeb :(

A co złego w tym podejściu? Może znasz lepsze?!? Może potrafisz nauczyć się czegoś bez nauki i prób?!? Taka metoda to wertowanie papierów i pustosłowie - to jest z powodzeniem praktykowane na polskich uczelniach. Tylko do niczego to nie prowadzi... nie powstają umiejętności - czyli taki ktoś nie będzie potrafił wytworzyć nic nowego, będzie bez użyteczny...
 
> AK (Piszacy w C/C++ 30+ lat w tym w czystym ASM86

Widać nie za dużo myślisz przy tym co robisz i nie uogólniasz swojego doświadczenia. Ja natomiast dużą wagę przywiązywałem do nauki rzeczy we właściwej kolejności - tym bardziej, że uczyłem się wszystkiego sam, z książek i gazet. Dlatego jedyną skuteczną metodą nauki programowania jaką znam (i jaką z powodzeniem przerobiłem) jest:
1. System dwójkowy, algebra Boola i prawa de Morgana (3 miesiące nauki)
2. Asembler (6 miesięcy nauki)
3. C++ (6-12 miesięcy nauki)
4. Algorytmy (rok nauki)
5. Qt (reszta życia)

Tak wygląda optymalna ścieżka. Jest możliwa do realizacji przy wsparciu osób doświadczonych (np. z grup dyskusyjnych). Jak ktoś to przerobi ten program nauczania będzie programistą z krwi i kości, a nie partaczem. Dużo łatwiej będzie się mu studiowało (przedmioty techniczne będą formalnością i całą energię będzie mógł kierować w opanowanie przedmiotów matematycznych).
Twoje krytykanctwo (bo nie proponujesz niczego w zamian tylko hasło: Python 3) prowadzi do produkcji debili z dyplomami uniwersyteckimi - znam takich z pracy i z Internetu (np. Stokrotka - udostępnia nie działające programy i nie widzi nic w tym złego - bo jak twierdzi są darmowe).

A jeśli chodzi o Python to jest on przydatny do operacji na tekście - gdy trzeba  coś przeanalizować, coś zautomatyzować (np. generować kod), wciągać/wyrzucać dane do/z baz. Natomiast nie nadaje się do pisania prawdziwych programów. I nie jest prawdą, że komputery są już wystarczająco szybkie by się nie martwić o szybkość wykonania. Bariera 4,5GHz jest nie przekraczalna dla x64. Poza tym co to za programista którego program zawsze jest wolny?!? I zawsze wymaga czegoś dodatkowego?!? (interpretera) i zawsze zajmuje dużo pamięci?!? Dlatego dla prawdziwego/poważnego programisty jedyną opcją są języki kompilowane. Po za tym jak chcesz zrobić kontrolkę COM w Pythonie?!? A COM w aplikacjach komercyjnych to standard... Poza tym C++ jest standardem w konkursach programistycznych (a nie żadne gówniane Javy, C#, JavaScripty, PHP) - bo tam uczą wyciskania wszystkiego ze sprzętu i szacunku dla zasobów. I to jest zdrowe podejście.

Na koniec odpowiedz sobie na pytanie:
Co po lekturze wybranej książki (przez Roberta) (na temat Pythona) będzie wiedział jego syn na temat budowy funkcjonalnej komputera?!?
Będzie wiedział, że są if-y, for-y, def-y, class-y, try i catch i nic więcej. To nie jest wiedza o komputerze, tylko wiedza o języku programowania! Dlatego proponowałem kompleksowe podejście, a nie "rapu capu" - "HURAAAA!!! i programujemy".

On Sun, 11 Feb 2018 11:45:14 -0800 (PST), szykcech@gmail.com wrote:

>> To nie tyle jest niepopularne co zwyczajnie bezdennie glupie :(
> 
> Tylko co w tym głupiego, by wiedzieć jak na prawdę działa komputer?!? Jakie są instrukcje atomowe procesora?!? Ja znam wiele osób które nie mają pojęcia o Asemblerze ani o C++ i próbowały być programistami - bez skutecznie, bo nie miały pojęcia co to jest komputer. Nauka Asemblera daje dobre pojęcie na ten temat. Same if-y for-y i while to za mało by rozumieć z czym ma się do czynienia...
>  
>>> Jeśli chcesz synowi "otworzyć oczy" na to "jak komputer działa", to jedyna sensowna opcja to 
>>> Asembler.
>> 
>> Ten co to pisze powinien puknac sie zwyczajnie w łeb :(
> 
> A co złego w tym podejściu? Może znasz lepsze?!? Może potrafisz nauczyć się czegoś bez nauki i prób?!? Taka metoda to wertowanie papierów i pustosłowie - to jest z powodzeniem praktykowane na polskich uczelniach. Tylko do niczego to nie prowadzi... nie powstają umiejętności - czyli taki ktoś nie będzie potrafił wytworzyć nic nowego, będzie bez użyteczny...
>  
>> AK (Piszacy w C/C++ 30+ lat w tym w czystym ASM86
> 

[...ciach brednie...]

> Co po lekturze wybranej książki (przez Roberta) (na temat Pythona) będzie wiedział jego syn na temat budowy funkcjonalnej komputera?!?

A jak mu tato kupuje autko to najpierw powinien go wysłać by skończył
wydział mechaniczny na polibudzie? A jak klocki to może też budowlany?
Ty się rzeczywiście stuknij w czerep.

> Będzie wiedział, że są if-y, for-y, def-y, class-y, try i catch i nic więcej. 

I to mu absolutnie wystarczy w tym wieku i na tym etapie! A za rok zapomni
o tym i zajmie się ...samolotami, koleją, statkami.

> To nie jest wiedza o komputerze, tylko wiedza o języku programowania! Dlatego 
> proponowałem kompleksowe podejście, a nie "rapu capu" - "HURAAAA!!! i programujemy".

Tobie się popieprzyło, ojciec nie szuka dla syna pracy... może włącz
myślenie i podejdź do tematu ze zrozumieniem... potrafisz?


-- 
pozdrawiam
Roman Tyczka

On Fri, 9 Feb 2018 05:59:45 -0800 (PST), szykcech@gmail.com wrote:
> �a", to jedyna sensowna opcja to... 

To BYŁA SENSOWNA OPCJA DLA CIEBIE. 

Ale na pewno to NIE JEST DOBRE DLA KAŻDEGO. 

I BYĆ MOŻE są lepsze rzeczy i lepsze sposoby. Może tak, może nie. Ale 
trzeba być otwartym na nowe. A nie upierać się że "trzeba jak łojce". 
 Bo to pachnie gumofilcem i negowaniem postępu. Tego realnego, nie z 
pitolenia spin-doktorów i menago. 

Python jest świetnym językiem z paroma obrzydliwymi wadami. (CIL, 
prędkość, bezpieczeństwo, wielkość "exe") Moim zdaniem, aby dobrze 
programować w Pythonie trzeba być inteligentnym, nie trzymać się 
kurczowo nawyków z innych języków, mieć świadomość co już jest w 
Pythonie zrobione i do czego Python się NIE nadaje.

On Fri, 9 Feb 2018 07:15:58 -0800 (PST), amorawski@magna-power.com 
wrote:
> BeagleBone. Osobiście bym wystartował o normalnego C idąc w =
> kierunku nowoczesnego C++. 

C, a nawet C++, to babranie się z szczegółami, bez szansy na 
ogarnięcie całości. Nie twierdzę że C to kiepski język (ileś tam 
tysięcy linii w nim napisałem), ale w Pythonie programuje się 
znacznie przyjemniej. Python może robić rzeczy, które w C są 
niemożliwe lub po prostu zbyt upierdliwe. To jak płacenie gotówką a 
kartą. Kartą jest wygodniej.

On Fri, 9 Feb 2018 08:38:56 -0800 (PST), Adam M 
<amorawski@magna-power.com> wrote:
> 3DNow! A tego nie da się zautomatyzować


Jak się nie da, jak się da. I tyle.

On Fri, 9 Feb 2018 09:41:09 -0800 (PST), szykcech@gmail.com wrote:
> łem, po co ludzie się bawią jednoukładowymi komputerkam=
> i (czy też sterownikami mikroprocesorowymi) skoro wszystko można =
> zrobić na PC? 

Kasa misiu.

mikrokontrolery są po prostu tanie.

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> Ale na pewno to NIE JEST DOBRE DLA KAŻDEGO.

Jesli dla mnie to i dla kazdego.
A juz dla dla dziecka nepewno :)).
W przeciwienstwie do wiekszosci MWZDM staram sie byc normalnym
czlowiekiem (a nie zaadresowanym pointerami samolubnym/samouwielbiajacym
sie robotem:) i myslec _wciaz_ jak normalny czlowiek (mimo dluzszego doswiadczenia
programistycznego niz zycie tu piszacych:) i wczuc sie w potrzeby pytajacego i _kontekst_
tego pytania (dziecko - z natury niecierpliwe/szybko zniechecajace sie - wiec niezdolne
na tym etapie zycia do wiekszej abstrakcji, ze juz o chorym C/C++ nie wspomne).

Byla przeciez juz "wieki temu" inicjatywa (chyb zbyt wyprzedzila swoj czas) CP4E:
https://www.python.org/doc/essays/cp4e/

PS: Sa  i dzis jej skutki/kontynuacje w roznej postaci. Np (mimo ze nie dla dzieci):
https://www.coursera.org/learn/python

> I BYĆ MOŻE są lepsze rzeczy i lepsze sposoby. Może tak, może nie.

Tak ? No to wpierw je _znajdz i podaj_, zanim bedziesz znow zasmiecal
grupe swoimi "madrosciami" i zwyklym krytykanctwem.
Bo: krytyka bezalternatywna == pospolite prymitywne krytykanctwo.

W przeciwienstwie do Ciebie znam taka alternatywe/alternatywy.
Np jedna z nich jest nawet prostrza/strawniejsza od Scratcha.
W dodatku 100% polska.
Niestety wbudowana w stricte rynkowy produkt, wiec publicznie
niedostepna. Wielka szkoda, bo liczy ona sobie ponad 20 lat istnienia.

> trzeba być otwartym na nowe. A nie upierać się że "trzeba jak łojce". Bo to pachnie gumofilcem i 
> negowaniem postępu. Tego realnego, nie z pitolenia spin-doktorów i menago.

To ty sie upierasz jak typowy wstecznik przy starym.
Przypomniec Ci/Wam jak wysmiewaliscie mnie i Pythona
10+ lat temu gdy kupowalem domeny python.pl i python.org.pl?
Przypomniec kolejnym Ayatollahom C/C++ jak wysmiewaliscie
(tez ok 10lat temu) MS-a i jego .NET ?
Kto mial wtedy racje? Hę? Bo napewno nie Wy.

Tak sie sklada ze zaczynalem przygode z programowaniem
od Algolu-u i Simuli i przeszedlem w swej drodze produkcyjnie
~10 j.programowania (a "zabawowo" jeszcze kilka innych) i nie potrzebuje
w tym temacie adwokatow (zwlaszcza marnych, czyli siedzacych cale zycie
jedynie za akademickim biurkiem i nie majacych wiekszego pojecia o prawdziwej
produkcji softu i "waznosci" roznych czynnikow w nim wystepujacych).

> Python jest świetnym językiem

Uuu? Co za zmiana stanowiska o 180st ?! :)
Jeszcze kilka lat temu wieszales na Pythonie psy i odsadzales od
"czci i wiary", wtorujac zreszta pewnemu Profesorowi z USA
(bardzo madremu zreszta - bardzo go szanuje, szkoda ze opuscil usenet -
ale w temacie Pythona i jemu zabraklo zwyczajnie ee.. nosa/wyczucia).

> z paroma obrzydliwymi wadami. (CIL,  prędkość, bezpieczeństwo,
> wielkość "exe")

Ta wielkosc exe zwyczajnie mnie rozsmieszyla :)
Zwlaszcza dzisiaj, gdy "za rogiem" mozna dostac 8GB pamieci za kilka
marnych zlotych.

> Moim zdaniem, aby dobrze  programować w Pythonie trzeba być inteligentnym,
> nie trzymać się  kurczowo nawyków z innych języków, mieć świadomość
> co już jest w  Pythonie zrobione i do czego Python się NIE nadaje.

To tyczy dokladnie _kazdego_ jezyka programowania.
Akurat Pythona najmniej, gdyz mozna zaczac wlasciwie od 0, zanim dojdzie sie
do metaklas, generatorow, greenletow, asyncio, stackless, korutyn itp, itd.

PS: Co do GILa to zwyczajnie sie doucz. Nie stanowi on
takiej przeszkody o ktorej bajasz (hm.. ciekawe kiedy dziecko
zetknie sie z niedoskonaloscia GILowa hihi :).
Slaba wydajniosc tez jest mityczna. Dla krytycznych rzadkich przypadkow istnieje
przeciez standardowe ctypes czy cffi czy SWIG czy boost-Python czy SIP czy zwykłe
standardowe API do C - a i sprzegow do innych j.programowania/APIs wiele.

AK

On Sat, 17 Feb 2018 00:46:00 +0100, "AK" <nobody@nowhere.net> wrote:
> Jesli dla mnie to i dla kazdego.

Jeżeli ja noszę buty rozmiar 46, to dla każdego ten rozmiar jest 
najlepszy?

> W przeciwienstwie do wiekszosci MWZDM staram sie byc normalnym

Tyle że nie jesteś.

> W przeciwienstwie do Ciebie znam taka alternatywe/alternatywy.

Nie masz pojęcia o czym nie mam pojęcia.

> Jeszcze kilka lat temu wieszales na Pythonie psy

Zawsze wskazywałem wady jakie ma Python. Nigdy nie powiesiłem psa, 
ani innego zwierzęcia.

> Slaba wydajniosc tez jest mityczna.

Wymieniłem 4 wady Pythona: brak dobrej współbieżności, małą prędkość 
działania, kłopoty z bezpieczeństwem, rozmiar "exe". Zauważ: nie 
czepiam się dyscypliny typów, składni czy sposobu definiowania 
stałych. (Bo byłoby to jak narzekanie że w Lisp nie ma pętli 
do-while.)

Piszesz, że z tą prędkością to nie tak. A jak? Skoro normalnie Python 
jest 1000 wolniejszy niż C, to przecież nic takiego: dokupi się 999 
komputerów.

W zastosowaniach, gdzie prędkość działania nie jest potrzebna, Python 
będzie ok. Ale do ciężkiej numeryki to raczej C i nadal Fortran, ew. 
Matlab itp. I tu nic nie zmieni ani Cython, ani numpy. 

Bezpieczeństwo... Da się uzyskać CE na system sterowany programem w 
Pythonie? Jakie gwarancje daje PyPI? Co z Python MISRA? Pod tym 
względem Java i C dają radę, ale Python wyraźnie nie.

Współbieżność. W smartfonie mam dwa procesory po cztery rdzenie. W 
komputerze podobnie i jeszcze parę tysięcy z GPU. Ale Python boi się 
współbieżności. Nie zachęca do niej. To nie jest pythonic way.

Ok. Napisałem fajny programik. Co teraz? Jeżeli dam go jako tekst 
źródłowy jest fajnie... tyle że użytkownicy będą musieli poinstalować 
sobie Pythona. A jeżeli ma być to po prostu "zwykły exe"? No to 
będzie to ważyć około 300MB. Ale co tam... telkomy dają "najszybszy 
internet na osiedlu",  ceny pendrive 2TB są umiarkowane.

Mimo wszystko Python jest świetny do nauki programowania, ale trzeba 
zdawać sobie sprawę z ograniczeń. Bo są.

Co ważne - to normalny język - a nie zabawka w rodzaju Small Basic, 
Scratch czy Alice.

Użytkownik "slawek" <fake@fakeemail.com> napisał:

>> Jesli dla mnie to i dla kazdego.
>
> Jeżeli ja noszę buty rozmiar 46, to dla każdego ten rozmiar jest najlepszy?

Hm.. No faktycznie powazne odstepstwo, ale nie moje...
Ja nosze jeszcze standardowe 42 :).

>> W przeciwienstwie do wiekszosci MWZDM staram sie byc normalnym
>
> Tyle że nie jesteś.

Pozostane przy swym zdaniu :)

>> W przeciwienstwie do Ciebie znam taka alternatywe/alternatywy.
>
> Nie masz pojęcia o czym nie mam pojęcia.

W kontekscie Pythona mam. Wiem dobrze, ze nie masz o Pythonie
pojecia (w tym wzgledzie prezentujesz wrecz modelowe wstecznictwo).

>> Jeszcze kilka lat temu wieszales na Pythonie psy
>
> Zawsze wskazywałem wady jakie ma Python. Nigdy nie powiesiłem psa, ani innego zwierzęcia.

Tak? Mam odszukac Twoje wypociny?
Nie chce mi sie, ale dobrze pamietam "glos akademikow"
sprzed lat na temat jakosci, antyprzydatnosci i sensownosci/przyszlosci Pythona.

> Wymieniłem 4 wady Pythona: brak dobrej współbieżności, małą prędkość działania, kłopoty z 
> bezpieczeństwem, rozmiar "exe". Zauważ: nie czepiam się dyscypliny typów.

Ze niby co? Ze Python nie posiada dyscypliny typow?
Znow brak wiedzy (czyli tzw wiedza "naukawa" - czyli wyczytana
w jakiejs gazecie) wychodzi.

> Piszesz, że z tą prędkością to nie tak. A jak? Skoro normalnie Python jest 1000 wolniejszy niż C, 
> to przecież nic takiego: dokupi się 999 komputerów.
>
> W zastosowaniach, gdzie prędkość działania nie jest potrzebna, Python będzie ok. Ale do ciężkiej 
> numeryki to raczej C i nadal Fortran, ew. Matlab itp. I tu nic nie zmieni ani Cython, ani numpy.

Zmieni. Juz dawno zmienilo. Tylko ty sie zatrzymales w swym wstecznictwie
w sredniowieczu. Np. chwalac w nieboglosy Fortran i jego mityczna szybkosc.
Praktyka (szczegolnie na PC-tach) jej przeczy. Sam Fortran (jako jezyk)
w kwestii "szybkosci" nic takiego nie daje - a jest jezykiem wrecz okropnym (
oczywiscie dostrzegam duzy postep od F90). Wszystko zalezy od
srodowiska/kompilatora itp.
Podstawowe linki zamieszczam dla innnych:
http://www.numpy.org/
https://www.scipy.org/scipylib/index.html
https://numba.pydata.org/
http://pandas.pydata.org/
http://www.sagemath.org
https://en.wikipedia.org/wiki/SageMath
https://www.anaconda.com/what-is-anaconda/
https://www.enthought.com/product/canopy/
https://en.wikipedia.org/wiki/Orange_(software)
https://en.wikipedia.org/wiki/Mlpy
Np. Twoj Matlab jest wolniejszy i gorszy od Pythona/numpy.
http://brains.zut.edu.pl/wp-content/%C5%81ukasz-Przyby%C5%82ek-Python-jako-alternatywa-Matlaba-1.pdf

Cale szczescie nie cala polska nauka unika Pythona. Ba!
Stosuje go z powodzeniem od wielu lat np.
https://sage3.icse.us.edu.pl/home/pub/133/
https://sage3.icse.us.edu.pl/home/pub/34/
i duzo rzeczy o sage:
https://sage3.icse.us.edu.pl/pub/
http://visual.icse.us.edu.pl/LA/algebra_macierze_w_sage.html
Tu tez fajne/skrotowe wprowadzenie do numpy+sympy:
http://www.cs.put.poznan.pl/wjaskowski/pub/teaching/kck/labs/python-tools.pdf

> Bezpieczeństwo... Da się uzyskać CE na system sterowany programem w Pythonie? Jakie gwarancje daje 
> PyPI? Co z Python MISRA? Pod tym względem Java i C dają radę, ale Python wyraźnie nie.

Jakos MicroPython powoli daje rade:
https://micropython.org/

> Współbieżność. W smartfonie mam dwa procesory po cztery rdzenie. W komputerze podobnie i jeszcze 
> parę tysięcy z GPU. Ale Python boi się współbieżności. Nie zachęca do niej. To nie jest pythonic 
> way.

Hehe :) Nie zacheca :) No nie moge!:).
Chlopie poczytaj sobie chocby o Twisted, chocby o asyncio,
chocby o stackless Python itp i przestan przynudzac Twoja marnuitka
wiedza. Python nie tylko nie boi sie wspolbieznosci ale _wyznacza
nowe dgrogi_. Np Twisted a juz w pelni standardowe asyncio
wyznacza nowy "bezcallbackowy" (czyli w pelni udajacy zwykly sekwencyjny)
sposob pisania programow wspolbieznych i "zdarzeniowych".
Dzieki technice deferred_callback:
(http://twistedmatrix.com/documents/9.0.0/core/howto/deferredindepth.html)
w pelni zintegrowanej z Pythonowymi generatorami (przez to bardzo uproszczonej)
wlasnie w asyncio (czyli od Pythona 3.5 wlasnie), ktory stal sie standardem.
Programy oparte na Twisted pisalem juz w 2002, jeszcze wczesniej chyba
oparte na Stackless (https://en.wikipedia.org/wiki/Stackless_Python) jeszcze
wczesniej a Ty tu pieprzysz  i "slabosci" Pythona we wspolbieznosci :)
Zwyczajnie zalosne.

Taki przykladzik pierwszy z brzegu:
"Stary jak swiat" i oparty na juz przestarzalych i o wiele mniej wydajnych
mechanizmach wspobieznosci niz dzisiejsze chociazby asyncio, a jednak
calkiem dobrze wciaz "daje rade" wiodacym C/C++ odpowiednikom
(vide benchmark na dole stronny):
https://pypi.python.org/pypi/pyftpdlib/

> Ok. Napisałem fajny programik. Co teraz? Jeżeli dam go jako tekst źródłowy jest fajnie... tyle że 
> użytkownicy będą musieli poinstalować sobie Pythona.

No i co z tego? Wszyscy i wszedzie instaluja juz Pythona.
Nie znam dystrybucji Linuxa bez niego.
Na Win to chwila (30sek) i zupelnie bezproblemowa instalacja.
Pseudoargumentow uzywasz "akademiku".
Zalosnych i smiesznych.

> A jeżeli ma być to po prostu "zwykły exe"? No to będzie to ważyć około 300MB. Ale co tam... 
> telkomy dają "najszybszy internet na osiedlu",  ceny pendrive 2TB są umiarkowane.

C:\bin>cgi
Usage: cgipython <pyfile> [parameters]
C:\bin>fsize cgi.exe
file size is 1883136

W tym cgi.exe jest _caly_ Python (wlacznie z biblioteka standardowa).
Z najnowszym Pythonem jest gorzej (~5MB), ale IMHO daleko temu do
mitycznych/wydumanych 300MB.
Wystarczy porownac z Java gdzie najprostrzy "exe" ciagnie za soba
cala jre a. np. jre1.8.0_161 to 178MB+

> Mimo wszystko Python jest świetny do nauki programowania, ale trzeba zdawać sobie sprawę z 
> ograniczeń. Bo są.

Znow zmiana o 180st do opini sprzed lat:)

> Co ważne - to normalny język -

..i znow.:)
No.. doceniam! :)

 > a nie zabawka w rodzaju Small Basic,
> Scratch czy Alice.

Zabawki? Heh.
No to co tu powiedziec o "laderach" krolujacych w automatyce.
To ci dopiero zabawka :) Prawda?
No i co z tego ze sterowniki Siemensa czy innego Rockwella
w nich glownie programowane?, prawda? Zabawki?:)

AK

Update: przeoczone (a wazne):
https://github.com/pydata/numexpr, http://numexpr.readthedocs.io/en/latest/
https://pypi.python.org/pypi/Theano

http://scikit-learn.org/stable/
https://en.wikipedia.org/wiki/TensorFlow

AK

On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nobody@nowhere.net> wrote:
> w sredniowieczu. Np. chwalac w nieboglosy Fortran i jego mityczna 
szybkosc.
> Praktyka (szczegolnie na PC-tach) jej przeczy. Sam Fortran (jako 
jezyk)
> w kwestii "szybkosci" nic takiego nie daje - a jest jezykiem wrecz 
okropnym (
> oczywiscie dostrzegam duzy postep od F90). 

Ale Fortran naprawdę jest szybki. I w praktyce nadal używany DO 
BARDZO POWAŻNYCH RZECZY. A że jest jaki jest? Taka jego uroda.

Obejrzyj sobie "Ukryte działania" na Canal+ a potem poszukaj muzeum 
NASA - można zobaczyć to co wtedy pisano i jak. Część tego stosuje 
się do dziś.

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nobody@nowhere.net> wrote:
>> w sredniowieczu. Np. chwalac w nieboglosy Fortran i jego mityczna
> szybkosc.
>> Praktyka (szczegolnie na PC-tach) jej przeczy. Sam Fortran (jako
> jezyk)
>> w kwestii "szybkosci" nic takiego nie daje - a jest jezykiem wrecz
> okropnym (
>> oczywiscie dostrzegam duzy postep od F90).
>
> Ale Fortran naprawdę jest szybki. I w praktyce nadal używany DO BARDZO POWAŻNYCH RZECZY. A że jest 
> jaki jest? Taka jego uroda.

Mit.
Na PC-tach wcale nie przewyzsza zwyklego C/C++/Pascal-a.
Co innego CRAY (ale tak jak mowie, to kwestia kompilatorow/wykorzystania
bibliotek srodowiska/"procesora" np. CRAYowego itp anie jakosci samego
jezyka - dzis bym wprost zabranial uzywania Fortnanu<90, a nawet 95).

> Obejrzyj sobie "Ukryte działania" na Canal+ a potem poszukaj muzeum NASA - można zobaczyć to co 
> wtedy pisano i jak. Część tego stosuje się do dziś.

PS: Pamietaj, ze kupe lat w Fortranie pisalem (jeszcze na Odrze, potem Mera400,
potem nieco na IBM360 a potem na PC-tach (MS-Fortram, NDP-Fortran, Watcom-Fortran)
wiec moze komu innemu/nieswiadomemu tak, ale mnie mitu ani kitu latwo nie wcisniesz.
Cudow nie ma. Po prostu tu "trzyma" koprocesor/jego szybkosc, a nie j.programowania i tyla.

AK

On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nobody@nowhere.net> wrote:
> Np. Twoj Matlab jest wolniejszy i gorszy od Pythona/numpy.

Matlab używa do obliczeń GPU. Używa SIMD. I to bez męczenia 
użytkownika. 

Nie masz też chyba pojęcia tym jakie kwiatki można znaleźć w np. 
scipy (np. że niezależnie od kontekstu 1E-20 to jest to samo co 
zero).

Porównanie numpy i Matlaba to jak porównanie samoróbki że złomu i 
Maybacha. Jedno i drugie dowiezie cię gdzie trzeba, ale ani równie 
bezpiecznie, ani równie wygodnie.

On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nobody@nowhere.net> wrote:
> Z najnowszym Pythonem jest gorzej (~5MB), ale IMHO daleko temu do
> mitycznych/wydumanych 300MB.

Tyle niestety wyszło: numpy, scipy, matplotlib, arrow, coś tam 
jeszcze... I jest 270MB. Choć sam program to jakieś 200 LOC.

On Sat, 17 Feb 2018 14:43:12 +0100, "AK" <nobody@nowhere.net> wrote:
> Mit.
> Na PC-tach wcale nie przewyzsza zwyklego C/C++/Pascal-a.

Sprawdziłeś? To sprawdź! Możesz się zdziwić...

> Cudow nie ma. 

CUDA jest.

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nobody@nowhere.net> wrote:
>> Np. Twoj Matlab jest wolniejszy i gorszy od Pythona/numpy.
>
> Matlab używa do obliczeń GPU. Używa SIMD. I to bez męczenia użytkownika.

Python tez moze uzywac i GPY i SIMD tez, tylko trzeba umiec.
Umiec tez trzeba uzywac Pythona/numpy np z:
https://software.intel.com/en-us/articles/numpyscipy-with-intel-mkl
a Python/numpy ma obustronne wsparcie do/od KLM od dobrych kilku lat.

> Nie masz też chyba pojęcia tym jakie kwiatki można znaleźć w np. scipy (np. że niezależnie od 
> kontekstu 1E-20 to jest to samo co zero).

Juz w czasach Odry/w mych czasach 1E-20 to bylo to samo co zero.
Naucz sie uzywac i porownywac wreszcie liczby fp. Czas najwyzszy :)

> Porównanie numpy i Matlaba to jak porównanie samoróbki że złomu i Maybacha.

Bredzisz :)
Np. sposob obslugi subtablic w Pytnonie/numpy jest o wiele lepszy/wydajniejszy
niz w 'Maybachu' Matlabie.

AK

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nobody@nowhere.net> wrote:
>> Z najnowszym Pythonem jest gorzej (~5MB), ale IMHO daleko temu do
>> mitycznych/wydumanych 300MB.
>
> Tyle niestety wyszło: numpy, scipy, matplotlib, arrow, coś tam jeszcze... I jest 270MB. Choć sam 
> program to jakieś 200 LOC.

Znow bredzisz.
Robiac pythono-frozen exeka bierze sie tylko to co faktycznie
jest uzywane a niekoniecznie to wszytsko co lezy na dysku.

AK 

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Sat, 17 Feb 2018 14:43:12 +0100, "AK" <nobody@nowhere.net> wrote:
>> Mit.
>> Na PC-tach wcale nie przewyzsza zwyklego C/C++/Pascal-a.
>
> Sprawdziłeś? To sprawdź! Możesz się zdziwić...

Tak. Sprawdzalem.
Fakt ze dosc dawno temu, ale wtedy tez juz koprocesor byl i to on "trzymal".
Nie bylo specjalnej roznicy miedzy MS-Fortranem, MS-Pascalem,
MS-C/C++. TurboPascalem i WatcomC++ i WatcomFortranem.

>> Cudow nie ma.
>
> CUDA jest.

Ano jest w Pythonie nie od dzisiaj.
I to m.in. u zrodla:
https://developer.nvidia.com/pycuda

AK

On Sat, 17 Feb 2018 16:41:22 +0100, "AK" <nobody@nowhere.net> wrote:
> Juz w czasach Odry/w mych czasach 1E-20 to bylo to samo co zero.
> Naucz sie uzywac i porownywac wreszcie liczby fp. 

No to np. taka stała Plancka wynosi twoim zdaniem zero. Odwrotność 
liczby Avogadro... to też zero. Masa elektronu... itd.

Nie każdy liczy tylko liczbę sznurówek i rolek papieru toaletowego. 
Czasem komputerów używa się w chemii, czasem do obliczania 
trajektorii satelitów. A ustawianie odcięcia na 1E-20 gdy zakres jest 
do 1E-308 to delikatnie ujmując jest nieodpowiednie.

On Sat, 17 Feb 2018 16:43:22 +0100, "AK" <nobody@nowhere.net> wrote:
> Robiac pythono-frozen exeka bierze sie tylko to co faktycznie
> jest uzywane a niekoniecznie to wszytsko co lezy na dysku.

A bo ja wiem? Tyle mi wyszło. Konkretnie, dla dość małego (200 LOC) 
programu. I to nie bez gimnastyki: Python 3.6, nie chciało czegoś 
jakoś, wreszcie poszło, ale trwało to długo, zrobiło się wielkie i do 
tego okazało się że i tak nie chroni przed inżynierią odwrotną.

Użytkownik "slawek" <fake@fakeemail.com> napisał:
> A ustawianie odcięcia na 1E-20 gdy zakres jest do 1E-308 to delikatnie ujmując jest 
> nieodpowiednie.

Przeciez jasne (moze nie dla Ciebie?:) ze porownujemuy roznicę ?
Nie wiem jak ciebie uczono, ale mnie uczono (pierwszy raz w
ksiazce prof.Sysły "Algorytmy optymalizacji w jezyku Algol60"),
ze zasada pracy na liczbach fp to _wlasciwie bez wyjatku_ porownania
"nieostre" (czyli z zalozonym EPS):
Czyli jak porownujemy liczby FP? Ano zawsze tak:

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

gdzie EPS to gory zalozona dokladnosc i mniejsza _przynajmniej_ o rzad/dwa,
(a tak naprawde mocno zalezna od "bledogennosci" - zaokraglenia/kumulacja bledow
obliczen itp - wykonywanych obliczen) od rzedu dokladnosci/ilosci cyfr znaczacych mantysy.

Mamy na IEEE double ~17 cyfr znaczacych mantysy czyli EPS minimalna to <= 1.0E-15.
No i teraz sobie podstaw:
a = 0.0
b = 1.0E-20
do: a == b    =>   abs(a - b) <= EPS
abs(0.0 - 1.0E-20) <= 1.0E-15
1.0E-20 <= 1.0E-15  # Prawda ci to czy nie ? Czyli a == b.
Koniec kropka.

Ale gdy sobie porownasz:
a = 1.0E-10
b = 1.0E-20
abs(a - b) <= EPS => 9.999999999e-11 !<= 1.0E-15  # czyli a != b

PS: Pamietam dobrze z "moich czasow" pewien projekt obliczeniowy
wykonany przez Szacowna Woskowa Uczelnie dla przemyslu.
Projekt/program dzialal tylko dla załaczonych przykladowych danych.
Dla zadnych innych nie /nie byl zbiezny/ :)
Miedzy innymi z powodu takich (choc nie tylko) kwiatkow.
No i potem musieli dlugi czas zwykli programisci poprawiac mozolnie
(a tak naprawde w duzym stopniu przepisac/napisac od nowa)
"dzieło" (nie darmowe bynajmniej:) Panow Akademikow rodem z LWP.
Ze juz o rachunkach 0.0zl czy bankowym zadluzeniu 0.0zl nie wspomne :)

PS1: Nie zawsze teoretycznie mamy IEEE. Na rzeczonej Odrze
czy Merze (czy nawet na PC-tach w poczatkowym okresie w
kompilatorach MS-sa) liczby FP wcale nie byly IEEE-owe
wiec nawet zalozenie o tych 17 cyfrach znaczacyh mantysy nie jest
bezwzgledniee jedynie sluszne.

PS2: A wystarczy przyjac prosta zasade:
_Jakiekolwiek_ liczby FP sa z zadady niedokladne.
Nawet po prostej operacji: b = a + 0.0 - 0.0 nie mozna
przyjac ze pozniejsze "sztywne" porownanie a == b da prawdę.

PS3: A ta naprawde/w praktyce to porownuje sie  z reguly w numeryce
       _wzgledną_ roznicę liczb FP. Zasada z EPS pozostaje jednak wciaz aktualna.

PS4: Wlasnie Python wyszedl na przeciw wiekszosci "nieswiadomym" dzis
      uzytkownikom FP i zaimplementowal wewnetrzenie nieco bardziej lagodny
     algorytm porownywania/wyswietlania/zaokraglana przy operacjach liczb fp niz
     taki "na surowo" czyli ze nieco czesciej a == b dziala  dobrze nawet jesli liczby
     nie sa stricte/co do bita mantysy takie same.
     Stad zapewne to, ze 1.0e-20 == 0.0, choc osobiscie nie wierze
     bo w czystym Pythonie akurat ta operacja daje False.

AK

Użytkownik "slawek" <fake@fakeemail.com> napisał:
>> Robiac pythono-frozen exeka bierze sie tylko to co faktycznie
>> jest uzywane a niekoniecznie to wszytsko co lezy na dysku.
>
> A bo ja wiem? Tyle mi wyszło.

Bo "trza sie naumiec".
Jesli mu kazales wszystko wciagnac, no to grzecznie wciagnal.

AK 

Użytkownik "AK" <nobody@nowhere.net> napisał;

Update:

> PS3: A ta naprawde/w praktyce to porownuje sie  z reguly w numeryce
>       _wzgledną_ roznicę liczb FP. Zasada z EPS pozostaje jednak wciaz aktualna.
>
> PS4: Wlasnie Python wyszedl na przeciw wiekszosci "nieswiadomym" dzis
>      uzytkownikom FP i zaimplementowal wewnetrzenie nieco bardziej lagodny
>     algorytm porownywania/wyswietlania/zaokraglana przy operacjach liczb fp niz
>     taki "na surowo" czyli ze nieco czesciej a == b dziala  dobrze nawet jesli liczby
>     nie sa stricte/co do bita mantysy takie same.
>     Stad zapewne to, ze 1.0e-20 == 0.0, choc osobiscie nie wierze
Mialo byc:  Stad zapewne to, ze w scipy 1.0e-20 == 0.0, choc osobiscie nie wierze
>     bo w czystym Pythonie akurat ta operacja daje False.

Tu odpowiedni PEP:
https://www.python.org/dev/peps/pep-0485/
i help(math.isclose())
tudziez
help(numpy.isclose())
help(numpy.allclose())

AK

Użytkownik "AK" <nobody@nowhere.net> napisał w wiadomości news:p6a1mm$936$1@gioia.aioe.org...

Update1:
Juz calkiem doglebne wejscie w temat/"dokladnosc" fp w Pythonie to np:
np: math.fsum()
czy metody float-a
hex(), fromhex(), a szczegolnie as_integer_ratio()

AK

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> Nie każdy liczy tylko liczbę sznurówek i rolek papieru toaletowego.

No widzisz? Nawet Twoj ulubiony Lahey (i to w lata temu: 1996) uczy jak trzeba postepowac
w Fortranie (i w ogole) z  FP (i to w wersji roznicy wzglednej - czyli najbardziej odpowiedniej):

http://www.lahey.com/float.htm

a tam:

Safe Comparisons
-------------------
Different computers use different numbers of bits to store floating-point numbers.
Even when the same IEEE formats are used for storing numbers, differences in calculations
can occur because of the size of intermediate registers.
To increase portability and to ensure consistent results, I recommend against comparing for
exact equality of real numbers in FORTRAN.
A better technique is to compare the absolute value of the difference of two numbers with
an appropriate epsilon to get relations like approximately equal, definitely greater than, etc.
Example:

REAL EPSILON, X, A, B
PARAMETER (EPSILON = .000001)
DATA A/13.9/, B/.000005/
X = (A * B) / B
IF (ABS(X - A) .LE. (ABS(X)*EPSILON)) THEN
   PRINT *, 'X is approximately equal to A'
ENDIF
IF ((X - A) .GT. (ABS(X)*EPSILON)) THEN
   PRINT *, 'X is definitely greater than A'
ENDIF
IF ((A - X) .GT. (ABS(X)*EPSILON)) THEN
   PRINT *, 'X is definitely less than A'
ENDIF
END

Jak widac pokrywa sie w pelni z tym co uprzednio napisalem.

AK

W dniu 09.02.2018 o 18:41, szykcech@gmail.com pisze:
> Tyle, że to już inna architektura. W sumie zawsze się dziwiłem, po co ludzie się bawią jednoukładowymi komputerkami (czy też sterownikami mikroprocesorowymi) skoro wszystko można zrobić na PC?


Policz ile ma nóżek przeciętny procek w PC,
potrzebujesz takiego do sterowania pralką?
Po drugie sterowniki mają układy we/wy. przetworniki
analogowo cyfrowe, potrzeba minimum dodatkowych elementów.
Płytka może być malutka i tania.

-- 
Cezary Grądys <czarekgr@wa.onet.pl>

> Policz ile ma nóżek przeciętny procek w PC,
> potrzebujesz takiego do sterowania pralką?

Kto robi sterowniki pralki w domu?!?

> Po drugie sterowniki mają układy we/wy. przetworniki
> analogowo cyfrowe, potrzeba minimum dodatkowych elementów.
> Płytka może być malutka i tania.

Na USB podpięte do PC też powinny śmigać... Z resztą typowe urządzenie USB to sterownik mikroprocesorowy 8051...

On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nobody@nowhere.net> wrote:
> Czyli jak porownujemy liczby FP? Ano zawsze tak:
> a == b    =>   abs(a - b) <= EPS

Poczytaj sobie PEP485.

To co proponujesz nie nadaje się do danych które są z natury rzeczy 
mniejsze niż EPS. Czyli jeżeli np. a = 0.5*EPS,  b = 0 oraz EPS = 
sqrt(MACHINE_EPSILON), to błędnie uznasz że a == b.

Poprawniej jest porównywać abs(a-b) <= EPS*(abs(a)+abs(b)), ale i ten 
sposób - używany m.i. w Numerical Recipes - ma swoje wady.

Bo zasadniczy problem to nie porównywanie... do tego zawsze 
wystarczyłoby a == b... ale oszacowanie jak duże mogą być błędy 
zaokrągleń. A tego nie da się wiedzieć w bibliotece numerycznej nie 
znając domeny problemu. W szczególności są takie dane, gdzie jest 
około 20 dokładnych cyfr po przecinku.

On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nobody@nowhere.net> wrote:
> PS1: Nie zawsze teoretycznie mamy IEEE. Na rzeczonej Odrze
> czy Merze (czy nawet na PC-tach w poczatkowym okresie w
> kompilatorach MS-sa) liczby FP wcale nie byly IEEE-owe
> wiec nawet zalozenie o tych 17 cyfrach znaczacyh mantysy nie jest
> bezwzgledniee jedynie sluszne.

Zdziwisz się - FPU PC liczy na liczbach 80-bitowych, czyli nie są to 
typowe IEEE-754. Ale... choćby w tym nielubianym przez ciebie 
Fortranie - da się wybrać jak mają być przeprowadzane obliczenia - 
czy FPU, czy SSE itd. itp.

Jeszcze bardziej się zdziwisz gdy przeczytasz w/w standard: jest 
gwarantowane że liczby całkowite 32 bitowe można bezpiecznie trzymać 
(oraz porównywać) jako float point 64 bitowy.

On Sat, 17 Feb 2018 23:08:51 +0100, Cezary 
Grądys<czarekgr@wa.onet.pl> wrote:
> Policz ile ma nóżek przeciętny procek w PC,
> potrzebujesz takiego do sterowania pralką?

Jeżeli to AK to odpowiedź brzmi "tak".

> Płytka może być malutka i tania.

... Może być nawet do jednorazowego użytku, disposable. Ale niektórzy 
ludzie mają, patologiczną, chęć posiadania największego i 
najdroższego. Dla nich coś co małe, proste i tanie jest czymś 
niepojętym.

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nobody@nowhere.net> wrote:
>> Czyli jak porownujemy liczby FP? Ano zawsze tak:
>> a == b    =>   abs(a - b) <= EPS
>
> Poczytaj sobie PEP485.

Znam go w miare dokladnie.
Mowilem zreszta wyraznie, ze najczesciej stosuje sie EPS wzglednie,
ale.. nie zawsze na to sens. Czasem/czesto to wlasnie EPS bezwzgledny
jest odpowiedniejszy. Czesto stosuje sie techniki no..nazwe je "dynamicznym EPSem"
zwlaszac w przypadku algorytmow slabo/zbieznych/malo odpornych na bledy zaikraglen/malo stabilnych
gdzie nawet stosuje sie dosc zaawansowane statystyczne szacoiwanie bledu, aby
zdecydowac czy "toto jest rowne 0.0" (np. odleglosc od ekstremum).
Czesto jest to problem sam w sobie, bo np w przypadku dochodzenia
do ekstremum badac czy na tyle malo zmienia sie krok czy wartosc fukcji
czy moze obie? A co gdy funkcja jest bardzo plaska i krok (x) zmienia sie
"kilka rzedow" bardziej od wartosci(y)? Wtedy "moze" lepiej miec/stosowac
dwa EPS(XY), co jesy funkcja jest bardzo stroma, a co jestli jest
rozna w roznym zakresie/dziedzinie? Itp itd. Problem z fp (i w ogole
z szacowaniem "czy cus jest 0.0:) wydaje sie prosty, ale nim nie jest.

> To co proponujesz nie nadaje się do danych które są z natury rzeczy mniejsze niż EPS.

.. bo przeciez EPS jest _wlasnie po to _ aby do dobrac _wlasciwie_ do skali danych
/domeny wiec: albo stosowac roznice wzgledne albo stosowac EOS _odpowiednio_
dobrany, ale bezwzgledny. Nie zawsze roznice wzgkedne maja sens. Czesto wlasnie
EPS i roznice bezwzgledne sa wlasciwe,

PS: W "moich czasach" EPS zwykle wystepowal jako parametr stosowanej
procedury/algorytmu i.. nie posiadal anu wartosc domyslnych ani zalecanych.
Pozostawiano to (i slusznie) programiscie numerykowi.

> Poprawniej jest porównywać abs(a-b) <= EPS*(abs(a)+abs(b)), ale i ten sposób - używany m.i. w 
> Numerical Recipes - ma swoje wady.

To prawda. niekiedy "zwykly"surowy bezwzgledny EPS jest odpowiedniejszy
a niekiedy (tak jak zaznaczylem) EPS jest "dynamiczny" i jest to skomplikowany
test/algorytm np. statystyczny na podstawie/bazie dotychczasowych danych.

> Bo zasadniczy problem to nie porównywanie... do tego zawsze wystarczyłoby a == b... ale 
> oszacowanie jak duże mogą być błędy zaokrągleń.

Porownananie "sztywne"wiedzac, ze sa bledy zaokraglen/kunulacja bledow itp
jest zwykla bzdura, bo zaklamuije rzeczywistosc.

>A tego nie da się wiedzieć w bibliotece numerycznej nie  znając domeny problemu.

Tak. Tu 100% zgoda.

> W szczególności są takie dane, gdzie jest  około 20 dokładnych cyfr po przecinku.

Ilosc miejsc znaczacyh mantysy tak naprawde nie ma tu znaczenia.
Problem porownania/szacowania fp bedzie taki sam nawet przy 1000 cyfr znaczacych.

Liczy sie tez dokladnosc dzialan posrednich (a moze byc rozna/mniejsza od
wyniku/formatu koncowego. Liczy sie dlugosc akumulatorow wewnetrznych
w koprocesorze itp. Bardzo madrze u Laheya napisali, ze nawet jesli na dwoch
roznych srodowiskach stosuje sie "zewnetrznie" ten sam format IEEE to i tak
wyniki (i ich bledy) moga byc inne. Wlasnie z w/w powodow.

PS: Najlepiej przyjac zasade: _nic nie wiemy o formacie/dokladnosci liczb fp_
(nawet jesli wiemy wszystko:)

AK

Użytkownik "slawek" <fake@fakeemail.com> napisał:

> On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nobody@nowhere.net> wrote:
>> PS1: Nie zawsze teoretycznie mamy IEEE. Na rzeczonej Odrze
>> czy Merze (czy nawet na PC-tach w poczatkowym okresie w
>> kompilatorach MS-sa) liczby FP wcale nie byly IEEE-owe
>> wiec nawet zalozenie o tych 17 cyfrach znaczacyh mantysy nie jest
>> bezwzgledniee jedynie sluszne.
>
> Zdziwisz się - FPU PC liczy na liczbach 80-bitowych, czyli nie są to typowe IEEE-754.

Jakos nie jestem w ogole zdziwiony hihi :)

> Ale... choćby w tym nielubianym przez ciebie Fortranie - da się wybrać jak mają być przeprowadzane 
> obliczenia - czy FPU, czy SSE itd. itp.

No i co z tego?
Poza tym to nieprawda. W Fortranie nie  (pokaz mi odpowiedni zapis standardu)
tylko w _kompilatorze/srodowisku_.

> Jeszcze bardziej się zdziwisz gdy przeczytasz w/w standard: jest gwarantowane że liczby całkowite 
> 32 bitowe można bezpiecznie trzymać (oraz porównywać) jako float point 64 bitowy.

Ale skadze!. Np. na Waiteku (o ile dobrze pamietam) operacje na nich
byly czesto _szybsze_ niz te wykonywane wtedy przez zwykly procesor (386/386SX)
na 'longach' (bo wtedy int ===short a long == 32b a dzialania na longach to juz
byla (prosta bo prosta, ale jednak) procedura, a nie jeden rozkaz maszynowy
jak dzis.

Np. w takim BorlandzieC mam ja nawet pod reka:

F_LXMUL@        proc    far

                push    si
                mov     si,ax       ; bylo xchg
                mov     ax,dx   ; bylo xchg
                or      ax,ax
                jz      @@loc_1
                mul     bx
@@loc_1:
                jcxz    @@loc_2
                xchg    ax,cx
                mul     si
                add     ax,cx
@@loc_2:
                xchg    ax,si
                mul     bx
                add     dx,si
                pop     si
                ret

F_LXMUL@        endp

AK

W dniu 18.02.2018 o 12:21, szykcech@gmail.com pisze:

> 
> Na USB podpięte do PC też powinny śmigać... Z resztą typowe urządzenie USB to sterownik mikroprocesorowy 8051...
> 

Czasem potrzeba zrobić coś bardzo prostego typu miganie diodą i często
warto zamiast układu 555 dać najprostszy sterownik. Scalak powiedzmy 8
nóżek i możesz sobie jakiś cykl tego migania zaprogramować, cena
dosłownie kilka złotych. A zasilanie bateryjne?


-- 
Cezary Grądys <czarekgr@wa.onet.pl>