Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

"Najbardziej imponujący kod, jaki widziałem"

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

Contents

  "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-07-30 06:58 -0700
    Re: "Najbardziej imponujący kod, jaki widziałem" dantes <dantes@qmail.com> - 2019-07-31 11:34 +0200
      Re: "Najbardziej imponujący kod, jaki widziałem" Roman Tyczka <noemail@because.no> - 2019-07-31 12:32 +0200
        Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-07-31 13:54 +0200
        Re: "Najbardziej imponujący kod, jaki widziałem" Bischoop <Bischoop@vimart.net> - 2021-09-23 23:11 +0000
    Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-07-31 05:59 -0700
      Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-07-31 16:18 +0200
        Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-07-31 16:36 +0200
        Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-01 04:47 -0700
      Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-07-31 10:03 -0700
        Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-01 05:26 -0700
          Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-01 07:29 -0700
            Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-02 01:32 -0700
              Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-02 05:10 -0700
                Re: "Najbardziej imponujący kod, jaki widziałem" AK <nobody@nowhere.net> - 2019-08-03 06:52 +0200
                  Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-03 00:55 -0700
                    Re: "Najbardziej imponujący kod, jaki widziałem" AK <nobody@nowhere.net> - 2019-08-08 00:44 +0200
                      Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-08 00:06 -0700
                        Re: "Najbardziej imponujący kod, jaki widziałem" AK <nobody@nowhere.net> - 2019-08-08 17:44 +0200
                          Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-08 13:04 -0700
                Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-03 12:51 -0700
                  Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-03 15:37 -0700
                    Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-04 13:57 -0700
                      Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-05 03:44 -0700
                        Re: "Najbardziej imponujący kod, jaki widziałem" Roman Tyczka <noemail@because.no> - 2019-08-05 14:35 +0200
                          Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-05 05:58 -0700
                        Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-05 13:29 -0700
                          Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-06 01:55 -0700
                            Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-06 13:57 -0700
                              Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-07 00:39 -0700
                                Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-07 01:09 -0700
                                  Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-07 02:10 -0700
                                    Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-07 05:02 -0700
                                      Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-07 07:43 -0700
                                        Re: "Najbardziej imponujący kod, jaki widziałem" Maciej Sobczak <see.my.homepage@gmail.com> - 2019-08-07 13:32 -0700
    Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-08-06 15:31 +0200
      Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-06 06:45 -0700
        Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-08-06 16:32 +0200
          Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-06 07:39 -0700
            Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-08-06 16:57 +0200
              Re: "Najbardziej imponujący kod, jaki widziałem" godek.maciek@gmail.com - 2019-08-06 08:20 -0700
            Re: "Najbardziej imponujący kod, jaki widziałem" Borneq <borneq@antyspam.hidden.p> - 2019-08-06 17:01 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#32787

> Czasem w radiu słyszę reklamy, że producent leku przeprowadził niezależne badania,

Ale ten producent wziął dane z niezależnego serwisu (Rosetta Code). Ty też możesz te dane stamtąd wziąć.

> Trochę też rozczarowuje brak APLa w ich rankingu

http://rosettacode.org/wiki/Category:Programming_Languages

Ja myślę, że tabelka by nie była czytelna, gdyby wszystkie języki tam uwzględnić.

> pewnie wyszłoby jeszcze krócej, niż Mathematica, i by się musieli tłumaczyć.

Gorzej. W tej dyskusji to LISP wyglądałby jeszcze biedniej.

> W każdym razie "krócej" nie zawsze znaczy "lepiej".

To prawda.

> > A dlaczego akurat do meta-programowania jest najlepsza?
> 
> Chyba dlatego, że ma najmniejszą możliwą liczbę reguł, dzięki czemu składnia jest jednocześnie formatem serializacji (i to lżejszym od np. JSONa)

Dokładnie to samo można napisać o Wolframie (to jest ta "LISPowatość"). Przykładowo, cały notebook, cokolwiek by nie miał, zapisany na dysku jest jednym legalnym wyrażeniem.

[Nothing]
> Na pewno do zrozumienia wymagała
> - znajomości funkcji "map"

Bo akurat chciałem, żeby przykład był w stylu funkcjonalnym. Nie musiał być i nie musiało tam być funkcji map.

> - wiedzy o osobliwym zachowaniu wartości "Nothing"

Bo właśnie to chciałem zaprezentować. Da się też bez tej wiedzy, czyli gorzej. Da się nawet tak samo źle, jak w Twoim przykładzie. Wolfram to bardzo uniwersalny język, może nawet udawać gorsze języki. :-)

