[Python] Spirali di prova

[Utone]

Ciao a tutti,
è la prima volta che scrivo in questa sezione...
io sono un ragazzo all 3° anno all ITIS corso elettronico.
Facendo il python in sistemi ho visto che aveva questa interfaccia grafica allora ho provato a implementare un programmino...
Sembra funzionare tutto ma se badate bene nella seconda spirale la curva iniziale è meno accentuata di quella della prima spirale.
C'è un errore?

Il programma è allegato in zip...


Saluti

[^TiGeRShArK^]

così sulla fiducia senza guardare il codice ma solo le spirali direi che la tartaruga della seconda spirale parte con orientazione shiftata di 90 gradi in senso anti-orario....
quindi è come se si perdesse il primo step penso....

[^TiGeRShArK^]

visto il codice...
ma usare una funzione per disegnare la spirale in modo da richiamarla due volte con i parametri corretti anzichè scrivere due volte lo stesso codice?
In quel modo sei anche sicuro che le due spirali ti vengano identiche (se hai scritto correttamente il codice di inizializzazione nella funzione) e il tuo codice ne guadagna MOLTO in leggibilità

[Utone]

scusa ma come faccio a usare la stessa funzione per disegnarne 2??

[^TiGeRShArK^]

Originariamente inviato da Utone

scusa ma come faccio a usare la stessa funzione per disegnarne 2??

basta che gli passi i parametri corretti (tipo velocità e numero di giri).

def drawSpiral(speed, revolutions):
    ...
end

[Utone]

ah...
queste funzioni non le conosco ancora...

[Utone]

Il prof mi ha detto di fare cosi:

Originariamente inviato da mio_prof

Hai spostato la tartaruga, ma non hai rimesso l'angolo iniziale a zero.
Il disegno diverso dipende solo dall'angolo iniziale che è diverso per le due spirali.

Cambia le istruzioni

turtle.color('white')
turtle.sety(-100)
turtle.setx(100)
turtle.sety(0)

con

turtle.up() # alza la penna
turtle.goto(100,0) # spostata la tartaruga nel seguente punto (x,y)
turtle.setheading(0) # setta l'algolo della tartaruga a zero (uguale all'angolo iniziale)
turtle.down() # abbassa la penna

giustamente le spirali vengono uguali ma i tempi mettendo stesso numero di giri e stessa veloità vengono diversi

[Utone]

up

[Utone]

ho rifatto il programma con gli accorgimenti che mi hai detto...

eccolo

[^TiGeRShArK^]

meglio, vero?

[Utone]

sisi molto meglio...
il mio prof ha detto che i tempi non vengono uguale perchè windows non è un os real time e si accumulano vari errori..

[cdimauro]

ROTFL: questa mi mancava. Aspetta che annoto.

Quindi il tuo prof. queste prove le avrà fatte con s.o. come QNX immagino. Roba alla portata della gente comune, insomma...

[Utone]

forse mi sono spiegato male...
ecco quello che mi ha scritto

Originariamente inviato da mio_prof

Quando vale il tempo complessivo ?
Quanto vale l'errore percentuale ? 100*(t1-t2)/t2

I tempi diversi dovrebbero essere causati dal fatto che, per rallentare la tartaruga, viene richiamata una funzione che chiede al sistema operativo di avvertire quando è passato un determinato intervallo di tempo.

In pratica l'algoritmo esegue tante sequenze: traccia - aspetta .
Tanto più piccolo è l'intervallo di attesa, tanto più veloce è la tartaruga.

Il sistema operativo avverte l'applicazione della fine dell'intervallo desiderato con una certa imprecisione (normalmente >20ms).
Tale imprecisione è sempre presente nei sistemi operativi utilizzati dai PC, che non sono "real time".

La somma di tante piccole imprecisioni può diventare misurabile.

Se sei curioso e desideri maggiori informazioni, prova a leggere i seguenti articoli:

