«

On Friday, November 16, 2012 10:42:01 AM UTC-8, Bart wrote:
> "Phil Carmody" <> wrote in message news:... > "BartC" <> writes: >> Why doesn't it print the right value? > > Probably a c library issue. What does > printf("%30.45f\n", 300.03); > give you? > > gcc 4.4 on my linux/powerpc gives > 300.029999999999972715158946812152862548828125000 > > The exact value is > > ? 5278183578906132/2^44. > 300.0299999999999727151589468121528625488281250000 0 I get: 300.029999999999970000000000000000000000000000000 using (mingw) gcc 4.5.0 on Windows. I'd prefer to get what you did.. HoweverDMC gives: 300.029999999999972710000000000000000000000000000 a few extra digits (but it seems incorrectly rounded down on the last digit). And PellesC gives: 300.029999999999953433870000000000000000000000000 which is not quite right. Finally, lcc-win32 gives: 300.030000000000000000000000000000000000000000000 which is either wildly inaccurate, or the only one that is spoton! -- Bartc


What does this get on those platforms (especially lcc-win32)?

printf("%30.45f\n", 300.02999999999997);

"Fred K" <> wrote in message
news:babef49c-0aec-4cc9-a86b-...

> What does this get on those platforms (especially lcc-win32)?
>
> printf("%30.45f\n", 300.02999999999997);

gcc:
300.029999999999970000000000000000000000000000000

lcc-win32:
300.030000000000000000000000000000000000000000000

DMC:
300.029999999999972710000000000000000000000000000

Pelles C:
300.030000000000046566120000000000000000000000000

So all the same as "300.03" except for the last.

--
Bartc

On Nov 15, 1:04*pm, hormelf...@gmail.com wrote:
> On Tuesday, November 13, 2012 5:43:13 AM UTC-8, Ben Bacarisse wrote:
> > Marcin Lukasik <mluka...@yazino.com> writes:

> > > But does this mean that VALUE(2) stores 300.029999 or 300.03?
>
> > Neither! It is stored as the closest floating point number to 300.03. Exactly
> > what that is is probably not important to you, but you can work it out if you
> > really need to know.
>
> It's likely to have "5" as the last digit...

why? I'm pretty sure this isn't so, but I'm interested in what made
you think that.

> > Read the excellent paper that James directed you to for
> > all the details (in my opinion, somewhat more than every programmer needs to
> > know, but extra knowledge is never a problem).
>
> If by "every programmer", you mean somebody who might have any kind
> of programming task thrown at them, then the knowledge is definitely
> helpful,

not really. You can go a long way without much use of floating point.
"what every computer scientist needs to know" is not exactly a light
read. The essential lessons "many numbers (notably 0.1) cannot be
represented in binary FP systems" and "many FP operations loose
precision" "corollary don't test two FP numbers for equality" are most
of what you need to know.

I'd just add FP arithmetic (like cryptography) shouldn't be attempted
without the support of a mathematical safety net (ie. knowing what you
are doing).

> in at least you'll know why your financial application is
> possibly giving wrong answers, but there's not enough information
> there to actually proactively fix the problem, so just another busted
> program, but you get paid the same amount anyway, so who cares except
> the user...

good grief.

On Saturday, November 17, 2012 6:39:48 AM UTC-8, Nick Keighley wrote:
> On Nov 15, 1:04*pm, hormelf...@gmail.com wrote:
> > On Tuesday, November 13, 2012 5:43:13 AM UTC-8, Ben Bacarisse wrote:
> > > Marcin Lukasik <mluka...@yazino.com> writes:
> > > > But does this mean that VALUE(2) stores 300.029999 or 300.03?
> > > Neither! It is stored as the closest floating point number to 300.03.
> > > what that is is probably not important to you, but you can work it out if > > > you really need to know.
> > It's likely to have "5" as the last digit...
> why? I'm pretty sure this isn't so,

How sure are you? Oh, that's right, "pretty"...

> but I'm interested in what made you think that.

Sheesh...

