Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #54647 > unrolled thread

C program. run time abend, range fault.

Back to article view | Back to comp.lang.c

Contents

  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

Page 3 of 3 — ← Prev page 1 2 [3]

#55930 — Re: C program. run time abend, range fault. Is this the correct solution?

On Mon, 5 Jan 2015 09:45:27 -0800 (PST), Shiva
<subramanian.klu@gmail.com> wrote:

>And about the concern raised by Geoff, the code is right - not just because it gives the correct value for the 'good' input. It also gives the correct answer for the 'bad' input. But just could not handle the 'overflow' that's happening at that iteration - except for that the outputs match. Regression testing was done. And it works. For these really bad inputs though it does not work, and I understand your argument that it could be a case of still where FORTRAN is not exactly replicated in C because even for one input if the program doesn't work exactly like FORTRAN it could mean that they are not the same - of course the compiler is different, and I think that's where the issue resides. Because the fortan object resets the variable value everytime it reaches the peak (or overflow as we say) and the value becomes zero again and is retried so the limit count 100 is hit and the answer is -1 for A in the code above. Again this is just my understanding and I could be wrong, but we need
>Fortran pundits to answer that. As far as I know, the FORTRAN code is mimicked clearly into this C code. There was every effort on that front.

I'll take your word on that. As far as differences in compiler or
runtime are concerned, you might be correct but that means your code
exhibits undefined behavior. 

I can't duplicate your -1 result, unless -1000 is that result. But
then I think I see a bug in your code.

Taking the code you posted here:
Message-ID: <ea8bbea1-0471-4243-bb70-205ca6522d4c@googlegroups.com>

I never get -1 returned. In funcA where you wrote:
...
	if ( count == limit)
		A = -1;
	else
	{
		A = (pow (A, 12) - 1) * 100;
		A = (double) ((long long int) (( A + 0.005) * 100 )) / 100;
	}

	A = A * 1000;
	r = (long int) A;

	return (r);
}

When (count == limit) it's never going to return -1. It's going to
return -1 * 1000 and your comments that it returns -1 "as expected" is
therefore confusing.

Did you mean to return -1 or -1000? If the former then:

	if (count == limit)
		return -1;
	else
 	....

Attempting to duplicate your results I coded the following test:

int main (void)
{
	long int l1, l2, l3, l4, l5, l6;
	long int res = 0;

	l1 = 1000;
	l2 = 44.50;
	l3 = 25;
	l4 = 0;
	l5 = 2;
	l6 = 2;
	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6));
	assert(res == -1000);  // expect -1?

	l1 = 1000000;
	l2 = 25000;
	l3 = 0;
	l4 = 0;
	l5 = 0;
	l6 = 60;
	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6));
	assert(res == 18710); // expect 18710

	l1 = 1000;
	l2 = 144.50;
	l3 = 25;
	l4 = 0;
	l5 = 2;
	l6 = 2;
	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6));
	assert(res == -1000); // expect -1?

	l1 = 1759672; 
	l2 = 23306; 
	l3 = 0; 
	l4 = 0; 
	l5 = 0; 
	l6 = 60; 
	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6)); 
	assert(res == -1000); // expect -1?

	l1 = 200000; 
	l2 = 7345; 
	l3 = 0; 
	l4 = 0; 
	l5 = 0; 
	l6 = 12; 
	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6)); 
	assert(res == -1000); // abend?
}

I don't know what data is expected to fault so I set the assertions to
the results I got in my environment. At no time did the program
overflow. I'd appreciate it if you could clarify these points and tell
me what the expected results are for these data sets.

[toc] | [prev] | [next] | [standalone]

#55989 — Re: C program. run time abend, range fault. Is this the correct solution?

> I'll take your word on that. As far as differences in compiler or
> runtime are concerned, you might be correct but that means your code
> exhibits undefined behavior. 
> 
> I can't duplicate your -1 result, unless -1000 is that result. But
> then I think I see a bug in your code.
>

Ah gosh! It is -1000 not -1. Sorry for the millionth time. :(
 
> Taking the code you posted here:
> Message-ID: <ea8bbea1-0471-4243-bb70-205ca6522d4c@googlegroups.com>
> 
> I never get -1 returned. In funcA where you wrote:
> ...
> 	if ( count == limit)
> 		A = -1;
> 	else
> 	{
> 		A = (pow (A, 12) - 1) * 100;
> 		A = (double) ((long long int) (( A + 0.005) * 100 )) / 100;
> 	}
> 
> 	A = A * 1000;
> 	r = (long int) A;
> 
> 	return (r);
> }
> 
> When (count == limit) it's never going to return -1. It's going to
> return -1 * 1000 and your comments that it returns -1 "as expected" is
> therefore confusing.
> 
> Did you mean to return -1 or -1000? If the former then:
> 
> 	if (count == limit)
> 		return -1;
> 	else
>  	....
> 
> Attempting to duplicate your results I coded the following test:
> 
> int main (void)
> {
> 	long int l1, l2, l3, l4, l5, l6;
> 	long int res = 0;
> 
> 	l1 = 1000;
> 	l2 = 44.50;
> 	l3 = 25;
> 	l4 = 0;
> 	l5 = 2;
> 	l6 = 2;
> 	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6));
> 	assert(res == -1000);  // expect -1?

Sorry about these double type inputs. There will never be such inputs. I didn't use them in the last time I wrote about the three kinds of inputs. 

> 
> 	l1 = 1000000;
> 	l2 = 25000;
> 	l3 = 0;
> 	l4 = 0;
> 	l5 = 0;
> 	l6 = 60;
> 	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6));
> 	assert(res == 18710); // expect 18710
> 

