Книги по основам символьных вычислений, баз знаний и CAL

[ponyatov]

Кто может посоветовать книги [en/ru] по основам реализации систем типа Wolfram Alpha ?

Интересует не столько реализация символьной математики, сколько представление и обработка знаний (индексированный поиск, символьные вычисления, мета- и трансформаторное программирование, формирование интерактивных учебных курсов для computer assisted learning)

[iifat]

По ссылке, вообще-то, не «трансформаторное программирование», а «преобразование программ».

[Eimrine]

ponyatov в сообщении #1152104 писал(а):

книги [en/ru] по основам реализации систем типа Wolfram Alpha ?

На правах дилетанта рекомендую начать с Lisp. Вне зависимости от выбранной вами книги и реализации, вы получите самый мощный ЯП, который, по всей видимости, является ядром Вольфрамовской мощи.

ponyatov в сообщении #1152104 писал(а):

формирование интерактивных учебных курсов для computer assisted learning

[arseniiv]

Eimrine в сообщении #1152230 писал(а):

который, по всей видимости, является ядром Вольфрамовской мощи

Они утверждают, что ядро Альфы — это Mathematica. Стиль вычислений у неё не очень-то как у лиспа, если не сводить его к одним макросам.

[Eimrine]

arseniiv, https://news.ycombinator.com/item?id=9799154

[arseniiv]

Спасибо. Правда, там для меня новы разве что исторические подробности и SMP. Но только непонятно, что вы хотели сказать. Если то, что M. написана на лиспе — это вряд ли; что её можно называть расширением или аналогом лиспа — опять же, вряд ли, потому что тогда надо будет связать с лиспом целую кучу вещей, которую обычно с ним не связывают.

[Eimrine]

Во-первых там в конце содержится популярное, но вовсе не глупое утверждение, что такую программу невозможно сделать на чём-то отличном от символьных вычислений. Во-вторых, сам Стивен, как я узнал из ссылки на его блог, много писал на Lisp. В третьих, как я узнал по pdf вырезке из его же книги, L. и M. на фундаментальном уровне есть одно и то же - символьные вычисления, основная разница - в деталях реализации модели вычислений. Вообще-то мне нечего добавить. Разве что SICP посоветовать ТС-у, как самую толстую книгу по теме.

[arseniiv]

Eimrine в сообщении #1152457 писал(а):

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

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

Eimrine в сообщении #1152457 писал(а):

Во-вторых, сам Стивен, как я узнал из ссылки на его блог, много писал на Lisp.

Ничто не мешает человеку программировать не на одном и том же языке.

Eimrine в сообщении #1152457 писал(а):

В третьих, как я узнал по pdf вырезке из его же книги, L. и M. на фундаментальном уровне есть одно и то же - символьные вычисления, основная разница - в деталях реализации модели вычислений.

Да, а человек и гаечный ключ тоже на фундаментальном уровне одно и то же — некое собрание молекул. Основная разница всего-то в доле атомов металлов, чего скрывать. Прекрасный факт, и главное, так много новых выводов дающий!

-- Пн сен 19, 2016 00:44:23 --

Eimrine в сообщении #1152457 писал(а):

Вообще-то мне нечего добавить.

Ну так silentium est aurum. Если бы не всякий (полу)оффтопик, в этой теме вместе с авторским было бы всего два поста, а сейчас в 4,5 раза больше.

[Eimrine]

arseniiv в сообщении #1152467 писал(а):

На любом языке можно написать интерпретатор лиспа

Скажу даже больше: каждая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp, согласно десятому правилу Гринспена.

arseniiv в сообщении #1152467 писал(а):

Ничто не мешает человеку программировать не на одном и том же языке.

Я просто сошлюсь на парадокс Блаба: By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. Поэтому, программист, знающий самый мощный ЯП, навсегда останется просветлённым, даже во время программирования на других ЯП а программист, не знающий его - нет. Аргументация, почему Лисп - самый мощный ЯП есть в других статьях Paul Graham, например, "Beating the Averages".

arseniiv в сообщении #1152467 писал(а):

человек и гаечный ключ тоже на фундаментальном уровне одно и то же — некое собрание молекул [...] чего скрывать.

У вас тут скрыт контекст: я не понимаю, чем мне сейчас может пригодиться такое сравнение. Если человек хочет написать аналог М., то безусловно, в порядке абсурда, можно посоветовать книгу о каких-нибудь пластиках, из которых состоит клавиатура, которой он будет набирать код, но это никак не приведёт его к результату. А книга о ключевых концепциях программирования, некоторые из которых оказались фундаментальными для разработки (а то и для возможности существования) программы, упомянутой ТС-ом мне кажется настолько подходящей вопросу, что я думаю, оригинальности в моём совете исчезающе мало.

arseniiv в сообщении #1152467 писал(а):

silentium est aurum

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

[arseniiv]

Eimrine в сообщении #1152489 писал(а):

согласно десятому правилу Гринспена

Так и знал, что вы о нём слышали. Тогда мне совершенно непонятен ход мыслей до.

