Newsgroup: it.comp.giochi.avventure.testuali
Titolo: Innovazione nelle AT?

 camera
CAMERA> {DESCRIZIONE SINTETICA DELLA CAMERA}
CAMERA>
CAMERA> sedia
CAMERA>SEDIA> {DESCRIZIONE SINTETICA DELLA SEDIA}
CAMERA>SEDIA> ..
CAMERA> scrivania
CAMERA>SCRIVANIA> {DESCRIZIONE SINTETICA DELLA SCRIVANIA}
CAMERA>SCRIVANIA> penna
CAMERA>SCRIVANIA>PENNA> >> tasca
CAMERA>SCRIVANIA> tasca            [scorciatoia, in quanto non è ambigua nel
contesto attuale]
ME>GIACCA>TASCA> {ELENCO CONTENUTO TASCA}
ME>GIACCA>TASCA> tutto >> scrivania        [vuota la tasca sulla scrivania]
ME>GIACCA>TASCA> {VUOTA}
ME>GIACCA>TASCA> [tramite funzionalità simili a quelle offerte dal vecchio
DOSKEY possiamo spostarci con facilità verso gli ultimi contesti usati]
CAMERA>SCRIVANIA> esci
CASA>CORRIDOIO>
    In generale i contesti non verranno resi disponibili fino a quando non
saranno raggiungibili o visibili. Per esempio sarebbe "pedante" mostrare il
prompt:
CASA>CORRIDOIO>CAMERA>SCRIVANIA>
però si potrebbe mostrare questo:
...>CAMERA>SCRIVANIA>
con la possibilità da parte del giocatore di vederlo completo.
    Come avrete visto ci si muoverebbe come si faceva in msdos, però
consentendo scorciatoie, contesti prestabiliti, ecc...
Notate che non è proprio come muoversi in un ambiente ipertestuale, infatti
nel nostro caso sappiamo sempre con precisione da dove veniamo (cosa
fondamentale onde evitare smarrimento nel giocatore).
Il giocatore dovrebbe solo impararsi qualche semplice operatore come ">>" e
"<<" che significa "prendere", "dare", "spostare", "versare", "acquisire",
"rubare", ecc...
    Questa interfaccia renderebbe tutto molto più intuitivo e facile
eliminando completamente vari problemi dei parser e permettendo all'utente
un approccio più "progressivo" verso l'azione che intende eseguire.
E' un po' come cercare qualcosa con un motore di ricerca e poi "rifinire" la
ricerca successivamente.
Con questo metodo è inoltre possibile focalizzare l'attenzione su singoli
oggetti senza doversi preoccupare dell'ambiente circostante.
Per es. sarebbe scomodo scrivere:
"prendi l'orologio che si trova sulla mensola a destra dell'armadio e
mettilo........"
Con i contesti diventa tutto può semplice.
Inoltre sono possibili azioni molto più complesse. Se per es. sappiamo che
saremo perquisiti da qualcuno più avanti nel gioco, possiamo nascondere un
oggetto importante all'interno di una scarpa o in posti analoghi (anche
"anali" se volete, ma prima meglio provare alternative meno compromettenti).
Il programma effettuerà la perquisizione semplicemente controllando il
contenuto della tasca e di altre zone prestabilite.
Se non trova l'oggetto, abbiamo superato la perquisizione. Non è necessario
per forza nascondere l'oggetto nel posto o nel modo previsto dall'autore del
gioco (questo è un buon metodo per non stressare il giocatore e rendere
tutto più realistico).
    Già m'immagino alcune critiche, ma vorrei ricordarvi due cose:
1) molte critiche possono essere presentate come consigli, cioè è inutile
fare notare che c'è una mancanza quando la soluzione è palese: ponete
l'accento sulla soluzione, anziché sulla mancanza;
2) non vi sto vendendo niente quindi cercate di vedere se è possibile
seguire questa strada, anziché cercare in tutti i modi di convincervi e
convincermi che non lo sia.
Kiuhnm

 cambiare approccio.
Sono d'accordo.
Secondo me pero' il modo migliore per creare un mondo AT
e quello di poterlo 'disegnare' in forma grafica e poi
di poterlo giocare in modo testo.
E non parlo di IDE, ma proprio di forma grafica nel design.
Quindi io disegno la mappa, e ci metto gli oggetti dentro come
se stessi disegnando una AG.
Poi definisco l'essere umano che ci si trova dentro.
In altre parole il setting e' indipendente dal fatto che qualcuno
ci si trovi dentro.
Ad esempio, ho notato molte limitazioni nei world model delle AT per
quello
che riguarda le parti del corpo.
In "The Last Hour" ho dovuto fare le evoluzioni per poter
gestire gambe, piedi, braccia, testa, etc...
Pensate che bello poter giocare la stessa AT con un personaggio
cieco, un personaggio "sordo", un bambino (che necessariamente
ha approcci diversi, riutilizzando lo stesso setting, pero'
gli oggetti avrebbero relazioni tra di loro differenti, in funzione
del giocatore.
Rob
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Già m'immagino alcune critiche
Non da me. Ti passo un paio di idee dell'epoca:
- Return torna al contesto superiore (e Ctrl-Return al livello base).
- Il primo contesto puo' essere il nome di un personaggio, consentendo 
di iniziare conversazioni (e/o di gestire personaggi multipli con un 
prefisso o un tasto modificatore).
   .Erix.

 convincermi che non lo sia.
La strada è assolutamente percorribile, ma anche sfruttando gli 
strumenti attuali (eliminare dalla libreria di inform il parser e fare 
una cosa del genere cercando di conservare il world model).
Secondo me una parte dei problemi di approccio con le AT derivano del 
parser come giustamente hai fatto notare, ma anche da come il parser si 
relaziona con il world model. Ad esempio Inform ha un ottimo world model 
ma secondo me non sempre funziona bene su "comando" del parser.
Giovanni
-- 
Giovanni Riccardi
personal: 
http://www.composizioni.net
   weblog: 
http://www.composizioni.net/addv
     work: 
http://www.anxur.it

 all'obiettivo un passo alla volta.
(snip)
Ricordo benissimo quando Enrico Colombini propose un "parser" a una
parola. Idea 
affascinante, che tu hai affrontato con molti spunti interessanti.  
Riflettevo, inoltre, sul messaggio postato da Venerandi qualche giorno fa:
l'idea di 
un testo con parole cliccabili e dunque ipertesti mi sembra un'altra buona
strada da 
percorrere, soprattutto da chi vuole concentrarsi sulla narrazione. Non
conosco Idra, 
č piů o meno cosě?
f.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 č piů o meno cosě?
No, ma volendo si puň fare con poco sforzo.


 No, ma volendo si puň fare con poco sforzo.
E' gia' stato fatto.
Si possono scrivere AT che girano su PHP + MySQL.
Ricordo di aver guardato questo applicativo quando fu presentato su
raif.
Non ricordo il link.
Se siete interessati lo cerco.


 prefisso o un tasto modificatore).