This one's good. 

> 	l1 = 1000;
> 	l2 = 144.50;
> 	l3 = 25;
> 	l4 = 0;
> 	l5 = 2;
> 	l6 = 2;
> 	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6));
> 	assert(res == -1000); // expect -1?
> 

Again no decimal point/ floating point / double kind of inputs.

> 	l1 = 1759672; 
> 	l2 = 23306; 
> 	l3 = 0; 
> 	l4 = 0; 
> 	l5 = 0; 
> 	l6 = 60; 
> 	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6)); 
> 	assert(res == -1000); // expect -1?

-1000 perfect.

> 
> 	l1 = 200000; 
> 	l2 = 7345; 
> 	l3 = 0; 
> 	l4 = 0; 
> 	l5 = 0; 
> 	l6 = 12; 
> 	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6)); 
> 	assert(res == -1000); // abend?
> }

And here the code should have abended, did it not? That makes me think - may be the DBL_MAX or the highest double value is less in my C compiler - and not so in your compiler, because that's the only explanation that I can think of. 

Consider the following: 

Print the loop count.
Print the value for F1in funcB.
Check whether the value of F1 is 2.189569 e -77 in the 66th iteration. 
And let me know the value of F1 in 67th, to 70th iterations. That's where my code seem to fail because of the range fault.

So the only explanation that I thought - holds true. The fortran compiler had the extended range like your C compiler has, to produce values until the 100th iteration is reached, to set the value of A to -1, but essentially the C compiler that I'm using is not doing that pretty good.

Now I really know what I should be after. I should look exactly what's the limit - like people have suggested earlier, and then I should look for ways to bypass that. The system should have something for that definitely.

Thanks much, Geoff!
Have a nice day.

> 
> I don't know what data is expected to fault so I set the assertions to
> the results I got in my environment. At no time did the program
> overflow. I'd appreciate it if you could clarify these points and tell
> me what the expected results are for these data sets.

[toc] | [prev] | [next] | [standalone]

#55990 — Re: C program. run time abend, range fault. Is this the correct solution?

On 01/06/2015 01:33 PM, Shiva wrote:
...
> And here the code should have abended, did it not? That makes me
> think- may be the DBL_MAX or the highest double value is less in my C
> compiler - and not so in your compiler, because that's the only
> explanation that I can think of.

Since the behavior on overflow is undefined, "should have abended"
doesn't apply. It could, for instance, have continued after setting

On my system, DBL_MIN == 2.2250738585072014e-308 and DBL_MAX is
1.7976931348623157e+308, so there's no problem. However, a fully
conforming implemenation of C is allowed to have DBL_MIN as large as
1e-37 and DBL_MAX as small as 1e37, so in principle that could be the
problem - but I'd consider it rather odd. What hardware are you
compiling the code for?

> Consider the following: 
> 
> Print the loop count.
> Print the value for F1in funcB.
> Check whether the value of F1 is 2.189569 e -77 in the 66th iteration. 
> And let me know the value of F1 in 67th, to 70th iterations. That's where my code seem to fail because of the range fault.

You didn't indicate which calculation overflowed, so I made the
following modifications to help figure it out:

double A,v,w,x,y,z;
static double funcB (int pF, int pN, int pD, double pC, double pB,
double pA)
{
    double F1, F2;
    F1 = pow (A, -pN);
    printf("A:%g pN:%d F1:%g ", A, pN, F1);
    F2 = pow (A, pF);
    printf("pF:%d F2:%g ", pF, F2);
    z = ((F2 * (A - 1) ) / (1 - F1));
    printf("z1:%g ", z);
    z = pB/ z;
    printf("pB:%g z2:%g ", pB, z);
    z = z - pA - (pC/ pow (A, pD));
    printf("pA:%g pC:%g pD:%d z3:%g\n", pA, pC, pD, z);
    return (z);
}

With the following results:

