'.2e2' asNumber ?
Locked
 
|
I noticed that in Squeak and earlier version of Pharo doing
'.2e2' asNumber would return 20.0 or '.2' asNumber would return 0.2 but currently in Pharo those return 0, without error, comment, or other hand waving. Good thing I have Sunits... So is this a bug or feature? Hint obviously in the Fractions calculator people are lazy and enter . 2e2 or .2 without the leading zero... -- = = = ======================================================================== 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 |
|
|
I imagine that nicolas will let us know.
If you have tests we would love to integrate them so that we can detect that. Stef On Sep 23, 2009, at 11:25 PM, John M McIntosh wrote: > I noticed that in Squeak and earlier version of Pharo doing > '.2e2' asNumber > would return 20.0 > or '.2' asNumber > would return 0.2 > > but currently in Pharo those return 0, without error, comment, or > other hand waving. > Good thing I have Sunits... > > So is this a bug or feature? > > Hint obviously in the Fractions calculator people are lazy and enter . > 2e2 or .2 without the leading zero... > > -- > = > = > = > = > = > ====================================================================== > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
The two problems were identified from the beginning:
1) 2.e5 and .2 did work in old squeak images, but no more with SqNumberParser Rationale: SqNumberParser is for parsing number literals in squeak syntax, and those extensions are not identified squeak syntax If you need these syntax, the best thing is to subclass the NumberParser. For example, I must have a FORTRANNumberParser available somewhere... 2) Silently returning zero in case of error. This was one of the goal of SqNumberParser: let programmer choose the appropriate behaviour - raise an Exception - answer nil - answer a default value (zero) The last solution has been connected to Number class>>#readFrom: for historical compatibility reasons. I agree this conservative choice was unfortunate. Pharo should not fear and break compatibility on such dumb behaviours. Nicolas 2009/9/24 Stéphane Ducasse <[hidden email]>: > I imagine that nicolas will let us know. > If you have tests we would love to integrate them so that we can > detect that. > > Stef > > On Sep 23, 2009, at 11:25 PM, John M McIntosh wrote: > >> I noticed that in Squeak and earlier version of Pharo doing >> '.2e2' asNumber >> would return 20.0 >> or '.2' asNumber >> would return 0.2 >> >> but currently in Pharo those return 0, without error, comment, or >> other hand waving. >> Good thing I have Sunits... >> >> So is this a bug or feature? >> >> Hint obviously in the Fractions calculator people are lazy and enter . >> 2e2 or .2 without the leading zero... >> >> -- >> = >> = >> = >> = >> = >> ====================================================================== >> 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 > > > _______________________________________________ > 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 |
|
|
Nicolas,
Silent failures are **BAD**. I always like to compare things to #at: and #at:ifAbsent:. #at: will answer the indicated item or raise an exception. #at:ifAbsent: allows one to customize the behavior and w/o the expense of setting up an exception handler, which is great if the error (bounds in this case) can be understood and corrected locally. Of course, structured exceptions arose to handle the common situation in which I find an error but only you can tell what to do about it, and we are working on completely different parts of the system. This whole debate arises again with end-of-stream exceptions: http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware I am using the additional protocol approach with good results, but should try to make some time to test your pluggable exception idea. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Nicolas Cellier Sent: Thursday, September 24, 2009 3:19 AM To: [hidden email] Subject: Re: [Pharo-project] '.2e2' asNumber ? The two problems were identified from the beginning: 1) 2.e5 and .2 did work in old squeak images, but no more with SqNumberParser Rationale: SqNumberParser is for parsing number literals in squeak syntax, and those extensions are not identified squeak syntax If you need these syntax, the best thing is to subclass the NumberParser. For example, I must have a FORTRANNumberParser available somewhere... 2) Silently returning zero in case of error. This was one of the goal of SqNumberParser: let programmer choose the appropriate behaviour - raise an Exception - answer nil - answer a default value (zero) The last solution has been connected to Number class>>#readFrom: for historical compatibility reasons. I agree this conservative choice was unfortunate. Pharo should not fear and break compatibility on such dumb behaviours. Nicolas 2009/9/24 Stéphane Ducasse <[hidden email]>: > I imagine that nicolas will let us know. > If you have tests we would love to integrate them so that we can > detect that. > > Stef > > On Sep 23, 2009, at 11:25 PM, John M McIntosh wrote: > >> I noticed that in Squeak and earlier version of Pharo doing '.2e2' >> asNumber would return 20.0 or '.2' asNumber would return 0.2 >> >> but currently in Pharo those return 0, without error, comment, or >> other hand waving. >> Good thing I have Sunits... >> >> So is this a bug or feature? >> >> Hint obviously in the Fractions calculator people are lazy and enter . >> 2e2 or .2 without the leading zero... >> >> -- >> = >> = >> = >> = >> = >> ===================================================================== >> = 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 > > > _______________________________________________ > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
R1) RATIONALE FOR HAVING AN EXCEPTION RAISED BY DEFAULT:
The Smalltalk way is the lazy way: raise an Exception, let it unhandled and let user interact in the Debugger to understand what went wrong. This work best if the Exception is raised soon after the error conditions, and that is why I generally prefer raising an Exception than answering nil, or even worse zero! R2) RATIONALE FOR HAVING PROGRAMMABLE ERROR: For a closed source application, you'll have to implement your own error handling... ...and the Kernel should propose, not impose the implementation style: - Exception handling ([] ifError: [], [] on: Error do: [:exc | ]) - exception block argument (at:ifAbsent:, readFrom:ifFail:) - isNil ifTrue: [] (very C-stylish) STATUS OF CURRENT IMPLEMENTATION: When reading fail for any reason then: SqNumberParser>>fail failBlock isNil ifFalse: [^failBlock value]. self error: 'Reading a number failed' Default behaviour is to raise an Exception. But SqNumberParser is programmable via failBlock. And this is used to answer 0 in case of failure... Number class>>readFrom: stringOrStream "Answer a number as described on aStream. The number may be any accepted Smalltalk literal Number format. It can include a leading radix specification, as in 16rFADE. It can as well be NaN, Infinity or -Infinity for conveniency. If stringOrStream does not start with a valid number description, answer 0 for backward compatibility. This is not clever and should better be changed." ^(SqNumberParser on: stringOrStream) failBlock: [^0]; nextNumber Unless you use the dedicated programmable entry point: Number class>>readFrom: stringOrStream ifFail: aBlock "Answer a number as described on aStream. The number may be any accepted Smalltalk literal Number format. It can include a leading radix specification, as in 16rFADE. It can as well be NaN, Infinity or -Infinity for conveniency. If input does not represent a valid number, then execute fail block and leave the stream positioned before offending character" ^(SqNumberParser on: stringOrStream) failBlock: aBlock; nextNumber CONCLUSION AND TODO: 1) R1 is not fulfilled, so better raise an Exception than answer zero 2) R2 is already fulfilled, just open a browser and see by yourself 3) Eventually create a dedicated exception like NumberParsingError... Nicolas 2009/9/24 Schwab,Wilhelm K <[hidden email]>: > Nicolas, > > Silent failures are **BAD**. I always like to compare things to #at: and #at:ifAbsent:. #at: will answer the indicated item or raise an exception. #at:ifAbsent: allows one to customize the behavior and w/o the expense of setting up an exception handler, which is great if the error (bounds in this case) can be understood and corrected locally. Of course, structured exceptions arose to handle the common situation in which I find an error but only you can tell what to do about it, and we are working on completely different parts of the system. > > This whole debate arises again with end-of-stream exceptions: > > http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware > > I am using the additional protocol approach with good results, but should try to make some time to test your pluggable exception idea. > > Bill > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Nicolas Cellier > Sent: Thursday, September 24, 2009 3:19 AM > To: [hidden email] > Subject: Re: [Pharo-project] '.2e2' asNumber ? > > The two problems were identified from the beginning: > > 1) 2.e5 and .2 did work in old squeak images, but no more with SqNumberParser > Rationale: SqNumberParser is for parsing number literals in squeak syntax, and those extensions are not identified squeak syntax > > If you need these syntax, the best thing is to subclass the NumberParser. For example, I must have a FORTRANNumberParser available somewhere... > > 2) Silently returning zero in case of error. > This was one of the goal of SqNumberParser: let programmer choose the appropriate behaviour > - raise an Exception > - answer nil > - answer a default value (zero) > The last solution has been connected to Number class>>#readFrom: for historical compatibility reasons. > I agree this conservative choice was unfortunate. > Pharo should not fear and break compatibility on such dumb behaviours. > > Nicolas > > 2009/9/24 Stéphane Ducasse <[hidden email]>: >> I imagine that nicolas will let us know. >> If you have tests we would love to integrate them so that we can >> detect that. >> >> Stef >> >> On Sep 23, 2009, at 11:25 PM, John M McIntosh wrote: >> >>> I noticed that in Squeak and earlier version of Pharo doing '.2e2' >>> asNumber would return 20.0 or '.2' asNumber would return 0.2 >>> >>> but currently in Pharo those return 0, without error, comment, or >>> other hand waving. >>> Good thing I have Sunits... >>> >>> So is this a bug or feature? >>> >>> Hint obviously in the Fractions calculator people are lazy and enter . >>> 2e2 or .2 without the leading zero... >>> >>> -- >>> = >>> = >>> = >>> = >>> = >>> ===================================================================== >>> = 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 >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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 |
|
|
Ok, well I'm going to go away and build a test suite to check for all
combos of '.' '1.' '1.2' '.e' '1.e' '1.2e' '1.2e3' '-1.e' '-1.2e-3' so we can at least agree on what a valid number is. On 2009-09-24, at 6:57 AM, Nicolas Cellier wrote: > SqNumberParser>>fail > failBlock isNil ifFalse: [^failBlock value]. > self error: 'Reading a number failed' > -- = = = ======================================================================== 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 |
|
|
Excellent idea.
Stef On Sep 24, 2009, at 10:36 PM, John M McIntosh wrote: > Ok, well I'm going to go away and build a test suite to check for all > combos of > '.' > '1.' > '1.2' > '.e' > '1.e' > '1.2e' > '1.2e3' > '-1.e' > '-1.2e-3' > > so we can at least agree on what a valid number is. > > > On 2009-09-24, at 6:57 AM, Nicolas Cellier wrote: >> SqNumberParser>>fail >> failBlock isNil ifFalse: [^failBlock value]. >> self error: 'Reading a number failed' >> > > -- > = > = > = > = > = > ====================================================================== > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |