Consult: is there any limit for number of lines in a code?

[pstrusi]

Hi Ninjas,

Maybe a dumb question, but I'd like to know if there's a limit for a code without having memory-issues or similar problems when I run it, whether number of lines or total size. I've tested code with 10.000, 20.000 and 30.000 lines ( about 1000k ) without any trouble.

Thanks

[NinjaTrader_Bertrand]

pstrusi, I believe you would hit a limit shy over 65000 lines then.

[pstrusi]

Thanks Bertrand, I thought that this could happen, so I must study another approach.

Best regards

[NinjaTrader_Bertrand]

You could spread out to partial classes as well, for example please see -

http://www.ninjatrader.com/support/helpGuides/nt7/user_defined_methods.htm?zoom_highlightsub=user%2Bdefined

[pstrusi]

Hi Bertrand, I've tested a code of 100.000 lines in NT and it performed as you predicted, it had big memory-issue, so let me briefly the problem in order to get some tips from you, if possible, because I´m stuck here and maybe it is easy to solve it.

I have 10 indicators, each one with 3 possible results: buy, sell, or null. If you want to combine the ten indicators at the same time it´d be: 3 ^10 or 59.049 different cases. What I try to do if optimize an algo in NT, the results export to excel, working with those results and "sending back" to fill a final code. I could do this when it was with 8 indicators, but now, with 10 indicators, I hit certain limitations in NT.

I'm sure that must be several easier ways to do what I want.
1. Maybe creating a database which could create and fill for each one of those 59.049 combinations?
2. A simpler way to fill a variable with results from combination of 10 boolean variables and recalling it when needed.

Any hint would be appreciated highly.

Best regards

[Harry]

I would probably create 10 IntSeries() objects and store one of the values -1, 0 , 1 representing a short setup, no setup or a long setup for every bar and for each of the indicators. You can then access that information and perform calculations, whatever you need.

[pstrusi]

Thanks Harry for your suggestion. Despite I've decided to solve this problem, working with 3^8 cases, I´ll tell you what my problem was working with 3^10 cases:
I set 3^10 different results and exporting to excel for additional work for each one of them, each one of these 59.049 cases has a final "info" that I must use as an input into my definite code, reading it from excel into NT. In that situation, with my basic programming knowledge, I must set 3 or 4 lines of code to do it, which if 59.049 x 4 = 236.196 lines, and thus difficult to work with.

Since I decided to work with less lines I won't be worried any longer about this matter.

Thanks again and best regards

[Harry]

Thanks Harry for your suggestion. Despite I've decided to solve this problem, working with 3^8 cases, I´ll tell you what my problem was working with 3^10 cases:
I set 3^10 different results and exporting to excel for additional work for each one of them, each one of these 59.049 cases has a final "info" that I must use as an input into my definite code, reading it from excel into NT. In that situation, with my basic programming knowledge, I must set 3 or 4 lines of code to do it, which if 59.049 x 4 = 236.196 lines, and thus difficult to work with.

Since I decided to work with less lines I won't be worried any longer about this matter.

Thanks again and best regards

There is no need to export anything to Excel and to reimport it. Everything that Excel does can be coded with C#.

[pstrusi]

Hi Bertrand, just a non priority question:

Regarding to a maximum lines in a NT code:

if I had the following pc featrures:
- Chip Intel core i5-3317U @ 1.70GHZ with 4 GB of RAM
- Windows 7 64 bits
- NT 7.0.1000.14

Would I have the chance to manage a code with 114.000 lines, or the 65.000 limit is pretty high already?

If I found the way to optimize and assigning values to each one of 15^3 simultaneous combinations I won't have this problem. Obviously I must dive into a more high level of programming.

Thanks

[Harry]

Let us assume that you have a 15 min chart with a lookback of 60 days, or a 1 minute chart with a lookback of three days. The first chart would have approximately 3900 bars, the second one 4100 bars. Therefore I will give my answer for a chart with 4,000 bars.

The memory requirement for a variable of type double is 8 Byte.

Your RAM requirement with 116,000 lines would therefore be at least

116,000 * 4,000 * 8 Byte = 3.7 GByte

which is beyond the capacity of your PC. If you want to display your lines on a high definition chart with an extended lookback period, your memory requirement may quickly jump to reach 100 GByte.

I would not even consider to code anything with more than 1,000 lines, as this is not necessary in most cases.

[pstrusi]

Thanks for your comment

[koganam]

Hi Bertrand, just a non priority question:

Regarding to a maximum lines in a NT code:

if I had the following pc featrures:
- Chip Intel core i5-3317U @ 1.70GHZ with 4 GB of RAM
- Windows 7 64 bits
- NT 7.0.1000.14

Would I have the chance to manage a code with 114.000 lines, or the 65.000 limit is pretty high already?

If I found the way to optimize and assigning values to each one of 15^3 simultaneous combinations I won't have this problem. Obviously I must dive into a more high level of programming.

Thanks

I agree with Harry. Even though one can use Virtual Memory to handle large memory structures, I still think that you should be able to code what you want more efficiently.

After all, at any given time, you only need to access and process the data that fits some very narrow criteria, so I wonder why you would need to keep such a large Array/Dictionary/List: it should be possible to code what you want in a more efficient way, to use only that data which is needed at any time.

Regardless, if you must do it as you are doing, you will need a lot of fast virtual memory. Consider buying an SSD and placing the Windows PageFile on it.

Just my $0.02.

[pstrusi]

Thanks for the input. I'll have to see how to code efficiently that massive simultaneous variable combinations.

Regards,