> A:1 pN:12 F1:0.999999 pF:0 F2:1 z1:0.0833334 pB:73.45 z2:881.399 pA:2000 pC:0 pD:0 z3:-1118.6
> A:1.05 pN:12 F1:0.556837 pF:0 F2:1 z1:0.112825 pB:73.45 z2:651.006 pA:2000 pC:0 pD:0 z3:-1348.99
> A:1.24276 pN:12 F1:0.0736818 pF:0 F2:1 z1:0.262068 pB:73.45 z2:280.271 pA:2000 pC:0 pD:0 z3:-1719.73
> A:1.45173 pN:12 F1:0.011412 pF:0 F2:1 z1:0.456947 pB:73.45 z2:160.741 pA:2000 pC:0 pD:0 z3:-1839.26
> A:1.70118 pN:12 F1:0.0017022 pF:0 F2:1 z1:0.702371 pB:73.45 z2:104.574 pA:2000 pC:0 pD:0 z3:-1895.43
> A:2.00967 pN:12 F1:0.000230413 pF:0 F2:1 z1:1.0099 pB:73.45 z2:72.7299 pA:2000 pC:0 pD:0 z3:-1927.27
> A:2.39663 pN:12 F1:2.78471e-05 pF:0 F2:1 z1:1.39667 pB:73.45 z2:52.5893 pA:2000 pC:0 pD:0 z3:-1947.41
> A:2.88496 pN:12 F1:3.00829e-06 pF:0 F2:1 z1:1.88497 pB:73.45 z2:38.9662 pA:2000 pC:0 pD:0 z3:-1961.03
> A:3.50289 pN:12 F1:2.93008e-07 pF:0 F2:1 z1:2.50289 pB:73.45 z2:29.346 pA:2000 pC:0 pD:0 z3:-1970.65
> A:4.28587 pN:12 F1:2.60335e-08 pF:0 F2:1 z1:3.28587 pB:73.45 z2:22.3533 pA:2000 pC:0 pD:0 z3:-1977.65
> A:5.27867 pN:12 F1:2.13651e-09 pF:0 F2:1 z1:4.27867 pB:73.45 z2:17.1665 pA:2000 pC:0 pD:0 z3:-1982.83
> A:6.538 pN:12 F1:1.6393e-10 pF:0 F2:1 z1:5.538 pB:73.45 z2:13.2629 pA:2000 pC:0 pD:0 z3:-1986.74
> A:8.13576 pN:12 F1:1.18911e-11 pF:0 F2:1 z1:7.13576 pB:73.45 z2:10.2932 pA:2000 pC:0 pD:0 z3:-1989.71
> A:10.1631 pN:12 F1:8.23508e-13 pF:0 F2:1 z1:9.16313 pB:73.45 z2:8.01582 pA:2000 pC:0 pD:0 z3:-1991.98
> A:12.7358 pN:12 F1:5.49124e-14 pF:0 F2:1 z1:11.7358 pB:73.45 z2:6.25861 pA:2000 pC:0 pD:0 z3:-1993.74
> A:16.0007 pN:12 F1:3.55088e-15 pF:0 F2:1 z1:15.0007 pB:73.45 z2:4.89644 pA:2000 pC:0 pD:0 z3:-1995.1
> A:20.144 pN:12 F1:2.24001e-16 pF:0 F2:1 z1:19.144 pB:73.45 z2:3.83671 pA:2000 pC:0 pD:0 z3:-1996.16
> A:25.4022 pN:12 F1:1.38528e-17 pF:0 F2:1 z1:24.4022 pB:73.45 z2:3.00997 pA:2000 pC:0 pD:0 z3:-1996.99
> A:32.0755 pN:12 F1:8.43189e-19 pF:0 F2:1 z1:31.0755 pB:73.45 z2:2.3636 pA:2000 pC:0 pD:0 z3:-1997.64
> A:40.5445 pN:12 F1:5.06777e-20 pF:0 F2:1 z1:39.5445 pB:73.45 z2:1.8574 pA:2000 pC:0 pD:0 z3:-1998.14
> A:51.2926 pN:12 F1:3.01536e-21 pF:0 F2:1 z1:50.2926 pB:73.45 z2:1.46045 pA:2000 pC:0 pD:0 z3:-1998.54
> A:64.9333 pN:12 F1:1.77989e-22 pF:0 F2:1 z1:63.9333 pB:73.45 z2:1.14885 pA:2000 pC:0 pD:0 z3:-1998.85
> A:82.2448 pN:12 F1:1.04399e-23 pF:0 F2:1 z1:81.2448 pB:73.45 z2:0.904058 pA:2000 pC:0 pD:0 z3:-1999.1
> A:104.215 pN:12 F1:6.09294e-25 pF:0 F2:1 z1:103.215 pB:73.45 z2:0.71162 pA:2000 pC:0 pD:0 z3:-1999.29
> A:132.098 pN:12 F1:3.54191e-26 pF:0 F2:1 z1:131.098 pB:73.45 z2:0.560267 pA:2000 pC:0 pD:0 z3:-1999.44
> A:167.485 pN:12 F1:2.05253e-27 pF:0 F2:1 z1:166.485 pB:73.45 z2:0.441181 pA:2000 pC:0 pD:0 z3:-1999.56
> A:212.395 pN:12 F1:1.1865e-28 pF:0 F2:1 z1:211.395 pB:73.45 z2:0.347454 pA:2000 pC:0 pD:0 z3:-1999.65
> A:269.391 pN:12 F1:6.84539e-30 pF:0 F2:1 z1:268.391 pB:73.45 z2:0.273668 pA:2000 pC:0 pD:0 z3:-1999.73
> A:341.726 pN:12 F1:3.94331e-31 pF:0 F2:1 z1:340.726 pB:73.45 z2:0.215569 pA:2000 pC:0 pD:0 z3:-1999.78
> A:433.528 pN:12 F1:2.2688e-32 pF:0 F2:1 z1:432.528 pB:73.45 z2:0.169816 pA:2000 pC:0 pD:0 z3:-1999.83
> A:550.035 pN:12 F1:1.30412e-33 pF:0 F2:1 z1:549.035 pB:73.45 z2:0.13378 pA:2000 pC:0 pD:0 z3:-1999.87
> A:697.896 pN:12 F1:7.49048e-35 pF:0 F2:1 z1:696.896 pB:73.45 z2:0.105396 pA:2000 pC:0 pD:0 z3:-1999.89
> A:885.55 pN:12 F1:4.29975e-36 pF:0 F2:1 z1:884.55 pB:73.45 z2:0.0830366 pA:2000 pC:0 pD:0 z3:-1999.92
> A:1123.7 pN:12 F1:2.46702e-37 pF:0 F2:1 z1:1122.7 pB:73.45 z2:0.0654224 pA:2000 pC:0 pD:0 z3:-1999.93
> A:1425.95 pN:12 F1:1.41496e-38 pF:0 F2:1 z1:1424.95 pB:73.45 z2:0.0515456 pA:2000 pC:0 pD:0 z3:-1999.95
> A:1809.54 pN:12 F1:8.11309e-40 pF:0 F2:1 z1:1808.54 pB:73.45 z2:0.0406129 pA:2000 pC:0 pD:0 z3:-1999.96
> A:2296.36 pN:12 F1:4.65082e-41 pF:0 F2:1 z1:2295.36 pB:73.45 z2:0.0319994 pA:2000 pC:0 pD:0 z3:-1999.97
> A:2914.18 pN:12 F1:2.6656e-42 pF:0 F2:1 z1:2913.18 pB:73.45 z2:0.025213 pA:2000 pC:0 pD:0 z3:-1999.97
> A:3698.28 pN:12 F1:1.52756e-43 pF:0 F2:1 z1:3697.28 pB:73.45 z2:0.0198659 pA:2000 pC:0 pD:0 z3:-1999.98
> A:4693.4 pN:12 F1:8.75289e-45 pF:0 F2:1 z1:4692.4 pB:73.45 z2:0.015653 pA:2000 pC:0 pD:0 z3:-1999.98
> A:5956.32 pN:12 F1:5.01496e-46 pF:0 F2:1 z1:5955.32 pB:73.45 z2:0.0123335 pA:2000 pC:0 pD:0 z3:-1999.99
> A:7559.11 pN:12 F1:2.87311e-47 pF:0 F2:1 z1:7558.11 pB:73.45 z2:0.00971804 pA:2000 pC:0 pD:0 z3:-1999.99
> A:9593.24 pN:12 F1:1.64594e-48 pF:0 F2:1 z1:9592.24 pB:73.45 z2:0.00765723 pA:2000 pC:0 pD:0 z3:-1999.99
> A:12174.8 pN:12 F1:9.42881e-50 pF:0 F2:1 z1:12173.8 pB:73.45 z2:0.00603345 pA:2000 pC:0 pD:0 z3:-1999.99
> A:15451.1 pN:12 F1:5.40113e-51 pF:0 F2:1 z1:15450.1 pB:73.45 z2:0.00475401 pA:2000 pC:0 pD:0 z3:-2000
> A:19609.1 pN:12 F1:3.09386e-52 pF:0 F2:1 z1:19608.1 pB:73.45 z2:0.0037459 pA:2000 pC:0 pD:0 z3:-2000
> A:24886.1 pN:12 F1:1.77218e-53 pF:0 F2:1 z1:24885.1 pB:73.45 z2:0.00295156 pA:2000 pC:0 pD:0 z3:-2000
> A:31583.3 pN:12 F1:1.0151e-54 pF:0 F2:1 z1:31582.3 pB:73.45 z2:0.00232567 pA:2000 pC:0 pD:0 z3:-2000
> A:40082.8 pN:12 F1:5.81435e-56 pF:0 F2:1 z1:40081.8 pB:73.45 z2:0.0018325 pA:2000 pC:0 pD:0 z3:-2000
> A:50869.7 pN:12 F1:3.33036e-57 pF:0 F2:1 z1:50868.7 pB:73.45 z2:0.00144391 pA:2000 pC:0 pD:0 z3:-2000
> A:64559.5 pN:12 F1:1.90755e-58 pF:0 F2:1 z1:64558.5 pB:73.45 z2:0.00113773 pA:2000 pC:0 pD:0 z3:-2000
> A:81933.5 pN:12 F1:1.0926e-59 pF:0 F2:1 z1:81932.5 pB:73.45 z2:0.000896469 pA:2000 pC:0 pD:0 z3:-2000
> A:103983 pN:12 F1:6.25807e-61 pF:0 F2:1 z1:103982 pB:73.45 z2:0.000706371 pA:2000 pC:0 pD:0 z3:-2000
> A:131967 pN:12 F1:3.58443e-62 pF:0 F2:1 z1:131966 pB:73.45 z2:0.000556583 pA:2000 pC:0 pD:0 z3:-2000
> A:167482 pN:12 F1:2.05304e-63 pF:0 F2:1 z1:167481 pB:73.45 z2:0.000438558 pA:2000 pC:0 pD:0 z3:-2000
> A:212554 pN:12 F1:1.17591e-64 pF:0 F2:1 z1:212553 pB:73.45 z2:0.000345561 pA:2000 pC:0 pD:0 z3:-2000
> A:269756 pN:12 F1:6.7352e-66 pF:0 F2:1 z1:269755 pB:73.45 z2:0.000272284 pA:2000 pC:0 pD:0 z3:-2000
> A:342352 pN:12 F1:3.85767e-67 pF:0 F2:1 z1:342351 pB:73.45 z2:0.000214546 pA:2000 pC:0 pD:0 z3:-2000
> A:434485 pN:12 F1:2.20953e-68 pF:0 F2:1 z1:434484 pB:73.45 z2:0.000169051 pA:2000 pC:0 pD:0 z3:-2000
> A:551413 pN:12 F1:1.26554e-69 pF:0 F2:1 z1:551412 pB:73.45 z2:0.000133203 pA:2000 pC:0 pD:0 z3:-2000
> A:699809 pN:12 F1:7.2485e-71 pF:0 F2:1 z1:699808 pB:73.45 z2:0.000104957 pA:2000 pC:0 pD:0 z3:-2000
> A:888140 pN:12 F1:4.15166e-72 pF:0 F2:1 z1:888139 pB:73.45 z2:8.2701e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:1.12716e+06 pN:12 F1:2.37791e-73 pF:0 F2:1 z1:1.12715e+06 pB:73.45 z2:6.51641e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:1.43049e+06 pN:12 F1:1.36197e-74 pF:0 F2:1 z1:1.43049e+06 pB:73.45 z2:5.13459e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:1.81547e+06 pN:12 F1:7.80085e-76 pF:0 F2:1 z1:1.81547e+06 pB:73.45 z2:4.04579e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:2.30404e+06 pN:12 F1:4.46802e-77 pF:0 F2:1 z1:2.30404e+06 pB:73.45 z2:3.18788e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:2.9241e+06 pN:12 F1:2.5591e-78 pF:0 F2:1 z1:2.9241e+06 pB:73.45 z2:2.51188e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:3.71103e+06 pN:12 F1:1.46575e-79 pF:0 F2:1 z1:3.71103e+06 pB:73.45 z2:1.97923e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:4.70974e+06 pN:12 F1:8.39525e-81 pF:0 F2:1 z1:4.70974e+06 pB:73.45 z2:1.55953e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:5.97722e+06 pN:12 F1:4.80847e-82 pF:0 F2:1 z1:5.97722e+06 pB:73.45 z2:1.22883e-05 pA:2000 pC:0 pD:0 z3:-2000
> A:7.58581e+06 pN:12 F1:2.7541e-83 pF:0 F2:1 z1:7.5858e+06 pB:73.45 z2:9.68256e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:9.62729e+06 pN:12 F1:1.57744e-84 pF:0 F2:1 z1:9.62729e+06 pB:73.45 z2:7.62936e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:1.22182e+07 pN:12 F1:9.03494e-86 pF:0 F2:1 z1:1.22182e+07 pB:73.45 z2:6.01154e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:1.55063e+07 pN:12 F1:5.17485e-87 pF:0 F2:1 z1:1.55063e+07 pB:73.45 z2:4.73678e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:1.96794e+07 pN:12 F1:2.96395e-88 pF:0 F2:1 z1:1.96794e+07 pB:73.45 z2:3.73234e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:2.49754e+07 pN:12 F1:1.69763e-89 pF:0 F2:1 z1:2.49754e+07 pB:73.45 z2:2.94089e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:3.16968e+07 pN:12 F1:9.72336e-91 pF:0 F2:1 z1:3.16968e+07 pB:73.45 z2:2.31727e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:4.0227e+07 pN:12 F1:5.56915e-92 pF:0 F2:1 z1:4.0227e+07 pB:73.45 z2:1.82589e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:5.10528e+07 pN:12 F1:3.18979e-93 pF:0 F2:1 z1:5.10528e+07 pB:73.45 z2:1.43871e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:6.47921e+07 pN:12 F1:1.82698e-94 pF:0 F2:1 z1:6.47921e+07 pB:73.45 z2:1.13363e-06 pA:2000 pC:0 pD:0 z3:-2000
> A:8.22289e+07 pN:12 F1:1.04642e-95 pF:0 F2:1 z1:8.22289e+07 pB:73.45 z2:8.93238e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:1.04358e+08 pN:12 F1:5.99349e-97 pF:0 F2:1 z1:1.04358e+08 pB:73.45 z2:7.03826e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:1.32443e+08 pN:12 F1:3.43283e-98 pF:0 F2:1 z1:1.32443e+08 pB:73.45 z2:5.54578e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:1.68086e+08 pN:12 F1:1.96619e-99 pF:0 F2:1 z1:1.68086e+08 pB:73.45 z2:4.36979e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:2.13321e+08 pN:12 F1:1.12615e-100 pF:0 F2:1 z1:2.13321e+08 pB:73.45 z2:3.44317e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:2.7073e+08 pN:12 F1:6.45016e-102 pF:0 F2:1 z1:2.7073e+08 pB:73.45 z2:2.71304e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:3.43588e+08 pN:12 F1:3.6944e-103 pF:0 F2:1 z1:3.43588e+08 pB:73.45 z2:2.13773e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:4.36054e+08 pN:12 F1:2.116e-104 pF:0 F2:1 z1:4.36054e+08 pB:73.45 z2:1.68442e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:5.53404e+08 pN:12 F1:1.21196e-105 pF:0 F2:1 z1:5.53404e+08 pB:73.45 z2:1.32724e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:7.02336e+08 pN:12 F1:6.94163e-107 pF:0 F2:1 z1:7.02336e+08 pB:73.45 z2:1.0458e-07 pA:2000 pC:0 pD:0 z3:-2000
> A:8.91348e+08 pN:12 F1:3.97589e-108 pF:0 F2:1 z1:8.91348e+08 pB:73.45 z2:8.24033e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:1.13123e+09 pN:12 F1:2.27723e-109 pF:0 F2:1 z1:1.13123e+09 pB:73.45 z2:6.49295e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:1.43566e+09 pN:12 F1:1.30431e-110 pF:0 F2:1 z1:1.43566e+09 pB:73.45 z2:5.11611e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:1.82202e+09 pN:12 F1:7.47055e-112 pF:0 F2:1 z1:1.82202e+09 pB:73.45 z2:4.03123e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:2.31236e+09 pN:12 F1:4.27883e-113 pF:0 F2:1 z1:2.31236e+09 pB:73.45 z2:3.1764e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:2.93466e+09 pN:12 F1:2.45074e-114 pF:0 F2:1 z1:2.93466e+09 pB:73.45 z2:2.50284e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:3.72444e+09 pN:12 F1:1.40369e-115 pF:0 F2:1 z1:3.72444e+09 pB:73.45 z2:1.97211e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:4.72675e+09 pN:12 F1:8.03976e-117 pF:0 F2:1 z1:4.72675e+09 pB:73.45 z2:1.55392e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:5.99881e+09 pN:12 F1:4.60486e-118 pF:0 F2:1 z1:5.99881e+09 pB:73.45 z2:1.22441e-08 pA:2000 pC:0 pD:0 z3:-2000
> A:7.61321e+09 pN:12 F1:2.63748e-119 pF:0 F2:1 z1:7.61321e+09 pB:73.45 z2:9.64771e-09 pA:2000 pC:0 pD:0 z3:-2000
> A:9.66206e+09 pN:12 F1:1.51064e-120 pF:0 F2:1 z1:9.66206e+09 pB:73.45 z2:7.6019e-09 pA:2000 pC:0 pD:0 z3:-2000
> A:1.22623e+10 pN:12 F1:8.65235e-122 pF:0 F2:1 z1:1.22623e+10 pB:73.45 z2:5.9899e-09 pA:2000 pC:0 pD:0 z3:-2000

