• 11 января 2019, 00:19
    • |
    • SergP
  • Еще

Можно ли на С# сделать окна для графиков с тем же функционалом что и в Квике? Я о прокрутке гор/верт, сжатии/растяжке...

★3
ВНИМАНИЕ! КОММЕНТАРИИ ПЕРВОГО УРОВНЯ В ВОПРОСАХ УПОРЯДОЧИВАЮТСЯ ПО ЧИСЛУ ПЛЮСИКОВ, А НЕ ПО ВРЕМЕНИ ПУБЛИКАЦИИ.
на C# можно все что угодно сделать
есть же куча всяких  сторонних приложений, которые с квиком соединяются и графики цен отражают. почти все они на с# написаны. Все реально но готовое купить в разы дешевле чем самому писать. Самому — это только если очень нетривиальные задачи хочется реализовать.

avatar
Андрейка, не знаю, что вы называете нетривиальностью… Нужна свобода действий над данными в их обработке и удобном отображении.
avatar
SergP, если для себя, то нет смысла и это абсолютно однозначно. Если коммерческий проект - it depends…
avatar
старый трейдер, для себя.
avatar
SergP, этапы:
1. Найти закономерность (готового софта достаточно)...
2. Формализовать и попытаться закодить или использовать руками...

avatar
мотивирующее: чем труднее найти и формализовать, тем больше шансов, что будет жить постоянно (есть такие).
avatar
старый трейдер, это вы про идеи (закономерности)?
avatar
SergP, да.
avatar
SergP, мой вам очень дорогой совет — воспользуйтесь готовым софтом. Даже если придётся от чего то отказаться по рюшечкам и скролбарам.

Не пишите GUI и окошки сами. Сэкономите годы жизни.
Если так уж нужен C# то есть SmartQuant (OpenQuant для розницы), RightEdge, .NET Multicharts, StockSharp (как у него с GUI не знаю) и тп

C# не совсем подходит  для исследований и разработки. Код на C# «захардкожен», многословен и плохо меняется в задачах исследования-поиска. C#,Java как и C++ это языки для «один раз надёжно сделал и не трогаешь», что противоречит исследовательским задачам.

Для задач исследований намного лучше R или Jupyter Notebook(Python).
avatar
Ромирес, 
C# не совсем подходит  для исследований и разработки. 
Почему? Математику мы уже писали на нем, и ничего...) И даже графику товарищ сделал для он-лайна. Все двигалось, рисовалось. Единственно что, не удобно было вернуться назад — хотя бы в дневную историю.
Поэтому хотелось бы как в Квике: сдвинул, подтянул, сжал и т.п. Как я уже выше писал, тики нам не нужны. Более того, обновление данных а окне может быть раз в десятки секунд. Скорость отображения вообще не критична.
Я почему спросил про С#… Товарищ мой много чего уже знает по этому языку (я меньше), но мы оба в нем все равно любители. Математику и всю логику управления мы все равно напишем на нем. А вот чисто визуалку-графику — хотелось бы понять, можно ли не сильно отклоняясь от идеологии .net сделать функционал окна квика для графиков. Такой функционал кажется оптимальным.
avatar
SergP, по 2м причинам
1. Слишком многословный язык (для исследований и поиска)
2. Среда разработки Visual Studio не помогает исследованиям (есть режим REPL, но работает неудобно). Пришла в голову идея поправить код -> остановил софт->залез в код, долго листал, нашёл-> запустил компиляцию-> дождался запуска, подкачки данных (иногда часы, если задача серьёзная), понажимал кнопочки, подождал что получилось. Это долго. Цикл может занимать часы.

В R и юпитере — просто поправил код и всё. Данные уже в памяти. Ничего подгружать не нужно.

