Floating point error

[ptcman]

Hi.

I'm receiving a floating point (division by zero error) in the following formula:

(1-value1/value2)*100

How can I remove the error?
Is there another way to write the above formula?

regards
ptcman

 

[Charlton]

Hi.

I'm receiving a floating point (division by zero error) in the following formula:

(1-value1/value2)*100

How can I remove the error?
Is there another way to write the above formula?

regards
ptcman

One way to remove a division by zero error where you expect this to happen is to introduce an IF statement

If value2 = 0 then 0 else (1-value1/value2)*100 ;

Charlton

 

[new_trader]

One way to remove a division by zero error where you expect this to happen is to introduce an IF statement

If value2 = then 0 else (1-value1/value2)*100 ;

Charlton

IMO: The cell shouldn't be = 0 if value2 is = 0. That is incorrect.

 

[Charlton]

IMO: The cell shouldn't be = 0 if value2 is = 0. That is incorrect.

In that case decide what you want the result to become - let's call it n and the formula becomes

If value2 = then n else (1-value1/value2)*100 ;

It's really a question of what you want the value to be if the calculation fails to work because you are dividing by zero.

What would you suggest the result should be ?

Charlton

 

[ptcman]

Hi.

Charlton, I didn't understand you formula.

Value1 and value2, by themselves, never plot zero as a result.

The above formula, some how, produce negative results in some bars presumably because of that division by zero error.

I don't know if any of you is familiarized with Metastock formula language, but in MSFL there is a way to solve this issue:

(1-value1/max(value2,0.0001))*100

Basically we use the Max() function.

I try to do the same thing in EL, using the MaxList() function but didn't work

 

[new_trader]

In that case decide what you want the result to become - let's call it n and the formula becomes

If value2 = then n else (1-value1/value2)*100 ;

It's really a question of what you want the value to be if the calculation fails to work because you are dividing by zero.

What would you suggest the result should be ?

Charlton

I don't know, it needs to be put into context. If you had 1 orange that you had to divide equally amongst zero people you don't end up with 0 oranges or 0 pieces. The result is basically what you get, ie/ Doesn't make sense.

 

[ptcman]

Imagine this:

(1-value1=30/value2=62)*100

Let me add that, value2 is always higher than value1

This formula will produce in some bars, negative results. How is that possible? I assume that it is because of that division by zero error.

 

[Charlton]

Imagine this:

(1-value1=30/value2=62)*100

Let me add that, value2 is always higher than value1

This formula will produce in some bars, negative results. How is that possible? I assume that it is because of that division by zero error.

Ptcman

The message "division by zero" means what it says and occurs when the denominator in a calculation is zero. If value2 is never zero at the point where you are performing the calculation within the code then the error must lie somewhere other than in the calculation you have posted.

If you enter a line into the code immediately before the calculation as follows:

print( "value1 ", value1, " , value2 ", value2);

this will send the values out to the log file. I still suspect that value2 has a value of zero at some point in the process, either because of a default that has been set or because it has been reset to zero at some point. Without the full code it is difficult to say, but the print statement above should verify that.

Certainly if values are, as you say they are and the calculation has been entered as you have shown, you should not get that message. The precedence of the calculation should always give a positive value.

"Operators have an order or precedence by which statements are evaluated. Certain operators have higher precedence
over others and those operator calculations are performed before those with lower precedence. Operators
are evaluated from left to right through the calculation or comparison. Multiplication and division have
precedence over addition and subtraction. AND has higher precedence over OR.
You can use parentheses around expressions to force grouping. Calculations or comparisons inside parentheses
are always performed first, with the innermost set having precedence working outward."

Charlton

 

[ptcman]

OK.

Here is a similar formula that produces the same error.

I've made two versions of the "bulRng" variable to see if there was a problem with the first one but the result is the same.

Notice how there are a couple of bars where the result is negative.

{ *Variables*}
vars : cls(0), dRng(0);
vars : inRng(true), upRng(true), dnRng(true), inBulRng(0), pctBul(0);
vars : in1Bul(0), in2Bul(0), up1Bul(0), up2Bul(0), dn1Bul(0), dn2Bul(0),bulRng(0);

