saving results of an array

Forums › ProRealTime English forum › ProBuilder support › saving results of an array

Viewing 12 posts - 1 through 12 (of 12 total)
  • 03/27/2024 at 10:20 AM #230550
    juld63

    Hi everyone,

    I have coded an array that calculates previous supports and resistances that are not engulfed by the highest and lowest of the following days. Of course the farther this goes back it time the better, but then of course it takes an inane amount of time to generate the the results. Is there a way to save and/or export the array thus generated today so that, when I want it to update tomorrow and the day after etc., it starts off with today’s array already generated and doesn’t need to generate it anew everyday?

    It seems to me there should be a simple way to do this but I have not found it yet. Thanks a lot for your help!

    03/27/2024 at 11:10 AM #230556
    PeterSt

    Unfortunately this is not possible. Nothing can be stored (unless manually by means of Excel exports from charts or lists) and certainly nothing can be imported.

    Now if 10000 people could provide a feature request for this, maybe someone starts to think that it is actually strange that no external storage can be used. I would have a 100+ applications for that …

    1 user thanked author for this post.
    avatar juld63
    03/27/2024 at 11:20 AM #230557
    juld63

    Hi PeterSt,

    Thanks for your reply. Is it possible to export an generated array to an excel sheet? Thanks again.

    03/27/2024 at 11:42 AM #230560
    PeterSt

    Hi again juld – … Sadly, No.
    If you look at the Lists and Charts from PRT, you may see a “Share” button, like you see one below which I used on the List of Orders. It really does not go further than that.

    In more technical terms : no I/O is possible to/from the program code.

    Notice that it *is* possible to determine the data from the past by means of scrolling back into the past on a chart – combine this with an indicator you created for the purpose, and register the Supports / Resistances / Pivots etc. hard-coded in your program code. As a kind of constants. Now your program can use that data in a fast manner without the necessity to sort it all out. But :
    You must now consider that when your program runs Live (or Demo), you must seamlessly integrate that past in constants with the future which builds up in real time. This could be quite a hurdle when you’re not into programming really. But I have the hunch you will find your ways with it ?

    03/27/2024 at 11:45 AM #230566
    PeterSt

    PS: Funny; I recalled that someone recently posted an example of my mentioned “constants” and wanted to share it with you … but it was you yourself providing that example.

    https://www.prorealcode.com/topic/generating-a-support-and-resistance-array/

    So yea, you already know … 🙂

     

    03/27/2024 at 11:50 AM #230567
    juld63

    Lol yes that was me

    I’ve found my way around in that:

    -the weeding out of obsolete supports and resistances works

    -If I display them as segments and not as lines they visually disappear when they’re obsolete.

    I’m currently trying to generate the array not only on the past six months but on the past 20 years. It’s been calculating for 3 hours already. Obviously I won’t be doing that every morning, so if I could only export/share the array as a csv file it would already be fantastic, but can you do that for an indicator? Or only for backtest results ?

    03/27/2024 at 1:52 PM #230573
    druby

    Hi…

    Been thinking about the export/import problem, even if we went with #peterST good petition idea and PRC said they were going to do it, I wouldn’t expect to see for a couple of years.

    So other than that its going to be either a compromise solution or data collection/entry.

    Currently the is no way, as mentioned to directly import/export the data in question.

    However the new PRINT() function could be used to generate a List of the data, then that could be cut/pasted to generate a  hard copy in another format .

    The image could be input to OCR to convert to editable text. Don’t know how reliable the conversion  would be!

    Then that to spreadsheet etc.

    A thought!…, if the list generated from the PRINT()  had an export feature, that would be a start! Maybe that would be an easy/quicker option to implement than a fully  export feature.

    Next manually/ simple C/C++, or similar simple program could take modified data, store in a text file,  use as input to generate a new text file listing the data as variables in PRT array format.

    Cut/paste  into its own indicator file, and then call it from another with main program code.

    When historical data is in file, just add new entries as they come along.

    I don’t think you can pass array’s via the ‘call’ instruction however if you link the barindex to the index of the array you can build the history[lookback] of a variable or load a new array over the  chart bars from bar zero.

    This call/load would only need to be done once, as the chart was build, and then just use similar as close[n] or array etc.

    Another idea that comes to mine, is to run as a backtest and the write code to enter at the valid resistance levels and exit at the support level.s. If these execute at the right levels, you could export the data from the detailed report statistics page…..

    Might have to build in some alignment offset to align data to known reference point. But entry and exit price could be at same  value as required res/ sup levels, if so, exportable.

    These are just a few ideas of top of head and untried apart from the ‘call’ bit.

    In worst case scenario, boring data entry session.

    regards druby

    Ps  #juld63 been working on a version of your res/sup code idea, will post when ironed a few bugs out for you to pass judgement.

    03/27/2024 at 2:58 PM #230581
    PeterSt

    @druby – all nice ideas !

    The OCR thing can work in general; I created it but it is of course nothing for the average person to work with. Even I myself don’t use it. Let’s say it is not decent (charts must stay in place etc.).

    The Print function IMO can’t work well because it shows 200 bars only. Of course it was the remark (even of PRT support themselves) that it is quite useless with 200 bars from of day 1 (now one full year ago), but nothing changed.
    Anyway, when set up properly, it does may require 200 records because you’d need only the highs and lows (per x time).

    It is a but crazy that we need to find these work arounds and need more time for those, than that I would make all the required solutions formally within PRT in 1/10th of the time.
    ProRealTine just likes to be old fashioned. And this gets worse every day.

    Tweaking BackTests so that they will output what is needed (in the Results form), is sure something which is doable (requires some creativity, but alas). Please keep in mind, though, that only 100 lines of output are possible in there. But of course the runs can be split into several, each covering for max 100 lines of output.

    Someone at PRT should finally look at the DDE link. IMHO it has huge capabilities, but was made a million years ago by someone who th0ught it could be done (and it could) and never was looked at again. much Much MUCH more can be done with that, if it only would be implemented with some intelligence. The way it works currently is also nice already, weren’t it that the data is presented wrongly (like not all instruments output with the same decimal character, like some are provided with a factor of 10000 too high, like you can’t preserve the (column) settings, like you can’t have a full list with all you need, which you would need because the selected lines don’t stick over to the next session).

    /End RantMode

     

    1 user thanked author for this post.
    avatar druby
    03/27/2024 at 3:03 PM #230583
    juld63

    It is somewhat disheartening that a newbie like I am would run into such limitations of PRT so quickly. Anyway my indicator is still calculating 6 hours after I started it… Did you know that after the first progress bar is full there is another progress bar? Like a boss in a video game…

    03/27/2024 at 3:46 PM #230587
    PeterSt
    juld63 wrote:

    Did you know that after the first progress bar is full there is another progress bar?

    For the Indicator calculating ? Yes. Can be a third too.
    Mind the 18 hours that PRT will run before it shuts down for the session.

     

    03/27/2024 at 3:48 PM #230588
    juld63

    Hours of fun!

    I’ve already hit the 18-hour limit more than once when backtesting. Maybe I should switch to downloading the program instead of opening it through my trading account?

    1 user thanked author for this post.
    avatar PeterSt
    03/27/2024 at 6:23 PM #230601
    PeterSt

    Downloading it ? I would say that everybody does this already, except for the new Web based version (you might be using ?). And otherwise let us know how to download it and use it really off line (for Backtesting). It does exist, but is not a normal option to chose from (or ask for), as far as I know.

    At least I now know who is holding up my own backtests. Hahaha.

  • Author
    Posts
Viewing 12 posts - 1 through 12 (of 12 total)

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
backtests not saving results when platform closed and reopened
“proscreener” and “probuilder” deliver different results with identical code
array/bubble sort in strategy doesn’t work, but works as an indicator
back testing results
backtest giving strange results
backtest vs live – different results recently??
binary “buy/sell” indicator results display: convenience or further processing
daylight saving coding… again!
different backtest results depending of atr code placement
different backtest results using different pc’s

Create your free account now and post your request to benefit from the help of the community
Register or Login