Lisp и современность

Проверить ИИ самого себя тоже невозможно при таком подходе т.к. фарш невозможно провернуть назад.

Можно. Одна нейросетка выдаёт результат, другая проверяет. GAN-ы так устроены.

Анасамбли ИИ

А в голове у тебя тоже ансамбль интеллектов?

а она и говорит, надо вам, голубчик, отрезать ногу.

Кинчик вспомнился «Особое мнение». Там вообще, сразу в морг.

А в голове у тебя тоже ансамбль интеллектов?

Не то, чтобы прямо интеллектов, но, в общем, не исключено. Есть хорошая книжка на эту тему — Society of Mind.

Первым делом нужно отказаться от регулярных выражений! Вот там самое зло и притаилось.

Регулярки не замай! Это зло какое надо зло! %)

Писать словами

«Начала Эвклида» так и написаны (PDF) ©.

Но ленивые потомки сокращений напридумывали :)

Можно. Одна нейросетка выдаёт результат, другая проверяет. GAN-ы так устроены.

Нет, не так. GAN это две сети: генератор + дискриминатор. Одна сеть это генератор бреда на базе первоначальной выборки, а вторая сеть это дискриминатор (двоичный классификатор) пытается решить, это генератор набредил или это что-то из исходной обучающей выборки.

Т.е. тут идет просто «подгонка». Ни о какой перепроверке самой себя речи не идет. Просто выходной слой нейронной сети вынесли в отдельную сеть - классификатор.

А в голове у тебя тоже ансамбль интеллектов?

Вы яркий пример генератора бреда, пятизвездочного.

Нет, не так

Даже из твоего же объяснения это так. ИИ проверяет/обучает ИИ.

Ни о какой перепроверке самой себя речи не идет

Зависит от того, как посмотреть, кто есть «само себя». Две сетки это части одного ИИ. Всё таки ИИ это немножко более широкое понятие чем сетка и может включать в себя сколько угодно этих сеток, как и символических систем одновременно.

Даже из твоего же объяснения это так. ИИ проверяет/обучает ИИ.

Второй ИИ просто сравнивает, похоже ли изображение на изображения из обучающей выборки. Он вообще ничего не знает ни о первом ИИ ни о том что его нужно проверять. Если вы все еще не понимаете, то попробуйте перенести эту связку на задачу «перепроверить» ответ на вопрос, может так понятнее станет.

Другой пример, первая сеть правильно выдала картинку слона, а в обучающей выборке было очень мало слонов. В итоге вторая сеть будет оч низко оценивать слонов и в конечном итоге первая сеть вообще перестанет их рисовать хотя это верный ответ. Вопрос, а кто в таком случае будет проверять вторую сеть на адекватность я даже не спрашиваю.

cdadr (ку-да-дер) .. Не сильно похоже на хороший интерфейс, если честно. Но это может быть просто я чего-то не пониманию.

Предложи хорошее имя для функции, которая возвращает хвост головы хвоста списка.

Для начала неплохо бы обосновать необходимость такой фичи. И почему нельзя все эти функции заменить макросней вроде универсальных head/hd и tail/tl? Или head-tail/ht и tail-head/th вдобавок? Например, (th tl <список>), хвост головы хвоста списка. Хотя бы читаемо, имхо.

предпочитают использовать иероглифическую, так как с её помощью можно понятно выражать более сложные утверждения

Нет, нельзя. Это кажущаяся «глубина». Так же как поставить смайлик, или клоуна. Людям кажется что это как бы передаёт весь спектр эмоций, что даже не выразить словами. На самом деле люди просто не умеют выразить это словами. А что конкретно имел в виду поставивший смайлик человек можно только догадываться.

Смайлики нужны для передачи эмоций, а слова – для передачи информации, нуждающейся в сознательной интеллектуальной обработке. Поэтому логично разделять два этих действия. Зачем тебе в ответах инфа, что кто-то считает тебя клоуном или взоржал от твоего сообщения, ты же скипать будешь этот мусор и не обращать на него никакого внимания, только раздражаться?