То есть если у вас идея оформленная (осталось захаркодить), то это не так существенно (C# отлично подойти может). А если вы исследуете, то C# неудобен (есть лучше).
avatar

Ромирес, или в том же ТСЛаб накидали скрипт — прогнали на истории — поправили — снова прогнали.

 

Писать страты на чистом C# и вправду тяжко.

 

Но R — ужасно тормозной. Питон, наверное, тоже.

avatar
ch5oh,  «python без pandas деньги на ветер» — язык очень медленный, но благодаря библиотекам заточенным на векторизированную обработку данных (pandas,numpy...) с оптимизацией до уровня разных SIMD и u,v конвейеров получается быстрым (в актуальных задачах часто существенно быстрее C#). Если задача выходит за возможности таких библиотек — C#, Java и C++ как языки  и платформы становятся быстрее. Но экосистема python стала настолько огромной, что остаётся всё меньше ниш в которых приходится делать что то своё низкоуровневое.
avatar

Ромирес, мне питон не понравился синтаксически. Даже R лучше ложится на мозг.

 

Что касается «дополнительных библиотек»… Ну, шарп тоже можно нагнуть интересными способами. Понятно, ускорение вычислений на GPU можно использовать. Некоторая поддержка SIMD была сделана в Mono. А еще есть вот такой прикол для шарпа:

https://habr.com/post/239619/

 

Но в итоге это приводит к тому, что код надо рефакторить, чтобы он лучше соответствовал ускоренным векторным инструкциям. Мало того, что это лишняя работа, так еще и читаемость с понятностью падает (обычно).

avatar
Конечно можно. Компонентов разных полно в сети.
Я, например, использую ChartDirector.
Давно написал, году так в 2010 — 2011.
По времени заняло, примерно, неделю чтобы разобраться.
Но помните все Chart компоненты — это, как правило, только отрисовка.
А данные Вы сами должны вычислять. Chart- Компонент только рисует.
Это написано на С# Wpf. Но можно и Windows Forms использовать.
Можно это же и на Крестах написать, но уже лень заморачиваться.
От языка все это не зависит.
Успехов.


avatar
_sg_, что такое Кресты? )
avatar
avatar
На всякий случай для ознакомления Charts на С#, если будете все сами писать:

www.amazon.com/Practical-Charts-Graphics-Jack-Xu/dp/097937250X

Кстати, у этого же автора есть еще пара книг по этой теме, поищите в Интернете по фамилии. Я уже забыл как они называются.

А если уж совсем хотите до глубин разобраться в вопросе и написать все на плюсах и Win32 то это знаменитая книжка Фень Юаня:

www.twirpx.com/file/162840/

Но лучше все таки поискать готовые Chart-компоненты.
Желаю успехов.
avatar
Скорее всего — да можно. Пути 2. Оба дорогие.
1. Приобретение быстрой библиотеки для отрисовки. 
Например https://www.arction.com/pricing/ . 
2. Написание самостоятельной библиотеки. Очень долго = дорого.

Использование managed языка для создания быстрого компонента отрисовки финансовых чартов (тики) — не самое лучшее решение (это не его сильная сторона), такие вещи лучше писать на C++. А это ещё трудозатратнее.

Всё становится несколько проще, если вы заранее решите что не будете строить тиковые графики.  Но слабая сторона C# — малое количество библиотек, в т.ч. для рисования чартов (но они есть — www.dundas.com, ilnumerics.net… ). Может даже штатный MSChart компонент справится с вашими задачами.
Но работы — адское количество. С GUI самая морока.
avatar
Ромирес, ну мощности с# в принципе хватит. Раз уж даже в браузере через js все неплохо рисуется(сжирая всю оперативу ).
avatar
Анзорик, для тиковых графиков C# часто не хватает, для остальных таймфреймов — вполне. 
avatar
Ромирес, Вы не умеете его готовить. У меня чарт на чистом C# отлично рисует тиковые графики. А также стакан и вообще все что надо.
avatar
Ромирес, да ладно. Используйте XAML, там что угодно рисуется, если знать как. 
avatar
Dmitryy, XAML это же язык разметки.
avatar
Ромирес, я как разработчик это прекрасно понимаю) Позволяет рисовать великолепные графики, которые ни один квик не нарисует. Точнее это будет WPF, но не суть.
avatar
Dmitryy, понятно. Ну а я то про производительность движка в целом. А не про то как объекты на форме расставить (или описывать их расстановку) и event-ы соединять в MVVM. Автору же как нужно (я домысливаю и гиперболизирую) — что бы тиковый график, с 10 сложными научными функциями плавненько зуммировался, скроллировался по клику да ещё и как в Quik в риал-тайме. Обычно так хотят.