What do you get?

[toc] | [prev] | [next] | [standalone]

#55992 — Re: C program. run time abend, range fault. Is this the correct solution?

> Since the behavior on overflow is undefined, "should have abended"
> doesn't apply. It could, for instance, have continued after setting

I didn't quite catch this point.

> 
> On my system, DBL_MIN == 2.2250738585072014e-308 and DBL_MAX is
> 1.7976931348623157e+308, so there's no problem. However, a fully
> conforming implemenation of C is allowed to have DBL_MIN as large as
> 1e-37 and DBL_MAX as small as 1e37, so in principle that could be the
> problem - but I'd consider it rather odd. What hardware are you
> compiling the code for?

I think that exactly is the problem. The hardware that I'm compiling the code on - is HP NONSTOP TANDEM SYSTEMS. It's proprietary hardware. Pretty old as well, I'd bet my lottery on this being the issue.

> 
> > Consider the following: 
> > 
> > Print the loop count.
> > Print the value for F1in funcB.
> > Check whether the value of F1 is 2.189569 e -77 in the 66th iteration. 
> > And let me know the value of F1 in 67th, to 70th iterations. That's where my code seem to fail because of the range fault.
> 
> You didn't indicate which calculation overflowed, so I made the
> following modifications to help figure it out:
> 

