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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Aug 13 12:47:04 UTC 2017


2017-08-13 12:13 GMT+02:00 Andrei Chis <chisvasileandrei at gmail.com>:

>
>
>
> On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at 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
>
>
Hi Andrei,
an image side modification is necessary if we want to gain more efficiency.
The question is whether we want to have correctly rounded results or not
for Integer>>nthRoot:.
If not, ((aNumber * self ln) exp) is OK (it can be a few ulp off as I told
before).
For Fraction, there's no point in rounding some term correctly then
spoiling by an inexact raisedTo: and an inexact /.
I started to look at it in Squeak (same code), then it will be time to port
in Pharo.

Nicolas


>
>> 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/8d2f20b6/attachment.html>


More information about the Vm-dev mailing list