Groups > pl.comp.programming > #33542 > unrolled thread

Ile czasu zajmie komputerowi rozszerzony algorytm euklidesa?

Started by	osobliwy nick <osobliwy.nick@gmail.com>
First post	2019-12-06 14:25 -0800
Last post	2020-01-11 21:54 +0100
Articles	20 on this page of 45 — 9 participants

Back to article view | Back to pl.comp.programming

Page 1 of 3 [1] 2 3 Next page →

#33542 — Ile czasu zajmie komputerowi rozszerzony algorytm euklidesa?

From	osobliwy nick <osobliwy.nick@gmail.com>
Date	2019-12-06 14:25 -0800
Subject	Ile czasu zajmie komputerowi rozszerzony algorytm euklidesa?
Message-ID	<ed31de14-90d3-405e-96e3-a82fcc32b9cc@googlegroups.com>

Chcę rozwiązywać równania typu:

a*2^(x+y)+b*g^y = 1

rozszerzonym algorytmem euklidesa dla losowych x+y=128, będących liczbami naturalnymi z zerem. Czy ktoś ma pomysł jak ustalić ile to może średnio zająć komputerowi dla całkowitego "g" wynoszącego powiedzmy 
5? Dodam tylko, że nie umiem programować, więc nie jestem w stanie napisać sobie żadnych testów (dopiero rozważam zlecenie napisania komuś programu).

Tutaj jest przykładowa implementacja rozszerzonego algorytmu euklidesa:

http://www.algorytm.edu.pl/rozszerzony-algorytm-euklidesa.html

Niestety nie wiem jak policzyć średni przypadek algorytmu. A kombinacji x+y równych 128 jest 128:

0+128=128
1+127=128
2+126=128
...
64+64=128
65+65=128
...
128+0=128

Więc do policzenia byłoby 128 przypadków użycia tego rozszerzonego algorytmu euklidesa. Chyba, że można to oszacować jak szybciej?

[toc] | [next] | [standalone]

#33544

From	godek.maciek@gmail.com
Date	2019-12-07 11:58 -0800
Message-ID	<f7034d01-5d38-40c6-8342-c911e426a20d@googlegroups.com>
In reply to	#33542

W dniu piątek, 6 grudnia 2019 23:25:56 UTC+1 użytkownik osobliwy nick napisał:
> Chcę rozwiązywać równania typu:
> 
> a*2^(x+y)+b*g^y = 1
> 
> rozszerzonym algorytmem euklidesa dla losowych x+y=128, będących liczbami naturalnymi z zerem. Czy ktoś ma pomysł jak ustalić ile to może średnio zająć komputerowi dla całkowitego "g" wynoszącego powiedzmy 
> 5?

Tak. Napisać program i to zmierzyć.

(Jeżeli dziedzina jest mała, to można sobie stabelaryzować wynik, i wówczas "wyliczenie" zajmie tyle, ile wydobycie danych z tablicy.)

> Dodam tylko, że nie umiem programować, więc nie jestem w stanie napisać sobie żadnych testów (dopiero rozważam zlecenie napisania komuś programu).

A dlaczego nie rozważysz "nauczenia się programowania"?
Brzmi to dość górnolotnie, ale nauczenie się jakiegoś języka w stopniu umożliwiającym Ci realizację rzeczy, o które pytasz, raczej nie zajmie Ci więcej czasu, niż napisanie takiego posta.

[toc] | [prev] | [next] | [standalone]

#33545

From	osobliwy nick <osobliwy.nick@gmail.com>
Date	2019-12-07 12:44 -0800
Message-ID	<a31aceaf-db83-42e1-a1ce-064abeb28058@googlegroups.com>
In reply to	#33544

W dniu sobota, 7 grudnia 2019 20:58:32 UTC+1 użytkownik godek...@gmail.com napisał:
> W dniu piątek, 6 grudnia 2019 23:25:56 UTC+1 użytkownik osobliwy nick napisał:
> > Chcę rozwiązywać równania typu:
> > 
> > a*2^(x+y)+b*g^y = 1
> > 
> > rozszerzonym algorytmem euklidesa dla losowych x+y=128, będących liczbami naturalnymi z zerem. Czy ktoś ma pomysł jak ustalić ile to może średnio zająć komputerowi dla całkowitego "g" wynoszącego powiedzmy 
> > 5?
> 
> Tak. Napisać program i to zmierzyć.
> 
> (Jeżeli dziedzina jest mała, to można sobie stabelaryzować wynik, i wówczas "wyliczenie" zajmie tyle, ile wydobycie danych z tablicy.)
> 
> > Dodam tylko, że nie umiem programować, więc nie jestem w stanie napisać sobie żadnych testów (dopiero rozważam zlecenie napisania komuś programu).
> 
> A dlaczego nie rozważysz "nauczenia się programowania"?
> Brzmi to dość górnolotnie, ale nauczenie się jakiegoś języka w stopniu umożliwiającym Ci realizację rzeczy, o które pytasz, raczej nie zajmie Ci więcej czasu, niż napisanie takiego posta.

Chodzi to za mną od dawna, ale to osobny temat. Miałem podstawy C na studiach, ale zapomniałem właściwie wszystkiego, nie byłem też szczególnie zdolnym studentem, jednocześnie nie miałem też szczególnie zdolnych prowadzących zajęcia (a to wiem od kolegów przybyłych do nas z Politechniki, studiujących jednocześnie inne kierunki, którzy krytykowali sposób nauczania na moim kierunku). W ostatnich latach zaś każdą wolną chwilę poświęcałem na naukę czegoś zupełnie innego - rynków finansowych i tradingu. I tak odkładałem to programowanie przez lata. Jednocześnie już na etapie analizy i testowania strategii tradingowych potrzebowałem... tak - umieć programować. Zleciłem wówczas dosyć szerokie testy i napisanie różnych programów pewnemu programiście. Ostatecznie zderzyliśmy się z teorią chaosu i efektem motyla - bo wykresy kursów łudząco przypominają błądzenie losowe (proces Wienera) i jest masa naukowych teorii i modeli traktująca o efektywności rynków finansowych i zachowaniu się kursu. Naiwni wtedy byliśmy, ale przynajmniej zyskałem fajnego znajomego.

Wracając do tematu. Może to jest ten moment. Na pewno masz rację, że powinienem to zrobić. Zwłaszcza, że poznałem z czym to się je i jakieś tam programy kilka lat temu nawet pisałem (na studiach i po nich). A już nie pierwszy raz zlecam komuś pisanie jakiegoś programu. Kiedyś zleciłem napisanie programu, który będzie poszukiwał liczb Crandalla, które nie będą liczbami Wieferich (problem z zakresu matematyki teoretycznej). Potrafiłem zostawić komputer odpalony na tydzień czasu, bo wzór, który to liczył przebiegał po ogromnej liczbie wariacji wielu zmiennych. Niczego niestety nie znalazłem.

Dzisiaj jednak mam inne już nieco dalej idące plany. Docelowo chcę założyć firmę, startup, która ma stworzyć program szyfrujący (na podstawie zaproponowanego przez mnie algorytmu) i opatentować to rozwiązanie, czy to w postaci implementacji, czy ogólnie algorytmu. Nie sądzę, że będę w stanie zrealizować ten plan samodzielnie, jako początkujący programista. Tutaj potrzeba ludzi, którzy robią to od lat, a najlepiej takich z doświadczeniem w kryptografii. I wobec konieczności zlecenia napisania takiego programu (a na początek testów), czy stworzenia całego oprogramowania, uczenie się programowania samodzielnie jest trochę jak zakładanie własnego zespołu kolarskiego i jednoczesne uczenie się jazdy na rowerze. Wiadomo, że prezes, czy sponsor zespołu sam nigdy na takiej kolarzówce nie będzie się tam ścigał razem z zawodnikami, jak bardzo by się nie starał.

[toc] | [prev] | [next] | [standalone]

#33548

From	godek.maciek@gmail.com
Date	2019-12-07 13:38 -0800
Message-ID	<152fff50-e2c9-48c2-b45c-dd859aa0b46c@googlegroups.com>
In reply to	#33545

