SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
Блог им. AlexGood
Как защитить свой алгоритм поручая программисту написание робота?
- 22 июля 2021, 15:31
- |
Друзья и коллеги, всем привет!
При поручении программисту написать по своему эффективному алгоритму робота он же узнает принципы входа-выхода, мани-риск менеджмент, количественные параметры! Как защитить свой алгоритм от раскрытия перед программистом?
При поручении программисту написать по своему эффективному алгоритму робота он же узнает принципы входа-выхода, мани-риск менеджмент, количественные параметры! Как защитить свой алгоритм от раскрытия перед программистом?
теги блога AlexGood
- BR
- brent
- cанкции
- Cбер
- Exante
- fRTS
- GD
- GZ
- interactive brokers
- Quik
- RI
- S&P500
- SaxoBank
- Si
- USDRUB
- USDRUB_TOM
- акции
- банки
- БКС
- брокерский счет
- брокеры
- вариационная маржа
- Великобритания
- волатильность
- вопрос
- ВТБ
- выбор брокера
- Газпром
- горизонтальный объем
- девальвация
- девальвация рубля
- дейтрейдинг
- дельта
- доверительное управление
- доллар
- Доллар рубль
- доллар-рубль
- доллары
- ДУ
- евро
- Еврооблигации
- Емельяненко
- золото
- ИИС
- Инвестиции в недвижимость
- Индекс МосБиржи
- интрадей
- квалифицированный инвестор
- Квик
- ключевая ставка
- комиссии брокера
- контанго
- коронавирус
- корпоративные облигации
- коррекция
- Кречетов
- криптовалюта
- маркет-дельта
- ММВБ
- Мосбиржа
- Московская биржа
- Налогообложение на рынке ценных бумаг
- НДФЛ
- недвижимость
- нефть
- Нефть Brent
- облигации
- ОИ
- околорынок
- околорыночник
- опрос
- опционы
- Открытие
- открытый интерес
- ОФЗ
- оффтоп
- продажа опционов
- разворот
- РТС
- рубль
- санкции
- Сбер
- Сбербанк
- Стоп-лосс
- США
- ТА
- торговая система
- торговые роботы
- торговые сигналы
- торговый софт
- трейдинг
- ТС
- Финам
- Форекс
- ФОРТС
- футпринт
- фьючерс MIX
- фьючерс ртс
- фьючерсы
- хеджирование валютного риска
или этих
законспектировал!
Ну разве что ещё сформулировать алгоритм максимально обще, с кучей параметров, задаваемых в конфиге (чтобы даже направление сделки параметризировалось, например), чтобы программист не смог понять в чем вообще логика работы. И потом параметрами уже под себя задать конкретную логику.
Правда, в этом случае уже у вас может быть проблема, что вы не сможете проверить, что программист написал то что надо.
А при реализации же думаешь.
И отдельные идеи тестируешь отдельно.
Даже если их в тз нет.
И они обойдены.
Торгуется неэффективность и вполне можно в копилку добавить еще одну неэффективность по результатам выполнения ТЗ.
Дело в том, что к таким как вы изначально относятся как городским сумасшедшим и просто даже нет желания проверять что вы там такое выдали. К тому же проверять надо своими живими деньгами, на истории то все подряд работает. Вы как то неуловимый Джо — не ловят потому что никому не интересен
Что касается ублюдков — а что проблема отдать свои идеи кому-то даром. Честно, не понимаю… почему бы другим не помочь. Ну тут же на голубом глазу предлагают че-то накодить нахаляву. Все это очень забавно — с одной стороны автор просит сделать ему бесплатно, а с другой ищет как бы его гениальные идеи не сперли. Картинка такого заказчика вырисоывается )))
вот человек поработал внутри, кое-что узнал, потому ушёл на «вольные хлеба». И что, к нему могут докопаться, он будет раскрывать им свой алгоритм?
Так что идеи к которым программист придет занимаясь написанием кода не защищаются.
А написать код и при этом не понять его идею.
Наверно можно так сделать ТЗ.
Кусками.
Заменить функции регрессии так средним )
Или в описании и принятии теста не тот тайм фреймйм задать.
И желательно с опытом.
Логично?
А опыт это знания и наработки.
В разработке роботов БОЛЬШЕ 50% времени это выяснение что-же хотел заказчик и за что он платит.
Иначе заказчик будет не доволен.
Результата не будет.
Это исследовательский проект где вы нанимаете исследователя.
который к тому же умеет кодить.
как доп функция.
другие просто не возьмутся так как тема не их.
слишком экзотично!
А кодер будет реализовывать вашу идею один… да и рынок как таковой ему скорее всего не интересен, иначе кодировал бы для себя
Другой вопрос что с частными трейдерами адекватный кодер работать не будет. Меня недавно звали в хэдж фонд на 300 000. Не пошел, потому что надо идти в офис. А шарамыги с улицы вообще часто хотят халявы и считают 20 — 30 тыс в робота пипец инвестицией и выпьют за них всю кровь. Ну нафиг
а ТЗ чтобы реализовать нужно понять о чем оно.
Хотя-бы для того чтобы оценить трудозатраты.
И в этот момент ты уже собираешь из кусочков.
Вот это уже есть.
Вот эту функцию я писал.
А вот это интересный поворот — зачем он в тз, и сколько его кодить.
Может его вообще не закодить.
Приходится уже на этапе чтения тз понимать как это будет работать.
С нуля то же ничего не пишется.
Это не возможно.
Так-как это значит что сфера новая и опыта в нем нет.
Оценить тз на трудозатраты нельзя.
Время и цен сказать нельзя.
Я вот например тз от некоторых людей на этом сайте вообще готов бесплатно сделать ).
очень простые.
e=mc^2 это очень простая формула.
И регрессия очень простая формула.
И матица очень простая вещь.
торгуются неэффективности.
алгоритм это метод их фиксации в виде позиции в рынке.
неэффективность получается из алгоритма можно вытащить и использовать отдельно.
если она есть.
а если неэффективность никакая не эксплуатируется то робот будет сливать примерно со скоростью комиссии.
если вы предполагаете что неэффективностй нет на рынке то из него надо уходить.
для меня еще одна неэффективность это артефакт.
можно ее добавить как фильтр.
или фильтр из другой неэффективности..
ну например из продавай в мае и уходи.
их можно миксовать.
можно просто покрывать в мае позиции фьючерсом, получая дешевую по входу облигацию.
с короткой дюрацией.
как раз на лето).
Модули которые должны общаться друг с другом должны знать спецификацию интерфейсов и типы данных друг от друга.
Короткий пример. Есть ядро системы и есть подтверждающий индюк. Без их совместной работы ТС является пустышкой. Ваша задача составить ТЗ на написание ядра таким образом, чтобы были четко описаны выходные данные (их типы, объемы, расстановка в переменных и т.п. в простейшем понимании).
Соответственно в ТЗ на индюк вы пишите, что на вход индюку будут подаваться такие данные (такого-то типа, в таком-то объеме, в такой-то расстановке в переменных и т.д.)
Если в ходе отладки возникают ошибки, вы сможете локализовать их и обратиться по гарантии именно к тому прогеру, кто ваял проблемный модуль и сказать «я подаю на вход значения 5 и ААА, а он не фурычит. Переделывай»
и во время теста при сдаче вам придется тестировать на каких-то данных.
а значит этот индикатор отдельно.
а робота по индикатору на md5 (md4) можно за 20 usd купить.
не считайте что кодер идиот.
особенно если он в этой нише несколько лет.
1. Разбираться с Lua
2. Писать на С#
3. Отдать на аутсорс вот с таким вот вопросом от топикстартера
Да — там могут быть проблемы, когда будут частые передачи (например) из ядра в индюк и обратно по ходу работы всего ПО, хотя и эти обращения можно рассматривать отдельно. Я работаю с программистами, но несколько на другом уровне, и меня удивляет ваше ярое отрицание возможности разбиения задачи на подзадачи, разделение труда и т.п., тем более если вы опытный программист. (насколько я понял вы таковым являетесь).
Также я слабо представляю что итоговый листинг с включением всех процедур, функций и модулей в коде (чтобы пример был ярким и показательным скажем что это ОС) собирал один единственный профи))))
Знаете сколько приходит таких задач, вот есть черный ящик где-то там и он выплёвывает такие то данные. Окей, дайте спецификацию, опишите как эти данные обрабатывать и в каком регламенте взаимодействие должно осуществляться. Это вопрос метода, подхода к решению задачи. По сути это вариант перевода задачи от написания всего полноценного кода разом, к вопросам интегрирования. Чем не выход? Отладка — да, дело будет сложное, хотя в большинстве случаев просто срок будет растянут, т.к. возникают накладные расходы на координацию команды, но эта задача упрощается если все модули готовы в срок, настроено корректное и полное логирование.
Может быть ваше категоричное мнение обусловлено моим примером с ядром и индюком, якобы в такой системе больше ничего нет от того она и простая. Но я привел упрощенный пример, касающийся именно тех частей, где будет зашита интеллектуальная собственность. Понятное дело, что там коннектор нужен, отдельные модули для формирования параметров позиции, ведения позиции, блок анализа сделок, расчет риска (хотя это больше функция ядра) и т.п. Там дохрена подзадач, т.к. робот это полноценная система. Но я и не говорил что написание роботов, да еще и силами других людей — это простая задача. Я говорю что методы могут быть простыми, упрощенными. И банально, скажем так второстепенные задачи и индюка мы можем отдать одному прогеру, а ядро другому. Как еще проще объяснить. Программисту отдаем задачу построения кузова, коробки, подвески, рулевого управления и описываем параметры подкапотного пространства + описание интерфейса взаимодействия с коробкой передач. А движок другому программисту. Если стоит вопрос написания всех модулей робота в одном пространстве имен, то это тоже не великая проблема.
Сложность реализации от масштаба растет экспонентциально, а не линейно. На коленке что то наваять несложно. Поэтом это очень быстро разваливается под своим весом
хотя есть такие методы.
я видел 2 раза в тз.
обычную регрессию.
писали формулой.
неправильно.
чтобы значит кодер реализовал а они потом вместь этой формулы нормальную регрессию поставят.
только кодер же из регрессии копипастит готовый код.
и тестирует получается 2 функции.
наивное понимание что кодер без во и регрессию не поймет.
и математику не знает.
и проект исследовательский.
а не услуга по написанию кода по тз.
что программист прямо берет и каждый пункт кодит не читая все тз.
а оценивает объем работы по кол-во листов тз.
(кстати точная оценка ))
2) предложить программисту написать кастомизированный вариант, т. е. будет вариабле, которая потом будет заменяться вручную, он то конкретных чисел не знает, а подбором заниматься муторно, это ведь не перебор вариантов пароля.
3) взять программиста в долю, размер доли подбирать индивидуально
Написать длинное, подробное ТЗ. Найти самого годного программиста, такого, чтобы мог бы даже написать бинарный поиск без ошибок. Пригласить на обсуждение ТЗ. В момент, когда программист будет обдумывать ваш эффективный алгоритм курвафиттинга и мартингейла, подкрасться сзади и треснуть по башке чем-нибудь тяжелым. Труп расчленить, печень программиста съесть. Только жарить не надо, лучше даже и не варить, если нет аллергии на кристаллический кофеин.
После этого вы сможете сами реализовать свой замечательный алгоритм. Можно даже сразу перейти к этому пункту, дорогу осилит идущий.