Quest'idea è molto interessante ed è anche in linea con la logica dei
contesti. Del resto ho fatto una cosa simile quando ho usato "ME" per
riferirmi al "contesto" del giocatore.
Kiuhnm

 del giocatore.
Quanto hai detto è molto simile a quello che proposi in un post di un anno
fa, ma nessuno sembrò essere d'accordo. L'idea sembrerebbe buona, ma penso
che la sua realizzazione sarebbe a dir poco difficoltosa.
Sarebbe quasi necessario definire delle leggi fisiche per controllare il
comportamento degli oggetti, altrimenti come fa il mondo ad apparire diverso
a un sordo, a un cieco, ecc...?
Per esempio un personaggio forte potrebbe sfondare la porta, mentre quello
debole dovrebbe cercare un altro modo, ecc... Chi decide se il personaggio
riesce a sfondare la porta? Il motore fisico (magari molto semplice, ma
sempre tale rimane).
Kiuhnm

 model ma secondo me non sempre funziona bene su "comando" del parser.
Infatti il problema è esclusivamente il parser.
In pratica dovremmo intervenire soltanto sulla facciata ovvero
sull'interfaccia.
C'è anche da dire che in questo modo forse il WM verrebbe valorizzato come
non mai.
Chissà...
Kiuhnm

Kiuhnm
max "torredifuoco" bianchi

 suspended (infocom)? niente motore (credo), solo l'idea.
Piccola correzione: ne discussi sul ng delle AG.
Kiuhnm

 Kiuhnm
Sai, l'idea del tuo parser (perché sempre di parser si tratta) non mi
dispiace per niente... A chi va di sperimentare? Finita la tesi, ad agosto
potrei cominciare a scrivere un linguaggio (magari con l'editor visuale che
piace a Rob)...
Ignazio

 cieco, un personaggio "sordo"...
"Suspended" della Infocom.

 "Suspended" della Infocom.
Esatto, solo che non devi scrivere ogni volta quello che 'vede', 'sente'
ad hoc
ma farebbe parte delle "librerie" perche' gestisce le relazioni 
PC-NPC e PC-Oggetti nel modello del mondo.


 PC-NPC e PC-Oggetti nel modello del mondo.
sinceramente non vedo come si potrebbero programmare interazioni 
complesse... un appunto che stavo per muovere anche al parser 
mono-parola, che mi pare vada bene giusto per esperimenti alla SUTW di 
Plotkin.
ciao
S

 Plotkin.
A dire il vero tutte le operazioni/interazioni complesse sono in realtà
composte da operazioni/interazioni semplici.
Kiuhnm

 Plotkin.
E non chiamarlo "parser mono-parola": non lo č.
Si utilizzano operatori quali >> e << oltre ad alcuni termini.
Tramite gli operatori si potrebbero anche formare "frasi complesse" (e
sarebbe anche facile da fare).
Kiuhnm

 l'editor visuale che piace a Rob)...
Non mi piace chiamarlo parser, comunque...
La critica secondo la quale non sarebbero possibili interazioni complesse
potrebbe essere tenuta in considerazione fornendo strumenti per combinare
più azioni insieme.
Comunque mi piacerebbe avere un esempio di "interazione complessa".
Sicuramente è sempre possibile esprimerla in simboli.
Penso che più che creare un parser monoparola, dovremmo creare un "parser
simbolico".
Sia ben chiaro che sarà sempre possibile utilizzare una singola parola per
muoversi tra i contesti, però operazioni complesse potranno essere eseguite
scrivendo "formule".
Per es.
    (penna + cappuccio) >> Giovanni
significherebbe:
"Combina la penna con il cappuccio e dai il risultato a Giovanni".
Diverso da:
    (penna, cappuccio) >> Giovanni
che significa:
"Da la penna e il cappuccio a Giovanni"
equivalente a:
    penna >> Giovanni; cappuccio >> Giovanni
o a:
    penna >> Giovanni
    cappuccio >> Giovanni
Mi pare che le interazioni complesse diventerebbero estremamente facili e
intuitive.
Mediante operatori generici, potenti, semplici e ben definiti, chiunque
potrà eseguire operazioni intuitivamente.
Kiuhnm
P.S. Attualmente sono veramente sotto pressione. Ho iniziato da 3 anni un
progetto (praticamente un micro-OS completamente Lockfree e Waitfree) e ci
sto lavorando giorno e notte quindi non penso di potermi dedicare a un altro
progetto come questo (anche se infinitamente più semplice e piccolo) entro
breve tempo.

 breve tempo.
Tanto all'inizio si tratta solo di progettare. Per l'implementazione, 
una volta che c'è lo studio dietro...


Inseguivo i banditi del tempo quando Kiuhnm scrisse...
 >   (penna + cappuccio) >> Giovanni
 >   (penna, cappuccio) >> Giovanni
 >   penna >>> Giovanni; cappuccio >> Giovanni
 > Mi pare che le interazioni complesse diventerebbero estremamente facili e
 > intuitive.
Quoto, e non dico altro.
--
Atrus di Myst
"The rock is hard. The rock cutter is patient."  - D'ni proverb
http://cube.auroraproject.net/

     cappuccio >> Giovanni
Credo che un giocatore occasionale, che di solito cancella una at dopo 
un minuto di litigi con il parser canonico, cancellerebbe una at con 
questo parser dopo trenta secondi.
Interessante, intendiamoci, ma giusto per chi è già nel giro, come 
diversivo.
f.

 una volta che c'è lo studio dietro...
Progettare fa comunque parte dello sviluppare software, no?
Spesso impiego mesi a progettare e giorni ad implementare.
Kiuhnm

     penna >> Giovanni; cappuccio >> Giovanni
Perchè non
cappuccio >> penna >> Giovanni? :-)
A parte gli scherzi, non credo che un clone della bash andrebbe bene: serve
qualcosa di molto più intuitivo.
Ignazio

 diversivo.
Sei troppo pessimista :-)
Kiuhnm

 serve qualcosa di molto più intuitivo.
Non mi pare la bash, infatti il tuo esempio sembra un "flusso", mentre il
mio è un'espressione matematica.
Non credo che si possa rendere tutto più intuitivo senza perdere libertà
d'azione.
Al limite possiamo eliminare del tutto gli operatori e permettere il
trascinamento delle parole tramite mouse.
Quando due oggetti possono essere combinati le loro parole si fondono a
formarne una nuova e così via.
Si potrebbe fare, ma mi pare molto più semplice usare gli operatori.
Kiuhnm

 trascinamento delle parole tramite mouse.
Lo stavo pensando. Assieme all'autocompletamento.
Ignazio

 č piů o meno cosě?