The calculation of F1 overflowed. And thanks for your print statements, they're quite clear - just the loop count could've been more helpful, but no problem I can count too. :D

The following are your 66th and 67th iterations.

> A:2.30404e+06 pN:12 F1:4.46802e-77 pF:0 F2:1 z1:2.30404e+06 pB:73.45 z2:3.18788e-05 pA:2000 pC:0 pD:0 z3:-2000 
> A:2.9241e+06 pN:12 F1:2.5591e-78 pF:0 F2:1 z1:2.9241e+06 pB:73.45 z2:2.51188e-05 pA:2000 pC:0 pD:0 z3:-2000 

Though you did the same e-77 for your 66th iteration. My F1 value was 2.189569e-77 and yours 4.45802e-77. For the moment, I couldn't explain the difference in those values but they seem to be very much near. And the 67th iteration of F1 could not be processed due to a range fault, which much likely indicates that my DBL_MAX lies very close to e-77 or much before e-78, either way confirming that will help us zero in on the issue. Now I think some gentle man pointed out a way for me to figure out the DBL_MAX and DBL_MIN values in my system? I'll scroll up and look for the way and will come back with an answer tomorrow. Thanks a lot, guys. For letting me know that the issue was potentially with my system files having a lesser DBL_MAX than the ordinary situations like what you people are facing. (though that needs confirming)

