Re: [Pharo-project] [squeak-dev] Re: The Trunk: Multilingual-ar.87.mcz
Also see http://code.google.com/p/pharo/issues/detail?id=1258 '.1' asNumber toss an error in Pharo 1.1 11043 and '1.0e+2' asNumber returns 1.0 yet other I think more knowledgeable people say http://www.wolframalpha.com/input/?i=1.0e%2B2 100 I'd just say any expectations of converting a string to a number in most flavours of Squeak should be viewed with suspicion. On 2010-02-12, at 12:44 AM, Andreas Raab wrote:
Nicolas Cellier wrote:
This of course fail with Number>>readFrom: You can also simply try 3r1.1e55 - 3r11.0e54 and the SqNumberParser form... (SqNumberParser parse: '3r1.1e55') - (SqNumberParser parse: '3r11.0e54') Maybe it's time to push the readFrom: changes i already pushed in Pharo...
Go for it. You're the best expert we have in this area, and I trust your judgment.
Cheers, - Andreas
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
in pharo too ;( Sef On Feb 12, 2010, at 12:44 PM, K. K. Subramaniam wrote:
On Friday 12 February 2010 02:40:36 pm John M McIntosh wrote:
'1.0e+2' asNumber returns 1.0 Squeak (Trunk) shows: '1.0e2' asNumber 100 '1.0e+2' asNumber 1.0
:-/ .. Subbu
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Except if my analytical skills are impaired by being tired and groggy due a very short sleep I think the solution to this is only a matter of putting: sourceStream peekFor: $+. just before eneg := sourceStream peekFor: $-. in SqNumberParser>>readExponent Did I miss something fundamental? my 0.01999. . . . -- Cesar Rabak Em 12/02/2010 11:44, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu: in pharo too ;( Sef On Feb 12, 2010, at 12:44 PM, K. K. Subramaniam wrote:
On Friday 12 February 2010 02:40:36 pm John M McIntosh wrote:
'1.0e+2' asNumber returns 1.0 Squeak (Trunk) shows: '1.0e2' asNumber 100 '1.0e+2' asNumber 1.0
:-/ .. Subbu
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/2/12 <csrabak@bol.com.br>:
Except if my analytical skills are impaired by being tired and groggy due a very short sleep I think the solution to this is only a matter of putting:
sourceStream peekFor: $+.
just before eneg := sourceStream peekFor: $-. in SqNumberParser>>readExponent
Did I miss something fundamental?
my 0.01999. . . .
-- Cesar Rabak
Yes, it's trivial. It's already implemented in the DolphinNumberParser, because Dolphin syntax allow 1.0e+2 In st-80 and current squeak, this rather means 1.0 e + 2 (send #e to 1.0 then send #+ with argument 2 to the result) Other features are not so hard either. We have to measure all the consequences then just decide what is worth. Nicolas
Em 12/02/2010 11:44, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu: in pharo too ;(
Sef On Feb 12, 2010, at 12:44 PM, K. K. Subramaniam wrote:
On Friday 12 February 2010 02:40:36 pm John M McIntosh wrote:
'1.0e+2' Â asNumber returns 1.0 Squeak (Trunk) shows: '1.0e2' asNumber 100 '1.0e+2' asNumber 1.0
:-/ Â .. Subbu
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Em 12/02/2010 13:16, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com > escreveu:
2010/2/12 <csrabak@bol.com.br>:
Except if my analytical skills are impaired by being tired and groggy due a very short sleep I think the solution to this is only a matter of putting: sourceStream peekFor: $+. just before eneg := sourceStream peekFor: $-. in SqNumberParser>>readExponent Did I miss something fundamental? my 0.01999. . . .
-- Cesar Rabak
Yes, it's trivial. It's already implemented in the DolphinNumberParser, because Dolphin syntax allow 1.0e+2 In st-80 and current squeak, this rather means 1.0 e + 2 (send #e to 1.0 then send #+ with argument 2 to the result)
I'm may be biased here but I don't follow ST-80 behaviour as reasonable (although sensible from the POV of Smalltalk syntax). Also, I don't know the origin of the fork, but while in Squeak performing in Workspace: 1.0012e+3 + 1 rises an error about Float(Object) DNU #e, in Pharo (PharoCore1.0rc2 Latest update: #10509) the code above generates the answer " 1002.23" which is what I would expect.
Other features are not so hard either. We have to measure all the consequences then just decide what is worth.
My only 'other feature' request would be to have the case sensitiveness for the 'e' of exponent notation removed, as it would ease the import of data from CSV files. . . IIRC I already mentioned that in Pharo's mailing list.
From my exposition above, I _think_ we should fix SqNumberParser>>readExponent in order to have a system which is consistent internally.
This begs another question: from where Pharo converts the string in Shout Workspace to number which has a different behaviour than SqNumberParser?? Mysteries of OO in Smalltalk? HTH -- Cesar Rabak PS.: On a side note I would like to comment that the method 'nextNumber' which is the one ultimately used to fetch the number from SqNumberParser seems to me to have a non intuitive name. . . Sorry I cannot concoct any better name right now to offer as a suggestion :-|
2010/2/12 <csrabak@bol.com.br>:
Em 12/02/2010 13:16, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com > escreveu:
2010/2/12 <csrabak@bol.com.br>:
Except if  my analytical  skills are impaired  by being  tired and groggy due a very short sleep  I think the solution to this is only a matter of putting: sourceStream peekFor: $+. just   before  eneg   :=  sourceStream   peekFor:   $-.  in SqNumberParser>>readExponent Did I miss something fundamental? my 0.01999. . . .
-- Cesar Rabak
 Yes,  it's   trivial.   It's  already   implemented  in  the DolphinNumberParser,  because Dolphin syntax  allow 1.0e+2  In st-80 and current squeak, this rather means 1.0 e + 2 (send #e to 1.0 then send #+ with argument 2 to the result)
I'm may be biased here but I don't follow ST-80 behaviour as reasonable (although sensible from the POV of Smalltalk syntax).
I guess one of st-80 goals was to have minimal syntax. With this respect, the plus sign is absolutely void (in the sense it adds no information). With this rationale, it was just useless to create rules for +2 and 1.0e+2. So it makes sense. Now, we can change this if there is consensus. I suggest in this case to also make a separator mandatory after end of sentence period.
Also, I don't know the origin of the fork, but while in Squeak performing in Workspace:
1.0012e+3 + 1 rises an error about Float(Object) DNU #e,
in Pharo (PharoCore1.0rc2 Latest update: #10509) the code above generates the answer " 1002.23" which is what I would expect.
I don't know about Pharo1.0, but Pharo1.1 fails (DNU #e) as most Smalltalk do (but Dolphin AFAIK).
 Other features are not so hard  either.  We have to measure all the consequences then just decide what is worth.
My only 'other feature' request would be to have the case sensitiveness for the 'e' of exponent notation removed, as it would ease the import of data from CSV files. . .
IIRC I already mentioned that in Pharo's mailing list.
From my exposition above, I _think_ we should fix SqNumberParser>>readExponent in order to have a system which is consistent internally.
This begs another question: from where Pharo converts the string in Shout Workspace to number which has a different behaviour than SqNumberParser??
Mysteries of OO in Smalltalk?
HTH
-- Cesar Rabak
PS.: On a side note I would like to comment that the method 'nextNumber' which is the one ultimately used to fetch the number from SqNumberParser seems to me to have a non intuitive name. . . Â Sorry I cannot concoct any better name right now to offer as a suggestion :-|
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
If I remember correctly the discussion we decided to have '.1' squeezeOutNumber returning a number and let '.1' asNumber raises an error. Stef On Feb 12, 2010, at 10:10 AM, John M McIntosh wrote:
Also see http://code.google.com/p/pharo/issues/detail?id=1258
'.1' asNumber toss an error in Pharo 1.1 11043 and
'1.0e+2' asNumber returns 1.0
yet other I think more knowledgeable people say http://www.wolframalpha.com/input/?i=1.0e%2B2 100
I'd just say any expectations of converting a string to a number in most flavours of Squeak should be viewed with suspicion.
On 2010-02-12, at 12:44 AM, Andreas Raab wrote:
Nicolas Cellier wrote:
This of course fail with Number>>readFrom: You can also simply try 3r1.1e55 - 3r11.0e54 and the SqNumberParser form... (SqNumberParser parse: '3r1.1e55') - (SqNumberParser parse: '3r11.0e54') Maybe it's time to push the readFrom: changes i already pushed in Pharo...
Go for it. You're the best expert we have in this area, and I trust your judgment.
Cheers, - Andreas
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
csrabak＠bol.com.br -
John M McIntosh -
K. K. Subramaniam -
Nicolas Cellier -
Stéphane Ducasse