> Тебя никто не заставляет этим пользоваться. Можешь писать в чисто
> функциональном стиле.

КАК? Переменные все равно глобальные. И б...ский dynamic scoping тоже
никак не выключишь. И типизацию не прикрутишь.

> Ну как сказать. Что в maxime, что в axiom - "нормальная инфиксная нотация",
> хоть и писаны они на lisp'е.

В maxime можно напрямую пользовать LISP. :lisp -- и вперед, с песней. Аналогично
с axiom. К сожалению, не совсем (совсем не?) стандартный LISP, но это лучше, чем
ничего.

> Так что лучше спросить опять-таки автора этих слов, что он имел в виду, говоря про
> "недоязычок".

Еще раз повторить? Глобальные переменные (все!), динамическая область видимости,
отсутствие типизации, придурковатая семантика (чем отличается a := 1; a = 1),
угребищный синтаксис (даже sed -- и тот не такой дурной).

> И б...ский dynamic scoping тоже никак не выключишь.

В сад.

2.7.7 Blocks Compared with Modules

One of the main ways to ensure that different parts of a program do not interfere is to give their variables only a certain scope. Mathematica provides two basic mechanisms for limiting the scope of variables: modules and blocks.

In writing actual programs, modules are far more common than blocks. When scoping is needed in interactive calculations, however, blocks are often convenient.

Module[vars, body] — lexical scoping

Block[vars, body] — dynamic scoping

> И типизацию не прикрутишь.

Обратно в сад.

2.3.4 Specifying Types of Expression in Patterns

You can tell a lot about what type of expression something is by looking at its head. Thus, for example, an integer has head Integer, while a list has head List.

In a pattern, _h and x_h represent expressions that are constrained to have head h. Thus, for example, _Integer represents any integer, while _List represents any list.

Именно что в сад!

> Module[vars, body] lexical scoping

Фига там.

jmath:$ Module[{x, y}, a = x+y;];
jmath:$ a
jmath:$ x$1 + y$1

В сад с таким lexical scoping.

ох, сами же напросились!

> You can tell a lot about what type of expression something is by looking
> at its head.

Угу, а как с помощью такой "типизации" проверить, что выражение -- многочлен
от одной переменной? Рациональная функция?

> In a pattern, _h and x_h represent expressions that are constrained to
> have head h. Thus, for example, _Integer represents any integer, while
> _List represents any list.

А какого типа прелесть вида x + {a, b, c}?

> Фига там.

Правильно, надо так:

Mathematica 5.2 for Linux x86 (64 bit)
Copyright 1988-2005 Wolfram Research, Inc.

In[1]:= Module[{a,x,y}, a=x+y]

Out[1]= x$14 + y$14

In[2]:= a

Out[2]= a

Или ты что-то другое хотел получить? :)

Ну я согласен, несколько через жопу сделано, но каким боком тебе
это может помешать, если не использовать символ $ в именах?

> Угу, а как с помощью такой "типизации" проверить, что выражение -- многочлен от одной переменной? Рациональная функция?

Почитай мануал, там про pattern matching целая глава. Или ты как школьник, любишь, когда тебе умный дядя всё пересказывает простым языком? :P

> Я этот TeXmacs еще году в 2002 пробовал как редактор для LaTeX - тогда же больше про него не вспоминал, думал что то изменилось - но он все такой же корявый (для меня).

Это ни разу не редактор LaTeX - даже близко не.

> про 70 летних - всех гнтаь надо - ничего они уже не двигают, я как вспомню как попал на заседание секции в РАН - так до сих пор передёргивает: половина в маразме, половина думает как бы побольше денег украсть.

Телепат? Кроме того в изначальной фразе присутсвовали не только 70летние.

Люди - очень разные звери. Не надо думать что всё видел и всё знаешь.

>Ну вот. Я музыкант. И диски записываю. Ничем, кроме Linux и GNU софта не пользуюсь. Что я делаю не так?

Каким именно софтом пользуешся?

З.Ы.: музыкант... и тоже пользуюсь сугубо Linux и GNU софтом...

> Axiom, Maxima, и M..... -- таки вполне сравнимые вещи.

:-)

> Дык ведь ежу понятно, что GiNaC is Not A CAS, какой же он конкурент?

:-) А я конкретно тебя и имел в виду! :-) (Правда, двухлетней выдержки... Некто мне пару лет назад на полном серьезе заливал, что всю алгебру надо делать на ЦеПП с помощью Гинака!)

Да ладно вам спорить. Maxima всё равно рулит - это факт, против которого никто тут не попрёт.