W dniu sobota, 7 grudnia 2019 21:44:27 UTC+1 użytkownik osobliwy nick napisał:
> W dniu sobota, 7 grudnia 2019 20:58:32 UTC+1 użytkownik godek...@gmail.com napisał:
> > W dniu piątek, 6 grudnia 2019 23:25:56 UTC+1 użytkownik osobliwy nick napisał:
> > > Chcę rozwiązywać równania typu:
> > > 
> > > a*2^(x+y)+b*g^y = 1
> > > 
> > > rozszerzonym algorytmem euklidesa dla losowych x+y=128, będących liczbami naturalnymi z zerem. Czy ktoś ma pomysł jak ustalić ile to może średnio zająć komputerowi dla całkowitego "g" wynoszącego powiedzmy 
> > > 5?
> > 
> > Tak. Napisać program i to zmierzyć.
> > 
> > (Jeżeli dziedzina jest mała, to można sobie stabelaryzować wynik, i wówczas "wyliczenie" zajmie tyle, ile wydobycie danych z tablicy.)
> > 
> > > Dodam tylko, że nie umiem programować, więc nie jestem w stanie napisać sobie żadnych testów (dopiero rozważam zlecenie napisania komuś programu).
> > 
> > A dlaczego nie rozważysz "nauczenia się programowania"?
> > Brzmi to dość górnolotnie, ale nauczenie się jakiegoś języka w stopniu umożliwiającym Ci realizację rzeczy, o które pytasz, raczej nie zajmie Ci więcej czasu, niż napisanie takiego posta.
> 
> Chodzi to za mną od dawna, ale to osobny temat. Miałem podstawy C na studiach, ale zapomniałem właściwie wszystkiego, nie byłem też szczególnie zdolnym studentem, jednocześnie nie miałem też szczególnie zdolnych prowadzących zajęcia (a to wiem od kolegów przybyłych do nas z Politechniki, studiujących jednocześnie inne kierunki, którzy krytykowali sposób nauczania na moim kierunku). W ostatnich latach zaś każdą wolną chwilę poświęcałem na naukę czegoś zupełnie innego - rynków finansowych i tradingu. I tak odkładałem to programowanie przez lata. Jednocześnie już na etapie analizy i testowania strategii tradingowych potrzebowałem... tak - umieć programować. Zleciłem wówczas dosyć szerokie testy i napisanie różnych programów pewnemu programiście. Ostatecznie zderzyliśmy się z teorią chaosu i efektem motyla - bo wykresy kursów łudząco przypominają błądzenie losowe (proces Wienera) i jest masa naukowych teorii i modeli traktująca o efektywności rynków finansowych i zachowaniu się kursu. Naiwni wtedy byliśmy, ale przynajmniej zyskałem fajnego znajomego.
> 
> Wracając do tematu. Może to jest ten moment. Na pewno masz rację, że powinienem to zrobić. Zwłaszcza, że poznałem z czym to się je i jakieś tam programy kilka lat temu nawet pisałem (na studiach i po nich). A już nie pierwszy raz zlecam komuś pisanie jakiegoś programu. Kiedyś zleciłem napisanie programu, który będzie poszukiwał liczb Crandalla, które nie będą liczbami Wieferich (problem z zakresu matematyki teoretycznej). Potrafiłem zostawić komputer odpalony na tydzień czasu, bo wzór, który to liczył przebiegał po ogromnej liczbie wariacji wielu zmiennych. Niczego niestety nie znalazłem.
> 
> Dzisiaj jednak mam inne już nieco dalej idące plany. Docelowo chcę założyć firmę, startup, która ma stworzyć program szyfrujący (na podstawie zaproponowanego przez mnie algorytmu) i opatentować to rozwiązanie, czy to w postaci implementacji, czy ogólnie algorytmu. Nie sądzę, że będę w stanie zrealizować ten plan samodzielnie, jako początkujący programista. Tutaj potrzeba ludzi, którzy robią to od lat, a najlepiej takich z doświadczeniem w kryptografii. I wobec konieczności zlecenia napisania takiego programu (a na początek testów), czy stworzenia całego oprogramowania, uczenie się programowania samodzielnie jest trochę jak zakładanie własnego zespołu kolarskiego i jednoczesne uczenie się jazdy na rowerze. Wiadomo, że prezes, czy sponsor zespołu sam nigdy na takiej kolarzówce nie będzie się tam ścigał razem z zawodnikami, jak bardzo by się nie starał.

Jest taka książka, "Od dobrego do wielkiego", w której pojawia się koncepcja "przywódcy 5 poziomu". Dziwne nazwy na bok, chodzi o to, że autor przeanalizował wiele firm, które odniosło spektakularny sukces, i mu wyszło, że najlepsi przywódcy byli ekspertami w dziedzinie, w której działała firma.

(Może brzmi to trywialnie, ale wiele firm zatrudnia jako liderów "etatowych menadżerów", którzy "znają się tylko na zarządzaniu" i mają bardzo niewielką wiedzę dziedzinową).

W moim odczuciu programowanie dobrze uczy trzeźwości w odfiltrowywaniu magicznego myślenia od tego, co jest rzeczywiście możliwe do wykonania.

Zwłaszcza te pytania, które zadajesz, po prostu się proszą o to, żebyś to sprawdził samodzielnie. To dobry pretekst, żeby przysiąść i odświeżyć sobie wiedzę ze studiów. To jest naprawdę na wyciągnięcie ręki.

Co do "niezbyt zdolnych prowadzących zajęcia", to nie jest to dobra wymówka.
Ja większości zajęć z polibudy też nie wspominam jakoś rewelacyjnie - na uniwersytecie studiowało mi się dużo przyjemniej (zwłaszcza filozofię, ale nawet na infie nie było tak źle).

Ale to na polibudzie mieliśmy jednego profesora, który w kółko mówił, że "albo ktoś jest samoukiem, albo nieukiem". Nikt Cię niczego nie nauczy. Sam musisz się nauczyć. Dobry nauczyciel może tylko stworzyć okazję do zainteresowania się przedmiotem.

Dlatego - jasne - dobrze by było, żebyś znalazł sobie jakiegoś magika od optymalizacji programu pod konkretny sprzęt, bo tutaj jest dużo szczególików, których nie powinieneś musieć poznawać. Ale napisanie programu w C czy chociaż Pythonie powinieneś mieć w małym palcu, bo to są proste rzeczy.

Python nawet wspiera duże liczby, więc w przeciwieństwie do C nie jesteś ograniczony rozmiarem rejestrów.

[toc] | [prev] | [next] | [standalone]

#33557

From	osobliwy nick <osobliwy.nick@gmail.com>
Date	2019-12-10 19:24 -0800
Message-ID	<a1335981-5bd7-4951-b6e5-3a3063771fab@googlegroups.com>
In reply to	#33548

> Jest taka książka, "Od dobrego do wielkiego", w której pojawia się koncepcja "przywódcy 5 poziomu". Dziwne nazwy na bok, chodzi o to, że autor przeanalizował wiele firm, które odniosło spektakularny sukces, i mu wyszło, że najlepsi przywódcy byli ekspertami w dziedzinie, w której działała firma.

Pytanie, czy firma tworzącą program szyfrujący powinna mieć na czele bardziej programistę, czy specjalistę od algorytmów szyfrujących. To rzadko idzie w parze, aczkolwiek wiadomo, że najlepiej, aby potrafił jedno i drugie.

> Co do "niezbyt zdolnych prowadzących zajęcia", to nie jest to dobra wymówka.
> Ja większości zajęć z polibudy też nie wspominam jakoś rewelacyjnie - na uniwersytecie studiowało mi się dużo przyjemniej (zwłaszcza filozofię, ale nawet na infie nie było tak źle).
> Ale to na polibudzie mieliśmy jednego profesora, który w kółko mówił, że "albo ktoś jest samoukiem, albo nieukiem". Nikt Cię niczego nie nauczy. Sam musisz się nauczyć. Dobry nauczyciel może tylko stworzyć okazję do zainteresowania się przedmiotem.

To wiadomo. Rzecz w tym, że wówczas po prostu zniechęciłem się nieco do programowania. Nauka szła ciężko i prowadzący w tym szczególnie nie pomagali (byli opryskliwi). Co więcej wszyscy uczestnicy zajęć byli już po jakichś kursach programowania na swoich drugich kierunkach, które studiowali na Politechnice, więc łapali wszystko w lot. Ja natomiast stwierdziłem, że chyba nie jestem powołany do programowania, skoro tak kiepsko mi idzie w porównaniu z nimi. Fakt, że włożyłem mimo wszystko wówczas w to niewiele pracy, raczej niezbędne minimum.

[toc] | [prev] | [next] | [standalone]

#33563

From	Roman Tyczka <noemail@because.no>
Date	2019-12-12 09:59 +0100
Message-ID	<c5q7x3h3ck8l$.dlg@tyczka.com>
In reply to	#33548

On Sat, 7 Dec 2019 13:38:59 -0800 (PST), godek.maciek@gmail.com wrote:

> Jest taka książka, "Od dobrego do wielkiego", w której pojawia się
> koncepcja "przywódcy 5 poziomu". Dziwne nazwy na bok, chodzi o to, że
> autor przeanalizował wiele firm, które odniosło spektakularny sukces, i
> mu wyszło, że najlepsi przywódcy byli ekspertami w dziedzinie, w której
> działała firma. 
> 
> (Może brzmi to trywialnie, ale wiele firm zatrudnia jako liderów
> "etatowych menadżerów", którzy "znają się tylko na zarządzaniu" i mają
> bardzo niewielką wiedzę dziedzinową). 
> 
> W moim odczuciu programowanie dobrze uczy trzeźwości w odfiltrowywaniu
> magicznego myślenia od tego, co jest rzeczywiście możliwe do wykonania.

100% racji i celnie ujęte, szkoda, że w praktyce rzadko się to spotyka. 

btw a książkę o której wspomniałeś już sobie zamówiłem, dzięki za cynk,
wydaje się ciekawą pozycją

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#33551

From	Maciej Sobczak <see.my.homepage@gmail.com>
Date	2019-12-08 11:24 -0800
Message-ID	<72e58de1-0684-4e65-8e2e-9fb4edbb9172@googlegroups.com>
In reply to	#33544

> > Dodam tylko, że nie umiem programować,
> 
> A dlaczego nie rozważysz "nauczenia się programowania"?

Przychylam się do tej sugestii.

Wygląda na to, że potrafisz racjonalnie analizować a nawet skonstruować algorytm obliczenia czegoś. Właściwie od tego miejsca do napisania programu, który demonstruje/testuje Twoje pomysły jest tylko prosty krok rzemieślniczy. Możesz się nawet zdziwić gdy zobaczysz, że prezycyjny opis algorytmu jest łatwiejszy w jakimś języku programowania, niż w języku naturalnym - a przecież zlecając komuś napisanie programu musiałbyś mu najpierw wytłumaczyć, co ma napisać.
Więc po co sobie utrudniać?

Oczywiście możesz sobie zatrudnić kiedyś specjalistów od wydziwiania i różnego rodzaju oszczędności (czasu, energii elektrycznej, kosztów produkcji/wdrożenia, itd.), ale zdolność napisania referencyjnej implementacji i tak będzie Ci potrzebna, żebyś mógł być dla swojego zespołu liderem a nie tylko szefem.

Więc do dzieła. Może nawet faktycznie Python będzie tu racjonalnym wyborem - dla Ciebie. Ale biorąc pod uwagę cel, który chcesz osiągnąć, nie zatrudniaj programistów, którzy znają tylko Pythona.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33558

From	osobliwy nick <osobliwy.nick@gmail.com>
Date	2019-12-10 19:40 -0800
Message-ID	<1796d3fc-8036-488e-8346-c5073aab2b5d@googlegroups.com>
In reply to	#33551

> Przychylam się do tej sugestii.
> 
> Wygląda na to, że potrafisz racjonalnie analizować a nawet skonstruować algorytm obliczenia czegoś. Właściwie od tego miejsca do napisania programu, który demonstruje/testuje Twoje pomysły jest tylko prosty krok rzemieślniczy. Możesz się nawet zdziwić gdy zobaczysz, że prezycyjny opis algorytmu jest łatwiejszy w jakimś języku programowania, niż w języku naturalnym - a przecież zlecając komuś napisanie programu musiałbyś mu najpierw wytłumaczyć, co ma napisać.
> Więc po co sobie utrudniać?

Miałem taki moment powrotu do programowania. Napisałem nawet pierwszy program od lat. Chodziło o ten problem:

http://cpp0x.pl/forum/temat/?id=22559

Poległem jednak wtedy. Napisanie tego było dla mnie nie do przeskoczenia, a jak zobaczyłem kod, którego oczywiście nie rozumiałem, który ktoś napisał ot tak, po krótkim czasie od ręki, stwierdziłem, że raczej żadnym rozsądnym czasie nie osiągnę takiego poziomu. Ostatecznie na podstawie tego co mi tam zasugerowano zleciłem komuś odpłatnie napisanie tego programu. Programista z tego co pamiętam i tak napisał cały kod od początku po swojemu, ale był on nie mniej złożony od tego, który podpowiadano mi w wątku.

I wtedy z poziomu dosyć wysokiej motywacji popadłem w marazm i zostawiłem programowanie na kolejne lata.

> Oczywiście możesz sobie zatrudnić kiedyś specjalistów od wydziwiania i różnego rodzaju oszczędności (czasu, energii elektrycznej, kosztów produkcji/wdrożenia, itd.), ale zdolność napisania referencyjnej implementacji i tak będzie Ci potrzebna, żebyś mógł być dla swojego zespołu liderem a nie tylko szefem.

No tak, masz rację.

> Więc do dzieła. Może nawet faktycznie Python będzie tu racjonalnym wyborem - dla Ciebie. Ale biorąc pod uwagę cel, który chcesz osiągnąć, nie zatrudniaj programistów, którzy znają tylko Pythona.

Ok. Zmotywowaliście mnie. Będę myślał w takim razie o powrocie do tematu programowania. A właściwie o zaczęciu od początku, bo pomimo, że wiem co to programowanie, jak to się robi itd., to moje praktycznie umiejętności są znikome. Co do języka myślałem o C++, bo często mam do policzenia jakieś matematyczne rzeczy, a ten język kojarzy mi się z takimi inżynierskimi i matematycznymi zastosowaniami. Poza tym łatwo znaleźć materiały na jego temat.

[toc] | [prev] | [next] | [standalone]

#33559

From	godek.maciek@gmail.com
Date	2019-12-11 03:53 -0800
Message-ID	<a0f802d0-fb07-43d9-9d76-9ea33f556ed9@googlegroups.com>
In reply to	#33558

W dniu środa, 11 grudnia 2019 04:40:28 UTC+1 użytkownik osobliwy nick napisał:
> > Przychylam się do tej sugestii.
> > 
> Ok. Zmotywowaliście mnie. Będę myślał w takim razie o powrocie do tematu programowania. A właściwie o zaczęciu od początku, bo pomimo, że wiem co to programowanie, jak to się robi itd., to moje praktycznie umiejętności są znikome. Co do języka myślałem o C++, bo często mam do policzenia jakieś matematyczne rzeczy, a ten język kojarzy mi się z takimi inżynierskimi i matematycznymi zastosowaniami. Poza tym łatwo znaleźć materiały na jego temat.

Ja osobiście raczej bym odradzał C++ do Twoich zastosowań.
Jest to język nadmiernie skomplikowany, i nawet nie za dobrze radzi sobie z liczbami (domyślnie implementuje arytmetykę modulo 2^32 albo 2^64)

Raczej bym polecał albo Racket, bo jest bardzo prosty i jest dla niego dużo dobrych materiałów dydaktycznych, a do tego wspiera od razu arytmetykę o dowolnej precyzji oraz liczby wymierne. Spośród materiałów dydaktycznych jest książka "How To Design Programs", dostępna za darmo tutaj (jakościowo o rzędy wielkości lepsza od jakichkolwiek materiałów o C++, z jakimi miałem styczność):

https://htdp.org/2019-02-24/

Na podstawie tej książki powstał kurs o systematycznym projektowaniu programów:

https://www.youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w

Jest też nieco starsza, ale wciąż nie chcąca się zestarzeć książka "Structure and Interpretation of Computer Programs" (wydana swego czasu też po Polsku przez WNT jako "Struktura i Interpretacja Programów Komputerowych"), udostępniona za darmo na stronie MIT:

https://mitpress.mit.edu/sites/default/files/sicp/index.html

Kurs, na potrzeby którego książka została opracowana, również można znaleźć na youtubie:

https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CABEA24090

Warto ewentualnie rozważyć język Haskell, który jest bardziej złożony, ale ma dość wydajną implementacje, i jest też sobie w stanie poradzić z dużymi liczbami (i pod względem składni mocno przypomina klasyczną notację matematyczną).

Rozwiązanie podlinkowanego przez Ciebie przykładu wyglądałoby tak.
Najpierw definiujemy sobie iloczyn kartezjański listy list, żeby móc generować ciągi wartośći x1, ..., xN:

cartprod [] = [[]]
cartprod (xs:xss) = [x:ys | x <- xs, ys <- cartprod xss]

wyprowadzenie powyższej definicji możesz znaleźć tutaj:
http://myhaskelljournal.com/cartesian-product-of-lists/

następnie definiujemy produkt kartezjański

cartpow l n = cartprod $ take n $ repeat l

gdzie (repeat l) tworzy nieskończoną listę powtórzeń listy l, zaś take n bierze tylko n początkowych elementów.

Ponieważ jest u Ciebie warunek, że

x1 >= x2 >= ... >= xN