[toc] | [prev] | [next] | [standalone]

#55996 — Re: C program. run time abend, range fault. Is this the correct solution?

On 01/06/2015 03:32 PM, Shiva wrote:
> 
>> Since the behavior on overflow is undefined, "should have abended"
>> doesn't apply. It could, for instance, have continued after setting
> 
> I didn't quite catch this point.

That's partly because it's subtle, but mostly because I forgot to finish
the sentence - sorry!

"It could, for instance, have continued calculations after setting the
result to any arbitrary convenient value, without abending. Another
option is that a signal might have been raised, and that you could
register a signal handler to deal with that signal."

The point is, "should have abended" makes an unjustified assumption
about what will happen when there's overflow. The best thing to do avoid
overflow, rather than relying upon unjustified assumptions about what
will happen when overflow occurs.

...
> The following are your 66th and 67th iterations.
> 
>> A:2.30404e+06 pN:12 F1:4.46802e-77 pF:0 F2:1 z1:2.30404e+06 pB:73.45 z2:3.18788e-05 pA:2000 pC:0 pD:0 z3:-2000 
>> A:2.9241e+06 pN:12 F1:2.5591e-78 pF:0 F2:1 z1:2.9241e+06 pB:73.45 z2:2.51188e-05 pA:2000 pC:0 pD:0 z3:-2000
> 
> Though you did the same e-77 for your 66th iteration. My F1 value was
> 2.189569e-77 and yours 4.45802e-77. For the moment, I couldn't
> explain the difference in those values but they seem to be very much
> near. ...

With A==2.30404e+06 pN==12, 4.46802e-77 is the correct value for F1,
that's easy to confirm by breaking it up into 2.30404^(-12)*1e6^(-12).
If you're getting anything else, that's a side-effect of running into
the limits of the capabilities of your floating point implementation.

> ... Now I think some gentle man pointed out
> a way for me to figure out the DBL_MAX and DBL_MIN values in my
> system?