Si', se ho capito bene cosa intendi. Dai un'occhiata al manuale, 
dovrebbe essere abbastanza leggibile 
(
http://www.erix.it/idra/Manuale/Idra-1.html
).
   .Erix.

 quindi non penso di potermi dedicare a un altro progetto 
 > come questo (anche se infinitamente più semplice e piccolo)
 > entro breve tempo.
Sull'infinitamente più semplice e piccolo avrei qualche dubbio (specie 
nel caso cui pensavo io con i <CR>). Iniziare e' facile, ma poi mi 
pare che si complichi non poco. Un OS ha complessita' lineare, un 
world model esponenziale ;-)
   .Erix.

 diversivo.
Infatti... gia' che ci sono, butto li' un'altra vecchia idea che non 
ho tempo di sviluppare: un testo sul quale il giocatore clicca una 
sequenza di 1..n parole (non un elenco di verbi ecc., proprio le 
parole del racconto). Le azioni sono implicite dal contesto.
   .Erix.
P.S. Argh, quanti messaggi, riesco a malapena a seguire questo thread. 
Se non rispondo a qualcuno e' perche' mi sfugge il messaggio, mi scriva.

 Lo stavo pensando. Assieme all'autocompletamento.
Che cosa intendi per autocompletamento (dato che si trascinano parole già
presenti)?
Il metodo del trascinamento potremmo anche renderlo più completo aggiungendo
sotto-menù dinamici.
I menù si attiveranno se necessario.
Per es. ipotizziamo che un enigma preveda che degli oggetti vengano
combinati in un certo modo e in un certo ordine. Trascinando una parola su
un'altra apparirà il menù con le varie possibilità.
Inoltre cliccando su una parola servirà un menù con le varie possibilità.
Mi sembra un'idea banale, ma efficace.
Praticamente ci stiamo riconducendo all'interfaccia delle AG...
Bisognerebbe però evitare di dare suggerimenti al giocatore usando menù
troppo restrittivi.
Kiuhnm

 troppo restrittivi.
Non lo so... Potrebbe essere simpatico il sistema: bisognerebbe sperimentare
secondo me.
Ignazio

 world model esponenziale ;-)
Starai scherzando, spero. Non c'è il benché minimo confronto.
Scrivere un OS è come cercare di disinnescare una bomba: al minimo passo
falso ti esplode tra le mani.
Un OS è paragonabile all'organismo umano, a un governo o a un ecosistema,
ecc.... Vai a chiedere agli esperti quanto è semplice.
Inolte stiamo parlando di OS waitfree (una vera sfida a livello accademico).
Ipotizziamo di avere una struttura dati che supporta operazioni
d'inserimento e di cancellazione.
Hai mai programmato in multithreading?
Spesso sento programmatori che si lamentano perché lavorare con gli
strumenti di sincronizzazione attuali, cioè con le sezioni critiche, i
semafori, i temporizzatori, ecc... è troppo difficile, ma non sanno quanto
si sbagliano.
Ammettiamo che n thread vogliano operare contemporaneamente sulla stessa
struttura dati. Come fai?
Attualmente si usano sezioni critiche in modo che di fatto un solo thread
alla volta abbia accesso alla struttura dati (metodo assolutamente
inefficiente).
I metodi lockfree / waitfree invece non usano sezioni critiche, ma
permettono a tutti di lavorare sulla stessa struttra concorrentemente.
Ti rendi conti di qual é il livello di complessità???
Un codice lockfree di 10 righe è più difficile da scrivere di un codice
normale di 1000 righe o più.
In un codice lockfree, ogni riga di codice aggiunta rimette in discussione
l'INTERO codice scritto fino a quel momento: è un INFERNO.
Ti basti pensare che sono serviti 50 anni per escogitare una versione
lockfree delle liste linkate "semplici". Quelle doppie sono improponibili e
gli alberi binari sono proprio impensabili con i metodi attuali.
Prova a lavorare su una struttura dati che cambia senza sosta e senza
preavviso.
Per esempio ipotizziamo che il thread A voglia settare un bit e B voglia
azzerarne un altro, il tutto concorrentemente.
Come fai?
L'operazione OR della CPU esegue 3 operazioni
1) tmp = [mem]
2) tmp = tmp | (1 << bit)
3) [mem] = tmp
Ora dimmi che cosa succede se un altro thread modifica [mem] subito dopo il
punto 1).
Semplice: il punto 3) annulla tutte le modifiche eseguite dall'altro thread.
Soluzione?
In questo caso è semplice perché la CPU offre istruzioni atomiche, ma a
livello di nodi e di elementi?
Difficilissimo se non impossibile.
Kiuhnm

 In un codice lockfree, ogni riga di codice aggiunta rimette in 
 > discussione l'INTERO codice scritto fino a quel momento:
 > è un INFERNO.