to możemy wybrać tylko te punkty z iloczynu kartezjańskiego, których wartościami są nierosnące ciągi:

nonasc (x:y:zs) = x >= y && nonasc (y:zs)
nonasc _ = True

Wreszcie, funkcja budująca zbiory punktów [x1, ..., xN] może mieć postać:

dom x n = [p | p <- (cartpow [0 .. x] n), nonasc p]

czyli zbiór wszystkich punktów z potęgi kartezjańskiej, których kolejne współrzędne tworzą ciąg nierosnący.

Można łatwo sprawdzić, że np. (dom 3 2) da nam wartość

[[0,0],[1,0],[1,1],[2,0],[2,1],[2,2],[3,0],[3,1],[3,2],[3,3]]

I teraz chcemy znaleźć elementy, które spelniają Twoje kryterium.
Żeby Haskell obsłużył liczby wymierne, trzeba załadować moduł Data.Ratio:

import Data.Ratio

Operator dzielenia wymiernego liczb całkowitych jest wówczas wyrażany symbolem %.

Pozwala to zdefiniować nam zbiór interesujących Cię liczb jako:

ws x y p = [(sum [(p^xn)%(2^xn) | xn <- seq]) * ((2^(y-1))%(2^(x+y)-p^y))
            | seq <- (dom x (y-1))]

i wtedy możemy sprawdzić, że wyrażenie (ws 3 3 3) da nam listę

[8 % 37,
10 % 37,
12 % 37,
13 % 37,
15 % 37,
18 % 37,
35 % 74,
39 % 74,
45 % 74,
27 % 37]

Jest to inny zbiór od tego, który podałeś w swoim drugim poście, więc możliwe, że źle zrozumiałem specyfikację.

W każdym razie "rozmawiając" sobie z interpreterem Racketa albo Haskella, możesz dość łatwo przeszukać interesujące Cię dziedziny.

[toc] | [prev] | [next] | [standalone]

#33560

From	Maciej Sobczak <see.my.homepage@gmail.com>
Date	2019-12-11 11:46 -0800
Message-ID	<d2cf63a5-4776-439f-a5a7-c028764e6b33@googlegroups.com>
In reply to	#33559

> Ja osobiście raczej bym odradzał C++ do Twoich zastosowań.
[...]

A ja bym nie odradzał, bo jeśli pomysł ma ostatecznie zostać skomercjalizowany, to *nieuniknionym* targetem będzie właśnie C++.

Więc jeśli jest już entuzjazm do C++ (w odróżnieniu do wspomnianego Pythona), to nie ma powodu, żeby z niego rezygnować.

> Raczej bym polecał albo Racket,
[...]
> Warto ewentualnie rozważyć język Haskell,
[...]

No jednak nie powstrzymałeś się. :-)
W takim razie obowiązkowe:

https://www.wolfram.com/broadcast/video.php?c=362&v=1049

W temacie eksploracji zagadnień matematycznych Wolfram nie ma merytorycznej konkurencji.
Ale przecież już o tym było. :-)

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33561

From	godek.maciek@gmail.com
Date	2019-12-11 12:47 -0800
Message-ID	<47282e96-b356-43ba-89d3-ed0561bc1d30@googlegroups.com>
In reply to	#33560

W dniu środa, 11 grudnia 2019 20:46:36 UTC+1 użytkownik Maciej Sobczak napisał:
> > Ja osobiście raczej bym odradzał C++ do Twoich zastosowań.
> [...]
> 
> A ja bym nie odradzał, bo jeśli pomysł ma ostatecznie zostać skomercjalizowany, to *nieuniknionym* targetem będzie właśnie C++.
> 
> Więc jeśli jest już entuzjazm do C++ (w odróżnieniu do wspomnianego Pythona), to nie ma powodu, żeby z niego rezygnować.

C++ to język, na którym niestety łatwo się sparzy. A jego nieuniknioność to raczej mit. (Jest np. firma tradingowa Jane Street, która do swoich zastosowań wymagających duźej wydajności używa języka OCaml. A Mozilla konsekwentnie zastępuje C++a w Firefoxie Rustem)

[toc] | [prev] | [next] | [standalone]

#33566

From	Maciej Sobczak <see.my.homepage@gmail.com>
Date	2019-12-12 10:25 -0800
Message-ID	<c31c3b18-fdc5-4948-bfbb-0a51d304bf7a@googlegroups.com>
In reply to	#33561

> C++ to język, na którym niestety łatwo się sparzy.

Albo odniesie sukces, podobny do wielu innych sukcesów w C++.

> A jego nieuniknioność to raczej mit.

Z tego co zrozumiałem, kolega chce zrobić jakiś algorytm. Więc zapewne będzie chciał, żeby jego implementacja była możliwa do użycia w jak największej liczbie różnych kontekstów - czy to poprzez pluginy, czy jako biblioteki do załadowania w innym języku, itp. Najpowszechniejszym formatem takich modułów są biblioteki z interfejsem w C, najlepiej bez narzucania się z obcym run-timem (np. ładowanie modułu w Javie do programu w .NET to głupi pomysł, ale moduł w C++ można załadować zarówno do Javy jak i do .NET).

Nieuniknioność C++ wynika z tego, że spełniając te warunki, jest jednocześnie dobrze znanym a w porównaniu do gołego C ma dodatkowe cechy, które sprawiają, że w takich właśnie zastosowaniach jest obiektywnie lepszy.

> Jest np. firma tradingowa Jane Street, która do swoich zastosowań wymagających duźej wydajności używa języka OCaml. A Mozilla konsekwentnie zastępuje C++a w Firefoxie Rustem

Brawo oni. Ale uwaga: nie da się tych rzeczy wykorzystać gdzie indziej, więc nie nadają się do komercjalizacji same z siebie.

Kontrprzykład: TensorFlow, chyba najpowszechniej wykorzystywany framework do machine learningu, jest napisany w C++. Dzięki tym cechom, o których napisałem powyżej, większość ludzi korzystających z tego np. w Pythonie nawet o tym nie wie. I nie musi.
I właśnie to jest źródłem sukcesu tego frameworku.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33567

From	godek.maciek@gmail.com
Date	2019-12-12 14:04 -0800
Message-ID	<9f3bbc44-70af-4f1b-a99d-c4d46908b5a8@googlegroups.com>
In reply to	#33566

W dniu czwartek, 12 grudnia 2019 19:25:38 UTC+1 użytkownik Maciej Sobczak napisał:
> > C++ to język, na którym niestety łatwo się sparzy.
> 
> Albo odniesie sukces, podobny do wielu innych sukcesów w C++.
> 
> > A jego nieuniknioność to raczej mit.
> 
> Z tego co zrozumiałem, kolega chce zrobić jakiś algorytm. Więc zapewne będzie chciał, żeby jego implementacja była możliwa do użycia w jak największej liczbie różnych kontekstów - czy to poprzez pluginy, czy jako biblioteki do załadowania w innym języku, itp. Najpowszechniejszym formatem takich modułów są biblioteki z interfejsem w C, najlepiej bez narzucania się z obcym run-timem (np. ładowanie modułu w Javie do programu w .NET to głupi pomysł, ale moduł w C++ można załadować zarówno do Javy jak i do .NET).

Mam kolegę, który tworzy język programowania Ć:
https://github.com/pfusik/cito
Programy nim napisane można tłumaczyć do C, C++, C#, Javy, JavaScriptu, i zdaje się że nawet D i Perla.
Można użyć.

> Nieuniknioność C++ wynika z tego, że spełniając te warunki, jest jednocześnie dobrze znanym a w porównaniu do gołego C ma dodatkowe cechy, które sprawiają, że w takich właśnie zastosowaniach jest obiektywnie lepszy.

Być może. Nie zmienia to jednak faktu, że C++ jest językiem bardzo złożonym, i że jego złożoność w dużej mierze wynika z zaszłości historycznych, które osobę nastawioną na konkretne cele nie będą szczególnie interesować, a mogą łatwo zniechęcić.

> > Jest np. firma tradingowa Jane Street, która do swoich zastosowań wymagających duźej wydajności używa języka OCaml. A Mozilla konsekwentnie zastępuje C++a w Firefoxie Rustem
> 
> Brawo oni. Ale uwaga: nie da się tych rzeczy wykorzystać gdzie indziej, więc nie nadają się do komercjalizacji same z siebie.
> 
> Kontrprzykład: TensorFlow, chyba najpowszechniej wykorzystywany framework do machine learningu, jest napisany w C++. Dzięki tym cechom, o których napisałem powyżej, większość ludzi korzystających z tego np. w Pythonie nawet o tym nie wie. I nie musi.
> I właśnie to jest źródłem sukcesu tego frameworku.