Eimrine в сообщении #1152489 писал(а):

Я просто сошлюсь на парадокс Блаба:

Мне кажется, или совершенно не в кассу? Вы исходите из того, что Грэм прав, и что пресуппозиции всей этой ерунды вообще верны, и языки линейно упорядочены по относительной мощности. Позвольте не принимать таких сильных постулатов. Если человек пишет на лиспе (кстати, Грэм говорил только про Common Lisp, а потом сменил мнение на Clojure, не? ), он всё-таки не обязан никому (и себе) писать только на лиспе. Производительность переписанного на другом языке участка кода может быть выше оптимизированного кода на исходном. Можно найти много случаев, для которого от ядра такой СКА как Mathematica потребуется наибольшая доступная производительность.

Eimrine в сообщении #1152489 писал(а):

У вас тут скрыт контекст: я не понимаю, чем мне сейчас может пригодиться такое сравнение.

У меня скрыт контекст знания конкретных отличий некоторых диалектов лиспа, о которых я имею представление, и Wolfram (как теперь некоторое время зовётся язык из Mathematica ). И к такому детальному представлению ваше сравнение ничего не добавляет. Вы говорите о схожести M. и лиспа, но не говорите об их различиях, и о спектре различий языков, которые называют диалектами лиспа.

Eimrine в сообщении #1152489 писал(а):

А книга о ключевых концепциях программирования, некоторые из которых оказались фундаментальными для разработки (а то и для возможности существования) программы, упомянутой ТС-ом мне кажется настолько подходящей вопросу, что я думаю, оригинальности в моём совете исчезающе мало.

Заметьте, я ваш совет почитать SICP вообще не обсуждал ни разу. Я про непродуктивное сравнение (см. выше).

В общем, явное лучше неявного, точное лучше обтекаемого etc.. Абстрактный лисп в вакууме — ещё не формула успеха.

-- Пн сен 19, 2016 03:00:04 --

arseniiv в сообщении #1152523 писал(а):

конкретных отличий

Которые в той PDF по вашей ссылке есть. Даже тех достаточно. Придётся на одном лиспе писать другой «лисп» с весьма многомудрым pattern matching’ом и вот тем потенциально бесконечным применением правил переписывания.

[Eimrine]

arseniiv в сообщении #1152523 писал(а):

Если человек пишет на лиспе (кстати, Грэм говорил только про Common Lisp, а потом сменил мнение на Clojure, не? ), он всё-таки не обязан никому (и себе) писать только на лиспе. Производительность переписанного на другом языке участка кода может быть выше оптимизированного кода на исходном

Эти языки, насколько я понимаю мнение Грэма, одинаковой силы. Вы говорите о производительности, но вы ведь не можете не знать цитату про тупой код и умные структуры данных, не говоря уж о цитате про корень всех зол. Производительность для pet-project, которому не ставится сходу цели стать популярным, совершенно не важна и знание трюков оптимизации поможет писать код продуктивно не больше, чем понимание тонкостей работы TFT-монитора. Продуктивный код пускай делает аутсорс.

arseniiv в сообщении #1152523 писал(а):

Вы говорите о схожести M. и лиспа, но не говорите об их различиях, и о спектре различий языков, которые называют диалектами лиспа.

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

arseniiv в сообщении #1152523 писал(а):

Заметьте, я ваш совет почитать SICP вообще не обсуждал ни разу.

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

arseniiv в сообщении #1152523 писал(а):

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

