Вы пытались оспорить, что аппаратная десятичная арифметика осталась только на мейнфреймах... И речь не о младших моделях, а более поздних. Промах у Вас.Сообщение от Hunta
На фортране можно это представить - там есть нормальные функции. Но для бухгалтерии это не подойдет, бухгалтеру придётся вместо a+b*c писать что-то типа longplus(a, longmul(b,c)) - нехорошо ему станет от этого. А представьте более длинное выражение с любимимы всеми банкирами сложными процентами - совсем будет нехорошо.А некоторые тупят что-то ещё и про древний бейсик.
Вот на си++ или рубине (и некоторых других языках) реализовать и использовать длинные числа - это вполне нормально - у меня многие студенты это делали в рамках курсовых работ.
Это есть, avivanov76 это запускал - и при чем тут z80? Но мюлисп там есть действительно только для Z80 - ваш очередной промах.
Так бывает. Вроде почти выпустили, но что-то сорвалось.
Посмотрите на снимок экрана ниже, который выложил avivanov76 - это никакой не лисп, а специализированный язык для математиков....поэтому заключаем, что си - это не си, потому что у него препроцессор, которым можно исковеркать синтаксисда?
Какое конкретное утверждение, когда нас интересовали только длинные числа? Вы знакомы с тем, что называют контекст?
Сомнительно, что ошибку исправили недавно - кто бы стал это делать?! Но чтобы разобраться с этим загадочным снимком экрана, нужны образы дисков с разными версиями рапиры. К сожалению, не смог найти архива агатовского софта.так вот, судя по снимку из заглавного поста, одно время длинная арифметика рапиры работала с ошибками (то есть НЕ работала)
...
возможно, баг исправле был уже в нашу эмуляторную эпоху (и возможно, не везде и не окончательно)
вот так, и теперь я жду 100% убедительных доказательств, что в исторической рапире вообще была правильная длинная арифметика
Была практическая тема, что форматы вещeственных BCD для 8-биток жестко фиксированы. Вы с этим спорите. Но это факт. Конечно, можно переписать MSX-бейсик, например, но как это было внедрять при наличие стандартного варианта в ПЗУ? Или представьте, что вам на Спеке нужно под бейсиком использовать вещественные числа формата 8087 - это практически невозможно. Максимум, что можно сделать это при вводе данных сразу конвертировать числа в стандартный формат, а при выводе делать наоборот, но это приведет к потере точности и сделает всё это бессмысленным.
Никто с этим не спорил - Вы похоже не следите за темой. Спорим мы, был ли универсальный язык, который поддерживал длинный числа на платформе 6502, кроме рапиры? MuMath-80 - это математический пакет, а не универсальный язык.
Это достаточно типично для софта Апл. Mumath-80 - это такой же монолит, у которого к тому же дискеты нестандартные - их, например, MAME не грузит. Перенос рапиры на ProDOS не должен был бы быть слишком сложным, но это, конечно, пустые разговоры. Без Звенигородского рапира зачахла.
Выше уже написал для Hunta соответствующий комментарий. Добавлю только, что древние бейсики очень тормозные. Например, как-то был озадачен, когда Коммодор 64 просто заполнял 120 длинных cтрок более 2 часов. Это из-за дрянного уборщика мусора, но и на более продвинутом Коммодоре +4 это занимает до 15 минут. А программы в бухгалтерии делал и внедрял...Что, вас жалкие 15 строчек напугали? Вы не программист, я смотрю. Почитайте Github что-ли. В реальных программах строк гораздо больше и на их фоне эти 15 просто потеряются.
Про парсинг выражений поподробнее. Вы собрались тетенькам из бухгалтерии голую Рапиру подсунуть? Чтобы они формулы в ней писали? Серьезно? Ну, успехов вам
Тут Вы абсолютно правы. Однако, мы в теме рапиры и Агата.
Речь о том, что 4361 только для некоторых видов расчетов мог быть до 3-х раз быстрее, чем IBM PC AT. А, например, обработка текстов или 16-битных данных на AT могла быть даже быстрее. Поэтому этот мейнфрейм соответствовал по мощи процессора только от 1 до 3 эйтишек. Конечно, у мейнфрейма диски были раз в 10 быстрее и некоторые другие преимущества, но были и недостатки, например, в популярных ОС не было даже поддержки каталогов, тексты нельзя нормально скроллировать, и т.п.
Его вы за $20000 не купили бы тогда.
Цели - это хорошо, но со списком реализаций как-то совсем плохо - не пошёл SETL.
Или яву с питоном.
Есть в питоне элементы, похожие именно на рапиру. Не понял про присваивание, это в рапире он нормальный, соответсвующий естественной практике языков, с нотацией слева-направо. Так же присваивание записывается в коболе, некоторых популярных ассемблерах. Даже для х86 в GCC используют почти всегда такую нотацию. Обратная нотация реально более массова, но это не делает её более нормальной. Некоторые языки используют нотацию справа-налево - они что ненормальные? Рапира создавалась ещё до того как концепции ООП явно оформились. Первые популярные ООП языки появились только к концу 90-х. Поэтому неудивительно, что ООП в рапире нет. С другой строны в питоне ООП весьма специфично. Возможно это дело вкуса, но считаю, что в С++, Ruby или Java с этим существенно получше. Индексы - это тоже дело непринципиальное, где-то они с нуля, где-то с 1, а в паскале начальный индекс вообще может быть любым и что?
Причем тут "обвиняю". Человек возможно посмотрел на рапиру и это помогло ему сделать питон, что в этом плохого?
- - - Добавлено - - -
Выше уже написал запрос. Не смог у Вас найти рапиру, а желательно получить разные версии. Вот уважаемый Lethargeek вообще сомневается, что арифметика на рапире работала...
Ответить с цитированием