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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#54906

On 12/17/2014 04:05 PM, Shiva wrote:
> Hi all,
> 
> Thanks for your immediate responses and valuable answers. It seems that the above code I posted from memory (hell let lose) is wrong. There were so many reasons why I did not post the exact code before. Some reasons I can't state here. But I am doing so now, please find the correct code below. Any faults in the below program are possibly typo. My confidence in saying that the below code is right, is from experience. The code works for the correct inputs. It just fails when the wrong input is provided and that's where I want to correct the code.
> 
> Code: 
...

The subject line reports a run-time abend, with a range fault. The code
you've provided shouldn't even compile, so a run-time abend is out of
the question. Therefore, one thing is certain - this is NOT the code
that the subject line is talking about.

I've long been curious about something that many people do, and as one
of those people, perhaps you could explain it to me. When people have a
problem that they bring to this newsgroup, far more often than not they
fail to provide the exact code that they actually compiled, and either
produced the error message they're asking about, or produced the
unexpected behavior they're asking about.

When told that we can't figure out the problem from the code they
provided, they provide a different body of code, that still is not the
actual code that failed. This often goes through many iterations. I've
noticed that if a person fails to provide the actual code when first
asked to do so, it's generally impossible to convince that person to
ever provide it, no matter how many times we ask, no matter how well we
explain why providing the wrong code does no good. They will just go on
endlessly providing hand-typed copies filled with errors other than the
actual errors that they're asking about.

As one of the people who's done this kind of thing, would you care to
provide an explanation for this kind of behavior? What makes it so
difficult to simply cut and paste the actual code that compiled and
malfunctioned into your posted message? What produces this strange
compulsion to generate an error-filled hand copy of the code?
-- 
James Kuyper

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

#54919

In article <m6thmr$mu7$1@dont-email.me>,
James Kuyper  <jameskuyper@verizon.net> wrote:
...
>As one of the people who's done this kind of thing, would you care to
>provide an explanation for this kind of behavior? What makes it so
>difficult to simply cut and paste the actual code that compiled and
>malfunctioned into your posted message? What produces this strange
>compulsion to generate an error-filled hand copy of the code?

The usual reasons apply.

Among those reasons are:
    1) Organizational constraints - i.e., the actual code may in fact not
	be public.  I.e., the OP could get in trouble if he posts it.

    2) The code is ugly (most code is!).  It would simply be embarrassing
	to post it.  Related to this is the fact that oftentimes posting
	code in CLC just generates a bunch of off-topic sidelines about
	this or that irrelevant feature of the code (yes, we've all seen
	CLC's abnormal tendency to get obsessed over irrelevant trivia).

    3) Posting abstracted code is often the best way to keep people focused
	on the real issue(s).  One hopes that someone would actually know
	something about the "range error" issues and not get bogged down in
	being "human compilers".

Therefore, it makes sense to post abstractions of the true code, and hope
that something useful can be gleaned from the exercise.  In cases like
this, it's the best one can hope for.

All of which boils down to an agreement that you are correct.  This OP is
not likely to ever post actual code - and it's my opinion that further
attempts to harass him into doing so will only prove fruitless.

-- 
 Modern Conservative: Someone who can take time out
 from demanding more flag burning laws, more abortion
 laws, more drug laws, more obscenity laws, and more
 police authority to make warrantless arrests to remind
 us that we need to "get the government off our backs".

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

#54967

On 12/18/2014 3:18 AM, Kenny McCormack wrote:
> In article <m6thmr$mu7$1@dont-email.me>,
> James Kuyper  <jameskuyper@verizon.net> wrote:
> ...
>> As one of the people who's done this kind of thing, would you care to
>> provide an explanation for this kind of behavior? What makes it so
>> difficult to simply cut and paste the actual code that compiled and
>> malfunctioned into your posted message? What produces this strange
>> compulsion to generate an error-filled hand copy of the code?
>
> The usual reasons apply.
>
> Among those reasons are:
>      1) Organizational constraints - i.e., the actual code may in fact not
> 	be public.  I.e., the OP could get in trouble if he posts it.
>
>      2) The code is ugly (most code is!).  It would simply be embarrassing
> 	to post it.  Related to this is the fact that oftentimes posting
> 	code in CLC just generates a bunch of off-topic sidelines about
> 	this or that irrelevant feature of the code (yes, we've all seen
> 	CLC's abnormal tendency to get obsessed over irrelevant trivia).
>
>      3) Posting abstracted code is often the best way to keep people focused
> 	on the real issue(s).  One hopes that someone would actually know
> 	something about the "range error" issues and not get bogged down in
> 	being "human compilers".

