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. 2017-08-10 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:
|
2017-08-10 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.oscog-eem.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
|
2017-08-13 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.cuis-smalltalk.org https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev @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/Kernel-nice.1111.diff 2017-08-13 14:47 GMT+02:00 Nicolas Cellier <[hidden email]>:
|
Free forum by Nabble | Edit this page |