Скорее дискретно, чем линейно. Вы разве не слышали об этой задаче? Её решение близко к элементарному на языке с рекурсией и близко к невозможному без реализации Лиспа. Я вот как представлю себе ООП реализацию Number, который (как я себе представляю) может быть и Float-ом, и Rational-ом, меня аж передёргивает от всего того полиморфизма, который нужно реализовать, и насколько я знаю, в Джаве нет такой реализации аккумулятора Number-ов, её просто не осилили (слышал, в новой появились лямбды - должно быть, теперь это можно сделать без труда).
As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators-- a function that takes a number n, and returns a function that takes another number i and returns n incremented by i. (That's incremented by, not plus. An accumulator has to accumulate.)In Common Lisp this would be

Используется синтаксис Lisp

(defun foo (n)
  (lambda (i) (incf n i)))

arseniiv в сообщении #1152523 писал(а):

Придётся на одном лиспе писать другой «лисп»

На программируемом языке программирования писать программируемый язык программирования, вы серьёзно? Если есть крутой pet-project, на лиспе, что-то вроде пре-альфа-бета версии М., то можно просто позвать негров, чтобы запилили более подходящую публичному сервису выч. модель, а самому дальше продолжать писать на том же лиспе, что и раньше, разве что нужно залочить для ЦА небезопасные фичи языка. А если есть знание системного ЯП, то... возможностей выдать миру что-то вроде M. поменьше всё-таки. Это не значит, что его не нужно знать, но это значит, что лисп-хакеру будет непродуктивно расфокусировывать своё внимание на детали реализации текущего поколения процессоров и прочие вопросы, которые в идеале должен решать компилятор.

[arseniiv]

(Оффтоп)

Eimrine в сообщении #1152565 писал(а):

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

Прекрасно, но не надо мыслить одними цитатами. Нет ни одной цитаты, область применимости которой была бы безграничной. А premature optimisation я не предлагал. Я предлагал оптимизировать тогда и там, где нужно. Всё-таки есть и количественные величины. Иногда 1 с может быть приемлема, а 2 с привести к ну, грубо говоря, убийству.

Eimrine в сообщении #1152565 писал(а):

и знание трюков оптимизации поможет писать код продуктивно не больше, чем понимание тонкостей работы TFT-монитора

Я не говорю про трюки оптимизации, ё-моё. Я говорю о среднем быстродействии программ, написанных на разных языках и скомпилированных разными компиляторами.

Eimrine в сообщении #1152565 писал(а):

Продуктивный код пускай делает аутсорс.

Какие крайности.

Eimrine в сообщении #1152565 писал(а):

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

Так не, я и говорю, что совет про SICP неплох. Ну общий, да. Но хотя бы не сомнительный.

Eimrine в сообщении #1152565 писал(а):

Скорее дискретно, чем линейно. Вы разве не слышали об этой задаче? Её решение близко к элементарному на языке с рекурсией и близко к невозможному без реализации Лиспа. Я вот как представлю себе ООП реализацию Number, который (как я себе представляю) может быть и Float-ом, и Rational-ом, меня аж передёргивает от всего того полиморфизма, который нужно реализовать, и насколько я знаю, в Джаве нет такой реализации аккумулятора Number-ов, её просто не осилили (слышал, в новой появились лямбды - должно быть, теперь это можно сделать без труда).

Да, и только один CL (и, как мы узнали, эквивалентная по постановлению свыше Closure) так умеет! Хаскель (ФП, типоклассы) не сможет, цейлон (ООП, интерфейсы) не сможет, только CL с мультиметодами! Мне уже не смешно. А вам? Тысячи языков, из них широко известно не так много. И пусть, скажем, 99% из них эзотерические или устаревшие, останется немало. Но только лисп на вершине, толко он всё похволяет разрабатывать, поддерживать, документировать etc. код самым лучшим способом! Да!

Eimrine в сообщении #1152565 писал(а):

которые в идеале должен решать компилятор

Вот кстати компиляторы тоже кто-то пишет. Давайте все компиляторы писать на лиспе. Они будут такие крутые, только вот… ну…

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

А раз я понял, не ожидайте от меня на эту тему дополнений. Потом, кому нужны уточнения, когда главная идея верна, правда?

[Eimrine]

arseniiv в сообщении #1152575 писал(а):

Я говорю о среднем быстродействии программ, написанных на разных языках и скомпилированных разными компиляторами.

Вот только кого оно волнует, кроме держателей компьютерных мощностей, на которых эта программа будет выполнятся? Точно не программиста, пытающегося как можно скорее запилить proof of concept.

(Оффтоп)

arseniiv в сообщении #1152575 писал(а):

Нет ни одной цитаты, область применимости которой была бы безграничной.

Теперь есть, я даже процитировал её.

arseniiv в сообщении #1152575 писал(а):

Хаскель (ФП, типоклассы) не сможет

Используется синтаксис Haskell

import IOExts
                      foo n = do
                        r <- newIORef n
                        return &#40;\i -> do
                          modifyIORef r &#40;+i&#41;
                          readIORef r&#41;

arseniiv в сообщении #1152575 писал(а):

Они будут такие крутые, только вот… ну…

Да, вы правы, компилятор языка X всё-таки принято писать на X в качестве доказательства состоятельности языка Х.

[iifat]

Eimrine в сообщении #1152230 писал(а):

На правах дилетанта рекомендую начать с Lisp

Никогда не понимал этого веяния. Не, против Lisp ничего не имею, но вот эта уверенность, что стоит только изучить его — и тут же из-под пера программиста начнут выходить исключительно системы искусственного интеллекта... Не, не понять мне этих людей.

[arseniiv]

(Оффтоп)

Eimrine в сообщении #1152584 писал(а):

Точно не программиста, пытающегося как можно скорее запилить proof of concept.

А никто не сказал, что proof of concept. Более того, они бывают разной детализации.

Eimrine в сообщении #1152584 писал(а):

Теперь есть, я даже процитировал её.

Ну-ну, давайте поиграем в металогику. Я имел в виду цитаты, не говорящие о цитатах, а говорящие притом о весьма конкретных и человекозависимых вещах.

А код на хаскеле вы привели, потому что не поняли, что это был сарказм. Более того, привели код сразу с монадой IO, когда можно было обойтись аккуратнее и использовать State или ST.

Eimrine в сообщении #1152584 писал(а):

Да, вы правы, компилятор языка X всё-таки принято писать на X в качестве доказательства состоятельности языка Х.

Я не имел в виду этого. Я имел в виду снова производительность. Снова ровно там, где надо, а не везде подряд.