With usability and efficiency in mind: what is an optimal number of buffers in a scalable indicator? - page 2

To add comments, please log in or register
Stanislav Korotky
31617
Stanislav Korotky  
Alain Verleyen:

You can use a lot of buffers just for calculations, they don't have to be available to human user. A customer already asked what was the limit, that's why I know it :-)

The question is about visible buffers to be more precise. Internals are out of consideration. I'm interested in end-user point of view.

Stanislav Korotky
31617
Stanislav Korotky  
Alain Verleyen:

What I mean is you maintain 1 code and you compile and sell X indicators.

These are not concrete examples, why a multicurrency or multiperiod would need a dynamic number of buffers ?

I still don't see any advantages to such approach so I would be happy if you could enlighten me. A general approach is always consuming more resource as needed, and is most of the time slower.

I really can't answer to your poll without knowing exactly what you mean.

That's strange. Suppose you have an indicator caclulating different MAs in its buffers. Do you suggest to publish as many indicators as buffers requested by customers? Every time as Alice or Bob come to me saying she wants 5 and he wants 10 buffers I should create new indicators with the same algoritm but specific number of buffers? If so, it seems inefficient.

If you do not use dynamic number of buffers we return to the previous paragraph - 1 product for specific number of buffers. I consider this incorrect approach.

Currently you can't change number dynamically, you can only set maximum number and allow user to use any of them. In the case of multicurrency indicator - how would you code an indicator which accepts an arbitrary list of work symbols? Just imagine you need to code an indicator with WPR for an arbitrary list of symbols.

It's a bit difficult for me to explain what seems obvious. But I'm ready to answer any question.

Alain Verleyen
39027
Alain Verleyen  
Stanislav Korotky:

The question is about visible buffers to be more precise. Internals are out of consideration. I'm interested in end-user point of view.

So nice.

End-user are not present on the forum.

Stanislav Korotky
31617
Stanislav Korotky  
Alain Verleyen:

So nice.

End-user are not present on the forum.

Nevertheless, all people on the forum should have strong view on their end-user point of view ;-). Also I don't know more MT-oriented forum.

12
To add comments, please log in or register