[Vm-dev] vm crash when using rairedTo: with fractions

[Andrei Chis]

On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <nicolas.cellier.aka.nice@
gmail.com> wrote:

>
>
>
> 2017-08-10 22:19 GMT+02:00 Andrei Chis <chisvasileandrei at gmail.com>:
>
>>
>> Hi Nicolas,
>>
>> Thanks for the info. Indeed sending #asFloat to the operand leads to a
>> correct behaviour.
>>
>> Just then is there a need for this special use case for handling
>> Fractions if it can lead to such problematic behaviour? Would the
>> logarithmic way ((aNumber * self ln) exp) not be enough? On this example
>> the computation takes a few minutes before crashing the image.
>>
>>
> Having (1/1000 raisedTo: 2/3) = (1/100)  is a nice thing and we want to
> keep it.
>

Indeed, it's a nice to have feature.


> But once we detect that we can't have an exact result, we should adopt a
> more efficient strategy.
>

Do you know if the vm plugin fix from Eliot addresses also this or there
should some more actions taken on the image side?


>
> There are corner cases where we want to avoid overflow/underflow in
> intermediate values, such as (1<<2000 + 1) raisedTo: 1/200 or ((1<<2000 +
> 1) reciprocal raisedTo: 1/200, so we must not convert asFloat too soon.
> But since ln already handles those edge cases (at least in Squeak, I have
> to check Pharo), ((aNumber * self ln) exp) is a good approximation (a few
> ulp off, depending on the quality of underlying libm).
>

For now I switched to using ((aNumber * self ln) exp)  and it's working
well.

Cheers,
Andrei


> Nicolas
>
>
>> Cheers,
>> Andrei
>>
>> On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>>
>>> Hi Andrei,
>>> indeed, the method does not scale well...
>>>
>>> If the result is an exact Fraction, then it will answer the Fraction.
>>> Else if not exact, it will be converted to a Float.
>>>
>>> The problem is that it will try to answer nearest Float with a rather
>>> naive algorithm.
>>> Moreover, computing the nthRoot: first, then raising the result to the
>>> power of numerator will cumulate rounding errors.
>>> So trying to get a very accurate nthRoot: first in case of Float result
>>> is not a good strategy anyway.
>>>
>>> Why the VM crashes exactly is another problem and remains to see, we'd
>>> prefer an Exception.
>>>
>>> As a workaround, I suggest sending asFloat to the receiver and/or
>>> operand.
>>>
>>>
>>> 2017-08-10 12:02 GMT+02:00 Andrei Chis <chisvasileandrei at gmail.com>:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I was executing this code  '(2009/2000) ** (3958333/100000)' with the
>>>> Pharo6.1 distribution and the vm crashed with she stack attached below.
>>>> Tried it on both mac and windows 10.
>>>> Seems that #raisedTo: has a special case for fractions that ends up
>>>> calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.
>>>>
>>>> Cheers,
>>>> Andrei
>>>>
>>>>
>>>> 0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n)
>>>> LargePositiveInteger
>>>> 0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n)
>>>> LargePositiveInteger
>>>> 0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n)
>>>> LargePositiveInteger
>>>> 0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n)
>>>> LargePositiveInteger
>>>> 0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350:
>>>> a(n) LargePositiveInteger
>>>> 0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350:
>>>> a(n) LargePositiveInteger
>>>> 0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
>>>> 0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
>>>> 0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
>>>> 0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
>>>> 0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
>>>> 0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
>>>> 0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n)
>>>> RubSmalltalkEditor
>>>> 0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n)
>>>> RubSmalltalkEditor
>>>> 0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint
>>>> 0x3062fdc8: a(n) GLMMorphicPharoScri
>>>> enderer
>>>> 0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
>>>> 0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
>>>> 0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
>>>> 0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
>>>> 0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
>>>> 0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
>>>> 0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
>>>> 0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
>>>> 0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
>>>> 0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
>>>> 0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n)
>>>> MorphicUIManager
>>>> 0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170813/45a2ddba/attachment.html>