Не далее как вчера написал пост о том, что хотелось бы алготрейдинг на Андроид. И тут началось — у Андроид, дескать, быстродействие не то, а у сотовой связи тем более.
Я ХФТ не занимаюсь, мне быстродействие некритично, но хотелось бы спросить.
Возьмём ручной интрадей трейдинг — там все руками, и успешно торгуем.
Какова реакция человека? — она известна 0.2 -0.3 с. Ещё время принятия решения. Полагаю, по себе, естественно, — 0.5 — 1.0  с.
И чё?, Задержки АТС существенны и важны? Думаю, что нет. Такие задержки вам 286 комп обеспечит.
В общем, претензии к быстродействию никак и ничем не обоснованы

Блин, 4 ядра, частота как в компе. И нет ничего! Мне без разницы, Питон или Java. Но где доступные терминалы с Андроид- API?
Сейчас вся жизнь на смартфоне или в планшете. Когда наконец это будет?
На СЛ есть брокеры и разработчики брокерского софта, задумайтесь, плиз, чем сегодняшний смартфон или планшет на Android хуже компа на Виндах?

Все совпадения с реальными именами и событиями случайны.
На днях написал топик — Модель идеального трейдера — Hamster. И вот оно, ушел в магазин, и 20 Кг сахара  стратегия. Она давно вынашивалась, тестировалась, и пора ее выводить на реал. Для того и писался индикатор, показанный в предыдущем топике.
Не все так просто, конечно, как показано на картинке, детали опущены, но стратегия — вот она:

Картинка, кстати, никак не подбиралась, просто последняя (сегодняшний день), на первом попавшемся инструменте.
А че, хорошее название для стратегии. Главное, редкое.

После написания топика «Quik, DDE, Excel» [1], где была поставлена задача вывода данных доски опционов не непосредственно в Excel, что является очень неудобным для конкретных приложений, а в свой DDE-сервер. Свой DDE-Сервер обладает тем преимуществом, что данные из него можно направлять куда угодно, и как угодно.

С тех пор прошло 3 дня. Черновая болванка программы уже написана, отлажена, работает, и выполняет все возложенные на нее задачи. Как я опрометчиво обещал, проект DDE-Сервера будет предоставлен всем желающим [2](см. список ссылок). Проект выполнен на C++ в среде VS2017. DDE-Сервер на данном этапе выполнен в виде консольного приложения, и все что он делает, это выводит получаемые из Quik по DDE данные на консоль. В принципе, он должен работать с любой таблицей Quik, но делался под вывод доски опционов.

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

( Читать дальше )

Тем, кто не читал предыдущий топик этой темы, рекомендую для начала ознакомиться с ним [1].

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

Ну, а сейчас мы займемся разработкой и тестированием индикаторов. Для начала нам нужна простейшая стратегия с использованием МА — его и построим. Самой лучшей по характеристикам МА является ЕМА. Формула ЕМА:

( Читать дальше )

Для моделирование ТС на Python, прежде всего нужен сам Python. Pythonы бывают очень разные.

Самый большой и длинный Python — Anaconda (https://anaconda.org/). Скачать дистрибутив Anaconda можно здесь — Индивидуальное издание -https://www.anaconda.com/products/individual.
Я работаю именно с Anaconda. Установив Anaconda мы получаем сам Python, уже установленные значительную часть нужных и ненужных пакетов с библиотеками Python, и несколько сред разработки. И все это сразу готово к работе, и нам, по большей части, уже не придется дополнительно устанавливать пакеты и среды.

Самый маленький Python последней версии 3.8.2. скачивается с сайта самого Python — https://www.python.org/. Это, практически, только сам язык, компилятор и минимальный набор пакетов. Сделать с ним практически ничего невозможно, и для работы придется постоянно устанавливать нужные пакеты. Среду разработки придется также устанавливать самостоятельно.
Этот Python больше подходит для запуска и работы с уже отлаженными законченными программами.

( Читать дальше )

Стоит ли посвятить несколько топиков моделированию стратегий на Python? Не о программировании на Python — это в книгах можно прочесть, а именно о методах моделирования и тестирования стратегий.
Можно начать, скажем с двух ЕМА. Стратегия изначально дохлая, но может послужить шаблоном для разработки ваших собственных стратегий. Для этого потребуется несколько топиков. Если интереса не будет, то и заморачиваться не имеет смысла. Может вы и сами с усами.)

