nikolz в очередной раз прилюдно обосрался, отвечая несуществующему пользователю, т. е. тому, кто заведомо не сможет парировать. Нормальный такой весь мужской поступок. Впрочем, для этого персонажа обсираться - занятие привычное. А еще не читать, что пишут; отвечать на вопросы, которые не задавали, а на заданные - не отвечать; раздавать направо и налево непрошенные советы уровня старухи Шапокляк; флудить килобайтными портянками текстов, где информации по теме - с гулькин хрен или вовсе нет и т. д. и т. п. Вот ЭТО все в совокупности и называется "хамство", а вовсе не то, чтобы называть черное черным, белое - белым, а придурка - придурком. И ложная вежливость в виде подчеркнутого обращения к оппоненту на "Вы" с большой буквы этого хамства нисколько не извиняет.
Владимир написал: И кто же этот "кто-то", лапуль? Не тот ли придурок
Добрый день.
Я Вас предупреждал, но Вы, по всей видимости, неисправимы. Всего наилучшего.
Вот это дела деются, месяц только стоило не заходить... Ну то есть называть вещи своими именами - это, по-вашему, плохо. Понятно. Тогда меня тоже можете забанить.
nikolz написал: В цифровой обработке сигналов есть понятие элементы задержки. <...> И это вполне алгоритмическое понятие в настоящее время
А ну-ка, покажи, где я утверждал обратное?
Цитата
nikolz написал: Так вот , то что хочет автор этой темы реализуется не очередями и не стеками, а циклическими массивами.
Твой "циклический массив" если только под этим подразумевается аналог регистра сдвига - такая же очередь, только фиксированным числом ячеек памяти. Если хочешь, всякий "циклический массив" - это очередь, но не всякая очередь - "циклический массив".
Цитата
nikolz написал: в луа есть операция сдвига вправо и влево - а это и есть сдвиговый регистр
Да ладно. Покажи?
Цитата
nikolz написал: А то что Вы здесь херней занимаетесь это факт.
Так, да не совсем. Мы тут как раз-таки автору темы уже на протяжении 26 страниц (или сколько их там уже?!) пытаемся объяснить, что не надо заниматься херней.
Цитата
Владимир написал: Glukator, А на кой НАМ беспокоиться о проблемах какого-то мусорщика? <...> При следующем всплеске активности скрипт просто перезабьёт новые данные в старые элементы - память под них уже выделена. А мусорщик сидит и молчит в тряпочку, а не путается под ногами. Сказка!
Я об этом не подумал. Пожалуй, надо будет вышвырнуть нахрен из скрипта очередь сделок и сделать вместо нее стек :) Хотя потребляемая память и так не растет выше 2 Мб.
Владимир, чтобы мусорщик память почистил в конкретном этом примере с очередью. Есть у меня некое подобие очереди на свечах - прошлая, текущая, накапливаемая. На границе таймфреймов прошлой присваивается текущая, текущей - накапливаемая, а накапливаемая обнуляется. Понятно, что тут никаких присваиваний nil нафиг не надо, три арифметических операции и все дела. Но тут, насколько я могу понять, VPM пихает в очередь куда больше, чем 3 значения, ему это не подойдет :)
VPM написал: Я не просто про очередь, про двойную очередь из приведенного примера. Переписываются значения, а индексы либо увеличиваются либо уменьшаются в зависимости от варианта(Стек, очередь), структура таблицы остается равная 5 элементам. То есть потребление памяти стабильно, ну или меняется незначительно.
Вы все еще про тот пример с List.pushlast(), List.pushfirst() ? Там ничего не остается постоянным. Сколько накидаете элементов, столько и будет. Там происходит ровно то же самое:
Цитата
Glukator написал: При добавлении элемента - добавляем его, инкрементируем индекс конца очереди. При удалении - извлекаем первый элемент, присваиваем по его индексу nil, инкрементируем индекс начального элемента.
Просто при добавлении элемента в начало очереди мы уменьшаем индекс начального элемента, вот и все. Он даже с успехом может стать отрицательным. А при удалении элемента с конца - по индексу конечного элемента присваивается nil, а индекс уменьшается на 1.
VPM написал: А что если просто перезаписывать, я про пример из 5 элементов? nil будет вызывать сборщик, а перезапись ну поменял элемент объем остался прежним?
Не очень понял, что перезаписывать? Если мы все еще про очередь (давайте для определенности положим, что мы добавляем элементы в конец, а извлекаем - с начала), то вариантов что-либо перезаписывать нет. При добавлении элемента - добавляем его, инкрементируем индекс конца очереди. При удалении - извлекаем первый элемент, присваиваем по его индексу nil, инкрементируем индекс начального элемента.
VPM написал: Я Вам напомнил что, таблица в луа это половина ОПП! Или и это тоже не верно.
Половина не равна целому. Разве это не очевидно? ООП - это не только структура с методами.
Цитата
VPM написал: 1) Как оказалось есть разные варианты как выбрасывать: сдвигать очередь (table.remove)? Вызывать сборщик (nil); Либо, как в двойной очереди контролировать индексы, пере присваивая значения.
Про table.remove() забудьте - это очень затратная операция. Пока ваша очередь будет относительно коротка - вы этого не заметите. Но если длина достигнет тысяч или десятков тысяч элементов - тормоза будут заметны невооруженным глазом.
Я поясню. При выполнении table.remove() элемент извлекается, а вот дальше происходит дичь - луа запускает цикл по перенумерации всех элементов, следующих после удаленного, и чем их больше, тем эта операция длится дольше. Поэтому - только хранить индексы первого и последнего элементов, и никак иначе. Удаленным элементам присваивать nil.
nikolz, объясняльщик ты х**в, понятие "сдвиговый регистр" пришло в ЦОС из схемотехники, где оно материализуется в виде законченного устройства, в виде микросхемы, естественно, с ограниченным числом ячеек. А "очередь" - понятие чисто алгоритмическое, подразумевающее добавление элементов с одного конца, а извлечение с другого, вот и все. И по барабану, с какого там конца программист индексы нумерует. И то, что ему захотелось длину очереди ограничить - с алгоритмической точки зрения тоже ниего не меняет, кто раньше вошел - тот раньше вышел. Называй как хочешь, суть не меняется. Терминологии он тут решил поучить, ага.
VPM написал: Знание или не знания какого-то языка, ни как не влияют на умственные способности.
Зато незнание базовых концепций ведет к неправильному пониманию смысла написанного. Вы нахватались цитат каких-то придурков, поняли их превратно, приняли свое неверное понимание за непреложную истину. Распинаться здесь, доказывая очевидные вещи (например, что lua НЕ является объектно-ориентированным языком), я не собираюсь - читайте книги (и не по lua, а по структурам данных в общем), поймете многое сами.
Цитата
VPM написал: И так задача сводится к удобному универсальному методу уменьшения хранения данных в ОЗУ, по сути в моем представлении к организации ОЧЕРЕДИ!
VPM написал: сделать очередь ФИФО, для управления, передачи и обработки заданного количества элементов
Берете обычную очередь, и если добавление в нее очередного элемента должно привести к превышению заданной длины, то после добавления (или перед ним - как нравится) выбрасываете первый элемент.
Непонятно, чем вас не устраивает самое простое и самое очевидное решение.
VPM написал: я <...> показываю прямо то место где идет заблуждение, еще раз Луа = таблица = ОПП, но если Вы используете таблицу , как можно можно не пользоваться ОПП, хотите Вы того или нет, мы эти пользуемся по умолчанию.
Очередная брехня. ООП - это стиль организации кода, и ничего больше. Использовать этот стиль или другой - решает программист. В lua ООП прикручивается через жопу: надо городить свои конструкты для классов, наследования и прочего. И вовсе не "Луа = таблица = ООП", вовсе нет. И никаких "использований по умолчанию" нет и быть не может.
Цитата
VPM написал: Вы опять пытаетесь определять кому что нужно, отвечайте за себя.
Вы сказали, что не имеете отношения к программированию и спросили совета у более опытных людей - вам его дали: не лезьте в эзотерику, используйте простые решения, не надо усложнять. А вы в ответ, нет уж, я сам решу, что мне надо, а вы мне тут давайте читайте лекции. У попа был двор, на двору кол, на колу мочало, начинаем все сначала.
VPM написал: пример который Вы показываете, связан с понятия свободных имен. А вопрос который обсуждается относится к применению глобальных переменных с динамическими именами.
Брехня, такого вопроса никто не задавал.
Цитата
VPM написал: не буду пользоваться, равно утверждению не понимаю как писать на луа! <...> не буду пользоваться молотком, когда молоток в рука, а заколочу лбом! Почувствуйте разницу
Конечно, разница очевидна. В первом случае делается ложное утверждение, что из "неиспользования" следует "незнание". Во втором случае вообще никакого утверждения не делается. Вы занимаетесь подменой смыслов, и это хреновая практика.
Давайте уже сместим обсуждение в область конкретных практических задач, а не каких-то эзотерических практик вроде "динамических имен", которые мало кому нужны вообще, а в автоматизации торговли в частности.
VPM написал: в луа единственная структура данных это таблица, таблица это половина ОПП, а утверждение что этим не буду пользоваться, равно утверждению не понимаю как писать на луа!
Ага, а утверждение "не буду пользоваться молотком" тождественно "не понимаю, как забивать гвозди"?
Вы не читаете, что вам пишут, не воспринимаете аргументы, упрямо талдычите одно и то же про "профессора", "его пример", "демонстрацию приемов", описываете "возможности" и прочее, а потом еще и делаете логически ложные заявления (см. выше), объявляя их истинными. После чего обижаетесь, что кто-то здесь за ваш счет "самоутверждается" и вас не слушает.
Теперь к делу, о глобальных переменных. Вот, наберите в терминале lua пять строчек:
Т. е., как вам уже раньше писал Nikolay, обращение через _ׂG[] - это просто еще один способ обращаться к переменным из глобального контекста. И способ на редкость уродливый. Запись x = 1 выглядит гораздо лучше, чем _G["x"] = 1. Так что не стоит заморачиваться на тему "что бы нам с этой таблицей эдакого сделать", есть она - и хрен с ней. Забудьте, для дела она не нужна ни вам, ни мне, ни кому бы то ни было еще.
Владимир, :) пока проблем не было. При разборе очереди сделок сначала оттуда извлекаю запись trade = qpop(Trades), и сразу же проверяю на trans_id == 0. Если это так, с извлеченной записью ничего не делается, просто извлекается и обрабатывается следующая. Если trans_id не 0, то ищу нужную заявку в одно действие: order = Orders[trade.trans_id]. Если результат nil, значит, сделка была по левой заявке. По комплексу признаков оно, вероятно, надежнее. Но, повторюсь, пока проблем не было ни разу, ни одна заявка и ни одна сделка не потерялись. Ну а очистка при снятии или после исполнения - это само собой, зачем лишний мусор хранить? Отработали - забыли :)
VPM написал: сделать очередь ФИФО, для управления, передачи и обработки заданного количества элементов
Берете обычную очередь, и если добавление в нее очередного элемента должно привести к превышению заданной длины, то после добавления (или перед ним - как нравится) выбрасываете первый элемент.
Владимир написал: Со стеком заявок чуть сложнее - некторые из них у меня подаются "вне очереди".
А у меня паспорта активных заявок складываются просто в глобальную lua-таблицу Orders, где индексы - trans_id заявок. И доступ быстрый и удобный, т. к. trans_id всегда известен.
VPM, я вам пытаюсь донести то, что "универсальность" нахрен не нужна. Нужна эффективность на _конкретных_ задачах, а она чаще достигается через отказ от универсальности. Это вообще зачастую две противоположности.
VPM написал: Glukator, Так что же Вы мне тут, целый час голову морочите, это я у Вас должен спрашивать. Мне кажется я Вам уже отвечал что я пишу про возможности, а как Вам делать, что Вам делать разберитесь сами!
Если у меня и есть вопросы, как и что делать, так они точно не из области базовых структур данных. А голову вы себе сами заморочили. Обсуждать какие-то "возможности" в отрыве от приложения их к _конкретным_ задачам - изначально бессмысленное занятие. И вам уже не меньше трех человек об этом говорили в разной форме.
VPM, что именно мне станет понятно? Базовые вещи вроде стеков и очередей? =) Так я их с закрытыми глазами напишу на любом языке, а извращаться в lua, прикручивая "объектно-ориентированность" туда, где можно обойтись тремя функциями, точно не стану. Вам нравится - на здоровье.
VPM написал: Алгоритм хранит 2 переменных, начало и конец, 2 функции на добавление элемента, 2 функции на удаление элемента, т.е. всего можно собрать 4 варианта. 1; 0 --------- 1 | 11; 10 0 | 01; 00
Это просто звиздец. Вы не можете сформулировать утверждение "в алгоритме не хватает функций извлечения элемента с конца очереди и добавления в начало" иначе, как через матрицы?! Вот неудивительно, что тут 23 страницы уже нафлудили, а тема яйца выеденного не стоит.
Цитата
VPM написал: Это две разные переменные 1 - хранит размер; 2 значение.
Бред. Какой еще размер? В коде вашего примера точно так же хранятся индексы начального и конечного элементов. Разница в том, что в вашем примере эти индексы хранятся в именованных переменных first и last, а у меня в элементе с индексом [0]. И в моем случае нельзя добавлять элементы в начало очереди, т. к. при этом рано или поздно нулевой элемент окажется похерен. Только вот классическая очередь, которая мне была нужна, добавления в начало и не подразумевает.
Владимир, да так-то очередь там нахрен не нужна, довольно было бы и стека. Она обслуживает вызовы OnTrade() - весь тот мусор с дублями и прочим. Мне изначально казалось, что надо непременно обрабатывать данные от этих вызовов в порядке поступления. Вот и собрал очередь. Но в итоге получилось, что алгоритму разбора порядок их прихода вообще по барабану. А переделывать уже было лень.
Владимир написал: Glukator, Проблемы потенциальные - в рассогласовании данных. <...> А то вдруг в портфеле тикер есть, а в списке его нет.
У меня была такая ситуация. С тех пор сначала загружаются тикеры, потом портфель. И если в портфеле тикер есть, а в списке нет, скрипт матерится в лог и отказывается работать.
-- Положить элемент v в конец очереди q
function qpush(q, v)
if q[0] == nil then
q[0] = { 1, 1 }
q[1] = v
else
q[0][2] = q[0][2] + 1
q[q[0][2]] = v
end
end
-- Извлечь первый элемент
function qpop(q)
if q[0] == nil then return nil end
local x = q[q[0][1]]
if x ~= nil then
q[q[0][1]] = nil
q[0][1] = q[0][1] + 1
end
return x
end
-- ֶДлина очереди
function qlen(q)
if q[0] == nil then return nil end
return q[0][2] - q[0][1] + 1
end
-- i-й элемент с начала
function qitem(q, i)
if q[0] == nil then return nil end
return q[q[0][1] + i - 1]
end
Потенциально опасные места есть, но мне не критично.
Владимир, ну я не вижу проблемы в том, чтобы держать открытыми несколько файлов. Лог всегда открыт, да - на то он и лог. Файл портфеля у меня обновляется при каждом изменении позиций и раз в 5 минут - на всякий случай. Перед сохранением файла портфеля делается его резервная копия. А конфиг - да, считали и забыли. Короче, то, что часто меняется (портфель) вынесено в отдельный файл. Остальное просто лежит рядом и хлеба не просит. Не вижу противоречий :)
Разделил по задачам. Конфиг - это lua-файл с настройками, там у меня задается режим работы (то же, что и у вас - 'file' - по истории, 'test' - по торгам с симуляцией сделок, 'work' - боевой - очередное спасибо за отличную идею), каталоги, файлы, размеры комиссий, параметры входа-выхода, настройки счетов, настройки сообщений. Портфель - простой текстовый файл, там первая строчка - это деньги (сколько свободно, сколько заблокировано под заявки, и общая оценка портфеля), а в каждой следующей строке параметры отдельного тикера из портфеля (код инструмента, количество лотов, размер лота, средняя цена позиции, индекс таймфрейма, время и цена последней покупки, суммарные затраты на покупку). Ну а файл со списком тикеров уже показывал - просто класс:код инструмента по штуке на строку. Он у меня практически не меняется.
Пока ничего не меняю ни в параметрах, ни в алгоритмах - надо понаблюдать за работой месяцок, сделать выводы.
Цитата
VPM написал: Кто то может сказать, как собрать ФИФО, как собрать ЛИФО, возможно есть еще варианты, и вообще о чем толкует профессор? Кто понимает?
Да хрен его знает, этого прохвоссора, о чем он толкует. У вас какое-то конкретное практическое приложение намечено для этих структур? Есть у меня очередь, но всего одна - это очередь сделок. Туда падает информация о сделках из OnTrade() и разгребается потом в main(). Вот я, в принципе, и умом понимаю, что без разницы, в каком порядке это разгребать (алгоритму разбора по барабану, в каком порядке пришла информация о сделках) - вполне можно и стеком было обойтись. Он реализуется куда как красивее.
Владимир написал: Glukator, И у меня этот файл просто содержит строки вида "класс, код", только там ещё валюта, содержимое портфеля (если тикер там есть), настройки разные. Но тоже выдерживается правило "одна строка - один тикер". Кроме того, есть другие строки - данные по кошельку, номер счёта, можно переопределить режим работы скрипта (боевой, тестовый, по историческим данным), добавить или отнять денег или тикеров и т.д. Короче, структура внешнего файла тоже тщательно продумана и столь же подробно описана, как и структура данных в самом скрипте.
О как :) А у меня три файла - список тикеров, конфигурация, портфель. Ну еще запрещенные для торговли тикеры - четвертый.
Цитата
VPM написал: У меня их не 3 это для простоты изложения, но точно не 300, к примеру для фондового рынка я установил правило ~ 5% Капитала на инструмент, 100% / 20% <= 20 бумаг в портфеле. В Вашем варианте Капитал =100% / 300 бумаг <= 0.33% капитала на 1 бумагу? Но мне помнится у Вас еще нужно 300 * 9 тайм фреймов, считайте сами на кого работаете (комиссии).
Нет у меня 300 бумаг в портфеле, с чего вдруг делить капитал на 300? 300 - это число бумаг, за которыми _следит_ скрипт (в моем случае не 300, а 226). И по _некоторым_ из них время от времени совершаются сделки. А в портфеле болтается обычно от 3 до 5 штук. Вот за сегодня 32 поданных заявки и 15 закрытых с профитом сделок. Утром в портфеле было 2 тикера, сейчас 3, из которых только один тот же самый. Кстати, памяти скрипт жрет от 900 кБ до 2 Мб.
VPM, написал: таблицы это просто способ хранить множество пар "ключ-значение", а все остальное - это то, какие вы выбираете ключи и какие значения."
Вот это именно то, что я пытаюсь донести, и Владимир вам про то же самое говорит. Данные надо структурировать, причем предварительно подумать, как вы собираетесь к ним обращаться. Вот пожалуйста:
И как вы будете искать нужный инструмент в этом индексированном массиве? Каждый раз будете в цикле перебирать?
Цитата
VPM написал: На мой взгляд все логично, у каждого инструмента есть несколько тайм фреймов, в каждом тайм фрейме есть несколько баров (индексов), такая вложенность (матрешка), а дальше идут переменные или еще таблицы! Что не так?
Вот именно, что у _инструмента_ есть бары, а не наоборот. А еще у инструмента есть куча других нужных параметров, и их может быть довольно много. А у вас инструмент тождественен источнику данных со свечками.
Цитата
VPM написал: local sec = { 'BRG4','NGF4', 'GDH4', }; local DS = {};
for i=1,#sec do --Заказываю Данные DS={}; for j=0,#tf do DS[j] = Source(cl[1],sec,tf[j]); --CreateDataSource
Пока у вас 3 инструмента, эта хренота даже будет работать. Как только у вас их станет 300, или даже 30, вас не спасут ни терабайт оперативки, ни дох**ядерный процессор, потому что все это будет жрать память как голодный слон, тормозить и глючить. Задолбаетесь глюки обходить.
Владимир написал: Во-вторых, закладыывать список тикеров в код и, следоватеьльно, править код на любой чих есть просто безумие
А как нужно?
Создайте текстовый файл со списком тикеров, которыми собираетесь торговать, и считывайте его при старте скрипта. У меня, к примеру, этот файл просто содержит строки вида
VPM написал: Glukator, Согласен, Ну конечно все так и делают! Именно этим и занимаюсь, собираю отдельные переменные в таблицы. Цель максимально локализовать переменные. От этого тоже отказался лишнее bar={}; bar[ticer][tf][inde[]={}; Все уже и так есть.
Обычно структуру данных формируют, исходя из целей и задач. А "максимально локализовать переменные" - это какая-то странная самоцель. Надо бы сначала подумать над структурой, а потом уж упихивать ее в код. Вот, к примеру, взять вашу структуру
Код
bar[ticker][tf][index]
Почему у вас тикер по отношению к свечам - подчиненный элемент? Это свечи являются атрибутами тикера, но никак не наоборот. Условно, должно быть как-то так:
Код
tickers[sec].bars[tf][i] = { H, L, O, C, ... }
где sec - код инструмента, tf - таймфрейм (или его индекс в таблице таймфреймов), i - индекс свечи. Это если вам нужны "японские" свечи, или как их там, и вы хотите к ним иметь доступ по индексу. А если не по индексу? Куда пихать время, в атрибуты свечи или в индекс (если оно надо вам вообще)? А не так что "хочу упихать все в таблицы" и все тут. Правильно организовать данные - это большая работа, и делается она не из желания упихать все куда-нибудь, а из соображений удобства и быстроты доступа к этим данным в дальнейшем.
Ухахах, шёл б ты в психоаналитики. То, что ты не в состоянии сделать нормальный publication quality график, и вываливаешь на суд публики какое-то вырвиглазное дерьмо - это моя проблема? Ой дурак...
Цитата
VPM написал: дерево всегда можно в последующим более аккуратно наследовать в глобальную таблицу
Вы прям комсомолец из анекдота, который сам создает себе трудности и сам их героически преодолевает. Вам принципиально хочется скипидарить себе мозги? Зачем что-то куда-то "наследовать"? Просто заведите переменную вне main() и разместите там свою таблицу. Она будет доступна в глобальном контексте.
nikolz написал: Хвалюсь. ------------------------------ Сегодня мой робот на сбере показал такую картинку с начала года.
Т е c 3.01.2024 профит 2.44%, из них 1.72 - лонг и 0.72 -шорт. Стратегия "купил и держи" дала бы 1%.
Чем тут хвалиться? Этой уродливой картинкой, по которой единственное, что можно понять, - что она опасна для глаз смотрящего? У меня цыгане на соседней улице живут, так вот от их шмоток в глазах меньше рябит.
Владимир написал: Glukator, А я делаю именно так. За исключением случаев, когда так нельзя делать.
В принципе при хорошем входе в позицию и достаточном количестве свободных средств это не такая уж проблема - поболтается да и продастся рано или поздно.
Цитата
Владимир написал: я ввёл рейтинги тикеров, которыми управлял через контекстное меню тикера: "говно", "мусор" и так далее до "отличного". И немного перенастроил алгоритм, чтобы "говно" из портфеля скрипт старался выводить, а хорошие тикеры, наоборот, старался придержать а портфеле. А уж разрешение тикеру покупать или продавать изначально было заложено в меню - это два бита, 4 состояния. Очень удобно. Например, где-то за неделю до экспирации я перевожу тикер в "говно", и он спокойно выводится в 0.
Красивое решение. У меня пока попроще, простое бинарное разложение: можно/нельзя торговать в принципе. Тупо через два файла - в одном общий список тикеров, в другом - запрещенные. Присмотрюсь, может, тоже придется рейтинги вводить. В биржевых делах разбираться мне тоже лень. Другое дело скрипт написать - упражнение для ума, а если с пользой для кошелька выйдет, так и вовсе хорошо.
Да с чего бы? Самый правильный показатель. И любую доходность я буду сравнивать с ключевой ставкой, потому что не вижу смысла в схеме с доходностью меньше ее (нахрена все эти сложности с торговлей, когда тупо с накопительного счета можно больше получить?).
VPM написал: Есть какие то первые результаты за период которые можно оценить? Ральфа Винца не читали?
Не читал, и даже не знаю, кто это, и зачем он мне надо. Результаты мои скромные на скромном депозите :) С 12.12.2023 (сейчас уточнил по логам, когда я выпилил убыточные позиции), результат следующий: - всего сделок: 50 (сделкой считается удержание позиции от открытия до закрытия); - прибыльных: 50, убыточных: 0; - лучший результат: 113.81; - худший результат: 0.21; - суммарный результат: 622.83. - оценка портфеля на 12.12.2023: 13167.70. Итоговая доходность схемы: 622.83 / 13167.70 / 28 * 365 = 61.6% гг.
VPM написал: Glukator, А вы сделки каким либо образом оцениваете, я имею ввиду результат?
Элементарно - по доходности в процентах годовых. У меня задана целевая доходность 25% годовых, которая в большинстве случаев перекрывается с огромным запасом. Вот к примеру выдержка из лога:
VPM написал: Glukator, я просто пошутил, да и результаты нужны статистически значимые (ведь задача стоит сделать стабильный доход!)
Цитата
Владимир написал: Glukator, А как быть с экспирациями? С банкротством? С долгими годами ожидания, когда позиция выйдет в плюс?
Мой ответ был как в анекдоте про математиков. Совершенно точный и совершенно бесполезный :) Я ж нигде не сказал, что сам так делаю? =)
Вот два примера из моего, так сказать, недавнего опыта: 1. В ноябре я накосячил в скрипте в самых базовых вещах, где и накосячить, казалось бы, нельзя. В результате он нахватал в портфель всякого говна, часть из которого к декабрю закрылось в плюс, а остальное ушло в глубокую жопу. После чего я совершенно спокойно закрыл эти убыточные позиции, чтобы высвободить средства и отлаживать скрипт дальше в "боевом" режиме, пусть и с меньшим депозитом - пусть выкручивается сам, сволочь такая ) 2. Эта сволочь купила UCSS, который решил слинять с биржи, за 3 дня до этого события. После предупреждения брокера о том, что фирма планирует сделать ручкой, также вручную закрылся в убыток (правда, совсем смешной - что-то около 150 рублей), после чего у скрипта появился "блеклист" для тикеров, с которыми вообще никогда не надо связываться.
Зато вот с начала декабря, когда косяки были выпилены, скрипт-таки начал реализовывать изначальную задумку. И практически все, что было куплено - продано с профитом, только пара тикеров болтается в портфеле со смешной просадкой от -1,5 до -4%, да периодически что-то покупается и продается.
VPM написал: Владимир, Ни кто не торгует чтоб на все 100% сделки были успешными <...> Вы свою приводите говорите что она лучшая, Glukator, приводит свою засомневался
Кто засомневался? С чего вы так решили? Есть некоторые моменты, над улучшением которых предстоит поработать, но в целом мой вариант, который я где-то выше изложил, вполне устраивает. А насчет 100% успешных сделок - это очень легко. Торгуйте в лонг и никогда не закрывайте убыточные позиции :)
VPM написал: в общем то существуют прибыльные стратегии которые торгуются чисто по графикам без применения индикаторов или с минимальным их количеством.
Если верить исследованиям oxfordstrat.com, то практически все это работает на уровне "так себе хреновенько".
Лександр написал: Чем раньше вы научитесь находить причину тем быстрее найдете ГРААЛЬ .
Если даже допустить обретение некоторыми индивидами навыка "нахождения причины", какое отношение это имеет к автоматизированной торговле, которая обсуждается здесь?
VPM написал: Ну смотрите, есть некое у нас расхождение в понимании, я Вам предложил отказаться от терминологии, которую используете и вернуться к классике. Там где просадка = просадке, а отскок отскоку, Либо нужно уточнять что от чего скачет. У Вас я запутался окончательно, давайте я поясню что хотел сказать:Тенденция недельная вниз, изменения цены в течении дня на 2% пробит квартальный уровень поддержки - это сигнал для набора позиции в шорт! Это некий сценарий для крупного участника, а Вы получается играете против и ждете свой отскок я так понимаю средней
Вот прям честно не знаю, как вам еще объяснить ) Мне кажется, вы за деревьями леса не видите. Все пытаетесь впихнуть в какую-то схему с "уровнями", "тенденциями" и прочим, а я на все это положил болт на 32. Не знаю я про недельную тенденцию ничего. Про "квартальные уровни" тоже. Мой горизонт событий - 6 часов активности тикера (для расчета разницы между двумя трехчасовыми средними).
VPM написал: 2% величина серьезная, есть стратегии которые при таком отскоке и пробитии уровня, начинают набирать позицию.
Каком-таком отскоке? Я ж писал, покупаю только на падении, а первым (только лишь первым) признаком, что можно покупать - для меня является просадка, т. е. снижение средней цены сделки по активу на величину, превосходящую 2%. А отскок - это то, что ожидается _после_ просадки.
Цитата
VPM написал: Скука это не то понятие которым оперируем, да для отладки я тоже пользуюсь быстрыми тайм фреймами, но это для отладки.
Я вот еще как оперирую. Представьте себе, что скрипт заложен на ожидание просадки не 2%, а минимум 20% (причем, за время, не превышающее 6 часов), после которой он начнет размышлять, открывать ли сделку. Да пять лет будете ждать, пока это событие наступит. Оно мне надо?
VPM написал: Glukator, Не совсем понял Ваш подход? Во первых, в трейдинге тоже есть устоявшиеся понятия (солнце=солнцу), так и понятие Просадка - говорит, что трейдер набрал позицию, а цена двигается против его позиции, максимальное отрицательное значение и будет называться просадкой для данной позиции.
Но мне думается что вы закладываете несколько другой смысл в это понятие (типа отскок)? Если это отскок то уместно сказать от чего (от средней, от цены позиции...)
А чего там понимать-то? Покупаем на падении, усредняясь вниз, и продаем все разом, когда цена вырастет и превысит средневзвешенную настолько, что будет выполнен один из критериев выхода. Все просто, как апельсин.
"Просадка" - это снижение цены актива относительно его цены в прошлом, неважно, есть по нему позиция, или нет. Если позиции нет - на просадке ее можно открыть, а если позиция есть - то нарастить. А вот на то, что после просадки, особенно глубокой, должен быть отскок - на это мы и рассчитываем :) Вот чего точно НЕ буду делать - так это наращивать позицию, если текущая цена выше средневзвешенной.
Цитата
VPM написал: А понял я, то что Вы хотите отловить те бумаги, которые прыгают на десятки процентов (ну это типа энергокомпаний в прошлом году)?
Нет. Движения на десятки процентов, если они будут, скрипт при нынешних условиях, конечно, выловит. Только не вижу смысла закладываться целенаправленно на столь редкие события - это ж скука смертная, помрешь, пока дождешься. Меня пока и 2% устраивает, вот после вчерашнего разговора с Владимиром вернулся к мысли о том, что можно сделать этот параметр динамическим.
Владимир написал: Я бы за это время заработал бы разве что геморрой.
Согласен. Я одно время было сидел втыкал в графики и прочая - потом понял, ну его нафиг. Тут не то что геморрой, еще и шизофрению вдогонку заработать можно и нервный тик впридачу. У кого нервы крепкие, тот пускай сидит ) Раз уж технический прогресс дал человеку компьютер, пусть компьютер и работает, а человек должен заниматься своими делами. Ради этого мы все когда-то сюда и забрели.
Владимир, идею понял. Вы ограничиваете сверху размер разовой ставки, и скрипт подает заявку на число лотов, которое умещается в отведенную сумму. Это, конечно, с точки зрения баланса лучше. У меня это ограничение пока работает просто как "планка сверху": цена выше заданной - значит, покупать нельзя. Покуда я своей "курице" денег много не даю, ваш подход для нее не катит - быстро выжрет депозит, не оставив простора для диверсификации. Пускай покамест курочка по зернышку клюет. Про частичное исполнение заявок, это да - песня просто с повторными колбеками и нулями в trans_id (я вам как-то писал, что мне нули не прилетали - вот с тех пор целый воз их нащелкал) и еще не помню с чем. Отладил, но тоже не сразу.
Во фьючерсы не лезу. Денег жалко ) Успел, что называется, опыт купить. Так что скрипту пока срочный рынок не доверю, хотя и заманчиво.
Владимир написал: Вопрос с величиной ставки куда более интересен: ведь одна бумага может стоить $1, а другая $1000.
Да, к слову - интересный момент. У меня все в рублях, но не суть. Пока я не придумал, что с этим делать, и ввиду этого задал ограничения вида "одна заявка - один лот" и "цена заявки не выше 5000". И ограничение на долю одной бумаги в портфеле - не более 25%, которое регулярно нарушается при продаже чего-нибудь, но, собака, мешает наращиванию позиций.