Ответы для темы «Почему Go это плохо....»

А реальность следующая:

Лавсан, ну вы опять серите, вам не надоело? Негоже виндовому программисту пытаться рассказывать на Линукс форуме о реальности.

CL - наиболее практичный, доступный и развитый из всех трех, с самыми навороченными компиляторами, с кучей библиотек, включая доступ к дотнету (а в коммерческих реализациях или в ABCL - и к Java тоже), и вообще чему угодно.

Который не соответствует стандарту IEEE-754, из-за чего у него проблемы с интеграцией с другими языками, например с тем же дотнетом под Linux.

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

Объясняю проблему на пальцах.

Языки которые прямо поддерживают операции числа с плавающей точкой одинарной и двойной точности стандарта IEEE-754 из коробки: C, C++, C#, Fortran, Java, JavaScript, Python, R, Julia, PHP, Go, Swift, Kotlin, Forth и тд.

Языки которые не поддерживают числа с с плавающей точкой одинарной и двойной точности IEEE-754 из коробки: Common Lisp, SBCL и прочие Лиспы.

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

В сообществе периодически возникают призывы что-то с этим делать, но воз и ныне там.

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

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

Любая публичная дискуссия с корректными аргументами на пользу её читателям. Лавсан хорош тем, что использует Common Lisp как есть и использует его в практических задачах (у меня дальше «заточки инструмента» дело не дошло). В общем, перефразируя классика, других лисперов у меня на ЛОРе для вас нет.

Любая публичная дискуссия с корректными аргументами на пользу её читателям.

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

Лавсан хорош тем, что использует Common Lisp как есть и использует его в практических задачах (у меня дальше «заточки инструмента» дело не дошло).

Все что от него было видно кроме гонора и не умения общаться так это то что он 4 года назад написал более современный аналог библиотеки RDNZL 13 летней давности.

В общем, перефразируя классика, других лисперов у меня на ЛОРе для вас нет.

И это к лучшему. Устаревшим языкам место там же где и устаревшему оборудованию - в музеях и в руках энтузиастов, а не в коммерческой разработке. Никто ж basic в прод не тянет и на латыни документацию не пишет.

Языки которые не поддерживают числа с с плавающей точкой одинарной и двойной точности IEEE-754 из коробки: Common Lisp, SBCL и прочие Лиспы.

CL-USER> *features*
(:SWANK :QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :ARENA-ALLOCATOR :X86-64 :GENCGC :64-BIT :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN :PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE :SBCL :UNIX)

Сообщение не читай, сразу беги отвечать.

Вы бы хоть открыли ссылку что я предоставил, там как раз про :ieee-floating-point и идет речь.

Why You Cannot (Yet) (Portably) Write an «Interval Arithmetic» Library in Common Lisp

Дальше заголовка не читай - сразу отвечай. Все оставшиеся тут лисперы такие контуженные?

Слово Portably вам голоса в голове нашептали? Такого слова вообще нет в статье.

В статье детально рассказывается почему у лиспа проблемы с остальными языками на уровне вычислений. Там прямо говорится что а давайте что ли стандарт какой сделаем, а то вариант "напишите свою реализацию под конкретный случай что то не очень работает, цитирую:

Увы, «простого добавления» бесконечностей и режимов округления в реализацию Common Lisp может быть недостаточно, поскольку их семантика глубоко переплетена с другими частями стандарта IEEE-754. Лучший образ действий было бы подтолкнуть разработчиков к соблюдению действующих стандартов. 

Определение новой «арифметической» спецификации в Common Lisp может быть лучшим способом достижения цели предоставления программистам Common Lisp многоуровневого набора документированных функций.

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

Это 2020 год, с тех пор НИЧЕГО не поменялось в этом вопросе.

Слово Portably вам голоса в голове нашептали?

Автор статьи написал.

Автор статьи написал.

Ну тогда потрудитесь сделать скриншот с этим словом, вот статья: https://arxiv.org/pdf/2003.03831.pdf

Слово Portably вам голоса в голове нашептали?

Автор статьи написал, после.
Потом другие добавили что нельзя написать такую либу только если условие использовать именно IEEE 754 в CL, пока ещё.

Автор статьи написал, после.

Хорошо, я вам верю, на слово. Джентльмены друг друга не обманывают.

Потом другие добавили что нельзя написать такую либу только если условие использовать именно IEEE 754 в CL, пока ещё.

Спасибо. Вы сейчас полностью подтвердили мои аргументы выше. Даже ту причину почему поделка Лавсана не работает нормально.

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

И когда очередной выскочка типа Лавсана чуть познавший лисп начинает рассказывать про 95% идиотов у меня появляется легкая улыбка на губах, а в голове загорается красная лампочка…