Qual e' lo scopo? [domanda da ignorante]. Pensavo che oggi la ricerca 
dell'affidabilita' intrinseca fosse enormemente piu' importante 
dell'efficienza, e cio' mi sembra andare nella direzione opposta. 
Quindi immagino ci sia un altro motivo.
(siamo un po' OT, magari proseguiamo in privato...)
   .Erix.


volevo anche tradurlo in ita per awl/pearson, ma ovviamente non se n'è 
fatto niente, grr

 delle AG, il tutto convertito in formato testo.
i SO moderni usano la GUI, altro che shell testuale, io provo ancora a 
insegnare il COPY di DOS agli allievi ingegneri informatici e loro mi 
guardano come fossi un babbuino viola...

 (siamo un po' OT, magari proseguiamo in privato...)
Hai presente come funziona un allocatore di memoria? Ovviamente sì.
E' semplicemente un "amministratore" che dice ai clienti quale porzione di
RAM usare evitando conflitti tra gli stessi (se facessero da soli staremmo
freschi!).
Qual è l'algoritmo migliore per evitare un'eccessiva frammentazione e altri
problemi?
E' quello di selezionare sempre il più piccolo blocco abbastanza grande da
soddisfare la richiesta del cliente.
Qual è la migliore struttura dati?
Indubbiamente un albero binario autobilanciante (altrimenti può degenerare,
nel peggiore dei casi, in una lista linkata).
Come facciamo in un sistema con multitasking dove tutti si rivolgono allo
stesso
gestore di memoria contemporaneamente?
Dobbiamo per forza di cose usare una sezione critica in modo che accedano
all'albero uno alla volta. Questo è inefficiente, infatti immagina che
l'albero sia molto grande e che a uno serva un nodo lungo 16 e all'altro
16184 bytes. I due clienti non potrebbero essere soddisfatti
contemporaneamente? Sì, infatti i due nodi sono agli antipodi dell'albero
(nel nostro esempio) e quindi le due operazioni possono avere luogo
contemporaneamente.
Però è impossibile prevedere se i nodi resteranno agli antipodi fino alla
fine delle due operazioni, quindi non si può usare un ibrido: o usi le
sezioni critiche o te ne sbarazzi completamente (qualcuno ha proposto
"piccole" sezioni critiche, ma il metodo non ha riscosso un gran successo
dati che si trattava sempre di un compromesso).
In pratica si usano 128 alberi binari contenenti nodi piccoli, ......, medi,
....., grandi. In questo modo si spera che non tutti i thread abbiano
bisogno di prendere nodi dallo stesso albero.
Capirai bene che comunque questa non è una soluzione infatti molti programmi
allocano blocchi di dimensione fissa e quindi accederebbero sempre allo
stesso albero, inoltre l'algoritmo non è più quello ottimo che avevamo
previsto con un albero unico.
Sezioni critiche: ([A, ..., J] = operazioni eseguite da thread diversi)
A
B
C
D
E
F
G
H
I
J
= 10 "cicli".
WaitFree/LockFree:
A   B   C
                 D     E            (c'è stata una lieve interferenza)
                                F  G   H   I   J
= 3 "cicli".
Tu mi dirai "Ma tanto la CPU simula il multitasking" eseguendo prima un
thread per 50 ms, poi l'altro e così via, quindi il tempo complessivo è lo
stesso alla fine.
Questo potrebbe essere vero se non fosse che oggi si punta molto sui sistemi
multiprocessore perché costano meno di un singolo processore equivalente.
Con le sezioni critiche ci sono sprechi enormi, infatti n-1 processori
potrebbero essere fermi ad aspettarne uno solo!
Differenze tra metodi lockfree e waitfree? Quelli lockfree semplicemente
provano a rifare l'operazione all'infinito finché non ci riescono e questo
potrebbe portare a (altamente improbabili) stalli fra due thread con la
stessa priorità in lotta per il "possesso" della stessa area della struttura
dati. Quelli waitfree invece completano l'operazione del thread che
interferisce (lo aiutano, in sostanza) e poi ricominciano ad eseguire la
loro. Problemi? Si potrebbe finire con l'aiutare un thread che aiuta un
altro thread che aiuta un altro.......... Dato che quest'ultima ipotesi è
*veramente* improbabile, i metodi waitfree sono preferibili e, neanche a
dirlo, più difficili da realizzare di quelli lockfree.
Praticamente le sezioni critiche bloccano a livello di CODICE, cioè fanno sì
che per es. due thread non eseguano la funzione BBT_InsertNode()
contemporaneamente, invece i metodi waitfree operano a livello di NODI cioè
entrano in azione soltanto quando effettivamente due o più thread iniziano a
litigare per il possesso di un nodo.
Che bella 'sta roba :-)))
Ci sarebbe anche un terzo metodo pseudo-lockfree/waitfree, ma per saperne di
più dovrai aspettare una mia pubblicazione ;-)
Dimenticavo! Un altro vantaggio dei metodi senza sezioni critiche è il tempo
di risposta.
Inserire uno o più nodi (operazioni concatenate: inserire molti nodi in
maniera atomica, cioè gli altri thread vedono (1) nessun nodo inserito o (2)
tutti i nodi inseriti, cioè sembrerà che i nodi siano stati inseriti tutti
in blocco) è un'operaz. relativamente lunga, dato che è anche necessario
ribilanciare l'albero. Se si sveglia un thread con priorità altissima (il
nocciolo sta per fondere!!!) e vuole accedere all'albero mentre un altro
thread è in una sezione critica, dovrà aiutare l'altro thread (per un totale
di 2 Thread-Switch "verso" e "da" il thread da aiutare) a terminare l'intera
operazione e questo può richiedere tempo.
In tutti e 3 i metodi (includendo anche il mio e parlando forzatamente di
"aiuti" anche nel metodo lockfree) si possono verificare varie possibilità:
a) riusciamo ad eseguire la nostra operazione senza incontrare ostacoli;
b) incontriamo un thread "fermo su un nodo", ma noi siamo di passaggio
quindi lo aiutiamo a proseguire del minimo indispensabile affinché possiamo
passare e andare per la nostra strada;
c) incontriamo un thread "fermo su un nodo" e dobbiamo aiutarlo fino alla
fine perché dobbiamo fare esattamente la sua stessa strada.
In realtà s'incontrano situazioni che sono una via di mezzo tra la (a) e la
(c). La (a) è molto probabile quando la struttura dati è molto grande e c'è
poca congestione, mentre la (c) è altamente improbabile perfino con molto
traffico ==> con un'altissima probabilità il tempo di attesa prima di
eseguire la nostra operazione sarà minimo.
Kiuhnm
P.S. E' vero, siamo OT, ma nella email ho un gran macello...comunque ho
finito con le dissertazioni :-)

 
http://www.the-underdogs.org/game.php?id=2435
Ti farò sapere che ne penso.
Kiuhnm


Infatti ho scritto "il tutto convertito in formato testo".
Il DOS non usa dei veri e propri operatori, ma dei comandi, come ben sai.
E' un po' come usare le funzioni del C anziché i più intuitivi e comodi
operatori del C++.
Al limite usiamo il mouse così siamo a posto. Quando l'autore dell'AT
ritiene che non sia sufficiente per es. richiedere che due oggetti vengano
combinati, farà apparire un piccolo menù dinamico con le opzioni...
Oppure manda dall'oculista i tuoi studenti! (magari sono soltanto daltonici
:-))))) )
Kiuhnm

 Come lo risolveresti?
Lavorandoci sopra parecchio in direzioni non formali :-)
Purtroppo per i prossimi anni non prevedo di poter fare ne' questo ne' 
altro, trovo solo lavori noiosi e poco redditizi che lasciano ben poco 
spaziotempo :-/
In ogni caso, la situazione dell'input e' ben descritta qui:
http://ars.userfriendly.org/cartoons/?id=20040616
Grazie per la panoramica sui waitfree/lockfree!
   .Erix.

 io provo ancora a insegnare il COPY di DOS agli allievi ingegneri
 > informatici e loro mi guardano come fossi un babbuino viola...
Beh, io non ti ho mai visto di persona, non posso confermare ne' 
smentire :-)
   .Erix. (che e' tornato alla linea di comando)

 E' un po' come usare le funzioni del C anziché i piů intuitivi 
 > e comodi operatori del C++.
Mi disattivo per non iniziare un flame OT :-)
   .Erix.

 
Il verbo potrebbe essere nella risposta del parser, ad esempio:
penna > gigi
'Consegni la penna al portiere della nazionale'
A me non sembra male come idea, però chi l'ha ideata deve per forza 
mettersi al lavoro ;-)

 'Consegni la penna al portiere della nazionale'
come dire: per risolvere il "guess the verb", togliamo ogni controllo al 
giocatore. E se io la penna gliela volevo ficcare nell'occhio? per me è 
un approccio assoluamente limitato... va bene per un esperimento, ma non 
ha senso discuterne come fosse un sistema generico/alternativo.
ciao
S

 mettersi al lavoro ;-)
E se il target è astratto? Come tradurresti
 >guarda fuori
bai
t

