info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Martwa grupa?
82 views
Skip to first unread message
Robert Wańkowski
Feb 9, 2018, 4:20:40 AM2/9/18
to
Witam obecnych.
Ktoś tu zagląda, czy trzeba szukać jakiegoś forum?
Zaczynam z Pythonem i badam grunt gdzie by tu można podpytać o podstawy
podstaw. :-)
Właśnie jadę do księgarni zobaczyć czy coś kupię od ręki z półki.
Robert
Ktoś tu zagląda, czy trzeba szukać jakiegoś forum?
Zaczynam z Pythonem i badam grunt gdzie by tu można podpytać o podstawy
podstaw. :-)
Właśnie jadę do księgarni zobaczyć czy coś kupię od ręki z półki.
Robert
szyk...@gmail.com
Feb 9, 2018, 5:05:05 AM2/9/18
to
> 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...
Tak.
> czy trzeba szukać jakiegoś forum?
> Zaczynam z Pythonem i badam grunt gdzie by tu można podpytać o podstawy
> podstaw. :-)
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.
Robert Wańkowski
Feb 9, 2018, 5:22:13 AM2/9/18
to
W dniu 2018-02-09 o 11:05, szyk...@gmail.com pisze:
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
> 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
Marcin Konarski
Feb 9, 2018, 5:31:51 AM2/9/18
to
Pythona po angielsku (tutoriale na YT) może lepszą pomocą
byłyby korepetycje z języka angielskiego niż książa nt Pythona?
Pozdrawiam,
-A.
Roman Tyczka
Feb 9, 2018, 6:55:15 AM2/9/18
to
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
>> 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. :-)
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
Robert Wańkowski
Feb 9, 2018, 7:11:39 AM2/9/18
to
W dniu 2018-02-09 o 12:55, Roman Tyczka pisze:
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
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
Roman Tyczka
Feb 9, 2018, 7:33:11 AM2/9/18
to
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
>> 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. :-)
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
Robert Wańkowski
Feb 9, 2018, 7:42:51 AM2/9/18
to
W dniu 2018-02-09 o 13:33, Roman Tyczka pisze:
Też zaczynaliśmy w Logo, Small Basic teraz Python.
Scratch znamy w szkole będą mieli. Ale ta informatyka w szkole... ehh.
Robert
Scratch znamy w szkole będą mieli. Ale ta informatyka w szkole... ehh.
Robert
szyk...@gmail.com
Feb 9, 2018, 8:59:46 AM2/9/18
to
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...
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...
amor...@magna-power.com
Feb 9, 2018, 10:15:59 AM2/9/18
to
szyk...@gmail.com
Feb 9, 2018, 11:16:14 AM2/9/18
to
> 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.
szyk...@gmail.com
Feb 9, 2018, 11:19:28 AM2/9/18
to
> 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.
Adam M
Feb 9, 2018, 11:38:57 AM2/9/18
to
Adam M
Feb 9, 2018, 11:41:35 AM2/9/18
to
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).
> > 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.
szyk...@gmail.com
Feb 9, 2018, 12:41:14 PM2/9/18
to
> 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ą...
Robert Wańkowski
Feb 9, 2018, 12:44:22 PM2/9/18
to
W dniu 2018-02-09 o 12:55, Roman Tyczka pisze:
Widzę, że w przykładach jest raw_input a w naszym Python-ie jest input.
Przewertowałem kilka książek i się okazało, że jest Python 2.x i 3.x
Kupiliśmy tę książkę. Omawiany jest 3.x z uwzględnieniem 2.x
https://helion.pl/ksiazki/python-instrukcje-dla-programisty-eric-matthes,pythip.htm#format/dhttps://helion.pl/ksiazki/python-instrukcje-dla-programisty-eric-matthes,pythip.htm#format/d
Robert
AK
Feb 10, 2018, 5:38:29 AM2/10/18
to
Użytkownik "Robert Wańkowski" <rob...@wp.pl> napisał w wiadomości
news:5a7d8ff9$0$675$6578...@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
news:5a7d8ff9$0$675$6578...@news.neostrada.pl...
> Martwi mnie to, że oczekuje szybkich postępów. Chce już widzieć jakąś grafikę.
PS: Dobra rada:
Skup sie tylko na Pythonie3 i to od wersji min. 3.5
O Pythonie2 zapomnij natychmiast :)
AK
Robert Wańkowski
Feb 10, 2018, 5:47:51 AM2/10/18
to
W dniu 2018-02-10 o 11:37, AK pisze:
Python-a 3.6
Robert
> 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
AK
Feb 11, 2018, 11:55:38 AM2/11/18
to
Użytkownik "Robert Wańkowski" <rob...@wp.pl> napisał w wiadomości
news:5a7ecdd6$0$577$6578...@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.
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...
> Jeśli chcesz synowi "otworzyć oczy" na to "jak komputer działa", to jedyna sensowna opcja to
> Asembler.
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)
szyk...@gmail.com
Feb 11, 2018, 2:45:15 PM2/11/18
to
> > 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...
>
> 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
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".
Roman Tyczka
Feb 11, 2018, 3:40:32 PM2/11/18
to
On Sun, 11 Feb 2018 11:45:14 -0800 (PST), szyk...@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...]
>> 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
>
> Co po lekturze wybranej książki (przez Roberta) (na temat Pythona) będzie wiedział jego syn na temat budowy funkcjonalnej komputera?!?
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.
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".
myślenie i podejdź do tematu ze zrozumieniem... potrafisz?
--
pozdrawiam
Roman Tyczka
szyk...@gmail.com
Feb 11, 2018, 4:13:49 PM2/11/18
to
> I to mu absolutnie wystarczy w tym wieku i na tym etapie! A za rok zapomni
> o tym i zajmie się ...samolotami, koleją, statkami.
> o tym i zajmie się ...samolotami, koleją, statkami.
> Tobie się popieprzyło, ojciec nie szuka dla syna pracy... może włącz
> myślenie i podejdź do tematu ze zrozumieniem... potrafisz?
Proponuję się zapoznać z podejściem tego chłopca:
> myślenie i podejdź do tematu ze zrozumieniem... potrafisz?
https://www.youtube.com/channel/UCxpf6B0-PAT1WpWsf1eLzwQ/videos
On jakoś nie wierzy, że go w wieku 20 paru lat nagle oświeci i zbawi światłość polibudy, tylko sam zakasał rękawy i już studiuje tam od kiedy miał 9 lat. Co prawda taka postawa w tym wieku nie jest przypadkiem (ja się domyślam co go inspiruje i jaki ma układ) i nie jest też przypadkiem, że ma warunki do tego wszystkiego. Ale fakt jest taki, że on chce i mu wychodzi. I nie pierdoli głupot, że jest za mały i że to jest jego chwilowy kaprys. Jak będziemy podchodzić do tego, że to wszystko "jest chwilowym kaprysem" to nie będzie żadnych inżynierów po nas! A dziecko w wieku 10-12 lat rozpoczynając naukę zawodu może osiągnąć poziom genialny w wieku 20 paru lat. I oto tu chodzi by kreować geniuszy, a nie pierdoły które udają, że potrafią programować (Java, C#, JS, PHP, Python).
AK
Feb 12, 2018, 4:38:42 AM2/12/18
to
Użytkownik "Roman Tyczka" <noe...@because.no> napisał w wiadomości
news:1l4fm5u8...@tyczka.com...:
Ba!. Nawet Python na ten wiek zbyt skomplikowany.
PS: Zreszta zgadzam sie z wszytskim co napisales.
AK (syn nauczycieli: kazde z ponad 40-letnim stazem pracy).
news:1l4fm5u8...@tyczka.com...:
>> 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!
I to jest clue/sendno sprawy!!!
>
> I to mu absolutnie wystarczy w tym wieku i na tym etapie!
Ba!. Nawet Python na ten wiek zbyt skomplikowany.
PS: Zreszta zgadzam sie z wszytskim co napisales.
AK (syn nauczycieli: kazde z ponad 40-letnim stazem pracy).
AK
Feb 12, 2018, 4:44:36 AM2/12/18
to
Użytkownik <szyk...@gmail.com> napisał w wiadomości
news:4b1a20fe-a225-41c7...@googlegroups.com...
> Po za tym jak chcesz zrobić kontrolkę COM w Pythonie?!?
Doucz sie czlowieku:
"Kontrolki" w Pythonie robie dokladnie od 1998 roku.
Z wykorzystaniem czego chcesz ? pywin32 czy moze comtypes?
> A COM w aplikacjach komercyjnych to standard...
Tak. Tu 100% zgoda!
PS: na reszte albo bede odpowiadal wybiorczo (jesli beda tyczyc merytoryki) lub w ogole
(jesli bedzie zwyczajnie szkoda klawiatury na kolejne banialuki kolejnego Ayatolla C/C++).
AK
news:4b1a20fe-a225-41c7...@googlegroups.com...
> Po za tym jak chcesz zrobić kontrolkę COM w Pythonie?!?
"Kontrolki" w Pythonie robie dokladnie od 1998 roku.
Z wykorzystaniem czego chcesz ? pywin32 czy moze comtypes?
> A COM w aplikacjach komercyjnych to standard...
PS: na reszte albo bede odpowiadal wybiorczo (jesli beda tyczyc merytoryki) lub w ogole
(jesli bedzie zwyczajnie szkoda klawiatury na kolejne banialuki kolejnego Ayatolla C/C++).
AK
m
Feb 12, 2018, 7:47:58 AM2/12/18
to
W dniu 11.02.2018 o 20:45, szyk...@gmail.com pisze:
przewinął się podwątek na temat jednego z dyskutantów który zanim
zacznie uczyć studentów pętli for, najpierw ich wdraża w iteratory, a w
ogóle przede wszystkim trzeba poznać pełną gramatykę języka zanim się
cokolwiek zacznie robić.
To co piszesz bardzo mi to przypomina. Sorry, ale to jest podejście
leśnego dziadka który zanim pozwoli komuś przekręcić kluczyk w
samochodzie, każe mu samodzielnie nawinąć cewki rozrusznika.
p. m.
>>> 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...
>
Kilka miesięcy temu na comp.lang.python w wątku "loop and half"
>>> 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...
>
przewinął się podwątek na temat jednego z dyskutantów który zanim
zacznie uczyć studentów pętli for, najpierw ich wdraża w iteratory, a w
ogóle przede wszystkim trzeba poznać pełną gramatykę języka zanim się
cokolwiek zacznie robić.
To co piszesz bardzo mi to przypomina. Sorry, ale to jest podejście
leśnego dziadka który zanim pozwoli komuś przekręcić kluczyk w
samochodzie, każe mu samodzielnie nawinąć cewki rozrusznika.
p. m.
slawek
Feb 16, 2018, 1:10:25 PM2/16/18
to
On Fri, 9 Feb 2018 05:59:45 -0800 (PST), szyk...@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.
> �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.
slawek
Feb 16, 2018, 1:20:58 PM2/16/18
to
On Fri, 9 Feb 2018 07:15:58 -0800 (PST), amor...@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.
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.
slawek
Feb 16, 2018, 1:22:12 PM2/16/18
to
On Fri, 9 Feb 2018 08:38:56 -0800 (PST), Adam M
<amor...@magna-power.com> wrote:
> 3DNow! A tego nie da się zautomatyzować
Jak się nie da, jak się da. I tyle.
<amor...@magna-power.com> wrote:
> 3DNow! A tego nie da się zautomatyzować
slawek
Feb 16, 2018, 1:24:43 PM2/16/18
to
On Fri, 9 Feb 2018 09:41:09 -0800 (PST), szyk...@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.
> ł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.
slawek
Feb 16, 2018, 1:26:22 PM2/16/18
to
On Sat, 10 Feb 2018 11:37:57 +0100, "AK" <nob...@nowhere.net> wrote:
> Standardowy tkinter
Jeszcze lepiej: żówik.
> Skup sie tylko na Pythonie3 i to od wersji min. 3.5
True.
> Standardowy tkinter
Jeszcze lepiej: żówik.
> Skup sie tylko na Pythonie3 i to od wersji min. 3.5
slawek
Feb 16, 2018, 1:33:22 PM2/16/18
to
On Sun, 11 Feb 2018 11:45:14 -0800 (PST), szyk...@gmail.com wrote:
> A co złego w tym podejściu? Może znasz lepsze?!?
1. Wiele złego.
2. Znam.
slawek
Feb 16, 2018, 1:56:13 PM2/16/18
to
On Fri, 9 Feb 2018 18:44:22 +0100, Robert Wańkowski<rob...@wp.pl>
wrote:
uruchomić program z dwóch linijek: jedna to ten input, druga print?
Eksperymentuj! A może Google wyłączyli? A może zniknęła gdzieś
dokumentacja z Python.org?
Jeżeli rozwiążesz problem z input, to bonusem będzie poczucie że
zrobiłeś krok do przodu... a nie że potrafisz przepisać przykład z
książki bez zrobienia literówek.
wrote:
> Widzę, że w przykładach jest raw_input a w naszym Python-ie jest
input.
Użyj mózgu. To coś co masz pomiędzy uszami. Co ma robić input? Da się
input.
uruchomić program z dwóch linijek: jedna to ten input, druga print?
Eksperymentuj! A może Google wyłączyli? A może zniknęła gdzieś
dokumentacja z Python.org?
Jeżeli rozwiążesz problem z input, to bonusem będzie poczucie że
zrobiłeś krok do przodu... a nie że potrafisz przepisać przykład z
książki bez zrobienia literówek.
Robert Wańkowski
Feb 16, 2018, 2:16:23 PM2/16/18
to
W dniu 2018-02-16 o 19:56, slawek pisze:
Ale w kontekście czego się czepiasz, żem głupi?
Czyż nieprawdą jest że raw_input i input w zależności o wersji Pythona?
Coś więcej napisałem?
Robert
Czyż nieprawdą jest że raw_input i input w zależności o wersji Pythona?
Coś więcej napisałem?
Robert
AK
Feb 16, 2018, 5:56:25 PM2/16/18
to
Użytkownik "Robert Wańkowski" <rob...@wp.pl> napisał:
> Czyż nieprawdą jest że raw_input i input w zależności o wersji Pythona?
> Coś więcej napisałem?
Prawdą.
raw_input() z Py2 stal sie input-em() w Py3.
input() z Py2 poszedl do kosza, bo stanowil piekne zrodlo
wlamow/lamania bezpieczenstwa (bo po prostu dzialal
jak/poprzez eval()).
AK
> Czyż nieprawdą jest że raw_input i input w zależności o wersji Pythona?
> Coś więcej napisałem?
raw_input() z Py2 stal sie input-em() w Py3.
input() z Py2 poszedl do kosza, bo stanowil piekne zrodlo
wlamow/lamania bezpieczenstwa (bo po prostu dzialal
jak/poprzez eval()).
AK
AK
Feb 16, 2018, 6:46:51 PM2/16/18
to
Użytkownik "slawek" <fa...@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
> Ale na pewno to NIE JEST DOBRE DLA KAŻDEGO.
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.
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.
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")
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.
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
slawek
Feb 17, 2018, 1:51:36 AM2/17/18
to
On Fri, 16 Feb 2018 20:15:48 +0100, Robert Wańkowski<rob...@wp.pl>
wrote:
Teraz musisz po prostu samodzielnie myśleć... a nie liczyć na to że
ktoś wie lepiej i że wszystko znajdziesz w jakiejś jednej mądrej
książce jako gotowe rozwiązania.
> Czyż nieprawdą jest że raw_input i input w zależności o wersji
Pythona?
Jak już ci ktoś napisał: nie ma sensu zajmować się Pythonem 2.
wrote:
> Ale w kontekście czego się czepiasz, żem głupi?
Jeżeli zainteresował cię Python to nie jesteś głupi.
Teraz musisz po prostu samodzielnie myśleć... a nie liczyć na to że
ktoś wie lepiej i że wszystko znajdziesz w jakiejś jednej mądrej
książce jako gotowe rozwiązania.
> Czyż nieprawdą jest że raw_input i input w zależności o wersji
Pythona?
slawek
Feb 17, 2018, 2:49:44 AM2/17/18
to
On Sat, 17 Feb 2018 00:46:00 +0100, "AK" <nob...@nowhere.net> wrote:
> Jesli dla mnie to i dla kazdego.
Jeżeli ja noszę buty rozmiar 46, to dla każdego ten rozmiar jest
> Jesli dla mnie to i dla kazdego.
najlepszy?
> W przeciwienstwie do wiekszosci MWZDM staram sie byc normalnym
> W przeciwienstwie do Ciebie znam taka alternatywe/alternatywy.
> Jeszcze kilka lat temu wieszales na Pythonie psy
ani innego zwierzęcia.
> Slaba wydajniosc tez jest mityczna.
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.
AK
Feb 17, 2018, 5:40:02 AM2/17/18
to
Użytkownik "slawek" <fa...@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
>> Jesli dla mnie to i dla kazdego.
>
> Jeżeli ja noszę buty rozmiar 46, to dla każdego ten rozmiar jest najlepszy?
Ja nosze jeszcze standardowe 42 :).
>> 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.
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.
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
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.
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.
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.
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.
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.
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ą.
> Co ważne - to normalny język -
No.. doceniam! :)
> a nie zabawka w rodzaju Small Basic,
> Scratch czy Alice.
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
AK
Feb 17, 2018, 6:15:41 AM2/17/18
to
slawek
Feb 17, 2018, 8:29:14 AM2/17/18
to
On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nob...@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
> 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).
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ś.
AK
Feb 17, 2018, 8:43:52 AM2/17/18
to
Użytkownik "slawek" <fa...@fakeemail.com> napisał:
> On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nob...@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" <nob...@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.
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ś.
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
slawek
Feb 17, 2018, 8:46:03 AM2/17/18
to
On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nob...@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.
slawek
Feb 17, 2018, 8:56:31 AM2/17/18
to
On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nob...@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
> mitycznych/wydumanych 300MB.
jeszcze... I jest 270MB. Choć sam program to jakieś 200 LOC.
slawek
Feb 17, 2018, 9:04:57 AM2/17/18
to
On Sat, 17 Feb 2018 14:43:12 +0100, "AK" <nob...@nowhere.net> wrote:
> Mit.
> Na PC-tach wcale nie przewyzsza zwyklego C/C++/Pascal-a.
Sprawdziłeś? To sprawdź! Możesz się zdziwić...
> Mit.
> Na PC-tach wcale nie przewyzsza zwyklego C/C++/Pascal-a.
> Cudow nie ma.
CUDA jest.
AK
Feb 17, 2018, 10:42:03 AM2/17/18
to
Użytkownik "slawek" <fa...@fakeemail.com> napisał:
> On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nob...@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
> On Sat, 17 Feb 2018 11:39:20 +0100, "AK" <nob...@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.
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).
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.
Np. sposob obslugi subtablic w Pytnonie/numpy jest o wiele lepszy/wydajniejszy
niz w 'Maybachu' Matlabie.
AK
AK
Feb 17, 2018, 10:44:03 AM2/17/18
to
Użytkownik "slawek" <fa...@fakeemail.com> napisał:
Znow bredzisz.
Robiac pythono-frozen exeka bierze sie tylko to co faktycznie
jest uzywane a niekoniecznie to wszytsko co lezy na dysku.
AK
Robiac pythono-frozen exeka bierze sie tylko to co faktycznie
jest uzywane a niekoniecznie to wszytsko co lezy na dysku.
AK
AK
Feb 17, 2018, 10:49:41 AM2/17/18
to
Użytkownik "slawek" <fa...@fakeemail.com> napisał:
> On Sat, 17 Feb 2018 14:43:12 +0100, "AK" <nob...@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 14:43:12 +0100, "AK" <nob...@nowhere.net> wrote:
>> Mit.
>> Na PC-tach wcale nie przewyzsza zwyklego C/C++/Pascal-a.
>
> Sprawdziłeś? To sprawdź! Możesz się zdziwić...
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.
I to m.in. u zrodla:
https://developer.nvidia.com/pycuda
AK
slawek
Feb 17, 2018, 11:16:15 AM2/17/18
to
On Sat, 17 Feb 2018 16:41:22 +0100, "AK" <nob...@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ść
> Juz w czasach Odry/w mych czasach 1E-20 to bylo to samo co zero.
> Naucz sie uzywac i porownywac wreszcie liczby fp.
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.
slawek
Feb 17, 2018, 11:25:54 AM2/17/18
to
On Sat, 17 Feb 2018 16:43:22 +0100, "AK" <nob...@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)
> Robiac pythono-frozen exeka bierze sie tylko to co faktycznie
> jest uzywane a niekoniecznie to wszytsko co lezy na dysku.
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ą.
AK
Feb 17, 2018, 2:30:34 PM2/17/18
to
Użytkownik "slawek" <fa...@fakeemail.com> napisał:
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
> 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ę ?
> nieodpowiednie.
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
AK
Feb 17, 2018, 2:34:46 PM2/17/18
to
Użytkownik "slawek" <fa...@fakeemail.com> napisał:
Jesli mu kazales wszystko wciagnac, no to grzecznie wciagnal.
AK
>> 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".
>> jest uzywane a niekoniecznie to wszytsko co lezy na dysku.
>
> A bo ja wiem? Tyle mi wyszło.
Jesli mu kazales wszystko wciagnac, no to grzecznie wciagnal.
AK
AK
Feb 17, 2018, 3:01:29 PM2/17/18
to
Użytkownik "AK" <nob...@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
https://www.python.org/dev/peps/pep-0485/
i help(math.isclose())
tudziez
help(numpy.isclose())
help(numpy.allclose())
AK
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
> 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
AK
Feb 17, 2018, 3:23:15 PM2/17/18
to
Użytkownik "AK" <nob...@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
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
AK
Feb 17, 2018, 3:38:57 PM2/17/18
to
Użytkownik "slawek" <fa...@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
> Nie każdy liczy tylko liczbę sznurówek i rolek papieru toaletowego.
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
Cezary Grądys
Feb 17, 2018, 5:08:54 PM2/17/18
to
W dniu 09.02.2018 o 18:41, szyk...@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 <czar...@wa.onet.pl>
> 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 <czar...@wa.onet.pl>
szyk...@gmail.com
Feb 18, 2018, 6:21:40 AM2/18/18
to
> Policz ile ma nóżek przeciętny procek w PC,
> potrzebujesz takiego do sterowania pralką?
Kto robi sterowniki pralki w domu?!?
> 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.
slawek
Feb 18, 2018, 8:49:29 AM2/18/18
to
On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nob...@nowhere.net> wrote:
> Czyli jak porownujemy liczby FP? Ano zawsze tak:
> a == b => abs(a - b) <= EPS
Poczytaj sobie PEP485.
> Czyli jak porownujemy liczby FP? Ano zawsze tak:
> a == b => abs(a - b) <= EPS
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.
slawek
Feb 18, 2018, 9:16:03 AM2/18/18
to
On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nob...@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
> 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.
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.
slawek
Feb 18, 2018, 9:25:58 AM2/18/18
to
On Sat, 17 Feb 2018 23:08:51 +0100, Cezary
Grądys<czar...@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".
Grądys<czar...@wa.onet.pl> wrote:
> Policz ile ma nóżek przeciętny procek w PC,
> potrzebujesz takiego do sterowania pralką?
> Płytka może być malutka i tania.
ludzie mają, patologiczną, chęć posiadania największego i
najdroższego. Dla nich coś co małe, proste i tanie jest czymś
niepojętym.
AK
Feb 18, 2018, 10:08:24 AM2/18/18
to
Użytkownik "slawek" <fa...@fakeemail.com> napisał:
> On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nob...@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
> On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nob...@nowhere.net> wrote:
>> Czyli jak porownujemy liczby FP? Ano zawsze tak:
>> a == b => abs(a - b) <= EPS
>
> Poczytaj sobie PEP485.
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.
/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.
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ń.
jest zwykla bzdura, bo zaklamuije rzeczywistosc.
>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.
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
AK
Feb 18, 2018, 10:27:18 AM2/18/18
to
Użytkownik "slawek" <fa...@fakeemail.com> napisał:
> On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nob...@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.
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
> On Sat, 17 Feb 2018 20:29:51 +0100, "AK" <nob...@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.
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.
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
Cezary Grądys
Feb 18, 2018, 5:25:09 PM2/18/18
to
W dniu 18.02.2018 o 12:21, szyk...@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 <czar...@wa.onet.pl>
>
> Na USB podpięte do PC też powinny śmigać... Z resztą typowe urządzenie USB to sterownik mikroprocesorowy 8051...
>
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 <czar...@wa.onet.pl>
Roman Tyczka
Mar 12, 2018, 9:50:53 AM3/12/18
to
On Fri, 9 Feb 2018 10:20:20 +0100, Robert Wańkowski wrote:
> Właśnie jadę do księgarni zobaczyć czy coś kupię od ręki z półki.
https://helion.pl/ksiazki/programista-samouk-profesjonalny-przewodnik-do-samodzielnej-nauki-kodowania-cory-althoff,proprs.htm#format/d
Promo do północy -30%
--
pozdrawiam
Roman Tyczka
> Właśnie jadę do księgarni zobaczyć czy coś kupię od ręki z półki.
https://helion.pl/ksiazki/programista-samouk-profesjonalny-przewodnik-do-samodzielnej-nauki-kodowania-cory-althoff,proprs.htm#format/d
Promo do północy -30%
--
pozdrawiam
Roman Tyczka
0 new messages