Делаю новую алгоритмическую торговую систему (АТС) под Quik. Базовой в системе является достаточно сложная многопоточная C++ DLL, связывающаяся с Quik через Lua. Для разработки с самого начала использовалась VS 2015. Т.к. в настоящее время перешел на х64 Quik занялся перекомпиляций всего своего х86 софта под Quik на платформу х64.
Все бы ничего, но при больших рыночных потоках данных Quik начинал подтормаживать, а при подключении DDL, Quik подтормаживал еще сильнее и через некоторое время падал вместе с DLL. Переход на х64 существенно улучшил ситуацию, Однако эпизодические падения, значительно реже, но продолжались.
Надо сказать, что все эти многопоточности и были ранее введены в DLL для снижения нагрузки на Quik, чтобы не грузить поток событий терминала. Вся обработка событий заключалась лишь в том, чтобы преобразовать данные получаемые из Lua и отдать их соответствующему потоку для дальнейшей обработки.
В общем, о стабильной АТС приходилось только мечтать, и думать что дальше с этим делать.
У меня на компе давно без дела пылилась Visual Studio 2017. Требований к железу она предъявляет больше чем VS 2015, и я ее использовал считанные разы, скорее, чтобы посмотреть что в ней нового и отличия от VS 2015. Существенных отличий не заметил, и продолжал работать на старой VS 2015.

( Читать дальше )

Не далее как вчера опубликовал топик "Смена x86 Quik 7.27.2.1 на x64 Quik 8.4.1.6. Пляски вокруг DLL", где кратко рассказывалось как перекомпилировать проект С++ с платформы х86 на х64. Надеюсь, что у вас все уже получилось или получится.
Но я «крутой» программист, и, естественно, у меня вначале вообще ничего и никак не получалось. А так как проект большой, да еще и непонятно в чем дело, а своими экспериментами я могу вообще все испортить, то решил сделать маленькую простенькую DLL LuaProba.dll, на ней отработать переход на х64, и потом перенести это в большой проект.
Привожу код С++ DLL целиком:

// LuaProba.cpp: определяет экспортированные функции для приложения DLL.
//

#include "stdafx.h"
#include <stdio.h>
#include <string.h>

//=== Необходимые для Lua константы ============================================================================//
#define LUA_LIB
#define LUA_BUILD_AS_DLL

//=== Заголовочные файлы LUA ===================================================================================//
extern "C" {
#include "Lua\lua.h"
#include "Lua/lauxlib.h"
}

static int forLua_TestFunc(lua_State *L) // Возвращает заданный текст
{
        const char *cc = "Привет из C/C++ и от меня 2 раза"; //str.c_str();
        lua_pushstring(L, cc);
        return(1);
}

//= == Регистрация реализованных в dll функций, чтобы они стали "видимы" для Lua == == == == == == == == == == == == == == == ==//
static struct luaL_reg ls_lib[] =
{
        { "TestFunc", forLua_TestFunc },
        { NULL, NULL }
};

//=== Регистрация названия библиотеки, видимого в скрипте Lua ==================================================//
extern "C" LUALIB_API int luaopen_LuaProba(lua_State *L)
{
        luaL_openlib(L, "LuaProba", ls_lib, 0);
        return 0;
}

Весь проект DLL для VS 2015 можно скачать по ссылке - 

( Читать дальше )

Сижу, изучаю рыночные временные ряды. Уперся вот во что:
Излагаю в очень упрощенном виде.
Имеются 3 монетки — одна честная и две нечестных, с симметричным перекосом, одна в сторону орла, другая в сторону решки. Без разницы, но пусть вероятности будут 0.75 и 0.25.
В основном бросается честная монетка, но время от времени она подменяется одной из нечестных. Выбор одной из нечестных с вероятностью 0.5.
Таким образом, в любой серии вероятность выпадения орла/решки не изменится и останется 0.5.
Вопрос к читателям — возможно ли в каком либо наблюдении или серии наблюдений установить сам факт использования нечестных монеток? И каким образом?
А если бросать только нечестные и выбирать между ними с вероятностью 0.5. Можно это обнаружить? Сам факт, что с монеткой что-то не так?
Что-то мне сдается, что способов нет.
 
PS Когда уже опубликовал пост понял, что решения у этой задачи нет. Распознать подмену монеток невозможно никаким способом. Это свойство широко используется в технике связи. Процесс называется скремблированием. При этом любая произвольная последовательность двоичных символов превращается в последовательность нулей-единиц с вероятностью 0.5.