{ *Variable declaration* }
cls = close[1];
inRng = high > cls and low < cls;

{ *Daily Range* }
if high < cls then begin
dRng = cls - low;
end
else
if low > cls then begin
dRng = high - cls;
end
else
if high > cls and low < cls then begin
dRng = high - low;
end;

{ *Inside Range 1st version* }
if inRng then begin
in1Bul = high - open;
in2Bul = close - low;
bulRng = (in1Bul + in2Bul) * 0.5;
end;

{ *Inside Range 2nd version
if inRng then begin
in1Bul = high - open;
end
else
in1Bul = 0;
if inRng then begin
in2Bul = close - low;
end
else
in2Bul = 0;
inBulRng = (in1Bul + in2Bul) * 0.5;
if inRng then begin
bulRng = inBulRng;
end;
*}

{ *Percentage Range }
pctBul = (1-bulRng/dRng)*100;

{ *Plot im own Window* }
plot1(pctBul);

I tested the Print() as you advised and I didn't find any zero result

I just can't see where is the problem

PS: I forgot to say that I´m using Multicharts and not Tradestation

 

[Charlton]

OK.

Here is a similar formula that produces the same error.

I've made two versions of the "bulRng" variable to see if there was a problem with the first one but the result is the same.

Notice how there are a couple of bars where the result is negative.

{ *Variables*}
vars : cls(0), dRng(0);
vars : inRng(true), upRng(true), dnRng(true), inBulRng(0), pctBul(0);
vars : in1Bul(0), in2Bul(0), up1Bul(0), up2Bul(0), dn1Bul(0), dn2Bul(0),bulRng(0);

{ *Variable declaration* }
cls = close[1];
inRng = high > cls and low < cls;

{ *Daily Range* }
if high < cls then begin
dRng = cls - low;
end
else
if low > cls then begin
dRng = high - cls;
end
else
if high > cls and low < cls then begin
dRng = high - low;
end;

{ *Inside Range 1st version* }
if inRng then begin
in1Bul = high - open;
in2Bul = close - low;
bulRng = (in1Bul + in2Bul) * 0.5;
end;

{ *Inside Range 2nd version
if inRng then begin
in1Bul = high - open;
end
else
in1Bul = 0;
if inRng then begin
in2Bul = close - low;
end
else
in2Bul = 0;
inBulRng = (in1Bul + in2Bul) * 0.5;
if inRng then begin
bulRng = inBulRng;
end;
*}

{ *Percentage Range }
pctBul = (1-bulRng/dRng)*100;

{ *Plot im own Window* }
plot1(pctBul);

I tested the Print() as you advised and I didn't find any zero result

I just can't see where is the problem

PS: I forgot to say that I´m using Multicharts and not Tradestation

Ptchman

One last try - Going back to my supposition based on the error message you gave the problem is division by zero. The only part of the code that is a division is:

pctBul = (1-bulRng/dRng)*100;

You tell me that you have plotted dRng and it gives no zero values or (I assume) missing values. At this point I would stop and say that I cannot help further.

However there appear to be some instances in your code that could give rise to missing values for dRng. Let’s say you had a bar where the High > Cls and Low = Cls

InRng would then be false.

Within section { *Daily Range* } dRng would remain at 0, because it does not fall into any of the conditions

high < cls OR low > cls OR high > cls and low < cls

so will not be set to a new value

It will persist with this value right down to the final pctBul calculation and would result in division by zero.

The same problem would arise where High = Cls and Low < Cls.

If this is not the answer then I’m afraid I cannot provide any further suggestions

Charlton

 

[ptcman]

First of all, let me thank you for your replys. They're great for brainstorming, especially for people like me, iniciating on EL.

I made a little modification in the { *Daily Range* } and in the { *Variable declaration* } section.

{ *Variables*}
vars : cls(0), dRng(0);
vars : inRng(true), upRng(true), dnRng(true), inBulRng(0), pctBul(0);
vars : in1Bul(0), in2Bul(0), up1Bul(0), up2Bul(0), dn1Bul(0), dn2Bul(0),bulRng(0);

{ *Variable declaration* }
cls = close[1];
inRng = high > cls and low < cls;
upRng = low >= cls;
dnRng = high <= cls;