Inseguivo i banditi del tempo quando Stefano Gaburri scrisse...
 > i SO moderni usano la GUI
I SO moderni usano GUI e shell insieme, a seconda di cosa devi fare. :)
-- 
Atrus di Myst
"Be careful what you wish for. You never know who will be listening."
Or what, for that matter." -- Terry Pratchett
http://legendknights.tk

>> e <<< non esistono, ma rappresentano sempre un esempio di operatori.
Avrei potuto mettere qualcos'altro senza problemi, ma questi sono i piů
"belli" da vedere e linguaggi simili al C++ o estesi li supportano.
C:
b = BN_Init("3455333444543");
c = BN_Init("987766234545433");
d = BN_Init("8779767862347652");
e = BN_Init("89734987359873");
f = BN_Init("39828879898398");
a = BN_RRot(BN_Add(BN_Add(BN_RRot(BN_RRot(a, 3)),
    BN_Mod(BN_Mul(BN_LRot(b, 23), BN_RRot(c, 15)), f)),
    BN_Mul((BN_SHR(e, 2), f)), 3);
E potrei avere sbagliato qualche parentesi nella traduzione...
A me sembra un buonissimo esempio di codice offuscato, ma se vuoi proprio
farti male... :-)
Inoltre nota che č necessario inserire le due iniziali BN di BigNum,
altrimenti non potremmo distinguere tra operazioni per BigNum, BigFloat,
Matrix, ecc... (BN_RRot(), BF_RRot(), M_Mul())
Il C++ invece supporta l'overloading quindi sceglie automaticamente la
funzione giusta in base al tipo dei parametri.
Kiuhnm

 Grazie per la panoramica sui waitfree/lockfree!
Prego!
Kiuhnm

 generico/alternativo.
Infatti è per questo che ritengo che pochi operatori potenti risolverebberi
il guess the verb.
Al posto degli operatori si potrebbero usare i verbi PRENDI, DAI, ecc..., ma
è piuttosto osceno e inoltre avete notato quanta gente preferisce scrivere
"x window" anziché "examine window"?
Questo perché si tende ad evitare cose più lunghe e ripetitive e "x" è una
scorciatoia di indubbia utilità.
Allora perché non usare
penna > Giovanni
Per dare la penna a Giovanni?
Certo le azioni sono in qualche modo limitate anche qui.
Con il trascinamento delle parole, apparirebbe il seg. sotto-menù:
1) dare
2) infilare in un occhio
E' un male?
E' un bene che l'utente perda tempo a cercare d'infilare la penna negli
occhi a tutti i personaggi quando l'autore ha previsto questa opzione
soltanto per uno di essi, o è meglio dire esplicitamente al giocatore se
un'azione è possibile o non lo è?
Al limite si può mostrare l'azione per ogni personaggio o coppia di
oggetti/persone però credo che stresserebbe soltanto il giocatore, infatti
il gioco semplicemente si rifiuterebbe di farlo fornendo, nella più rosea
delle ipotesi, uno straccio di motivazione.
L'idea del controllo tramite mouse mi alletta sempre di più.
Inoltre l'esplorazione non avverrebbe eslusivamente tramite ipertesto (cosa
che, secondo me, disorienta), ma anche tramite nuove finestre (un po' come
quando si naviga e si tengono aperte varie finestre).
Per es. ammettiamo di dover portare molti oggetti da una stanza all'altra.
Non si potrebbe facilitare l'operazione permettendo al giocatore di tenere
aperte entrambe le finestre delle stanze?
Direi di permettere al giocatore di vedere tutti i luoghi direttamente
raggiungibili.
Per es., se hai già visitato tutta la case, dovresti poter scrivere "cucina"
per vedere apparire immediatamente la finestra con la descrizione della
cucina e il prompt.
Se invece la locazione (può essere anche un personaggio?)  non fosse
conosciuta o raggiungibile, basterebbe dirlo al giocatore.
Ho detto molte cose banali, ma a volte si danno per scontate e poi ci si
accorge che si partiva da premesse differenti.
Kiuhnm


"Who has time to read?" E' proprio vera 'sta cosa!
Giovanni
-- 
Giovanni Riccardi
personal: 
http://www.composizioni.net
   weblog: 
http://www.composizioni.net/addv
     work: 
http://www.anxur.it


Ah...
Kiuhnm

 "x window" anziché "examine window"?
Secondo me bisognerebbe andare verso qualcosa di simile allo SCUMM...
Da 4 a 10-12 verbi al massimo.
Si ripristina il buon vecchio USA e non se ne parla piu'.
Rob
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Da 4 a 10-12 verbi al massimo.
Anche io stavo pensando proprio al vecchio caro SCUMM...
Ignazio

 Anche io stavo pensando proprio al vecchio caro SCUMM...
Urka, ho pensato adesso che questa mi fa proprio meritare
il titolo di "nemico delle AT". ;)


 Si ripristina il buon vecchio USA e non se ne parla piu'.
No dai, usa è senza fantasia... alla fine diventa
una matrice di tentativi!!!
t

Ola',

Hai ragione Tomb, ma sai quanti "guess the verb" ti puo' evitare?


 Il C++ invece supporta l'overloading quindi sceglie 
 > automaticamente la funzione giusta in base al tipo dei parametri.
Per un valore abbastanza basso di "sempre" :-)
Pnso di essere stato tra i primi a usare il C++... e probabilmente 
anche tra i primi a considerarlo un pessimo esempio di design, dopo 
qualche anno di impiego.
   .Erix.

 preciso?
Sorry. Erata corige:
http://www.userfriendly.org/cartoons/archives/04jun/xuf006836.gif
   .Erix.

 una matrice di tentativi!!!
Non e' che col parser dopo un po' sia molto diverso.
   .Erix.

 
Beh ovvio, se è scritta coi piedi è anche peggio.
A me il guess the verb piace nel senso che se la storia,
le descrizioni, gli eventi sono combinati bene ti portano
nel peggiore dei casi a scoprire in un tempo relativamente
breve il verbo. E' sempre la stessa storia.
bai
t

Inseguivo i banditi del tempo quando Roberto Grassi scrisse...
 > Si ripristina il buon vecchio USA e non se ne parla piu'.
IMHO un "usa" globale potrebbe essere introdotto, però con le dovute misure.
- ci deve essere comunque la possibilità di usare un comando serio; "usa
forbici su carta" non deve annullare la possibilità di scrivere "taglia
carta con forbici"
- l'autore si mantiene comunque la possibilità di non far funzionare "usa";
cioè, se io scrivo "usa autocarro" il programma mi chiederà di essere più
specifico.
--
Atrus di Myst
"Susan knew that modern theory said that dreams were only images thrown
up while the brain was filing the day's events. She would have been more
reassured if the day's events had ever included flying white horses, huge
dark rooms and lots of skulls." -- Terry Pratchett
http://ladyblonde.net
 - L'episodio 9 è online!

 specifico.
