[Pharo-project] digitAt: issue
Hi, try to run the following: (2 raisedTo: 100000) digitAt: 1 The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index. Is this a bug or am I missunderstanding how digitAt: should work? Cheers, Bernat Romagosa. p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
Bernat, On 02 May 2011, at 11:13, Bernat Romagosa wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
Consider, 2 raisedTo: 32 #digitAt: for digits 1 to 4 returns 0, 5 return 1.
From the comments you can see that the number is looked at in base 256. The above number thus has 5 digits in this base, four are zero and the highest one is one. Furthermore, the first digit is the lowest one. If you inspect the number it might become clearer.
Any #digitAt: has to depend on the base you use to represent the number, this one doesn't, so it seems to be useful only to return internal parts of a number. HTH, Sven
Ouch, understood! Then what would be the proper way to address a decimal digit in a number? I can only think of (bigNumber asString at: index) asNumber, which is... awful. 2011/5/2 Sven Van Caekenberghe <sven@beta9.be>
Bernat,
On 02 May 2011, at 11:13, Bernat Romagosa wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
Consider,
2 raisedTo: 32
#digitAt: for digits 1 to 4 returns 0, 5 return 1. From the comments you can see that the number is looked at in base 256. The above number thus has 5 digits in this base, four are zero and the highest one is one. Furthermore, the first digit is the lowest one. If you inspect the number it might become clearer.
Any #digitAt: has to depend on the base you use to represent the number, this one doesn't, so it seems to be useful only to return internal parts of a number.
HTH,
Sven
DigitAt: is a horrible name then, should rather be bitAt:. the digitAt: implementation you're looking for: ^ self // (10 raisedTo: index - 1) \\ 10 thats quite short :) On 2011-05-02, at 11:35, Bernat Romagosa wrote:
Ouch, understood!
Then what would be the proper way to address a decimal digit in a number? I can only think of (bigNumber asString at: index) asNumber, which is... awful.
2011/5/2 Sven Van Caekenberghe <sven@beta9.be> Bernat,
On 02 May 2011, at 11:13, Bernat Romagosa wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
Consider,
2 raisedTo: 32
#digitAt: for digits 1 to 4 returns 0, 5 return 1. From the comments you can see that the number is looked at in base 256. The above number thus has 5 digits in this base, four are zero and the highest one is one. Furthermore, the first digit is the lowest one. If you inspect the number it might become clearer.
Any #digitAt: has to depend on the base you use to represent the number, this one doesn't, so it seems to be useful only to return internal parts of a number.
HTH,
Sven
Yup, it seems to me like a horrible name too, especially considering that bitAt: already exists :) 2011/5/2 Camillo Bruni <camillo.bruni@inria.fr>
DigitAt: is a horrible name then, should rather be bitAt:.
the digitAt: implementation you're looking for:
^ self // (10 raisedTo: index - 1) \\ 10
thats quite short :)
On 2011-05-02, at 11:35, Bernat Romagosa wrote:
Ouch, understood!
Then what would be the proper way to address a decimal digit in a number? I can only think of (bigNumber asString at: index) asNumber, which is... awful.
2011/5/2 Sven Van Caekenberghe <sven@beta9.be>
Bernat,
On 02 May 2011, at 11:13, Bernat Romagosa wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
Consider,
2 raisedTo: 32
#digitAt: for digits 1 to 4 returns 0, 5 return 1. From the comments you can see that the number is looked at in base 256. The above number thus has 5 digits in this base, four are zero and the highest one is one. Furthermore, the first digit is the lowest one. If you inspect the number it might become clearer.
Any #digitAt: has to depend on the base you use to represent the number, this one doesn't, so it seems to be useful only to return internal parts of a number.
HTH,
Sven
open an issue and propose a path to get there Stef On May 2, 2011, at 3:34 PM, Camillo Bruni wrote:
DigitAt: is a horrible name then, should rather be bitAt:.
the digitAt: implementation you're looking for:
^ self // (10 raisedTo: index - 1) \\ 10
thats quite short :)
On 2011-05-02, at 11:35, Bernat Romagosa wrote:
Ouch, understood!
Then what would be the proper way to address a decimal digit in a number? I can only think of (bigNumber asString at: index) asNumber, which is... awful.
2011/5/2 Sven Van Caekenberghe <sven@beta9.be> Bernat,
On 02 May 2011, at 11:13, Bernat Romagosa wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
Consider,
2 raisedTo: 32
#digitAt: for digits 1 to 4 returns 0, 5 return 1. From the comments you can see that the number is looked at in base 256. The above number thus has 5 digits in this base, four are zero and the highest one is one. Furthermore, the first digit is the lowest one. If you inspect the number it might become clearer.
Any #digitAt: has to depend on the base you use to represent the number, this one doesn't, so it seems to be useful only to return internal parts of a number.
HTH,
Sven
Done: http://code.google.com/p/pharo/issues/detail?id=4154 2011/5/2 Stéphane Ducasse <stephane.ducasse@inria.fr>
open an issue and propose a path to get there
Stef
On May 2, 2011, at 3:34 PM, Camillo Bruni wrote:
DigitAt: is a horrible name then, should rather be bitAt:.
the digitAt: implementation you're looking for:
^ self // (10 raisedTo: index - 1) \\ 10
thats quite short :)
On 2011-05-02, at 11:35, Bernat Romagosa wrote:
Ouch, understood!
Then what would be the proper way to address a decimal digit in a number? I can only think of (bigNumber asString at: index) asNumber, which is... awful.
2011/5/2 Sven Van Caekenberghe <sven@beta9.be> Bernat,
On 02 May 2011, at 11:13, Bernat Romagosa wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
Consider,
2 raisedTo: 32
#digitAt: for digits 1 to 4 returns 0, 5 return 1. From the comments you can see that the number is looked at in base 256. The above number thus has 5 digits in this base, four are zero and the highest one is one. Furthermore, the first digit is the lowest one. If you inspect the number it might become clearer.
Any #digitAt: has to depend on the base you use to represent the number, this one doesn't, so it seems to be useful only to return internal parts of a number.
HTH,
Sven
Yes, if you want ith decimalDigit of integer n, 1 being least significant digit, then you shall write the division with a method like: decimalDigitOfRank: i "Answer the ith decimal digit, i=1 being the least significant digit" ^self // (10 raisedTo: i - 1) \\ 10 However, the awfull method you proposed might be faster if your intention is to scan all digits on very large numbers, because printString is optimized. Nicolas 2011/5/2 Bernat Romagosa <tibabenfortlapalanca@gmail.com>:
Ouch, understood! Then what would be the proper way to address a decimal digit in a number? I can only think of (bigNumber asString at: index) asNumber, which is... awful.
2011/5/2 Sven Van Caekenberghe <sven@beta9.be>
Bernat,
On 02 May 2011, at 11:13, Bernat Romagosa wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
Consider,
2 raisedTo: 32
#digitAt: for digits 1 to 4 returns 0, 5 return 1. From the comments you can see that the number is looked at in base 256. The above number thus has 5 digits in this base, four are zero and the highest one is one. Furthermore, the first digit is the lowest one. If you inspect the number it might become clearer.
Any #digitAt: has to depend on the base you use to represent the number, this one doesn't, so it seems to be useful only to return internal parts of a number.
HTH,
Sven
Hello, digitAt: 1 returns the least significant byte, thus it is expectedto be 0. The most significant would be | n | (n := 2 raisedTo: 100000) digitAt: n digitLength Nicolas 2011/5/2 Bernat Romagosa <tibabenfortlapalanca@gmail.com>:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index. Is this a bug or am I missunderstanding how digitAt: should work? Cheers, Bernat Romagosa. p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
digitAt: answers a byte in an integer and so is working as intended. Eliot (phone) On May 2, 2011, at 2:13 AM, Bernat Romagosa <tibabenfortlapalanca@gmail.com> wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
As intended, yes. But not as expected from what digit usually means (any of the arabic figures of 1 through 9 and 0. [3<http://dictionary.reference.com/browse/digit> ]). I guess that'd change the behavior of too many things, but IMHO byteAt: would suit much better what this method does. 2011/5/2 Eliot Miranda <eliot.miranda@gmail.com>
digitAt: answers a byte in an integer and so is working as intended.
Eliot (phone)
On May 2, 2011, at 2:13 AM, Bernat Romagosa < tibabenfortlapalanca@gmail.com> wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index.
Is this a bug or am I missunderstanding how digitAt: should work?
Cheers,
Bernat Romagosa.
p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
You are perfectly right, digitus means finger in latin, so it generally carries the notion of 10-base. I guess #byteAt: was not selected because it was considered as an implementation detail. The implementation might as well switch to 16 or 32 bits "digits", and you could still use generic code like 1 to: self digitLength do: [:i | (self digitAt: i) doSomething ] As long as you don't put any expectation on #digitAt: bit length... Since plenty of optimization depending on #digitAt: returning a byte have been added to the system - some by me :( - we shall better use byteAt:, but it's hard to control how a living system evolves... Nicolas 2011/5/2 Bernat Romagosa <tibabenfortlapalanca@gmail.com>:
As intended, yes. But not as expected from what digit usually means (any of the arabic figures of 1 through 9 and 0. [3]). I guess that'd change the behavior of too many things, but IMHO byteAt: would suit much better what this method does.
2011/5/2 Eliot Miranda <eliot.miranda@gmail.com>
digitAt: answers a byte in an integer and so is working as intended.
Eliot (phone) On May 2, 2011, at 2:13 AM, Bernat Romagosa <tibabenfortlapalanca@gmail.com> wrote:
Hi, try to run the following:
(2 raisedTo: 100000) digitAt: 1
The expected result (if I understood what digitAt: should return) is 9, but the message returns 0 instead. In fact, it returns 0 for any index. Is this a bug or am I missunderstanding how digitAt: should work? Cheers, Bernat Romagosa. p.s. My config is Pharo 1.2 with a 'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.51]' on Debian Lenny.
participants (6)
-
Bernat Romagosa -
Camillo Bruni -
Eliot Miranda -
Nicolas Cellier -
Stéphane Ducasse -
Sven Van Caekenberghe