#include <stdio.h>
#include <float.h>
int main(void)
{
    printf("DBL_MIN:%g DBL_MAX:%g\n", DBL_MIN, DBL_MAX);
    return 0;
}

[toc] | [prev] | [next] | [standalone]

#56003 — Re: C program. run time abend, range fault. Is this the correct solution?

Shiva <subramanian.klu@gmail.com> writes:
<snip>
>> 	l1 = 200000; 
>> 	l2 = 7345; 
>> 	l3 = 0; 
>> 	l4 = 0; 
>> 	l5 = 0; 
>> 	l6 = 12; 
>> 	printf("A value = %ld \n", res = funcA(l1, l2, l3, l4, l5, l6)); 
>> 	assert(res == -1000); // abend?
>> }
>
> And here the code should have abended, did it not? That makes me think
> - may be the DBL_MAX or the highest double value is less in my C
> compiler - and not so in your compiler, because that's the only
> explanation that I can think of.

The abend/no abend issue is not always a matter of the range.  On my
system here, floating point arithmetic won't ever "abend".  What's more,
the answer can come out right even if the arithmetic overflows.
However, what matters is your system and you can't really avoid finding
out the properties of its floating point arithmetic, and those of the
pow function you are using.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#56008 — Re: C program. run time abend, range fault. Is this the correct solution?

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Shiva <subramanian.klu@gmail.com> writes:

(snip)
>> And here the code should have abended, did it not? That makes me think
>> - may be the DBL_MAX or the highest double value is less in my C
>> compiler - and not so in your compiler, because that's the only
>> explanation that I can think of.

The only systems that I know of that have abend are IBM systems...
 
> The abend/no abend issue is not always a matter of the range.  On my
> system here, floating point arithmetic won't ever "abend".  What's more,
> the answer can come out right even if the arithmetic overflows.
> However, what matters is your system and you can't really avoid finding
> out the properties of its floating point arithmetic, and those of the
> pow function you are using.

The IBM systems that I know of that abend have a mask bit to 
indicate the desired effect in the case of decimal overflow, 
fixed point (binary) overflow, exponent (floating point) underflow,
and significance, but no bit for floating point overflow.

If you don't have a SPIE routine to process the overflow, and
many language libraries do that, you will get the appropriate abend.

For current machines, that could be for hexadecimal floating point,
binary (IEEE) floating point, or decimal (IEEE 754-2008) 
floating point.


-- glen

[toc] | [prev] | [next] | [standalone]

#56009 — Re: C program. run time abend, range fault. Is this the correct solution?

On Wed, 7 Jan 2015 04:31:33 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Shiva <subramanian.klu@gmail.com> writes:
>
>(snip)
>>> And here the code should have abended, did it not? That makes me think
>>> - may be the DBL_MAX or the highest double value is less in my C
>>> compiler - and not so in your compiler, because that's the only
>>> explanation that I can think of.
>
>The only systems that I know of that have abend are IBM systems...
> 
>> The abend/no abend issue is not always a matter of the range.  On my
>> system here, floating point arithmetic won't ever "abend".  What's more,
>> the answer can come out right even if the arithmetic overflows.
>> However, what matters is your system and you can't really avoid finding
>> out the properties of its floating point arithmetic, and those of the
>> pow function you are using.
>
>The IBM systems that I know of that abend have a mask bit to 
>indicate the desired effect in the case of decimal overflow, 
>fixed point (binary) overflow, exponent (floating point) underflow,
>and significance, but no bit for floating point overflow.


In practice, though, those interrupts are rarely enabled.

[toc] | [prev] | [next] | [standalone]

#56011 — Re: C program. run time abend, range fault. Is this the correct solution?

glen herrmannsfeldt wrote:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Shiva <subramanian.klu@gmail.com> writes:
> 
> (snip)
>>> And here the code should have abended, did it not? That makes me think
>>> - may be the DBL_MAX or the highest double value is less in my C
>>> compiler - and not so in your compiler, because that's the only
>>> explanation that I can think of.
> 
> The only systems that I know of that have abend are IBM systems...

IRTA "ICBM" systems.

In my defence, they definitely do abend. =:-O

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#56113 — Re: C program. run time abend, range fault. Is this the correct solution?

Hi everyone,

To cut to the chase,

DBL_MIN: 1.727723e-77
DBL_MAX: 1.15792e+77

And I could see that I had mentioned the F1 value before the abend wrongly. I just checked and it was a 1.737489e-77 (I don't know how it got beyond the DBL_MIN value, though even very little) at the 66th iteration. And at the 67th iteration it has failed. So clearly it is an issue of having a much limited range, for this range fault. 

Since you were able to get the -1000 answer for A, it means that if my DBL_MIN/DBL_MAX had the same range as yours, my program would've got the same answer as yours as well as the FORTRAN code's. That's a bit of a relief and a pain. The problems with working under a propriety software, I tell you, unimaginable. You don't know what you'd run into - next.

This from James, is a gem:

On my system, DBL_MIN == 2.2250738585072014e-308 and DBL_MAX is 
1.7976931348623157e+308, so there's no problem. However, a fully 
conforming implemenation of C is allowed to have DBL_MIN as large as 
1e-37 and DBL_MAX as small as 1e37, so in principle that could be the 
problem - but I'd consider it rather odd. What hardware are you 
compiling the code for? 

That's what made me give a real thought. I didn't really expect DBL range to be this low. I should've been more careful. Stupid me. But thanks a lot everyone for your valuable help and timely answers. You people helped me find the real issue behind this. The answer was there all along, and I knew - but the comparison with a run on the normal systems - gave a clear perspective. 

I've got various options at hand. The first one is to look at the specification manual more keenly for the C compiler in my environment (something I should have really done at the start before coding this up) sorry guys. Thanks a lot though for all your guidance. It was really helpful.

Again many thanks especially to Jen, Glen, Barry, Ben, Richard (both of you), Keith, James, Kenny, Martin, Jacob, Jeoff, and Robert! And a very happy new year to everyone, and you Malcolm! :)

