Re: [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:

--
===========================================================================
John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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
[hidden email]
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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

in pharo too ;(

Sef
On Feb 12, 2010, at 12:44 PM, K. K. Subramaniam wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
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 < [hidden email] > escreveu:
in pharo too ;(

Sef
On Feb 12, 2010, at 12:44 PM, K. K. Subramaniam wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2010/2/12  <[hidden email]>:
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Em 12/02/2010 13:16, Nicolas Cellier < [hidden email] > escreveu:

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 :-|

   

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2010/2/12  <[hidden email]>:
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).

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project