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/SequenceA
lignment.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/Distanc
eAndSimilarityMeasures.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.

do góry

> > 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

do góry

> 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

do góry

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ą)

do góry

> > 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

do góry

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/1159029909672
603648

> > 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.

do góry

> 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_prog
ramming_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

do góry

On 2019-08-03 09:55, g...@g...com wrote:
> W dniu sobota, 3 sierpnia 2019 06:52:44 UTC+2 użytkownik AK napisał:
>
>>> No np. tak (z pattern-matcherem Shinna/Wrighta):
>>>
>>> (let (((abc ... y z) some-list))
>>> `(,@abc ,z ,y))
>>
>> O ja pieprnicze.. No rzeczywiscie "prosto"...
>
> Dla ignoranta nawet zwykłe dodawanie będzie wyglądało jak czarna magia.
>
> Jeżeli uważasz, że umiesz prościej, to pokaż, a jeśli nie, to lepiej zachowaj
> takie światłe uwagi dla siebie.

vec[-2], vec[-1] = vec[-1], vec[-2]

Tak sie to robi w _normalnym_ jezyku programowania, a nie jakies szmuje
buje z kompletnie nieczytelnym pattern matchingiem do tak prostackiej
wrecz operacji.

AK

do góry

> vec[-2], vec[-1] = vec[-1], vec[-2]
>
> Tak sie to robi w _normalnym_ jezyku programowania

W Wolframie jest nieco dłużej:

{vec[[-2]], vec[[-1]]} = {vec[[-1]], vec[[-2]]}

ale idea jest zachowana. Tak czy inaczej chodzi o fundament: lista musi być strukturą
liniową z dostępem swobodnym a nie jakąś rekurencyjną matrioszką.

Niektóre języki odróżniają listy od tablic pod względem tego swobodnego dostępu, ale
to jest rozróżnienie niskopoziomowe, przydatne powiedzmy w C/C++ lub w Adzie, ale
kompletnie nieużyteczne w takich językach jak Python czy Wolfram.

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

do góry

On 2019-08-08 09:06, Maciej Sobczak wrote:
>> vec[-2], vec[-1] = vec[-1], vec[-2]
>>
>> Tak sie to robi w _normalnym_ jezyku programowania
>
> W Wolframie jest nieco dłużej:
>
> {vec[[-2]], vec[[-1]]} = {vec[[-1]], vec[[-2]]}

Dopuszczalnie. Nie ma o co kopii kruszyc (choc Wolframa nie lubie
bo zbyt Lispowaty i malo obiektowy - ale dobrze - j.w. - ze nie
"dogmatycznie" Lispowaty). Jest czytelne.

> ale idea jest zachowana. Tak czy inaczej chodzi o fundament: lista musi być
strukturą liniową z dostępem swobodnym a nie jakąś rekurencyjną matrioszką.

Janiej/trafniej juz nie mozna :)

>
> Niektóre języki odróżniają listy od tablic pod względem tego swobodnego dostępu,
ale to jest rozróżnienie niskopoziomowe, przydatne powiedzmy w C/C++ lub w Adzie, ale
kompletnie nieużyteczne w takich językach jak Python czy Wolfram.

No niekoniecznie. Tzn "metodycznie" masz racje, ale wydajnosciowo
juz mniej. W Pythonie istnieje standardowa struktura typu tablice
- array() - o okreslonym i i stalym (w przeciwienstwie do list) -
typie danych, czyli zdecydowanie wydajniejsza ok (linked)list,
Oczywiscie obluga obu jest taka sama/bardzo podobna.

PS: Nalezy tez wspomniec o numpy arays.

AK

do góry