This question has probably been asked before, but I couldn't find it. I am getting an error message occasionally when I run [Optimize], but never when I put specific values into [Format]. Error is: "Error in study <study_name>: {EXCEPTION} Floating-point invalid operation". I assume this is a divide-by-zero error, but I can't find any place in my code that does that (I always use "if denominator<>0...." guard code).
My question: how can I find out where (which function, what line of code) the error occurs so that I can fix this?
How can I find where "Error in Study..." occurs?
-
- Posts: 43
- Joined: 01 Dec 2008
- Has thanked: 2 times
- Been thanked: 2 times
- Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
Hi Rob,
Some of your input values are causing this error. To find out which particular values result in the floating point error, please insert the following lines into your code:
This will allow you to find out what input values result in the floating point error when your indicator is calculated.
Some of your input values are causing this error. To find out which particular values result in the floating point error, please insert the following lines into your code:
Code: Select all
if currentbar=1 then
begin
Print(input values)
end;
-
- Posts: 43
- Joined: 01 Dec 2008
- Has thanked: 2 times
- Been thanked: 2 times
- TJ
- Posts: 7745
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2224 times
You could wish upon a star that some day (maybe 15 years from now) MC will have a debugger with break and step functions (only available during off-line mode so that at the end of the code it would get the next tick to execute the next cycle through the code). Now that would be really cool. Gee, I might actually be able to fully automate my discretionary trading system with that one.
Tip. If you want it within 10 years you need to wish upon the biggest star you can find.
Tip. If you want it within 10 years you need to wish upon the biggest star you can find.
- TJ
- Posts: 7745
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2224 times
It is all a matter of speed and actually nothing more. If one has used a print statement one has used a debugger (a very crude debugger). Everyone has had many bugs and had to use a debugger many times. I have had to work with programs with over 10,000 lines of code with management breathing down my back, no documentation at all, and a need to get it fixed in 1 hour and it is not my program. One needs a lot of speed in that situation. It can let you know that you have chosen the wrong 10,000 line program to find the bug. Speed is good.
Here is a great example. The MicroFocus cobol debugger can run at 10 speeds. From step to fast to full speed (no debugger). You just hit the number 1 to 0 for these speeds. One of the best programmers could not figure out why her program was locking up. The manager knew I took the time to learn the debugger well. He asked me to help her. I had her run her program on the debugger at full speed until she thought it was locked. We changed the speed and she could see the infinit loop right there in front of her. Total time to find it was about 5 minutes when she had spent hours before that. It is silly to not use a tool like that when it is available.
Here is a great example. The MicroFocus cobol debugger can run at 10 speeds. From step to fast to full speed (no debugger). You just hit the number 1 to 0 for these speeds. One of the best programmers could not figure out why her program was locking up. The manager knew I took the time to learn the debugger well. He asked me to help her. I had her run her program on the debugger at full speed until she thought it was locked. We changed the speed and she could see the infinit loop right there in front of her. Total time to find it was about 5 minutes when she had spent hours before that. It is silly to not use a tool like that when it is available.
So come to think of it, if TS-Support could ever get a debugger as good as the MicroFocus Cobol debugger in their product (for off line debugging) and TS does not have a debugger like that you can sure guess where the traders are going to start moving to. Of course if TS-Support can ever do that MC is already going to be an amazing program.
Last edited by bowlesj3 on 30 Jan 2009, edited 1 time in total.
- TJ
- Posts: 7745
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2224 times
+1million for even a simple debugger. I'd be happy with just a run time error that display the line number of the code where the error occurred. Would have saved me many hours of time. I too used debuggers in many languages (Fortran, C, C++, VB, VC++, java, perl; some with the Eclipse IDE), and now use FreeBasic a lot with FBIde for the IDE. Interesting to note that array bounds checking is always on - most compilers have an option to turn it off to speed things up; that would be a useful feature too.+1 on the debugger