GNU <TeXmacs> is a free wysiwyw (what you see is what you want) editing platform with special features for scientists. ниже по тексту про конверторы в Латех. Вот как готовить документы в Латехе - также неудобно и работать с maxima.

Дальше оффтоп: Не надо быть телепатом: в институте, где я работал достаточно акадэмиков, те кому 70 - уже ничего не публикуют - занимаются исключительно хобби, (сад/огород, литература), те кто моложе - смотрим в базу ISI - и средний зав лаб второсортного универа затыкает этих акадэмиков за пояс. А уж как Осипов борется за свой пост - так смешнее придумать нельзя, думает в могилу его, наверное, забрать. В виду того, что большей частью научного процесса заправляет РАН - можно сделать простой вывод - никто ничего никуда не двигает. Есть исключения - они лишь подтверждают мое мнение. К примеру, в Казанском физтехе и универе несколько иначе, есть академик Фортов, который занимается исследованиями, ну кто то еще - но в целом положение настолько удручающее - что проще всех разогнать.

> что проще всех разогнать.

Это пример неправильного простого решения.

Долгая память хуже сифилиса

> > Module[{x, y}, a = x+y; ];
> > a

> Правильно, надо так:

> In[1]:= Module[{a,x,y}, a=x+y]


Вещи должны называться своими именами. Сказано "lexical scope" -- значит он
таки и должен быть. А то, что у них -- это караул какой-то.

А его нужно устраивать руками.
Во-вторых, в моем примере я хотел бы получить compile error :)

> Или ты что-то другое хотел получить? :)

Что-нибудь в таком духе:

(let ((x 1) (y 2)) (set! a (+ x y)))

Backtrace:
In current input:
3: 0* (let ((x 1) (y 2)) (set! a (+ x y)))
3: 1 (set! a (+ x y))

<unnamed port>:3:20: In expression (set! a (+ x y)):
<unnamed port>:3:20: Unbound variable: a
ABORT: (unbound-variable)


> Out[1]= x$14 + y$14

> Ну я согласен, несколько через жопу сделано, но каким боком тебе
> это может помешать, если не использовать символ $ в именах?

Таким, что совершенно неожиданным образом у меня появилась глобальная
переменная. Надо объяснять, чем это грозит?

> Некто мне пару лет назад на полном серьезе заливал, что всю алгебру
> надо делать на ЦеПП с помощью Гинака!)

Во-первых, речь шла о не о "всей алгебре", а именно о рассчетах в pQFT.
А во-вторых, утверждение было, что:

1. Нефиг изобретать заведомо убогих языков программирования, надо пользовать
те, что есть. Во-первых, сделать нормальный язык -- крайне тяжко. Во-вторых,
тот самый wall clock performance -- жизнь слишком короткая, чтоб изучать
всякие недоязыки.

И на самом деле, эта идея живет и здравствует, потому как

Reduce -- LISP библиотека
Axiom -- LISP библиотека
Maxima -- LISP библиотека
PARI/GP -- C библиотека
Singular -- C++ библиотека
Giac -- C++ библиотека
...

2. К сожалению, многие CAS, как свободные, так и коммерческие, весьма
убого работают с памятью. До такой степени, что практически любой "жизненный"
рассчетов захлебывается. Maintainer'ам на это плевать, а потому народ
изворачивается, как может.

еще про типизацию

> Почитай мануал, там про pattern matching целая глава.

Сам факт того, что для определения _типа_ выражения нужны какие-то
нетривиальные действия, говорит о том, что типизации в языке нет.
А за использование для этого pattern matching (который как минимум NP
complete) нужно отправлять в принудительном порядке в психиатрическую
клинику -- чтоб мозги вправили.

> Сам факт того, что для определения _типа_ выражения нужны какие-то нетривиальные действия, говорит о том, что типизации в языке нет.

Да есть она там.

In[1]:= Head[42]

Out[1]= Integer

In[2]:= Head[{1,2,3}]

Out[2]= List

In[3]:= Head[Head]

Out[3]= Symbol

Ты лучше объясни мне, определять типы для тебя самоцель? Приведи пример жизненной задачи, которая тяжело решается на Математике, но легко решается на твоём любимом языке.

> Да есть она там.

Нету:

In[1]:= Head[x+x^2]
Out[1]=
Plus
In[2]:= Head[Cos[y]+Exp[x]]
Out[2]=
Plus

Что многочлен, что трансцендентное выражение -- а все Plus.

> Ты лучше объясни мне, определять типы для тебя самоцель?

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

> Приведи пример жизненной задачи, которая тяжело решается на Математике,