One could create code that exhibits the problem behavior while not being 
the "real" code. That would take care of objection 1 and 3. (There's not 
much that can be done about 2.)

> Therefore, it makes sense to post abstractions of the true code, and hope
> that something useful can be gleaned from the exercise.  In cases like
> this, it's the best one can hope for.

It doesn't make sense to post code that doesn't even exhibit the problem 
in question, which is what is actually being complained about.

> All of which boils down to an agreement that you are correct.  This OP is
> not likely to ever post actual code - and it's my opinion that further
> attempts to harass him into doing so will only prove fruitless.

That's probably true enough. Never the less, it's still the most likely 
route to take to actually help him. Not that you care since you were 
clearly just using this as an excuse to badmouth the ones actually 
trying to help.

Martin Shobe

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

#54989

Hi everyone,

First things first. Really, really sorry for all the trouble and debate I've caused over here. That was not my intention in anyway. I'm really sorry for any trouble or aggravation caused. 

Now, first to James Kuyper - Really sorry mate. I'll attempt to answer your questions. I understand that in a group like this, gurus like you are only trying to help. And it is understandable that you'd expect the answer-seekers like myself to at least put up a good effort in explaining the problem. And trust me, we try. We really do. We are here to find answers and you are here voluntarily because of your good heart, only to help us. No complaints with regards to that. Now over to your question.

> What makes it so difficult to simply cut and paste the actual code that compiled and malfunctioned into your posted message? What produces this strange compulsion to generate  an error-filled hand copy of the code? 

Kenny got point one and three fine. But there's a more important and more explaining answer to that. I hope you have offshore colleagues? I hope you have Indian contractors working for 'partner' companies contracted to your company? If not, what I'm going to tell you might look like a made up story, but trust me - it is not. 

I don't know about the other occurrences that you were saying about, but in this instance - I work from India (of course, the outsourcing debate comes up right here) in one such partner company to a very, very reputed European client whose name I cannot disclose here due to legal restrictions. 

In my workplace, we have rules. Better read that as strict rules. I'm not allowed to take camera mobiles to my workplace. I'm not allowed to take a piece of paper inside, and even if I did - definitely can't bring it back outside the office. Strict rules, 24x7 monitored. And there's near to zero internet access in my workplace. If I develop a code and I face an issue and I want to google an answer for it, I don't get an opportunity to open all the results that google provides me. 9 out of those 10 results would come up as blocked sites for me. So everytime I face an issue, I have to steal a part of my own (faulty) code and come back home with that piece of paper and google it then and try to find a solution to make it work the next day. If you had seen my replies above, they'd validate that I've been answering questions only after the indian day time. Only during nights when I come home. It's not that I don't want to copy paste my code. Forget the legal restrictions there, I'm well past that when I first posted a similar kind of code to post the question here in the first place. To post my code here I've painfully write every single line of it in a piece of paper that can be accommodated in my pocket without any notice and I come back home to type it all up from that paper again and post it. 

I understand your frustration when you ask, how can I provide you a solution with a faulty code. More than you want to provide us a solution, we seek answers eagerly too. Again, I don't speak for all the other instances you faced before. I speak for myself, because I don't know the other situations you faced these, but more likely that they belong to this cider, I can't think of another reason why they'd be stupid enough to do it the hard way. We all post questions here only to seek answers. 

And I don't expect you to have known this already, because even my onshore colleagues who work for the same brand don't know all this. I understand the aggravation caused to you by this, I just hope you understand my situation as well. Because you honestly just wanted to know why - I made an attempt to write this up. I didn't want to spoil up all your time. Sorry about that. 

So James, you and Kenny are right in one point. I might never really be able to post the exact code that caused the run time abend. I'm crippled that way. 

I posted the same question on stack overflow and the question got more negative ratings than the one here. And my question even got rejected or [on hold] because it did not meet the requirements you all were saying and of course they were right. But I still got replies here, good minded people like you, Jen, Glen, Barry, Ben, Keith and so many others were still trying to understand my problem here and that's what made me try to give the correct code even more. The last code that I provided is the exact, with a few typos, code that runs. Few of the questions - I think - have answers in the code already, not sure why they did not see it. I'll ask below. And a few minor corrections needed as well, I agree. 

And you get to ask, for all the talk I make, I could've just wrote the correct code or if not debug and correct my code rather having to talk all this here (though that involves my capabilities as a coder, but that debate is for another day) - I have debugged the code and I know where exactly the problem is, and like I've stated above I have a few solutions in mind. I just want to know if there was a way to pick the abend out just before it is about to happen. 

