Sono relativamente nuovo a Lisp e mi chiedevo se esistesse davvero un limite superiore alla funzione "+".
(Suppongo che questo valga per tutte le altre funzioni aritmetiche "-", "/" ecc.)
risposte:
11 per risposta № 1Sì, c'è un limite superiore, ma la parte superiore esattail limite è dipendente dall'implementazione. Hai la garanzia di essere in grado di passare almeno a 50, ma dipende tutto.Se hai bisogno di sommare una lista, probabilmente stai meglio con (reduce #"+ list), questo dovrebbe darti una scalabilità molto migliore rispetto a qualsiasi altro metodo.
Common Lisp HyperSpec ha qualche informazione in più.
Quando si tratta di intervalli di valori ce ne sono duecasi distinti, float e interi. I float sono intrinsecamente limitati dalle loro dimensioni e un'implementazione che è passata da single float a double float mi sorprenderebbe molto. Con interi e razionali, CL passa senza problemi tra fixnum e bignum, quindi il limite è una funzione dello spazio di indirizzi utilizzabile disponibile per l'implementazione. Sospetto che lo stesso vale per i numeri complessi (interi e razionali complessi -> vai su bignum se necessario, float complessi -> segnala un fuori range, o restituisci un Inf o NaN).
8 per risposta № 2
Common Lisp è stato definito in modo talepotrebbe essere implementato in modo efficiente su un'ampia varietà di sistemi hardware e software. Esempi sono processori come il Motorola 68000/20/30/40, i vari processori Intel x86, processori basati su stack di Lisp Machine, DEC VAX, processori RISC, computer super come quelli di Cray. Negli anni '80 c'erano molte famiglie di processori in competizione, inclusi processori sviluppati per l'esecuzione del codice Lisp. Oggi abbiamo ancora diverse famiglie di processori (x86, x86-64, ARM, SPARC, POWER, PowerPC, ...).
Può anche essere compilato in C, Scheme o altri linguaggi di programmazione.
Può anche essere compilato su macchine virtuali come quelle di CMUCL, CLISP o JVM / Java Virtual Machine (la Java Virtual Machine sembra avere un limite di 254 argomenti).
Ad esempio, potrebbe essere compilato un compilatore Common LispCodice Lisp per il codice C semplice. Quindi sarebbe bene se la maggior parte della funzione chiamata del compilatore C potesse essere riutilizzata il più possibile. Soprattutto anche per rendere più facile chiamare Lisp da C.
Anche in C / C ++ ci sono dei limiti:
Numero massimo di parametri nella dichiarazione di funzione
Sopra dà numeri come 127 (C) e 256 per C ++. Quindi per un compilatore da Lisp a C questi potrebbero essere i limiti. Altrimenti il codice Lisp non userebbe la chiamata della funzione C.
Il primo compilatore KCL (Kyoto Common Lisp, in seguito questa implementazione si è evoluto in GPL / GNU Common Lisp e ECL / CommonLisp incorporabile) ha avuto un CALL-ARGUMENTS-LIMIT di 64.
Un'implementazione a 64 bit di LispWorks / Mac OS X ad esempio ha un valore di 2047 per CALL-ARGUMENTS-LIMIT.
CALL-ARGUMENTS-LIMIT non dovrebbe essere inferiore a 50.
In Common Lisp, quindi, elabora l'elaborazione e la chiamatagli argomenti non sono correlati. Se si desidera elaborare elenchi, è necessario utilizzare gli strumenti di elaborazione elenco (LISTA, MAPCAR, APPEND, RIDUCE, ...). Common Lisp fornisce un meccanismo per accedere agli argomenti come elenco usando a &RESTparametro. Ma di solito dovrebbe essere evitato, dal momento che potrebbe causare un sovraccarico della funzione perché è necessario un elenco degli argomenti da trattare.
2 per risposta № 3
Clojure fornisce un esempio di Lisp in cui puoi effettivamente avere un numero infinito di argomenti per una funzione, tramite l'uso di sequenze lazy:
; infinite lazy sequence of natural numbers
(def naturals (iterate inc 1))
(take 10 naturals)
=> (1 2 3 4 5 6 7 8 9 10)
; add up all the natural numbers
(apply + naturals)
=> ...... [doesn"t terminate]
Non particolarmente utile, ovviamente .....
2 per risposta № 4
Dipende dall'implementazione. "Suggerirei agli utenti di LISP di impiegare 5 minuti per testare la propria piattaforma".
Per Clojure
(defn find-max-n [n]
(try
(eval (concat (list +) (take n (repeat 1))))
(println "more than" n)
; return n if something goes wrong
(catch Exception e n))
(recur (* n 2)))
(find-max-n 1)
Non termina, si blocca a 8192 dato le mie impostazioni.
more than 1
more than 2
more than 4
more than 8
more than 16
more than 32
more than 64
more than 128
more than 256
more than 512
more than 1024
more than 2048
more than 4096
more than 8192
-1 per risposta № 5
Risposta semplice, no, anche se una scarsa implementazione con ricorsione e non ricorsione in coda avrà un limite di stack.
A seconda dell'implementazione + può essere implementato utilizzando la ricorsione o una chiamata di funzione diretta.
Non conosco abbastanza bene Common Lisp per sapere quali requisiti specifica, ma la maggior parte delle implementazioni, se usano la ricorsione, useranno la ricorsione in coda ed eviteranno qualsiasi limite di stack.
Una chiamata di funzione sarà in grado di accedere agli argomenti come una lista e quindi non c'è limite al numero di argomenti che possono essere elaborati.
EDIT: Dato che qualcuno ha effettivamente dato un riferimento al Common Lisp, dovrebbe essere chiaramente una risposta migliore, ma avrei pensato che qualsiasi buona implementazione avrebbe applicato automaticamente l'equivalente di (reduce #"+ arg-list) quando vengono forniti sufficienti argomenti.