Все, что сложнее hello world.

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

Пытался седня осилить максиму. Подскажите, как в ней посчитать выражение в комплексных числах? Полчаса курил мануал, добился тока вывода самого выражения. Как сделать чтобы выводило ответ, т.е. просто комплексное число?

> Все, что сложнее hello world.

Спасибо, слив засчитан.

> Во-первых, речь шла о не о "всей алгебре", а именно о рассчетах pQFT.

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

Второе -- ну, давай сравним, сколько рассчетов в pQFT выполнено на Математике с Формом, а сколько -- на ЦеПП, Редьюсе и всем остальном, вместе взятом?

> 1. Нефиг изобретать заведомо убогих языков программирования, надо пользовать те, что есть. Во-первых, сделать нормальный язык -- крайне тяжко. Во-вторых, тот самый wall clock performance -- жизнь слишком короткая, чтоб изучать всякие недоязыки.

Золотые слова!

А теперь сравним, кто появился раньше -- ЦеПП (с Гинаком ;) ) или Скунсшип?

И на чем был Минцер написан!

И где сейчас один из его главных авторов, отказавшихся от Форма с пользу кошерного пути в лице Вирта?

:)))

> Второе -- ну, давай сравним, сколько рассчетов в pQFT выполнено на Математике

Ноль целых фиг десятых. В лучшем случае на ней пишут красивую обертку к
FORM'овскому или C'шному коду.

> с Формом,

Таки да, много. Но убог он, как по функциональности, так и семантика у него
[sensored] несколько странная, мягко говоря.

> а сколько -- на ЦеПП, Редьюсе и всем остальном, вместе взятом?

> И на чем был Минцер написан!

Опять же -- с горя. В те времена не на чем его было больше написать. Ткачову
пришлось бы с нуля писать свою CAS (чем он сейчас, кстати, и занялся), причем
ни GMP, ни mpfr|CLN тогда не было, так что неблагодарной работы _дохренищи_
пришлось бы делать.


> И где сейчас один из его главных авторов, отказавшихся от Форма с пользу
> кошерного пути в лице Вирта?

Мало какой рассчет не использует его методы, так что он всюду :)

> А теперь сравним, кто появился раньше -- ЦеПП (с Гинаком ;) ) или Скунсшип?

LISP (с Максимой) :)

> Во-первых, там как-раз рачь шла о математике вообще

Как ни странно, математики таки используют GiNaC. (см. AUTHORS).

>> А теперь сравним, кто появился раньше -- ЦеПП (с Гинаком ;) ) или Скунсшип?

> LISP (с Максимой) :)

:-)))

Maxima стартовала в 1998 году как свободный клон Macsyma

Macsyma стартовала в МИТе в 1968 году.

А первый препринт Вельтмана по SCHOONSHIP датирован 1967 годом! К тому времени он уже много посчитал на нем, кстати.

> Как ни странно, математики таки используют GiNaC. (см. AUTHORS).

Дык, кто ж спорит-то! Его многие используют, и в pQFT тоже!

Просто кол-во результатов, полученных в pQFT с помощью связки Математика+Форм(+Редьюс еще немного, пожалуй) на порядки превышает все, что было посчитано с использованием прочего софта.

> > LISP (с Максимой) :)

> Maxima стартовала в 1998 году как свободный клон Macsyma

Я имел в виду именно Macsyma.

> Macsyma стартовала в МИТе в 1968 году.

Стартовала? Или уже была работоспособная версия?

> А первый препринт Вельтмана по SCHOONSHIP датирован 1967 годом!

Дык возможности у него куда боле куцые (до сих пор GCD считать не умеет).

> Стартовала? Или уже была работоспособная версия?

Насколько я знаю, именно СТАРТОВАЛА! Работоспособная версия появилась несколько лет спустя -- впрочем, я не уверен.

> Дык возможности у него куда боле куцые

Дык, что понимать под словом "возможности"!

Разумеется, он мало что умел в смысле алгебры -- но он с самого начала не был ограничен размером оперативной памяти!

> (до сих пор GCD считать не умеет).

ФОРМ уже несколько лет, как умеет! Просто это было заявлено как "экспериментальная фича", но сейчас оно, типа, считается стабильным (насколько все "оно" вообще может быть рассмотрено как "стабильное" :) )

> > (до сих пор GCD считать не умеет).

> ФОРМ уже несколько лет, как умеет!

О чудо! Не прошло и 50-ти лет! Еще лет через 50 его отучат, может быть,
раскрывать выражения, когда его об этом никто не просит. А там, глядишь,
и от собственного убого недоязычка откажутся, и сделают из его C'шную
библиотеку.

