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 
Hi Andrei, indeed, the method does not scale well...Else if not exact, it will be converted to a Float. 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. 20170810 12:02 GMT+02:00 Andrei Chis <[hidden email]>:

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. Cheers, Andrei On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <[hidden email]> wrote:

20170810 22:19 GMT+02:00 Andrei Chis <[hidden email]>:
Having (1/1000 raisedTo: 2/3) = (1/100) is a nice thing and we want to keep it. But once we detect that we can't have an exact result, we should adopt a more efficient strategy. 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). Nicolas

In reply to this post by Andrei Chis
Hi Andrei,
On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <[hidden email]> wrote:
The plugin is now fixed; see VMMaker.oscogeem.2262. I'll generate code soon (am debugging something you're familiar with that takes several hours to run and don't want to generate sources while it's running). But I'm glad you've found a better way! This case creates 600k byte large integers and takes forever to run :)
_,,,^..^,,,_ best, Eliot 
On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <[hidden email]> wrote:
Nice! Thanks for the fix. Cheers, Andrei

In reply to this post by Nicolas Cellier
On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <[hidden email]> wrote:
Indeed, it's a nice to have feature.
Do you know if the vm plugin fix from Eliot addresses also this or there should some more actions taken on the image side?
For now I switched to using ((aNumber * self ln) exp) and it's working well. Cheers, Andrei

20170813 12:13 GMT+02:00 Andrei Chis <[hidden email]>:
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

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:
 Juan Vuletich www.cuissmalltalk.org https://github.com/CuisSmalltalk/CuisSmalltalkDev @JuanVuletich 
In reply to this post by Nicolas Cellier
So, i've patched Squeak (I hope I made no mistake, I'm not Smalltalking much these days) I'm not willing to contribute to Pharo immediately because no time to play with a fragile infrastucture.See http://source.squeak.org/trunk/Kernelnice.1111.diff 20170813 14:47 GMT+02:00 Nicolas Cellier <[hidden email]>:

Free forum by Nabble  Resume Templates  Edit this page 