> > > Read the excellent paper that James directed you to for
> > > all the details (in my opinion, somewhat more than every programmer needs > > > to know, but extra knowledge is never a problem).
> > If by "every programmer", you mean somebody who might have any kind
> > of programming task thrown at them, then the knowledge is definitely
> > helpful,
> not really. You can go a long way without much use of floating point.

Sheesh...

> "what every computer scientist needs to know" is not exactly a light read..

Sheesh...actually, it's about 8th-grade level math, but then I had to
get all the way to the 11th grade to flunk out of a math class...

> The essential lessons "many numbers (notably 0.1) cannot be represented in
> binary FP systems" and "many FP operations loose precision" "corollary don't > test two FP numbers for equality" are most of what you need to know.

As always, the most important thing to know is what you don't know...this
is a very large body of knowledge for many programmers...

> I'd just add FP arithmetic (like cryptography) shouldn't be attempted without > the support of a mathematical safety net (ie. knowing what you are doing).

Knowing what you are doing is ALWAYS important, but how often does
THAT happen?

> > in at least you'll know why your financial application is
> > possibly giving wrong answers, but there's not enough information
> > there to actually proactively fix the problem, so just another busted
> > program, but you get paid the same amount anyway, so who cares except
> > the user...

> good grief.

Good grief indeed...I still remember the second time I used a computer
several decades ago. A friend of mine worked for one of the first companies
to make "home" computers, and as a prelude to me getting hired there, he
gave me an overview of their computers one night.

The computer had a "user-friendly" feature that allowed you to use it
as a calculator from the command line. So I typed in "2+2" and got the
answer "3.975" or some such nonsense. Neither one of us liberal arts
majors knew at the time why it gave such a strange answer, and obviously
neither did the idiot programmer who developed the feature (of course,
it wasn't really a "calculator" since actual calculators use binary-coded
decimal or similar).

Then a few years back I got a financial application for a trial run
and had to decide not to purchase when a calculation that should have
returned the value "100.00" actually returned "99.9999875" or some
such nonsense, so it was clear that 20 years of time hadn't made the
average working programmer any smarter...

---
William Ernest Reid

Nick Keighley <> wrote:

(snip)
>> It's likely to have "5" as the last digit...

> why? I'm pretty sure this isn't so, but I'm interested in what made
> you think that.

When I binary fraction (power of two in the denominator) is written
as a decimal fraction (power of ten in the denominator) the numerator
has lots of fives as factors, and powers of five tend to end in "5".

Consider pow(2.,-n) (I almost wrote 2.**(-n) but then remembered...)

Going down in n, 0.5, 0.25, 0.125. 0.0625, 0.03125, 0.015625,
each one is the next higher power of five, with the decimal point
moved over one more position.

I have wondered why the usual US measurement system uses strange
multiples (12 inches per foot, 5280 feet/mile) but binary fractions
for less than an inch.