Źródło sukcesu TensorFlow jest takie samo, jak źródło sukcesu Pythona, mianowicie to, że oba projekty zostały mocno doinwestowane przez firmę Google.

Zresztą to dość typowe zjawisko. Podobnie źródłem sukcesu IBM PC było to, że stała za nim firma IBM (i że ten projekt zaniedbała), a nie to, że był jakimś technicznym majstersztykiem. Podobnie C++ został mocno doinwestowany przez korporacje.

Ja znam jeszcze dwie inne historie: Viaweb Paula Grahama i Minecraft Markusa Perssona. Obie zostały napisane w różnych językach (odpowiednio: Common Lispie i Javie), a następnie wykupione za duże pieniądze przez wielkie korporacje (odpowiednio: Yahoo i Microsoft) i przepisane na C++.

Ta droga jest ważna, bo pokazuje, że C++ jest raczej językiem do 'zacementowywania' istniejących projektów, niż do dostarczania innowacji.

[toc] | [prev] | [next] | [standalone]

#33572

From	Maciej Sobczak <see.my.homepage@gmail.com>
Date	2019-12-13 12:06 -0800
Message-ID	<5577b64d-f88c-4a32-80fd-2e5d5fd11cce@googlegroups.com>
In reply to	#33567

> Mam kolegę, który tworzy język programowania Ć:

Jedni zbierają znaczki a inni klej do znaczków...

> Programy nim napisane można tłumaczyć do C, C++, C#, Javy, JavaScriptu, i zdaje się że nawet D i Perla.

Obrazki w UMLu też można tłumaczyć. Nic z tego nie wynika od 30 lat.

Ale tak konkretnie - jaką wadę języka C++ można ominąć pisząc program w języku Ć i tłumacząc go potem do C++ i jednocześnie nie rezygnując z zalet, z których można by było skorzystać od razu pisząc w C++?

W sensie - jaka jest wartość dodana tego języka Ć?

> Można użyć.

Pytanie, jaki jest cel tego ćwiczenia. Bo jeśli komercjalizacja jakiegoś pomysłu, to nie chodzi o to, że "można użyć", tylko czego użyć, żeby jak najlepiej osiągnąć zamierzony efekt. Hasło "można użyć" jest zupełnie z innej płaszczyzny. Dokładnie na tej samej zasadzie niektórzy zbierają klej do znaczków. Można zbierać.

> Być może. Nie zmienia to jednak faktu, że C++ jest językiem bardzo złożonym

To używaj wybranego podzbioru. Wtedy taki (pod)język będzie mniej złożony.

Teza: dla każdego problemu/zadania istnieje sensownie niezłożony podzbiór języka C++, w którym można ten problem/zadanie rozwiązać/zrealizować.

Język polski też jest jednym z bardziej złożonych, ale żeby się skutecznie pokłócić na usenecie, wystarczy jego mały podzbiór.

Częstym błędem jest stosowanie tych elementów języka, których nie trzeba było używać.

Zaraz, zaraz - już wiem! Bo... można użyć.
Niestety to jest powszechna choroba inżynierów, nie tylko programistów.

> Źródło sukcesu TensorFlow jest takie samo, jak źródło sukcesu Pythona, mianowicie to, że oba projekty zostały mocno doinwestowane przez firmę Google.

Błąd. Firma Google zainteresowała się Pythonem dopiero po tym, jak Python osiągnął sukces.
Możliwe, że z punktu widzenia managementu trochę niewygodny był fakt, że każda inna duża firma miała jakiś "swój" język. Zatrudnienie Guido mogło się wydawać "rozwiązaniem" tego marketingowego problemu. Tak czy inaczej - najpierw był sukces, potem adopcja.

> Podobnie C++ został mocno doinwestowany przez korporacje.

I tu się wyłożyłeś używając słowa "korporacje" zaraz po tym, jak w innym kontekście podałeś konkretne nazwy. Słowo "korporacje" oznacza tyle samo, co "oni", albo "wszyscy".
Czyli sukces C++ wynikał z tego, że wszyscy go używali? Oczywiście.

Dlatego też zachodzi podejrzenie, że do zadania z tego wątku też będzie to dobry wybór.

> Ja znam jeszcze dwie inne historie: Viaweb Paula Grahama i Minecraft Markusa Perssona. Obie zostały napisane w różnych językach (odpowiednio: Common Lispie i Javie), a następnie wykupione za duże pieniądze przez wielkie korporacje (odpowiednio: Yahoo i Microsoft) i przepisane na C++.

Ciekawe. Ale to fajne przykłady.

> Ta droga jest ważna, bo pokazuje, że C++ jest raczej językiem do 'zacementowywania' istniejących projektów, niż do dostarczania innowacji.

Mam inną tezę. Wykupienie tych produktów wiązało się z założeniem, że będą dostarczone na masowy rynek (w przypadku projektów sieciowych oznacza to masowe obciążenia) a najwyraźniej na komercyjnym rynku C++ jest właściwym narzędziem, żeby sprostać komercyjnym wymaganiom. "Zacementowanie" jest celem, któro nie dość, że niczego nie oznacza, to jeszcze trudno taki cel uzasadnić koniecznymi kosztami. Natomiast poniesienie kosztów, żeby dostarczyć użytkownikom niezawodny produkt, jest jak najbardziej racjonalne. I to również jest powód, żeby się tym językiem zainteresować.

Oczywiście można też wysunąć argumentację, że "oni" (korporacje?) robią źle, bo są źli, więc skoro robią coś w C++, to na pewno C++ też jest zły.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33573

From	godek.maciek@gmail.com
Date	2019-12-13 13:37 -0800
Message-ID	<58b7973f-e791-4d86-b35d-4af7fbefd650@googlegroups.com>
In reply to	#33572

W dniu piątek, 13 grudnia 2019 21:06:19 UTC+1 użytkownik Maciej Sobczak napisał:

> 
> > Programy nim napisane można tłumaczyć do C, C++, C#, Javy, JavaScriptu, i zdaje się że nawet D i Perla.
> 
> Obrazki w UMLu też można tłumaczyć. Nic z tego nie wynika od 30 lat.
> 
> Ale tak konkretnie - jaką wadę języka C++ można ominąć pisząc program w języku Ć i tłumacząc go potem do C++ i jednocześnie nie rezygnując z zalet, z których można by było skorzystać od razu pisząc w C++?
> 
> W sensie - jaka jest wartość dodana tego języka Ć?

Sam chwilę temu pisałeś o problemach z wołaniem Javy z C# albo na odwrót.

> > Można użyć.
> 
> Pytanie, jaki jest cel tego ćwiczenia. Bo jeśli komercjalizacja jakiegoś pomysłu, to nie chodzi o to, że "można użyć", tylko czego użyć, żeby jak najlepiej osiągnąć zamierzony efekt. Hasło "można użyć" jest zupełnie z innej płaszczyzny. Dokładnie na tej samej zasadzie niektórzy zbierają klej do znaczków. Można zbierać.

To życzę udanych zbiorów.

> > Być może. Nie zmienia to jednak faktu, że C++ jest językiem bardzo złożonym
> 
> To używaj wybranego podzbioru. Wtedy taki (pod)język będzie mniej złożony.
> 
> Teza: dla każdego problemu/zadania istnieje sensownie niezłożony podzbiór języka C++, w którym można ten problem/zadanie rozwiązać/zrealizować.

To bardzo fajnie.
Tylko skąd będę wiedział, który podzbiór jest tym właściwym?

> Język polski też jest jednym z bardziej złożonych, ale żeby się skutecznie pokłócić na usenecie, wystarczy jego mały podzbiór.

Żeby się porozumieć, trzeba mieć wolę porozumienia.

> > Źródło sukcesu TensorFlow jest takie samo, jak źródło sukcesu Pythona, mianowicie to, że oba projekty zostały mocno doinwestowane przez firmę Google.
> 
> Błąd. Firma Google zainteresowała się Pythonem dopiero po tym, jak Python osiągnął sukces.

Jaki konkretnie sukces osiągnął Python przed zainteresowaniem się nim przez Google?

> Możliwe, że z punktu widzenia managementu trochę niewygodny był fakt, że każda inna duża firma miała jakiś "swój" język. Zatrudnienie Guido mogło się wydawać "rozwiązaniem" tego marketingowego problemu. Tak czy inaczej - najpierw był sukces, potem adopcja.
> 
> > Podobnie C++ został mocno doinwestowany przez korporacje.
> 
> I tu się wyłożyłeś używając słowa "korporacje" zaraz po tym, jak w innym kontekście podałeś konkretne nazwy. Słowo "korporacje" oznacza tyle samo, co "oni", albo "wszyscy".