avatar
Ромирес, в буквальном смысле тики не планируются. Свечи или бары — да. Остальное — гладкие кривые, полученные из математики.
avatar

Ромирес, скорость графика зависит от реализации либы и от криворукости конечного программиста. Нельзя априорно сказать, что «C# — это всегда медленно».

 

На худой конец (если нужно 60 fps) можно взять что-то типа OpenTK — отрисовка будет делаться с такой скоростью с какой может рисовать OpenGL. Когда-то себе скальперский стакан на нем делал. Ясен пень все летало со скоростью света.

avatar
ch5oh, все пральна.
С появлением и широким использованием в разработке правильными программистами C# TPL (task parallel library)  ограничений по скорости практически нет.
avatar
_sg_, ключевое слово «правильные программисты». У «правильных программистов» ограничений по скорости и без TPL не было. =)
avatar
ch5oh, нет TPL значительно все упростила при разработке многопоточных приложений для C#.
avatar

Ромирес, арктион всего от 2 килобаксов в год стоит.

А так, наверное, хорошая либа. =)

avatar
ch5oh, бывают люди кому в риалтайме на канвас хочется несколько миллиардов тиков выводить, а для кого то тиковый график это все точки (points) цен сделок по лукойлу с начала дня с барами объёмов внизу.Тут индивидуально всё. У C# область начала применимости для HFT-чартинга (из-за managed модели, packing-unpacking, сериализаций-десериализаций и плохо контролируемого GC) похуже чем у C++. Но как вы правильно заметили — все готовят по-разному.
avatar
Ромирес, на плюсах рисовать можно? я и не знал =))
avatar

Ромирес, хулиард тиков в монитор не влазит. Его надо сначала преобразовать к фактически наблюдаемым пикселам (естественно, это делается в памяти без бессмысленных отрисовок). Тогда на каждом обновлении графика нужно будет рисовать не более 2-5 тысяч пикселей.

avatar
ch5oh, мне кажется вы сейчас описываете рисование на канвасе. 
avatar

Ромирес, Вообще-то не надо ничего никуда рисовать предварительно. Что данные нужно готовить — это да. А кому сейчас легко?

 

Большинство либ ленятся делать нормальную оптимизацию и получается стандартная ловушка: учебные примеры ведут себя замечательно. Все красиво и гламурно. Начинаешь внедрять в прод — и привет. Уже на 10к точек (свечек) — гламурный чарт за хулиард баксов вдруг загибается и перестает подавать признаки жизни.

 

avatar
SergP, присоединяюсь к озвученному ранее: если для себя - 
воспользуйтесь готовым софтом


На своем опыте скажу — лично убил несколько лет времени неспешно конструируя и переделывая с нуля бэктестер с перспективой доработки до торгового терминала. В процессе эволюции как трейдера из проги выбрасывались одна за другой фичи, которые ранее казались ключевыми — например, прорисовка графических примитивов — чтобы наклонные линии поддержки/сопротивления на разных таймфреймах располагались одинаково, а не скакали вверх-вниз, как в МТ4, ведь как можно торговать, если не знаешь где точно находится поддержка канала (здесь уже можно смеяться); отображение маркерами новостей на графике и многое другое.
Плюс потеря вычислительного времени для нужд синхронизации графического вывода при многопоточности.

В общем, совет такой — для поиска неэффективностей изучать и использовать уже готовые решения, при нахождении таковых для написания робота использовать готовые терминалы либо писать что-то свое без GUI — он-то не нужен будет.

avatar
Электричка, 
не у всех есть квик....
а причем здесь это? 
avatar

ZedGraph хорашая либа (бесплатная и даже исходники можно найти).


Либо подсоединить к квику ТСЛаб. Там будут любые графики с возможностями зум/скролл/смена вида отображения/объемный анализ/покер с девушками.

avatar
Что тут за идиотское размещение постов?!
avatar

Только зарегистрированные и авторизованные пользователи могут оставлять ответы.

Залогиниться

Зарегистрироваться

теги блога SergP

....все тэги



UPDONW
Новый дизайн