Thanks for the answer. I actually assumed that f>d puts exact 64 bit representation of a floating on the floating stack to the integer stack - nondestructively, even though it starts looking as an integer on the integer stack. Too sad it is not so.
This raises another question. Can anyone tell me a trick how to save and then restore floating stack numbers ( 1 or 2 ) for doing intermediate calculations which require all floating stack slots? When I do computations then saving iteration to an array in memory is fine. But for a sum when at each iteration I need to increment the same value fetching from/to memory seems costly (maybe I am wrong?) Thank you! On Sunday 11 June 2006 04:33, Bernd Paysan wrote: > On Sunday 11 June 2006 10:45, Sergey Plis wrote: > > Hi! > > > > It looks like there is one more bug. Looking at the session below you > > see that during conversion using f>d digits after decimal point are > > lost. Is this expected semantics or a bug? > > This is expected semantics - d is an integer. > > > order FLOAT FORTH FORTH ROOT FORTH ok > > !2 f>d ok > > .s <2> 2 0 ok > > d>f f. 2. ok > > !0.2 f>d ok > > .s <2> 0 0 ok > > d>f f. 0. ok > > !1.2 f>d ok > > .s <2> 1 0 ok > > d>f f. 1. ok > > > > Thank you! -- Sergey Plis PhD Candidate University of New Mexico --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