Интересно -- сами велосипед изобретали, или взяли что-то готовое?

> но сейчас оно, типа, считается стабильным (насколько все "оно" вообще может
> быть рассмотрено как "стабильное" :) )

Отож.

> Разумеется, он мало что умел в смысле алгебры -- но он с самого начала
> не был ограничен размером оперативной памяти!

1. Угребищная семантика -- слишком большая цена за это.

2. В те времена, когда компьютеры были большими, а адресное пространство
маленьким, это действительно было очень важно. А сейчас оно 64-битное,
и если и туда данные не влазят -- надо срочно выпрямлять руки.

> Угребищная семантика -- слишком большая цена за это.

:-)

Фор хум хау!

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

Математика мне нравится, на типизацию мне как-то начихать. Если бы еще из ее языка боком притянутую функциональщину (типа Module[{c},If[a<b,c =a,c=b];c]) повыгнать, совсем здОрово было бы!

> ...когда компьютеры были большими, а адресное пространство маленьким, это действительно было очень важно. А сейчас оно 64-битное, ...

Пространства - то хватает, вот только памяти всегда мало!

> А сейчас оно 64-битное, и если и туда данные не влазят -- надо срочно выпрямлять руки.

Очень сильное утверждение! Оказывается, все рекордные вычисления в pQFT последних лет сделаны индивидуумами с кривыми руками!

:-)

> ...сами велосипед изобретали, или взяли что-то готовое?

Полиномы -- Евклидом (очень даже неплохо работает, как ни странно!), а целые -- Йос сам изобрел. Мы поискали немного, но такого алгоритма в литературе не нашли -- ну и хрен с ним, никто его публиковать не собирается.

Очень шустрый!

ФОРМ заточен под pQFT, и типичные целые числа редко бывают длиннее 100-200 циферок, и вставка эвристики себя не оправдывает. Две ветки, короткая -- Евклид, все, что длиннее -- Йосовский алгоритм.

Конечно, никто не говорит, что оно работает оптимально, но работает.

> Полиномы -- Евклидом (очень даже неплохо работает, как ни странно!),

Я тоже так думал когда-то. :) А оказалось, что на реалистичных задачах
работает крайне тормозно и непредсказуемо. Особенно если многочлены
взаимно простые. Ну -- по сравнению с тем, что вообще ничего, оно-то
конечно да.

> а целые -- Йос сам изобрел.

Упертый дядечка. Вон даже поганые коммерсанты (Mathematica, Maple) -- и те
перестали изобретать велосипеды и пользуют себе GMP и MPFR.

> Мы поискали немного, но такого алгоритма в литературе не нашли

Может, люди стыдылись такое публиковать?

> ФОРМ заточен под pQFT, и типичные целые числа редко бывают длиннее
> 100-200 циферок,

Типичные целые числа ЛЕГКО зашкаливают за эти 100-200 циферок, как раз таки
при счете GCD (> 15 переменных), и в разложениях спец. функций
(гипергеометрических).

> и вставка эвристики себя не оправдывает.

Не только оправдывает, без нее -- вообще никак.

> Две ветки, короткая -- Евклид, все, что длиннее -- Йосовский алгоритм.

Подкинуть пару многочленов на пробу? Интересно -- задавится или нет...
Axiom -- задавился. Maxima -- задавилась. Mathematica (4.0) -- _сильно_
долго думала.

> на типизацию мне как-то начихать.

Я не хочу ничего плохого сказать, но кого там работа любит? Нравится
отлавливать _тривиальные_ ошибки вручную -- вперед. А меня это уже
порядком за^W достало, пускай таки этим занимается компилятор.

> Очень сильное утверждение! Оказывается, все рекордные вычисления в pQFT
> последних лет сделаны индивидуумами с кривыми руками!

Обсуждение плавно перешло к вопросу "а у кого длиннее"...

> Большинству людей именно семантика Лиспа кажется угребищной.

Кому конкретно? И сколько из этого "большинства" хоть чего-нибудь соображет
в том, о чем берется рассуждать? 0.1%? 0.01%?

Возвращаясь к FORM'у -- я еще ни одного человека не видел, который бы
хотя бы приблизительно понимал, что делает программа, которую он пишет.
"Если тут не поставить .sort, будет неправильный ответ, поэтому ставим
.sort после любого действия". Это шаманские танцы...

> Если бы еще из ее языка боком притянутую функциональщину

Она там не боком, она там совершенно естественно.

> (типа Module[{c},If[a<b,c =a,c=b];c]) повыгнать, совсем здОрово было бы!

