Как лучше искать среднее, если мы знаем только 2 последних значения - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Почему ? На мой взгляд - если получается экспотенциальное, то среднее тем более получается. А если не получается обычного среднего - то и экспотенциального не получить.
Впрочем - выше уже правильно написали, надо хранить не все значения, а только сумму, и количество.
Почему "бред" ???
Сколько вам значений надо копить-то ? Ну не больше же пары сотен - хранить их что, бред ???
Зная только два значения - нельзя делать никакие предположения о предыдущих значениях в силу нестационарности рынка.
А если сделок тысячи, зачем лишний пересчет... достаточно считать только послендие, и лучше вообще ничего не хранить.. Но я мб не совсем правильно сформулировал вопрос, мне нужно считать именно без массивов и перебора всех сделок, вариант со статическими переменными очень подошел
Это не для рынка, для проскальзывания, а они будут стремиться к среднему какому-то всегда
Потому-что для простой средней надо располагать значением которое было n баров тому назад.
А для экспотенциальной - нет ???
Вот данные: 1,2,3,4 - четыре отсчета. Если n = 5, то мы никак не посчитаем ни обычную среднюю, не экспотенциальную.
А если сделок тысячи, зачем лишний пересчет... достаточно считать только послендие, и лучше вообще ничего не хранить.. Но я мб не совсем правильно сформулировал вопрос, мне нужно считать именно без массивов и перебора всех сделок, вариант со статическими переменными очень подошел
Это не для рынка, для проскальзывания, а они будут стремиться к среднему какому-то всегда
Мне кажется, вы не на то направляете свои силы. Образно говоря, "дрожа над каплей - вы рискуете расплескать все остальное". Тем боле, что "вариант со статическими переменными" - вы же их тоже храните...
Не говоря уж о том, что это весьма опасный способ программирования. Подобные переменные либо надо делать на внешнем уровне - чтобы они были доступны из любого места, либо вобще выносить в члены класса. Так, как тут предложено - переменная объявляется внутри мелкой функции, и потом, если вдруг эта функция будет изменена - переменная исчезнет. Кроме того, ее значение может пересекаться с другими переменными в других местах программы с такими же названиями. Я бы крайне не рекомендовал так делать. Принцип в коде правильный, но реализация - опасная.
С другой стороны - при простых вычислениях - и так сойдет.
Мне кажется, вы не на то направляете свои силы. Образно говоря, "дрожа над каплей - вы рискуете расплескать все остальное". Тем боле, что "вариант со статическими переменными" - вы же их тоже храните...
Не говоря уж о том, что это весьма опасный способ программирования. Подобные переменные либо надо делать на внешнем уровне - чтобы они были доступны из любого места, либо вобще выносить в члены класса. Так, как тут предложено - переменная объявляется внутри мелкой функции, и потом, если вдруг эта функция будет изменена - переменная исчезнет. Кроме того, ее значение может пересекаться с другими переменными в других местах программы с такими же названиями. Я бы крайне не рекомендовал так делать. Принцип в коде правильный, но реализация - опасная.
С другой стороны - при простых вычислениях - и так сойдет.
ну я как бы умею пользоваться компилятором, имена нигде не пересекаются, и ф-я строго по назначению используется :) Статическую переменную потом легко сохранить в глобальные, затем загрузить при перезагрузке бота, а с массивами так не сделаешь, например
Создавать портянки с классами на mql не очень удобно, мне так кажется.. использую их только в случае крайней необходимости.. процедурное программирование рулит )
Мне кажется, вы не на то направляете свои силы. Образно говоря, "дрожа над каплей - вы рискуете расплескать все остальное". Тем боле, что "вариант со статическими переменными" - вы же их тоже храните...
Не говоря уж о том, что это весьма опасный способ программирования. Подобные переменные либо надо делать на внешнем уровне - чтобы они были доступны из любого места, либо вобще выносить в члены класса. Так, как тут предложено - переменная объявляется внутри мелкой функции, и потом, если вдруг эта функция будет изменена - переменная исчезнет. Кроме того, ее значение может пересекаться с другими переменными в других местах программы с такими же названиями. Я бы крайне не рекомендовал так делать. Принцип в коде правильный, но реализация - опасная.
С другой стороны - при простых вычислениях - и так сойдет.
Да, без проблем, тогда оптимизирую прошлый вариант ;)
{
_SpecMA_Count = 0;
_SpecMA_Summ = 0;
return(INIT_SUCCEEDED);
}
int _SpecMA_Count = 0;
double _SpecMA_Summ = 0;
double GetSpecMA(const double new_value)
{
_SpecMA_Summ += new_value;
++_SpecMA_Count;
return _SpecMA_Summ / _SpecMA_Count;
}
Но я больше склоняюсь к мнению: "Преждевременная оптимизация — корень всех зол."
Хотя, наверное, прошлый вариант и есть оптимизация, но для понимания принципа он более удобный, а этот вариант более объемный, но зато более безопасный. В любом случае, был важен принцип, чем фактический код.
А для экспотенциальной - нет ???
Вот данные: 1,2,3,4 - четыре отсчета. Если n = 5, то мы никак не посчитаем ни обычную среднюю, не экспотенциальную.
Вы не так поняли вопрос темы. Не история имеет длину 2 бара, а в каждый момент (на каждом баре) имеется доступ только к двум значениям.
Аааа... Ну, если мы имеем доступ к двум средним и двум барам - тогда может быть...
Хотя, мне кажется, что и там разницы не будет, но проверять лень.
Да, без проблем, тогда оптимизирую прошлый вариант ;)
Но я больше склоняюсь к мнению: "Преждевременная оптимизация — корень всех зол."
Вот так мне кажется - более правильно. Переменные объявляются во внешнем блоке, а значит, ситуация, когда мы поменяем блоки, и объявление переменных исчезнет - исключен.
Создавать портянки с классами на mql не очень удобно, мне так кажется.. использую их только в случае крайней необходимости.. процедурное программирование рулит )
Ну, если надо по-быстрому что-то "написать на коленке" - то да.
Но, если писать регулярно - то, боюсь, ООП все же более разумно. Библиотеки функций лично мне не нравятся своей "разрозненностью". Классы - позволяют инкапсулировать всю "черновую работу", предоставляя "чистый интерфейс". А в случае библиотек - обеспечить связность схожих процедур значительно сложнее.