Nie. Oznacza instytucje, które dysponują zasobami. Jeżeli pytasz o jakie korporacje chodzi, to przede wszystkim Microsoft z Visual C++, oraz Intel, któty raz że ma produkt w postaci ICC, a dwa że kontrybuuje do GCC, bo mu to zwiększa sprzedaż procesorów.

> Czyli sukces C++ wynikał z tego, że wszyscy go używali? Oczywiście.


Sukces C++ wyniknął stąd, że znalazły się podmioty, które zrobiły dla niego dobre narzędzia.

> Dlatego też zachodzi podejrzenie, że do zadania z tego wątku też będzie to dobry wybór.

Może będzie. Trzymam kciuki.

> > Ja znam jeszcze dwie inne historie: Viaweb Paula Grahama i Minecraft Markusa Perssona. Obie zostały napisane w różnych językach (odpowiednio: Common Lispie i Javie), a następnie wykupione za duże pieniądze przez wielkie korporacje (odpowiednio: Yahoo i Microsoft) i przepisane na C++.
> 
> Ciekawe. Ale to fajne przykłady.
> 
> > Ta droga jest ważna, bo pokazuje, że C++ jest raczej językiem do 'zacementowywania' istniejących projektów, niż do dostarczania innowacji.
> 
> Mam inną tezę. Wykupienie tych produktów wiązało się z założeniem, że będą dostarczone na masowy rynek (w przypadku projektów sieciowych oznacza to masowe obciążenia) a najwyraźniej na komercyjnym rynku C++ jest właściwym narzędziem, żeby sprostać komercyjnym wymaganiom. "Zacementowanie" jest celem, któro nie dość, że niczego nie oznacza, to jeszcze trudno taki cel uzasadnić koniecznymi kosztami. Natomiast poniesienie kosztów, żeby dostarczyć użytkownikom niezawodny produkt, jest jak najbardziej racjonalne. I to również jest powód, żeby się tym językiem zainteresować.

Sądzę, że raczej bierze się to stąd, że łatwiej znaleźć developerów C++ niż Common Lispa (w pierwszym przypadku) i łatwiej uzyskać dobrą wydajność w C++ niż w Javie (w drugim przypadku).
W każdym razie clou jest takie, że rozwijanie projektu jest czymś innym, niż utrzymanie produktu.

> Oczywiście można też wysunąć argumentację, że "oni" (korporacje?) robią źle, bo są źli, więc skoro robią coś w C++, to na pewno C++ też jest zły.

Zupełnie nie rozumiem tego co napisałeś (ani po co).

[toc] | [prev] | [next] | [standalone]

#33583

From	Maciej Sobczak <see.my.homepage@gmail.com>
Date	2019-12-14 11:02 -0800
Message-ID	<322a38fa-dba9-48b8-8bc5-52c2e2ff62c4@googlegroups.com>
In reply to	#33573

> > W sensie - jaka jest wartość dodana tego języka Ć?
> 
> Sam chwilę temu pisałeś o problemach z wołaniem Javy z C# albo na odwrót.

Sam chwilę temu pisałem, że moduł napisany w C++ mogę załadować do Javy i .NETa.
Więc jeśli celem jest napisanie takiego modułu, to wiem, jak to zrobić bez konieczności sięgania po nowe (niedopracowane?) narzędzia.

Więc pytam, jaka jest wartość dodana, skoro bez tego narzedzia nie mam problemu z osiąganiem swoich celów.

> > To używaj wybranego podzbioru. Wtedy taki (pod)język będzie mniej złożony.
> 
> Tylko skąd będę wiedział, który podzbiór jest tym właściwym?

Zapytasz na grupie dyskusyjnej? Podpatrzysz implementację innego produktu z tej samej lub zbliżonej dziedziny?
A może przy takich poszukiwaniach niechcący nauczysz się całego języka i wtedy sam będziesz mógł taki podzbiór wybrać?

> Jaki konkretnie sukces osiągnął Python przed zainteresowaniem się nim przez Google?

A co w ogóle jest miarą sukcesu języka programowania? Bo skoro twierdzisz, że Python osiągnął ten sukces po inwestycji ze strony Googla, to chyba masz jakiś pogląd na to, czym ten sukces jest?

> Nie. Oznacza instytucje, które dysponują zasobami. Jeżeli pytasz o jakie korporacje chodzi, to przede wszystkim Microsoft z Visual C++, oraz Intel, któty raz że ma produkt w postaci ICC, a dwa że kontrybuuje do GCC, bo mu to zwiększa sprzedaż procesorów.

I to są świetne powody, żeby zainteresować się tym językiem planując własny produkt.

> Sukces C++ wyniknął stąd, że znalazły się podmioty, które zrobiły dla niego dobre narzędzia.

Super! Dobre narzędzia to kolejny powód, żeby się tym językiem zainteresować.
Po co tracić czas na języki, do których nie ma dobrych narzedzi?

> > Dlatego też zachodzi podejrzenie, że do zadania z tego wątku też będzie to dobry wybór.
> 
> Może będzie. Trzymam kciuki.

Wszyscy trzymamy.

> Sądzę, że raczej bierze się to stąd, że łatwiej znaleźć developerów C++ niż Common Lispa (w pierwszym przypadku) i łatwiej uzyskać dobrą wydajność w C++ niż w Javie (w drugim przypadku).

To są same świetne powody, żeby wybrać C++ do kolejnego projektu.

> W każdym razie clou jest takie, że rozwijanie projektu jest czymś innym, niż utrzymanie produktu.

Nie dostrzegam tego clou. Nie widzę sensu rozwijania produktu w jakimś języku, który nie będzie się nadawał do dalszego utrzymania tego produktu - chociażby dlatego, że skazałbym się na koszt przepisywania tego produktu. Praktyka pokazuje, że rozwiązania tymczasowe mają zdumiewającą zdolność przetrwania, więc najlepiej ich z góry uniknąć i od razu zrobić dobrze (o ile w ogóle mamy długofalową wizję co to ma oznaczać - ale jeżeli plan jest komercyjny, to jakaś wizja najwyraźniej jest).

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33585

From	godek.maciek@gmail.com
Date	2019-12-15 02:54 -0800
Message-ID	<57af27de-5b38-4db3-888e-4a3e196a22e1@googlegroups.com>
In reply to	#33583

W dniu sobota, 14 grudnia 2019 20:02:41 UTC+1 użytkownik Maciej Sobczak napisał:
> > > W sensie - jaka jest wartość dodana tego języka Ć?
> > 
> > Sam chwilę temu pisałeś o problemach z wołaniem Javy z C# albo na odwrót.
> 
> Sam chwilę temu pisałem, że moduł napisany w C++ mogę załadować do Javy i .NETa.
> Więc jeśli celem jest napisanie takiego modułu, to wiem, jak to zrobić bez konieczności sięgania po nowe (niedopracowane?) narzędzia.
> Więc pytam, jaka jest wartość dodana, skoro bez tego narzedzia nie mam problemu z osiąganiem swoich celów.

Jeżeli idzie o Javę, to obawiam się, że korzystając z Twojej metody będziesz się musiał sam martwić o to, żeby przeportować i utrzymywać swój moduł na każdą interesującą Cię platformę. Czyli najważniejszą cechę Javy - przenośność pomiędzy platformami - wyrzucasz do kosza.
Dodatkowo wołanie kodu natywnego jest na JVM kosztowne, i stosując je, tracisz JVMowe optymalizacje.
Więc chociażby taka.

> > > To używaj wybranego podzbioru. Wtedy taki (pod)język będzie mniej złożony.
> > 
> > Tylko skąd będę wiedział, który podzbiór jest tym właściwym?
> 
> Zapytasz na grupie dyskusyjnej? Podpatrzysz implementację innego produktu z tej samej lub zbliżonej dziedziny?
> A może przy takich poszukiwaniach niechcący nauczysz się całego języka i wtedy sam będziesz mógł taki podzbiór wybrać?

Się uśmiałem.
C++ jest językiem, którego nie ogarniają sami jego twórcy, więc nie sądzę, żeby osobie łażącej po grupach dyskusyjnych było dane nauczyć się "całego" języka.

> > Jaki konkretnie sukces osiągnął Python przed zainteresowaniem się nim przez Google?
> 
> A co w ogóle jest miarą sukcesu języka programowania? Bo skoro twierdzisz, że Python osiągnął ten sukces po inwestycji ze strony Googla, to chyba masz jakiś pogląd na to, czym ten sukces jest?