So finally, I'm still going to try and correct the code above, I'm really sorry - I won't force you to help me, nor any of you, I'll try my best here and if there's no body here to respond, I'd understand. I just want to give it a try. I'm really sorry for all the grievances caused.

Yours sincerely,
Shiva.

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

#54991

On 12/18/2014 02:38 PM, Shiva wrote:
...
>> What makes it so difficult to simply cut and paste the actual code
>> that compiled and malfunctioned into your posted message? What
>> produces this strange compulsion to generate  an error-filled hand
>> copy of the code?
> 
> Kenny got point one and three fine. But there's a more important and
> more explaining answer to that. I hope you have offshore colleagues?
> I hope you have Indian contractors working for 'partner' companies
> contracted to your company? If not, what I'm going to tell you might
> look like a made up story, but trust me - it is not.

I work in a very different environment from yours. We don't outsource
any of our own code, but we do receive code from dozens of science teams
all around the world that we're required to integrate into our system.

> I don't know about the other occurrences that you were saying about,
> but in this instance - I work from India (of course, the outsourcing
> debate comes up right here) in one such partner company to a very,
> very reputed European client whose name I cannot disclose here due to
> legal restrictions.
> 
> In my workplace, we have rules. Better read that as strict rules. I'm
> not allowed to take camera mobiles to my workplace. I'm not allowed
> to take a piece of paper inside, and even if I did - definitely can't
> bring it back outside the office. Strict rules, 24x7 monitored. And
> there's near to zero internet access in my workplace. If I develop a
> code and I face an issue and I want to google an answer for it, I
> don't get an opportunity to open all the results that google provides
> me. 9 out of those 10 results would come up as blocked sites for me.
> So everytime I face an issue, I have to steal a part of my own
> (faulty) code and come back home with that piece of paper and google
> it then and try to find a solution to make it work the next day. If
> you had seen my replies above, they'd validate that I've been
> answering questions only after the indian day time. Only during
> nights when I come home. It's not that I don't want to copy paste my
> code. Forget the legal restrictions there, I'm well past that when I
> first posted a similar kind of code to post the question here in the
> first place. To post my code here I've painfully write every single
> line of it in a piece of paper that can be accommodated in my pocket
> without any notice and I come back home to type it all up from that
> paper again and post it.

Again, I work in a very different environment. Since we do civilian
scientific data processing, all of our science code is required to be
freely available to the general scientific public, so it can be subject
to review by other scientists to confirm whether it does what it's
supposed to do. Open source is the norm in our world, not the exception.
Our production system code is not publicly available, but only because
it's of no outside interest - there's nothing sensitive about it.

Some of the work I do involves purely civilian applications of data
collected by a satellite that is shared between NASA, NOAA, and the
Department of Defense. Because of the DoD involvement, even though I
know nothing about how the DoD uses that satellite, that code is subject
to export restrictions, and is therefore not publicly available, but
that's a rare thing in my working environment. I can't imagine how a
foreign agent could make use of any of that code to harm the US - but
I've often found my imagination to be lacking.

...
> So finally, I'm still going to try and correct the code above, I'm
> really sorry - I won't force you to help me, nor any of you, I'll try
> my best here and if there's no body here to respond, I'd understand.
> I just want to give it a try. I'm really sorry for all the grievances
> caused.

Some parts of what you describe are reasonable approaches to keeping
proprietary code secure. But they go too far in restricting your ability
to seek useful help. In the long run, that will help ensure that the
code you write won't be worth stealing - which, I suppose, is another
way to discourage theft :-}

