Canvas - это круто! - страница 106
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Rust сам по себе весьма хорош как язык. Но по поводу создания и поддержки в рабочем состоянии библиотек (уровня Boost.Beast из С++) возникло ощущение, что в мире раста этим занимаются полтора энтузиаста. А это весьма чревато.
«Мы приняли Rust ради безопасности и видим 1000-кратное снижение плотности memory-safety уязвимостей по сравнению с C и C++ кодом Android. Но самым большим сюрпризом стало влияние Rust на доставку ПО. Rust-изменения имеют в 4 раза меньший rollback rate и тратят на 25% меньше времени в code review — безопасный путь оказался ещё и быстрым» — это слова Джеффа Вандер Стопа из Google.
https://blog.google/security/rust-in-android-move-fast-fix-things/
ощущение ошибочное. Новый код в Linux и Android пишется на Rust, а критичные по безопасности модули в Android точечно переписываются
«Мы приняли Rust ради безопасности и видим 1000-кратное снижение плотности memory-safety уязвимостей по сравнению с C и C++ кодом Android. Но самым большим сюрпризом стало влияние Rust на доставку ПО. Rust-изменения имеют в 4 раза меньший rollback rate и тратят на 25% меньше времени в code review — безопасный путь оказался ещё и быстрым» — это слова Джеффа Вандер Стопа из Google.
Возможно вы и правы. ИИ пишет что мне нужны tokio и reqwest, которые "абсолютно защищены от проблемы выгорания разработчиков".
Тем не менее, пока подожду записываться в растоманы)
Увы, на стандартных таймфреймах этого сделать нельзя из-за разной плотности времени.
А в данной задаче это и не нужно. М1 - это основной ТФ в МТ5. Остальные ТФ являются синтетическими от него.
В МТ5 вы загружаете историю только М1(!!!), остальные ТФ рассчитываются в терминале от М1. В МТ4 загружаются все ТФ.
Не важно, что интуитивно понятно трейдеру. Главное, чтобы советник был бесконфликтным. А M1, M4, M16, M64, M256, M1024, M4096 дают эту бесконфликтность за счет одинаковой равномерности плотности времени на разных масштабах.
Да, я понимаю, и именно поэтому я назвал этот метод элегантным. Но только с точки зрения разработчика. А не с точки зрения пользователя, по моему скромному мнению.
У меня была идея увеличить масштаб свечей, чтобы показать другие стандартные таймфреймы, сохранив при этом состояние пользовательской отрисовки, индикаторов и т.д. Проще говоря, при увеличении масштаба вы видите свои оригинальные индикаторы и рисунки на других стандартных таймфреймах. Вы правильно заметили, что стандартные таймфреймы не позволяют этого сделать из-за уникальной плотности времени, и это именно то, что я пытаюсь решить. Я думаю, что чистый ZUI не будет работать с этим, мне, вероятно, нужна золотая середина, больше похожая на переход, чем на непрерывное масштабирование, что делает это очень реалистичным, но философски другим...
Это ощущение ошибочно. Новый код в Linux и Android пишется на Rust, а критически важные для безопасности модули в Android точечно переписываются
"Мы приняли Rust ради безопасности и увидели 1000-кратное снижение плотности уязвимостей безопасности памяти по сравнению с кодом Android на C и C++. Но самым большим сюрпризом стало влияние Rust на доставку программного обеспечения. Изменения на Rust имеют в 4 раза меньший процент откатов и на 25 % меньше времени тратится на проверку кода - безопасный путь был также быстрым" - это слова Джеффа Вандер Ступа из Google.
https://blog.google/security/rust-in-android-move-fast-fix-things/
Да, я понимаю, и именно поэтому я назвал этот метод элегантным. Но только с точки зрения разработчика. А не с точки зрения пользователя, по моему скромному мнению.
У меня была идея увеличить масштаб свечей, чтобы показать другие стандартные таймфреймы, сохранив при этом состояние пользовательской отрисовки, индикаторов и т.д. Проще говоря, при увеличении масштаба вы видите свои оригинальные индикаторы и рисунки на других стандартных таймфреймах. Вы правильно заметили, что стандартные таймфреймы не позволяют этого сделать из-за уникальной плотности времени, и это именно то, что я пытаюсь решить. Я думаю, что чистый ZUI не будет работать с этим, мне, вероятно, нужна золотая середина, больше похожая на переход, чем на непрерывное масштабирование, что делает это очень реалистичным, но философски другим...
это более простая задача, чем та, что я реализовал в плавном динамическом таймфрейме. Я даже где-то видел нечто подобное. Или даже сам реализовал нечто подобное.