# vm crash when using rairedTo: with fractions

10 messages
Open this post in threaded view
|

## vm crash when using rairedTo: with fractions

Open this post in threaded view
|

## Re: vm crash when using rairedTo: with fractions

Open this post in threaded view
|

## Re: vm crash when using rairedTo: with fractions

Open this post in threaded view
|

## Re: vm crash when using rairedTo: with fractions

Open this post in threaded view
|

## Re: vm crash when using rairedTo: with fractions

Open this post in threaded view
|

## Re: vm crash when using rairedTo: with fractions

Open this post in threaded view
|

## Re: vm crash when using rairedTo: with fractions

Open this post in threaded view
|

## Re: vm crash when using rairedTo: with fractions

 Is this enough? Fraction >> nthRoot: aPositiveInteger     "Answer the nth root of the receiver."     | d n |     n _ numerator nthRootTruncated: aPositiveInteger.     (n raisedTo: aPositiveInteger) = numerator ifFalse: [         ^self asFloat nthRoot: aPositiveInteger ].     d _ denominator nthRootTruncated: aPositiveInteger.     (d raisedTo: aPositiveInteger) = denominator ifFalse: [         ^self asFloat nthRoot: aPositiveInteger ].     ^n / d Seems to work ok in Cuis. Thanks, On 8/13/2017 9:47 AM, Nicolas Cellier wrote: ` ` 2017-08-13 12:13 GMT+02:00 Andrei Chis :   On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier wrote:   2017-08-10 22:19 GMT+02:00 Andrei Chis :   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 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 :   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 ```-- Juan Vuletich www.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev @JuanVuletich```