операции числа с плавающей точкой одинарной и двойной точности стандарта IEEE-754 из коробки: C, C++, C#, Fortran, Java, JavaScript, Python, R, Julia, PHP, Go, Swift, Kotlin, Forth и тд.

Emacs Lisp.
Common Lisp: single-float, double-float.

GCC, math.h

/* IEEE Not A Number.  */
# if __GNUC_PREREQ (3, 3)
#  define NAN (__builtin_nanf (""))
# else
/* This will raise an "invalid" exception outside static initializers,
   but is the best that can be done in ISO C while remaining a
   constant expression.  */
#  define NAN (0.0f / 0.0f)
# endif

Отсюда:

On almost all computers supported by Emacs, this is IEEE binary64 floating point format, which is standardized by IEEE Std 754-2019.

On modern platforms, floating-point operations follow the IEEE-754 standard closely; however, results are not always rounded correctly on some systems, notably 32-bit x86.

Другими словами - почти. Emacs Lisp похоже ближе всех подобрался к тому чтобы повернуться к программисту лицом. Про CL/SBCL такого, к сожалению, сказать нельзя.

Не используй 32 бита и будет в emacs счастье.

В SBCL по ссылке написано, что полностью поддерживается, но нет режима с возвратом исключения.

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

if <boolean_expression> <statement>
else <statement>

спрятаны внутри интерпретатора, как «стандартные формы»

Не стандартные, а «специальные формы».
Обычная форма это вызов функции с выполнением все аргументов.
IF специальная форма потому что вызов IF решает как использовать аргументы выполняя сначала первый аргумент «<boolean_expression>».

В Lisp не нужен ELSE. В Lisp нет проблем со вложенностью IF/ELSE.

полностью поддерживается

нет режима с возвратом исключения.

Вы сейчас на ноль поделили, дважды.

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

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

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

Да не то, чтобы сильно прям сложные. Простенький ридер с раскрытием фиксированного количества ридер макросов можно за пару вечеров запилить с перекурами, как выяснилось %)

Раскрыть последовательность "'" "a" в "(" "quote" "a" ")" — не то, чтобы экзактли рокет саенс.

Учитывающий set-dispatch-macro-character? Ещё есть всякие #1#.

Простенький, конечно можно, но для Си простенький даже проще.

и на латыни документацию не пишет.

по мнению [1] Степанова(https://en.wikipedia.org/wiki/Alexander_Stepanov)

возможно зря

[1]https://www.youtube.com/watch?v=ptqzhxGPGy0 Four Algorithmic Journeys: Epilogue

:)

Открываете что-нибудь такое, там прямо в описании есть API Note:

This method corresponds to the fusedMultiplyAdd operation defined in IEEE 754-2008.

Итд. Java поддерживает операции с double и float так как это определено в спецификации IEEE. Со всеми положительными, отрицательными бесконечностями, NaN и прочим.

Для деления также добавили соответствие стандарту для соответствия логики работы с ошибками округления.

Сами типы также соответствуют стандарту т.к.:

JAVA float == IEEE 754 binary32

JAVA double == IEEE 754 binary64

Также, контексты decimal32, decimal64 и decimal128 реализуют точность указанную в стандарте.

Да, в Java есть свои собственные типы, например, BigDecimal со совими операциями, точностью и прочим. Одно другому не мешает т.к. можно переводить double в BigDecimal используя математический контекст и обратно.

Не надо было это лисперам показывать, они для большой «элитарности» начнут комменты к скобкам на латыни писать.

возможно кстати документацию на латыни и пишут

прост для продуктов чьи разработчики по пользователи с префильтром PhD(али другие D)

как раз таки по доле знающих латынь (ща и «тогда») особой разницы относительно общего числа нет

прст ща «грамотных» больше поэтому доля грамотных среди «грамотных» ща ощущается меньшей чем когда грамотные и «грамотные» были по сути одним и тем же

слава Прогрессу и https://en.wikipedia.org/wiki/The_Marching_Morons

Разработчики и так зачастую не могут внятно оформить свою мысль в текст, а не в код. Если дать им латынь то на выходе вся документация будет уровня: Sapienti sat.

Разработчики и разработчики - разные разработчики

те которые «как дети» - им ваще мало чё можно давать без фатальных последствий для них и окружающих

слава богу живём в эпоху материального изобилия

поэтому вполне приемлемо bulshitjob Для большей части населения

ибо пока так

В SBCL всё то же самое, если верить табличке 1.2 в предоставленной Вами статье. Округление и все операции поддерживаются согласно IEEE.