Я говорю — к примеру, суть не в хэшмапах. Пока у тебя кададры вместо интерфейса — ты никуда от списков не денешься, хэшмапы или не хэшмапы.

Если по ТЗ должен быть список, то почему не список? Если вдруг ТЗ изменится настолько, что списки не подходят, то лучше переписать всё, чем пытаться совместить два интерфейса (как std::string.c_str() заставляет хранить лишний байт в каждой строке и заставляет std::string.substr быть O(n), а не O(1)).

Для начала неплохо бы обосновать необходимость такой фичи.

Работа со списками. В случае лиспа с телами макросов (my-macros (var1 var2 ...) (vals :key k1 k2)), например, надо убедится, что ключ имеет значение :key.

Альтернатива: вместо (eq (cadadr body) :key) писать как в Схеме

(match body
  (((names ...) (v1 mode k ...)) (eq mode :key)))

Читает чуть легче, но заметно многословнее.

И почему нельзя все эти функции заменить макросней вроде универсальных head/hd и tail/tl?

Так и есть универсальные car и cdr. Буквы a и d (а не h и l) традиционно. Ведь если будешь описывать точку, то её абсциссу и ординату не будешь же называть a и o, а будешь x и y. Так и здесь.

Для начала неплохо бы обосновать необходимость такой фичи.

Работа со списками.

То есть это решение проблемы, порождаемой отсутствием в лишпе чего-то еще, кроме списков: большая вложенность списков друг в друга.

Буквы a и d (а не h и l) традиционно. Ведь если будешь описывать точку, то её абсциссу и ординату не будешь же называть a и o, а будешь x и y. Так и здесь.

Только в математике действительно есть такая традиция, потому что x, y и z (или a, b, c и т.д. по алфавитному порядку) используются повсеместно, ибо так исторически сложилось (и поскольку алгебра знакома каждому образованному человеку, то такая традиция понятна всем), а в лишпе местечковая традиция непонятная никому за пределами его мира. foo/bar знаю, а эти кадавры – что это такое??

Если по ТЗ должен быть список, то почему не список?

По ТЗ у тебя система для управления зоопарком. Списки разрабатывать не надо, они уже разработаны.

Если вдруг ТЗ изменится настолько, что списки не подходят, то лучше переписать всё

Как ты думаешь, бизнес будет согласен на каждый чих заново переписывать всё, выбрасывая на ветер кучу времени и денег и распугивая клиентов, у которых раз в год (или в месяц) всё перестаёт работать от слова совсем и нужно срочно переписывать весь клиентский код с кададров на сепульки? Или всё-таки постарается по максимуму этого избежать?

чем пытаться совместить два интерфейса

Не надо ничего совмещать, если у твоего зоопарка уже есть нормальный публичный интерфейс. Он представляет собой контракт между твоим кодом и тем кодом, что его использует, и пока интерфейс остаётся неизменным — ты можешь шатать реализацию как твоей душе угодно. Заменять списки на хэшмапы, менять фреймворки, переписывать всё на расте (если ты предоставляешь доступ к своему API по сети) — и у твоих пользователей ничего не сломается.

порождаемой отсутствием в лишпе чего-то еще, кроме списков

Нет, это связано с представлением кода в виде списков, точнее деревьев. Даже пример тебе привели, как в макросе вытаскивается ключ из дерева. А так вообще в CL есть и обычные first, second и т.д. до десяти. Вместе с макросами типа -> можно бегать по дереву как угодно.

Все традиции местечковые. Счëтчик в переменной i из фортрана, cat из Unix, car из Лиспа.

Есть структура cons, у неë поля car и cdr. Из этих ячеек можно строить список, можно дерево, можно ассоциативный список. И для получения данных из этих структур сделаны удобные функции.

Так этот нормальный публичный интерфейс и предоставляет список списков животных. Если кому-то вдруг нужны хэшмапы, надо делать вторую версию интерфейса.

