> 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

Reply via email to