Почему в LISP нет ограничений на количество?

Question

Я могу даже рассчитать (expt 32768 32768) и я получил:

476170470581645852036305042887575891541065808607552399123930385521914333389668342420684974786564569494856176035326322058077805659331026192708460314150258592864177116725943603718461857357598351152301645904403697613233287231227125684710820209725157101726931323469678542580656697935045997268352998638215525166389437335543602135433229604645318478604952148193555853611059596230656

Answer 1

Lisp автоматически переключает математику для использования пакета bignum , когда видит подобные вещи. Но есть ограничение. Сделайте ваши числа достаточно большими, и вам может потребоваться больше битов, чтобы представить их, чем атомов в известной вселенной. Тогда ваша системная память, вероятно, будет исчерпана. :)

Answer 2

Вы можете найти некоторые подсказки, перевернув вопрос: Почему существуют ограничения на размер чисел?

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

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

PS: Также посмотрите, как элегантно Лисп обрабатывает дроби. Невращение дробей в числа с плавающей запятой позволяет получить точную арифметику. Например: (+ 1/3 2/7) => 13/21

Answer 3

Вот еще одна перспектива.

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

Emacs Lisp упаковывает целые числа в одно слово с тегом типа, и поскольку у него нет арифметики bignum (или, может быть, есть сейчас? Но в любом случае не было в одной точке), целые числа/ были ограничены чем-то вроде 28 бит (на 32-битной платформе).Это искалечено по сравнению с C.

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

Например, программа чтения новостей GNU Emacs сломалась (на 32-битных блоках) при подключении к серверам, где номера статей переполнили 28 бит.Так что стоит иметь бигнумы только для того, чтобы получить 32 бита.

Конечно, это не то, почему бигнумы были введены в Лисп.Согласно статье Evolution of Lisp bignums были впервые добавлены в MacLisp в 1970 или 1971 году, потому что некоторые пользователи, занимающиеся символической математикой с Macsyma, нуждались в этом.

Но если вы реализуете Lispс целыми числами с тегами типа вы почувствуете боль и захотите реализовать bignums, чтобы обойти потерянные биты с тегом типа.

Эту проблему можно решить, установив 32-битные целые числа, которыев кучу и без коробки, которые 31, 30, ... 28 (независимо от вашего размера тега).Но это очень мало окупается за сложность.С этой схемой вы уже должны обрабатывать все комбинации в ваших математических процедурах: распакованный - распакованный, распакованный - в штучной упаковке, в штучной упаковке - распакованный и т. Д. С большим количеством усилий вы можете делать bignums.

Go bignum илииди домой, понимаешь, о чем я?:)

Думай bignum, будь bignum!

Требуется bignum, чтобы признать, что он fixnum.

Мягко иди (код, расширяя макросы) и несиbig num!

Чем больше они bignum, тем труднее их получить.