VPM (Все сообщения пользователя)

Всем чем можем управлять это риск! От него и строим сделку.На срочном после дневного клиринга даже бывает > 100% вложение, но я такое не люблю и уменьшаю позиции.
Кстати Вы не считаете показатель из таблицы "состояние счета" "% Испол.ГО". Не могу понять как правильно?

Ну тут работает Ваше правило 300 * 9 = 2700 или 1/2700 капитала с работала на  90.4% в день.  

На фондовом у меня инвестиционный подход. А рассказываю я про срочный (спекулятивный подход). Сейчас торгую руками отслеживаю в основном 4 тикера, которые котируются  в USD, для того чтоб оценить результаты одним взглядом т.е. посчитать пункты. А от 300 * 9 через пять минут можно в обморок упасть
Для сравнения на стадии отладки пишу в скрипт тоже 4 , позволяет сравнивать два подхода!  

Это так, вот только задача и заключается у знать как надо? Сейчас делаю подход от обратного.  

Я не про воровство, я чтоб не портили задумку автора, а потом жаловались , что не так все работает, про не опытность!

Вы же сами говорите об эффективности использования капитала, а у Вас получается какую - то часть замораживаете на месяц, пусть даже небольшую, а зачем?

У фьючерса есть еще одна особенность, чем дальше срок исполнения, тем больше отклонение от справедливой цены! По мере приближения срока исполнения его цена будет смещаться в сторону цены актива!

1) Почему в кубышке? 20 инструментов * 5% капитала = 100% Капитала на 20 инструментов.
2) Как не зависит, у каждого инструмента своя комиссия.
Но я даже не об этом. Представим, дневной диапазон одного инструмента  в среднем ходит в день на 100 пунктов что составляет 2% изменения в цене.
Мой Вариант чтоб взять 100 пунктов мне нужен 1 контракт, (2%), если риск позволяет получить 500 пунктов мне нужно 5 контракт (5*2%) и т.д.
Ваш вариант так как тайм фреймы для принятия решений небольшие, а удержание позиции не значительное, то ценна на них делает несколько небольших колебаний, для простоты скажем 0.5%,
для того чтоб набрать 2% нужно сделать 4 сделки (4 комиссии).

У меня это просто отдельный класс (таблица), то что пользователь задает , отвечает на вопросы , где торговать?, чем торговать? Какие средства использовать? и т.д.
Я до пересмотра этого еще не дошел (у маркетмейкера структура, а я один )  Возможно далее что то автоматизирую.

Но сейчас актуально проблема как правильно организовать работу с получением хранением и обработкой РЫНОЧНЫХ данных! Что делать с памятью которая растет значительно к концу торгового дня (сессии)?
Именно этот пример и привожу!

Согласен, но я так делаю пока для себя и для отладки , просто так удобней пока, и от этого принципиально не что не меняется. Но а если передавать код другому лицу, еще и пароль поставлю, чтоб не лазили!  

DS[1][4][n].cc=n>1 and round(DS[i][j]:C(n) - DS[i][j]:C(n-1), feed[i].sec_scale) or 0;

feed[i].sec_scale -- это параметр тиккера sec_scale
feed[i]. -- это таблица необходимых параметров? получаю при инициализации и обновляю при каждом обращении к инструменту (feed[i].bid)

Здесь нужно сказать, что у меня не одна глобальная таблица, а несколько и по возможности локальных + классы.
Может этим ввел в заблуждение? Пока не вижу смысла собирать все в одну (придерживаюсь своего взгляда, принципиальную схему я показывал Выше)

Именно так при получении данных и их подготовке.

DS[1][4][n].cc=n>1 and round(DS[i][j]:C(n) - DS[i][j]:C(n-1), feed[i].sec_scale) or 0;
1 -- первый тикер, 4 тайм фрейм, n- последний бар , n-1 предпоследний бар.
Я не понимаю что Вас смущает здесь?

А далее просто

if rule[i].open_buy and OrderSmart[i].position<=0 then --Открыть позицию