[toc] | [prev] | [next] | [standalone]

#55921 — Re: C program. run time abend, range fault. Is this the correct solution?

On Mon, 05 Jan 2015 15:00:35 GMT, raltbos@xs4all.nl (Richard Bos)
wrote:

>This is a good temporary solution, but for the final product, given that
>(IIUC) the OP only ever uses integer values, I'd replace it by an
>integer_pow() function. And then measure which is more efficient.

I respectfully submit that this is all off on a non-productive path.
Quoting the OP's original post:

__________________________________________________________________
Inputs:

      pA = 1000
      pB = 44.50
      pN = 25
      pC = 0
      pD = 2
      pF = 2

These are correct inputs for which program works fine. Only for a few
weird inputs passed, like below, it gives the range fault. 

      pA = 1000
      pB = 144.50
      pN = 25
      pC = 0
      pD = 2
      pF = 2
__________________________________________________________________

Later, in another post he writes:
int main (void)
{
	long int l1, l2, l3, l4, l5, l6;
	l1 = 1000000;
	l2 = 25000;
	l3 = 0;
	l4 = 0;
	l5 = 0;
	l6 = 60;
	printf("A value = %ld \n", funcA(l1, l2, l3, l4, l5, l6));
}
__________________________________________________________________

He's inputting double type arguments to functions expecting int or
long long int. Then he changes to integer types, as seen in his last
posted code sample. 

I question his methodology. He's translating Fortran to C and jamming
it into a full system without unit tests and without consideration for
the data set. Then he wonders why it blows up. 

Is it floating point or is it integers or a combination? Only the
Fortran knows for sure and he hasn't posted that and probably can't
since it's so proprietary. Too bad too, I'd love to try my hand at
translating Fortran to C again, haven't done it in quite some time and
I have fond memories of adventures in Fortran. (It appears to me to be
some kind of quantitative analysis or online trading algorithm.)

Any advice offered regarding his code must consider the fact that the
C is fundamentally flawed at the outset without a deep understanding
of the specifications implied by the Fortran it's replacing and the
COBOL-to-Fortran interface.

I also believe the C as presented is questionable based on the
transcription process involved.

Best advice to him at this point is:

1. Start over.

2. Write new C, paying close attention to the Fortran variables and 
   their numeric types. Code the functions such that pass-by-value
   and pass-by-reference are handled faithfully according to the
   original Fortran rules. It's permissible and probably necessary 
   to have more than one C function per Fortran subroutine.

3. Write the C such that intermediate results can be compared with
   corresponding intermediate results in the Fortran and exceptions
   can be caught and handled. (I suspect there are no exceptions
   in the Fortran or they are handled gracefully somehow before
   they can be seen by the COBOL.)

4. Gather data sets to use in unit tests and their corresponding
   results as computed by the Fortran code.

5. Unit test the code, comparing the input and output data side by
   side with the Fortran.

6. Do not integrate with the system until unit test fidelity is
   achieved.

[toc] | [prev] | [next] | [standalone]

#55660

On Tue, 16 Dec 2014 00:47:50 -0800 (PST), Shiva
<subramanian.klu@gmail.com> wrote:

>There's an arithmetic program that I wrote in C. It was converted 
>from fortran. For the same inputs the fortran code does not give 
>out any run time abends but my C code does. 

Forgive me for going all the way back to the beginning but your C code
is full of conversions, implicit conversions, extra variables and
notations that just seems to confuse the issue. Your "good" data and
"bad" data inputs are inconsistent, beginning with floating point in
one case and integer in another. I can no longer tell if your inputs
are valid. I can't tell if your conversions from double to long long
are appropriate for the problem space this program is meant to solve.

You are converting Fortran code to C. Without seeing your Fortran
source, there is no way to judge whether your C is a correct
translation of that Fortran. The calling conventions of Fortran are
different than C and the interfaces from COBOL to FORTRAN and from
COBOL to C are another source of problems for a successful translation
of your module. No one here can give you specific advice on how to
proceed without comparing the two and understanding both.

The problems you describe in carrying over a true copy of the code as
it exists in your environment contribute to your problem of designing
a true test of the fidelity of the C code.

I think you are asking the wrong questions. The question in my mind is
now, "How can I prove my C is doing what the Fortran used to do?".

To prove the correctness of your F-to-C translation, you must test the
C module against the Fortran module outside of the COBOL that is going
to use it. 

Your first order of business should be to write a test harnesses and a
representative larger data set and run them against the Fortran module
and the C module while logging the outputs of each module. Any
deviations will be cause for questioning the fidelity of the C to the
original Fortran. You must arrive at identical outputs before you can
even consider integrating your C with the larger system.

The data you have provided here so far is inadequate for determining
if your C is faithful to the Fortran it's replacing. It's very evident
your C is "correct C" in that it compiles with few warnings but it
simply doesn't compute the same results as the Fortran module or it
wouldn't fail in the larger system.

It will be quite necessary to probe the intermediate results of your
calculations in C in order to determine where your program is failing.
In the overall sense you are white-box testing your module against
another known white-box, the Fortran it's replacing.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web