There should be a way to sanitize failed code so it contains no
proprietary information, while still demonstrating the problem that
needs to be solved. It should be possible to get permission to post that
sanitized code in places like this, in order to get help. Alternatively,
if your workplace is large enough, it should have a internal location
where you can go to for help, without worrying about such issues - but
that requires that your company hire at least a few guru-level
programmers, and those are very expensive, for good reasons. If you have
management that is open to suggestions (I won't be surprised if they
aren't), I recommend suggesting these things - your company would be
better for it.

Do you have, at home, a system capable of compiling the "stolen" code
you brought home? In particular, do you have a home system sufficiently
similar to your work system that it allows you to duplicate the problem
you've reported? If so, take your "stolen" code, and work with it on
your home system until you've got a version that compiles and executes,
producing the same problematic behavior you saw at work. Then post the
following:

* The exact code you compiled.
* Identification of the compiler you're using, and of the compile/link
options you chose.
* All of the evidence produced by your program indicating that it
failed. If it produced error messages, cut and past those messages into
your posting.

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

#54995

That's a valid point, James. Very valid. It is in my fault that I never tried that really. Though there are a few exceptions that I could give, I still could've given a better code. I'll try do all that you suggest. 

And about suggesting things to my workplace, let's just say that the ears are very far away from the place that I am at.  :)

Just that I work in a very propriety environment. I don't have those compilers. I have the normal GCC, and the code that works fine in the normal GCC spurs out errors in that environment. It's a HP NS Tandem environment, if that helps. But I'll still run it through the GCC and let you know. 

Thank you very much for understanding. Much appreciated.

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

#55035

1) run the C code .exe form in a debugger
2) initialize variables with value that has problem
3) follow step by step all calculation... there would be some result it is out eg NAN or too much little or too much big
4) handle that case: Why I have that? Is it a routine error? Is it an input error? Etc

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

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

I proposed a solution yesterday but nobody answers. Can anyone have a look?


Le 18/12/2014 21:28, Shiva a écrit :
 > So the error comes up in funcB line:
 >
 > F1 = pow (A, -pN);
 >
 > where F1's value in the 66th iteration becomes 2.189569 e -77already 
and hence will

try to become more lesser in the 67th iteration and that's where it fails.
-------------------------------------------------------
My proposal

Undeflow/overflow is happening.

So, if pow(A,-pN) must be less than DBL_MAX or DBL_MIN, you can test for it

DBL_MAX 1.7976931348623157E+308

log (DBL_MAX) --> 709.78271289338399672769243071670056098

so if fabs(log(A)*log(pN)) > 700.0

this will overflow and

DBL_MIN 2.2250738585072014E-308

log(DBL_MIN) -708.39641853226410621681158499121371867

so if fabs(log(A)*log(pN)) > 700.0

will work also avoiding underflow.

I hope this is right. I *think* the reasoning is right but let's see 
what the other experts think here

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

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

Le 19/12/2014 18:32, jacob navia a écrit :
> I proposed a solution yesterday but nobody answers. Can anyone have a look?

  That solution was wrong
we have

	a^b < DBL_MAX  to avoid overflow

Taking logs at both sides

	b*log(a) < LOG(DBL_MAX)
	b*log(a) < 708

	log(a) < 708/b

That is the correct solution

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

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

Hi everyone,

Thanks a lot for all your valuable inputs. Took a break from all this work, hence the delay. :)

Like some of you pointed out, I still had posted wrong code. Too bad of me, I could've at least compiled it. And the input I provided was in the wrong order as well. 

Use the following: 

#include<stdio.h> 

#include<stdlib.h> 

#include<math.h> 

double A,v,w,x,y,z; 

double funcC (int, int, int, double, double, double); 

double funcB (int, int, int, double, double, double); 

long int funcA (long long int Lp1, long long int Lp2, long long int Lp3, long long int Lp4  , long long int Lp5, long long int Lp6) 

{ 
  
double pA, pB, pC; 

int pD, pF, pN, count, limit; 
      
long int r; 
      
double q; 
      
pA = (double) Lp1/100; 
      
pB = (double) Lp2/100; 
      
pC = (double) Lp3/100; 
      
pD = Lp4; 
      
pF = Lp5; 
      
pN = Lp6; 
      
limit = 100; 
      
q = pow (10,7); 
      
A = 10000001/q; 
      
z = funcB (pF, pN, pD, pC, pB, pA); 
      
v = A; 
      
w = z; 
      
A = 1.05; 
      
z = funcB (pF, pN, pD, pC, pB, pA); 
      
x = A; 
      
y = z; 
      
count = 0; 
      
do 
      
{ 
        
A = funcC (pF, pN, pD, pC, pB, pA); 
        
count = count + 1; 
        
} while ((( z >= 0.0001) || ( z <= -0.0001)) && (count < limit)); 
      
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); 
  
} 
    

double funcB (int pF, int pN, int pD, double pC, double pB, double pA) 

{ 
  
double F1, F2; 
  
F1 = pow (A, -pN); 
  
F2 = pow (A, pF); 
  
z = ((F2 * (A - 1) ) / (1 - F1)); 
  
z = pB/ z; 
  
z = z - pA - (pC/ pow (A, pD)); 
  
return (z); 
} 

double funcC (int pF, int pN, int pD, double pC, double pB, double pA) 
    