D'accordo anche qui.


 parte, quello di world model!
ottenendo cosě Galaga... :)

Ola',

ROTFL! 8)


 scorciatoia di indubbia utilità.
ma cosa c'entra? x è solo una scorciatoia puramente lessicale, non 
c'entra assolutamente nulla con un operatore overloaded. L'overloading è 
precisamente quello che si deve _evitare_ perché scopo preciso 
dell'avventura è far sì che l'utente scopra i verbi (le azioni) 
originali escogitate dal progettista. Abolire i verbi è una livella 
totale che non risolve i problemi, semmai distrugge tutta la ricchezza 
del modello (e così facendo magari risolve anche i problemi connessi, ma 
con ben poco vantaggio).
A me pare che vogliate scrivere un gioco che fa tutto lui in vece (nei 
panni/al posto) del giocatore: scusate, ma continuo a preferire il 
contrario. Comunque senza offesa ma questa mi sembra un discussione 
assolutamente campata in aria, e me ne tiro fuori - invito chiunque a 
realizzare un prototipo anche microscopico che usi un approccio come 
quello ventilato in questo thread prima di riparlarne...
ciaociao
S

 qualche anno di impiego.
Non sono in molti a pensarla come te, infatti il C# riconferma il C++ con
piccole modifiche qua e là.
Più che altro sono stati eliminati problemi che il C++ ha ereditato
direttamente dal C.
Comunque qui siamo veramente OT.
Quale alternativa proporresti al C# o al C++?
Kiuhnm

 breve il verbo. E' sempre la stessa storia.
Hai mai giocato a "guess the verb"?
Giocarci è semplicemente stressante.
Kiuhnm

 c'entra assolutamente nulla con un operatore overloaded.
Sei tu che travisi qualsiasi cosa dica, quindi facciamola finita qui e amen.
Se sempre esclusivamente polemico e dimostri anche di non aver capito (o di
non voler capire) quello che si vuol dire.
Dovresti essere *molto* più elastico quando parli con gli altri e non
calpestare tutto e tutti, *IMHO*.
Kiuhnm

 calpestare tutto e tutti, *IMHO*.
Ne ho gia' parlato in un thread privato con Stefano.
Egli e' apodittico.
Bisogna solo 'pesare' quello che dice.
Mica e' la Madonna! 8)


  >guarda fuori
Out look 
-- 
Paolo Vece - 
pv...@mclink.it
 - 
http://www.vece.net

 ottenendo così Galaga... :)
Oppure Raskolnikov, a seconda dell'abilita' dell'autore :-)
   .Erix.

 Sei tu che travisi qualsiasi cosa dica, quindi facciamola finita qui e amen.
ma scusa come fai a mettere sullo stesso piano un operatore overloaded 
con l'uso di x per examine? Cos'è che non ho capito o non voglio capire?
S

 Quale alternativa proporresti al C# o al C++?
Dipende dall'uso. Ad esempio Lua + C, o Python + C per i programmatori 
object-dependent.
Io uso il C++ solo per la comodita' delle librerie Borland, ma ormai 
soltanto rigorosamente come super-C evitando accuratamente 
l'overloading e le conversioni automatiche (e quando mi serve 
flessibilita' gli metto dentro Lua).
   .Erix.

 flessibilita' gli metto dentro Lua).
Invece io uso C+asm, pensa un po'!
Però uso un compilatore C++ in modo da poter mantenere alcune comodità come
poter dichiarare le variabili quando voglio, ecc...
Ho usato molto il C++ per sviluppare un engine 3d 5 anni fa (i "soci" mi
hanno abbandonato e il progetto è naufragato...alla fine stavo facendo tutto
io, in pratica). Gli operatori e l'overloading sono una gran cosa, altroché!
Lì lavoravo coi quaterni, le matrici e i tensori (modulo per la simulazione
della fisica) e sarebbe stato un vero casino in C.
Kiuhnm

 Egli e' apodittico.
Anche te perņ...ho dovuto prendere il dizionario! :-)
Kiuhnm

 quello ventilato in questo thread prima di riparlarne...
Penso che bisognerebbe essere più umili nella vita e in particolar modo
quando ci si rapporta con gli altri.
Non puoi dire che tutti tranne te partecipano senza accorgersene a
discussioni "campate in aria", inoltre nessuno ha voglia di mettersi a fare
un prototipo solo per poterne poi riparlare con una persona così tanto alla
mano.
Kiuhnm

 Gli operatori e l'overloading sono una gran cosa, altroché!
Soprattutto quando tenti di rileggere il codice dopo 5 anni :-)
Comunque sia chiaro che io mi diverto a fare il bastian contrario, ma 
in realta' sono piuttosto pragmatico: in pratica uso quello che mi fa 
comodo in un dato momento, uso i linguaggi come la casetta degli 
attrezzi e non ne considero alcuno 'superiore' o 'inferiore' per 
principio.
E poi con te non c'e' molto divertimento a fare il bastian contrario: 
sei troppo ragionevole :-)
   .Erix.

Ho la forte impressione che quello che consigli tu sia, in fin dei
conti, mettere un parser da avventura grafica (*) in un'avventura
testuale.
(1) Ok, ok, le AG non hanno parser, ma avete capito quello che intendo
:)
La mia opinione è che alla fine tutte queste idee fanno fuori dal
seminato, e quindi bene o male devono essere ampiamente sperimentate
... certo è che se le avventure testuali hanno lo stesso parser da 30
anni ci sarà un motivo.
Pensate alle vostre avventure preferite e immaginatele col parser
mono-parola (2); quasi sicuramente arriverete ad un punto in cui vi
accorgerete che le cose non funzionano più. Perchè invece di partire
da un'idea di parser su cui costruire avventure non si parte invece da
un'idea/storia, e domandarsi: Qual'è il modo migliore per RACCONTARLA?
(2) Immaginate un'avventura in cui il protagonista ha una collana che
se baciata tre volte vi porta nel favoloso mondo dei Puffi. Il
protagonista ne scopre questa proprietà a metà gioco. Se all'inizio
del gioco, scrivendo "collana" si ha il menu
1) Esamina
2) Bacia
abbiamo già sputtanato il plot.
Se la possibilità 2) appare solo dopo aver scoperto la proprietà
magica della collana, abbiamo minato la rigiocabilità e ridicolizzato
il world model.
Aspetto commenti.
Saludos
         Kyoba

 Giocarci è semplicemente stressante.
Una buona avventura non contiene "guess the verb".
Per evitare quello famigerato di "Time Warp", per esempio, bastava un
po' di playtesting.

 sei troppo ragionevole :-)
Purtroppo o per fortuna sono fatto cosě... :-)
Kiuhnm


