есть же куча всяких сторонних приложений, которые с квиком соединяются и графики цен отражают. почти все они на с# написаны. Все реально но готовое купить в разы дешевле чем самому писать. Самому — это только если очень нетривиальные задачи хочется реализовать.
SergP, мой вам очень дорогой совет — воспользуйтесь готовым софтом. Даже если придётся от чего то отказаться по рюшечкам и скролбарам.
Не пишите GUI и окошки сами. Сэкономите годы жизни.
Если так уж нужен C# то есть SmartQuant (OpenQuant для розницы), RightEdge, .NET Multicharts, StockSharp (как у него с GUI не знаю) и тп
C# не совсем подходит для исследований и разработки. Код на C# «захардкожен», многословен и плохо меняется в задачах исследования-поиска. C#,Java как и C++ это языки для «один раз надёжно сделал и не трогаешь», что противоречит исследовательским задачам.
Для задач исследований намного лучше R или Jupyter Notebook(Python).
C# не совсем подходит для исследований и разработки.
Почему? Математику мы уже писали на нем, и ничего...) И даже графику товарищ сделал для он-лайна. Все двигалось, рисовалось. Единственно что, не удобно было вернуться назад — хотя бы в дневную историю.
Поэтому хотелось бы как в Квике: сдвинул, подтянул, сжал и т.п. Как я уже выше писал, тики нам не нужны. Более того, обновление данных а окне может быть раз в десятки секунд. Скорость отображения вообще не критична.
Я почему спросил про С#… Товарищ мой много чего уже знает по этому языку (я меньше), но мы оба в нем все равно любители. Математику и всю логику управления мы все равно напишем на нем. А вот чисто визуалку-графику — хотелось бы понять, можно ли не сильно отклоняясь от идеологии .net сделать функционал окна квика для графиков. Такой функционал кажется оптимальным.
SergP, по 2м причинам
1. Слишком многословный язык (для исследований и поиска)
2. Среда разработки Visual Studio не помогает исследованиям (есть режим REPL, но работает неудобно). Пришла в голову идея поправить код -> остановил софт->залез в код, долго листал, нашёл-> запустил компиляцию-> дождался запуска, подкачки данных (иногда часы, если задача серьёзная), понажимал кнопочки, подождал что получилось. Это долго. Цикл может занимать часы.
В R и юпитере — просто поправил код и всё. Данные уже в памяти. Ничего подгружать не нужно.
То есть если у вас идея оформленная (осталось захаркодить), то это не так существенно (C# отлично подойти может). А если вы исследуете, то C# неудобен (есть лучше).
ch5oh, «python без pandas деньги на ветер» — язык очень медленный, но благодаря библиотекам заточенным на векторизированную обработку данных (pandas,numpy...) с оптимизацией до уровня разных SIMD и u,v конвейеров получается быстрым (в актуальных задачах часто существенно быстрее C#). Если задача выходит за возможности таких библиотек — C#, Java и C++ как языки и платформы становятся быстрее. Но экосистема python стала настолько огромной, что остаётся всё меньше ниш в которых приходится делать что то своё низкоуровневое.
Ромирес, мне питон не понравился синтаксически. Даже R лучше ложится на мозг.
Что касается «дополнительных библиотек»… Ну, шарп тоже можно нагнуть интересными способами. Понятно, ускорение вычислений на GPU можно использовать. Некоторая поддержка SIMD была сделана в Mono. А еще есть вот такой прикол для шарпа:
Но в итоге это приводит к тому, что код надо рефакторить, чтобы он лучше соответствовал ускоренным векторным инструкциям. Мало того, что это лишняя работа, так еще и читаемость с понятностью падает (обычно).
Конечно можно. Компонентов разных полно в сети.
Я, например, использую ChartDirector.
Давно написал, году так в 2010 — 2011.
По времени заняло, примерно, неделю чтобы разобраться.
Но помните все Chart компоненты — это, как правило, только отрисовка.
А данные Вы сами должны вычислять. Chart- Компонент только рисует.
Это написано на С# Wpf. Но можно и Windows Forms использовать.
Можно это же и на Крестах написать, но уже лень заморачиваться.
От языка все это не зависит.
Успехов.
Скорее всего — да можно. Пути 2. Оба дорогие.
1. Приобретение быстрой библиотеки для отрисовки.
Например https://www.arction.com/pricing/ .
2. Написание самостоятельной библиотеки. Очень долго = дорого.
Использование managed языка для создания быстрого компонента отрисовки финансовых чартов (тики) — не самое лучшее решение (это не его сильная сторона), такие вещи лучше писать на C++. А это ещё трудозатратнее.
Всё становится несколько проще, если вы заранее решите что не будете строить тиковые графики. Но слабая сторона C# — малое количество библиотек, в т.ч. для рисования чартов (но они есть — www.dundas.com,ilnumerics.net… ). Может даже штатный MSChart компонент справится с вашими задачами.
Но работы — адское количество. С GUI самая морока.
Ромирес, я как разработчик это прекрасно понимаю) Позволяет рисовать великолепные графики, которые ни один квик не нарисует. Точнее это будет WPF, но не суть.
Dmitryy, понятно. Ну а я то про производительность движка в целом. А не про то как объекты на форме расставить (или описывать их расстановку) и event-ы соединять в MVVM. Автору же как нужно (я домысливаю и гиперболизирую) — что бы тиковый график, с 10 сложными научными функциями плавненько зуммировался, скроллировался по клику да ещё и как в Quik в риал-тайме. Обычно так хотят.
Ромирес, скорость графика зависит от реализации либы и от криворукости конечного программиста. Нельзя априорно сказать, что «C# — это всегда медленно».
На худой конец (если нужно 60 fps) можно взять что-то типа OpenTK — отрисовка будет делаться с такой скоростью с какой может рисовать OpenGL. Когда-то себе скальперский стакан на нем делал. Ясен пень все летало со скоростью света.
ch5oh, все пральна.
С появлением и широким использованием в разработке правильными программистами C# TPL (task parallel library) ограничений по скорости практически нет.
ch5oh, бывают люди кому в риалтайме на канвас хочется несколько миллиардов тиков выводить, а для кого то тиковый график это все точки (points) цен сделок по лукойлу с начала дня с барами объёмов внизу.Тут индивидуально всё. У C# область начала применимости для HFT-чартинга (из-за managed модели, packing-unpacking, сериализаций-десериализаций и плохо контролируемого GC) похуже чем у C++. Но как вы правильно заметили — все готовят по-разному.
Ромирес, хулиард тиков в монитор не влазит. Его надо сначала преобразовать к фактически наблюдаемым пикселам (естественно, это делается в памяти без бессмысленных отрисовок). Тогда на каждом обновлении графика нужно будет рисовать не более 2-5 тысяч пикселей.
Ромирес, Вообще-то не надо ничего никуда рисовать предварительно. Что данные нужно готовить — это да. А кому сейчас легко?
Большинство либ ленятся делать нормальную оптимизацию и получается стандартная ловушка: учебные примеры ведут себя замечательно. Все красиво и гламурно. Начинаешь внедрять в прод — и привет. Уже на 10к точек (свечек) — гламурный чарт за хулиард баксов вдруг загибается и перестает подавать признаки жизни.
SergP, присоединяюсь к озвученному ранее: если для себя -
воспользуйтесь готовым софтом
На своем опыте скажу — лично убил несколько лет времени неспешно конструируя и переделывая с нуля бэктестер с перспективой доработки до торгового терминала. В процессе эволюции как трейдера из проги выбрасывались одна за другой фичи, которые ранее казались ключевыми — например, прорисовка графических примитивов — чтобы наклонные линии поддержки/сопротивления на разных таймфреймах располагались одинаково, а не скакали вверх-вниз, как в МТ4, ведь как можно торговать, если не знаешь где точно находится поддержка канала (здесь уже можно смеяться); отображение маркерами новостей на графике и многое другое.
Плюс потеря вычислительного времени для нужд синхронизации графического вывода при многопоточности.
В общем, совет такой — для поиска неэффективностей изучать и использовать уже готовые решения, при нахождении таковых для написания робота использовать готовые терминалы либо писать что-то свое без GUI — он-то не нужен будет.
1. Найти закономерность (готового софта достаточно)...
2. Формализовать и попытаться закодить или использовать руками...
Не пишите GUI и окошки сами. Сэкономите годы жизни.
Если так уж нужен C# то есть SmartQuant (OpenQuant для розницы), RightEdge, .NET Multicharts, StockSharp (как у него с GUI не знаю) и тп
C# не совсем подходит для исследований и разработки. Код на C# «захардкожен», многословен и плохо меняется в задачах исследования-поиска. C#,Java как и C++ это языки для «один раз надёжно сделал и не трогаешь», что противоречит исследовательским задачам.
Для задач исследований намного лучше R или Jupyter Notebook(Python).
Поэтому хотелось бы как в Квике: сдвинул, подтянул, сжал и т.п. Как я уже выше писал, тики нам не нужны. Более того, обновление данных а окне может быть раз в десятки секунд. Скорость отображения вообще не критична.
Я почему спросил про С#… Товарищ мой много чего уже знает по этому языку (я меньше), но мы оба в нем все равно любители. Математику и всю логику управления мы все равно напишем на нем. А вот чисто визуалку-графику — хотелось бы понять, можно ли не сильно отклоняясь от идеологии .net сделать функционал окна квика для графиков. Такой функционал кажется оптимальным.
1. Слишком многословный язык (для исследований и поиска)
2. Среда разработки Visual Studio не помогает исследованиям (есть режим REPL, но работает неудобно). Пришла в голову идея поправить код -> остановил софт->залез в код, долго листал, нашёл-> запустил компиляцию-> дождался запуска, подкачки данных (иногда часы, если задача серьёзная), понажимал кнопочки, подождал что получилось. Это долго. Цикл может занимать часы.
В R и юпитере — просто поправил код и всё. Данные уже в памяти. Ничего подгружать не нужно.
То есть если у вас идея оформленная (осталось захаркодить), то это не так существенно (C# отлично подойти может). А если вы исследуете, то C# неудобен (есть лучше).
Ромирес, или в том же ТСЛаб накидали скрипт — прогнали на истории — поправили — снова прогнали.
Писать страты на чистом C# и вправду тяжко.
Но R — ужасно тормозной. Питон, наверное, тоже.
Ромирес, мне питон не понравился синтаксически. Даже R лучше ложится на мозг.
Что касается «дополнительных библиотек»… Ну, шарп тоже можно нагнуть интересными способами. Понятно, ускорение вычислений на GPU можно использовать. Некоторая поддержка SIMD была сделана в Mono. А еще есть вот такой прикол для шарпа:
https://habr.com/post/239619/
Но в итоге это приводит к тому, что код надо рефакторить, чтобы он лучше соответствовал ускоренным векторным инструкциям. Мало того, что это лишняя работа, так еще и читаемость с понятностью падает (обычно).
Я, например, использую ChartDirector.
Давно написал, году так в 2010 — 2011.
По времени заняло, примерно, неделю чтобы разобраться.
Но помните все Chart компоненты — это, как правило, только отрисовка.
А данные Вы сами должны вычислять. Chart- Компонент только рисует.
Это написано на С# Wpf. Но можно и Windows Forms использовать.
Можно это же и на Крестах написать, но уже лень заморачиваться.
От языка все это не зависит.
Успехов.
lurkmore.to/C%2B%2B
www.amazon.com/Practical-Charts-Graphics-Jack-Xu/dp/097937250X
Кстати, у этого же автора есть еще пара книг по этой теме, поищите в Интернете по фамилии. Я уже забыл как они называются.
А если уж совсем хотите до глубин разобраться в вопросе и написать все на плюсах и Win32 то это знаменитая книжка Фень Юаня:
www.twirpx.com/file/162840/
Но лучше все таки поискать готовые Chart-компоненты.
Желаю успехов.
1. Приобретение быстрой библиотеки для отрисовки.
Например https://www.arction.com/pricing/ .
2. Написание самостоятельной библиотеки. Очень долго = дорого.
Использование managed языка для создания быстрого компонента отрисовки финансовых чартов (тики) — не самое лучшее решение (это не его сильная сторона), такие вещи лучше писать на C++. А это ещё трудозатратнее.
Всё становится несколько проще, если вы заранее решите что не будете строить тиковые графики. Но слабая сторона C# — малое количество библиотек, в т.ч. для рисования чартов (но они есть — www.dundas.com, ilnumerics.net… ). Может даже штатный MSChart компонент справится с вашими задачами.
Но работы — адское количество. С GUI самая морока.
Ромирес, скорость графика зависит от реализации либы и от криворукости конечного программиста. Нельзя априорно сказать, что «C# — это всегда медленно».
На худой конец (если нужно 60 fps) можно взять что-то типа OpenTK — отрисовка будет делаться с такой скоростью с какой может рисовать OpenGL. Когда-то себе скальперский стакан на нем делал. Ясен пень все летало со скоростью света.
С появлением и широким использованием в разработке правильными программистами C# TPL (task parallel library) ограничений по скорости практически нет.
Ромирес, арктион всего от 2 килобаксов в год стоит.
А так, наверное, хорошая либа. =)
Ромирес, хулиард тиков в монитор не влазит. Его надо сначала преобразовать к фактически наблюдаемым пикселам (естественно, это делается в памяти без бессмысленных отрисовок). Тогда на каждом обновлении графика нужно будет рисовать не более 2-5 тысяч пикселей.
Ромирес, Вообще-то не надо ничего никуда рисовать предварительно. Что данные нужно готовить — это да. А кому сейчас легко?
Большинство либ ленятся делать нормальную оптимизацию и получается стандартная ловушка: учебные примеры ведут себя замечательно. Все красиво и гламурно. Начинаешь внедрять в прод — и привет. Уже на 10к точек (свечек) — гламурный чарт за хулиард баксов вдруг загибается и перестает подавать признаки жизни.
На своем опыте скажу — лично убил несколько лет времени неспешно конструируя и переделывая с нуля бэктестер с перспективой доработки до торгового терминала. В процессе эволюции как трейдера из проги выбрасывались одна за другой фичи, которые ранее казались ключевыми — например, прорисовка графических примитивов — чтобы наклонные линии поддержки/сопротивления на разных таймфреймах располагались одинаково, а не скакали вверх-вниз, как в МТ4, ведь как можно торговать, если не знаешь где точно находится поддержка канала (здесь уже можно смеяться); отображение маркерами новостей на графике и многое другое.
Плюс потеря вычислительного времени для нужд синхронизации графического вывода при многопоточности.
В общем, совет такой — для поиска неэффективностей изучать и использовать уже готовые решения, при нахождении таковых для написания робота использовать готовые терминалы либо писать что-то свое без GUI — он-то не нужен будет.
ZedGraph хорашая либа (бесплатная и даже исходники можно найти).
Либо подсоединить к квику ТСЛаб. Там будут любые графики с возможностями зум/скролл/смена вида отображения/объемный анализ/покер с девушками.
Только зарегистрированные и авторизованные пользователи могут оставлять ответы.
Залогиниться
Зарегистрироваться