[Vm-dev] vm problem on cog and stack spur

[Nicolas Cellier]

Hi Levente, thank you.
Here is a follow up:

I was able to reproduce the same symptom on the classical interpreter VM.
<rant> It's just that for MacOSX, there is no recent VM available, and that
the MacOS build is somehow abandonware, so it took much more time than
necessary :( </rant>

So the changes that have been integrated on Interpreter Vm in july 2014 and
that I thought correct were not.
It's certainly related to a LargeInteger plugin primitive.
Those are triggered when nbits of magnitude > 64.
(otherwise, <= 64 bits, the LargeInteger numbered primitives do their job).

Now the job is to produce/isolate an elementary failing LargeInteger test.
But you need to generate the VM from VMMaker.oscog head for COG/STACK
V3/SPUR 32/64 bits
or use a sufficiently recent interpreter VM (> july 2014) to trigger such
failure.


--------------------------------------------

Here is my starting point:

If you load ArbitraryPrecisionFloat and Tests from
http://www.squeaksource.com/ArbitraryPrecisionFl
then you'll see this strange pattern:

(53 to: 70) collect: [:i |
    i -> (10 asArbitraryPrecisionFloatNumBits: i) erf ]

 {53->(ArbitraryPrecisionFloat readFrom: '0.9999998981732067' readStream
numBits: 53) .
 54->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 54) .
 55->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 55) .
 56->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 56) .
 57->(ArbitraryPrecisionFloat readFrom: '0.99999989817320666' readStream
numBits: 57) .
 58->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 58) .
 59->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 59) .
 60->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 60) .
 61->(ArbitraryPrecisionFloat readFrom: '0.9999998981732066655' readStream
numBits: 61) .
 62->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 62) .
 63->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 63) .
 64->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 64) .
 65->(ArbitraryPrecisionFloat readFrom: '0.99999989817320666564' readStream
numBits: 65) .
 66->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 66) .
 67->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 67) .
 68->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 68) .
 69->(ArbitraryPrecisionFloat readFrom: '0.999999898173206665646'
readStream numBits: 69) .
 70->(ArbitraryPrecisionFloat readFrom: '1.0' readStream numBits: 70)}

The value seems incorrect every four numbits
The exact value is near 1- 2.0e-45, and given the insufficient precision
requested, the result should be rounded to 1.
We can confirm with online high precision erf calculator like found for
example with http://keisan.casio.com/exec/system/1180573449

Or we can check with
(10 asArbitraryPrecisionFloatNumBits: 200) erf (ArbitraryPrecisionFloat
readFrom: '0.999999999999999999999999999999999999999999997911512416237455'
readStream numBits: 200)

-----------------------------

Note that when I change the LargeInteger digitLength to 32bits instead of 8
(my own VM branch) then the problem magically disappear.

I plan to introduce these change in the VMMaker.oscog, so I can as well
ignore the problem and proceed, however I much prefer to isolate it, and
understand it for gain of knowledge :)


2016-03-27 4:27 GMT+02:00 Levente Uzonyi <leves at caesar.elte.hu>:

>
> Hi Nicolas,
>
> If you give us a bit more detailed instructions about what to test, then
> we might be able to help you get this sorted out.
>
> Levente
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160327/799a6448/attachment-0001.htm