{ 
      
double a,b,c,d,e; 
      
a = x - v; 
      
b = w - y;   
      
A = v + (fabs(w)/ ((fabs(b)) / (a))); 
      
z = funcB (pF, pN, pD, pC, pB, pA); 
      
if (z > 0) 

{ 

v = A; 

w = z; 

} 

else if (z < 0) 

{ 

x = A ;   

y = z; 

} 

return (A); 

} 

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));

}

I hope the above code is devoid of any errors and the added main function gives way for me to pass the values onto funcA which does the math and returns A for the COBOL program in production, but for testing purposes  - the main was introduced. Hence was never added in my previous codes. Provided here just for the sake of it.

So Barry if you notice the inputs now, you won't get the case you suggested. My inputs were wrong, for all the stupidity that I've done all over this post, I had to give the wrong inputs. I'm sorry.

Jen, many thanks for your analysis. Makes my route much clearer.

I understand that the following are my options here.

1) Check my MATH.H first and know what's there. To know if exceptions are handled and if so, how. - Not too hard, already on it. Will come back with more details when I find some.

2) Catching the 'signal' or 'error'(as they call it) myself within my program. That would require some more testing (which I'm always up to) Once I'm done with point one, I'll get on with this.

Also I would like some advice here. Say I test this and I find that the error value trips over when the overflow/underflow happens - it would be like me checking the value of that error right after I call the power function and then decide to quit the iteration or something like that - but again, I think the problem arises not when assigning the pow output to a variable, but while calling pow itself. When you call pow with those 'out of bounds' values, the program abends at run time. It never recovers from that point, it doesn't even transfer the control back to the line of code which calls pow. At least this is what my assumption is, though I'll have to prove it first. 

But if it is so, then what do I do? I'd have to amend my math.h and make out catch exceptions through the FPU which Jen suggested? (considering that point one turns out to be negative).

3) Something like what Jacob has suggested. Well thought and a good one too. A check for the inputs before we go into the pow function, now this would avoid the problem that I might face in point 2. But I think, like Jen says, even if I do these checks before I go to the pow function - this is going to make my code a lot different than where I started because I might have to eventually add this check to every single line of the above code that calls to pow function (because the line that I mentioned which failed is not the only pow function in the code, sadly)

And thanks Jacob, your latest reply sounds solid. :)

4) Now this might be more or less like point 3 extended. I might have to write a pow function myself. Now that's going to be a real pain. A flawless, accurate pow function that could handle the error that math.h is letting go. But if accomplished, this could be my safest way out. 

Let me know if I've missed anything. I'll start to work on the above. Spare me the new year day. ;)

Happy new year, everyone. Thanks a lot! :)

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

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

On 12/31/2014 02:48 PM, Shiva wrote:
> Hi everyone,
> 
> Thanks a lot for all your valuable inputs. Took a break from all this work, hence the delay. :)
> 
> Like some of you pointed out, I still had posted wrong code. Too bad
> of me, I could've at least compiled it. And the input I provided was in
> the wrong order as well.
> 
> Use the following: 
...

I run into a fundamental problem when I use it - I can't reproduce the
reported problem. I get the following:

A value = 18710

Did you make sure that you could duplicate the reported problem with
this version of the code?

If it abends on your system, and completes on mine, it's possible that
your code has a portability problem that I could figure out with a code
review, but that kind of thing is much harder to track down than a
reproducible error condition.

...
> 4) Now this might be more or less like point 3 extended. I might have
> to write a pow function myself. Now that's going to be a real pain. A
> flawless, accurate pow function that could handle the error that
> math.h is letting go. But if accomplished, this could be my safest
> way out.

You don't have to write the entire pow() function, just a wrapper named
my_pow() which validates the arguments before passing them on to pow().

If you're certain that it's pow() that's the problem, create a wrapper
for pow() that prints out the arguments being passed to pow(), and then
call fflush(stdout). Change your code to call the wrapper function, and
you'll know what values they had just before your abend occurred.

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

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

