<div dir="ltr"><div><div><div>So, i've patched Squeak (I hope I made no mistake, I'm not Smalltalking much these days)<br>See <a href="http://source.squeak.org/trunk/Kernel-nice.1111.diff">http://source.squeak.org/trunk/Kernel-nice.1111.diff</a><br></div>I'm not willing to contribute to Pharo immediately because no time to play with a fragile infrastucture.<br></div>If you badly need the patch in Pharo, feel free to plagiarize.<br><br></div>Nicolas<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-13 14:47 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-08-13 12:13 GMT+02:00 Andrei Chis <span dir="ltr"><<a href="mailto:chisvasileandrei@gmail.com" target="_blank">chisvasileandrei@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmai<wbr>l.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-08-10 22:19 GMT+02:00 Andrei Chis <span dir="ltr"><<a href="mailto:chisvasileandrei@gmail.com" target="_blank">chisvasileandrei@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Hi Nicolas,<div><br></div><div>Thanks for the info. Indeed sending #asFloat to the operand leads to a correct behaviour. </div><div><br></div><div>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. </div><div><br></div></div></blockquote><div><br></div><div>Having (1/1000 raisedTo: 2/3) = (1/100)  is a nice thing and we want to keep it.<br></div></div></div></div></blockquote><div><br></div></span><div>Indeed, it's a nice to have feature.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>But once we detect that we can't have an exact result, we should adopt a more efficient strategy.  </div></div></div></div></blockquote><div><br></div></span><div><div>Do you know if the vm plugin fix from Eliot addresses also this or there should some more actions taken on the image side?</div></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.<br>But since ln already handles those edge cases (at least in Squeak, I have to check Pharo), ((aNumber * self ln) exp)<span> </span>is a good approximation (a few ulp off, depending on the quality of underlying libm). </div></div></div></div></blockquote><div><br></div></span><div>For now I switched to using ((aNumber * self ln) exp)  and it's working well.</div><div><br></div><div>Cheers,</div><div>Andrei</div><div><br></div></div></div></div></blockquote><div><br></div><div>Hi Andrei,<br>an image side modification is necessary if we want to gain more efficiency.</div><div>The question is whether we want to have correctly rounded results or not for Integer>>nthRoot:.<br></div><div>If not, ((aNumber * self ln) exp) <span class="m_-6535739154604651844gmail-">is OK </span>(it can be a few ulp off as I told before).<br>For Fraction, there's no point in rounding some term correctly then spoiling by an inexact raisedTo: and an inexact /.<br>I started to look at it in Squeak (same code), then it will be time to port in Pharo.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Nicolas<br></div></font></span><div><div class="h5"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Nicolas<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Cheers,</div><div>Andrei</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmai<wbr>l.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><div><div><div><div><div><div>Hi Andrei,<br></div>indeed, the method does not scale well...<br><br></div>If the result is an exact Fraction, then it will answer the Fraction.<br>Else if not exact, it will be converted to a Float.<br><br></div>The problem is that it will try to answer nearest Float with a rather naive algorithm.<br></div>Moreover, computing the nthRoot: first, then raising the result to the power of numerator will cumulate rounding errors.<br>So trying to get a very accurate nthRoot: first in case of Float result is not a good strategy anyway.<br><br></div><div>Why the VM crashes exactly is another problem and remains to see, we'd prefer an Exception.<br></div><div><br></div>As a workaround, I suggest sending asFloat to the receiver and/or operand.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-10 12:02 GMT+02:00 Andrei Chis <span dir="ltr"><<a href="mailto:chisvasileandrei@gmail.com" target="_blank">chisvasileandrei@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr">Hi,<div><br></div><div>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.</div><div>Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.</div><div><br></div><div>Cheers,</div><div>Andrei</div><div><br></div><div><br></div><div><div>0xaddeac M LargePositiveInteger(Integer)><wbr>quo: 0x314093e8: a(n) LargePositiveInteger</div><div>0xaddec8 M LargePositiveInteger(LargeInte<wbr>ger)>quo: 0x314093e8: a(n) LargePositiveInteger</div><div>0xaddee8 M LargePositiveInteger(Integer)><wbr>// 0x314093e8: a(n) LargePositiveInteger</div><div>0xaddf04 M LargePositiveInteger(LargeInte<wbr>ger)>// 0x314093e8: a(n) LargePositiveInteger</div><div>0xaddf34 I LargePositiveInteger(Integer)><wbr>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger</div><div>0xaddf5c I LargePositiveInteger(Integer)><wbr>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger</div><div>0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009</div><div>0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction</div><div>0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction</div><div>0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction</div><div>0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject</div><div>0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler</div><div>0xade074 I RubSmalltalkEditor>evaluate:an<wbr>dDo: 0x305e5878: a(n) RubSmalltalkEditor</div><div>0xade09c I RubSmalltalkEditor>highlightEv<wbr>aluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor</div><div>0xade0b8 M GLMMorphicPharoScriptRenderer(<wbr>GLMMorphicPharoCodeRenderer)>p<wbr>opupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri</div><div>enderer</div><div>0xade0d8 I MorphicAlarm(MessageSend)>valu<wbr>e 0x4f9ab20: a(n) MorphicAlarm</div><div>0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm</div><div>0xade114 M WorldState>triggerAlarmsBefore<wbr>: 0x71bb5e0: a(n) WorldState</div><div>0xade140 M WorldState>runLocalStepMethods<wbr>In: 0x71bb5e0: a(n) WorldState</div><div>0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState</div><div>0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph</div><div>0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState</div><div>0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState</div><div>0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph</div><div>0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class</div><div>0xade200 M [] in MorphicUIManager>spawnNewProce<wbr>ss 0x2cc88718: a(n) MorphicUIManager</div><div>0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure</div></div></div>
<br></blockquote></div><br></div>
<br></blockquote></div><br></div>
<br></blockquote></div><br></div></div>
<br></blockquote></div><br></div></div>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>