I do not know what you are thinking, and you have not illustrated your
thoughts sufficiently for me to grasp them.

So, I thought I'd work through this:

   (14^2) (] - [ * _1 + [: <. ] % [)5729082486784839
147
   (14^2x) (] - [ * _1 + [: <. ] % [)5729082486784839x
343

Clearly, the exact answer is different from the quick answer.

If we compare
   load'debug/dissect'
   dissect '(14^2) (] - [ * _1 + [: <. ] % [)5729082486784839'
   dissect '(14^2x) (] - [ * _1 + [: <. ] % [)5729082486784839x'

We can see the initial off-by-one errors, but the big difference shows
up at the end (where we subtract from 5729082486784839)

The value we are subtracting is:

   (14^2x) ([ * _1 + [: <. ] % [)5729082486784839x
5729082486784496
   (14^2) ([ * _1 + [: <. ] % [)5729082486784839
5.72908e15

Looking at the bits needed to represent that as an integer:

   2^.(14^2) ([ * _1 + [: <. ] % [)5729082486784839
52.3472

we can see that that's right on the edge of being the number of
representable digits in a 64 bit float.

But, also, it's the result of multiplying

   14^2
196

by an off-by-one amount. And...

   343-196
147

...

Anyways, I'm not sure what you were thinking, but I guess we can take
this as a good example of the idea that errors can actually
accumulate.

Thanks,

-- 
Raul


On Mon, Sep 11, 2017 at 9:07 AM, Erling Hellenäs
<erl...@erlinghellenas.se> wrote:
> As we can see here, J does not lose precision if you do the calculations
> which seem to be needed. Floor gives an incorrect answer, probably because
> of comparison tolerance. I correct it with the " _1 + ". It is not obvious
> that you have to lose precision here. Is it a bug?
>
> (14^2) (] - [ * _1 + [: <. ] % [)5729082486784839
>
> 147
>
>
> /Erling
>
>
>
>
> Den 2017-09-08 kl. 15:21, skrev Erling Hellenäs:
>>
>> Hi all !
>>
>> It seems an IEEE double can hold this value without lost precision. I
>> don't know what might happen in the calculations. Where the precision is
>> lost. Maybe something with comparison tolerance.
>>
>>      5729082486784839 - 5729082486784839 - 0.999
>>
>> 1
>>
>>
>> JWithATwist does not lose precision. Here with integer and float right
>> argument.
>>
>>
>> { ( 14 ^ 2 ) {! ] - [ * |<. ] % [  } 1.0 * 5729082486784839 }
>>  147
>> { ( 14 ^ 2 ) {! ] - [ * |<. ] % [  } 5729082486784839 }
>>  147
>>
>>
>> Cheers,
>>
>>
>> Erling Hellenäs
>>
>>
>> Den 2017-09-08 kl. 13:19, skrev Erling Hellenäs:
>>>
>>> Case 3 seems to be working in the latest Beta(8.06.03). The problem seems
>>> to be solved. /Erling
>>>
>>>      3!:0 (x: n^2)
>>>
>>> 128
>>>
>>>      (x: n^2) | 5729082486784839
>>>
>>> 147
>>>
>>>     3!:0 (x: n^2)
>>>
>>> 128
>>>
>>>
>>> Den 2017-09-07 kl. 20:40, skrev Erling Hellenäs:
>>>>
>>>> Hi all !
>>>>
>>>> Case 1:
>>>>     3!:0 [ (n^2)
>>>>
>>>> 8
>>>>
>>>>      (n^2) | 5729082486784839
>>>>
>>>> 0
>>>>
>>>> It is non-intuitive that an integer raised to an integer is a float, but
>>>> I think it is normal. It would be possible with a performance penalty to 
>>>> get
>>>> an integer result. One problem with that is that it would easily overflow.
>>>> It would also be possible to have a special operation for this case.
>>>> When the left argument is a float the right argument has to be converted
>>>> to a float. It must be assumed that this conversion is intentional, even
>>>> though it is implicit.
>>>>
>>>> Case 2:
>>>>      3!:0 [ (n^2)
>>>>
>>>> 8
>>>>
>>>>      (n^2) | 5729082486784839x
>>>>
>>>> 0
>>>>
>>>> 3!:0 (n^2) | 5729082486784839x
>>>>
>>>> 8
>>>>
>>>> Here the rational seems to be converted to a float and the result is
>>>> float. Shouldn't we have an error instead of converting rationals to float?
>>>>
>>>> Case 3:
>>>>
>>>> 3!:0 (x: n^2)
>>>>
>>>> 128
>>>>
>>>>      (x: n^2) | 5729082486784839
>>>>
>>>> 0
>>>>
>>>> 3!:0 (x: n^2) | 5729082486784839
>>>>
>>>> 128
>>>>
>>>> I have a hard time understanding what happens here. This result seems
>>>> very peculiar. Is the left and right argument converted to float and the
>>>> float result converted to rational?!
>>>> Shouldn't we have an error instead of converting rationals to float?
>>>> We could not have floats auto-converted to rationals?
>>>> In this case the integer should be converted to rational and we should
>>>> get a rational result?
>>>>
>>>> It is non-intuitive that (*: n) does not give the same result as (n^2).
>>>> Maybe once this was decided because of performance reasons.
>>>>
>>>> Cheers,
>>>>
>>>> Erling Hellenäs
>>>>
>>>> On 2017-09-05 18:41, Rob B wrote:
>>>>>
>>>>> Could someone explain this please?
>>>>>
>>>>>   n=.14
>>>>>     n
>>>>> 14
>>>>>     (*: n) | 5729082486784839
>>>>> 147
>>>>>     196 | 5729082486784839
>>>>> 147
>>>>>     (n^2) | 5729082486784839
>>>>> 0
>>>>>     (n^2) | 5729082486784839x
>>>>> 0
>>>>>     (x: n^2) | 5729082486784839
>>>>> 0
>>>>>     (x: n^2) | 5729082486784839x
>>>>> 147
>>>>>
>>>>>
>>>>> Regards, Rob Burns
>>>>> ----------------------------------------------------------------------
>>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>
>>>
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
>
> ----------------------------------------------------------------------
> 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