Numerical overflow

[Parachute]

Using Borland Builder 6, I get numerical overflow when running a small
programme without CodeGuard ("exp: OVERFLOW error"). The programme does
not give any error messages when CodeGuard is activated during the run.
The equation that causes overflow uses the exp-function, but given and
resulting values are not very large (and are written in
double-variables anyway). So why does it seem as if there were not
enough space in the buffer? And why doesn't the problem occur, when the
same programme is run with an activated CodeGuard?

The equation looks like this (except int delta_t: all variables
double):
new_amount = old_amount * ( 1 - ( A * exp(K1* delta_t) + (1-A) *
exp(K2* delta_t) ) );

 

[Victor Bazarov]

Using Borland Builder 6, I get numerical overflow when running a small
programme without CodeGuard ("exp: OVERFLOW error"). The programme
does not give any error messages when CodeGuard is activated during
the run. The equation that causes overflow uses the exp-function, but
given and resulting values are not very large (and are written in
double-variables anyway). So why does it seem as if there were not
enough space in the buffer? And why doesn't the problem occur, when
the same programme is run with an activated CodeGuard?

I have no idea what "CodeGuard" is, and Borland-specific discussion is
off-topic here, but if the behaviour is particular to some compiler and
changes while your program is run under a tool, it can mean two things:
either your program has *undefined behaviour* or the tools are to blame.
The former case can be exposes if we know the code and the data, and the
latter can be cleared up with the makers of the tools.

The equation looks like this (except int delta_t: all variables
double):
new_amount = old_amount * ( 1 - ( A * exp(K1* delta_t) + (1-A) *
exp(K2* delta_t) ) );

And how are we supposed to know if this is going to overflow without
knowing the _values_ of the variables?

V

 

[Frederick Gotham]

Parachute posted:

new_amount = old_amount * ( 1 - ( A * exp(K1* delta_t) + (1-A) *
exp(K2* delta_t) ) );

You'd be far more likely to get a more satisfactory response over on
comp.lang.c

 

[Howard]

Parachute posted:



You'd be far more likely to get a more satisfactory response over on
comp.lang.c

Eh? What about that assignment statement is C, as opposed to C++?

But he would get a better response if he posted the data types of those
variables, and their values on entry to that line of code.

-Howard

 

[Frederick Gotham]

Howard posted:

Eh? What about that assignment statement is C, as opposed to C++?

If you ask about basic language functionality on comp.lang.c++, you get few
responses.

If you ask about basic language functionality on comp.lang.c, you get many
responses.

The question being asked is also a valid C question, so it may be worthwhile
to ask it on a C group.

 

[Howard]

Howard posted:



If you ask about basic language functionality on comp.lang.c++, you get
few
responses.

If you ask about basic language functionality on comp.lang.c, you get many
responses.

The question being asked is also a valid C question, so it may be
worthwhile
to ask it on a C group.

Hmmm, I've never noticed a lack of responses to "basic language
functionality" questions here.

(Besides, how many _correct_ responses do you need? )

-H

 

[Jim Langston]

Using Borland Builder 6, I get numerical overflow when running a small
programme without CodeGuard ("exp: OVERFLOW error"). The programme does
not give any error messages when CodeGuard is activated during the run.
The equation that causes overflow uses the exp-function, but given and
resulting values are not very large (and are written in
double-variables anyway). So why does it seem as if there were not
enough space in the buffer? And why doesn't the problem occur, when the
same programme is run with an activated CodeGuard?

The equation looks like this (except int delta_t: all variables
double):
new_amount = old_amount * ( 1 - ( A * exp(K1* delta_t) + (1-A) *
exp(K2* delta_t) ) );

This is just a suggestion, but try changing the constant 1 to 1.0

1 is an int. 1.0 is a double. 1.0f is a float.

It might be because you have an int in there it's doing integer math
somewhere, which would give you your overflow. Try it and see. It's hard
for me to understand when the compilers default to integer math and when
they use floating point math with an integer variable. There are rules but
I can't remember them.

 