Tak. W przypadku języków programowania sukcesem jest popularność.
I jeżeli spojrzysz na rankingi popularności, to z łatwością dostrzeżesz, że Python zaczął się na nim pojawiać w okolicach 2000-2001 roku.
Czyli mniej więcej w czasie kiedy kierownik działu badań w Googlu napisał ten tekst: https://norvig.com/python-lisp.html

> > Sukces C++ wyniknął stąd, że znalazły się podmioty, które zrobiły dla niego dobre narzędzia.
> 
> Super! Dobre narzędzia to kolejny powód, żeby się tym językiem zainteresować.
> Po co tracić czas na języki, do których nie ma dobrych narzedzi?

Zdecydowanie nie warto.
Ale C++ nie jest jedynym językiem, dla którego istnieją dobre narzędzia.

> > W każdym razie clou jest takie, że rozwijanie projektu jest czymś innym, niż utrzymanie produktu.
> 
> Nie dostrzegam tego clou. Nie widzę sensu rozwijania produktu w jakimś języku, który nie będzie się nadawał do dalszego utrzymania tego produktu - chociażby dlatego, że skazałbym się na koszt przepisywania tego produktu. 

Paul Graham swego czasu pisał dużo na temat wyboru Common Lispu do swojego start-upu. Jego zdaniem to właśnie użycie tego języka dawało im przewagę nad konkurencją, bo mogli bardzo szybko dodawać do swojego produktu nowe ficzery, tym samym prześcigając konkurencję. Innymi słowy, zdaniem Grahama, jeśli by wybrali inny język, to produkt albo nigdy by nie powstał, albo by przegrał. 
I podejrzewam, że Graham ma w tym przypadku rację - bo koniec końców to jego produkt. I nawet jeżeli ocena języka programowania jest subiektywna, to jeżeli ktoś na przykład czerpie frustrację z używania jakiegoś języka, to raczej trudno się spodziewać, żeby zaszedł w nim dalej od kogoś, kto używa swojego języka z przyjemnością. (I z dotychczasowych wypowiedzi wynika, że Osobliwy Nick nie był szczególnie zadowolony z C++, więc pewnie w jego przypadku warto rozejrzeć się za jakimiś alternatywami)

Natomiast w tej historii to nie Graham i nie Persson poniósł koszty przepisywania, tylko - odpowiednio - Yahoo i Microsoft. Z tego co wiem, autorzy kodu byli raczej zadowoleni z transakcji, a przepisanie go na C++ było czymś, co miało sens z perspektywy nabywców (a dlaczego tak było? Bo może mieli u siebie zatrudnionych wielu doświadczonych programistów C++, w związku z czym przepisanie kodu na ten język miało dla nich sens) 

Dlatego jeśli miałbym wybierać pomiędzy tym, czy projekt ma być zrealizowany, a tym, czy do realizacji projektu mam użyć C++, i nigdy go nie ukończyć, to raczej bym się nie zastanawiał.

> Praktyka pokazuje, że rozwiązania tymczasowe mają zdumiewającą zdolność przetrwania, więc najlepiej ich z góry uniknąć i od razu zrobić dobrze (o ile w ogóle mamy długofalową wizję co to ma oznaczać - ale jeżeli plan jest komercyjny, to jakaś wizja najwyraźniej jest).

Jasne, że lepiej robić dobrze, niż źle, ale problem jest taki, że o tym, co w danym przypadku znaczy "dobrze", a co "źle", dowiadujemy się dopiero po fakcie.

[toc] | [prev] | [next] | [standalone]

#33594

From	Maciej Sobczak <see.my.homepage@gmail.com>
Date	2019-12-15 14:38 -0800
Message-ID	<0a1a7d8c-f88b-4d78-9594-1aae2b941c0e@googlegroups.com>
In reply to	#33585

> Jeżeli idzie o Javę, to obawiam się, że korzystając z Twojej metody będziesz się musiał sam martwić o to, żeby przeportować i utrzymywać swój moduł na każdą interesującą Cię platformę.

Akurat C++ jest dużo bardziej przenośny, niż Java, więc nie martwi mnie to zbytnio.

> Czyli najważniejszą cechę Javy - przenośność pomiędzy platformami - wyrzucasz do kosza.

Mój moduł będzie przenośny nawet na te platformy, na których JVM w ogóle nie da się zrobić. Problem więc jest dokładnie odwrotny - decydując się na pisanie takiego modułu pod kątem Javy, ograniczyłbym sobie ilość docelowych platform. To brzmi głupio, ale faktycznie, wielu ludzi właśnie tak się z własnej woli ogranicza.

> Dodatkowo wołanie kodu natywnego jest na JVM kosztowne,
> i stosując je, tracisz JVMowe optymalizacje.

Akurat doświadczenie z wydajnością czegokolwiek podpowiada mi, że mój moduł będzie wtedy i tak najszybszą częścią takiego składaka. Więc znowu nie martwiłbym się tym zagadnieniem.

> C++ jest językiem, którego nie ogarniają sami jego twórcy,

Nie szkodzi. Ważne, że ogarnęli go twórcy wszystkich tych projektów, które w C++ odniosłu sukces - a które nawet sam tutaj przytoczyłeś.

> Tak. W przypadku języków programowania sukcesem jest popularność.
> I jeżeli spojrzysz na rankingi popularności, to z łatwością dostrzeżesz, że Python zaczął się na nim pojawiać w okolicach 2000-2001 roku.
> Czyli mniej więcej w czasie kiedy kierownik działu badań w Googlu napisał ten tekst: https://norvig.com/python-lisp.html

Nie wiązałbym tej popularności z tym konkretnie artykułem. Przypuszczam nawet, że jeśli ktoś nie interesował się LISPem, to na ten artykuł w ogóle nie trafił.

Guido został zatrudniony w Google'u w 2005. Python był już wtedy bardzo dobrze rozpoznawalny, w top 10 (https://www.youtube.com/watch?v=Og847HVwRSI). I raczej nie był to efekt jakiegoś artykułu napisanego dla fanów LISPa.

> Ale C++ nie jest jedynym językiem, dla którego istnieją dobre narzędzia.

Tak. Ale nie zaproponowałeś żadnego innego, który by ten warunek spełniał.

> Paul Graham swego czasu pisał dużo na temat wyboru Common Lispu do swojego start-upu. Jego zdaniem to właśnie użycie tego języka dawało im przewagę nad konkurencją, bo mogli bardzo szybko dodawać do swojego produktu nowe ficzery, tym samym prześcigając konkurencję.

Dokładnie tak samo tłumaczą swoje wybory wszyscy inni, którzy osiągnęli jakiś sukces.
Co płynnie przenosi nas do wniosku, że wybór języka może być drugorzędny:

> I podejrzewam, że Graham ma w tym przypadku rację - bo koniec końców to jego produkt. I nawet jeżeli ocena języka programowania jest subiektywna, to jeżeli ktoś na przykład czerpie frustrację z używania jakiegoś języka, to raczej trudno się spodziewać, żeby zaszedł w nim dalej od kogoś, kto używa swojego języka z przyjemnością.

To prawda. Ale ponieważ powstało wiele produktów, które osiągnęły sukces, to może być też tak, że istotnym składnikiem sukcesu nie jest wybór języka, tylko entuzjazm do jego używania.

> (I z dotychczasowych wypowiedzi wynika, że Osobliwy Nick nie był szczególnie zadowolony z C++, więc pewnie w jego przypadku warto rozejrzeć się za jakimiś alternatywami)

Z dotychczasowych wypowiedzi wynika, że w ogóle nie był zadowolony ze swoich osiągnięc programistycznych, więc na dzień dzisiejszy chyba każdy język startuje z równej pozycji. Ale jeżeli składnik subiektywny ma odegrać istotną rolę, to tego oczywiście nie rozstrzygniemy. Osobliwy sam musi to zrobić.

> Natomiast w tej historii to nie Graham i nie Persson poniósł koszty przepisywania, tylko - odpowiednio - Yahoo i Microsoft. Z tego co wiem, autorzy kodu byli raczej zadowoleni z transakcji, a przepisanie go na C++ było czymś, co miało sens z perspektywy nabywców (a dlaczego tak było? Bo może mieli u siebie zatrudnionych wielu doświadczonych programistów C++, w związku z czym przepisanie kodu na ten język miało dla nich sens) 

Mogło tak być. Czyli kierował nimi entuzjazm.
Ale skoro ostatecznie osiągnęli sukces, to najwyraźniej nie była to zła decyzja.

> Dlatego jeśli miałbym wybierać pomiędzy tym, czy projekt ma być zrealizowany, a tym, czy do realizacji projektu mam użyć C++, i nigdy go nie ukończyć, to raczej bym się nie zastanawiał.

