> Still, if #: o (<. o o.) Y is an exact result, I am surprised that the > error in the other results is not closer to the 53rd bit.
These things are usually subject to tolerance (default value, 2^_44). On Sat, Jul 7, 2012 at 10:44 AM, Raul Miller <rauldmil...@gmail.com> wrote: > On Fri, Jul 6, 2012 at 7:18 PM, Jose Mario Quintana > <jose.mario.quint...@gmail.com> wrote: > > o=. @: > > Y=. 10x&^20 > > ((#: o (<. o o.)) -: ((#: o <.) o o.)) Y > > 0 > > > > Special code seems to be involved because, > > f=. #: > > g=. <. > > h=. o. > > ((f o (g o h)) -: ((f o g) o h)) Y > > 1 > > The variant result is from #: o (<. o o.) Y and a close inspection > shows that it's a problem in the 42nd bit of a floating point result. > > So the issue here is probably the special code described at: > > http://jsoftware.com/help/dictionary/special.htm > > <.@f both also >.@f ; avoids non-integer intermediate results on > extended precision integers > > Still, if #: o (<. o o.) Y is an exact result, I am surprised that the > error in the other results is not closer to the 53rd bit. > > (And, as an aside, personally, I much prefer that this kind of > inconsistency be directly visible, instead of having it concealed from > me by a type system.) > > -- > Raul > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm