Re: \if

#80152
OldClaudio
Partecipante
    Up
    0
    Down
    ::


    Marco, il fatto che il tuo processore consenta la doppia precisione e ti garantisca 10 cifre significative “esatte” non credo che abbia nulla a che vedere con la precisione con cui pgfmath faccia i conti.

    il pacchetto fp (floating point) apparentemente garantisce un precisione quasi illimitata, ma è lento perché fa i calcoli simulando i contatori floating point di un processore a 64bit con un numero adeguato di contatori interi TeX, e simula i calcoli (che nella CPU vengono fatti con pochi cicli di clock) lavorando con una cifra alla volta come si farebbe a mano su un quaderno quadrettato.

    TeX fa conto solo con quantità intere.

    Calc e le nuove istruzioni di e-TeX (già incorporate in pdftex e xetex, i motori di composizioni “normali, e luatex che però può ricorrere ai calcoli in ambiente Lua) sembra che eseguano i conti con quantità fratte, ma in realtà lavorano con grandezze in punti espresse come valori interi di scaled points, ovvero, il che è in pratica lo stesso, con valori fratti in punti, a a virgola fissa e con 16 cifre binarie nella parte fratta. per la parte intera si arriva solo a 14 cifre binarie, quindi la massima grandezza in valore assoluto è di 16 384pt, anzi, per l’esattezza 16383.99999pt.

    Ne segue che il massimo numero di cifre fratte che si possono usare in aritmetica a virgola fisse, come quella che usano tex, pdftex, xetex, equivale ad una “precisione” di circa 5 o 6 cifre decimali fratte. Non puoi fare di meglio se non usare il pacchetto fp, che però è lentissimo.

    Tutto ciò premesso, i calcoli a virgola fisse implicano degli errori di troncamento o di arrotondamento ad ogni operazione eseguita, per cui le cifre “esatte” alla fine di qualunque conto sono meno di 5 cifre fratte.

    In qualunque corso di programmazione si insegna che i confronti con lo zero sono banali lavorando con gli interi, e sono difficili con i numeri fratti a causa di questi arrotondamenti e troncamenti. Il concetto sostanzialmente è che invece di confrontare qualcosa con lo zero bisogna confrontare il valore assoluto di quel qualcosa con un numero piccolo e non nullo. In termini logico-matematici in aritmetica finita a virgola mobile, bisognerebbe confrontare due quantità relativa, per esempio, detta D la distanza calcolata e D0 una distanza di riferimento bisognerebbe confrontare ` |D/D0| < epsilon` dove epsilon è una quantità positiva sufficientemente piccola, abbastanza minore di uno ma non così piccola da non poter essere rappresentata nell'aritmetica finita di TeX; potrebbe andare bene qualcosa come 0.001pt. Allora il test eseguito è vero se se il primo valore assoluto è minore di epsilon, vale a dire che in quel caso D si può considerare trascurabile rispetto a D0, quindi, scelto D0 in modo adeguato, ma in modo che sia paragonabile col il massimo delle addendi algebrici usati nei calcoli precedenti, allora D si può considerare nullo entro la tolleranza relativa stabilita con epsilon. Il fatto che possa impostare il limite del troncamento ad un valore qualsiasi con i comandi che presenti, non mi sembra una cosa da fare e lo considererei un bug di pgfmath se consente di farlo. Non sperare di poter mai ottenere differenze nulle fra distanze lavorando con i programmi del sistema TeX; Non ci riusciresti nemmeno se usassi triangoli pitagorei; nel momento in cui calcoli, per esempio, la radice quadrata di x al quadrato più y al quadrato dove x=3 e y=4, non sperare di ottenere 5; al meglio potrai ottenere 4.99973 oppure 5,00013 o cose del genere. Non voglio deprimerti con queste indicazioni, ma sperare di poter ottenere dei valori nulli eseguendo delle differenze fra numeri fratti è praticamente impossibile.

    Go to top