Shiva <subramanian.klu@gmail.com> writes:
> Hi everyone,
>
> Thanks a lot for all your valuable inputs. Took a break from all this work, hence the delay. :)
>
> Like some of you pointed out, I still had posted wrong code. Too bad of me, I could've at least compiled it. And the input I provided was in the wrong order as well. 
>
> Use the following: 
>
> #include<stdio.h> 
>
> #include<stdlib.h> 
>
> #include<math.h> 
>
> double A,v,w,x,y,z; 
>
> double funcC (int, int, int, double, double, double); 
>
> double funcB (int, int, int, double, double, double); 
>
> long int funcA (long long int Lp1, long long int Lp2, long long int Lp3, long long int Lp4  , long long int Lp5, long long int Lp6) 
>
> { 
>   
> double pA, pB, pC; 
>
> int pD, pF, pN, count, limit; 
>       
> long int r; 
[snip]

Judicious use of blank lines, for example to separate function
definitions or logical blocks, is useful.  Double-spacing *all* the code
is not; it just wastes vertical space and makes it more difficult to
read.

Proper indentation is also important for readability.  There are several
competing indentation styles; which one you pick matters less than
following it consistently.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

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

On Wed, 31 Dec 2014 13:07:15 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>[snip]
>
>Judicious use of blank lines, for example to separate function
>definitions or logical blocks, is useful.  Double-spacing *all* the code
>is not; it just wastes vertical space and makes it more difficult to
>read.
>
>Proper indentation is also important for readability.  There are several
>competing indentation styles; which one you pick matters less than
>following it consistently.

He copy-pasted the code as you previously insisted he do. It was
indented at one time and it takes minimal effort to see that. Once
it's reformatted to removed the extra line feeds it's well-spaced and
reasonable C.

I suspect the line spacing is an artifact of the Google groups
interface. Copying it into Visual Studio revealed tabs and spaces
within the blank lines, indicating it was very likely originally
tabbed and spaced in an editor like VS and the tabs were placed on new
lines by the stupid Google formatter rather than at the beginning of
the non-blank lines.

AFAIK, Google doesn't have a preview window where one can see how ones
post is going to look before launching it upon the world. The result
is not really the direct fault of the OP but merely his poor choice of
Usenet interface.

If you're not going to comment on the problem and the code but instead
simply snipe at the style of the post and ignore the content because
it doesn't meet your esthetic requirements wouldn't it be better to
remain silent and pretend you never saw it?

Why don't you take your Netiquette crusade to the management of
Google, Inc. and tell them all about how Usenet posts are supposed to
look. Since you are such a grand authority on the topic I'm sure
they'll move heaven and earth to satisfy your stringent requirements.

Here's Shiva's code, reformatted and trimmed for the imperious twits
who can't be bothered to do it themselves. I'm sure someone will rise
to the occasion to criticize it for containing tabs instead of spaces.

#include<stdio.h>
#include<stdlib.h>
#include<math.h>

double A,v,w,x,y,z;
double funcC (int, int, int, double, double, double);
double funcB (int, int, int, double, double, double);

long int
funcA (long long int Lp1, long long int Lp2,
	long long int Lp3, long long int Lp4,
	long long int Lp5, long long int Lp6)
{
	double pA, pB, pC;
	int pD, pF, pN, count, limit;
	long int r;
	double q;

	pA = (double) Lp1/100;
	pB = (double) Lp2/100;
	pC = (double) Lp3/100;
	pD = Lp4;
	pF = Lp5;
	pN = Lp6;
	limit = 100;
	q = pow(10.0,7);
	A = 10000001/q;
	z = funcB (pF, pN, pD, pC, pB, pA);
	v = A;
	w = z;
	A = 1.05;
	z = funcB (pF, pN, pD, pC, pB, pA);
	x = A;
	y = z;
	count = 0;
	do
	{
		A = funcC (pF, pN, pD, pC, pB, pA);
		count = count + 1;
	}
	while ((( z >= 0.0001) || ( z <= -0.0001)) && (count < limit));

	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);
}


double funcB (int pF, int pN, int pD, double pC, double pB, double pA)
{
	double F1, F2;
	F1 = pow (A, -pN);
	F2 = pow (A, pF);
	z = ((F2 * (A - 1) ) / (1 - F1));
	z = pB/ z;
	z = z - pA - (pC/ pow (A, pD));
	return (z);
}

double
funcC (int pF, int pN, int pD, double pC, double pB, double pA)
{
	double a,b,c,d,e;
	a = x - v;
	b = w - y;
	A = v + (fabs(w)/ ((fabs(b)) / (a)));
	z = funcB (pF, pN, pD, pC, pB, pA);
	if (z > 0)
	{
		v = A;
		w = z;
	}
	else if (z < 0)
	{
		x = A ;
		y = z;
	}
	return (A);
}

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));
}

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

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