Ale nie ma przesłanek do twierdzenia, że w C++ byś go nie ukończył. To raczej pachnie uprzedzeniami.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#33595

From	godek.maciek@gmail.com
Date	2019-12-15 15:05 -0800
Message-ID	<620e7e19-4c6c-4352-808b-b5b8a5917f2c@googlegroups.com>
In reply to	#33594

W dniu niedziela, 15 grudnia 2019 23:38:50 UTC+1 użytkownik Maciej Sobczak napisał:
> > Jeżeli idzie o Javę, to obawiam się, że korzystając z Twojej metody będziesz się musiał sam martwić o to, żeby przeportować i utrzymywać swój moduł na każdą interesującą Cię platformę.
> 
> Akurat C++ jest dużo bardziej przenośny, niż Java, więc nie martwi mnie to zbytnio.

Jeżeli Twoim targetem (np. biznesowym) jest Java, to powinno.
Język Ć jest zaś jeszcze bardziej przenośny, niż C++.

> > Tak. W przypadku języków programowania sukcesem jest popularność.
> > I jeżeli spojrzysz na rankingi popularności, to z łatwością dostrzeżesz, że Python zaczął się na nim pojawiać w okolicach 2000-2001 roku.
> > Czyli mniej więcej w czasie kiedy kierownik działu badań w Googlu napisał ten tekst: https://norvig.com/python-lisp.html
> 
> Nie wiązałbym tej popularności z tym konkretnie artykułem. Przypuszczam nawet, że jeśli ktoś nie interesował się LISPem, to na ten artykuł w ogóle nie trafił.

W takim razie z czym byś tę popularność wiązał?

> Guido został zatrudniony w Google'u w 2005. Python był już wtedy bardzo dobrze rozpoznawalny, w top 10 (https://www.youtube.com/watch?v=Og847HVwRSI). I raczej nie był to efekt jakiegoś artykułu napisanego dla fanów LISPa.

Sądzę, że wątpię. Python pojawił się na wykresie w roku 2001, tak więc niedługo po tym, jak Norvig zaczął go promować. I nie chodzi oczywiście o jeden artykuł. Chodzi o zastąpienie Common Lispa Pythonem w dydaktyce sztucznej inteligencji.

> > Ale C++ nie jest jedynym językiem, dla którego istnieją dobre narzędzia.
> 
> Tak. Ale nie zaproponowałeś żadnego innego, który by ten warunek spełniał.

Tak konkretnie to zaproponowałem dwa: Racketa i Haskella.
Racket jest moim faworytem jeżeli idzie o łatwość użycia i przenośność: można go łatwo zainstalować wraz z prostym w obsłudze IDE na najważniejszych platformach (tj. Windows, OS X i Linux) albo używać w przeglądarce bez instalacji (https://www.wescheme.org).

Haskella trudniej zainstalować na Windowsie (choć też bez przesady), i nie ma "w pudełku" prostych w użyciu narzędzi, ale kompilator GHC zazwyczaj produkuje dobrze zoptymalizowany kod.

> > I podejrzewam, że Graham ma w tym przypadku rację - bo koniec końców to jego produkt. I nawet jeżeli ocena języka programowania jest subiektywna, to jeżeli ktoś na przykład czerpie frustrację z używania jakiegoś języka, to raczej trudno się spodziewać, żeby zaszedł w nim dalej od kogoś, kto używa swojego języka z przyjemnością.
> 
> To prawda. Ale ponieważ powstało wiele produktów, które osiągnęły sukces, to może być też tak, że istotnym składnikiem sukcesu nie jest wybór języka, tylko entuzjazm do jego używania.

Może tak być. Dlatego stoję na stanowisku, że w miarę możliwości warto używać takich języków, które wzbudzają entuzjazm, a unikać takich, które powodują frustrację. (Co jest oczywiście cechą indywidualną)

[toc] | [prev] | [next] | [standalone]

#33598

From	Maciej Sobczak <see.my.homepage@gmail.com>
Date	2019-12-16 11:02 -0800
Message-ID	<650eb48f-7b9b-480f-a4c3-198431ca8a7f@googlegroups.com>
In reply to	#33595

> > Akurat C++ jest dużo bardziej przenośny, niż Java, więc nie martwi mnie to zbytnio.
> 
> Jeżeli Twoim targetem (np. biznesowym) jest Java, to powinno.

Nie, bo Java będzie tylko podzbiorem targetów mojego modułu.

> Język Ć jest zaś jeszcze bardziej przenośny, niż C++.

Nie. Bo jeżeli zaczynasz traktować język jako źródło do translacji, to C++ też tak można wykorzystać (nota bene, pierwszy "kompilator" C++ to był translator do innego języka). Rozsądny podzbiór C++ da się translować na dowolny inny język imperatywny, zapewne również na język Ć.

Oznacza to, że zarówno C++ jak i Ć można translować na coś innego, ale C++ można jeszcze kompilować na dowolną platformę bezpośrednio (i można robić to tak dobrze, że nie ma już motywacji do translowania C++ na inny język). Z tego wynika, że zakres zastosowań C++ jest większy, niż Ć.

Czyli nie ma takiej rzeczy, którą można zrobić z Ć a której nie można zrobić z C++.
Dlatego pytam o wartość dodaną. Nadal jej nie widzę.

[Python]
> W takim razie z czym byś tę popularność wiązał?

Potrzebny był nowy Perl. Python wypełnił tą niszę proponując świeższą składnię, w szczególności bardziej atrakcyjną dla początkujących.

> Sądzę, że wątpię. Python pojawił się na wykresie w roku 2001, tak więc niedługo po tym, jak Norvig zaczął go promować.

Jeżeli objawem tej promocji był wspomniany przez Ciebie artykuł napisany dla dotychczasowych fanów LISPa, to ta promocja nie miała wpływu dokładnie na nic.

> I nie chodzi oczywiście o jeden artykuł. Chodzi o zastąpienie Common Lispa Pythonem w dydaktyce sztucznej inteligencji.

O, teraz ciekawiej. Ale sztuczna inteligencja stała się buzzwordem jeszcze później. Python rozpowszechnił się zupełnie bez wsparcia ze strony AI. Dzisiaj to (wzajemne) wsparcie jest bardzo widoczne, ale np. ja uczyłem się Pythona zanim ktokolwiek z mojego otoczenia zaczął w ogóle mówić o AI.

Więc ponownie, nie wiązałbym ze sobą tych nurtów.

Z Quory (bo akurat tam mi wyskoczyło):

https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow

Na tej stronie słowa LISP i AI nie występują ani razu, więc chyba nikt z dyskutantów nie dostrzega związków Pythona z tymi dwoma.
Jest natomiast wzmianka o zastosowaniach, które wcześniej były domeną właśnie Perla.

[o dostępności dobrych narzędzi]
> Tak konkretnie to zaproponowałem dwa: Racketa i Haskella.

To jaki dobry generator kodu z UMLa polecasz, albo generatory serializatorów dla różnych standardów komunikacyjnych, albo porządny debugger (również zdalny), albo chociaż coś do automatycznej generacji dokumentacji z kodu (z diagramami)? Albo jakieś niezależne analizatory statyczne?

> Racket jest moim faworytem jeżeli idzie o łatwość użycia i przenośność:

Niech zgadnę - przenośność jeszcze mniejsza, niż w Javie?

> można go łatwo zainstalować wraz z prostym w obsłudze IDE na najważniejszych platformach (tj. Windows, OS X i Linux)

iOS, Android? Jakiś RTOS? Bare-metal?

A jakbym chciał dla odmiany jakieś *trudne* w obsłudze IDE, to da radę?
Bo czasem mogę chcieć.

> albo używać w przeglądarce bez instalacji (https://www.wescheme.org).

Czad. Ale czas, kiedy on-line'owy kompilator (albo interpreter) C++ robił wrażenie, już dawno minął.

> Haskella trudniej zainstalować na Windowsie

Wiem, próbowałem. Za to C++ mam w tylu różnych stanach skupienia, że sam nie pamiętam.

[składnik subiektywny]
> Może tak być. Dlatego stoję na stanowisku, że w miarę możliwości warto używać takich języków, które wzbudzają entuzjazm, a unikać takich, które powodują frustrację. (Co jest oczywiście cechą indywidualną)

Tak.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

Page 1 of 3 [1] 2 3 Next page →

csiph-web

Ile czasu zajmie komputerowi rozszerzony algorytm euklidesa?

Contents

#33542 — Ile czasu zajmie komputerowi rozszerzony algorytm euklidesa?

#33544

#33545

#33548

#33557

#33563

#33551

#33558

#33559

#33560

#33561

#33566

#33567

#33572

#33573

#33583

#33585

#33594

#33595

#33598