How to use Array variables

Forums ProRealTime English forum ProBuilder support How to use Array variables

  • This topic has 27 replies, 5 voices, and was last updated 1 year ago by avatarJS.
Viewing 13 posts - 16 through 28 (of 28 total)
  • #197031
    JS

    You can store all data, including tick data, in an array and with this you can make calculations such as subtraction, addition, average, etc…

    #197033

    You can store all data, including tick data, in an array

    Yes. And now from within a bar. If you can do that, please show that. It would be the most interesting.
    And the answer is not : then make a smaller timeframe (you tried that twice already – haha).

    #197034

    Something else I thought of after my post early this morning : it is ridiculous that this is not possible. The data DOES pass there (Indicator code). We can do all with it, except for storing it. Knowing a but about programming, it is beyond me why this is prohibited. Indicator code (or the parser of it) must be a veeeery strange animal.

    #197035
    JS

    Tickdata is data from within a bar…(haha)

    #197036

    If it would be a bar with 1 tick you can do it. But again you made the TF smaller first.

    #197037

    JS, I don’t think you understood the casus;

    Store all the values you see passing from an indicator, in an array. Watch the indicator moving in its current (rightmost) bar. Up-down-up. That would be three values. Store those …
    (please – haha)

    #197038

    The more simple version of it (but tells better what the issue is) : give back the whatever-average of those 3 values you see passing.
    I think it is impossible. But it would be infinitely useful.

    #197040
    JS

    @PeterSt

    Every time it turns out that you have no idea how it works, you only provide (incomprehensible) comments and when you come up with something yourself, it makes no sense at all.

    Sorry…

     

    #197049

    Though I think we are flogging a dead horse on this question, I beginning to understand the situation a bit better.

    Market data is made up of several data feeds, this gives the ticker name; exchange; OHLCV, bid/ask, timestamps and other parameters. PRT has access to at least some if not all of these feeds at the package level.

    But at the coding level it seems access is limited to the OHLCV and a timestamp.

    Now the tick time frame is at the highest resolution of this data available and all other time frames seam to be  calculated from it. Drawing a parallel with calculating a average….

    The candles on time frame are just the ‘SUM’ of the ticks that fall in the candle’s time period. So if you have only got access to the result of that sum, like an average, you can’t interrogate it to find the values that made it up.

    Also when you see the current candle move, what your seeing is the current sum for that candle,  this sum is increased when new ticks come in, but when it closes its just the dumb value of a sum of ticks it always was.

    Regarding real time, all time, time frames are only updated on close/time period  with the tick updated per tick not in a time period. On the code side you can do quite a bit of processing between open and close of a candle but from the above, how the time frames are setup an built restricts the data available to be processed and manipulated. This may also explain why the TIMEFRAME instruction only do time and not ticks.

    Though on a technical level it may not be done this way, the dress seems to fit. Another wrong path in the maze mapped out.

    I’ll leave with this, ‘Do nothing and your potential is limitless, do everything to your potential and your limited!’

    No indeed… not this way!

     

    #197051

    … you can’t interrogate it to find the values that made it up. …

    Actually you can, using the multiple time frame support and set it to the lowest timeframe available (1 second, as ticks cannot be used).

    There are some features that would be highly appreciated:

    • using non-time based charts (ticks, rengo, etc…) in strategies
    • adding more data types (mainly alphanumeric)

    but that would imply changing the logic of the whole platform and rewrite it from scratch. I don’t know if this will ever be possible… mainly due to time and costs.

     

     

    1 user thanked author for this post.
    #197063

    Thanks for the clarification Rob, wasn’t meaning to imply that you couldn’t interrogate values of lower time frames from a higher one. But that, the platform logic you mentioned, from my observations concur, and probably that’s why the TIMEFRAME instruction doesn’t go to the tick level, so we could interrogate that levels data.

    I’m running on philosophy that,  ‘you don’t know the door’s locked until you try to open it!’

    Regards

    #197064

    Every time it turns out that you have no idea how it works,

     

    It is always interesting to see how people first change the question and next think they have the answer correct (and bash on top of that).
    Did you ever read the (repeated) question from the OP ?

    Now, still waiting for your solution. I still think it is impossible, thus no need to get in some kind of defense mode.
    I hope we can behave somewhat.

    #197068
    JS

    Look who’s talking…

Viewing 13 posts - 16 through 28 (of 28 total)

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