Re: Help w/ Floats needed!

[Somebody]

So, what to do? Cast x to a double.

Change the line in the program to:
double z = static_cast<double>( x ) / y;
and the output is
0.333333

I know that :)... I was only including psuedo-code... but the point is:

double x = 100;
double cx = 300;
double ratio = x / cx; // = 0.33333

double newwidth = 300;
double newpos = ratio * newwidth; // result = 99, NOT 100 which is what it
should be.

My solution of storing the numerator and denomenator to get a real scaling
factor worked.

[Paul Brettschneider]

Somebody wrote:

>So, what to do? Cast x to a double.
Change the line in the program to:
double z = static_cast<double>( x ) / y;
and the output is
0.333333

I know that :)... I was only including psuedo-code... but the point is:

double x = 100;
double cx = 300;
double ratio = x / cx; // = 0.33333

double newwidth = 300;
double newpos = ratio * newwidth; // result = 99, NOT 100 which is what it
should be.

Beg your pardon?

#include <iostream>

int main()
{
double x = 100;
double cx = 300;
double ratio = x / cx;

double newwidth = 300;
double newpos = ratio * newwidth;

std::cout << newpos << std::endl;
}

gives 100 for me. Of course the internal representation might correspond to
99.99999 or something like that but *definitely* not something closer to 99
than to 100.

[James Kanze]

On 18 mai, 20:02, "Somebody" <[e-mail]:

So, what to do? Cast x to a double.
Change the line in the program to:
double z = static_cast<double>( x ) / y;
and the output is
0.333333

I know that :)... I was only including psuedo-code... but the point is:

double x = 100;
double cx = 300;
double ratio = x / cx; // = 0.33333

double newwidth = 300;
double newpos = ratio * newwidth; // result = 99, NOT 100 which is what it
should be.

Are you kidding? The result won't be 100.0, but it will
be fairly close to 100. (In fact, it might actually end up as
100.0; it does on my machine, anyway. But of course, you can't
count on it; you can only count on it being fairly close.)

My solution of storing the numerator and denomenator to get a
real scaling factor worked.

It's guaranteed to be 100% accurate. And very slow, and liable
to overflow in integral arithmetic. Depending on the
application, it might be what's needed, or it might not be.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Somebody]

>Are you kidding? The result won't be 100.0, but it will

>be fairly close to 100. (In fact, it might actually end up as
100.0; it does on my machine, anyway. But of course, you can't
count on it; you can only count on it being fairly close.)

Fairly close to 100 is not 100, now is it? :). In fact, when I convert it to
an int, it would get truncated down to 99.

Imagine this scenario to explain why I needed it EXACT. You have an object
on the screen at x,y = 100,100. You do something on the screen that causes
the layout to be recalculated and suddenly the object moves to 99,99. Not
very good.

[Somebody]

gives 100 for me. Of course the internal representation might correspond

to
99.99999 or something like that but *definitely* not something closer to
99
than to 100.

Hmm... so it does for me too (in a test app). I was definitely seeing round
off errors in my layout when I was using doubles. Possible I might have had
that because of the way I did the casting throughout the algorithm. Oh well,
its working with the int pair solution. No point in going back to try to
figure it out.

[Thomas J. Gritzan]

Somebody schrieb:

>Are you kidding? The result won't be 100.0, but it will
be fairly close to 100. (In fact, it might actually end up as
100.0; it does on my machine, anyway. But of course, you can't
count on it; you can only count on it being fairly close.)

Fairly close to 100 is not 100, now is it? :). In fact, when I convert it to
an int, it would get truncated down to 99.

Imagine this scenario to explain why I needed it EXACT. You have an object
on the screen at x,y = 100,100. You do something on the screen that causes
the layout to be recalculated and suddenly the object moves to 99,99. Not
very good.

You could try rounding the double to nearest integer when converting to int:

int roundToNearest(double d)
{
return static_cast<int>(d + 0.5);
}

This will round values in the range [98.5, 99.5) to 99 and [99.5, 100.5)
to 100. Simple casting to int will round the value down.

--
Thomas

[James Kanze]

On May 18, 9:58 pm, "Somebody" <[e-mail]:

Are you kidding? The result won't be 100.0, but it will
be fairly close to 100. (In fact, it might actually end up as
100.0; it does on my machine, anyway. But of course, you can't
count on it; you can only count on it being fairly close.)

Fairly close to 100 is not 100, now is it? :). In fact, when I
convert it to an int, it would get truncated down to 99.

If you want it rounded to a certain precision, you round it to
that precision. If you round the value to an int, you'll get
100, and not 99.

Imagine this scenario to explain why I needed it EXACT. You
have an object on the screen at x,y = 100,100. You do
something on the screen that causes the layout to be
recalculated and suddenly the object moves to 99,99. Not very
good.

So round correctly when you need to determine the pixel.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Paavo Helde]

"Thomas J. Gritzan" <ph*************@gmx.dekirjutas:

>
You could try rounding the double to nearest integer when converting
to int:

int roundToNearest(double d)
{
return static_cast<int>(d + 0.5);
}

That would be wrong for negative numbers. Better use:

int roundToNearest(double d)
{
return static_cast<int>(floor(d + 0.5));
}

Regards
Paavo