I don't know what the context is of the numbers used in the fsoj example, but wouldn't the loss of precision be clearer if you used a simple, ascending sequence on the right? 29|15^10+i.12 13 21 0 0 0 0 0 0 0 0 0 0 29|15^ x: 10+i.12 13 21 25 27 28 14 7 18 9 19 24 12 15(29&|@^)10+i.12 13 21 25 27 28 14 7 18 9 19 24 12
On Sun, Jul 29, 2018 at 9:48 AM Henry Rich <[email protected]> wrote: > Special code is not the problem, it's the solution. The system is doing > what you ask of it. > > 15(^)22 5 3 20 15 18 > 7.48183e25 759375 3375 3.32526e23 4.37894e17 1.47789e21 > > ^ produces floating-point results. If they require more than 53 bits of > significance you will lose low-order bits and the result after dividing > by cs will be garbage. > > cs&|@^ takes the modulus after each multiplication and avoids the loss > of significance. > > Henry Rich > > On 7/28/2018 9:43 PM, Brian Schott wrote: > > Yes, the problem may be special code. > > I think I can see how to edit the fsoj now. > > Thanks, Raul > > > > On Sat, Jul 28, 2018 at 7:01 PM, Raul Miller <[email protected]> > wrote: > > > >> I do not think that this is 64 bit representation issue: > >> > >> 2^.15^22 > >> 85.9516 > >> 15(cs&|@^)22 5 3 20 15 18 > >> 6 10 11 24 14 9 > >> cs|15(^)22 5 3 20 15 18 > >> 0 10 11 0 0 0 > >> > >> I think it's a special code issue. I think the (cs&|@^) expression > >> gets handled by special code. > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > --- > This email has been checked for viruses by AVG. > https://www.avg.com > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- Devon McCormick, CFA Quantitative Consultant ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
