I know some of them:<br><br>(Integer new: 5 neg: true) class.<br>(SmallInteger maxVal + 1 replaceFrom: 4 to: 4 with: #[0] startingAt: 1) class.<br>(SmallInteger maxVal + 1 digitDiv: 4 neg: false) first class.<br>
(SmallInteger maxVal + 1 \\\ 3) class.<br><br>And probably a few others (digitRshift:bytes:lookfirst:).<br>IMO, it's the responsibility of senders to normalize, and we should clearly indicate the comment of each of these messages.<br>
I also think that the last one, \\\, should send normalize, because it won't change performance of senders noticeably.<br><br>Nicolas<br><br><div class="gmail_quote">2011/7/11 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Igor,<br><br><div class="gmail_quote"><div class="im">On Mon, Jul 11, 2011 at 4:30 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Levente, your change is a bit dangerous,<br>
because if i remember correctly, not all primitives normalizing large integers.<br>
So, it is fairly possible to have large integer with value in a range<br>
of small integer.<br></blockquote><div><br></div></div><div>It is difficult to construct such a beast. If one uses the interpreterProxy API, positive32BitIntegerFor et al you'll always obtain something normalized. AFAIA, the only way one can create something unnormalized is by asking for a large integer and then altering its contents. So for me this isn't a dangerous change and requiring VM code to always deal with normalized integers seems rational and dependable to me.</div>
<div><div></div><div class="h5">
<div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Not saying , that one can manipulate largeinteger bits directly, and<br>
then use it later in comparison,<br>
which will fail due to your changes.<br>
So, such change requiring strong guarantees that you cannot create<br>
large integers which is in range of small integers.<br>
<div><div></div><div><br>
On 10 July 2011 16:36, <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>> wrote:<br>
> Levente Uzonyi uploaded a new version of Kernel to project The Trunk:<br>
> <a href="http://source.squeak.org/trunk/Kernel-ul.604.mcz" target="_blank">http://source.squeak.org/trunk/Kernel-ul.604.mcz</a><br>
><br>
> ==================== Summary ====================<br>
><br>
> Name: Kernel-ul.604<br>
> Author: ul<br>
> Time: 10 July 2011, 4:36:20.467 pm<br>
> UUID: f758876f-a507-404b-aa2f-2c1038504b48<br>
> Ancestors: Kernel-bf.603<br>
><br>
> Optimized Integer >> #= for integer-integer comparisons. Return false for integers from different classes without further checking.<br>
><br>
> =============== Diff against Kernel-bf.603 ===============<br>
><br>
> Item was changed:<br>
> ----- Method: Integer>>= (in category 'comparing') -----<br>
> = aNumber<br>
> +<br>
> + aNumber isInteger ifTrue: [<br>
> + aNumber class == self class ifFalse: [ ^false ].<br>
> + ^(self digitCompare: aNumber) = 0 ].<br>
> + aNumber isNumber ifFalse: [ ^false ].<br>
> + ^aNumber adaptToInteger: self andCompare: #=!<br>
> - aNumber isNumber ifFalse: [^ false].<br>
> - aNumber isInteger ifTrue:<br>
> - [aNumber negative == self negative<br>
> - ifTrue: [^ (self digitCompare: aNumber) = 0]<br>
> - ifFalse: [^ false]].<br>
> - ^ aNumber adaptToInteger: self andCompare: #=!<br>
><br>
><br>
><br>
<br>
<br>
<br>
--<br>
</div></div>Best regards,<br>
<font color="#888888">Igor Stasenko AKA sig.<br>
<br>
</font></blockquote></div></div></div><br><br clear="all"><br>-- <br>best,<div>Eliot</div><font color="#888888"><br>
</font><br><br>
<br></blockquote></div><br>