Menu
Sister Sites

Options

Bookmark Thread

First Page First Unread Last Page Last Post

Print Thread

Similar Threads

from zero to zero way 66 replies

division of price from high to low indicator 1 reply

The Bank, Futures Division - Trading Reports 33 replies

Forex.com, a division of Gain Capital, Discussion 24 replies

Programmers Indicator - Group Assembly 0 replies

Note to programmers: Division by zero errors

  • Post #1
  • Quote
  • First Post: Dec 22, 2009 8:48pm Dec 22, 2009 8:48pm
Fellow coders,

No disrespect intended, but there's absolutely no excuse for having your EAs and indicators fall over with 'division by zero' errors.

All you need is to include a function similar to this:

//+------------------------------------------------------------------+
double Divide(double n, double d)
//+------------------------------------------------------------------+
{
if (d == 0) return(0); else return(n/d);
}

at the end of your source.

And then instead of coding:

C = A/B;

use

C = Divide(A,B);

A and B can be expressions, as complex as you like.

That way, should B ever evaluate to zero, the error is trapped and handled. Returning a value of 0 might not be ideal, but it's better than having your executable fall over.
Actually proper range checking on the data renders this unnecessary.
You are in a maze of twisty little passages, all alike.
Obviously, Mr. Hanover you have not been educated as to the fact that getting an EA to properly solve 200/0 is the key that opens the door to the holy grail. LOL!
@Mr Magnum, I consider myself corrected.

@Steve, you are right, the fact that a divisor of zero occurs is the result of an oversight in the programmer's earlier logic.
Quoting hanover
Fellow coders,

No disrespect intended, but there's absolutely no excuse for having your EAs and indicators fall over with 'division by zero' errors.

All you need is to include a function similar to this:

[color="Blue"][font="Courier New"]//+------------------------------------------------------------------+
double Divide(double n, double d)
//+------------------------------------------------------------------+
{...
Very well said. I've used this kind of method for many years now. And I hope it helps other programmers out there!
Request custom Expert Advisor or Indicator: dostapyuk "at" gmail . com
Quoting hanover
@Mr Magnum, I consider myself corrected.

@Steve, you are right, the fact that a divisor of zero occurs is the result of an oversight in the programmer's earlier logic.
So I need something like this then, instead of simple division; just in case the magic is not present at the moment and is actually zero. Thanks for the big help. It was the final piece I needed.

PHP Code
 #import ".expertsdllsHolyGrail.dll"
   double  TheSecret();
   double AndThenAMiracleHappens();
   double IAmNowStinkingRich(double HopeAndAPrayer);
#import


double IHaveAllTheMoney = Divide( IAmNowStiningRich(AndThenAMiracleHappens()), TheSecret() );



//+------------------------------------------------------------------+
double Divide(double n, double d )
//+------------------------------------------------------------------+
   {
      if (d == 0) return(0); else return(n/d);
   } 
There are supposed to be back slashes on the dll line, for some reason, they are removed in the PHP quote.
OK, so the logic goes....



If ( IHaveAllTheMoney )

then ( IAmNowStinkingRich )

else

Return ( $$$$$$ )
Quoting Price
OK, so the logic goes....



If ( IHaveAllTheMoney )

then ( IAmNowStinkingRich )

else

Return ( $$$$$$ )

Well that is the plan, but I am having some trouble with my dll. It is not performing any miracles yet. Still working on it.
There is finally a thread where we can direct the new wannabe programmers. Thanks guys
Quoting hanover
//+------------------------------------------------------------------+
double Divide(double n, double d)
//+------------------------------------------------------------------+
{
if (d == 0) return(0); else return(n/d);
}
I doubt that this is a good idea. In fact it is the worst possible idea for handling this. It does not solve the problem but instead makes it even worse because the code will continue to run and produce difficult to debug errors elsewhere without any notice that there was an error in the division.

There is a reason why errors exist: They are not a bad thing, they are a gift! They tell the programmer that there is something wrong with his code, so he can fix it. Division by zero is an error, the program simply cannot continue to run as if nothing had happened. This error must be properly handled or completely avoided but never ever just be ignored!
hey 7bit...... when you mention It does not solve the problem ,

why would d==0 be necessarily be a problem.... it might be a fact....


true, we need to deal with the possibility prior to the division thru various means..... hanover's method is one such....

do you have an alternative method.....

//---
maybe we could toss in
if(d==0) Print("hey check d"); .....h
to trade and code, keep both simple... no call to impress....h
Quoting hayseed
hey 7bit...... when you mention It does not solve the problem ,

why would d==0 be necessarily be a problem.... it might be a fact....


true, we need to deal with the possibility prior to the division thru various means..... hanover's method is one such....

do you have an alternative method.....

//---
maybe we could toss in
if(d==0) Print("hey check d"); .....h
When checking for a currency quote that is not the Symbol(), if that currency is either missing or not updated, it will return a 0. This is actually useful information to me. I use it in a conditional statement to create the currency synthetically from two other pairs. So trapping the zero divide error is very useful and keeps the program running and my conditional statement takes care of solving the problem that the zero divide error could have caused. This is just one example of a useful need for the zero to be returned.
So if China destroys the US my wealth would be infinite

Hmmmm >
Quoting 7bit
I doubt that this is a good idea. In fact it is the worst possible idea for handling this. It does not solve the problem but instead makes it even worse because the code will continue to run and produce difficult to debug errors elsewhere without any notice that there was an error in the division.

There is a reason why errors exist: They are not a bad thing, they are a gift! They tell the programmer that there is something wrong with his code, so he can fix it. Division by zero is an error, the program simply cannot continue...
I agree - it's not a good idea.

Even if you are somehow aware of the problem and wants to debug it, you still have absolutely no idea which line of code it came from - just about as non-informative as the original "divide by zero" error.

The function would have also changed the behavior of the original code. Consider the following:

double1 = integer1/integer2;

vs

double1 = Divide(integer1,integer2);

They do not give the same results, so it's not just a simple matter of replacing the code.
Quoting smjones
When checking for a currency quote that is not the Symbol(), if that currency is either missing or not updated, it will return a 0. This is actually useful information to me. I use it in a conditional statement to create the currency synthetically from two other pairs. So trapping the zero divide error is very useful and keeps the program running and my conditional statement takes care of solving the problem that the zero divide error could have caused. This is just one example of a useful need for the zero to be returned.
Then you are using the wrong tool for the job. If you have a currency missing issue, check for that directly.
Quoting 7bit
I doubt that this is a good idea.......
I expected that somebody would say something like that.

You're absolutely correct, in principle.

Of course I believe that each situation should be taken on its own merit, and every effort should be made to proactively anticipate, and handle, every conceivable eventuality. That is a mandatory programming ethic. However, bugs are invariably the result of the unforeseen, and substituting zero for an unexpected missing or null item is usually a sensible, last resort 'catch all'. Leaving applications unnecessarily exposed to possible crashes is not good policy, IMO.

As a commercial operator, I'd rather have a benign error pass by unnoticed, than face a possible lawsuit because a mission-critical app falls over.

Just my personal view. Each to their own.

Quoting blogzr3
They do not give the same results, so it's not just a simple matter of replacing the code.
IMO the (truncated) result of

double C = A/B;

where A and B are integers is illogical, and a trap for young players. If one assigns a result to a float variable, one isn't seeking an integer result (having to work around with something like C = (1.0*A)/B; is cumbersome), and the Divide() function averts this. Of course one could easily write a DivideInt() function that returns an integer result, if desired.
I believe returning 0 is worse than just crashing. Dividing something by zero should return infinite if anything at all or the largest possible value (LONG_MAX, FLT_MAX), not zero.

Quote
As a commercial operator, I'd rather have a benign error pass by unnoticed, than face a possible lawsuit because a mission-critical app falls over.
How do you know it's a benign error? Maybe because returning 0 the EA will put on a 100 lot order instead of 1 lot (it's not that hard to come up with a formula which would do this if returning 0 when dividing by 0, something along the lines of 100 - X/0).

