# How do you divide 1.6 / 0.1

This topic is 830 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi all.

I know dumb ass question.

I'm using vc10 express.

if I do this

float f = 1.6 / 0.1 = 16; all good

But if I do this

double mass = 0.1;

float posx = 1.6;

double dd = posx / mass;

dd = 1.6;

can 0.1 ever = 0.0, as for now its = to 1.0

windows caluclator saying its 16 so does the Iphone vc saying its 1.6

##### Share on other sites
Use two equal signs == instead of one = when you want to make a comparison. A single equal sign always means "assign", which will overwrite the variable's value with a new value.

Also, you might have problems comparing floating point values to exact numbers, especially in the case of 0.1 and 1.6 due to the inexact internal format of floats and doubles. Edited by Nypyren

##### Share on other sites

no I looking at the value from setting a watch. I know that about floats but this is no rounding error there must be some thing up. its turning 0.1 into 1.0.

even Like this.

.

double e = 1.6 / 0.1;
//works
double m = RTSComponentMotion.m_dMass;
double x = m_vSteeringForce.x;
double y = m_vSteeringForce.y;
double z = m_vSteeringForce.z;

x = x / m;
y = y / m;
z = z / m;
//does not work
//Acceleration = Force/Mass
D3DXVECTOR3 acceleration;
acceleration.x = x;
acceleration.y = y;
acceleration.z = z;


did some thing break.

##### Share on other sites

Can you give some more detail on "does not work". ? What you wrote should not be off by a factor of ten.

On the inexact and rounding thing, that usually takes place about six decimal digits out.

People are used to base ten. So we are fine with 0.1 or 0.2 or 0.9321 and similar. That 0.9321 is represented as 9/10 + 3/100 + 2/1000 + 1/10000.

But in base ten we get really messed up when trying to represent a fraction like 2/3. We write 0.666666, repeating forever because we cannot exactly represent it. No matter how hard we try in base ten, it will always be an inexact representation of 2/3.

The same thing applies in other number bases.

Computers are base two. They do fractions as 1/2, 1/4, 1/8, 1/16, 1/32, 1/64. They are combined the same way we add 1/10, 1/100, 1/1000, 1/10000.

Trying to represent 0.6 will never work out exactly in base two.  As a fractional binary is 0.1001 1001 1001 1001...  that is, 1/2 + 1/16 + 1/32 + 1/256 + 1/512 + 1/4096, which Google says is 0.59985351562.  It gets really close to 0.6, just like 0.66666 in base ten gets really close to 2/3.

Whenever you work with floating point numbers, it is best to think of them as approximations. They are usually right within a small tolerance.  There are technical rules for figuring out the precision, but they're probably more than you want in this post.

Since they're approximations, and since only a limited number of bits fit in a value, any time you mix floating points that are different orders of magnitude, about six digits different, the math tends to break down quickly.  So if you've got very small values of acceleration combined with very large forces, the math can break down when the processor tries to convert them to the same scale for the operations.

##### Share on other sites

I think that it is not a matter of rounding, I guess that you use a variable (mass) which got either not properly initiliased or overwritten. Output the variable just before doing the calculation to check it.

##### Share on other sites

long double seems to give the correct results.

long double m = RTSComponentMotion.m_dMass;

long double x = m_vSteeringForce.x;

long double y = m_vSteeringForce.y;

long double z = m_vSteeringForce.z;

x = x / m;

y = y / m;

z = z / m;

but why does this work;

float x = 1.6 / 0.1; Does the compiler use long doubles.???

##### Share on other sites

What are the actual values on each of those lines?

Stop it in the debugger.

From the debugger screen, what are the three actual values of m_vSteeringForce.x,y,z? What is the actual value of m?  What is the value that is stored?

/Edit: I can think of many possibilities, including that x,y, and z are integers rather than floating point types.

Edited by frob

##### Share on other sites

I'm viewing it all in the debugger watch window.

D3DXVECTOR3 m_vSteeringForce;

m_vSteeringForce.x    = -2.6226043701171875e-005;

m_vSteeringForce.y = -6.1118044e-010;

m_vSteeringForce.z = 2.5629997e-006;

long double m = 0.1;//mass

long double x = m_vSteeringForce.x;

long double y = m_vSteeringForce.y;

long double z = m_vSteeringForce.z;

x = x / m;

y = y / m;

z = z / m;

x = -2.6226043701171875e-005;

y = -6.1118043959140778e-009;

z = 2.5629997253417969e-005;

##### Share on other sites
double m = RTSComponentMotion.m_dMass;


That looks suspiciously like a static field to me, which has a few ways of being misused that can cause mysterious problems. Can you post the definitions of RTSComponentMotion and m_dMass, the name of the file they're in, and the code assigning their values and the name of the file(s) those are in?

##### Share on other sites

m_vSteeringForce.x    = -2.6226043701171875e-005;

(later)

x = -2.6226043701171875e-005;

m_vSteeringForce.y = -6.1118044e-010;
m_vSteeringForce.z = 2.5629997e-006;

(later)

y = -6.1118043959140778e-009;
z = 2.5629997253417969e-005;