> Łatwo jest zdefiniować "only" przy pomocy "append-map" (czy flatMap, czy concatMap, jak zwał tak zwał)
> 
> (define (only satisfying? elements)
>   (append-map (lambda (element)
>                  (if (satisfying? element)
>                      `(,element)
>                     '()))
>               elements))
> 
> Wygląda prawie tak samo, jak Twoja, tylko nie trzeba wymyślać "specjalnych elementów" o "magicznych właściwościach" i "niejasnym statusie ontycznym".

No jak nie. Ja tam widzę pustą listę gdy warunek nie jest spełniony. Skąd mam wiedzieć, że pusta lista jest ignorowana przez append-map? Przecież mogła być też dodana do wyniku.
A gdybym jednak chciał dodać pustą listę do wyniku?

W Wolframie pusta lista i Nothing to dwie różne sprawy.
Przykładowo:

only[condition_, list_] := Map[
  Function[x,
   If[condition[x], x, {}] (* tutaj jest {} zamiast Nothing *)
   ],
  list
  ]

only[EvenQ, {1, 2, 3, 4, 5, 6, 7}]

{{}, 2, {}, 4, {}, 6, {}}

Jest różnica, prawda? Jak tą różnicę uzyskać w Twoim przykładzie?

> Najwidoczniej dla mnie prostota jest ważniejsza od wygody (którą Ty tutaj nazywasz "użytecznością"), a dla Ciebie na odwrót.

Zgodziłbym się, gdyby Twoje przykłady były proste. Ale nie są.

[...]
> Zaprawieni programiści Lispa nazywają ten proces "rytuałem przejścia".

Rozumiem. Wspominałeś już to określenie, ale wcześniej nie zrozumiałem. Czyli "rytuał przejścia" to sytuacja, kiedy ktoś bez sukcesu próbuje usprawnić język i ostatecznie rezygnuje z tego, wracając do języka bez usprawnień.

A jest jakaś fajna nazwa na sytuację, kiedy ktoś bez sukcesu próbuje usprawnić język i ostatecznie rezygnuje z tego i zmienia język na lepszy?
Nie wiem - rytuał wyjścia? odejścia? rozejścia?
Musi być jakaś fajna nazwa.

> Być może sytuacja z Mathematiką ma się nieco inaczej, bo ona ma już wokół siebie stosunkowo dużą społeczność.

To pewnie ludzie po rytuale wyjścia z LISPa. :-D

W porównaniu do poprzednich postów, w których próbowałeś wykazać, że nikt z tego nie korzysta, zauważam pozytywną zmianę.

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

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

#32789

W dniu sobota, 3 sierpnia 2019 21:51:13 UTC+2 użytkownik Maciej Sobczak napisał:
> > Czasem w radiu słyszę reklamy, że producent leku przeprowadził niezależne badania,
> 
> Ale ten producent wziął dane z niezależnego serwisu (Rosetta Code). Ty też możesz te dane stamtąd wziąć.

Nawet zerknąłem z ciekawości.
Tak konkretniej to zerknąłem tutaj:
https://rosettacode.org/wiki/Levenshtein_distance

Rozwiązanie w Mathematice wyglądało tak:

EditDistance["kitten","sitting"]
->3
EditDistance["rosettacode","raisethysword"]
->8

Dla porównania rozwiązanie w Haskellu:

levenshtein :: Eq a => [a] -> [a] -> Int
levenshtein s1 s2 = last $ foldl transform [0 .. length s1] s2
  where
    transform ns@(n:ns1) c = scanl calc (n + 1) $ zip3 s1 ns ns1
      where
        calc z (c1, x, y) = minimum [y + 1, z + 1, x + fromEnum (c1 /= c)]
 
main :: IO ()
main = print (levenshtein "kitten" "sitting")


Czyli autorzy "rozwiązania" w Mathematice nie dostarczyli implementacji odległości Levenshteina, tylko skorzystali z wbudowanej. Wygląda zatem na to, że nawet nie zrozumieli reguł zabawy.
Przy takiej interpretacji rzeczywiście trudno się dziwić, że w Mathematice wychodzą najkrótsze implementacje.

> > - wiedzy o osobliwym zachowaniu wartości "Nothing"
> 
> Bo właśnie to chciałem zaprezentować. Da się też bez tej wiedzy, czyli gorzej. Da się nawet tak samo źle, jak w Twoim przykładzie. Wolfram to bardzo uniwersalny język, może nawet udawać gorsze języki. :-)
> 
> > Łatwo jest zdefiniować "only" przy pomocy "append-map" (czy flatMap, czy concatMap, jak zwał tak zwał)
> > 
> > (define (only satisfying? elements)
> >   (append-map (lambda (element)
> >                  (if (satisfying? element)
> >                      `(,element)
> >                     '()))
> >               elements))
> > 
> > Wygląda prawie tak samo, jak Twoja, tylko nie trzeba wymyślać "specjalnych elementów" o "magicznych właściwościach" i "niejasnym statusie ontycznym".
> 
> No jak nie. Ja tam widzę pustą listę gdy warunek nie jest spełniony. Skąd mam wiedzieć, że pusta lista jest ignorowana przez append-map? Przecież mogła być też dodana do wyniku.
> A gdybym jednak chciał dodać pustą listę do wyniku?

To zamiast '() napisałbyś '(())

> > Najwidoczniej dla mnie prostota jest ważniejsza od wygody (którą Ty tutaj nazywasz "użytecznością"), a dla Ciebie na odwrót.
> 
> Zgodziłbym się, gdyby Twoje przykłady były proste. Ale nie są.

Nie do końca wiem, które przykłady masz na myśli.

> [...]
> > Zaprawieni programiści Lispa nazywają ten proces "rytuałem przejścia".
> 
> Rozumiem. Wspominałeś już to określenie, ale wcześniej nie zrozumiałem. Czyli "rytuał przejścia" to sytuacja, kiedy ktoś bez sukcesu próbuje usprawnić język i ostatecznie rezygnuje z tego, wracając do języka bez usprawnień.

Raczej: próbuje usprawnić język, ale w międzyczasie odnajduje perspektywę, w której okazuje się, że pozorne usprawnienia wcale nic nie usprawniają. Że zmiana kształtu koła nie sprawia, że koło staje się lepszym kołem. Że tym, co było przeszkodą, nie były niedoróbki języka, tylko nawyki programisty.

> A jest jakaś fajna nazwa na sytuację, kiedy ktoś bez sukcesu próbuje usprawnić język i ostatecznie rezygnuje z tego i zmienia język na lepszy?

Zauważyłem, że często (w naszych różnych rozmowach, nie tylko teraz) posługujesz się takimi określeniami, jak "lepszy" czy "gorszy", tak jakby one same w sobie coś znaczyły.
Być może ma sens mówienie o tym, że coś jest lepsze dla jakiegoś danego celu niż coś innego, albo że jest lepsze względem jakiegoś kryterium czy jakiejś miary, ale nie wydaje mi się, żeby można było w ogóle powiedzieć, że dany język jest w jakimś absolutnym sensie lepszy od jakiegoś innego języka.

> Nie wiem - rytuał wyjścia? odejścia? rozejścia?
> Musi być jakaś fajna nazwa.

Może "sytuacja utknięcia"?
Albo "nieprzejście rytuału przejścia"?

> > Być może sytuacja z Mathematiką ma się nieco inaczej, bo ona ma już wokół siebie stosunkowo dużą społeczność.
> 
> To pewnie ludzie po rytuale wyjścia z LISPa. :-D

Nie wiem jacy to ludzie. Pytanie jest rzeczywiście ciekawe, ale mi brak narzędzi, żeby to ocenić. (Nie ukrywam jednak, że zdziwiłbym się, gdyby się okazało, że jakiś znaczący odsetek użytkowników Mathematiki miał wcześniej głębszy kontakt z Lispem)

> W porównaniu do poprzednich postów, w których próbowałeś wykazać, że nikt z tego nie korzysta, zauważam pozytywną zmianę.

Kiedy ja niby próbowałem coś takiego wykazać?

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

#32791

> Nawet zerknąłem z ciekawości.
> Tak konkretniej to zerknąłem tutaj:
> https://rosettacode.org/wiki/Levenshtein_distance
[...]
> Czyli autorzy "rozwiązania" w Mathematice nie dostarczyli implementacji odległości Levenshteina, tylko skorzystali z wbudowanej. Wygląda zatem na to, że nawet nie zrozumieli reguł zabawy.

Niekoniecznie. Bo jeśli reguły zabawy były takie, żeby nie używać istniejących ficzerów, tylko biczować się na jak najniższym poziomie, to akurat pokazana przez Ciebie wersja w Haskellu też tego nie spełnia. foldl, scanl, zip3, minimum, print, itd. - naprawdę, autorzy nie zrozumieli reguł, powinni to wszystko napisać od zera.

Zaletą Wolframa jest właśnie te 5000+ funkcji, które od ręki coś robią. A ponieważ Wolfram jest LISPowaty, to nie da się wyraźnie oddzielić funkcji "podstawowych" od "bibliotecznych", bo wszystkie mają takie same prawa i nie ma żadnej niezbędnej.

> Przy takiej interpretacji rzeczywiście trudno się dziwić, że w Mathematice wychodzą najkrótsze implementacje.

Problem w tym, że przy innej interpretacji mogłoby się okazać, że w wielu językach w ogóle nie dałoby się wielu rzeczy napisać, bo większość języków bez swojej biblioteki standardowej nie potrafi zrobić nawet Hello World.
Więc skoro reguły są takie, że bierzemy język *razem* z jego biblioteką standardową, to niestety w Wolframie ten konkretny przykładowy problem rozwiązuje się jednym wywołaniem odpowiedniej funkcji.

To trochę jakbyś chciał wymyślić takie reguły gry w piłkę, żeby Lewandowski nie mógł strzelić gola i żebyś wtedy mógł z nim wygrać. Sorry, ale przy normalnych, uczciwych regułach, Lewandowski wygrywa.

(nie żebym się znał na piłce i kto tam teraz rulez, ale mam nadzieję, że analogia jest zrozumiała)

> > A gdybym jednak chciał dodać pustą listę do wyniku?
> 
> To zamiast '() napisałbyś '(())

Ale czad. Prawie zaczynam pamiętać te wszystkie specjalne szczególiki. Bo sorry, ale nadal tutaj jest specjalne traktowanie listy.

> (Nie ukrywam jednak, że zdziwiłbym się, gdyby się okazało, że jakiś znaczący odsetek użytkowników Mathematiki miał wcześniej głębszy kontakt z Lispem)

Bardzo nieudolnie ukrywasz swoje poczucie wyższości nad resztą świata.

Otóż Wolfram sam twierdzi, że:

https://www.wolfram.com/language/faq/

"LISP and APL were two early influences"

https://blog.stephenwolfram.com/2013/06/there-was-a-time-before-mathematica/

"I had a pretty broad knowledge of other computer languages of the time, both the “ordinary” ALGOL-like procedural ones, and ones like LISP and APL."

I większy wywód tutaj, z wczesnej dokumentacji:

https://reference.wolfram.com/legacy/v1/contents/4.2.7.pdf

Przypuszczam, że takie doświadczenia dotyczą również jakiejś części użytkowników. Ile jest takich przypadków - nie wiem, ale biorąc pod uwagę, że w środowisku uczelnianym LISP jest silnie reprezentowany i wiele narzędzi związanych z matematyką było swego czasu napisanych w LISPie, to spodziewam się, że świadomość LISPa wśród użytkowników Wolframa jest co najmniej zauważalna.

-- 
Maciej Sobczak

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

#32792

W dniu niedziela, 4 sierpnia 2019 22:57:09 UTC+2 użytkownik Maciej Sobczak napisał:
> > Nawet zerknąłem z ciekawości.
> > Tak konkretniej to zerknąłem tutaj:
> > https://rosettacode.org/wiki/Levenshtein_distance
> [...]
> > Czyli autorzy "rozwiązania" w Mathematice nie dostarczyli implementacji odległości Levenshteina, tylko skorzystali z wbudowanej. Wygląda zatem na to, że nawet nie zrozumieli reguł zabawy.
> 
> Niekoniecznie. Bo jeśli reguły zabawy były takie, żeby nie używać istniejących ficzerów, tylko biczować się na jak najniższym poziomie, to akurat pokazana przez Ciebie wersja w Haskellu też tego nie spełnia. foldl, scanl, zip3, minimum, print, itd. - naprawdę, autorzy nie zrozumieli reguł, powinni to wszystko napisać od zera.

O ile mogę się zgodzić, że problem demarkacji nie jest w tym przypadku łatwy, o tyle nie zgodzę się z radykalnym wnioskiem.
Rozwiązanie Haskellowe, chociaż korzysta z funkcji wbudowanych, daje jednak możliwość zozumienia tego, co się dzieje pod spodem. Rozwiązanie w Mathematice takiej możliwości nie daje.
Prosta sprawa - zmodyfikuj rozwiązanie w Mathematice tak, żeby koszt zamiany elementu wynosił 2 a nie 1.

> Zaletą Wolframa jest właśnie te 5000+ funkcji, które od ręki coś robią. A ponieważ Wolfram jest LISPowaty, to nie da się wyraźnie oddzielić funkcji "podstawowych" od "bibliotecznych", bo wszystkie mają takie same prawa i nie ma żadnej niezbędnej.

To też jest interesujące: czy algorytm Levenshteina napisany w Mathematice będzie działał równie szybko jak ten wbudowany?
Czy może ten wbudowany został zaimplementowany w C?

> > Przy takiej interpretacji rzeczywiście trudno się dziwić, że w Mathematice wychodzą najkrótsze implementacje.
> 
> Problem w tym, że przy innej interpretacji mogłoby się okazać, że w wielu językach w ogóle nie dałoby się wielu rzeczy napisać, bo większość języków bez swojej biblioteki standardowej nie potrafi zrobić nawet Hello World.
> Więc skoro reguły są takie, że bierzemy język *razem* z jego biblioteką standardową, to niestety w Wolframie ten konkretny przykładowy problem rozwiązuje się jednym wywołaniem odpowiedniej funkcji.

W każdym razie zagadka "najkrótszego kodu" w Mathematice rozwiązana.
Każdy może wyciągnąć swoje wnioski.

> To trochę jakbyś chciał wymyślić takie reguły gry w piłkę, żeby Lewandowski nie mógł strzelić gola i żebyś wtedy mógł z nim wygrać. Sorry, ale przy normalnych, uczciwych regułach, Lewandowski wygrywa.
> 
> (nie żebym się znał na piłce i kto tam teraz rulez, ale mam nadzieję, że analogia jest zrozumiała)

Bardziej taka analogia, że wystawiamy w wyścigu biegaczy i motocyklistów.
Raczej nikogo nie zdziwi, że motocykliści dojadą szybciej na metę. Ale raczej nie wnioskowałbym stąd, że kondycja motocyklistów jest lepsza.

> > > A gdybym jednak chciał dodać pustą listę do wyniku?
> > 
> > To zamiast '() napisałbyś '(())
> 
> Ale czad. Prawie zaczynam pamiętać te wszystkie specjalne szczególiki. Bo sorry, ale nadal tutaj jest specjalne traktowanie listy.

Tutaj nie ma żadnego specjalnego traktowania listy.
Funkcja "append-map" wymaga, żeby przekazana do niej funkcja zwracała listę. Funkcja tworzy listę wynikową sklejając ze sobą wyniki list cząstkowych, powstałych przez aplikację przekazanej funkcji do każdego elementu przekazanej listy.
Nie ma tu żadnych specjalnych szczególików.

> > (Nie ukrywam jednak, że zdziwiłbym się, gdyby się okazało, że jakiś znaczący odsetek użytkowników Mathematiki miał wcześniej głębszy kontakt z Lispem)
> 
> Bardzo nieudolnie ukrywasz swoje poczucie wyższości nad resztą świata.

Zauważyłem, że niejednokrotnie w naszych dyskusjach zdarza Ci się wyjechać z jakimś dziwnym "ad personam" w moim kierunku. A to że próbuję szpanować, a to że jestem arogancki, a to że mam poczucie wyższości nad resztą świata.

Nie wiem, skąd się to u Ciebie bierze, ani czemu to ma służyć. Jeżeli masz jakieś pytania na temat mojej osobowości, to lepiej zapytaj, zamiast spekulować.

W tym kontekście, jeżeli miałbym mówić o "wyższości czegoś nad czymś", to bym powiedział, że wkład Johna McCarthy'ego w rozwój informatyki był moim zdaniem większy od wkładu Stephena Wolframa (który być może lepiej się potrafił sprzedać). Ale to tyle. Nie ma w tym przekonaniu absolutnie nic na mój temat.

> Otóż Wolfram sam twierdzi, że:

Że Wolfram twierdzi, to mnie nie zaskakuje. Ale mówiłem o "znaczącym odsetku użytkowników", a nie o "odsetku znaczących użytkowników"

> Przypuszczam, że takie doświadczenia dotyczą również jakiejś części użytkowników. Ile jest takich przypadków - nie wiem, ale biorąc pod uwagę, że w środowisku uczelnianym LISP jest silnie reprezentowany i wiele narzędzi związanych z matematyką było swego czasu napisanych w LISPie, to spodziewam się, że świadomość LISPa wśród użytkowników Wolframa jest co najmniej zauważalna.

No właśnie. Ty się spodziewasz jednego, ja się spodziewam drugiego, i pewnie żaden z nas nigdy się na ten temat nie dowie niczego.

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

#32793

On Mon, 5 Aug 2019 03:44:59 -0700 (PDT), godek.maciek@gmail.com wrote:
>>> (Nie ukrywam jednak, że zdziwiłbym się, gdyby się okazało, że jakiś znaczący odsetek użytkowników Mathematiki miał wcześniej głębszy kontakt z Lispem)
>> 
>> Bardzo nieudolnie ukrywasz swoje poczucie wyższości nad resztą świata.
> 
> Zauważyłem, że niejednokrotnie w naszych dyskusjach zdarza Ci się wyjechać z jakimś dziwnym "ad personam" w moim kierunku. A to że próbuję szpanować, a to że jestem arogancki, a to że mam poczucie wyższości nad resztą świata.
> 
> Nie wiem, skąd się to u Ciebie bierze, ani czemu to ma służyć. Jeżeli masz jakieś pytania na temat mojej osobowości, to lepiej zapytaj, zamiast spekulować.

Raz spytałem, o ile pomnę to odpowiedzi nie było. Spytam jeszcze raz, dość
na temat, skąd ksywa "panicz"?

-- 
pozdrawiam
Roman Tyczka

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

#32794

W dniu poniedziałek, 5 sierpnia 2019 14:35:32 UTC+2 użytkownik Roman Tyczka napisał:

> Raz spytałem, o ile pomnę to odpowiedzi nie było. Spytam jeszcze raz, dość
> na temat, skąd ksywa "panicz"?

Kiedyś kolega mnie tak przezwał, i mi zostało.
(Dlaczego tak przezwał, tego nie wyjaśnił)
Kontekst historyczny swego czasu szerzej opisałem tutaj:
https://www.quora.com/What-is-something-you-wish-you-knew-when-you-first-started-functional-programming/answer/Panicz-Godek

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

#32795

> Rozwiązanie Haskellowe, chociaż korzysta z funkcji wbudowanych, daje jednak możliwość zozumienia tego, co się dzieje pod spodem.

Słuszna uwaga. Ale Mathematica ma inne cele. To nie jest narzędzie dla ludzi, którzy chcą wiedzieć, co się dzieje, tylko raczej co się stanie. Omawialiśmy to już w okolicy open-source. Przy użyciu funkcji EditDistance Mathematica daje odpowiedź na pytanie, jaka jest odległość między wektorami w jakiejś tam mierze.

> Prosta sprawa - zmodyfikuj rozwiązanie w Mathematice tak, żeby koszt zamiany elementu wynosił 2 a nie 1.

Pytanie jest fair i odpowiedź (również fair) jest taka: sam sobie policz. Możesz w Wolframie. Zaletą Wolframa jest to, że ma 5000+ gotowych odpowiedzi; nie jest jego wadą to, że nie wszystkie (nieskończoność!) odpowiedzi są gotowe - bo w ostatecznym porównaniu i tak jest lepiej, niż w językach, gdzie wszystko trzeba wyklepać ręcznie.

> To też jest interesujące: czy algorytm Levenshteina napisany w Mathematice będzie działał równie szybko jak ten wbudowany?
> Czy może ten wbudowany został zaimplementowany w C?

Dobre pytanie. Nie wiemy. Co więcej, nawet gdybyśmy się dowiedzieli, to w kolejnej wersji produktu może być inaczej. I nawet nie chodzi o język implementacji, ale również o takie sprawy jak automatyczne wykorzystanie dostępnej równoległości albo specjalnego sprzętu obecnego w systemie. Również w tym sensie Mathematica jest narzędziem wysokopoziomowym.

> W każdym razie zagadka "najkrótszego kodu" w Mathematice rozwiązana.
> Każdy może wyciągnąć swoje wnioski.

Tak. Wniosek jest taki, że statystycznie w Mathematice trzeba napisać najmniej kodu. To jest odpowiedź na zupełnie praktyczne pytanie kogoś, dla kogo komputer jest narzędziem pracy.

> Bardziej taka analogia, że wystawiamy w wyścigu biegaczy i motocyklistów.
> Raczej nikogo nie zdziwi, że motocykliści dojadą szybciej na metę. Ale raczej nie wnioskowałbym stąd, że kondycja motocyklistów jest lepsza.

Ale osoba zamawiająca pizzę ma gdzieś kondycję gościa, który z dumą przynosi wystygniętego kapcia, i to jeszcze jak już wszyscy goście sobie poszli.

> Funkcja "append-map" wymaga, żeby przekazana do niej funkcja zwracała listę.

I w ten sposób zaprzeczasz swoim wcześniejszym pretensjom, że żeby coś tam zrozumieć w Wolframie, to trzeba znać działanie jego funkcji a może nawet trzeba przeczytać dokumentację. Z nazwy "append-map" nie wynika, że oczekuje list. Mapowanie ogólnie, zgodnie z nazwą, mapuje elementy. A tu proszę, xyz-map oczekuje listy.

> Jeżeli masz jakieś pytania na temat mojej osobowości, to lepiej zapytaj

Nie da się. W tym zakresie nikt nie potrafi się sam zdiagnozować, muszę więc polegać na swoich (subiektywnych) odczuciach.

> W tym kontekście, jeżeli miałbym mówić o "wyższości czegoś nad czymś", to bym powiedział, że wkład Johna McCarthy'ego w rozwój informatyki był moim zdaniem większy od wkładu Stephena Wolframa

Ależ nikt nie twierdzi inaczej. Ba, nawet Wolfram nie twierdzi, że ma jakikolwiek wkład w rozwój informatyki, on się raczej eksponował w innych obszarach. Natomiast to, że w celu ułatwienia sobie pracy w tych innych obszarach napisał program, który potem równolegle rozwinał się jako użyteczny produkt, jest niewątpliwie osiągnięciem, zarówno inżynierskim, jak i biznesowym.

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

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

#32796

> > Prosta sprawa - zmodyfikuj rozwiązanie w Mathematice tak, żeby koszt zamiany elementu wynosił 2 a nie 1.
> 
> Pytanie jest fair i odpowiedź (również fair) jest taka: sam sobie policz.

OK, żeby nie było, że jestem nieuprzejmy, i dla własnej zabawy, zrobiłem mały research w tej sprawie.
Jest taka fajna funkcja:

https://reference.wolfram.com/language/ref/SequenceAlignment.html

Ta funkcja rozpisuje różnice między sekwencjami, z czego można wyciągnąć poszczególne operacje (usunięcie, wstawienie, zamiana). Jeżeli dobrze zrozumiałem ćwiczenie, to rozwiązeniem może być takie coś:

myDistance[s1_, s2_] := Total[
  Min[#] + Max[#] & /@
   Cases[SequenceAlignment[s1, s2], a_List :> StringLength /@ a]
  ]

Pozwoliłem sobie użyć skróconych (idiomatycznych) zapisów na podstawowe operacje mapowania i lambdy - skoro w innych językach są śmieszne znaczki, to ja też skorzystam.

Wyrażenie Min+Max załatwia podwójne zliczenie zamian w porównaniu do wstawień/usunięć. Pełne wyrażenie dla dowolnych wag to:

replacementCost*Min[#] + deletionCost*(Max[#] - Min[#])

gdzie # to anonimowa para {del, ins}, gdzie del to ilość znaków do usunięcia a ins to ilość znaków do wstawienia; jeśli obie są niezerowe, to znaczy, że jest zastąpienie, więc np. para {3,5} oznacza, że są 3 znaki do zastąpienia i 2 do usunięcia/wstawienia. Wszystkie takie wartości są sumowane.
Czy to jest prawidłowy sposób liczenia - nie wiem, ale tak to zrozumiałem.

Czyli nadal nie wyszło jakoś dramatycznie dużo tego kodu, prawda?

Nadal jednak szukałbym gotowych implementacji tutaj (choćby po to, żeby skorzystać z optymalizacji, które ktoś zrobił za mnie):

https://reference.wolfram.com/language/guide/DistanceAndSimilarityMeasures.html

I właśnie na tym polega użyteczność tego produktu.

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

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

#32804

W dniu wtorek, 6 sierpnia 2019 10:55:05 UTC+2 użytkownik Maciej Sobczak napisał:

> > Jeżeli masz jakieś pytania na temat mojej osobowości, to lepiej zapytaj
> 
> Nie da się. W tym zakresie nikt nie potrafi się sam zdiagnozować, muszę więc polegać na swoich (subiektywnych) odczuciach.

Szczerze powiedziawszy, jeżeli idzie o poznawanie ludzi, to mamy cały arsenał środków o wiele lepszych niż swoje subiektywne odczucia. Zresztą nawet to, w jaki sposób chcemy kategoryzować ludzi, czy wręcz sam fakt, że w ogóle chcemy ich kategoryzować, w większym stopniu świadczy o naszym własnym "kosmosie wewnętrznym", niż o tych osobach.

Serio. Jeżeli masz jakieś wątpliwości co do moich motywacji, to nic nie stoi na przeszkodzie, żeby przed wydaniem osądu zapytać. Z mojego doświadczenia odbiór tekstu potrafi się drastycznie różnić od intencji autora (kiedyś rozmawiałem z kolegą na czacie, i rozmowa poszła w takim kierunku, że prawie zaczęliśmy skakać sobie do gardeł. Kiedy porozmawialiśmy na żywo, okazało się, że jest luz)

> > > Prosta sprawa - zmodyfikuj rozwiązanie w Mathematice tak, żeby koszt zamiany elementu wynosił 2 a nie 1.
> > 
> > Pytanie jest fair i odpowiedź (również fair) jest taka: sam sobie policz.
> 
> OK, żeby nie było, że jestem nieuprzejmy, i dla własnej zabawy, zrobiłem mały research w tej sprawie.
> Jest taka fajna funkcja:
> 
> https://reference.wolfram.com/language/ref/SequenceAlignment.html
> 
> Ta funkcja rozpisuje różnice między sekwencjami, z czego można wyciągnąć poszczególne operacje (usunięcie, wstawienie, zamiana). Jeżeli dobrze zrozumiałem ćwiczenie, to rozwiązeniem może być takie coś:
> 
> myDistance[s1_, s2_] := Total[
>   Min[#] + Max[#] & /@
>    Cases[SequenceAlignment[s1, s2], a_List :> StringLength /@ a]
>   ]
> 
> Pozwoliłem sobie użyć skróconych (idiomatycznych) zapisów na podstawowe operacje mapowania i lambdy - skoro w innych językach są śmieszne znaczki, to ja też skorzystam.

No właśnie, i to mi się nie podoba. Widziałem w swoim życiu już takie wynalazki, i choć może przyspieszają nieznacznie samo pisanie, zdecydowanie utrudniają czytanie (i komplikują reguły użycia języka)

Kiedyś napisałem w Schemie takie rozwiązanie:


[define [edit-distance a b]
  [match `[,a ,b]
    [`[,a []]
     [length a]] ; insert all from a
    [`[[] ,b]
     [length b]] ; insert all from b
    [`[[,a0 . ,a*] [,b0 . ,b*]]
     [min [+ [edit-distance a* b] 1] ; delete a0
          [+ [edit-distance a b*] 1] ; delete b0
          [+ [edit-distance a* b*] ; replace or leave alone
             [if [equal? a0 b0] 0 2]]]]]]

Co prawda trzeba sobie przyswoić specjalne znaczenie przecinków i apostrofów, ale oprócz tego nie ma tu prawie nic oprócz nazywania i budowania/rozkładania struktur, a jedyne funkcje biblioteczne użyte w kodzie to min, length, + i equal?.

Struktura kodu blisko odzwierciedla matematyczną definicję z Wikipedii. Jak się zastosuje memoizację, to i szybkość działania tego programu nie jest tragiczna.

Pewnie w Mathematice można podobnie. Może nawet w jakimś sensie ładniej, bo nie trzeba tych przecinków i apostrofów. Ale też nie trzeba się w definicji odwoływać do tajemniczych funkcji, których zrozumienie samo w sobie jest wyzwaniem

[...]
> Czyli nadal nie wyszło jakoś dramatycznie dużo tego kodu, prawda?

Nie wyszło. Ale nadal wyszło mniej, niż powinno.

> Nadal jednak szukałbym gotowych implementacji tutaj (choćby po to, żeby skorzystać z optymalizacji, które ktoś zrobił za mnie):
> 
> https://reference.wolfram.com/language/guide/DistanceAndSimilarityMeasures.html
> 
> I właśnie na tym polega użyteczność tego produktu.

Jeżeli jest użyteczny, to super. Ale mam nadzieję, że teraz lepiej rozumiesz moją perspektywę i niechęć do środowisk programistycznych o zamkniętym kodzie.

Zresztą moim ideałem jest, żeby to kompilator szukał za mnie gotowych implementacji, żebym mógł korzystać z gotowych optymalizacji, które ktoś zrobił za mnie.

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

#32805

> > myDistance[s1_, s2_] := Total[
> >   Min[#] + Max[#] & /@
> >    Cases[SequenceAlignment[s1, s2], a_List :> StringLength /@ a]
> >   ]
> > 
> > Pozwoliłem sobie użyć skróconych (idiomatycznych) zapisów na podstawowe operacje mapowania i lambdy - skoro w innych językach są śmieszne znaczki, to ja też skorzystam.
> 
> No właśnie, i to mi się nie podoba.

Nie mam z tym problemu. Interpunkcja w Wolframie nie jest bardziej rozbudowana, niż powiedzmy w C++ a dla purystów (lub, co ważniejsze, automatycznych parserów i generatorów) wszystko ma dostępną tzw. pełną formę, zgodną ze schematem head[e1,e2,...].
Czyli idomatyczny zapis zawierający lambdę i mapowanie, np.:

#^2& /@ {1,2,3,4}

jest równoważny:

Map[Function[x, x^2], {1,2,3,4}]

ze spodziewanym wynikiem {1,4,9,16}.

To jest też zaletą Wolframa w stosunku do innych języków, które takich ustandaryzowanych zapisów nie umożliwiają i wymuszają swoją mniej lub bardziej cyrkową interpunkcję każdemu, kto tego języka używa. Ja w Wolframie mam wybór i stosuję skrócone zapisy tam i w takim zakresie, w jakim uznaję to za użyteczne. Ocena zależy też od tego, jaką żywotność ma mieć kod - projekt dłogofalowy i eksperymenty "na kolanie" to dwie różne sprawy (powyższy przykład to oczywiście ta druga kategoria). Fajnie, że Wolfram potrafi się dopasować do obu tych zastosowań.
Warto też zauważyć, że przy programowaniu w stylu funkcjonalnym wystarczy tylko kilka skrótów (lambda, mapy, transformacje), żeby spektakuralnie wpłynąć na ilość pisanego kodu. Te kilka skrótów to idiomy, które pojawiają się regularnie w dokumentacji i przykładach Wolframa, więc ich znajomość zdobywa się bardzo wcześnie. To nie jest poziom ekspercki.
Zobacz na pierwsze dwa przykłady tutaj:

https://reference.wolfram.com/language/ref/Map.html

Nie da się znać jednego i nie znać drugiego. To jest tak jak mała i wielka litery 'a' oraz 'A'.

> > Czyli nadal nie wyszło jakoś dramatycznie dużo tego kodu, prawda?
> 
> Nie wyszło. Ale nadal wyszło mniej, niż powinno.

A kto decyduje, ile powinno? Mathematica jest narzędziem wysokopoziomowym.

> Jeżeli jest użyteczny, to super. Ale mam nadzieję, że teraz lepiej rozumiesz moją perspektywę i niechęć do środowisk programistycznych o zamkniętym kodzie.

Wręcz przeciwnie. Rozumiem jeszcze gorzej, bo nie pokazałeś żadnej wady takiego rozwiązania. W Mathematice mam dostępne wszystkie opcje: mogę sięgnąć po gotową funkcję gdy chcę mieć od ręki gotowy wynik lub samemu napisać sobie algorytm, gdy chcę się wykazać rozumieniem tego jak działa. W tym drugim przypadku mogę stosować zapisy o różnym poziomie rygoru składniowego, żeby osiągnąć oczekiwane właściwości kodu. We wszystkich przypadkach jest albo krócej albo czytelniej (albo oba!), niż w dyskutowanych tutaj alternatywach.

Która z tych cech ma u mnie powodować "niechęć do środowisk programistycznych o zamkniętym kodzie"? Bo ja na skutek naszych dyskusji tylko się utwierdzam w przekonaniu, że Wolfram to bardzo dobra inwestycja.

> Zresztą moim ideałem jest, żeby to kompilator szukał za mnie gotowych implementacji, żebym mógł korzystać z gotowych optymalizacji, które ktoś zrobił za mnie.

Ale przecież napisanie własnego algorytmu jest tu utrudnieniem, bo odwraca uwagę kompilatora od właściwego celu. Rozwiązaniem jest właśnie zestaw funkcji wysokopoziomowych - takich jak EditDistance czy inny SequenceAlignment. Tam są te optymalizacje, z których chcesz skorzystać.

Tzn. ja chcę. :-)

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

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

#32806

> Czyli idomatyczny zapis zawierający lambdę i mapowanie, np.:
> 
> #^2& /@ {1,2,3,4}
> 
> jest równoważny:
> 
> Map[Function[x, x^2], {1,2,3,4}]

Przepraszam, to jeszcze nie pokazuje istoty zagadnienia. Można jeszcze bardziej purystycznie (prościej?):

Map[Function[x, Power[x,2]], List[1,2,3,4]]

Czy ta wersja jest czytelniejsza? To zależy, kto czyta. Na pewno dla automatu jest najlepsza (i wewnętrznie tak właśnie widać wszystkie wyrażenia, więc metaprogramowanie i przetwarzanie symboliczne odbywa się na takim poziomie), ale człowiek potrafi korzystać ze skrótów. A jak widać jest ich w tym przykładzie nawet więcej, niż się na początku wydawało.

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

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

#32807

W dniu środa, 7 sierpnia 2019 10:09:10 UTC+2 użytkownik Maciej Sobczak napisał:
> > Czyli idomatyczny zapis zawierający lambdę i mapowanie, np.:
> > 
> > #^2& /@ {1,2,3,4}
> > 
> > jest równoważny:
> > 
> > Map[Function[x, x^2], {1,2,3,4}]
> 
> Przepraszam, to jeszcze nie pokazuje istoty zagadnienia. Można jeszcze bardziej purystycznie (prościej?):
> 
> Map[Function[x, Power[x,2]], List[1,2,3,4]]
> 
> Czy ta wersja jest czytelniejsza? To zależy, kto czyta.

To jest problem z pojęciem czytelności, że jest niedookreślone.
Ale ta wersja korzysta z mniejszej ilości reguł, które "czysty umysł" potencjalnego czytelnika musi sobie przyswoić, żeby móc ją zrozumieć.
I to akurat nie zależy od tego, kto czyta.
(No, chyba że ktoś by twierdził, że ludzie od razu się rodzą ze zdolnością do parsowania zapisu #^2& jako funkcji anonimowej. Ale np. moje osobiste doświadczenie falsyfikuje owo twierdzenie)

Być może użycie "list comprehensions" byłoby dla różnych osób czytelniejsze, tzn. coś jak

[x^2 | x <- {1,2,3,4}]

> Na pewno dla automatu jest najlepsza (i wewnętrznie tak właśnie widać wszystkie wyrażenia, więc metaprogramowanie i przetwarzanie symboliczne odbywa się na takim poziomie), ale człowiek potrafi korzystać ze skrótów.

Automat też potrafi korzystać ze skrótów. Automatowi naprawdę jest wszystko jedno. Automat zrobi wszystko, do czego go zaprogramujesz.

Moje pytanie jest takie, czy ta pierwsza wersja rzeczywiście ma jakąś znaczącą przewagę nad tą ostatnią - na tyle znaczącą, żeby uzasadniała komplikowanie reguł dotyczących notacji.

Moim zdaniem nie. Zdaniem Wolframa (i Twoim chyba także) najwidoczniej tak.

Piszesz powyżej, że "interpunkcja w Wolframie nie jest bardziej skomplikowana, niż w C++", ale ze znanych mi języków C++ ma niewątpliwie najbardziej skomplikowaną składnię (na tyle skomplikowaną, że sami jego twórcy sobie z nim nie radzą)

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

#32808

> > Map[Function[x, Power[x,2]], List[1,2,3,4]]
> 
> Ale ta wersja korzysta z mniejszej ilości reguł, które "czysty umysł" potencjalnego czytelnika musi sobie przyswoić, żeby móc ją zrozumieć.

Bez przesady. W odróżnieniu od komputerów, człowiek nie musi "zarządzać" regułami, które zna. W szczególności znaczkologia, którą zna nawet ze szkoły podstawowej jest znacznie bardziej skomplikowana - dlatego dla większości ludzi zapis x^2 jest od razu czytelny, podczas gdy Power[x,2] budzi podejrzenia o jakiś podstęp, pomimo tego, że "korzysta z mniejszej ilości reguł". Podobnie jest z nawiasami, czy w ogóle z operatorami.
Dlatego też to:

a*x^2 + b*x + c

jest czytelniejsze, niż to:

Plus[c, Times[b, x], Times[a, Power[x, 2]]]

W pewnej optymalnej ilości skróty są więc czytelniejsze i naturalniejsze.

> Być może użycie "list comprehensions" byłoby dla różnych osób czytelniejsze, tzn. coś jak
> 
> [x^2 | x <- {1,2,3,4}]

Żaden postęp w stosunku do zwykłego mapowania. To jest nadmiarowa notacja. Jeśli dla kogoś czytelna, fajnie, ale posługując się Twoim własnym argumentem, wymaga znajomości większej liczby reguł. I ma bardzo ograniczone zastosowania.

> Automat też potrafi korzystać ze skrótów. Automatowi naprawdę jest wszystko jedno. Automat zrobi wszystko, do czego go zaprogramujesz.

Ale właśnie w przypadku automatu ja chcę, żeby był jak najprostszy. Bo wtedy spędze mniej czasu na jego programowaniu.

> Moje pytanie jest takie, czy ta pierwsza wersja rzeczywiście ma jakąś znaczącą przewagę nad tą ostatnią - na tyle znaczącą, żeby uzasadniała komplikowanie reguł dotyczących notacji.

Tak. Jest prostsza dla tych, co znają znaczki. Dokładnie tak samo, jak z wielomianem kwadratowym ze szkoły z powyższego przykładu.

> Moim zdaniem nie. Zdaniem Wolframa (i Twoim chyba także) najwidoczniej tak.

Błąd. Ja korzystam z *obu* wersji. Zależnie od tego, która jest w danym kontekście bardziej efektywna.
Znaczy - w każdym kontekście moja efektywność może być optymalna. :-)

> Piszesz powyżej, że "interpunkcja w Wolframie nie jest bardziej skomplikowana, niż w C++", ale ze znanych mi języków C++ ma niewątpliwie najbardziej skomplikowaną składnię

Więc wiem, że będzie łatwiej. :-P

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

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

#32809

W dniu środa, 7 sierpnia 2019 14:02:30 UTC+2 użytkownik Maciej Sobczak napisał:
> > > Map[Function[x, Power[x,2]], List[1,2,3,4]]
> > 
> > Ale ta wersja korzysta z mniejszej ilości reguł, które "czysty umysł" potencjalnego czytelnika musi sobie przyswoić, żeby móc ją zrozumieć.
> 
> Bez przesady. W odróżnieniu od komputerów, człowiek nie musi "zarządzać" regułami, które zna. W szczególności znaczkologia, którą zna nawet ze szkoły podstawowej jest znacznie bardziej skomplikowana - dlatego dla większości ludzi zapis x^2 jest od razu czytelny, podczas gdy Power[x,2] budzi podejrzenia o jakiś podstęp

Całkowicie się nie zgadzam.
Nigdy nie miałem w szkole wprowadzanego zapisu x^2.
W języku C ^ oznacza operację xor.
W Pythonie (i zdaje się że FORTRANie też) do potęgowania używa się operatora **.
Użycie symbolu ^ do wyrażenia potęgowania jest może uznane przez garstkę osób piszących w raczej niszowych językach.

> pomimo tego, że "korzysta z mniejszej ilości reguł". Podobnie jest z nawiasami, czy w ogóle z operatorami.

No właśnie. Ile godzin spędziliśmy w szkole, przyzwyczajając się do tej notacji?

> Dlatego też to:
> 
> a*x^2 + b*x + c
> 
> jest czytelniejsze, niż to:
> 
> Plus[c, Times[b, x], Times[a, Power[x, 2]]]

Tzn. chyba chciałeś powiedzieć, że Tobie wydaje się czytelniejsze, a nie "jest czytelniejsze", bo to ostatnie określenie nawet nie do końca wiadomo, co znaczy.


> W pewnej optymalnej ilości skróty są więc czytelniejsze i naturalniejsze.

Może raczej "w pewnych bardzo szczególnych okolicznościach".
W innych np. [a, b, c] będzie lepszą reprezentacją wielomianu, który powyżej zapisałeś.

Zresztą notacja matematyczna ma to do siebie, że jest zoptymalizowana względem dość specyficznego celu, mianowicie łatwości manipulacji formułami na papierze albo tablicy. Łatwiej jest zapisać "x", bo to tylko dwa ruchy ręką, niż, dajmy na to, "ilość" (czy cokolwiek chcemy wyrazić przy pomocy tej liczby)

> > Być może użycie "list comprehensions" byłoby dla różnych osób czytelniejsze, tzn. coś jak
> > 
> > [x^2 | x <- {1,2,3,4}]
> 
> Żaden postęp w stosunku do zwykłego mapowania. To jest nadmiarowa notacja. Jeśli dla kogoś czytelna, fajnie, ale posługując się Twoim własnym argumentem, wymaga znajomości większej liczby reguł. I ma bardzo ograniczone zastosowania.

Tak samo jak /@ jest nadmiarową notacją.
List comprehensions mają jednak pewną przewagę nad map. Przy pomocy map nie napiszesz czegoś takiego:

[(x, y, z) | x <- [1 .. 100], y <- [1 .. 100], z <- [1 .. 100], x^2+y^2==z^2]


> > Automat też potrafi korzystać ze skrótów. Automatowi naprawdę jest wszystko jedno. Automat zrobi wszystko, do czego go zaprogramujesz.
> 
> Ale właśnie w przypadku automatu ja chcę, żeby był jak najprostszy. Bo wtedy spędze mniej czasu na jego programowaniu.

A w przypadku człowieka dlaczego nie chcesz, żeby był jak najprostszy?

> > Moje pytanie jest takie, czy ta pierwsza wersja rzeczywiście ma jakąś znaczącą przewagę nad tą ostatnią - na tyle znaczącą, żeby uzasadniała komplikowanie reguł dotyczących notacji.
> 
> Tak. Jest prostsza dla tych, co znają znaczki. Dokładnie tak samo, jak z wielomianem kwadratowym ze szkoły z powyższego przykładu.

Zrobiłem ankietę na Twitterze. Jak do tej pory zagłosowały 32 osoby.
Wygląda na to, że spośród nich zgadza się z Tobą dokładnie 0 osób.

https://twitter.com/PaniczGodek/status/1159029909672603648

> > Moim zdaniem nie. Zdaniem Wolframa (i Twoim chyba także) najwidoczniej tak.
> 
> Błąd. Ja korzystam z *obu* wersji. Zależnie od tego, która jest w danym kontekście bardziej efektywna.
> Znaczy - w każdym kontekście moja efektywność może być optymalna. :-)

Cały czas nie znam kontekstu, w którym ta druga notacja z haszami i małpami byłaby efektywniejsza.

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

#32813

> Całkowicie się nie zgadzam.
> Nigdy nie miałem w szkole wprowadzanego zapisu x^2.

No tak. Bo widzisz - w Mathematice ten zapis wygląda dokładnie tak jak w szkole. Natomiast po skopiowaniu go do grup dyskusyjnych jest x^2, bo w okienku, gdzie pisze tego posta, jest tylko taki font i nie ma superscriptu.

> Użycie symbolu ^ do wyrażenia potęgowania jest może uznane przez garstkę osób piszących w raczej niszowych językach.

https://en.wikipedia.org/wiki/Exponentiation#In_programming_languages

MATLAB, Wolfram, R, Excel, Analytica, TeX, "most computer algebra systems".

"Garstka osób w niszowych językach", tak? Łomatko...
Sami użytkownicy Excela pewnie przykryliby liczebnie fanów wszystkich innych zapisów... Pozostali to ludzie zajmujący się profesjonalnie inżynierią i matematyką. Niech będzie, że to nieistotna garstka.

> No właśnie. Ile godzin spędziliśmy w szkole, przyzwyczajając się do tej notacji?

Nie ważne ile. Ważne, że to była inwestycja, na której można bezpiecznie budować. Programiści nie startują od zera i zwykle są to ludzie z jakimś istniejącym już fundamentem intelektualnym. No chyba że robimy język dla kosmitów, jak w filmach sci-fi i zakładamy, że odbiorca nie kuma kompletnie nic.

> List comprehensions mają jednak pewną przewagę nad map. Przy pomocy map nie napiszesz czegoś takiego:
> 
> [(x, y, z) | x <- [1 .. 100], y <- [1 .. 100], z <- [1 .. 100], x^2+y^2==z^2]

To, że w Twoim ulubionym języku nie napiszę, to jest Twój problem a nie mój. :-)

Map[
 Function[triple,
  Apply[Function[{x, y, z}, If[x^2 + y^2 == z^2, {x, y, z}, Nothing]], triple]
 ],
 Tuples[Range[100], 3]
]

Nieco dłużej, ale Ty osiągnąłeś limit swojego zapisu a moja mapa nawet się nie rozgrzała.
W tym przypadku jednak nie użyłbym mapy, bo to jest system z ograniczeniami a nie transformacja i od mapy lepszy jest filtr:

Cases[Tuples[Range[100], 3], {x_, y_, z_} /; x^2 + y^2 == z^2]

Nawet działa >2x szybciej. I tak bym to zostawił.

> A w przypadku człowieka dlaczego nie chcesz, żeby był jak najprostszy?

Bo polegam na tym, co człowiek już wie ze szkoły. To jest koszt, który już został poniesiony, więc mogę z niego za darmo skorzystać.

> Zrobiłem ankietę na Twitterze. Jak do tej pory zagłosowały 32 osoby.
> Wygląda na to, że spośród nich zgadza się z Tobą dokładnie 0 osób.

Ale znasz tą teorię psychologiczną, że otaczamy się ludźmi, którzy potwierdzają nasze poglądy (bo innych nie lubimy, więc nie chcemy ich mieć w kręgu znajomych)? Wiesz, co by wyszło, gdyby Wolfram taką ankietę zrobił na swoim profilu?

> Cały czas nie znam kontekstu, w którym ta druga notacja z haszami i małpami byłaby efektywniejsza.

Problem w tym (podobnie jak w wielu poprzednich tematach), że nie da się ustawić obiektywnej granicy pomiędzy znaczkami rozsądnymi a nierozsądnymi. Od nawiasów, przez podstawowe operatory, po strzałki po hasze i małpy. Dla Ciebie małpa jest nieczytelna, dla kogoś innego nieczytelny będzie znak plusa.

Granica czytelności jest subiektywna i zależy od... kręgu znajomych.

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

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

#32797

W dniu 30.07.2019 o 15:58, godek.maciek@gmail.com pisze:
> Hej,
> gdyby ktoś był zainteresowany, to ostatnio opublikowałem na Quorze nieco przydługawy artykuł (czy może raczej "małą książkę"?) objaśniający technikę Friedmana i Byrda "uruchamiania ewaluatora od tyłu".
> 
> https://www.quora.com/Can-you-explain-to-non-coders-the-most-impressive-code-youve-seen/answer/Panicz-Godek
> 
> W ogólności pytanie "jaki jest najbardziej imponujący kod, jaki widziałeś" wydaje mi się ciekawe, więc jeśli ktoś tu ma jakieś swoje obserwacje na ten temat, z chęcią bym się dowiedział.
> 
> Pozdrawiam
> 
Daję namiar:
https://scholarworks.iu.edu/dspace/bitstream/handle/2022/8777/Byrd_indiana_0093A_10344.pdf

"Relational Programming in miniKanren:Techniques, Applications, 
andImplementations"

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

#32798

W dniu wtorek, 6 sierpnia 2019 15:32:26 UTC+2 użytkownik Borneq napisał:

> > gdyby ktoś był zainteresowany, to ostatnio opublikowałem na Quorze nieco przydługawy artykuł (czy może raczej "małą książkę"?) objaśniający technikę Friedmana i Byrda "uruchamiania ewaluatora od tyłu".
> > 
> > https://www.quora.com/Can-you-explain-to-non-coders-the-most-impressive-code-youve-seen/answer/Panicz-Godek
> > 
> > W ogólności pytanie "jaki jest najbardziej imponujący kod, jaki widziałeś" wydaje mi się ciekawe, więc jeśli ktoś tu ma jakieś swoje obserwacje na ten temat, z chęcią bym się dowiedział.
> > 
> > Pozdrawiam
> > 
> Daję namiar:
> https://scholarworks.iu.edu/dspace/bitstream/handle/2022/8777/Byrd_indiana_0093A_10344.pdf
> 
> "Relational Programming in miniKanren:Techniques, Applications, 
> andImplementations"

Posiłkowałem się tym, zwłaszcza przy obsłudze więzów.
Inne źródło to artykuł Friedmanna i Hemanna o minimalistycznej wersji minikanrena zwanej "microkanren" (albo uKanren):

http://webyrd.net/scheme-2013/papers/HemannMuKanren2013.pdf

Ale jeśli ktoś ma za małą motywację do czytania, to jest też film warsztatowy:

https://www.youtube.com/watch?v=0FwIwewHC3o

Przyznam też, że pomocna była dla mnie lektura źródeł microkanrena w Haskellu (dzięki systemowi typów rozumiało mi się to dużo lepiej, niż implementację w Scheme):
https://gist.github.com/msullivan/4223fd47991acbe045ec

ale moja implementacja różni się na kilka istotnych sposobów od miniKanrena, bo mieliśmy inne priorytety - im zależało na przenośności i integrowalności ich języka w różnych środowiskach (i w pewnej mierze na wydajności), a mnie na czytelności języka i łatwości prezentacji

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

#32799

W dniu 06.08.2019 o 15:45, godek.maciek@gmail.com pisze:
> Przyznam też, że pomocna była dla mnie lektura źródeł microkanrena w Haskellu (dzięki systemowi typów rozumiało mi się to dużo lepiej, niż implementację w Scheme):
> https://gist.github.com/msullivan/4223fd47991acbe045ec

Co to znaczy microkanren w Haskellu?
Czy ten mały program to interpreter w Haskellu składni schemapodobnej 
microkanrena czy też rozszerzenie Haskella i microkanren ma tu składnię 
haskelopoodbną?

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

#32800

W dniu wtorek, 6 sierpnia 2019 16:32:17 UTC+2 użytkownik Borneq napisał:

> > Przyznam też, że pomocna była dla mnie lektura źródeł microkanrena w Haskellu (dzięki systemowi typów rozumiało mi się to dużo lepiej, niż implementację w Scheme):
> > https://gist.github.com/msullivan/4223fd47991acbe045ec
> 
> Co to znaczy microkanren w Haskellu?
> Czy ten mały program to interpreter w Haskellu składni schemapodobnej 
> microkanrena czy też rozszerzenie Haskella i microkanren ma tu składnię 
> haskelopoodbną?

Tzn. ma składnię wywiedzioną z Haskella (nie tyle "Haskellopodobną", tylko taką, na jaką Haskell naturalnie pozwala swoimi konstruktorami typów i funkcji anonimowych)

na dole wklejonego powyżej linka jest kilka przykładów wyrażeń w Haskellowym microKanrenie.

MiniKanren jako taki nie ma swojej składni, jego składnia jest z założenia "pasożytnicza" na składni goszczącego języka.

Różne implementacje języków *Kanren można znaleźć tutaj:
http://minikanren.org/

Jak byś sobie chciał zobaczyć jak to wygląda np. w JavaScripcie, to tutaj masz przykłady:
https://github.com/tca/veneer/blob/master/mk_test.js

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

#32801

W dniu 06.08.2019 o 16:39, godek.maciek@gmail.com pisze:
> MiniKanren jako taki nie ma swojej składni, jego składnia jest z założenia "pasożytnicza" na składni goszczącego języka.
> 
> Różne implementacje języków *Kanren można znaleźć tutaj:
> http://minikanren.org/

To świetnie, widzę że nawet język nie musi być funkcyjny. Widzę Javę i 
Rust (co prawda nie ma C++, ale to chyba z braku odśmiecania pamięci)
Najbardziej znam Javę, więc w wolnym czasie przyjrzę się:
https://github.com/nd/mk.java
i
https://github.com/heidisu/java8kanren

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | pl.comp.programming

csiph-web