{ *Daily Range* }
if dnRng then begin
dRng = cls - low;
end
else
if upRng then begin
dRng = high - cls;
end
else
if inRng then begin
dRng = high - low;
end;

{ *Inside Range 1st version* }
if inRng then begin
in1Bul = high - open;
in2Bul = close - low;
bulRng = (in1Bul + in2Bul) * 0.5;
end;

{ *Percentage Range }
pctBul = (1-bulRng/dRng)*100;

{ *Plot in own Window* }
plot1(pctBul);

{ *Plot in own window upRng, dnRng and inRng conditions* 
plot1(high<=cls);
plot2(low>=cls);
plot3(high>cls and low<cls); }

As you can see on the chart in the @ test 02 window, each true condition is correctly plotted. Red equals "dnRng", Blue equal "upRng" and Aqua equals "inRng". When one is false the other one is true and so forth. There is no place for zero/missing values.

So if all conditions are correctly plotted, shouldn't "dRng" be also correctly set?

In @ test 03 window you can see that "pctBul" continues to plot negative values for some bars.

What and where is the problem?

 

[Charlton]

I think I see what is going on now. I can reproduce the problem with Tradestation as you can see in the attached document. This shows a 5 min chart and your code gives negative bars there as well.

If you look at the screen prints you will see that one of the bars actually flipped over from negative to positive during the formation of the 5 min bar.

If you look at the values captured in the print log you will see that the calcuation is performing correctly, but what it is doing is peforming the calculation at tick level. The open for the 5 min bar is static, but the other prices are based on the tick and so at times the value of bulrng becomes larger than dnrng, so a negative number occurs.

In Tradestation you can force the calculation to only be performed at the closing tick (see the barstatus reserved word in the attached document).

Hopefully that will solve your problem if the same facility is available in Multicharts

Charlton

 

[ptcman]

I tried to plot the study on a real time chart but I always received a floating point error, closing the window automaticaly. So I could only see it on daily charts.

There is nothing better than to test an indicator on a real time chart to see what exactly is going on.

The prints that you showed are clear about the problem, bulRng cannot be higher than dRng.

Multicharts also has the BarStatus() reserved word. Actually, I think Multicharts has all funtions that TS has.

Let me see how BarStatus() works and how can I apply it.

 

[ptcman]

Hi Charlton.

I've tested BarStatus() but I'm having difficulty in understanding the concept.

plot1(barstatus);

As far as I could see, when a new bar iniciates (open price) the barstatus() plots 2 and after that plots 1 until the end of the, in this case, 5 min bar althouht this is a bit different of what EL manual says about barstatus()

Can you give me a hint on how to apply it, I'm clueless.

You've mentioned that the open price is static, but isn't the high and low of each bar also static after they've been made? For example, a bar opens and starts to rise. Then starts to come back towards the open, so that high has become static, right?

The only value that will truly become static at the end of the bar is the close, right?



Fernando

 

[Charlton]

Hi Charlton.

I've tested BarStatus() but I'm having difficulty in understanding the concept.

plot1(barstatus);

As far as I could see, when a new bar iniciates (open price) the barstatus() plots 2 and after that plots 1 until the end of the, in this case, 5 min bar althouht this is a bit different of what EL manual says about barstatus()

Can you give me a hint on how to apply it, I'm clueless.

You've mentioned that the open price is static, but isn't the high and low of each bar also static after they've been made? For example, a bar opens and starts to rise. Then starts to come back towards the open, so that high has become static, right?

The only value that will truly become static at the end of the bar is the close, right?



Fernando

The barstatus has the values 2= closing tick of the bar, 1 = a tick within the bar, 0 = opening tick of bar.

Within your code you have some calculations based on subtracting various prices from each other based on open, high, close and low.

If your calculations are being performed on each tick within a bar then only the Open will stay static during the formation of a bar. High and Low will remain static until breached, because on each tick there is a possibility that the high or low for the bar will change. This together with the various conditions that you imposed to calculate the numerator of your percentage equation is what cause the result to become negative on some ticks.

So back to barstatus. What you could try is something along the lines of:

If barstatus(1) = 2 then begin......................... end;