Или как представляешь единый интерфейс к спискам и хэшмапам? Не отдавать вообще коллекцию? Тогда придëтся реализовать map-animals, если структура коллекции должна быть скрыта. И если в интерфейсе есть animals-first и animals- rest, то при переходе на хэшмапы станет жутко тормозить, так как rest на хэшмапах требует почти полного копирования коллекции.

какой в этом смысл?

За это платят деньги.

Счëтчик в переменной i из фортрана, cat из Unix, car из Лиспа.

«i» определенно от «iterate», это понятно.
«cat» это от «catenate/concatenate» (не нашел инфы, сам я думал, что это от «каталога»), тоже понятно.
«car» … ?? «Автомобиль»? «Carrying»? Но тут видишь «cdr» и всё, ноль догадок.

Так этот нормальный публичный интерфейс и предоставляет список списков животных.

Он предоставляет список животных. У списков свой интерфейс, у животных свой. В список списков это превращается, если ты выкидываешь понятие жывотного и начинаешь теребонькать его как список списков напрямую. Со всеми вытекающими.

как представляешь единый интерфейс к спискам и хэшмапам?

Не нужно никакого единого интерфейса к спискам и хэшмапам — и у того, и у того уже есть собственные стабильные, не зависящие от деталей реализации интерфейсы. Такой же стабильный интерфейс должен быть и у сущностей твоей предметной области — зоопарков, домов и бинарных деревьев.

структура коллекции должна быть скрыта

Не «структура коллекции должна быть скрыта» (хотя она, наверное, должна), а коллекции не должны смешиваться с сущностями, которые они содержат. Баханье коллекций сущностей кададрами приводит именно к этому.

«i» определенно от «iterate», это понятно.

А счётчик по второй координате «j»?

«cat» это от «catenate/concatenate» (не нашел инфы, сам я думал, что это от «каталога»), тоже понятно.

«car»

«Contents of the Address Register» и «Contents of the Decrement Register»

Это то, во что загружалась cons на IBM 704.

Он предоставляет список животных.

Он предоставляет список животных, сгруппированных по видам. Поэтому список списков.

Не нужно никакого единого интерфейса к спискам и хэшмапам

Если у тебя в интерфейсе список животных, а в реализации хэшмап, на каждый вызов будешь преобразовывать в список?

коллекции не должны смешиваться с сущностями, которые они содержат.

Так тут и не смешиваются. Есть сущность Зоопарк. Есть сущность Животное. Есть у Зоопарка метод интерфейса, возвращающий список животных, сгруппированных по видам (то есть список списков).

Он предоставляет список животных, сгруппированных по видам. Поэтому список списков.

Без разницы на самом деле. Хоть список списков списков — всё равно нельзя бахать жывотных кададрами, если не хочешь проблем в будущем %)

Если у тебя в интерфейсе список животных, а в реализации хэшмап, на каждый вызов будешь преобразовывать в список?

Как клиентский код организован — не моё дело на самом деле. Моё дело придерживаться контракта — предоставлять функцию, которая отдаёт список (список списков, список списков списков — в документации описано, что именно) жывотных. Не какое-то произвольное месиво из структур данных.

Клиент может его хранить как угодно, хоть в списках, хоть в векторах, хоть в перловых хэшах, хоть в сишных массивах.

Потом под кададры подвели базу:

The  LISP  tree  access  language  consists  of only  four   statements  signified  by  single  letters. These
statements are then placed in sequence to create an access program. The four statements are as follows:
a access: accesses the head cell
c complete:  finished processing
d drop: drop the head cell
r run: run the program

Программа читается справа налево.

То есть cadadr = «запустить: сбросить, прочитать, сбросить, прочитать, завершить».

Не какое-то произвольное месиво из структур данных.

Так никакого месива и нет. Есть список списков животных в публичном интерфейсе.

всё равно нельзя бахать жывотных кададрами

А map и filter можно? Кададры такие же функции для работы со списками, как и map.