(Drill bits come in 1/16, 3/32, 1/8, 5/32, 3/16, 7/32, 1/4 inch.
Biggers sets in multiples of 1/64th inch. All nice binary fractions.

-- glen

On 11/17/2012 9:39 AM, Nick Keighley wrote:
> On Nov 15, 1:04 pm, hormelf...@gmail.com wrote:
>> On Tuesday, November 13, 2012 5:43:13 AM UTC-8, Ben Bacarisse wrote:
>>> Marcin Lukasik <mluka...@yazino.com> writes:
>
>>>> But does this mean that VALUE(2) stores 300.029999 or 300.03?
>>
>>> Neither! It is stored as the closest floating point number to 300.03. Exactly
>>> what that is is probably not important to you, but you can work it out if you
>>> really need to know.
>>
>> It's likely to have "5" as the last digit...
>
> why? I'm pretty sure this isn't so, but I'm interested in what made
> you think that.

Consider a decimal fraction whose rightmost non-zero
digit is *not* five. Multiply that fraction by a suitable
power of ten so the rightmost non-zero is now in the tenth's
place. The product is

[integer] + {1,2,3,4,6,7,8,9}/10

Your mission, should you choose to accept it, is to represent
all eight possible fractions in binary, that is, as quotients
of the form N/2^K for positive integer N and K. Good luck, Nick,
and if you or any of your team experience numerical frustration,
the Secretary will disavow all knowledge.

--
Eric Sosman
d

On Sat, 17 Nov 2012 15:56:34 +0000 (UTC), glen herrmannsfeldt
<> wrote:

>Nick Keighley <> wrote:
>
>(snip)
>>> It's likely to have "5" as the last digit...
>
>> why? I'm pretty sure this isn't so, but I'm interested in what made
>> you think that.
>
>When I binary fraction (power of two in the denominator) is written
>as a decimal fraction (power of ten in the denominator) the numerator
>has lots of fives as factors, and powers of five tend to end in "5".
>
>Consider pow(2.,-n) (I almost wrote 2.**(-n) but then remembered...)
>
>Going down in n, 0.5, 0.25, 0.125. 0.0625, 0.03125, 0.015625,
>each one is the next higher power of five, with the decimal point
>moved over one more position.
>
>I have wondered why the usual US measurement system uses strange
>multiples (12 inches per foot, 5280 feet/mile) but binary fractions
>for less than an inch.
>
>(Drill bits come in 1/16, 3/32, 1/8, 5/32, 3/16, 7/32, 1/4 inch.
>Biggers sets in multiples of 1/64th inch. All nice binary fractions.
>

You basically stubbled on your own answer.

It has only been recently (in terms of history) that measurements
could be made in hundreds and even tens.

For most of recorded history, machine shops had to create their own
tools. Imagine for a moment you needed to create your own scale
(ruler) and all you had was a few scales (very expensive) where one
often could only accurately determine an "inch" as equal to your
neighbor's "inch". How would you mark it off?

By halving. Easily done using compass and care, anything else is an
adventure. (Try trisecting an angle. or five-secting a span. <g>)

The key to the mile is not the feet/mile but yards to mile (1760).
That gives use 880 yards to a half section. 440 yards to the quarter,
.... . All easier to mark off using the simple tools of the time.

-ralph

On 11/17/2012 1:25 PM, ralph wrote:
>[...]
> You basically stubbled on your own answer.

Shaving yaks?

--
Eric Sosman
d

"ralph" <> wrote in message
news:...
> On Sat, 17 Nov 2012 15:56:34 +0000 (UTC), glen herrmannsfeldt

>>I have wondered why the usual US measurement system uses strange
>>multiples (12 inches per foot, 5280 feet/mile) but binary fractions
>>for less than an inch.
>>
>>(Drill bits come in 1/16, 3/32, 1/8, 5/32, 3/16, 7/32, 1/4 inch.
>>Biggers sets in multiples of 1/64th inch. All nice binary fractions.

> It has only been recently (in terms of history) that measurements
> could be made in hundreds and even tens.
>
> For most of recorded history, machine shops had to create their own
> tools. Imagine for a moment you needed to create your own scale
> (ruler) and all you had was a few scales (very expensive) where one
> often could only accurately determine an "inch" as equal to your
> neighbor's "inch". How would you mark it off?
>
> By halving. Easily done using compass and care, anything else is an
> adventure. (Try trisecting an angle. or five-secting a span. <g>)

Dividing a straight line into N equal sections is trivial, although you
might need a setsquare in addition to ruler, compass and pencil. (However a
setsquare can be constructed by marking up some material using a ruler,
compass and pencil, so it's not essential.)

--
Bartc

ralph <> writes:
<snip>
> The key to the mile is not the feet/mile but yards to mile (1760).
> That gives use 880 yards to a half section. 440 yards to the quarter,
> ... . All easier to mark off using the simple tools of the time.

Your point about small units being divided is a good one, but it's the
very fact that you can add any number of units easily that has given
rise to these crazy systems -- crazy because there's a factor of 11 in
there.

The key to the mile is actually the furlong -- it was defined by statute
to be eight furlongs, with a furlong being 40 poles. All sane(ish)
except that a pole is 16 1/2 feet. Yes, 16 1/2. It's that 16 1/2 gives
rise to the 11.

--
Ben.