А кто ж мешает -- вперед :)

> Конечно, я понимаю, лисперы считают, что большинство людей -- дебилы и уроды...

А оно по жизни так и есть. :(

> Подкинуть пару многочленов на пробу?

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

Уверяю, в вящей производительности Гинака ВСЕ заинтересованы!

> Упертый дядечка. ...

Да, есть такая проблема.

> Вон даже поганые коммерсанты (Mathematica, Maple) -- и те перестали изобретать велосипеды и пользуют себе GMP и MPFR.

Факт -- на типичных числах ФОРМ работает БЫСТРЕЕ GMP (хоть и не раз подчеркивалось, что целая арифметика не есть конек ФОРМа!)

Еще факт -- GMP весьма шустра на ЦЕЛЫХ, но имеет некоторые проблемы с рациональными (глупые и исправимые не выходя за рамки кастом аллокаторов -- тем не мение).

>> ФОРМ заточен под pQFT, и типичные целые числа редко бывают длиннее 100-200 циферок,

> Типичные целые числа ЛЕГКО зашкаливают за эти 100-200 циферок, как раз таки при счете GCD (> 15 переменных), и в разложениях спец. функций (гипергеометрических).

Насколько я понял, речь идет про скоростное суммирование и PCLQ -- уверяю, там Гинак ПРОСТО не имеет шансов, как и все прочие точные алгебраические системы. Там применяются СОВСЕМ другие методы. Дядя Бродхарст, скушавший на этом собаку, пользует Редьюс и Фортран.

>> Большинству людей именно семантика Лиспа кажется угребищной.

>Кому конкретно?

:-) Мне! :-)

Кстати, Лисп -- один из первых языков, с которым я познакомился. Я от него перся года 1.5 (он был у меня третьим, после Фортана и Паскаля, Васик я не считаю). Но это было задолго до Бессмертных Трудов Пола Грэхэма (да воздаст ему Аллах за его Заслуги перед Истинной Парадигмой)! Увы, мой личный опыт немного старше Бессмертной Библии Лисперов...

От ООП я перся, правда, дольше -- лет 5, наверное... Конечно, я не претендую на критику ЦеПП и Страуструпа Пророка Его, но, слава Богу, опять же, удосужился ознакомиться на практике с основами несколько ранее тотального проникновения в души неверных сего Справедливого Учения...

Слава Богу, начинал я с классических (ныне забытых) наук!

:-)))

> Очень сильное утверждение! Оказывается, все рекордные вычисления в pQFT
> последних лет сделаны индивидуумами с кривыми руками!

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

Тем временем математики проблему успешно решили. Вычисление делается не
в кольце Z[X][Y]..., а в его гомоморфном образе в конечном поле (как правило, Z/p),
и по ряду таких гомоморфных образов восстанавливается выражение в Z[X]. Поскольку
поле таки конечное, то и все коеффициенты заведомо ограничены, и памяти таким
алгоритмам нужно _гораздо_ меньше.

Отсюда и исходное утверждение.

Да, когда-нибудь, наверное, даже автор FORM'а дойдет до этих вещей. Но стоит
ли самому наступать на все грабли, которые только могут быть?

> на типизацию мне как-то начихать.

Хочется узнать, почему отсутствие типизации -- зло, можно полазить по исходникам
GiNaC'а (у которого тоже весьма ублюдочная динамическая типизация).

Угу, стоял у меня как-то... крякнутый. Ничего, работать можно, только imho не то...

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

LoL!

Последние 10 лет физики только этим и занимаются. И математику они хорошо знают, уверяю.

А проблема не столько в коэффициентах, сколько в рекуррентных цепочках.

Есть такая штука -- алгебры Ора называется -- борьба идет за разрешение рекуррентных соотношений, но пока неудачно. Есть метод Байкова, там много чего строго доказано, но соотношения удается разрешить только в пределе d->бесконечности. Тем не менее, работает (требуется параллельный ФОРМ и суперкомпьютеры).

Есть базисы Гребнера -- к сожалению, математики пока сливают, но физики кое-как научились это делать. Дифференциальный базис Гребнера развивается Тарасовым (там ДЕЙСТВИТЕЛЬНО есть проблемы с коеффициентами, конкретно -- с Грамм- детерминантами), а Смирновы соорудили свой "S-базис", и оно совершенно неплохо работает, но требует очень много "рукоблудия" (реализовано оно на Математике, кстати).

Немного смешно слышать про то, что физики не в ладах с математикой -- уверяю, физики как раз ОЧЕНЬ хорошо с математикой знакомы!