Put another way, how could I trust an EA made by someone who can't get something as simple as this right? As a programmer, EVERYTIME I'm dividing something, I ALWAYS think what if the divider is 0, can that happen? how do I handle that case?
Quoting Adal
Put another way, how could I trust an EA made by someone who can't get something as simple as this right?
What is 'right' is subjective, IMO. Experience has taught me that theory is for academics, and a pragmatic approach is preferable. As long as the code delivers a correct result, how it's written is irrelevant. If you disagree, well, that's OK.

Re your comment about trust, I've never asked that anybody trust the EAs and indicators that I've posted. Moreover, I almost always include a "take it or leave it, use at your own risk" type of disclaimer. People are welcome to judge the accuracy and usefulness of the end result for themselves. If the quality is sub-standard, well, it's a freebee, and nobody's forcing them to use it.

[EDIT] I just noticed this thread. Here's an indicator that's apparently crashing because the programmer failed to test for division by zero errors.
Quoting hanover
What is 'right' is subjective, IMO. Experience has taught me that theory is for academics, and a pragmatic approach is preferable.
Half a century of computer programming experience from a whole generation of computer programmers has led to some insights, best practices, well known sources of errors and rules and methods how to avoid them.

If you chose to ignore all the accumulated knowledge and want to re-invent programming from scratch, ignoring all knowledge because knowledge is "academic" and everything "academic" is useless and repeating the same old errors that already have been made a thousand times is "pragmatic" and pragmatism has to be a good thing, then go on and do it. Experience the errors yourself.

But don't teach newbies things that have already been proven wrong decades ago.

Quoting hanover
[EDIT] I just noticed this thread. Here's an indicator that's apparently crashing because the programmer failed to test for division by zero errors.
You are proposing the same thing: Ignoring the errors by simply turning off the error message instead of fixing them. This makes finding them and fixing them later when they eventually have to be fixed even more difficult.
Quoting 7bit
Half a century of computer programming experience......
Must admit I'm a little surprised that this topic has evoked such a passionate and insistent response. All I did – after seeing a rise in the number of "Division by zero error crash, please help" posts – was suggest a possible 'last resort' function for trapping them.

During my time as a developer, I've witnessed many debates over what constitutes 'right' or 'wrong' on a myriad of methodological and semantic issues (anybody remember the GOTO controversy? ). For better or worse, I've gradually come to prioritize accuracy and efficiency over technique. If anybody disagrees, that's fine with me. I'm merely sharing ideas that have worked well enough for me, over many years. I'm not trying to prove anything.

As for "reinventing programming from scratch", I wouldn't know where to start, LOL.

Quoting 7bit
You are proposing the same thing: ........
I didn't post in that thread.
0 traders viewing now