Geoff <geoff@invalid.invalid> writes:
> On Wed, 31 Dec 2014 13:07:15 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>[snip]
>>
>>Judicious use of blank lines, for example to separate function
>>definitions or logical blocks, is useful.  Double-spacing *all* the code
>>is not; it just wastes vertical space and makes it more difficult to
>>read.
>>
>>Proper indentation is also important for readability.  There are several
>>competing indentation styles; which one you pick matters less than
>>following it consistently.
>
> He copy-pasted the code as you previously insisted he do. It was
> indented at one time and it takes minimal effort to see that. Once
> it's reformatted to removed the extra line feeds it's well-spaced and
> reasonable C.

Copy-and-pasting code is very nearly always better than re-typing it; it
avoid re-introducing irrelevant errors.  Do you disagree?  Most code I
see here *is* properly indented, so it can't be too difficult.  That's
not to say I blame the OP for the formatting; it's likely the fault of
the Google interface.

I see that the code is encode as "quoted-printable", and that there are
some remains of the original indentation.  I hadn't noticed that when I
posted my followup.  I was only able to see it by saving the article to
a file.

> I suspect the line spacing is an artifact of the Google groups
> interface. Copying it into Visual Studio revealed tabs and spaces
> within the blank lines, indicating it was very likely originally
> tabbed and spaced in an editor like VS and the tabs were placed on new
> lines by the stupid Google formatter rather than at the beginning of
> the non-blank lines.
>
> AFAIK, Google doesn't have a preview window where one can see how ones
> post is going to look before launching it upon the world. The result
> is not really the direct fault of the OP but merely his poor choice of
> Usenet interface.

That sounds about right.

> If you're not going to comment on the problem and the code but instead
> simply snipe at the style of the post and ignore the content because
> it doesn't meet your esthetic requirements wouldn't it be better to
> remain silent and pretend you never saw it?

My intent was to be helpful to the original poster.  I merely
misunderstood the cause of the bad formatting.

> Why don't you take your Netiquette crusade to the management of
> Google, Inc. and tell them all about how Usenet posts are supposed to
> look. Since you are such a grand authority on the topic I'm sure
> they'll move heaven and earth to satisfy your stringent requirements.

Why don't you take your sarcasm and [...]

Happy New Year.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

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

On Thursday, January 1, 2015 12:02:21 AM UTC, Keith Thompson wrote:
> 
> Why don't you take your sarcasm and [...]
> 
> Happy New Year.
> 
Woo hoo.

First post of 2015.

Happy New Year everybody.

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

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

Geoff <geoff@invalid.invalid> wrote:

> Why don't you take your Netiquette crusade to the management of
> Google, Inc. and tell them all about how Usenet posts are supposed to
> look.

Because they have a very well-documented history of not giving a flying
@&^@#.

Richard

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

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

Shiva <subramanian.klu@gmail.com> writes:
<snip>
> Like some of you pointed out, I still had posted wrong code. Too bad
> of me, I could've at least compiled it. And the input I provided was
> in the wrong order as well.
>
> Use the following: 
>
> #include<stdio.h> 
>
> #include<stdlib.h> 
>
> #include<math.h> 
>
> double A,v,w,x,y,z; 
>
> double funcC (int, int, int, double, double, double); 
>
> double funcB (int, int, int, double, double, double); 

...etc.

I found that my brain stared to hurt trying to follow the code.  It
computes by setting six one-letter globals that seem to ties all the
functions together.  It hurt so much that I tried to re-write it without
the globals.  It's not that hard:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

double funcB(double, int, int, int, double, double, double); 

long int funcA(long long int Lp1, long long int Lp2,
               long long int Lp3, long long int Lp4,
               long long int Lp5, long long int Lp6)
{ 
     double pA = Lp1/100.0, pB = Lp2/100.0, pC = Lp3/100.0;
     int pD = Lp4, pF = Lp5, pN = Lp6;

     double v = 10000001 / pow(10,7);
     double w = funcB(v, pF, pN, pD, pC, pB, pA);

     double x = 1.05;
     double y = funcB(x, pF, pN, pD, pC, pB, pA); 

     int count = 0, limit = 100;
     double A, z;
     do {
          A = v + fabs(w) / (fabs(w - y) / (x - v));
          z = funcB(A, pF, pN, pD, pC, pB, pA); 
          if (z > 0) {
               v = A;
               w = z;
          }
          else if (z < 0) {
               x = A;
               y = z;
          }
     } while ((z >= 0.0001 || z <= -0.0001) && ++count < limit);
      
     if (count == limit) 
          A = -1; 
     else {
          A = (pow(A, 12) - 1) * 100;
          A = (long long int)((A + 0.005) * 100) / 100.0;
     }
     return A * 1000;
}   