У меня их не 3 это для простоты изложения, но точно не 300, к примеру для фондового рынка я установил правило ~ 5% Капитала на инструмент,  100% / 20% <= 20 бумаг в портфеле.
В Вашем варианте  Капитал =100% / 300 бумаг <= 0.33% капитала  на 1 бумагу? Но мне помнится у Вас еще нужно 300 * 9 тайм фреймов, считайте сами на кого работаете (комиссии).

ДА и на срочном 300 инструментов не нужны достаточно ликвидных. А стоимость позиции регулируется количеством контрактов, и зависит от риска принимаемого в данной позиции!
Согласен есть некоторые сложности CreateDataSource, но к моему удивлению оказались не такими тяжелыми как предполагал ранее, видимо потому что лежат на сервере.
Получаю так ds:SetEmptyCallback(); С памятью надо подчищать пока пробую варианты.

В чем разница считывать из файла, или читать таблицу прямо из скрипта, кроме как удобства?
local sec   = { 'BRG4','NGF4', 'GDH4',  }; for i=1,#sec do  

Согласен i,j пропустил, (но они вроде и так локальные для цикла),
sec и tf видимость ведь позволяет держать локальными?

Ну если считать то к примеру Н4 то не одной сделки не сделаешь, нужно тогда историю записывать и сохранять!

А как нужно?

Владимир,  Не "покладая рук" а Вы?  
А что не так?

DS[i][j][n]
На мой взгляд все логично, у каждого инструмента есть несколько тайм фреймов, в каждом тайм фрейме есть несколько баров (индексов), такая вложенность (матрешка), а дальше идут переменные  или еще таблицы! Что не так?

"Таблицы в Lua — это не одна из структур данных, — это единственная структура данных".
"Таблицы - это всё.
Хотя, на самом деле, таблицы это просто способ хранить множество пар "ключ-значение", а все остальное - это то, какие вы выбираете ключи и какие значения."

Glukator,  Я не пишу новый код, оптимизирую старый, переосмысливаю, какие - то моменты.
У меня сейчас организовано так  

local sec   = { 'BRG4','NGF4', 'GDH4',  };
local tf = { INTERVAL_M1, ---- 1 минута  
INTERVAL_M4, ---- 4 минуты
INTERVAL_H1, ---- 1 час
INTERVAL_D1, ---- 1 день
--INTERVAL_W1, ---- 1 неделя
--INTERVAL_MN1, ---- 1 месяц
};

local DS = {};

for i=1,#sec do --Заказываю Данные
    DS[i]={};
    for j=0,#tf do
           DS[i][j] = Source(cl[1],sec[i],tf[j]); --CreateDataSource


--получаю
for i=1,#sec do    
     for j=#tf,1,-1 do

          I[i][j] = DS[i][j]:Size();
           local n;
           n = I[i][j];

            DS[i][j][n] = {}
            DS[i][j][n].d = get_date(DS[i][j]:T(n))
            DS[i][j][n].t = get_time(DS[i][j]:T(n))
            DS[i][j][n].p=round((DS[i][j]:H(n) + DS[i][j]:L(n))*0.5, feed[i].sec_scale);
            DS[i][j][n].hl=round(DS[i][j]:H(n) - DS[i][j]:L(n), feed[i].sec_scale);
            DS[i][j][n].co=round(DS[i][j]:C(n) - DS[i][j]:O(n), feed[i].sec_scale);
            DS[i][j][n].cc=n>1 and round(DS[i][j]:C(n) - DS[i][j]:C(n-1), feed[i].sec_scale) or 0;
         
            --сюда же ответы от алгоритмов присваиваю
           local Pdf = f[i][j].pdf( n, {period=4,v_t='M',up=1.5, dw=-1.5}, DS[i][j] )
            DS[i][j][n].pdf=Pdf;

Отсюда и структура

