Come posso gestire le lancette dell'orologio usando il doppio che soffre al massimo di O (log n) bit corrotti all'ennesimo fotogramma del display?

Question

Come posso gestire le lancette dell'orologio usando il doppio che soffre al massimo di O (log n) bit corrotti all'ennesimo fotogramma del display?

#1 da (2 voti)

0

Attualmente ho un'app di orologio che calcola da zero ad ogni iterazione. Ciò significa O (1) bit corrotti nella mia creazione di doppi e oggetti pesanti e cancellazione anche.

Sono diffidente nell'eseguire calcoli indefiniti con doppi o altri float perché i bit corretti di O (n) normalmente accompagnano ogni passo.

Vorrei sapere se esiste un modo alternativo (in un'app iOS) per trasformare e posizionare le lancette dell'orologio con O (1), o forse O (log n), bit corrotti dopo n passaggi.

In particolare, mi chiedevo quale sarebbe stata la corruzione per "Ad ogni passo, ruota ogni mano nella posizione zero, ovvero una trasformazione di rotazione affine di -1 * l'ultima rotazione ricevuta dalla mano, quindi ruota in avanti di la nuova angolazione che la mano dovrebbe avere in questa fase. " Nell'aritmetica in virgola mobile di Objective-C, non è mai il caso (escludendo eccezioni come un valore che indica un numero è corrotto) che x - x! = 0,0 esattamente? I casi che ho visto che illustrano i bit di danneggiamento in virgola mobile includono Python che dice che 1.1 + 1.1 + 1.1 - 3.3! = 0.0; Non ho visto esempi da manuale del modulo x - x! = 0.0.

Questa non è esattamente la questione se un'immagine raster trasformata dall'angolo x e poi dall'angolo -x è il suo sé originale; potrebbe essere che il suggerimento precedente funzionasse bene per errore O (1) sugli angoli ma corruzione usuale nell'immagine disegnata e trasformata.

Qual è la minima "complessità della corruzione", che significa pochi bit corrotti alla fine dei calcoli n, per il rendering di un orologio? Esistono approcci O (1) o O (log n)?

Grazie,

errors floating-point complexity graphics

posta JonathanHayward 13.10.2013 - 00:30

fonte

1 risposta

Leggi altre domande sui tag errors floating-point complexity graphics

simbolo dell'attributo design della lingua OOP [chiuso] Condizioni multiple in una funzione utilizzando PSR

score 2 · Accepted Answer

Per calcoli come questo non devi davvero preoccupartene. Almeno non molto.

Assicurati di non accumulare l'errore su troppe iterazioni. Qui troppi significano qualcosa come milioni. Ci vogliono secoli prima che l'errore si avvicini allo 0,1%. In dubbio, usa il doppio anziché il float.

I would like to know if there is an alternate way (in an iOS app) to transform and position clock hands with O(1), or maybe O(log n), corrupt bits after n steps.

Non pensare a corruzione e bit . C'è qualche errore numerico e ci sono alcune regole non esattamente semplici per delimitarla. Per quanto riguarda l'errore assoluto sei al sicuro a meno che non ti occupi di numeri molto grandi o dividi per qualcosa vicino allo zero. Quindi sei al sicuro.

is it ever not the case (excluding exceptions like a value indicating a number is corrupt) that x - x != 0.0 exactly?

Non ho mai visto Objective-C, ma sono perfettamente sicuro che x - x == 0 .

Python saying that 1.1 + 1.1 + 1.1 - 3.3 != 0.0

Sì, va bene. Regola 1: Non confrontare mai mai due numeri in virgola mobile per l'uguaglianza. C'è sempre qualche errore. Regola 2: l'errore è molto piccolo. In questo esempio è 4.44e-16 (sta usando double piuttosto che float ). Ora immagina quale impatto terribile può avere sulle tue lancette dell'orologio.

What is the minimum "corruption complexity", meaning fewest corrupt bits at end of n calculations, for rendering a clock? Are there O(1) or O(log n) approaches?

Suppongo che non ci sia un approccio di tipo O (1), a meno che tu non sia in grado di convertirlo in aritmetica in virgola fissa perché altrimenti c'è sempre la possibilità che l'errore aumenti a causa dell'arrotondamento.

Suppongo che il modo normale e stupido (supponendo che tu stia facendo rotazioni tramite moltiplicazioni di matrice) aumenta l'errore come O (n). Quindi dopo 1e9 iterazioni si ottiene un errore come 4.44e-7. Niente di cui preoccuparsi.