[Parachute]

The problem is not caused by data types: it also occurs when all
variables are float or double.
The values of the parameters are:
A: between 0 and 0.6
K1: between -10^(-1) and -10^(-4)
K2: between -3 and -10(-5)
delta_t: 1 to possibly several hundred, but the programme never reaches
the point where large values of delta_t would occur.

Overflow occurs over the whole range of parameter values. The error
message can be clicked away, the programme will then continue. But
since the equation is written within a loop, the error will come back
repeatedly, finally causing the programme to crash.

 

[Pete Becker]

It might be because you have an int in there it's doing integer math
somewhere, which would give you your overflow. Try it and see. It's hard
for me to understand when the compilers default to integer math and when
they use floating point math with an integer variable. There are rules but
I can't remember them.

When the type of one of the arguments to a binary operator is a double,
its other argument is promoted to double. That int isn't the problem.

 

[Howard]

[Please don't top-post. Responses belong at the end of, or interspersed
with, the comments you're replying to. I've re-arranged your reply. See
below.]

The problem is not caused by data types: it also occurs when all
variables are float or double.
The values of the parameters are:
A: between 0 and 0.6
K1: between -10^(-1) and -10^(-4)
K2: between -3 and -10(-5)
delta_t: 1 to possibly several hundred, but the programme never reaches
the point where large values of delta_t would occur.

Overflow occurs over the whole range of parameter values. The error
message can be clicked away, the programme will then continue. But
since the equation is written within a loop, the error will come back
repeatedly, finally causing the programme to crash.

Can you give us an example of a _specific_ set of values which causes the
error? Use your debugger or an output statement and capture the values. We
can't simply guess at values and try to cause an error on our end. Also,
what are the data types for each of those variables? You still haven't
answered that question.

One suggestion for figuring this out on your own: break the calculations
apart into separate variables, one for each sub-expression, and check the
values of each of those sub-expressions. Like this:

double t0 = K1 * delta_t;
double t1 = K2 * delta_t;
double t2 = exp( t0 );
double t3 = exp( t1 );
double t4 = A * t2;
double t5 = 1 - A;
double t6 = t5 * t3;
double t7 = t4 + t6;
double t8 = 1 - t7;
new_amount = old_amount * t8;

-Howard

 

[Parachute]

[Please don't top-post. Responses belong at the end of, or interspersed
with, the comments you're replying to. I've re-arranged your reply. See
below.]

The problem is not caused by data types: it also occurs when all
variables are float or double.
The values of the parameters are:
A: between 0 and 0.6
K1: between -10^(-1) and -10^(-4)
K2: between -3 and -10(-5)
delta_t: 1 to possibly several hundred, but the programme never reaches
the point where large values of delta_t would occur.

Overflow occurs over the whole range of parameter values. The error
message can be clicked away, the programme will then continue. But
since the equation is written within a loop, the error will come back
repeatedly, finally causing the programme to crash.

Can you give us an example of a _specific_ set of values which causes the
error? Use your debugger or an output statement and capture the values. We
can't simply guess at values and try to cause an error on our end. Also,
what are the data types for each of those variables? You still haven't
answered that question.

One suggestion for figuring this out on your own: break the calculations
apart into separate variables, one for each sub-expression, and check the
values of each of those sub-expressions. Like this:

double t0 = K1 * delta_t;
double t1 = K2 * delta_t;
double t2 = exp( t0 );
double t3 = exp( t1 );
double t4 = A * t2;
double t5 = 1 - A;
double t6 = t5 * t3;
double t7 = t4 + t6;
double t8 = 1 - t7;
new_amount = old_amount * t8;

Many thanks for you helping me (in spite of my unprofessionell posting
;-) !

Following your proposal, I've found the mistake: it lay in the
time-variable, which regularly
took very strange values due to an incorrect use of dynamic memory
allocation before assigning the new time-value to the variable. So, the
root of the problem lay quite far away from its emergence...

Thanks again!
Heidrun