Glukator, Согласен, Ну конечно все так и делают!  Именно этим и занимаюсь,  собираю отдельные переменные в таблицы. Цель максимально локализовать переменные.
От этого тоже отказался лишнее bar={};  bar[ticer][tf][inde[]={};  Все уже и так есть.  

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

Склоняюсь к варианту А (подход  Владимир,), подход опробован,  как утверждает Владимир, показывает отличный результат, такое дерево всегда можно в последующим более аккуратно наследовать в глобальную таблицу. Подход Б требует дополнительного ознакомления, что можно чего нельзя. И так решено подход А, соберу в четырех этажную таблицу переменные.
bar={};  bar[ticer][tf][inde[]={};  

Пересмотрел главу Окружение.
"Поскольку окружение — это обычная таблица, то вы можете просто индексировать ее нужным ключом (именем переменной).
Похожим образом можно присвоить значение глобальной переменной, чье имя вычисляется динамически, если написать
_G[varname] = value."

Есть еще одна интересная "штука":
"Поскольку _ENV — это обычная переменная, мы можем обращаться к ней и присваивать значения как и любой другой переменной.
Присваивание _ENV=nil сведет на нет любой прямой доступ к глобальным переменным в оставшейся части куска. Это может пригодиться для контроля над тем, какие переменные использует ваш код"
"Конечно, главной областью применения _ENV является изменение окружения, используемого фрагментом кода."

Явно кокая - то ошибка, или это простое присвоение или профессор что то напутал?
Возможно это имелось ввиду? Не понятно.

_G[varname] = varname;
local value = _G[varname] ;
print(value)

nikolz,  Ну это просто аппроксимация в черном ящике? Если конечно в учителях не паттерны.Не понятно в чем мерите и относительно чего?

for n in pairs(_G) do print(n) end;   А так можно узнать какие глобальные переменные используются.
Понимание организационной структуры приводит к пониманию, установлению компромисса между быстродействием и производительностью, ну и не забываем про простоту кода.

 "Едем дальше, видим больше!"   1)  Структура:
Итак, вплотную подошли к вопросу организации структуры данных в скрипте.
Из того что выше обсуждалось можно сделать вывод, есть два подхода:

А) Создать внутреннею переменную (таблицу) и уже внутри нее строить дерево.

Б) Создать в глобальном окружении, служебные поля для переменных данного скрипта;
Про такой подход подсказал Игорь М,  описан автором языка в его книге, и применяется разработчиками QUIK при создании модуля qlua.
Вот такие две записи идентичны:

local varname = 20
local value = load or loadstring("return " .. varname)()
print(value)

Более эффективная:
_G[varname] = value
local value = _G[varname]
print(value)

Да я так делаю, еще получаю используемую память, а в главное окно скрипта вывожу прямо в заголовок окна, удобно всегда перед глазами информация как работает скрипт.

"Повторение мать ученья"! Благодарю за обсуждение и ликбез, не которые мои сомнения развеялись, понятно стало в какую сторону копать. Надеюсь что обсуждение было полезно не только мне.

Владимир, Ну тогда получается, что и голову "ломать" не стоит, пихай все в оперативную и все дела? Ну да еще можно подчищать так?

nikolz, Наоборот прозрел, за скоростью не гоняюсь , тогда чем можно руководствоваться и как наилучшим (оптимальным) образом организовать память?

И так если провести промежуточную черту о выше сказанном:

1)  Структура;
2) Хранение данных:
3) Парсер:
4) Дамп текущего состояния.

И все же остался не раскрыт вопрос как эффективно, распоряжаться памятью, хотя не которые моменты прорезались?  

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

Игорь М, написал  value = _G[varname]

Такой подход встречал в работах Nikolay, Не очень понятно зачем лезть в поле глобальной переменной, предполагал что ради видимости.
Но не как не могу себе предположить, что это более эффективно, тогда возможно нужно дерево сделать как  Владимир,  ("Волки сыты и овцы целы")?

Вроде уловил смысл.

Игорь М,  Да нет в книге то, не понятно как в жизни этим пользоваться, чем руководствоваться можно какой - то не большой пример?
Это что писать в глобальную переменную?
Ну к примеру вот:
Сделал класс, написал под него метод , вот использую Ну ведь удобно же.