Il "guess the verb" è fisiologico nella AT con parser, c'è poco da fare.
Il "guess the right solution" inoltre è fisiologico nelle AG.
Almeno raggiungiamo il livello delle AG, dato che andare oltre e raggiungere
il livello degli RTS è quasi impossibile.
Kiuhnm

 il livello degli RTS è quasi impossibile.
beh, parte dei meccanismi dei mud vanno in quella direzione.
f.

 2) Bacia
La soluzione è semplice. "Bacia" non apparirà poiché il protagonista non ha
un motivo per farlo.
Ho detto più volte che i menù saranno dinamici.
Alcuni oggetti avranno 2 voci, mentre altri ne avranno 20, se necessario
(usando eventualmente anche sotto-menù, per comodità).
Kiuhnm

 beh, parte dei meccanismi dei mud vanno in quella direzione.
In che modo? Non ricordo piů...i mud sono rpg testuali?
Kiuhnm

 un prototipo solo per poterne poi riparlare  
scusa eh, ma è proprio quello che invece viene detto a tutti i 
programmatori che propongono una modifica o un'innovazione... di 
implementarla, cioè...

 Il "guess the right solution" inoltre è fisiologico nelle AG.
si chiama gameplay.

 Probabilmente ti hanno passato il codice di un pazzo 
Si', il mio :-)
   .Erix.

 overloading quasi dovuto.
A questo punto potrei ribattere che quel problema esiste anche usando le
funzioni al posto degli operatori..., ma non lo farò! ;-)
Kiuhnm


Però gameplay è un termine senza connotati positivi e/o negativi.
Potrebbe non essere un "buon gameplay".
Kiuhnm

 implementarla, cioč...
Perň alla bambina che propose di sgonfiare le ruote del camion per farlo
passare sotto il ponte non hanno chiesto di sgonfiarle da sola.
Kiuhnm

 un motivo per farlo.
Ma l'hai letto il resto del messaggio? :D


OK, ho saltato un pezzo. Non l'ho fatto volutamente.
Mi pare che questo sia un caso molto particolare.
Che cosa succede se il giocatore lo fa subito senza sapere niente della
collana?
La trama del gioco cambia? Si affrontano enigmi diversi?
Non credo.
Comunque ecco una possibilità: si usa un menù del tipo
- osserva
- prendi
- <altro>
Scegliendo <altro> apparirà un sotto-menù dove sarà possibile scegliere
altre azioni (suddivise per categorie). Se l'azione scelta sarà sensata,
verrà eseguita e aggiunta automaticamente al menù principale che diventerà:
- osserva
- prendi
- bacia
- <altro>
Dato che le combinazioni sono molte, sarà difficile (ma non impossibile)
arrivarci per puro caso.
A questo punto i vantaggi sono:
1) non è possibile scegliere sinonimi non previsti dall'autore;
2) le azioni più comuni (e sufficienti per risolvere il 99% degli enigmi)
sono già disponibili;
Kiuhnm

 passare sotto il ponte non hanno chiesto di sgonfiarle da sola.
pensavo fossi un programmatore, non una bambina... :)
ciao
S

 pensavo fossi un programmatore, non una bambina... :)
Sono una bambina programmatrice...
Kiuhnm

 In che modo? Non ricordo più...i mud sono rpg testuali?
I mud sono una marea di cose, ma in italia purtroppo sono principamente 
rpg testuali di ambientazione fantasy.
Grazie al cielo i mud non sono solo quello e gli aspetti più 
interessanti sono altrove, nei moo e nei mush e nella varie ibridazioni. 
In pratica, a differenza delle at, il guess the verb ha peso molto 
minore, in quanto si adatterebbe male ad un mondo nel quale si va e si 
torna in maniera ricorsiva.
Quello che importa è la crezione di un mondo verisimile che possa 
"funzionare" ed interagire con i giocatori: a differenza della at, 
quando il giocatore si stacca e smette di giocare, il mondo continua ad 
andare avanti.
I motori di verisimiglianza dei mud (di quelli buoni) sono anni luce 
avanti rispetto a quelli delle at, anche perché non possono se non in 
minima parte usufruire dello sviluppo narrativo tipico delle at.
In italia un buon esempio è the gate.
Esistono ovviamente eccezioni, tra cui il mud a cui collaborai io, che è 
in realtà una serie di at tra loro correlate attraverso meccanismo mud.
f.

 ad andare avanti.
Questo accade già con gli rpg online se non sbaglio.
Kiuhnm

 Questo accade già con gli rpg online se non sbaglio.
che come gameplay derivano proprio dai mud.
Giovanni
-- 
Giovanni Riccardi
personal: 
http://www.composizioni.net
   weblog: 
http://www.composizioni.net/addv
     work: 
http://www.anxur.it

 Questo accade già con gli rpg online se non sbaglio.
"Già" nel senso di "successivamente"?
f.

 si esce.
Nel linguaggio comune ricorsivo significa "ricorrente". Chevvoddě???
Per es. quanti rapporti sessuali ricorsivi hai avuto nella tua vita?
Kiuhnm

 "Già" nel senso di "successivamente"?
Già.
Kiuhnm

 Per es. quanti rapporti sessuali ricorsivi hai avuto nella tua vita?
L'etimologia è la stessa per le due parole (sempre da "ricorrere", che è 
dal latino "recurrere" = "correre indietro", nel senso di ritornare al 
punto di partenza). Anche se "ricorsivo" si usa più frequentemente nel 
linguaggio matematico/informatico ha più o meno lo stesso significato: 
una successione ricorsiva (che in molti libri americani di matematica, 
anche recenti, è chiamata "recurrence") "ritorna indietro" nel senso che 
ogni termine è ricavato dal precente. Anche se la matrioska da te citata 
(riferendoti alla ricorsività in programmazione) è giusta per rendere 
l'idea della ricorsività, questa si chiama così perché raggiunto 
l'ultimo passo della ricorsione si "torna indietro" nello stack.
Giovanni
-- 
Giovanni Riccardi
personal: 
http://www.composizioni.net
   weblog: 
http://www.composizioni.net/addv
     work: 
http://www.anxur.it

 Per es. quanti rapporti sessuali ricorsivi hai avuto nella tua vita?
heh, un esempio a caso!   :)))))
ciao
PS ok, lo dico:  "io per ora mi limito a iterare". Non sono riuscito a 
trattenermi...

 trattenermi...
Chissà se il "trattenermi" fa parte della battuta o no...
Kiuhnm

 della ricorsione si "torna indietro" nello stack.
Considera di avere 3 funzioni a(x), b(x), c(x), tali che a(x) chiama b(x) e
questa chiama c(x).
All'ultimo passo si torna indietro, ma non vedo ricorsione.
Il "tornare indietro" è proprio delle "strutture" annidate, non di quelle
ricorsive.
Si può pensare alla ricorsione come a un auto-annidamento.
La ricorsione avviene quando una funzione chiama se stessa ed esce dalla
ricorsione quando "ritorna" da un'altra istanza di se stessa.
Kiuhnm

 ricorsione quando "ritorna" da un'altra istanza di se stessa.
