SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
теги блога SergP
- Brexit
- COVID-19
- EPFR Global
- Ryanair
- S&P500
- S&P500 фьючерс
- SpaceX
- Teslamotors
- Transparency International
- Авангард
- акции
- анбандлинг
- антикризис Россия
- Беларусь-Россия
- Белоруссия
- брекзит
- Брексит
- Вакцина от COVID-19
- Венесуэла
- вопрос
- Выборы 2019
- Газ
- газ для европы
- Газпром
- геополитические риски
- Гонконг Китай
- Госдолг США
- Государство в период кризиса
- Гренландия
- Деловая активность
- День космонавтики
- День Победы
- ДНР ЛНР
- доллары
- Донбасс
- Запад
- Избранное
- Импортзамещение
- инвестинг
- индекс МБ
- Индекс РТС
- инфляция
- инфляция в России
- Кабанов
- Казахстан
- Китай
- коронавирус
- Коронавирус в РФ
- кризис 2020
- Лукашенко
- Магнит
- Мадуро
- Майкл Блумберг
- мид рф
- минсельхоз
- Минфин
- Минэкономразвития
- Набибулина
- Налогообложение на рынке ценных бумаг
- Нефть
- опек+
- опрос
- Отравление Навального
- отставка правительства
- оффтоп
- перечень
- Песков
- Плюсы и минусы
- праймериз
- профессионал
- Путин
- рейтинг
- рисковые активы
- Рольф
- Роскомнадзор
- Роскосмос
- Россия
- Росстат
- Рунет
- Саммит
- санкции
- Санкции США
- Северный поток
- Северный поток-2
- Сергей Алексашенко
- Сечин
- СЛаб
- смартлаб
- СМИ
- Сонин
- СП-2
- Стояк
- сурков
- США
- США-Китай
- Трамп
- Трамп Дональд
- Украина
- Шпилькин
- Эмбарго
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 хорашая либа (бесплатная и даже исходники можно найти).
Либо подсоединить к квику ТСЛаб. Там будут любые графики с возможностями зум/скролл/смена вида отображения/объемный анализ/покер с девушками.
Только зарегистрированные и авторизованные пользователи могут оставлять ответы.
Залогиниться
Зарегистрироваться