Anzi, a tal proposito, visto che qui ci sono persone che con la
matematica non se la cavano per nulla male, ed io invece ho FORTI
difficoltà , se qualcuno mi aiutasse a trasformare la formula in codice
gli sarei moooolto grato…
la formula in questione è la prima presente su
ed io l’ho implementata come:
@rata = c * ((1+ta/pa)(pa*a)) * ( (ta/pa) / ((1+ta/pa)(pa*a))-1)
il che ovviamente è sbagliato, ma data la mia scarsissima cultura
matematica è il massimo che posso raggiungere.
grazie anticipato a chi ci si cimenterà .
Giuliano U. ha scritto:
@rata = c * ((1+ta/pa)(pa*a)) * ( (ta/pa) / ((1+ta/pa)(pa*a))-1)
Non mi sembra sbagliata, però quando le formule sono co complicate mi
piace riscriverle in più step per mantenere chiarezza:
x = ta/pa
y = (1 + x) ** (pa * a)
@rata = c * y * x / (y -1)
Più leggibile no? 
On 6/7/07, Giuliano U. [email protected] wrote:
@rata = c * ((1+ta/pa)(pa*a)) * ( (ta/pa) / ((1+ta/pa)(pa*a))-1)
il che ovviamente è sbagliato, ma data la mia scarsissima cultura
matematica è il massimo che posso raggiungere.
grazie anticipato a chi ci si cimenterà.
Giuliano, scherzavo per la cosa del ‘**’ 
ma percè dici che la tua formula non va bene? sembra corretta rispetto al
documento che hai linkato.
hai problemi con le regole di conteggio dei giorni o con il tipo di
convenzione usata per l’accumulo degli interessi?
un qualche float che ti scappa da qualche parte forse?
On 6/7/07, Matteo V. [email protected] wrote:
On 6/7/07, chiaro scuro [email protected] wrote:
Io ti consiglio soltanto di scrivere dei test; prendi dei casi di cui
conosci il risultato, di solito sono i casi limite, e verifica che la tua
formula restituisca il risultato corretto con un test automatico
e aggiungo… dato che hai la formula excel… generati con excel un
megatabellone con dati di input e output per molti casi e usalo per
generare
un file cvs che guida i tuoi test.
On 6/7/07, chiaro scuro [email protected] wrote:
On 6/7/07, Giuliano U. [email protected] wrote:
@rata = c * ((1+ta/pa)(pa*a)) * ( (ta/pa) / ((1+ta/pa)(pa*a))-1)
il che ovviamente è sbagliato, ma data la mia scarsissima cultura
matematica è il massimo che posso raggiungere.
grazie anticipato a chi ci si cimenterà.
Io ti consiglio soltanto di scrivere dei test; prendi dei casi di cui
conosci il risultato, di solito sono i casi limite, e verifica che la
tua
formula restituisca il risultato corretto con un test automatico
M
chiaro scuro wrote:
e aggiungo… dato che hai la formula excel… generati con excel un
megatabellone con dati di input e output per molti casi e usalo per
generare
un file cvs che guida i tuoi test.
Io aggiungerei il cosiglio di evitare i float per i calcoli decimali che
devono essere precisi poiche i float sono una approssimazione binaria
dei numeri reali e possono capitare cose “spiacevoli” tipo:
irb(main):002:0> a = 1.20 - 1.00
=> 0.2
irb(main):003:0> b = 0.20
=> 0.2
irb(main):004:0> a==b
=> false
(vedi anche questo thread: Using Float For Currency - Ruby - Ruby-Forum )
ciao,
Luca
–
On 6/7/07, Luca M. [email protected] wrote:
irb(main):004:0> a==b
=> false
(vedi anche questo thread: Using Float For Currency - Ruby - Ruby-Forum )
Heh. Non è un discorso semplice… che vuol dire “preciso”? Supponiamo
che
evitiamo di usare Float, e rappresentiamo i soldi come un numero intero
di
centesimi. Allora 100 euro sono rapprestentati dall’intero 10000. Ma
cosa
succede se devo dividere 100 euro in 3 pagamenti? Dove finisce il
centesimo
che balla? (Vedi il pattern Money di
Fowlerhttp://www.martinfowler.com/eaaCatalog/money.html
)
In molti casi Float è un’approssimazione accettabile; tieni però conto che
non si devono mai confrontare due Float con ==. L’uguaglianza fra
numeri in
virgola mobile si fa sempre “a meno di un epsilon”, quindi invece di
a == b
devi testare
abs(a - b) < epsilon
dove epsilon è un numero che in teoria dipende dalla precisione della tua
macchina, ma che puoi, se (come me) ignori la teoria, sostituire con un
numero molto piccolo tipo 1e-8 (dipende anche dalla tua applicazione).
M