##### Share on other sites

I'm assuming either he stopped at the wrong place in the debugging or copy/paste error.

Overall These all appear as expected.

Dividing by 0.1 is the same as multiplying by ten.

I'm assuming you mistyped or selected the x value after the first division because the before and after values didn't change.

The values are REALLY small, which is concerning.

The forces are:

-0.000026226

-0.00000000061118

0.0000256299

When you start working with bigger numbers, very often the CPU needs to bring them to the same scale.

We'll use addition because it is easy.

So let's say we're adding that acceleration to an existing acceleration:

10.1234 + -0.00000000061118

The result is a destructive operation. The first thing the CPU needs to do is bring them up to the same scale, and it has roughly six decimal digits of precision.  So it rounds to (10.1234) + (-0.00000) = (10.1234)

Which probably leads to a result different from what he wanted, but correct (within precision requirements) for floating point math.

##### Share on other sites

this is a new app its to test motion of units and to control the steering with a PID controller.

I think its some thing to do with the 5629997253417969e-005  the e-005;

because if I code

x = 1.6;

x = x / m;

x = 16.0.

my steering force is foobar.

last night I was thinking ghost in the machine, first comes paranoia then realization and only then maybe the fix. I call this the PRF affect.

Is it my force values.

##### Share on other sites

5629997253417969e-005  the e-005;

It is just that the number is very small.

0.0000562999...

If you are talking meters, that is 56 micrometers. That's roughly the width of a human hair.

If you're talking meters per second, that is moving a human hair's width every second.

The one that had e-010, that's on the order of Angrstroms if you're looking at 1.0 being a meter.  That is the size of a single atom.

Again, those numbers are really small.

##### Share on other sites

Say What.

If you are talking meters, that is 56 micrometers. That's roughly the width of a human hair.

If you're talking meters per second, that is moving a human hair's width every second

That would be why my tank move so slow.

How do you apply a scale to the forces. the Book Programming game Ai by Example is Normalizing all the forces, which is leading to the small values.

nope just must of been late last night and I changed the DesiredVelocity D3DXVec3Length to D3DXVec3LengthSq and was getting tiny force.

and plus I got transfixed on why the steering force was the same after a divide Ahhhhh mutant.

Oh now the fun of integrating the PID controller to steer the tank,, fun fun fun. Found it here

##### Share on other sites

Yeah, I mentioned to pay attention to scale in each of the posts.  I guess the fourth time is the charm.  :-)

Orders of magnitude are important.

One or two orders of magnitude are usually normal in games.

Any time you see four or more orders of magnitude out of scale, it is so far distant that it doesn't even matter.

When you're working on meter scale, any power of ten (e0xx) more than +2 or -2 (or more) means something is likely broken.

Going bigger, e+2 and you're talking about the distance of sports arenas; still possible in games but less common. e+3 is kilometers where you're normally looking at different levels or zones and normally not used in games. e+4 and you're talking the scale of cities. e+6 and you're talking full planet diameter.

Going smaller, e-2 and you're talking centimeters which are about the limit downward. e-3 is millimeters, the scale of a fingernail width and usually too small for games.  When you had e-5 you're on the scale of the width of a hair, e-10 you're on the scale of a single atom.

Edited by frob

##### Share on other sites
You'll get a much better experience in this forum if you post an actual program that we can compile and run ourselves to see the problem. Try to make the program "minimal", meaning you wouldn't be able to show the problem if it were any smaller. Very often you'll find the answer yourself in the process of writing this minimal program. And if you don't, you can post it here and we'll be able to help you much better. Edited by Álvaro

##### Share on other sites
I'm surprised that in 2015 C++ doesn't have a decimal data type for exactly these situations. IE. accurate floating-point/decimal math.

##### Share on other sites

There have been several papers proposing decimal types for C++. Here's a relatively recent one. I know there were a few in 2004-2005, but they were poorly reviewed and didn't make it in.

##### Share on other sites

I'm surprised that in 2015 C++ doesn't have a decimal data type for exactly these situations. IE. accurate floating-point/decimal math.

Considering that you're using VS10, you don't even have extensive access to C11. To be fair though, C++ is reaching that point in it's lifespan where it's becoming archaic.

##### Share on other sites

I'm surprised that in 2015 C++ doesn't have a decimal data type for exactly these situations. IE. accurate floating-point/decimal math.

Considering that you're using VS10, you don't even have extensive access to C11. To be fair though, C++ is reaching that point in it's lifespan where it's becoming archaic.

I'm not sure where or how you're conjuring the idea that I'm using VS10. I use VS12 and 13.

##### Share on other sites

I'm surprised that in 2015 C++ doesn't have a decimal data type for exactly these situations. IE. accurate floating-point/decimal math.

Considering that you're using VS10, you don't even have extensive access to C11. To be fair though, C++ is reaching that point in it's lifespan where it's becoming archaic.

I'm not sure where or how you're conjuring the idea that I'm using VS10. I use VS12 and 13.

Whoops, my bad, I was looking at the wrong post

Edited by GutenTag

##### Share on other sites

This topic is 830 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.