http://it.wikipedia.org/wiki/Multitasking
http://it.wikipedia.org/wiki/Scheduler
http://it.wikipedia.org/wiki/Sistema...tivo_real-time

Ciao

[cdimauro]

Rimane il fatto che anche un s.o. "real-time" ha un suo "tempo di risposta" che comporterà anch'esso una perdita di precisione che sarà, a sua volta, anch'essa misurabile (bisognerà semplicemente attendere più tempo per l'accumularsi degli errori).

Altra cosa, qui parla dell'intervallo di attesa e questo, più che sul fatto che il s.o. sia "real-time" o meno, dipende dalla precisione del timer interno utilizzato dal s.o. per dispatching degli eventi time-based.

In soldoni: possono esistere s.o. "non real-time" che, però, offrono timer a precisione molto elevata.

Per inciso: anche su Windows esistono timer come questi. Ecco qui http://www.mtsu.edu/~csjudy/directX/...anceTimer.html il primo link che ho recuperato sull'argomento.

[Utone]

Originariamente inviato da cdimauro

Rimane il fatto che anche un s.o. "real-time" ha un suo "tempo di risposta" che comporterà anch'esso una perdita di precisione che sarà, a sua volta, anch'essa misurabile (bisognerà semplicemente attendere più tempo per l'accumularsi degli errori).

Tutti i sistemi di misura hanno una loro imprecisione

Originariamente inviato da cdimauro

Altra cosa, qui parla dell'intervallo di attesa e questo, più che sul fatto che il s.o. sia "real-time" o meno, dipende dalla precisione del timer interno utilizzato dal s.o. per dispatching degli eventi time-based.

Il tempo può essere misurato con molta precisione anche con un sistema operativo normale, al limite si può utilizzare un orologio hardware che lavora per conto suo, magari sincronizzato con un orologio atomico.

Ma quello che ci interessa non è l'errore della misura di tempo, ma il ritardo con cui il sistema operativo richiama i vari task.

L'errore dipende dal tempo massimo che impiega il sistema operativo a restituire il controllo al programma che fa la misura. Nel caso di windows, tale errore può essere > 20ms.

E' vero che la precisione della misura dipende dal "timer interno" utilizzato, però occorre sempre aggiungere il ritardo (casuale) introdotto dal multitasking.

Se gli intervalli di tempo sono molto piccoli e si devono sommare fra di loro, come nel caso della misura di tante azioni "traccia-aspetta" che portano al disegno della spirale, la differenza di tempi fra due disegni diventa misurabile e significativa, indipendentemente dalla precisione del "timer interno".

Originariamente inviato da cdimauro

In soldoni: possono esistere s.o. "non real-time" che, però, offrono timer a precisione molto elevata.

Vero, però la differenza di tempo che hai osservato nel movimento a spirale della tartaruga, non è causata dalla imprecisione del timer utilizzato, ma dell'inevitabile errore introdotto dal multitasking. Tale errore diventa grande quando si sommano tante misure di tempo.

[cdimauro]

Indubbiamente, ma l'errore introdotto dal multitasking è praticamente ineliminabile (a meno che tu non abbia il pieno controllo del sistema, come quando su AmigaOS si eseguiva una chiamata all'API Disable() che disabilitava qualunque interrupt) anche in un s.o. realtime.

L'unica cosa che puoi fare è verificare mediamente a quanto ammonta il ritardo dovuto all'esecuzione dello scheduler e regolarti di conseguenza.

Altra cosa molto utile, puoi anche elevare la priorità del tuo processo a "real-time", mettendolo al di sopra persino di quasi tutti i processi del s.o. e, quindi, garantendoti praticamente quasi tutta la CPU.

Cose che, ad esempio, si fanno generalmente nei giochi per PC.

[Utone]

eh già!
sotto windows non si può avere un risultato perfetto...
comunque era solo una curiosità..
Grazie per il supporto!...