Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Tempo in treno

14 views
Skip to first unread message

Just Time

unread,
Nov 3, 2015, 4:30:02 AM11/3/15
to
Sono moltissimi anni che sviluppo software a scopo dilettantistico ed
ho prodotto un gran numero di progetti in ambiente VISUAL BASIC 6.0 ma
i misteri non finiscono mai.
L'ultimo progetto, che registra gli orari ferroviari e le durate dei
viaggi, mi presenta risultati non troppo esatti: un viaggio con
partenza alle 22:03 ed arrivo alle 07:15 dura 9 ore, 12 minuti, 0
secondi. Ma il software mi risponde con: 9 ore, 11 minuti e 59,99
secondi, ossia si "pappa" un centesimo di secondo.
Qualcuno mi svela l'arcano, ignorando l'esiguità della differenza ai
fini pratici e con esplicito riferimento all'aspetto tecnico?

--
CobraOne

GIulia

unread,
Nov 8, 2015, 12:10:02 PM11/8/15
to
Just Time ha scritto:
la funzione modulo sbaglia da qualche parte o arrotonda male.

Giulia

aller...@gmail.com

unread,
Dec 11, 2015, 7:24:01 AM12/11/15
to

Da come e` descritto il problema sembra che sia stato usaato il tipo di dato temporale fornito dall'ambiente di sviluppo (VB6), o qualunque cosa usata sembra leggermente difettosa nella differenza tra datetime.

Comunque quando la precisione e' al centesimo di secondo, il valore
ad esempio 23:59:59.99 essendo indefinito al di sotto del centesimo,
potrebbe rappresentare valori veri da
23:59:59.9999999999999999999999999999999999999... fino a
23:59:59.980000000000000000000000000000000...0001
(notare che questo e` un intervallo di 0.02s (piu` precisamente di 0.019999999999999999999999999999999999999...) dato dall'indefinito)



particolarmente manca la definizione dell'imprecisione al centesimo di secondo, ha senso preferibile restringere la rappresentazione verso un intervallo probabilistico di lunghezza 0.010000000000000000000000000000000000s scelto tra gli estremi menzionati, da ripetere contiguamente per ogni rappresentazione di centisecondo.
Questo modo di verere i centisecondi permette di confermare la preferibile giustezza che vede un errore di +-0.005s anziche` +-0.01s.


Trattando al meglio differenti momenti temporali campionati al centesimo di secondo e` ottimale sia nel senso di probabile esattezza che di leggibilita` nei casi in cui i dati sono campionati con precisione al secondo, non avere quella sottrazione di 1centisecondo.

Io metterei verificherei i valori ritornati da differenze
1. nello stesso giorno,
2. in in giorni consecutivi
3. in in giorni piu` distanti


se c'e` sempre 0.01s meno, potresti creare una funzione che calcola differenza di orari chprima e verifica con due costanti che la differenza e` sbagliata di 0.01s (la libreria potrebbe essere aggiornata e corretta in futuro) e SE lo e` con le costanti ritorna la differenza con i numeri in input aggiungedo 0.01s correttivi.



Ancora piu` importante: Ci vuole molta cautela con date e orari perche` particolarmente gli orari di viaggio sono espressi in ora locale, per tragitti internazionali potrebbe essere necessario convertire ore locali (che cambiano in senso dell'ora legale con normative dei paesi che cambiano nel corso degli anni (non tutti i paesi adottano l'ora legale, alcuni cominciano a farlo recentemente)

Saluti,
MARco
Nota: Rispondo a questo secondario problema per verificare la vivacita' del newsgroup it.scienza.informatica
--
x(t),y(t) = th(3t-34.5)*e^[-(3t-34.5)^2]/2-4.3+e^(-1.8/t^2)/(.8*atg(t-
3)+2)(t-1.8)-.3th(5t-42.5),(1.4e^[-(3t-34.5)^2]+1-sgn[|t-8.5|-.5]*1.5*
|sin(pi*t)|^[2e^(-(t-11.5)^2)+.5+e^(-(.6t-3.3)^2)])/(.5+t)+1 ; 0<t<14
0 new messages