Если Вы про парсер который освещали в начале своих публикаций, то я  на нем "зуб потерял"?
Дамп текущего состояния, вообще не понятно что туда писать, почему через 3 минуты сохранять, нужен какой - то подход?

При организации структуры программы в виде классов, проявилась еще одна особенность lua!
В случае обнаружения при выполнении ошибки, скрипт останавливается, там где раньше перепрыгивал через эту ошибку и продолжал выполнение.
Нашел этому объяснение, хочу поделиться:

"Errare humanum est. Поэтому мы должны обрабатывать ошибки как можно лучше.
Поскольку Lua — это язык расширения, часто встраиваемый в приложение, он не может просто аварийно завершить работу или завершить работу в случае возникновения ошибки.
Вместо этого при возникновении ошибки Lua завершает текущий фрагмент и возвращается в приложение."

"Любое неожиданное условие, с которым сталкивается Lua, вызывает ошибку.
Ошибки возникают, когда вы (то есть ваша программа) пытаетесь добавить значения, не являющиеся числами, вызвать значения, не являющиеся функциями, индексировать значения, не являющиеся таблицами, и т. д. (Вы можете изменить это поведение с помощью метатаблиц , как мы увидим позже.)
"
Стало чуть сложней искать, но появилась уверенность, что программа с ошибками не будет исполняться!

nikolz,  Спасибо попробую!

Владимир,  Вы подняли сейчас, очень нужную техническую тему и даже не одну, там где для Вас вещи очевидные, для меня и таких как я полная "тьма". Вопрос такой, не вдаваясь сильно в детали, есть какие - то критерии оценки какие переменные куда целесообразно относить,  

Я вообще не понимаю в чем различие loadfile от load в каком случае чем пользоваться (может есть какие то критерии) ???

Ну здесь все просто, если читать из файла f:read("a") получим строковой формат, перевод в функцию и чтение из функции позволяет работать в формате таблицы.
Не знаю насчет элегантности, но очень удобно при дальнейшей обработке.  

Вроде как заработало , кому нужно вот

для 5.1
local tbl = assert(loadstring("return "..f:read("*a")))
для 5.4
local tbl = assert(load("return "..f:read("a")))

Glukator,  Я этим пользовался в lua 5.1 при переходе на 5.4 перестало работать, вот смысл:
https://bot4sale.ru/blog-menu/qlua/301-save-lua-table.html

file:read (···)

Считывает файл fileв соответствии с заданными форматами, которые определяют, что читать. Для каждого формата функция возвращает строку или число с прочитанными символами или завершается ошибкой , если она не может прочитать данные в указанном формате. (В последнем случае функция не считывает последующие форматы.) При вызове без аргументов она использует формат по умолчанию, который считывает следующую строку (см. ниже).

Доступные форматы

• « a»: читает весь файл, начиная с текущей позиции. В конце файла возвращается пустая строка; этот формат никогда не подводит.
  

----- Чтение таблицы из файла в массив или таблицу
  --message(filename)
  local f,err = io.open(filename,"r")--"r": режим чтения (используется по умолчанию);
  if not f then
     return nil,err
  end
  local tbl = assert(load("return "..f:read("a")))--"a": режим дозаписи в конец файла
  f:close()

Никак не могу понять, что изменилось в lua 5.4 и перестала работать строка, подскажите что тут не так?

local tbl = assert(load("return "..f:read("a")))

РАЛЬФ ВИНС - "Математика управления капиталом"  
Результат приличный!  Только годовые считать узкая оценка! Но об в следующий раз.

Есть какие то первые результаты за период которые можно оценить? Ральфа Винца не читали?

Ну к примеру сделка прошла (не обязательно закрытие но и уменьшение позиции) я сохраняю в таблицу такие показатели (Выиграла +1 Проиграла -1,), то есть количество выиграны и проигранных сделок, плюс сам результат, это позволяет делать оценку торговой системы, как я уже приводил?

Glukator,  А вы сделки каким либо образом оцениваете, я имею ввиду результат?