Почему в LISP нет ограничений на количество?
Могу даже посчитать (expt 32768 32768) и я получил:
476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656
3 ответа
Lisp автоматически переключает математику для использования пакета bignum, когда видит подобные вещи. Но есть ограничение. Сделайте ваши числа достаточно большими, и вам может потребоваться больше битов, чтобы представить их, чем атомов в известной вселенной. Тогда ваша системная память, вероятно, будет исчерпана.:)
Вы можете найти некоторые подсказки, перевернув вопрос: почему существуют ограничения на размер чисел?
Есть несколько практических причин для ограничения размера чисел. Представление чисел в некоторых других языках программирования тесно связано с аппаратной архитектурой, причем размер чисел ограничен количеством битов в регистрах процессора.
К счастью, в Лиспе вы можете мыслить более абстрактно, освобождая программиста от таких низкоуровневых деталей. Но такая арифметика произвольной точности, как правило, медленнее, чем ограничение чисел для размещения в регистрах процессора.
PS: Также проверьте, как элегантно Lisp обрабатывает дроби. Невращение дробей в числа с плавающей запятой позволяет получить точную арифметику. Например: (+ 1/3 2/7) => 13/21
Здесь другая перспектива.
Одна из причин, по которой нужны целые числа произвольной точности, заключается в том, что реализации Lisp, которые имеют эффективные неупакованные целые числа, но не имеют математических вычислений произвольной точности, являются ограниченными по сравнению с некоторыми другими языками на той же платформе.
Emacs Lisp упаковывает целые числа в одно слово с тегом типа, и, поскольку у него нет арифметики bignum (или, может быть, есть сейчас? Но в любом случае не было), целые числа ограничены или были ограничены чем-то вроде 28 бит (на 32-битной платформе). Это покалечено по сравнению с C.
32 бита покалечены, а 28 лишних. Это затрудняет взаимодействие с другими программами. Например, чтение двоичных структур, которые содержат 32-битные целые числа.
Например, программа чтения новостей GNU Emacs сломалась (на 32-битных блоках) при подключении к серверам, где номера статей превышали 28 бит. Так что стоит иметь бигнум только для того, чтобы добраться до 32 бит.
Конечно, это не то, почему бигнумы были введены в Лисп. Согласно документу The Evolution of Lisp bignums были впервые добавлены в MacLisp в 1970 или 1971 году, потому что некоторые пользователи, занимающиеся символической математикой с Macsyma, нуждались в этом.
Но если вы реализуете Lisp с целыми числами с тегами типа, вы почувствуете боль и захотите реализовать bignums, просто чтобы обойти биты, которые вы потеряли в теге type.
Вы можете решить эту проблему, установив 32-битные целые числа с кучей и распакованные 31, 30, ... 28 (независимо от размера тега). Но это очень мало окупается за сложность. С этой схемой вы уже должны обрабатывать все комбинации в ваших математических процедурах: распакованный - распакованный, распакованный - в штучной упаковке, в штучной упаковке - распакованный и т. Д. Приложив больше усилий, вы сможете делать большие дела.
Иди бигнум или иди домой, понимаешь, о чем я?:)
Думай bignum, будь bignum!
Требуется большой человек, чтобы признать, что он неподвижен.
Идите (код, расширяя макросы) мягко, и носите большое количество!
Чем больше они bignum, тем сложнее их вывозить.