Basically you bury your calculations within this if statement, so they are only calculated on the final tick of the bar.

The code that you sent to me had no zero division problem, so you should be able to use that code as it is. Amend that code to put in a print statement and print out the current time (if you can do that in Multicharts - in TS the command is computerdatetime() and you also need to format it ),
bulRng, dRng, pctBul, open, close, high, low values. You will then get a print that looks like the one I sent yesterday, where you will be able to see tick by tick the values being used in the calculation.

If you introduce the above if statement then you should get just one output on the last tick of the bar and, hopefully, eliminate your negative bars.

Charlton

 

[BigPointValue]

Hi.

I'm receiving a floating point (division by zero error) in the following formula:

(1-value1/value2)*100

How can I remove the error?
Is there another way to write the above formula?

regards
ptcman

One way that I often remove this type of error is by making the denominator very small.

I would therefore insert the following piece of code directly after calculating value2.

If Value2 = 0 then value2 = .001;

Your code would then read as follows:

{code for calculating Value2 above this...}
If Value2 = 0 then value2 =.001;
...(1-value1/value2)*100...;

Hope this helps.

BPV

 

[ptcman]

Hi.

I appreciate all the help that you are giving me but I'm starting to go crazy here.

I simply cannot open the study, plotted in the #11 post of this thread, on a intraday chart because I'm always receiving a floating point error.

The only way for that error dissapear is to use BPV option but that produce completely useless data

You said that you don't receive any error? How is that possible? In this case, the message that MC gives is a floating point error, not a divison by zero error.

My god, how can a simple formula give so much problems?

 

[Charlton]

Hi.

I appreciate all the help that you are giving me but I'm starting to go crazy here.

I simply cannot open the study, plotted in the #11 post of this thread, on a intraday chart because I'm always receiving a floating point error.

The only way for that error dissapear is to use BPV option but that produce completely useless data

You said that you don't receive any error? How is that possible? In this case, the message that MC gives is a floating point error, not a divison by zero error.

My god, how can a simple formula give so much problems?

I do not get any error, which suggests that it is an issue with data. Foating point error generally means that a calculation has generated a very small value which is non-zero.

I suggest that you comment out bits of the code, one part at a time, and also use print statements as I suggested before to print to the message log. Then you can see what each part of the code is outputting as values. Hopefully you will find some values that are extremely small and then alter the code e.g. if xxxx > 0.0000001 then begin .......

so you only do the calculation with values above a certain amount.

That is all I can suggest

Charlton

 

[BigPointValue]

Hi.

I appreciate all the help that you are giving me but I'm starting to go crazy here.

I simply cannot open the study, plotted in the #11 post of this thread, on a intraday chart because I'm always receiving a floating point error.

The only way for that error dissapear is to use BPV option but that produce completely useless data

You said that you don't receive any error? How is that possible? In this case, the message that MC gives is a floating point error, not a divison by zero error.

My god, how can a simple formula give so much problems?

Don't go CRAZY... the exercise of getting this right will cause you to become better at describing your ideas in easylanguage. Like building muscles! Data error is possible but unlikely. Apply your code to different charts to check this. You may also require a reinstall if there is other corruption in the program, but this is also not usually the case.

I note from one of your earlier posts that in Metastock you used the following code:

(1-value1/max(value2,0.0001))*100

You can convert the above metastock code into easylanguage very easily with the statement

(1-value1/maxlist(value2,0.0001)*100;

If this formula worked for you in Metastock it should now work in Tradestation unless the error lies elsewhere. If this gives bad results then you will have to talk maths...i.e. turn your division into a multiplication with a multiplicative

inverse see Multiplicative inverse - Wikipedia, the free encyclopedia

Alternatively you will have to look at the "concept" of your code and find another way to program it. This is not a bad thing as you will become more versatile. Almost all code can be programmed in different ways. It's like a puzzle. Best of luck.

BPV

 

[ptcman]

I want to thank you both for your pacience.

I'm plotting each variable and see them in realtime so I can discover where is the error.

Like BPV said, problems like these always have a good side, we learn to better understand how easy language works although the bad side is that it's to much time consuming.

Again, thank you
Regards