Smalltalk › Pharo › Pharo Smalltalk Developers

About float: new chapter looking for reader and contributors

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

stephane ducasse

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

Float.pdf (156K) Download Attachment

DougEdmunds

Re: About float: new chapter looking for reader and contributors

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

Stéphane Ducasse

Re: About float: new chapter looking for reader and contributors

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-contributors-tp3445093p3445905.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

laurent laffont

Re: About float: new chapter looking for reader and contributors

In reply to this post by stephane ducasse

On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <[hidden email]> 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 Cellier

Re: About float: new chapter looking for reader and contributors

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

>
>
>
> On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <[hidden email]>
> 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
>>
>
>

Stéphane Ducasse

Re: About float: new chapter looking for reader and contributors

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 <[hidden email]>:
>>
>>
>>
>> On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <[hidden email]>
>> 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
>>>
>>
>>
>

Float.tex (11K) Download Attachment

Nicolas Cellier

Re: About float: new chapter looking for reader and contributors

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

> 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 <[hidden email]>:
>>>
>>>
>>>
>>> On Tue, Apr 12, 2011 at 6:07 PM, stephane ducasse <[hidden email]>
>>> 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
>>>>
>>>
>>>
>>
>
>
>

Stéphane Ducasse

Re: About float: new chapter looking for reader and contributors

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

Nicolas Cellier

Re: About float: new chapter looking for reader and contributors

Hi Stephane,
did you notice https://github.com/SquareBracketAssociates/PharoByExample-english/pulls
?

Nicolas

2011/4/14 Stéphane Ducasse <[hidden email]>:

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

Stéphane Ducasse

Re: About float: new chapter looking for reader and contributors

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

Stéphane Ducasse

Re: About float: new chapter looking for reader and contributors

In reply to this post by Nicolas Cellier

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:

Nicolas Cellier

Re: About float: new chapter looking for reader and contributors

2011/4/19 Stéphane Ducasse <[hidden email]>:
> 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

Stéphane Ducasse

Re: About float: new chapter looking for reader and contributors

ok I will fix it :)

On Apr 22, 2011, at 1:03 AM, Nicolas Cellier wrote:

> 2011/4/19 Stéphane Ducasse <[hidden email]>:
>> 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
>