Ого анонимусов вернули?

В техразделы, да.

А там нечего отвечать. Я авторку той темы читал еще в 2009 году когда он вел блог в juik или типа того сайт назывался, он смешно матерился и подражал языку подонкофф. Это старый жирный тролль. Все написанное им можно смело отправлять в /dev/null. Не надо вестись на провокации, хотя многое из того, что он пишет правда

В SBCL всё то же самое, если верить табличке 1.2 в предоставленной Вами статье. Округление и все операции поддерживаются согласно IEEE.

Настолько «все тоже самое» что допиливают его до сих пор. Только в этом году, в январе в SBCL 2.3.1 приводили «в большее соответствие с требуемой семантикой стандарта IEEE 754 для обработки NaN значений». И еще будут приводить, т.к. этот вопрос до конца не закрыт насколько мне известно.

Вообще, тема NaN настолько глубока и обширна что сами создатели стандарта IEEE 754 не пришли до конца к общему мнению, нужна ли единообразность т.е. NaN == NaN или нет. Сейчас NaN не равно самому себе и на это есть несколько причин. Одна из главных как обычно, историческая: NaN в арифметике Intel 8087 уже было, а предиката isnan() - еще не было, как не было и требования на него. И нужно было дать программистам возможность отлавливать NaN и не допускать исключения т.к. 8087й плевался invalid operation exception при вычислениях с NaN. Поэтому выбрали вариант NaN ≠ NaN (не равен самому себе) чтобы такой механизм был в стандарте и явно отличался от результат сравнения чисел где число == число. Но это я уже в дебри полез.

Не буду спорить. Я опираюсь только на данные из статьи.

Даже стало интересно, а что сейчас не соответствует?

Поэтому выбрали вариант NaN ≠ NaN

$ sbcl
This is SBCL 2.3.7.debian, an implementation of ANSI Common Lisp.
...
* (= (/ 0.0d0 0.0d0) (/ 0.0d0 0.0d0))
NIL

Даже стало интересно, а что сейчас не соответствует?

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

По ANSI спецификации для сравнения float с рациональным производится преобразование float в рациональное, а NaN и бесконечности не могут преобразовываются в рациональную форму записи, поэтому там всякие INFINITE-X-FINITE-Y and INFINITE-Y-FINITE-X.

И бесконечности (положительная с отрицательной) и NaN в лиспе имеют максимальный показатель. А различают их тем что бесконечность всегда имеет мантиссу равную нулю, а NaN всегда имеет мантиссу не равную нулю. Т.е. тут проблема в том что нужно соответствовать стандарту IEEE 754 оставаясь в рамках ANSI стандарта.

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

С учётом того, что в остальных перечисленных языках рациональных чисел нет вообще, это не проблема.

С учётом того, что в остальных перечисленных языках рациональных чисел нет вообще, это не проблема.

Проблема как раз в том что они есть в Lisp :)

Из меня плохой объяснятор, но я попытаюсь донести свою мысль: вот есть ANSI стандарт для Lisp и IEEE 754 стандарт для всех остальных. Оба стандарта несовместимы друг с другом выше определенного порога, более того оба стандарта не совместимы с реальной арифметикой нашего мира выше определенного порога и в некоторых местах этот порог довольно невысокий.

И когда язык под ANSI пытаются причесать под IEEE получается вот тут работает, вот тут даже избыточно поддерживает опциональные фичи стандарта, а вот тут мы рыбу заворачивали.

И это не проблема даже лиспа как такового, если попытаться реализовать ANSI стандарт в «IEEE языке» получим те же самые грабли только с другой стороны.

Так это проблема стандартов. Никто не мешает работать на конкретной реализации (например, SBCL).

В этом смысле, проще языкам, для которых стандарта нет типа Питона, Явы или Рэкета.

Так это проблема стандартов. Никто не мешает работать на конкретной реализации (например, SBCL).

Да это проблема стандартов, но для того чтобы Lisp стал стильным, модным, молодежным (с) необходимо отринуть ANSI как ересь и причаститься у IEEE чего понятное дело мы не увидим. Потому так и будет огромная толпа IEEE-based языков и занесенные в красную книгу ANSI-based языки в своих узких нишах трепыхаться.

IEEE 754 это ведь не только стандарт для ЯП по арифметике с плавающей точкой. Он и при разработке аппаратного обеспечения используется, те же процы Intel начиная с 8087, AMD и тд. Именно поэтому он так распространен.

В этом смысле, проще языкам, для которых стандарта нет типа Питона, Явы или Рэкета.

Им проще скорее потому что они разрабатывались под работу на аппаратном обеспечении которое создавалось после создания IEEE 754, а Lisp создавался для работы на IBM 704 за 30 лет до рождения этого самого стандарта.

