Help please, strange behavior

[Simply_Red]

i'm sorry i posted this in other groupes, and i didn't see it, and as
this group is most actif, i repost it here, and sorry for
mutliposting:

Hi,
i'm using VC6, i have this declaration:

typedef struct tagTLimite {
double Debut;
double Fin;
}Limites;

typedef struct TagElemTab {
double NivY;
bool Existe;
std::vector<Lim itesPtLimites;
}ElemTabCont;

void myfunc( )
{
......
ElemTabCont * ContNonOrd;//contour non ordone
long nbNiveau = (yhi-ylo)/stepY +1 ;
ContNonOrd = new ElemTabCont [nbNiveau];
......
}
i don't know why,nbNiveau is equal to (yhi-ylo)/stepY, it didn't
+1????and even if i put:
ContNonOrd = new ElemTabCont [nbNiveau+1]; the size of ContNonOrd =
nbNiveau????

[Howard]

"Simply_Red " <Si**********@g mail.comwrote in message
news:11******** **************@ s48g2000cws.goo glegroups.com.. .

typedef struct tagTLimite {
double Debut;
double Fin;
}Limites;

typedef struct TagElemTab {
double NivY;
bool Existe;
std::vector<Lim itesPtLimites;
}ElemTabCont;

void myfunc( )
{
.....
ElemTabCont * ContNonOrd;//contour non ordone
long nbNiveau = (yhi-ylo)/stepY +1 ;

>What is the type of 'yhi', 'ylo', 'stepY'? What are their values?
What value do you get in 'nbNiveau'? What did you expect

yhi, ylo, stepY are doubles values: 16, 0, 0.1 respectively
I get 160 in nbNiveau, and I need 161.

double isn't precise either. Note that 0.1 in binary is a periodic number
that cannot be represented exactly. So instead of 0.1, you get the
closest
representabl e value. As a result, you might get something like
160.9999999999 8, which gets truncated to 160 when converted to long.

but if 160.999999998 is truncated to 160, 159.99999998 must be
truncated to 159.....

True, but where did you get 159.99999998?

The problem is that, sometimes, the result of (yhi-ylo)/stepY will not be an
exact integer, because stepY may not be exactly representable in binary (as
a double or float). So sometimes your array size will be too small.

The solution for handling this depends on your goal. How are you later
using the array elements?

In your example, stepY is 0.1, or 1/10, which means you're expecting to get
(yhi-ylo)*10 = 160, right? Well, where does stepY come from? Can you
compute it from something like 1/numElementsPerU nit, where
numElementsPerU nit is an integer? If so, your code could change to:

nbNiveau = (yhi-ylo)*numElement sPerUnit + 1;
stepY = 1 / numElementsPerU nit;

That would avoid the issue entirely.

If stepY is not representable that way, and if yhi-ylo isn't too big, you
could just add 1.1 instead of 1 before truncating to an integer, but that's
not the prefered solution.

Victor's idea of "bumping up" the value might work for you, as well, if all
you care about is having "enough" elements in the array.

One thing to note: If you ever make calculations like (i-ylo)/stepY, or
simply i*stepY, then for large values of i the result will get further and
further from what you expect. But that's probably not be a problem for you,
since your values are small.

By the way, one thing I like to do when investigating problems involving
calculations like this is to store intermediate results to another variable,
like this:

double temp = (yhi-ylo)/stepY +1;
long nbNiveau = temp;

This lets you examine the values yourself when debugging, instead of trying
to guess what's going on inside the program.

Hope this helps...

-Howard

[Simply_Red]

On 15 fév, 16:33, "Howard" <[e-mail] rote:

"Simply_Red " <Simply.Re...@g mail.comwrote in message

news:11******** **************@ s48g2000cws.goo glegroups.com.. .

typedef struct tagTLimite {
double Debut;
double Fin;
}Limites;

typedef struct TagElemTab {
double NivY;
bool Existe;
std::vector<Lim itesPtLimites;
}ElemTabCont;

void myfunc( )
{
.....
ElemTabCont * ContNonOrd;//contour non ordone
long nbNiveau = (yhi-ylo)/stepY +1 ;

What is the type of 'yhi', 'ylo', 'stepY'? What are their values?
What value do you get in 'nbNiveau'? What did you expect

yhi, ylo, stepY are doubles values: 16, 0, 0.1 respectively
I get 160 in nbNiveau, and I need 161.

double isn't precise either. Note that 0.1 in binary is a periodic number
that cannot be represented exactly. So instead of 0.1, you get the
closest
representable value. As a result, you might get something like
160.99999999998 , which gets truncated to 160 when converted to long.

but if 160.999999998 is truncated to 160, 159.99999998 must be
truncated to 159.....

True, but where did you get 159.99999998?

The problem is that, sometimes, the result of (yhi-ylo)/stepY will not bean
exact integer, because stepY may not be exactly representable in binary (as
a double or float). So sometimes your array size will be too small.

The solution for handling this depends on your goal. How are you later
using the array elements?

In your example, stepY is 0.1, or 1/10, which means you're expecting to get
(yhi-ylo)*10 = 160, right? Well, where does stepY come from? Can you
compute it from something like 1/numElementsPerU nit, where

I take the value of stepY from a database, i can't compute it.

numElementsPerU nit is an integer? If so, your code could change to:

nbNiveau = (yhi-ylo)*numElement sPerUnit + 1;
stepY = 1 / numElementsPerU nit;

That would avoid the issue entirely.

If stepY is not representable that way, and if yhi-ylo isn't too big, you
could just add 1.1 instead of 1 before truncating to an integer, but that's
not the prefered solution.

Victor's idea of "bumping up" the value might work for you, as well, if all
you care about is having "enough" elements in the array.

One thing to note: If you ever make calculations like (i-ylo)/stepY, or
simply i*stepY, then for large values of i the result will get further and
further from what you expect. But that's probably not be a problem for you,
since your values are small.

By the way, one thing I like to do when investigating problems involving
calculations like this is to store intermediate results to another variable,
like this:

double temp = (yhi-ylo)/stepY +1;
long nbNiveau = temp;

This lets you examine the values yourself when debugging, instead of trying
to guess what's going on inside the program.

Hope this helps...

-Howard

thank you for your help.