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

  • Ключевые слова:
  • C#,
  • Quik
★3
на C# можно все что угодно сделать
Ромирес, ну мощности с# в принципе хватит. Раз уж даже в браузере через js все неплохо рисуется(сжирая всю оперативу ).
есть же куча всяких  сторонних приложений, которые с квиком соединяются и графики цен отражают. почти все они на с# написаны. Все реально но готовое купить в разы дешевле чем самому писать. Самому — это только если очень нетривиальные задачи хочется реализовать.

avatar

Андрейка

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


avatar

_sg_

На всякий случай для ознакомления Charts на С#, если будете все сами писать:

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

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

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

www.twirpx.com/file/162840/

Но лучше все таки поискать готовые Chart-компоненты.
Желаю успехов.
avatar

_sg_

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

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

Всё становится несколько проще, если вы заранее решите что не будете строить тиковые графики.  Но слабая сторона C# — малое количество библиотек, в т.ч. для рисования чартов (но они есть — www.dundas.com, ilnumerics.net… ). Может даже штатный MSChart компонент справится с вашими задачами.
Но работы — адское количество. С GUI самая морока.
avatar

Ромирес

SergP, если для себя, то нет смысла и это абсолютно однозначно. Если коммерческий проект - it depends…
SergP, мой вам очень дорогой совет — воспользуйтесь готовым софтом. Даже если придётся от чего то отказаться по рюшечкам и скролбарам.

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

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

Для задач исследований намного лучше R или Jupyter Notebook(Python).

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

 

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

avatar

ch5oh

Ромирес, Вы не умеете его готовить. У меня чарт на чистом C# отлично рисует тиковые графики. А также стакан и вообще все что надо.
avatar

ch5oh

_sg_, что такое Кресты? )
avatar

SergP

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


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

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

avatar

Искатель

Ромирес, 
C# не совсем подходит  для исследований и разработки. 
Почему? Математику мы уже писали на нем, и ничего...) И даже графику товарищ сделал для он-лайна. Все двигалось, рисовалось. Единственно что, не удобно было вернуться назад — хотя бы в дневную историю.
Поэтому хотелось бы как в Квике: сдвинул, подтянул, сжал и т.п. Как я уже выше писал, тики нам не нужны. Более того, обновление данных а окне может быть раз в десятки секунд. Скорость отображения вообще не критична.
Я почему спросил про С#… Товарищ мой много чего уже знает по этому языку (я меньше), но мы оба в нем все равно любители. Математику и всю логику управления мы все равно напишем на нем. А вот чисто визуалку-графику — хотелось бы понять, можно ли не сильно отклоняясь от идеологии .net сделать функционал окна квика для графиков. Такой функционал кажется оптимальным.
avatar

SergP

SergP, по 2м причинам
1. Слишком многословный язык (для исследований и поиска)
2. Среда разработки Visual Studio не помогает исследованиям (есть режим REPL, но работает неудобно). Пришла в голову идея поправить код -> остановил софт->залез в код, долго листал, нашёл-> запустил компиляцию-> дождался запуска, подкачки данных (иногда часы, если задача серьёзная), понажимал кнопочки, подождал что получилось. Это долго. Цикл может занимать часы.

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

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

Dmitryy

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

SergP

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

SergP

Андрейка, не знаю, что вы называете нетривиальностью… Нужна свобода действий над данными в их обработке и удобном отображении.
avatar

SergP

старый трейдер, для себя.
avatar

SergP

SergP, этапы:
1. Найти закономерность (готового софта достаточно)...
2. Формализовать и попытаться закодить или использовать руками...

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

SergP

Dmitryy, XAML это же язык разметки.
Ромирес, я как разработчик это прекрасно понимаю) Позволяет рисовать великолепные графики, которые ни один квик не нарисует. Точнее это будет WPF, но не суть.
avatar

Dmitryy

Анзорик, для тиковых графиков C# часто не хватает, для остальных таймфреймов — вполне. 
Dmitryy, понятно. Ну а я то про производительность движка в целом. А не про то как объекты на форме расставить (или описывать их расстановку) и event-ы соединять в MVVM. Автору же как нужно (я домысливаю и гиперболизирую) — что бы тиковый график, с 10 сложными научными функциями плавненько зуммировался, скроллировался по клику да ещё и как в Quik в риал-тайме. Обычно так хотят.


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


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

avatar

ch5oh

ch5oh, все пральна.
С появлением и широким использованием в разработке правильными программистами C# TPL (task parallel library)  ограничений по скорости практически нет.
avatar

_sg_

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

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

avatar

ch5oh

_sg_, ключевое слово «правильные программисты». У «правильных программистов» ограничений по скорости и без TPL не было. =)
avatar

ch5oh

ch5oh, нет TPL значительно все упростила при разработке многопоточных приложений для C#.
avatar

_sg_

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

SergP

Ромирес, на плюсах рисовать можно? я и не знал =))

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

 

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

 

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

avatar

ch5oh

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

avatar

ch5oh

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

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

 

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

 

avatar

ch5oh

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

 

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

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

 

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

avatar

ch5oh


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

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

Зарегистрироваться
....все тэги
Регистрация
UPDONW