L'etimologia di un termine può anche non corrispondere perfettamente 
all'uso che se ne fa al giorno d'oggi. Forse l'esempio dello stack non 
era molto azzeccato. Ok. Mi sono (ri)documentato (avevo ricordi più o 
meno confusi sull'etimologia): "ricorsività" è stato formalizzato in 
matematica (Godel negli anni 30) per indicare funzioni che richiamano se 
stesse. Il concetto di "tornare indietro" (il perché si scelse proprio 
quel termine) è dato dal fatto che richiamando se stesse si deve 
eseguire prima un altro calcolo (un altro ancora fino alla base della 
ricorsione) per poi tornare indietro.
Sul fatto che poi la ricorsione venga spesso "confusa" (in senso 
etimologico) con l'effetto matrioska è una cosa abbastanza comune (ma 
non va bene fuori dall'ambito informatico) visto l'estremo fascino che 
quest'effetto ha sulle menti. La ricorsività è splendidamente descritta 
in uno dei miei libri preferiti, "Godel, Escher, Bach: un'eterna 
ghirlanda brillante" di D.R. Hofstadter con il concetto di "strano 
anello". Cito dal libro:
"Il fenomeno dello "Strano Anello consiste nel fatto di ritrovarsi 
inaspettamente, salendo o scendendo lungo i gradini di qualche sistema 
gerarchico, al punto di partenza"
Si torna indietro, quindi.


 Si torna indietro, quindi.
Quello che sto cercando di dirti è che questo fenomeno è condizione
necessaria, ma non sufficiente per avere la ricorsione.
Lo "Strano Anello" descrive perfettamente anche ciò che accade
nell'iterazione (pensa a cicli annidati).
Kiuhnm

 nell'iterazione (pensa a cicli annidati).
No, è diverso. Per vari motivi.
1) il libro parla di ricorsione. In effetti è tutto un discorso (con 
racconti, esempi, anche cose piuttosto comiche) sulla teoria della 
calcolabilità (il libro ha tra i "protagonisti" proprio Godel)e in 
questa si fa esplicito riferimento alla ricorsione e mai all'iterazione.
2) la citazione si capisce poco, messa così, ma il fulcro sta in quella 
parola "inaspettatamente" che nel descrivere l'iterazione non ci sarebbe 
stata.
3) non esiste in matematica alcuna definizione di annidamento, mentre 
esiste di ricorsione o iterazione.
4) a riconferma del mio esempio iniziale sullo stack, nel libro ad un 
certo punto l'autore inserisce un divertentissimo racconto (protagonisti 
Achille e la tartaruga del famoso paradosso) riguardante proprio 
l'annidamento in relazione alla ricorsione.
5) a conferma della definizione di ricorsività come di funzione che 
richiama se stessa, pensa alle funzioni mutuamente ricorsive: g chiama f 
che chiama g.
6) dove starebbe l'annidamento nell'iterazione? i cicli annidati sono 
così perché ce li vuoi mettere tu per fare una qualche operazione. Non 
sono caratteristici di una funzione. Ad esempio le seguenti due 
sommatorie annidate:
sum_{i=1}^{N} sum_{k=1}^{N} i*k
le puoi anche scrivere così:
sum_{i,k=1}^{N} ì*k
cioè "puoi contare i e k insieme". Questa la implementi con due cicli 
annidati anche se in Python puoi fare "for i, k in range(1,N)" ed è uno 
solo. In generale se l'insieme su cui variano due indici i e k sono 
diversi ("1...N" e "1...M" ad esempio) i cicli annidati restano due, ma 
sono comunque due cose separate (ad esempio le righe di una matrice, le 
colonne di un'altra). Cioè mi spiego meglio: l'annidamento 
nell'iterazione di cui parli è proprio della programmazione (e del 
linguaggio che usi) e non dell'algoritmo o della funzione che stai 
implementando. E comunque non caratterizza la funzione (cioè non ci sono 
proprietà della funzione che seguono dall'essere "annidata").
7) Tornando alla ricorsione. Supponi di avere un linguaggio di 
programmazione che non la supporta. Come fai ad implementare una 
funzione ricorsiva? (Senza barare e usare un'equivalente algoritmo 
iterativo, se esiste) Ti devi creare una pila e fare i tuoi bei "push" e 
"pop" e questo anche nel caso di cose più complicate come gli esempi che 
hai fatto in cui non sembra che si torni indietro ma invece si va 
avanti. E la pila la devi prima riempire e poi completamente svuotare 
(tornando indietro). L'algoritmo termina con lo svuotamento della pila.


 lo svuotamento della pila.
Allora tutte le funzioni che chiamano altre funzioni sono ricorsive, secondo
quanto dici. E' falso.
Lo vedi che si torna sempre a questo punto?
Kiuhnm
P.S. Non hai l'impressione che questa discussione sia ricorsiva?
IMHO, abbiamo entrambi ragione perché non siamo completamente d'accordo su
tante piccole questioncine...quelle che fanno sì che una goccia d'acqua
colpendo la punta di un cono non cada sempre nella stessa direzione :-)

 colpendo la punta di un cono non cada sempre nella stessa direzione :-)
Qualche tempo fa riflettevo sulla matematica e sul mio modo di 
pensare/comportarmi e mi è venuta fuori questa massima: "un matematico è 
colui che si crea i problemi per il gusto di poterli risolvere!".
Giovanni
PS: se vuoi continuiamo in privato...
PPS: Nei libri americani di matematica/informatica viene utilizzato 
l'aggettivo "recursive" ma quasi mai il sostantivo "recursion", che 
invece nella stragrande maggioranza dei casi viene sostituito da 
"recurrence"! (facci caso, se hai qualche libro a portata di mano).


 "recurrence"! (facci caso, se hai qualche libro a portata di mano).
google:
recursion programming    [178'000 risultati]
recurrence programming    [59'700 risultati]
Leggendo le varie pagine si vede inoltre che recursion è il più usato
(qualcuno mette inizialmente recurrence tra parentesi, ma poi usa sempre
recursion).
Non è che hai libri un po' datati? :-)
Se trovi frasi del "Thou shalt use this form when..." fai un aggiornamento.
Kiuhnm

(SCUSATE SE RISCRIVO IL MEX MA NON ERA MOLTO VISIBILE)
Per riallacciarmi all'idea dell'innovazione credo che IDRA e le evoluzioni
successive (parlo dell'integrazione degli OGGETTI) è un'ottima risposta
Lo sto provando in questi giorni con la trasposizione di un mio lavoro di
qualche anno fa e il risultato è incoraggiante!
Inoltre i limiti di programmazione di IDRA (vedi iterazione tra oggetto e
oggetto) sono assolutamente superabili con un pò di ingegno di
programmazione e un utilizzo di variabili Flag
Secondo me il futuro delle AT, inteso anche come possibilità di conoscenza
