Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | jt@toerring.de (Jens Thoms Toerring) |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: C program. run time abend, range fault. |
| Date | 2014-12-16 23:08 +0000 |
| Organization | Freie Universitaet Berlin |
| Message-ID | <cfbsbnFmha3U1@mid.uni-berlin.de> (permalink) |
| References | <3636bf65-fa27-43a6-b54f-45477b249b5d@googlegroups.com> <cfag0nF9r44U1@mid.uni-berlin.de> <079d80e9-04b3-4ea4-958a-72033e2c46e0@googlegroups.com> |
Shiva <subramanian.klu@gmail.com> wrote:
> Hi Jens,
> Thanks for your response. Really sorry about the code. I posted an earlier
> version. Really sorry, my bad.
Nothing to be sorry about;-)
> I've had corrected these and added the variables as globals.
Now you have global variables and variables of the same names
as function argument names, which become local variables in
these functions, hiding the global variables. That, unfortu-
nately, doesn't solve the problem. If you do someting like
int a = 13; // global variable
void foo( a ) {
a = 42;
}
all you achive is creating two variables, one global named 'a'
and another one with the same name, only existing in foo().
And this local variable in foo() hides the global one in foo().
So, you either have to do everything via global variables (not
something I personally would recommend, but there can be situa-
tions where there's no better solution) or use the function
arguments how it's properly done in C/
> And I've had
> also passed the returns from functions into variables. Below is the
> corrected code (from memory)
It tends to be better to post the exact code...
> point me if it is wrong, but I got the
> functionality of fortran code replicated into the C code, of which I'm sure.
> Can you please answer the original question now that I got the right code?
> long long int pA, pB, pC, pD, pF, pN;
> double z, A;
> long long int funcA (long long int, long long int, long long int, long long int, long long int, long long int)
This obviously is either from memory, but incorrect (because
you need to give names to the variables in C) or you're using
a C++ compiler (in C++ it's, in contrast to C, allowed to
leave out the names for arguments not used in the function).
And where do these global variables get set? I have trouble
understanding what happens here. One guess is that there's some
other function calling funcA(), setting them up and then calling
funcA(). That might work. modulo the missing argument names, but
that's missing from you code. And you also mention something
about funcA() called from Cobol. Call me puzzled...
> {
> ... Initialisation...
> z = funcB (A, pF, pN, pD, pC, pB, pA, z);
> ...initialisations value assigning to other variables...A
> z = funcB (A, pF, pN, pD, pC, pB, pA, z);
> do
> {
> A = funcC (A, pF, pN, pD, pC, pB, pA, v, w, x, y, z);
> count = count + 1;
> } while (((z >= 0.0001) || (z <= 0.0001)) && count < limit);
> if ( count = limit)
> A = -1;
> else
> {
> ... Some more math..
> }
> return A;
> }
> double funcB (double A, int pF, int pN, int pD, double pC, double pB, double pA, double z)
> {
> z = (pow (A, pF) * (A - 1)) / (1 - (pow (A, -pN)));
> z = pB / z;
> z = z - pA - (pC / pow (A, pD));
> return (z);
> }
> double funcC (double A, int pF, int pN, int pD, int pC, double pB, double pa, double v, double w, double x, double y, double z)
> {
> A = some math...
> z = calcz (A, pF, pN, pD, PC, pB, pA, z);
> Some more math...
> return (A);
> }
> If you see the error that I have listed above - it says that the range fault
> occurs in funcB (I have debugged to the point that it is actually line one
> of funcB) It is trying to calculate the value for (1/10 ^ 72) or something
> like that. Can get you the exact value if you'd like. That's where it gives
> the range fault.
> So as I mentioned it happens in line 1 of funcB when it is called by funcC,
> which is called by funcA which is called by some other COBOL program.
> Just want to catch this run time error. Not sure what you mean by libraries.
> I use STDIO.H, STDLIB.H and MATH.H nothing else. And the compiler I use is
> C89 version for Tandem HP NS product.
Never used that (which might explain my unfamilarity with the
wording of the error message you got). My only guess at the
moment is that with (1/10^72) a floating point exception is
raised (assuming that it comes from one of the pow() calls)
because the result would underflow on your machine. The name
"Tandem" evokes memories of old times and all Google searches
with "Tandem HP NS" come up with some machines from nearky
40 years ago;-) - is this perhaps some machine with 32-bit
floating point numbers? In that case (as- suming IEEE-754
floating point representation) the range for floating point
numbers is in that case is somewhere 10^38 and 10^-38. Thus
(1/10^72) would underflow. That's still within the requirements
by C89 - the smallest double don't have to be smaller than
10^-37.
I'd try to simply print out the value of the nacro DBL_MIN from
<limits.h> to check if this what's going on your machine.
If that's the case the obvious question is how to avoid the
problem. Unfortunately, the C89 standard only says about the
pow() function that "A range error may occur.". It's not speci-
fied what exact effects that may have. It's not unheard of that
for underflows a floating-point exception (FE_UNDERFLOW) is
raised. That can depend, as far as I know, on settings for
the programs not defined in the C89 standard (C99 added some
support for this). My guess is that your best bet is to trya
avoiding calling pow() with values that might under/overflow
if possible. Or try to find out how to disable that such floa-
ting point exceptions get raised, kiling your program, under
these circumstances on your system (returning just 0 as the
result) - but that's something I definitely can't help with,
knowing nothing about that system, sorry.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
C program. run time abend, range fault. Shiva <subramanian.klu@gmail.com> - 2014-12-16 00:47 -0800
Re: C program. run time abend, range fault. jt@toerring.de (Jens Thoms Toerring) - 2014-12-16 10:31 +0000
Re: C program. run time abend, range fault. Shiva <subramanian.klu@gmail.com> - 2014-12-16 11:33 -0800
Re: C program. run time abend, range fault. Barry Schwarz <schwarzb@dqel.com> - 2014-12-16 14:27 -0800
Re: C program. run time abend, range fault. jt@toerring.de (Jens Thoms Toerring) - 2014-12-16 23:08 +0000
Re: C program. run time abend, range fault. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-16 23:44 +0000
Re: C program. run time abend, range fault. glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-16 19:37 +0000
Re: C program. run time abend, range fault. jt@toerring.de (Jens Thoms Toerring) - 2014-12-17 00:12 +0000
Re: C program. run time abend, range fault. Shiva <subramanian.klu@gmail.com> - 2014-12-17 13:05 -0800
Re: C program. run time abend, range fault. Barry Schwarz <schwarzb@dqel.com> - 2014-12-17 15:06 -0800
Re: C program. run time abend, range fault. Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 23:15 +0000
Re: C program. run time abend, range fault. Keith Thompson <kst-u@mib.org> - 2014-12-17 16:00 -0800
Re: C program. run time abend, range fault. Keith Thompson <kst-u@mib.org> - 2014-12-17 15:56 -0800
Re: C program. run time abend, range fault. Shiva <subramanian.klu@gmail.com> - 2014-12-18 12:28 -0800
Re: C program. run time abend, range fault. Barry Schwarz <schwarzb@dqel.com> - 2014-12-18 14:07 -0800
Re: C program. run time abend, range fault. Barry Schwarz <schwarzb@dqel.com> - 2014-12-18 14:16 -0800
Re: C program. run time abend, range fault. jacob navia <jacob@spamsink.net> - 2014-12-19 00:55 +0100
Re: C program. run time abend, range fault. jt@toerring.de (Jens Thoms Toerring) - 2014-12-19 00:18 +0000
Re: C program. run time abend, range fault. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 01:12 +0000
Re: C program. run time abend, range fault. jt@toerring.de (Jens Thoms Toerring) - 2014-12-18 01:00 +0000
Re: C program. run time abend, range fault. James Kuyper <jameskuyper@verizon.net> - 2014-12-17 22:29 -0500
Re: C program. run time abend, range fault. gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-18 09:18 +0000
Re: C program. run time abend, range fault. Martin Shobe <martin.shobe@yahoo.com> - 2014-12-18 11:10 -0600
Re: C program. run time abend, range fault. Shiva <subramanian.klu@gmail.com> - 2014-12-18 11:38 -0800
Re: C program. run time abend, range fault. James Kuyper <jameskuyper@verizon.net> - 2014-12-18 15:24 -0500
Re: C program. run time abend, range fault. Shiva <subramanian.klu@gmail.com> - 2014-12-18 12:37 -0800
C program. run time abend, range fault. asetofsymbols@gmail.com - 2014-12-18 22:21 -0800
Re: C program. run time abend, range fault. Is this the correct solution? jacob navia <jacob@spamsink.net> - 2014-12-19 18:32 +0100
Re: C program. run time abend, range fault. Is this the correct solution? jacob navia <jacob@spamsink.net> - 2014-12-20 11:34 +0100
Re: C program. run time abend, range fault. Is this the correct solution? Shiva <subramanian.klu@gmail.com> - 2014-12-31 11:48 -0800
Re: C program. run time abend, range fault. Is this the correct solution? James Kuyper <jameskuyper@verizon.net> - 2014-12-31 15:49 -0500
Re: C program. run time abend, range fault. Is this the correct solution? Keith Thompson <kst-u@mib.org> - 2014-12-31 13:07 -0800
Re: C program. run time abend, range fault. Is this the correct solution? Geoff <geoff@invalid.invalid> - 2014-12-31 13:57 -0800
Re: C program. run time abend, range fault. Is this the correct solution? Keith Thompson <kst-u@mib.org> - 2014-12-31 16:02 -0800
Re: C program. run time abend, range fault. Is this the correct solution? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-31 22:55 -0800
Re: C program. run time abend, range fault. Is this the correct solution? raltbos@xs4all.nl (Richard Bos) - 2015-01-05 14:56 +0000
Re: C program. run time abend, range fault. Is this the correct solution? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-31 21:51 +0000
Re: C program. run time abend, range fault. Is this the correct solution? jacob navia <jacob@spamsink.net> - 2015-01-01 02:51 +0100
Re: C program. run time abend, range fault. Is this the correct solution? raltbos@xs4all.nl (Richard Bos) - 2015-01-05 15:00 +0000
Re: C program. run time abend, range fault. Is this the correct solution? Shiva <subramanian.klu@gmail.com> - 2015-01-05 09:45 -0800
Re: C program. run time abend, range fault. Is this the correct solution? Geoff <geoff@invalid.invalid> - 2015-01-05 11:02 -0800
Re: C program. run time abend, range fault. Is this the correct solution? Shiva <subramanian.klu@gmail.com> - 2015-01-06 10:33 -0800
Re: C program. run time abend, range fault. Is this the correct solution? James Kuyper <jameskuyper@verizon.net> - 2015-01-06 14:09 -0500
Re: C program. run time abend, range fault. Is this the correct solution? Shiva <subramanian.klu@gmail.com> - 2015-01-06 12:32 -0800
Re: C program. run time abend, range fault. Is this the correct solution? James Kuyper <jameskuyper@verizon.net> - 2015-01-06 15:47 -0500
Re: C program. run time abend, range fault. Is this the correct solution? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-01-06 23:58 +0000
Re: C program. run time abend, range fault. Is this the correct solution? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-07 04:31 +0000
Re: C program. run time abend, range fault. Is this the correct solution? Robert Wessel <robertwessel2@yahoo.com> - 2015-01-06 23:36 -0600
Re: C program. run time abend, range fault. Is this the correct solution? Richard Heathfield <invalid@see.sig.invalid> - 2015-01-07 07:08 +0000
Re: C program. run time abend, range fault. Is this the correct solution? Shiva <subramanian.klu@gmail.com> - 2015-01-09 13:46 -0800
Re: C program. run time abend, range fault. Is this the correct solution? Geoff <geoff@invalid.invalid> - 2015-01-05 09:56 -0800
Re: C program. run time abend, range fault. Geoff <geoff@invalid.invalid> - 2015-01-01 14:38 -0800
csiph-web