Интересная тема про запуск в клауд сеть огромных задач - иногда денег не хватает - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Скорее всего он просто не рассчитал нагрузку, сделав очень тормозного эксперта.
Конструктивчику можно?
У меня предложение: при запуске оптимизации на облаке рассчитывать ориентировочную стоимость всего цикла оптимизации (если точную стоимость вычислить заранее невозможно) и
1) Отображать (на видном месте!) эту цифру в оптимизаторе.
2. В случае если она близка снизу или перекрывает баланс юзера на счёте - немедленно (задолго до приближения баланса к нулю) выдавать юзеру предупреждение о нехватке средств для завершения оптимизации.
--
Множество потенциальных проблем будет исчерпано в зародыше. И к тому же всем станет реально удобнее пользоваться сервисом.
Ещё лучше - создать возможность заранее (до вывода цикла оптимизации на клауд!) оценить стоимость оптимизации в облаке данного конкретного эксперта (путём замера нагрузки на локальной машине пользователя). Возможно для этого понадобится что-то вроде предварительной калибровки (запуска тестовой калибровочной задачи на машине юзера), но это мне кажется не проблема : желающие заранее знать стоимость оптимизации своей задачки в облаке с удовольствием откалибруют свою машину.
Конструктивчику можно?
У меня предложение: при запуске оптимизации на облаке рассчитывать ориентировочную стоимость всего цикла оптимизации (если точную стоимость вычислить заранее невозможно) и
1) Отображать (на видном месте!) эту цифру в оптимизаторе.
2. В случае если она близка снизу или перекрывает баланс юзера на счёте - немедленно (задолго до приближения баланса к нулю) выдавать юзеру предупреждение о нехватке средств для завершения оптимизации.
Я уже где то в ветке про облако предлагал рассчитывать ориентировочную общую стоимость расчета задачи, и даже предложил алгоритм. С ходу не найду, поищу - покажу ссылку.
Мы не можем на основании одного-двух-трёх проходов делать выводы, даже ориентировочные, о предстоящей ресурсоёмкости тестирования.
Мы собираем статистику о временах проходов для определения тормозных агентов. Но всё очень сильно зависит от набора параметров. С одним набором эксперт моментально сливает, с другим набором вообще не торгует, с третьим набором торгует долго и счастливо. И как достоверно определить среднее время?
И как достоверно определить среднее время?
Мы не можем на основании одного-двух-трёх проходов делать выводы, даже ориентировочные, о предстоящей ресурсоёмкости тестирования.
Мы собираем статистику о временах проходов для определения тормозных агентов. Но всё очень сильно зависит от набора параметров. С одним набором эксперт моментально сливает, с другим набором вообще не торгует, с третьим набором торгует долго и счастливо. И как достоверно определить среднее время?
Может быть на основании только тех проходов, которые встречаются чаще? И значение стоимости будет плавающим (~приблизительным), также, как и время оптимизации.
Это так, мысли вслух. Я если честно даже ещё и не попробовал воспользоваться облаком (жутко стыдно). )))
Мы не можем на основании одного-двух-трёх проходов делать выводы, даже ориентировочные, о предстоящей ресурсоёмкости тестирования.
Мы собираем статистику о временах проходов для определения тормозных агентов. Но всё очень сильно зависит от набора параметров. С одним набором эксперт моментально сливает, с другим набором вообще не торгует, с третьим набором торгует долго и счастливо. И как достоверно определить среднее время?
Мы не можем на основании одного-двух-трёх проходов делать выводы, даже ориентировочные, о предстоящей ресурсоёмкости тестирования.
Мы собираем статистику о временах проходов для определения тормозных агентов. Но всё очень сильно зависит от набора параметров. С одним набором эксперт моментально сливает, с другим набором вообще не торгует, с третьим набором торгует долго и счастливо. И как достоверно определить среднее время?
В формуле такие нюансы были учтены - ориентировочная стоимость получалась довольно достоверной.
Так и не смог найти свой пост, там и екселевский файл был приложен с примером расчета.
https://www.mql5.com/ru/forum/4927/page87#comment_132318
и
https://www.mql5.com/ru/forum/4927/page88#comment_132323
Я уже где то в ветке про облако предлагал рассчитывать ориентировочную общую стоимость расчета задачи, и даже предложил алгоритм. С ходу не найду, поищу - покажу ссылку.
Очень грубую оценку получить легко, если знать количество проходов. Методика есть по ссылке данной Ренатом. С генетикой предсказать конечное количество проходов будет сложно, а вот для полного перебора такой способ получения грубой оценки вполне подходит. Если пример немного упростить, то выглядит так:
100 000 passes * 140 seconds = 3 888 hours
3 888 hours * 0.01 credit = 38.88 сredits. (if PR = 100)
Погрешность конечно не маленькая (38.88 оценка и 30 фактически), но вполне ожидаемая и приемлемая с учетом массы упрощений.
Мы не можем на основании одного-двух-трёх проходов делать выводы, даже ориентировочные, о предстоящей ресурсоёмкости тестирования.
Мы собираем статистику о временах проходов для определения тормозных агентов. Но всё очень сильно зависит от набора параметров. С одним набором эксперт моментально сливает, с другим набором вообще не торгует, с третьим набором торгует долго и счастливо. И как достоверно определить среднее время?
Могу даже дровишек подбросить: в начале генетической оптимизации сливных и "не торгующих" пассов статистически будет существенно больше, к концу будут преобладать счастливые и долгие пассы. Этот фактор дополнительно усложняет задачку.
Но это нормальная ситуация. В смысле неизбежная. По ходу оптимизации статистическая оценка будет улучшаться.
Нужно выжать максимум возможной достоверности - и не более.