В этом плане водораздел примерно 1985-87 годы. И это же основная причина почему даже GO (ака лошадиные шоры на программиста) лучше Лиспа не смотря на все его действительно значимые фичи.

стандарта нет типа … Явы

Пажжи, спецификация же есть.

По ANSI спецификации для сравнения float с рациональным производится преобразование float в рациональное, а NaN и бесконечности не могут преобразовываются в рациональную форму записи, поэтому там всякие INFINITE-X-FINITE-Y and INFINITE-Y-FINITE-X.

Не понимаю проблемы. «When rationals and floats are compared by a numerical function, the function rational is effectively called to convert the float to a rational and then an exact comparison is performed.» и «Might signal arithmetic-error.» в описании rational.

Что было бы плохого, если бы попытка сравнения рационального с NaN/Inf сигнализировало бы ошибку?

С другой стороны, в ANSI нет запрета на рациональные числа 0/0, 1/0, -1/0.

Сейчас получается, что слегка нарушен ANSI. Даже дважды. Во-первых, rational вызывает исключение, которое ни type-error ни arithmetic-error. Во-вторых, результат (> 1/2 (/ 0.0 0.0)) не совпадает с тем, который был бы, если бы для второго аргумента вызывался rational.

более того оба стандарта не совместимы с реальной арифметикой нашего мира выше определенного порога и в некоторых местах этот порог довольно невысокий.

ANSI для рациональных чисел вполне совместима.

Пажжи, спецификация же есть.

Спецификация не стандарт. Её автор компилятора может править как ему надо.

Поддержу с IEEE 754 - лично столкнулся с проблемами и бросил изучение LISPа.

В 2005м надо было сделать анализ двухканального ADPCM с вещественными числами внутри. Прочитал PCL как раз и решил попробовать его - ничего сложного ж не требуется прочитать числа из файла и просто посчитать по формулам - кода на один экран. И как я удивился когда пришлось закатывать солнце вручную - сделать чтение мантисы, порядка и привести это все в числовую форму (<эмоции вырезаны самоцензурой>!). Естественно программа тормозила на больших данных как только могла.

Плюнул и по итогу за полчаса написал решение на C++, которое за пару минут выдавало искомые данные.

Ещё раз о том почему Лисп «скобочный».

В 80-е и 90-е CPU работали на порядки медленее нынешних.
Лисп «скобочный» потому, что он крайне прост для парсинга и создания эффективной run-time подсистемы или бинарного кода.
В те года Лисп использовался в устройствах.
Надеюсь, что Лисп ныне «не доконали» и бинарный код эффективен.

Сейчас получается, что слегка нарушен ANSI. Даже дважды.

Вы начинаете понимать о чем я толкую.

ANSI для рациональных чисел вполне совместима.

До тех пор пока вы остаетесь исключительно в рациональных числах - проблемы нет. Преобразования В и ИЗ них, хотя бы для сравнения, не говоря уже о базовых математических операциях, вот где болото. В IEEE тоже болото, но с тропинками размеченными колышками.

Он и при разработке аппаратного обеспечения используется, те же процы Intel начиная с 8087, AMD и тд. Именно поэтому он так распространен.

Так поэтому SBCL де-факто его и поддерживает. Как написано в исходниках «предполагаем, что аппаратура соответствует». Техническая проблема есть с переносимостью, но тут на всё, что не в стандарте, от FFI и потоков до финализаторов и сборки мусора, есть некие пакеты унификации.

Для IEEE такой потребности видимо нет.

И как я удивился когда пришлось закатывать солнце вручную

cl-cffi разве тогда не было?

Лисп «скобочный» потому, что он крайне прост для парсинга и создания эффективной run-time подсистемы или бинарного кода.

В те годы нескобочный Фортран был на порядки быстрее. Даже достаточно примитивный Си был заметно быстрее Лиспа, что и привело к вымиранию лисп-машин.

Скобочный он по той же причине, по которой он скобочный до сих пор: легче писать макросы.

Что касается эффективности, то второе рождение Лиспа случилось благодаря скорости SBCL. Если старые лиспы были чуть быстрее, чем Perl, то SBCL идёт почти вровень с Java. При этом не требуя явного указания типов, позволяя компилировать во время работы программы и имея прочие преимущества динамического языка.

cl-cffi разве тогда не было?

Это было бы неспортивно: всегда пробую чистое решение практической задачи на изучаемом языке программирования. Чтобы оценить его профпригодность.

Можно разработать кодовую страницу, содержащюю видимые и невидимые символы "(" и ")".