Andreas,
I completely agree with what you said except for the first sentence. Why do you think it is a "complete and utter overkill"? I can think of three possibilities:
1) The extra class you are adding to the image (SqNumberParser) 2) The extra object involved in the parsing 3) All the explicit methods that you have to define on the SqNumberParser object.
None of them seems an overkill to me. I am obviously missing something.
Cheers, Francisco
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
Le Vendredi 28 Avril 2006 18:27, francisco.j.garau@jpmorgan.com a écrit :
Andreas,
I completely agree with what you said except for the first sentence. Why do you think it is a "complete and utter overkill"? I can think of three possibilities:
- The extra class you are adding to the image (SqNumberParser)
- The extra object involved in the parsing
- All the explicit methods that you have to define on the SqNumberParser
object.
None of them seems an overkill to me. I am obviously missing something.
Cheers, Francisco
I added the bug report and a few test cases at http://bugs.impara.de/view.php?id=3512 last night.
I have a first implementation of SqNumberParser. It is more convenient to have a class than a set of messages (see how many are necessary in Number>>readFrom:), because we can store some intermediate results and better optimize Float reading (number of trailing zeroes is an example that can save useless computations). Relax, creating a class does not spoil efficiency.
The second advantage of SqNumberParser is that it is a good starting point for those wanting their own extension for Number parsing as suggested by Diego and Francisco. The class could easily have other extensions like indicating the error in the TextEditor, like for code...
So far, i suppressed the bugs i know, and the class read Integer ScaledDecimal and Float (including nan infinity and negative zero), and pass all the NumberParsingTests successfully.
However i still have the bellerophon algorithm (from tony's reference) failing with last bit incorrect in a few cases (i can check that with asTrueFraction for number greater than 1.0 timestwoPower: 53). So i do not release it yet.
Float>>absPrintOnExactly;base: works rather well and is a good candidate for testing readFrom:. However, i do not over trust it, because it includes the same code that bugged absPrintOn: (See note in http://bugs.impara.de/view.php?id=3493) : it adds 1 to a digit without testing if digit=(base-9)... I did not reveal the bug yet.
Nicolas
On 4/28/06, nicolas cellier ncellier@ifrance.com wrote:
I added the bug report and a few test cases at http://bugs.impara.de/view.php?id=3512 last night.
I have a first implementation of SqNumberParser.
Excellent!!! Since the last mail, I was trying to do the same (a separate number parser), but I didn't have time. :)
I added the bug report and a few test cases at http://bugs.impara.de/view.php?id=3512 last night.
I have a first implementation of SqNumberParser. It is more convenient to have a class than a set of messages (see how many are necessary in Number>>readFrom:), because we can store some intermediate results and better optimize Float reading (number of trailing zeroes is an example that can save useless computations). Relax, creating a class does not spoil efficiency.
:)
The second advantage of SqNumberParser is that it is a good starting point for those wanting their own extension for Number parsing as suggested by Diego and Francisco. The class could easily have other extensions like indicating the error in the TextEditor, like for code...
So far, i suppressed the bugs i know, and the class read Integer ScaledDecimal and Float (including nan infinity and negative zero), and pass all the NumberParsingTests successfully.
However i still have the bellerophon algorithm (from tony's reference) failing with last bit incorrect in a few cases (i can check that with asTrueFraction for number greater than 1.0 timestwoPower: 53). So i do not release it yet.
Float>>absPrintOnExactly;base: works rather well and is a good candidate for testing readFrom:. However, i do not over trust it, because it includes the same code that bugged absPrintOn: (See note in http://bugs.impara.de/view.php?id=3493) : it adds 1 to a digit without testing if digit=(base-9)... I did not reveal the bug yet.
Nicolas
I added the bug report and a few test cases at http://bugs.impara.de/view.php?id=3512 last night.
thanks.
I have a first implementation of SqNumberParser. It is more convenient to have a class than a set of messages (see how many are necessary in Number>>readFrom:), because we can store some intermediate results and better optimize Float reading (number of trailing zeroes is an example that can save useless computations). Relax, creating a class does not spoil efficiency.
:)))))))))
The second advantage of SqNumberParser is that it is a good starting point for those wanting their own extension for Number parsing as suggested by Diego and Francisco. The class could easily have other extensions like indicating the error in the TextEditor, like for code...
So far, i suppressed the bugs i know, and the class read Integer ScaledDecimal and Float (including nan infinity and negative zero), and pass all the NumberParsingTests successfully.
:) So this is crying for new tests :)
However i still have the bellerophon algorithm (from tony's reference) failing with last bit incorrect in a few cases (i can check that with asTrueFraction for number greater than 1.0 timestwoPower: 53). So i do not release it yet.
Float>>absPrintOnExactly;base: works rather well and is a good candidate for testing readFrom:. However, i do not over trust it, because it includes the same code that bugged absPrintOn: (See note in http://bugs.impara.de/view.php?id=3493) : it adds 1 to a digit without testing if digit=(base-9)... I did not reveal the bug yet.
Nicolas to help us harvesting for 3.9 could you provide us with a list of the ready to harvest items.
Stef
Le Vendredi 28 Avril 2006 20:08, nicolas cellier a écrit :
However i still have the bellerophon algorithm (from tony's reference) failing with last bit incorrect in a few cases (i can check that with asTrueFraction for number greater than 1.0 timestwoPower: 53). So i do not release it yet.
Nicolas
Subjects developped in this (too) long email are: - A) Float readFrom: now round exactly :) - B) my solution use a new ArbitraryPrecisionFloat class :( - C) this class can solve other asFloat problems :) - D) shouldn't the readFrom: fix better be moved to asFloat fix ?
A)----------------------------------------------------------------------------
OK, now i have the Float reading working, also for gradual underflow !
This of course solve Andreas' Numerics question: reading floating point constants, i now have (SqNumberParser on: '6.07710050630396597660e-11') nextNumber hex = '3DD0B4611A600000'.
B)----------------------------------------------------------------------------
The solution is not as light as i wanted, because i finally added an ArbitraryPrecisionFloat class to handle 64bits arithmetic involved in Bellerophon. So i do not know if i should publish my solution at http://bugs.impara.de/view.php?id=3512, or rather in SM. Unfortunately my SM account is blocked inactive...
It's funny how easy creating a new Number class was. Of course, ArbitraryPrecisionFloat lacks a short literal form syntax, it does not implement usual mathematical functions (default is to convert to Float). And it's not optimized at all (please don't compare to hardwired Float arithmetic...). But it's more general than just reading Float. This is why i wanted to publish on SM.
C)----------------------------------------------------------------------------
This can potentially solve other asFloat incorrect rounding behaviour:
C.1) current implementation of LargeInteger>>asFloat. will not round to nearest even Float when highBit > 53.
example: 16r1FFFFFFFFFFFF081 asFloat hex
The ArbitraryPrecisionFloat implements IEEE rounding mode, so it can cure this one easily.
C.2) it is more difficult with Fraction>>asFloat which does neither round to nearest even Float...
Bellerophon and ArbitraryPrecisionFloat together can fix the Fraction problem (conversion from decimal to binary representation is just a special case of these Large fractions).
I now know why i never succedeed in implementing my own Smalltalk Float reading in VW, despite of Integer infinite precision... I was over-trusting asFloat implementation that suffer the same problem...
D)----------------------------------------------------------------------------
So, maybe we should better move the fixes i wrote from Number>>readFrom: to LargeInteger and Fraction>>asFloat, Then exactly rounded Float>>readFrom: will be a side effect...
Nicolas
Nicolas,
This looks great, thanks for your description here. (and fwiw, I'd say yes to puting it on Impara and also yes to your D) item)
Milan On 2006 April 30 18:38, nicolas cellier wrote:
Le Vendredi 28 Avril 2006 20:08, nicolas cellier a écrit :
However i still have the bellerophon algorithm (from tony's reference) failing with last bit incorrect in a few cases (i can check that with asTrueFraction for number greater than 1.0 timestwoPower: 53). So i do not release it yet.
Nicolas
Subjects developped in this (too) long email are:
- A) Float readFrom: now round exactly :)
- B) my solution use a new ArbitraryPrecisionFloat class :(
- C) this class can solve other asFloat problems :)
- D) shouldn't the readFrom: fix better be moved to asFloat fix ?
A)-------------------------------------------------------------------------
OK, now i have the Float reading working, also for gradual underflow !
This of course solve Andreas' Numerics question: reading floating point constants, i now have (SqNumberParser on: '6.07710050630396597660e-11') nextNumber hex = '3DD0B4611A600000'.
B)-------------------------------------------------------------------------
The solution is not as light as i wanted, because i finally added an ArbitraryPrecisionFloat class to handle 64bits arithmetic involved in Bellerophon. So i do not know if i should publish my solution at http://bugs.impara.de/view.php?id=3512, or rather in SM. Unfortunately my SM account is blocked inactive...
It's funny how easy creating a new Number class was. Of course, ArbitraryPrecisionFloat lacks a short literal form syntax, it does not implement usual mathematical functions (default is to convert to Float). And it's not optimized at all (please don't compare to hardwired Float arithmetic...). But it's more general than just reading Float. This is why i wanted to publish on SM.
C)-------------------------------------------------------------------------
This can potentially solve other asFloat incorrect rounding behaviour:
C.1) current implementation of LargeInteger>>asFloat. will not round to nearest even Float when highBit > 53.
example: 16r1FFFFFFFFFFFF081 asFloat hex
The ArbitraryPrecisionFloat implements IEEE rounding mode, so it can cure this one easily.
C.2) it is more difficult with Fraction>>asFloat which does neither round to nearest even Float...
Bellerophon and ArbitraryPrecisionFloat together can fix the Fraction problem (conversion from decimal to binary representation is just a special case of these Large fractions).
I now know why i never succedeed in implementing my own Smalltalk Float reading in VW, despite of Integer infinite precision... I was over-trusting asFloat implementation that suffer the same problem...
D)-------------------------------------------------------------------------
So, maybe we should better move the fixes i wrote from Number>>readFrom: to LargeInteger and Fraction>>asFloat, Then exactly rounded Float>>readFrom: will be a side effect...
Nicolas
Hi Nicolas,
The first step is to publish what you have in any place you have access to (or even via email) so we can test these changes and see if they work as advertised ;-) I'm looking forward to throw a few of my test cases at the parser and see if they come out correctly.
Cheers, - Andreas
nicolas cellier wrote:
Le Vendredi 28 Avril 2006 20:08, nicolas cellier a écrit :
However i still have the bellerophon algorithm (from tony's reference) failing with last bit incorrect in a few cases (i can check that with asTrueFraction for number greater than 1.0 timestwoPower: 53). So i do not release it yet.
Nicolas
Subjects developped in this (too) long email are:
- A) Float readFrom: now round exactly :)
- B) my solution use a new ArbitraryPrecisionFloat class :(
- C) this class can solve other asFloat problems :)
- D) shouldn't the readFrom: fix better be moved to asFloat fix ?
A)----------------------------------------------------------------------------
OK, now i have the Float reading working, also for gradual underflow !
This of course solve Andreas' Numerics question: reading floating point constants, i now have (SqNumberParser on: '6.07710050630396597660e-11') nextNumber hex = '3DD0B4611A600000'.
B)----------------------------------------------------------------------------
The solution is not as light as i wanted, because i finally added an ArbitraryPrecisionFloat class to handle 64bits arithmetic involved in Bellerophon. So i do not know if i should publish my solution at http://bugs.impara.de/view.php?id=3512, or rather in SM. Unfortunately my SM account is blocked inactive...
It's funny how easy creating a new Number class was. Of course, ArbitraryPrecisionFloat lacks a short literal form syntax, it does not implement usual mathematical functions (default is to convert to Float). And it's not optimized at all (please don't compare to hardwired Float arithmetic...). But it's more general than just reading Float. This is why i wanted to publish on SM.
C)----------------------------------------------------------------------------
This can potentially solve other asFloat incorrect rounding behaviour:
C.1) current implementation of LargeInteger>>asFloat. will not round to nearest even Float when highBit > 53.
example: 16r1FFFFFFFFFFFF081 asFloat hex
The ArbitraryPrecisionFloat implements IEEE rounding mode, so it can cure this one easily.
C.2) it is more difficult with Fraction>>asFloat which does neither round to nearest even Float...
Bellerophon and ArbitraryPrecisionFloat together can fix the Fraction problem (conversion from decimal to binary representation is just a special case of these Large fractions).
I now know why i never succedeed in implementing my own Smalltalk Float reading in VW, despite of Integer infinite precision... I was over-trusting asFloat implementation that suffer the same problem...
D)----------------------------------------------------------------------------
So, maybe we should better move the fixes i wrote from Number>>readFrom: to LargeInteger and Fraction>>asFloat, Then exactly rounded Float>>readFrom: will be a side effect...
Nicolas
Le Lundi 01 Mai 2006 21:31, Andreas Raab a écrit :
Hi Nicolas,
The first step is to publish what you have in any place you have access to (or even via email) so we can test these changes and see if they work as advertised ;-) I'm looking forward to throw a few of my test cases at the parser and see if they come out correctly.
Cheers, - Andreas
OK i simply attach the prototype in this e-mail.
There is still work and cleaning needing to be done. I did not create the NumberParserException, some methods are unused and some redundant. Proper comments are sometimes lacking. ArbitraryPrecisionFloat needs more TestCase.
Major unfinished work lie in failure cases of Bellerophon: it will halt before using AlgorithmR, which is not tested yet. Let me know if you encounter the halt, i didn't yet.
SqNumberParserTest is a copy of NumberParsingTest for the interim (i did not overide Number>>readFrom: yet).
No method is overriden by the changeSet.
You can give it a try and perhaps fix some holes i did miss in my implementation.
Le Lundi 01 Mai 2006 20:59, Milan Zimmermann a écrit :
Nicolas,
This looks great, thanks for your description here. (and fwiw, I'd say yes to puting it on Impara and also yes to your D) item)
I am in favour of D) also, but did nothing about it yet...
Nicolas
Hi Francisco -
The reason I call this overkill is that the problem we've been talking about (Number readFrom: '' readStream) can *literally* be addressed with a one-line fix, like here:
aStream atEnd ifTrue:[^self error: 'At least one digit expected'].
If you need a whole class to do that, I call this overkill ;-)
Cheers, - Andreas
francisco.j.garau@jpmorgan.com wrote:
Andreas,
I completely agree with what you said except for the first sentence. Why do you think it is a "complete and utter overkill"? I can think of three possibilities:
- The extra class you are adding to the image (SqNumberParser)
- The extra object involved in the parsing
- All the explicit methods that you have to define on the SqNumberParser
object.
None of them seems an overkill to me. I am obviously missing something.
Cheers, Francisco
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Diego Fernandez -
francisco.j.garau＠jpmorgan.com -
Milan Zimmermann -
nicolas cellier -
stéphane ducasse