[Pharo-project] About float: new chapter looking for reader and contributors
Hi guys I started to put in shape a chapter on floats based on the numerous discussions we got over the years. You can find it on github under the pharo by example book/Floats Stef
Include a link to: What Every Computer Scientist Should Know About Floating-Point Arithmetic http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html -- View this message in context: http://forum.world.st/About-float-new-chapter-looking-for-reader-and-contrib... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Yes this was my idea but I was in the train and no internet connection. I should reread it by the way. Stef On Apr 13, 2011, at 1:44 AM, DougEdmunds wrote:
Include a link to: What Every Computer Scientist Should Know About Floating-Point Arithmetic http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html
-- View this message in context: http://forum.world.st/About-float-new-chapter-looking-for-reader-and-contrib... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <stephane.ducasse@free.fr>wrote:
Hi guys
I started to put in shape a chapter on floats based on the numerous discussions we got over the years. You can find it on github under the pharo by example book/Floats
For me it's a good candidate for a ProfStef tutorial (text, evaluations, text, ...) Laurent
Stef
Here is a small variation. It's not perfect, and most elements are already in Stephane's text. But maybe we can jump deeper in the first example that claims some explanations. We can first explain that 0.1 will answer the Float nearest to (1/10). Thanks to this important property, if we enter 0.1, it will be printed 0.1 and reinterpreted the same. A nice property to have! However, what is fundamental is that this Float won't be equal to (1/10). How is this so ? Hey we didn't learn that in school ! Well, Float have an internal representation in base 2, of the form mantissa * (2 raisedTo: exponent). There is no way to represent (1/10) in base 2 with a finite number of bits... (like illustrated with 1.3 example, #significandAsInteger, #exponent, #ulp and such kind of messages...). A rounding operation has to occur to make this number fit in Float internal representation ( it might be good to tell that Pharo Float follow the IEEE 754 double precision standard with a link to http://en.wikipedia.org/wiki/IEEE_754-1985 . This standard governs the way most FPU work on this planet). This rounding operation introduce a rounding error, and thus we don't get exactly (1/10). To know the exact internal representation of 0.1 the Smalltalk way is as usual to send a message: 0.1 asTrueFraction. The same goes with 0.2, it's not equal to (2/10), check it with 0.2 asTrueFraction. So what goes on with this operation 0.1+0.2 ? In fact you asked the system to perform following operation (0.1 asTrueFraction+0.2 asTrueFraction) asFloat. (0.1 asTrueFraction+0.2 asTrueFraction) is an exact operation, but the result again does not fit in Float internal representation: (0.1 asTrueFraction+0.2 asTrueFraction) numerator highBit -> 54 (0.1 asTrueFraction+0.2 asTrueFraction) numerator lowBit -> 1 This means that 54 bits of mantissa are required to represent this number. Float only have 53 Float precision -> 53 So converting it to aFloat requires another rounding operation, and due to this rounding error, (0.1 asTrueFraction+0.2 asTrueFraction) ~= (0.1 asTrueFraction+0.2 asTrueFraction) asFloat. That's exactly how your IEEE-754 compliant FPU will work. In the whole process, 3 rounding errors have been cumulated: (1/10) asFloat -> 0.1 (the error is not yet visible, but it's here already) (2/10) asFloat -> 0.2 (same) (0.1 asTrueFraction+0.2 asTrueFraction) asFloat -> 0.30000000000000004 This is to be compared to 0.3, which has a single rounding error: (3/10) asFloat -> 0.3 Due to these rounding errors, and the way they cumulate or annihilate, both result might differ. And in this case, they differ. This is a very important property of Float. Float are fast thanks to hardware acceleration, and thanks to these rounding errors that keep the number of significant bits from growing. But the counterpart is that operations on Float are inexact. Due to this inexactness, it is most often inadequate to rely on strict equality of Float, as this very simple example illustrates. Instead, Float comparisons shall better be tested with fuzzy tolerance. Note that the nice thing with Pharo is that you immediately see that (0.1+0.2) ~= 0.3 thanks to extraneous digits printed. Pharo does not hide the horrible truth by shortening the printed representation to 0.3 like some system do. However, the decimal printed form does not show you the truth about 0.1 ~= (1/10). Inexactness is hidden. This is an implicit knowledge to remember about Float, that you now learned with this lesson. Remember, this is not a deficiency of Pharo. This is the way Float are expected to work whatever the language. Nicolas 2011/4/13 laurent laffont <laurent.laffont@gmail.com>:
On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I started to put in shape a chapter on floats based on the numerous discussions we got over the years. You can find it on github under the pharo by example book/Floats
For me it's a good candidate for a ProfStef tutorial (text, evaluations, text, ...) Laurent
Stef
Nicolas why don't you grab the latex file and edit it? because I do not know anything about float. Stef On Apr 13, 2011, at 10:37 PM, Nicolas Cellier wrote:
Here is a small variation. It's not perfect, and most elements are already in Stephane's text. But maybe we can jump deeper in the first example that claims some explanations.
We can first explain that 0.1 will answer the Float nearest to (1/10). Thanks to this important property, if we enter 0.1, it will be printed 0.1 and reinterpreted the same. A nice property to have!
However, what is fundamental is that this Float won't be equal to (1/10). How is this so ? Hey we didn't learn that in school ! Well, Float have an internal representation in base 2, of the form mantissa * (2 raisedTo: exponent). There is no way to represent (1/10) in base 2 with a finite number of bits... (like illustrated with 1.3 example, #significandAsInteger, #exponent, #ulp and such kind of messages...). A rounding operation has to occur to make this number fit in Float internal representation ( it might be good to tell that Pharo Float follow the IEEE 754 double precision standard with a link to http://en.wikipedia.org/wiki/IEEE_754-1985 . This standard governs the way most FPU work on this planet). This rounding operation introduce a rounding error, and thus we don't get exactly (1/10).
To know the exact internal representation of 0.1 the Smalltalk way is as usual to send a message: 0.1 asTrueFraction. The same goes with 0.2, it's not equal to (2/10), check it with 0.2 asTrueFraction.
So what goes on with this operation 0.1+0.2 ? In fact you asked the system to perform following operation (0.1 asTrueFraction+0.2 asTrueFraction) asFloat. (0.1 asTrueFraction+0.2 asTrueFraction) is an exact operation, but the result again does not fit in Float internal representation: (0.1 asTrueFraction+0.2 asTrueFraction) numerator highBit -> 54 (0.1 asTrueFraction+0.2 asTrueFraction) numerator lowBit -> 1 This means that 54 bits of mantissa are required to represent this number. Float only have 53 Float precision -> 53 So converting it to aFloat requires another rounding operation, and due to this rounding error, (0.1 asTrueFraction+0.2 asTrueFraction) ~= (0.1 asTrueFraction+0.2 asTrueFraction) asFloat. That's exactly how your IEEE-754 compliant FPU will work.
In the whole process, 3 rounding errors have been cumulated: (1/10) asFloat -> 0.1 (the error is not yet visible, but it's here already) (2/10) asFloat -> 0.2 (same) (0.1 asTrueFraction+0.2 asTrueFraction) asFloat -> 0.30000000000000004
This is to be compared to 0.3, which has a single rounding error: (3/10) asFloat -> 0.3
Due to these rounding errors, and the way they cumulate or annihilate, both result might differ. And in this case, they differ. This is a very important property of Float. Float are fast thanks to hardware acceleration, and thanks to these rounding errors that keep the number of significant bits from growing. But the counterpart is that operations on Float are inexact. Due to this inexactness, it is most often inadequate to rely on strict equality of Float, as this very simple example illustrates. Instead, Float comparisons shall better be tested with fuzzy tolerance.
Note that the nice thing with Pharo is that you immediately see that (0.1+0.2) ~= 0.3 thanks to extraneous digits printed. Pharo does not hide the horrible truth by shortening the printed representation to 0.3 like some system do. However, the decimal printed form does not show you the truth about 0.1 ~= (1/10). Inexactness is hidden. This is an implicit knowledge to remember about Float, that you now learned with this lesson.
Remember, this is not a deficiency of Pharo. This is the way Float are expected to work whatever the language.
Nicolas
2011/4/13 laurent laffont <laurent.laffont@gmail.com>:
On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I started to put in shape a chapter on floats based on the numerous discussions we got over the years. You can find it on github under the pharo by example book/Floats
For me it's a good candidate for a ProfStef tutorial (text, evaluations, text, ...) Laurent
Stef
I created a git account last night but must install latex on my mac. I don't have your rythm :) Nicolas 2011/4/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Nicolas
why don't you grab the latex file and edit it? because I do not know anything about float.
Stef
On Apr 13, 2011, at 10:37 PM, Nicolas Cellier wrote:
Here is a small variation. It's not perfect, and most elements are already in Stephane's text. But maybe we can jump deeper in the first example that claims some explanations.
We can first explain that 0.1 will answer the Float nearest to (1/10). Thanks to this important property, if we enter 0.1, it will be printed 0.1 and reinterpreted the same. A nice property to have!
However, what is fundamental is that this Float won't be equal to (1/10). How is this so ? Hey we didn't learn that in school ! Well, Float have an internal representation in base 2, of the form mantissa * (2 raisedTo: exponent). There is no way to represent (1/10) in base 2 with a finite number of bits... Â (like illustrated with 1.3 example, #significandAsInteger, #exponent, #ulp and such kind of messages...). A rounding operation has to occur to make this number fit in Float internal representation ( it might be good to tell that Pharo Float follow the IEEE 754 double precision standard with a link to http://en.wikipedia.org/wiki/IEEE_754-1985 . This standard governs the way most FPU work on this planet). This rounding operation introduce a rounding error, and thus we don't get exactly (1/10).
To know the exact internal representation of 0.1 the Smalltalk way is as usual to send a message: 0.1 asTrueFraction. The same goes with 0.2, it's not equal to (2/10), check it with 0.2 asTrueFraction.
So what goes on with this operation 0.1+0.2 ? In fact you asked the system to perform following operation (0.1 asTrueFraction+0.2 asTrueFraction) asFloat. (0.1 asTrueFraction+0.2 asTrueFraction) is an exact operation, but the result again does not fit in Float internal representation: (0.1 asTrueFraction+0.2 asTrueFraction) numerator highBit -> 54 (0.1 asTrueFraction+0.2 asTrueFraction) numerator lowBit -> 1 This means that 54 bits of mantissa are required to represent this number. Float only have 53 Float precision -> 53 So converting it to aFloat requires another rounding operation, and due to this rounding error, (0.1 asTrueFraction+0.2 asTrueFraction) ~= (0.1 asTrueFraction+0.2 asTrueFraction) asFloat. That's exactly how your IEEE-754 compliant FPU will work.
In the whole process, 3 rounding errors have been cumulated: (1/10) asFloat -> 0.1 (the error is not yet visible, but it's here already) (2/10) asFloat -> 0.2 (same) (0.1 asTrueFraction+0.2 asTrueFraction) asFloat -> 0.30000000000000004
This is to be compared to 0.3, which has a single rounding error: (3/10) asFloat -> 0.3
Due to these rounding errors, and the way they cumulate or annihilate, both result might differ. And in this case, they differ. This is a very important property of Float. Float are fast thanks to hardware acceleration, and thanks to these rounding errors that keep the number of significant bits from growing. But the counterpart is that operations on Float are inexact. Due to this inexactness, it is most often inadequate to rely on strict equality of Float, as this very simple example illustrates. Instead, Float comparisons shall better be tested with fuzzy tolerance.
Note that the nice thing with Pharo is that you immediately see that (0.1+0.2) ~= 0.3 thanks to extraneous digits printed. Pharo does not hide the horrible truth by shortening the printed representation to 0.3 like some system do. However, the decimal printed form does not show you the truth about 0.1 ~= (1/10). Inexactness is hidden. This is an implicit knowledge to remember about Float, that you now learned with this lesson.
Remember, this is not a deficiency of Pharo. This is the way Float are expected to work whatever the language.
Nicolas
2011/4/13 laurent laffont <laurent.laffont@gmail.com>:
On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <stephane.ducasse@free.fr> wrote:
Hi guys
I started to put in shape a chapter on floats based on the numerous discussions we got over the years. You can find it on github under the pharo by example book/Floats
For me it's a good candidate for a ProfStef tutorial (text, evaluations, text, ...) Laurent
Stef
On Apr 14, 2011, at 11:31 AM, Nicolas Cellier wrote:
I created a git account last night but must install latex on my mac.
you can also just write and I will latex it. There is no problem.
I don't have your rythm :)
:) But you are doing a lot of things too. Sometimes I have the impression that I could be more focused and it would be better but the system does not give me this chance. Stef
Hi Stephane, did you notice https://github.com/SquareBracketAssociates/PharoByExample-english/pulls ? Nicolas 2011/4/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Apr 14, 2011, at 11:31 AM, Nicolas Cellier wrote:
I created a git account last night but must install latex on my mac.
you can also just write and I will latex it. There is no problem.
I don't have your rythm :)
:) But you are doing a lot of things too. Sometimes I have the impression that I could be more focused and it would be better but the system does not give me this chance. Stef
:) No I was driving all day long yesterday and I will try to find my way in the github interface. Damien showed me how I can pull a request and merge it, so this is time to try for real. Stef On Apr 18, 2011, at 10:21 PM, Nicolas Cellier wrote:
Hi Stephane, did you notice https://github.com/SquareBracketAssociates/PharoByExample-english/pulls ?
Nicolas
2011/4/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Apr 14, 2011, at 11:31 AM, Nicolas Cellier wrote:
I created a git account last night but must install latex on my mac.
you can also just write and I will latex it. There is no problem.
I don't have your rythm :)
:) But you are doing a lot of things too. Sometimes I have the impression that I could be more focused and it would be better but the system does not give me this chance. Stef
sadly after 10 min I could not find how to integrate your work. I hate this cool UI that are just plain confusing and totally inadapted. I have no idea how to do it. I will try to find but I hate hate this $#%^&*() system. Stef On Apr 18, 2011, at 10:21 PM, Nicolas Cellier wrote:
Hi Stephane, did you notice https://github.com/SquareBracketAssociates/PharoByExample-english/pulls ?
Nicolas
2011/4/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Apr 14, 2011, at 11:31 AM, Nicolas Cellier wrote:
I created a git account last night but must install latex on my mac.
you can also just write and I will latex it. There is no problem.
I don't have your rythm :)
:) But you are doing a lot of things too. Sometimes I have the impression that I could be more focused and it would be better but the system does not give me this chance. Stef
2011/4/19 Stéphane Ducasse <stephane.ducasse@inria.fr>:
sadly
after 10 min I could not find how to integrate your work. I hate this cool UI that are just plain confusing and totally inadapted. I have no idea how to do it. I will try to find but I hate hate this $#%^&*() system.
Stef
BTW, I shamelessly let an untranslated frenchism: pose a division It should better be: lay out a division Nicolas
ok I will fix it :) On Apr 22, 2011, at 1:03 AM, Nicolas Cellier wrote:
2011/4/19 Stéphane Ducasse <stephane.ducasse@inria.fr>:
sadly
after 10 min I could not find how to integrate your work. I hate this cool UI that are just plain confusing and totally inadapted. I have no idea how to do it. I will try to find but I hate hate this $#%^&*() system.
Stef
BTW, I shamelessly let an untranslated frenchism:
pose a division
It should better be:
lay out a division
Nicolas
participants (5)
-
DougEdmunds -
laurent laffont -
Nicolas Cellier -
stephane ducasse -
Stéphane Ducasse