Так никакого месива и нет. Есть список списков животных в публичном интерфейсе.

Ну и отлично. Keep it that way.

А map и filter можно? Кададры такие же функции для работы со списками, как и map.

Почему нельзя-то. Все эти функции входят в интерфейс списков, используй на здоровье. Со списками.

Технически, конечно, тебе никто не запретит использовать их и с животными, в обход их интерфейса (если они представлены в виде списков) — но лучше не надо. Точно так же, как не стоит лазить напрямую в реализацию списков в обход cons, car и cdr.

Почему нельзя-то. Все эти функции входят в интерфейс списков, используй на здоровье. Со списками.

Так я и предлагаю использовать cadadr для получения второго животного из второй группы.

в обход их интерфейса (если они представлены в виде списков)

Внутрь объектов лазить через списки я не предлагаю. Даже если они в виде списков, в CL есть defstruct для списков.

(defstruct (animal (:type list)) name age)
(animal-name '("Tom" 10))
"Tom"

«i» определенно от «iterate», это понятно.

А счётчик по второй координате «j»?

А это уже упомянутый мною ранее алфавитный порядок наименования переменных, выполняющих одинаковую роль, в данном случае счетчиков циклов. Поэтому «i», «j» и «k» нормально воспринимаются в теле цикла. И здесь нет нужды ни в каком потайном знании вроде

«car»

«Contents of the Address Register» и «Contents of the Decrement Register»

Это то, во что загружалась cons на IBM 704.

«i» в теле цикла в любом (Си-подобном) языке будет счетчиком.

Это уже из разряда вещей вроде питоновского «Дзена». Изобретательно, интересно, но вторично, потому что является философской попыткой переосмыслить исторически сложившиеся факты с довольно прозаичной на самом деле историей возникновения.

Нет, нельзя. Это кажущаяся «глубина». Так же как поставить смайлик, или клоуна. Людям кажется что это как бы передаёт весь спектр эмоций, что даже не выразить словами. На самом деле люди просто не умеют выразить это словами. А что конкретно имел в виду поставивший смайлик человек можно только догадываться.

Смайлики нужны для передачи эмоций, а слова – для передачи информации, нуждающейся в сознательной интеллектуальной обработке.

А эмоции - результат твоих идей, установок, может даже сознательно выбранных воззрений.

И здесь нет нужды ни в каком потайном знании вроде

Здесь было потайное знание, что в Фортране тип определялся именем. Если имя начиналось с букв I, J, K, L, M, N, то переменная была целой, иначе – вещественной. А потом алгоритмы переписали на другие языки, а традиция осталась.

Также car и cdr. На IBM 704 была конкретная причина. А далее просто традиция.

«i» в теле цикла в любом (Си-подобном) языке будет счетчиком.

А «car» в любом (лисп-подобном) будет головой списка.

Вплоть до https://www.demo2s.com/node.js/node-js-array-cdr.html

Есть байка, что на языке эскимосов для обозначения разных видов снега существует сразу с десяток или больше разных слов, но кроме эскимосов это никому не интересно.

Счëтчик в переменной i из фортрана

Из математики вообще-то.

«i» определенно от «iterate», это понятно.

Вот, ни разу не факт. i,j,k — традиционное обозначение индексов массива из математики, тут либо в латынь смотреть, либо просто признать, что здесь так принято, а не подгонять задачу под ответ.

«cat» это от «catenate/concatenate»

Хотя так cat и можно использовать, чаще всё же он нужен, чтобы вывести файл на стандартный вывод или же засунуть в трубу. Тут метафора «to link together in a series or chain» скорее мешает.

«car» … ?? «Автомобиль»? «Carrying»? Но тут видишь «cdr» и всё, ноль догадок.

Линукс — интуитивно понятная операционная система©. Человек потыкается-потыкается и интуитивно поймёт, что нужно прочитать документацию.

P.S. В споре про закорючки против слов, я, кажется, нашёл ультимативный пример: знаки дорожного движения. Читаемость очень важна, потому как должно считываться за долю секунды, не должно отвлекать водителя, должно очень надёжно восприниматься, цена ошибки — жизнь человеческая. И вот тут слова просто не подходят и всё, их можно использовать для маловажных уточнений, но основа основ это графический символ.

индексов массива из математики

В математике есть массивы? А можно ссылку на любой учебник/статью до 1956 года, где есть такое слово?

Из математики вообще-то.

А в Фортране из математики.

В ANSI Common Lisp, например, было так (примеры из Стандарта):

(loop for n from 1 to 10
       when (oddp n)
         collect n)

...

(do ((temp-one 1 (1+ temp-one))
       (temp-two 0 (1- temp-two)))
      ((> (- temp-one temp-two) 5) temp-one)) =>  4

 (do ((temp-one 1 (1+ temp-one))
       (temp-two 0 (1+ temp-one)))     
      ((= 3 temp-two) temp-one)) =>  3

 (do* ((temp-one 1 (1+ temp-one))
        (temp-two 0 (1+ temp-one)))
       ((= 3 temp-two) temp-one)) =>  2                     

 (do ((j 0 (+ j 1)))
     (nil)                       ;Do forever.
   (format t "~%Input ~D:" j)
   (let ((item (read)))
     (if (null item) (return)   ;Process items until NIL seen.
         (format t "~&Output ~D: ~S" j item))))

...

(dotimes (temp-one 10 temp-one)) =>  10
(setq temp-two 0) =>  0
(dotimes (temp-one 10 t) (incf temp-two))

Матрицы точно есть. Отличие матрицы от массива, в данном случае, чисто филологическое и неинтересно.

Про матрицы и вектора согласен.

Это другая крайность, когда иероглифы-значки должны восприниматься без связи с соседними. Японцы даже в эмодзи часть своих кандзи запихнули (ну нет интернациональных картинок для «открыто», «заявка», «бесплатно», …).

И здесь их хотя бы можно заменить фонетикой.

А я именно про комбинации. Хоть про алгебраические и Haskell, хоть про вэньянь, когда четыре иероглифа расписываются фонетикой (даже современной китайской) на пару абзацев текста. И, соответственно, фразу, в которой 5-6 шесть таких четвёрок приходится расписывать на пару листов, причём не факт, что получится, так как читатель не может одновременно держать в голове больше 7 различных понятий. А визуально вполне приемлемо, так как это маленький абзац с 5-6 сложных, но понятных понятий.

Если заставить учить математике и физике только устно, то они откатятся на уровень 19 века.

Но если брать именно китайцев. то у них другая беда: произношение иероглифов не передаёт полностью смысл. Для бытовых разговоров этого хватает, а вот детектив вслух уже не почитать. Поэтому в идеале письменность должна быть типа китайской, а произношение типа русского.

Но ленивые потомки сокращений напридумывали

Попробуйте словами (т.е. без пр. a, отр. b, луч c) написать доказательство теоремы о трёх перпендикулярах. Или хотя бы для школьной алгебры:

первый корень квадратного уравнения равен минус произведение двух на коэффициент при неизвестном в первой степени плюс корень квадратный из квадрата коэффициента при неизвестном во второй степень минус произведения четырех на неизвестное в первой степень на свободный член и всё это поделить на произведение двух и коэффициент при неизвестном во второй степени.

Попробуйте словами (т.е. без пр. a, отр. b, луч c) написать доказательство теоремы о трёх перпендикулярах.

Математики до ~XVII века писали доказательства текстом на латыни, например, глянь математические трактаты в The Mathematical Association of America, от «Геометрии Эвклида» © до «Астрономии Кеплера» © и удивись :)