double funcB(double A, int pF, int pN, int pD, double pC, double pB, double pA) 
{
     return pB * (1 - pow(A, -pN)) / pow(A, pF) / (A - 1) - pA - pC / pow(A, pD);
}

int main(void)
{
     printf("A value = %ld \n", funcA(1000000, 25000, 0, 0, 0, 60));
}

I've also removed redundant parentheses and removed many temporary
variables.  I know not everyone likes that sort of change, but I find
shorter code with fewer names almost always simpler to debug.

I know this won't help you (the OP) but it may cause more people to look
harder at the problem you are having.

It did make one thing clear.  All you power operations are integer
powers, so you could very simply re-write with your own pow function
that checks for multiplication overflow in a loop (either a naive one or
one using the squaring algorithm).

<snip>
> 3) Something like what Jacob has suggested. Well thought and a good
> one too. A check for the inputs before we go into the pow function,
> now this would avoid the problem that I might face in point 2. But I
> think, like Jen says, even if I do these checks before I go to the pow
> function - this is going to make my code a lot different than where I
> started because I might have to eventually add this check to every
> single line of the above code that calls to pow function (because the
> line that I mentioned which failed is not the only pow function in the
> code, sadly)

No, just write a function that does the check.

<snip>
> 4) Now this might be more or less like point 3 extended. I might have
> to write a pow function myself. Now that's going to be a real pain. A
> flawless, accurate pow function that could handle the error that
> math.h is letting go. But if accomplished, this could be my safest way
> out.

This is not too hard given the fact that your exponents are all
integers.

I note that the example call given does not fail on my system.  Did you
post input that fails on yours?

<snip>
-- 
Ben.

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

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

Le 31/12/2014 20:48, Shiva a écrit :
>   Something like what Jacob has suggested. Well thought and a good one too.

A check for the inputs before we go into the pow function, now this 
would avoid the problem that I might face in point 2.

But I think, like Jen says, even if I do these checks before I go to the 
pow function -

this is going to make my code a lot different than where I started 
because I might have to eventually

add this check to every single line of the above code that calls to pow 
function (because the

line that I mentioned which failed is not the only pow function in the 
code, sadly)

Hi

Replace ALL calls to pow(a,b) with Pow(a,b)

Then you write:

double Pow(double a, double b)
{
	if (test_described_in_my_last_post)
		return 1e308;
	return pow(a,b);
}

Of course you could take other actions if the test fails instead of 
returning 1e308 that could make other calculations overflow!

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

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

jacob navia <jacob@spamsink.net> wrote:

> Replace ALL calls to pow(a,b) with Pow(a,b)

(Or, for clarity, pow_bounds_checked(a,b).)

> Then you write:
> 
> double Pow(double a, double b)
> {
> 	if (test_described_in_my_last_post)
> 		return 1e308;
> 	return pow(a,b);
> }

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.

> Of course you could take other actions if the test fails instead of 
> returning 1e308 that could make other calculations overflow!

You could, but then, in any case where that happens, the _real_ value
would've caused the same overflow, so that's not a problem as such.

Richard

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

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

Hi everyone,

I don't know what's it about me to keep misplacing the input. The input I provided above in the recent code is the 'good' input. And the answer as someone stated is an accurate 18710.

Which is:

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)); 

} 


The 'bad' input for which the code is returning the error value of -1 as per the condition check in the code is: 

int main (void) 

{ 

long int l1, l2, l3, l4, l5, l6; 

l1 = 1759672; 

l2 = 23306; 

l3 = 0; 

l4 = 0; 

l5 = 0; 

l6 = 60; 

printf("A value = %ld \n", funcA(l1, l2, l3, l4, l5, l6)); 

} 

Here for the above input data, the code does not abend but follow the correct procedure and returns a -1 for A.

But for the below input the abend happens.

int main (void) 

{ 

long int l1, l2, l3, l4, l5, l6; 

l1 = 200000; 

l2 = 7345; 

l3 = 0; 

l4 = 0; 

l5 = 0; 

l6 = 12; 

printf("A value = %ld \n", funcA(l1, l2, l3, l4, l5, l6)); 

} 


For the input provided above "the really bad input" - the  value for F1 becomes the following at the 66th iteration - or in the 67th, I don't really remember. F1 = 2.189569 e -77

And that's when the abend happens.

And yeah, like many of you seem to suggest, I could do with a check overtime before I call the pow function, that should help. 

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. 

Thanks for all your valuable inputs, guys. I'll try the signal_error display when the overflow happens and will also try the pow check which I'm sure will work! :)

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

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

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

csiph-web