Математики до ~XII века писали доказательства текстом на латыни

Арабские в том числе?! Математика до XII века в Европе – ад кромешный с «прибавим к одному числу другое число», а ещё веке в XIV один чувак получили докторскую степень по математике за составление таблицы умножения чисел до 50ти, то, с чем нынешний третьеклассник справиться за полчаса. Правда, если не последует примеру тогдашних европейских математиков и не будет использовать римскую нотацию для чисел.

Но уже во времена Ньютона и Лейбница (рубеж между 17 и 18 веками) в математике вовсю использовали специальные символы и придумывали новую нотацию для новых преобразований. Так, мы используем в дифференциальном исчислении обозначения, придуманные Ньютоном, они оказались удобнее предложенных Лейбницем.

Но уже во времена Ньютона и Лейбница (рубеж между 17 и 18 веками) в математике вовсю использовали специальные символы и придумывали новую нотацию для новых преобразований.

Любой нотации предшествуют элементарные текстовые определения.
Текст самодостаточен, а мат.нотация требует знания неочевидных абстракций, например, нужна куча времени, чтобы разбираться в индексах мат.анализа Риччи ©, графической нотации Пенроуза © и прочих «бурбакизмах» ©.

Текст самодостаточен,

Это как уметь ходить пешком vs уметь водить машину. Первое проще, но если хочется быстро и далеко перемещаться, приходится получать права (либо платить тому, у кого они есть).

Текст самодостаточен

Только если использует математическую нотацию. Попробуйте текстом записать нахождение решения с сингулярным ядром интегрального линейного уравнения второго порядка в частных производных. Даже в математической нотации без всякого текста это занимает несколько страниц. Собственно, даже на несложных выражениях будете путаться в «одна переменная, другая переменная, третья переменная, не та, что другая».

прочих «бурбакизмах»

Бурбаки – это смерть математики.

Но давайте проведём эксперимент и вы словами запишите доказательство простого факта: сумма произведения первой координаты одного радиус-вектора на первую координату другого радиус-вектора с произведением второй координаты первого радиус-вектора на вторую координату другого радиус-вектора с произведением третьей координаты первого радиус-вектора с третьей координатой другого радиус-вектора равна произведению длины первого радиус-вектора на длину другого радиус-вектора на косинус угла между одним и другим радиус-вектором.

Подозреваю, что после записи второго выражения из доказательства вы скажете «да пошло оно всё» и забьёте.

Попробуйте текстом записать нахождение решения…

Для математиков доказательство существования и единственности решения – почти навязчивая идея. А все остальные человеки используют мат.аппарат, как инструмент для решения своих задач, причём большинство формул уже записаны в библиотеки ЯП с текстовыми комментариями. Поэтому записать текстом нахождение решения в принципе можно, но ненужно.

вы скажете «да пошло оно всё» и забьёте.

Нет, напишу текстовое ТЗ и отдам профессиональному математику, пущай думает :)

А все остальные человеки используют мат.аппарат,…

…разработанный математиками с навязчивыми идеями, иначе будет как в короткометражке про "2 + 2 = 22".

Поэтому записать текстом нахождение решения в принципе можно

Можно. Я просто ради того, чтобы вы прониклись тем, что знаковая математическая нотация – высшее благо для науки.

напишу текстовое ТЗ и отдам профессиональному математику,

Профессиональный математик умный, он даже не возьмётся. Если только вы не предложите ему за то годовую зарплату.

иначе будет как в короткометражке про «2 + 2 = 22».

Хороший пример зависимости результата от контекста, правильный, если «+» перегружен как конкатенация.
А в общем случае понять суть компонентов формул без текстовых комментариев невозможно.
Текст – неявная основа любой формулы.

прониклись тем, что знаковая математическая нотация – высшее благо для науки.

Дык, это «благо» пока ЧатГоПоТу не научат понимать смысл слов человечьих, а опосля мат. нотация станет ненужным слоем абстракции.

Профессиональный математик умный, он даже не возьмётся. Если только вы не предложите ему за то годовую зарплату.

У меня был случай, когда пришлось словами объяснять профессиональному математику машиностроительный чертёж сложной поверхности (типа задачи Дирихле для уравнения Пуассона): он всё понял без формул и решил ~ за месяц, до корректно работающей программы.