Система принятия решений и/или Нечеткая логика(FuzzyLogic)

Страницы: Пред. 1 2 3 4 5 6
RSS
Система принятия решений и/или Нечеткая логика(FuzzyLogic), Нечеткая логика или Система принятия решений в трейдинге
 
Trbot,  Вы правы, мой подход  тоже такой, нашел интересное встрял, если с ходу не получилось разобраться, вход идут "молоток и отвёртка", остались лишние запасные части "капиталисты перемудрили" - все ведь работает, ну а если не работает берем в руки инструкции и буквари. :smile:  Касаемо, обсуждения, по мне так Вы перемудрили, не наверно подобная стратегия возможна, где ни будь на мало ликвидном  рынке, но даже для этого, чтоб ее реализовать 1. нужны приличные средства; 2. команда амбициозных единомышленников из разных сфер; 3. инсайд. Возможно кто из маркетмейкеров и реализует,  подобное но это очень сложно. У меня все гораздо проще, целый день тестирую одну стратегию, не идет ни как, "пялиться в экран  занятие грустное, вот и пишу всякую чушь". :wink:  
 
Для тех кто торговал сегодня Si, я на нем проводил тесты, делаем ставки, про тестировали уровень сопротивления, собрали ликвидность вернемся в зону 86700 - 86800, и все до свидание налоги, куда кривая вынесет! :smile:  
 
Код
function Cached.Roofing_Filter()
    -- Локальные таблицы для хранения данных между вызовами
    local Price, HP, SSF, Lead = {}, {}, {}, {}
    local alpha1, a1, b1, c2, c3, c1 = 0, 0, 0, 0, 0, 0
    local I1 = 0  -- Индекс предыдущего бара

    -- Функция для ограничения размера таблицы
    local function limit_table_size(tbl, max_size)
        while #tbl > max_size do
            table.remove(tbl, 1)
        end
    end

    return function(I, FSettings, ds)
        -- Параметры
        local I = I or 1
        local ds = ds or nil
        local FSettings = FSettings or {}
        local v_t = FSettings.v_t or 'C'
        local P = FSettings.period or 48
        local N = FSettings.N or 10
        local x = FSettings.x or nil

        -- Текущая цена
        local p0 = x or Value(I, v_t, ds) or 0

        -- Проверка смены бара
        local newbar = I > I1
        if newbar then
            -- Обновление индекса бара
            I1 = I

            -- Инициализация на первом баре
            if I == 1 then
                Price, HP, SSF, Lead = {}, {}, {}, {}
                Price[I], HP[I], SSF[I], Lead[I] = p0, 0, 0, 0
                local fi = (0.707 * 2 * math.pi / P)
                alpha1 = (math.cos(fi) + math.sin(fi) - 1) / math.cos(fi)
                a1 = math.exp(-1.41421356 * math.pi / N)
                b1 = 2 * a1 * math.cos(1.41421356 * math.pi / N)
                c2, c3, c1 = b1, -a1 * a1, 1 - c2 - c3
            else
                -- Обновление цены
                Price[I] = p0

                -- Разница цен для выделения высокочастотных компонентов
                local p1 = Price[I - 1] or p0
                local p2 = Price[I - 2] or p1
                local noise = p0 - 2 * p1 + p2

                -- Расчет HP-фильтра
                local hp1 = HP[I - 1] or 0
                local hp2 = HP[I - 2] or hp1
                local hp = (1 - alpha1 / 2) * (1 - alpha1 / 2) * noise + 2 * (1 - alpha1) * hp1 - (1 - alpha1) * (1 - alpha1) * hp2
                HP[I] = hp

                -- Расчет SuperSmoother
                local ssf1 = SSF[I - 1] or 0
                local ssf2 = SSF[I - 2] or ssf1
                local ssf = c1 * (hp + hp1) * 0.5 + c2 * ssf1 + c3 * ssf2
                SSF[I] = ssf

                -- Расчет опережающего сигнала (Lead)
                local lead1 = Lead[I - 1] or 0
                local lead = 2 * ssf - 1 * ssf2
                Lead[I] = lead
            end

            -- Ограничение размера таблиц
            limit_table_size(Price, 3)  -- Храним только последние 3 бара
            limit_table_size(HP, 3)
            limit_table_size(SSF, 3)
            limit_table_size(Lead, 3)
        end

        -- Возвращаемые значения
        return Lead[I] or 0, SSF[I] or 0
    end
end
Это реализация Roofing Filter, который состоит из двух основных компонентов:
  1. HP Filter (High-Pass Filter): Настроен на цикл 48 баров, чтобы ослабить более длительные периоды.

  2. SuperSmoother Filter: Настроен на цикл 10 баров, чтобы ослабить более короткие периоды.

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

Что не так с ним, в торговой стратегии подобных фильтраций несколько, особенностью QUIK - индикатор вызывается в функции обратного вызова, которая может вызываться несколько раз в рамках одного бара, при поступлении новых тиков. Если таблицы Price, HP, SSF, Lead инициализировать внутри возвращаемой функции, они будут сбрасываться при каждом вызове, что приведет к потере данных. Для корректной работы индикатора в QUIK нужно сохранять состояние между вызовами. Это можно сделать, используя локальные таблицы вне возвращаемой функции, но при этом ограничивать их размер, чтобы избежать утечек памяти.

Что смущает в этой реализации, Быстродействие?  

 
Это реализация из под кальки примеров расчёта индикаторов от ARQA. Они не столь удачны.

Для начала, если используется замыкание, то зачем же каждый раз передавать FSettings, ds. Это условно постоянные переменные. Они не изменятся для созданного экземпляра.
Значит их можно передавать только при инициализации, а значит и параметры определить один раз. Постоянно изменяемая величина - это индекс, вот только её и передавать в экземпляр расчёта.

Метод table.remove не самый быстрый - очень не быстрый. Хотя, наверно, в рамках Квик это не столь критично, тем более, что расчёт раз в бар. Я предпочитаю просто очищать данные в таблицах, сборщик мусора освободит память.

Также я предпочитая возвращать инициализированный метод расчёта и таблицы, хранящие данные (в данном случае это Lead и SSF). Их необходимо иницализировать один раз и тогда всегда будет под рукой ссылка на весь массив данных, а нее только возвращаемые последние.

Для примера:
local fCalc, Lead, SSF = Cached.Roofing_Filter(FSettings, ds)

И тогда расчёт выглядит элементарно:

fCalc(index)


А использование данных:

Lead[index], Lead[index-2]  и т.д. Ссылка же неизменная, а значит нет необходимости получать из метода расчёта что-то ещё, засоряя память.
 
Nikolay,  Вот сам вызов, я в принципе  всегда так делаю.
Settings={}
Settings.Name = "1Roofing_Filter"
Settings.v_t = "O"
Settings.period = 48
Settings.N = 10
--Settings.avto = 0 -- 1 adapt

local f
function Init()
local cached=dofile("C:\\cached.lua")
f = cached.Roofing_Filter()
cached=nil
Settings.line = {
{Name = "lead",          Color = RGB(0, 0, 0),   Type = TYPE_LINE, Width = 1},
{Name = "Roofing_Filter",Color = RGB(255, 0, 0), Type = TYPE_LINE, Width = 1},

}
return #Settings.line
end

function OnCalculate(index)
return f(index, Settings)
end
То есть с начало нужно инициализировать, а затем возвращаю замыкание. Если же  Settings перенести Roofing_Filter(Settings), то перестает работать Settings.period  когда индикатор на графике?  
 
Если речь про индикатор, то необходимо использовать метод OnChangeSettings и реинициализировать метод расчёта.

Я индикаторы редко использую, так что подход больше для скриптов.
 
Цитата
Nikolay написал:
Если речь про индикатор, то необходимо использовать метод OnChangeSettings и реинициализировать метод расчёта.
Даже не заметил когда метод добавили. Попробую Ваши рекомендации и этот метод.
Цитата
Nikolay написал:
Метод table.remove не самый быстрый - очень не быстрый. Хотя, наверно, в рамках Квик это не столь критично, тем более, что расчёт раз в бар.
Метод table.remove добавил для простоты кода, да и что он делает, двигает 3 бара, в рабочем варианте,  моя любимая двух факторная очередь, не плохо зарекомендовала себя.
Цитата
Nikolay написал:
Я предпочитаю просто очищать данные в таблицах, сборщик мусора освободит память.
Вы имеете в виду такой подход        Table[I] = x  if I > I - 3 then Table = nil end

Индикаторы удобны для визуализации кода.  
 
Цитата
VPM написал:
Вы имеете в виду такой подход        Table = x  if I > I - 3 then Table = nil end
Просто t[i-3] = nil

Проверять не обязательно. Если всего три элемента, то да, можно и удаление со сдвигом использовать. Хотя? т.к. в таблицах Вы храните не числа 1, 2, 3, а номера индекса ... 1001, 1002, 1003 и т.д.,
то после сдвига выйдет 1001 = nil, 1002, 1003, 1004. Что равносильно t[1004-3] = nil
 
Цитата
Nikolay написал:
Просто t[i-3] = nil
Такая операция не освобождает память
Вы просто в записываете тип элемента равным 0.
Но элемент остается в таблице.
 
каждый элемент таблицы это

#define TValuefields    Value value_; int tt_


typedef struct lua_TValue {
 TValuefields;
} TValue;

t[i-1]=nil  это   операция tt_=0  и все
 
Цитата
nikolz написал:
Цитата
Nikolay написал:
Просто t[i-3] = nil
Такая операция не освобождает память
Вы просто в записываете тип элемента равным 0.
Но элемент остается в таблице.
Код
t = {'a','b','c'}
t[2] = nil
for k,v in pairs(t) do print(k,v) end

элемента с номером 2 нет

 
Nikolay,  Кручу, верчу, откровенно туплю, вот этот момент:
Цитата
Nikolay написал: Также я предпочитая возвращать инициализированный метод расчёта и таблицы, хранящие данные (в данном случае это Lead и SSF). Их необходимо иницализировать один раз и тогда всегда будет под рукой ссылка на весь массив данных, а нее только возвращаемые последние.Для примера:local fCalc, Lead, SSF = Cached.Roofing_Filter(FSettings, ds)И тогда расчёт выглядит элементарно:fCalc(index)А использование данных:Lead[index], Lead[index-2] и т.д. Ссылка же неизменная, а значит нет необходимости получать из метода расчёта что-то ещё, засоряя память.
Если не сложно, покажите на примере кода выше, Вашу реализацию фильтра. Как должно выглядеть?
 
Цитата
nikolz написал:
Такая операция не освобождает память
Вы просто в записываете тип элемента равным 0.
Но элемент остается в таблице.
Так, да не совсем так. Это зависит от того в какую область попадёт ключ - в в массив или в хеш-мап Т.к. такая операция эмпирически проверена, и collectgarbage('count') явно показывает разницу, то в данном случае расход памяти уменьшается.

Для теста вот код, можно запустить как в чистом lua (тогда раскомментировать вызов main), так и в терминале.

Код
local last = os.clock()
print = _G.message or print

local sleep = sleep or function(ms)
    last = os.clock()*1000
    while (os.clock()*1000 - last) < ms do
    end
end

local tt1 = {}
local tt2 = {}

local test = function()

    for n = 1,10000 do
        tt1[n] = 100.12345
    end

    print('1. mem '..collectgarbage('count'))

    tt1 = nil

    collectgarbage()
    sleep(10)

    print('2. mem '..collectgarbage('count'))

    for n = 1,10000 do
        tt2[n] = 100.12345
        tt2[n-3] = nil
    end

    print('3. mem '..collectgarbage('count'))

    collectgarbage()

    sleep(10)

    print('4. mem '..collectgarbage('count'))
end

function main()
    test()
    sleep(1000)
end

-- main()


1. mem 279.5498046875
1. mem 23.5576171875
3. mem 23.787109375
4. mem 23.7060546875
5. mem 23.787109375


Впрочем, для массивов фиксированного размера просто применяются кольцевые буферы.
 
paluke,  Я тоже проверил, действительно второй элемент зачищен? Хотя структура таблицы должна  сохраниться, как утверждает nikolz,?
 
Цитата
VPM написал:
Если не сложно, покажите на примере кода выше, Вашу реализацию фильтра. Как должно выглядеть?
Код
function Cached.Roofing_Filter(FSettings, ds)

    -- Параметры
    local ds = ds or nil
    local FSettings = FSettings or {}
    local v_t = FSettings.v_t or 'C'
    local P = FSettings.period or 48
    local N = FSettings.N or 10
    local x = FSettings.x or nil

    -- Локальные таблицы для хранения данных между вызовами
    local Price, HP, SSF, Lead = {}, {}, {}, {}
    local alpha1, a1, b1, c2, c3, c1 = 0, 0, 0, 0, 0, 0
    local I1 = 0  -- Индекс предыдущего бара

    -- Функция для ограничения размера таблицы
    local function limit_table_size(tbl, max_size)
        while #tbl > max_size do
            table.remove(tbl, 1)
        end
    end

    return function(I)
        -- Текущая цена
        local p0 = x or Value(I, v_t, ds) or 0

        -- Проверка смены бара
        local newbar = I > I1
        if newbar then
            -- Обновление индекса бара
            I1 = I

            -- Инициализация на первом баре
            if I == 1 then
                Price[I], HP[I], SSF[I], Lead[I] = p0, 0, 0, 0
                local fi = (0.707 * 2 * math.pi / P)
                alpha1 = (math.cos(fi) + math.sin(fi) - 1) / math.cos(fi)
                a1 = math.exp(-1.41421356 * math.pi / N)
                b1 = 2 * a1 * math.cos(1.41421356 * math.pi / N)
                c2, c3, c1 = b1, -a1 * a1, 1 - c2 - c3
            else
                -- Обновление цены
                Price[I] = p0

                -- Разница цен для выделения высокочастотных компонентов
                local p1 = Price[I - 1] or p0
                local p2 = Price[I - 2] or p1
                local noise = p0 - 2 * p1 + p2

                -- Расчет HP-фильтра
                local hp1 = HP[I - 1] or 0
                local hp2 = HP[I - 2] or hp1
                local hp = (1 - alpha1 / 2) * (1 - alpha1 / 2) * noise + 2 * (1 - alpha1) * hp1 - (1 - alpha1) * (1 - alpha1) * hp2
                HP[I] = hp

                -- Расчет SuperSmoother
                local ssf1 = SSF[I - 1] or 0
                local ssf2 = SSF[I - 2] or ssf1
                local ssf = c1 * (hp + hp1) * 0.5 + c2 * ssf1 + c3 * ssf2
                SSF[I] = ssf

                -- Расчет опережающего сигнала (Lead)
                local lead1 = Lead[I - 1] or 0
                local lead = 2 * ssf - 1 * ssf2
                Lead[I] = lead
            end

            -- Ограничение размера таблиц
            limit_table_size(Price, 3)  -- Храним только последние 3 бара
            limit_table_size(HP, 3)
            limit_table_size(SSF, 3)
            limit_table_size(Lead, 3)
        end

        -- Возвращаемые значения
        return Lead[I] or 0, SSF[I] or 0
    end, Lead, SSF
end

local fAlgo, Lead, SSF = Cached.Roofing_Filter(FSettings, ds)
 
Цитата
VPM написал:
paluke,  Я тоже проверил, действительно второй элемент зачищен? Хотя структура таблицы должна  сохраниться, как утверждает nikolz,?
Он говорит о другом. Действительно, если инициализировать чистый массив, заполняя элементы последовательно, не допуская дырок, то тогда даже если пройтись по массиву и установить nil для каждого элемента, то память не освободится. Если же заполнять дырявую таблицу (а после третьего элемента она уже будет с дыркой), то это уже не массив и тогда мусорщик работает иначе.
 
Нашел, кому как и мне нужно более подробно!

"В Lua таблицы представляют собой ассоциативные массивы, которые могут хранить значения различных типов. Каждый элемент таблицы в Lua может быть представлен структурой TValue, которая содержит два основных поля:
  1. Value value_ — это поле, которое хранит значение элемента. В зависимости от типа, это может быть число, строка, указатель на другую структуру и т.д.

  2. int tt_ — это поле, которое хранит тип значения (например, LUA_TNIL, LUA_TNUMBER, LUA_TSTRING и т.д.).

Когда вы выполняете операцию t[i-1] = nil, это означает, что вы удаляете элемент из таблицы по индексу i-1. Внутри Lua это приводит к тому, что значение элемента устанавливается в nil, а тип (tt_) устанавливается в LUA_TNIL (который обычно соответствует значению 0).

Таким образом, операция t[i-1] = nil эквивалентна следующему:

  • Установка value_ в какое-то "пустое" значение (в случае nil это может быть просто 0 или NULL).

  • Установка tt_ в 0 (что соответствует типу LUA_TNIL).

Это означает, что элемент таблицы больше не содержит полезного значения и считается "удаленным" или "пустым"."
 
Nikolay,  Благодарю, это супер удобно:
Код
-- Возвращаемые значения
        return Lead[I] or 0, SSF[I] or 0
    end, Lead, SSF
end

local fAlgo, Lead, SSF = Cached.Roofing_Filter(FSettings, ds)
1) return Lead[I] or 0, SSF[I] or 0 можно использовать в индикаторах
2) end, Lead, SSF возвращает сам алгоритм и таблицы полностью, можно допустим выгружать в электронные таблицы и там обрабатывать и анализировать.
Супер!
Надо проверить будет ли этот подход в режиме индикатора пересчитывать если изменять, допустим период или другие задания?
 
Конфликт имен при работе с DDE-сервером и одновременном использовании нескольких терминалов QUIK. DDE —  один из старейших протоколов, и его использование может быть нестабильным.
Возможность использования более продвинутых методов интеграции, например таких как: Экспорт данных в файлы (CSV, TXT) средствами Lua, с последующей загрузкой в Excel или Блокнот.
На тыкается на проблему, чтения самой таблицы "состояние счета", или я опять что то пропустил?
 
Цитата
Nikolay написал:
local last = os.clock()
print = _G.message or print

local sleep = sleep or function(ms)
   last = os.clock()*1000
   while (os.clock()*1000 - last) < ms do
   end
end

local tt1 = {}
local tt2 = {}

local test = function()

   for n = 1,10000 do
       tt1[n] = 100.12345
   end

   print('1. mem '..collectgarbage('count'))

   tt1 = nil

   collectgarbage()
   sleep(10)

   print('2. mem '..collectgarbage('count'))

   for n = 1,10000 do
       tt2[n] = 100.12345
       tt2[n-3] = nil
   end

   print('3. mem '..collectgarbage('count'))

   collectgarbage()

   sleep(10)

   print('4. mem '..collectgarbage('count'))
end

function main()
   test()
   sleep(1000)
end

-- main()
Вы ошибаетесь. Ваш пример не соответствует Вашему t3[i=3]=nil
----------------
В Вашем тесте есть оператор tt1=nil  (стр 21)
Именно этот оператор освободит память так как он обнуляет ссылку на таблицу , т е массив из кучи становится без ссылки.
Его и удаляет сборщик.
---
если закомментировать tt1=nil.
то результат:
-------------
1. mem 285.5576171875
2. mem 284.5439453125
3. mem 284.751953125
4. mem 284.6689453125
------------
никакой очистки нет, как я Вам и написал.
 
Цитата
VPM написал:
Нашел, кому как и мне нужно более подробно!

"В Lua таблицы представляют собой ассоциативные массивы, которые могут хранить значения различных типов. Каждый элемент таблицы в Lua может быть представлен структурой TValue, которая содержит два основных поля:   Value value_ — это поле, которое хранит значение элемента. В зависимости от типа, это может быть число, строка, указатель на другую структуру и т.д.    int tt_ — это поле, которое хранит тип значения (например, LUA_TNIL, LUA_TNUMBER, LUA_TSTRING и т.д.).    Когда вы выполняете операцию t[i-1] = nil, это означает, что вы удаляете элемент из таблицы по индексу i-1. Внутри Lua это приводит к тому, что значение элемента устанавливается в nil, а тип (tt_) устанавливается в LUA_TNIL (который обычно соответствует значению 0).  Таким образом, операция t[i-1] = nil эквивалентна следующему:    Установка value_ в какое-то "пустое" значение (в случае nil это может быть просто 0 или NULL).    Установка tt_ в 0 (что соответствует типу LUA_TNIL).   Это означает, что элемент таблицы больше не содержит полезного значения и считается "удаленным" или "пустым"."
Вы очевидно не поняли, то что цитируете.
-----------------
Внутри Lua это приводит к тому, что значение элемента устанавливается в nil, а тип (tt_) устанавливается в LUA_TNIL (который обычно соответствует значению 0).
----------------
Поясняю.
Т е это означает лишь то, что тип элемента стал равный нулю.
Но само значение если это не указатель на таблицу или функцию хранится тоже в TValue. Поэтому ничего не освобождается,
Если это указатель таблицу, то место в памяти освободится лишь при условии, что эта таблица больше нигде не используется.  
 
Цитата
nikolz написал:
Вы ошибаетесь. Ваш пример не соответствует Вашему t3[i=3]=nil
----------------
В Вашем тесте есть оператор tt1=nil  (стр 21)
Именно этот оператор освободит память так как он обнуляет ссылку на таблицу , т е массив из кучи становится без ссылки.
Его и удаляет сборщик.
---
если закомментировать tt1=nil.
то результат:
-------------
1. mem 285.5576171875
2. mem 284.5439453125
3. mem 284.751953125
4. mem 284.6689453125
------------
никакой очистки нет, как я Вам и написал.
Я знаю, что без удаления ссылки самой таблицы, расстановка nil по элементам массива ничего не даст. Пример говорит о другом. Очистка всей таблицы собирает её всю, да. Но он добавлен для того, чтобы видеть какой объём занимает вся таблица, заполненная значениями double.

Второй пример показывает какой размер забирает скрипт при работе с таблицей с дырками. Именно такие и используются при расчёте по индексам ряда. Спорить желания нет, т.к. это эмпирически проверено, даже просто по наблюдаемому объёму занимаемой памяти в окне доступные скрипты.
 
Утро начал в борьбе с квик, квик победил. Пришлось переставлять, устранил одну из проблем, но видимо есть еще, зато с с моего скрипта снято подозрение. :smile:   Вариант
Цитата
Nikolay написал:
function Cached.Roofing_Filter(FSettings, ds)

   -- Параметры
   local ds = ds or nil
   local FSettings = FSettings or {}
   local v_t = FSettings.v_t or 'C'
   local P = FSettings.period or 48
   local N = FSettings.N or 10
   local x = FSettings.x or nil

   -- Локальные таблицы для хранения данных между вызовами
   local Price, HP, SSF, Lead = {}, {}, {}, {}
   local alpha1, a1, b1, c2, c3, c1 = 0, 0, 0, 0, 0, 0
   local I1 = 0  -- Индекс предыдущего бара

   -- Функция для ограничения размера таблицы
   local function limit_table_size(tbl, max_size)
       while #tbl > max_size do
           table.remove(tbl, 1)
       end
   end

   return function(I)
       -- Текущая цена
       local p0 = x or Value(I, v_t, ds) or 0

       -- Проверка смены бара
       local newbar = I > I1
не совсем подходит для реализации в индикаторе, все таки перестает работать таблица Settings в анонимной функции, видимо на то она и анонимна. Но подход взял на вооружение для алгоритмов.
Цитата
Nikolay написал:
Если речь про индикатор, то необходимо использовать метод OnChangeSettings и реинициализировать метод расчёта.
Показалось совсем не нужно или не понял как ею пользоваться?

Возник новая проблема:
Цитата
VPM написал:
Конфликт имен при работе с DDE-сервером и одновременном использовании нескольких терминалов QUIK. DDE —  один из старейших протоколов, и его использование может быть нестабильным. Возможность использования более продвинутых методов интеграции, например таких как: Экспорт данных в файлы (CSV, TXT) средствами Lua, с последующей загрузкой в Excel или Блокнот. На тыкается на проблему, чтения самой таблицы "состояние счета", или я опять что то пропустил?
неужели кроме как вывода таблицы состояния счета, нет других возможностей ее получения или ее параметров?
 
Цитата
VPM написал:
Показалось совсем не нужно или не понял как ею пользоваться?
Код
function _G.Init()
    PlotLines = Algo(_G.Settings)
    return 1
end
function _G.OnChangeSettings()
    _G.Init()
end

Тогда происходит реинициализация с новыми параметрами.
 
Цитата
Nikolay написал:
Цитата
nikolz написал:
Вы ошибаетесь. Ваш пример не соответствует Вашему t3[i=3]=nil
----------------
В Вашем тесте есть оператор tt1=nil  (стр 21)
Именно этот оператор освободит память так как он обнуляет ссылку на таблицу , т е массив из кучи становится без ссылки.
Его и удаляет сборщик.
---
если закомментировать tt1=nil.
то результат:
-------------
1. mem 285.5576171875
2. mem 284.5439453125
3. mem 284.751953125
4. mem 284.6689453125
------------
никакой очистки нет, как я Вам и написал.
Я знаю, что без удаления ссылки самой таблицы, расстановка nil по элементам массива ничего не даст. Пример говорит о другом. Очистка всей таблицы собирает её всю, да. Но он добавлен для того, чтобы видеть какой объём занимает вся таблица, заполненная значениями double.

Второй пример показывает какой размер забирает скрипт при работе с таблицей с дырками. Именно такие и используются при расчёте по индексам ряда. Спорить желания нет, т.к. это эмпирически проверено, даже просто по наблюдаемому объёму занимаемой памяти в окне доступные скрипты.
Хорошо, что признали.
------------------
Не увидел в вашем примере этого.
------------------
Что не так в этих данных.
1. mem 285.5576171875
2. mem 284.5439453125
3. mem 284.751953125
4. mem 284.6689453125
-----------------
Где Ваши доказательства?
Можете, не перескакивая, конкретно показать , что и как Вы сокращаете?
 
Цитата
nikolz написал:
Хорошо, что признали.
------------------
Не увидел в вашем примере этого.
------------------
Что не так в этих данных.
1. mem 285.5576171875
2. mem 284.5439453125
3. mem 284.751953125
4. mem 284.6689453125
-----------------
Где Ваши доказательства?
Можете, не перескакивая, конкретно показать , что и как Вы сокращаете?
Что я должен был признать? Впрочем, я уже ответил, что я не буду спорить. Мне хватает своих глаз для принятия решений. Вы можете продолжать спорить с другими.
 
Предложенный подход  paluke,  t[I-3] = nil (в место limit_table_size), разложений по полочкам Nikolay,  

Если просто обнулять элементы таблицы, например, t[I-3] = nil, это приведет к тому, что в таблице появятся "дыры" (nil-значения).  Да, не требуется сдвигать элементы, что может быть быстрее для больших таблиц. Но при этом таблица будет содержать "дыры", что может привести к ошибкам при использовании функций, ожидающих последовательности.  "В Lua таблицы с nil-значениями могут вести себя неожиданно, особенно при использовании функций, которые работают с последовательностями (например, #t, table.concat, ipairs). Память не освобождается сразу, так как в этом варианте Lua использует сборщик мусора для удаления nil-элементов. Это может привести к увеличению потребления памяти".

Из выше всего сказанного, делаем выводы.
1) limit_table_size подходит для небольших размеров таблиц
2) Подход таблица содержащая "дыры", подходит для конечных вычислений, не требующий передачи таблиц дальше для использования, как это показал нам Nikolay.
3) В подходе с выводом таблиц и функции, как это предложилNikolay,  на мой не профессиональный взгляд, лучше использовать альтернативный метод как это предлагают разработчики, использовать кольцевой буфер (circular buffer). В этом случае таблица имеет фиксированный размер, и новые элементы записываются поверх старых. Вариант, избежать использования limit_table_size, но при этом не хотите сталкиваться с проблемами nil-значений, в случае дальнейшего использования таблиц. Это наиболее эффективный способ управления памятью для задач, где требуется хранить только последние N элементов.
И чтоб не быть голословным вот пример.
Код
local function circular_buffer(tbl, max_size, index, value)
    local pos = (index - 1) % max_size + 1
    tbl[pos] = value
    return tbl[pos]
end

return function(I, FSettings, ds)
    local I = I or 1
    local ds = ds or nil
    local FSettings = FSettings or {}
    local P = FSettings.period or 9
    local v_t = FSettings.v_t or 'C'

    -- Текущая цена
    local p0 = Value(I, v_t, ds) or 0

    -- Инициализация на первом баре
    if I == 1 then
        Ema, iFich, Cu, Cd = {}, {}, {}, {}
    end

    -- Используем кольцевой буфер
    local ema1 = circular_buffer(Ema, P * 2, I - 1, p0)
    local ema0 = p0 * k + (1 - k) * ema1
    circular_buffer(Ema, P * 2, I, ema0)

    -- Остальная логика
    ...
end
 
Не стоит питать иллюзий: рынок — это не место для легких денег!
---------------------------------------------------------------------------------------------
Позволю себе немного по философствовать и высказать свое видение на инвестиции, но это только ради пользы общего дела.
Те кто сталкивался с финансовыми управляющими - аналитиками, знает что первым вопросом от них будет: "на какой временной горизонт планируете разместиться?"  И это не праздный вопрос, не много в суть него нас окунул TWG. Но я хочу начать рассуждать на эти вопросы с основ.

1) Открывая график в терминале, мы видим отражение цены во времени (массив), и это колебательный процесс, что в свою очередь равносильно волновой процесс.
Волновой процесс можно описать с помощь фазово - частотной характеристики.

2) Хаос и порядок
* Порядок — это система, где закономерности наблюдаемы и предсказуемы.
* Хаос — это не отсутствие порядка, а сложная система, которая кажется случайной из-за своей непредсказуемости. Однако в хаосе часто скрыты глубокие закономерности.

На финансовых рынках цены могут казаться хаотичными, но они подчиняются законам спроса и предложения, психологии толпы и макроэкономическим факторам. Изучая такую систему, пытаемся найти скрытые закономерности, анализируя графики, индикаторы и фундаментальные факторы. Даже в хаосе можно создать порядок, установив правила и рамки, торговая система с четкими правилами входа и выхода помогает избежать эмоциональных решений. Хаотичные системы часто меняются, поэтому важно быть гибким и готовым к изменениям (адаптироваться). Теория хаоса изучает, как малые изменения в начальных условиях могут привести к "эффект бабочки" (drastically different outcomes).

Философский взгляд, напоминает идеи стоицизма и даосизма:
 * Стоицизм: Принимайте то, что не можете изменить, и сосредоточьтесь на том, что можете контролировать.
 * Даосизм: Хаос и порядок — это две стороны одной медали (Инь и Ян). Они взаимосвязаны и дополняют друг друга. Хорошо, с практической стороны, разобраны в работе М.И. Беляева "Милогия".

Хаос — это не враг, а вызов. С ним также можно работать, если искать закономерности, создавать структуру и адаптироваться к изменениям. Если чувствовать баланс, найти тот самый ритм, вот и хаос обуздан.

* Баланс, на мой взгляд лучшее его описание - это бух. учет, нет не правила учета, а сама структура и построение этого учета, способного восстанавливать всю цепочку бинарных записей.
Ну и конечно бинарность хорошо известна в программировании.
* С РИТМОМ все значительно сложней, ритмом занимается - ритмодинамика. Волновая геометрия является базисом ритмодинамики. Основные постулаты РД совпадают с началами волновой геометрии.
Волновая геометрия, как инструмент, предоставляет возможность моделировать процессы самоорганизации простых и сложных систем без каких-либо специфических расчётов сил взаимодействия.
В основе моделирования лежит оценка состояния среды вокруг исследуемого осциллятора с последующим перемещением этого осциллятора в сторону области равновесия состояний.
Состояние среды описывается через амплитуду, фазу и частоту волн.
Вот мы и вернулись к математике, амплитуде, фазе и частоте волновых колебаний, балансу, ритму и ни какой философии. То есть можно писать алгоритм моделирования, и прогнозов, как это делается с помощь книги перемен или карт "Торо". И не каких чудес, практически одна математика - царица наук.
 
Цитата
VPM написал:
Открывая график в терминале, мы видим отражение цены во времени (массив), и это колебательный процесс, что в свою очередь равносильно волновой процесс.Волновой процесс можно описать с помощь фазово - частотной характеристики.
VPM, тут уже кто-то писал, что график цен - это не функция цены от времени и это не колебания. И тем более, это не волновой процесс. Волна - это распространение колебаний в пространстве.
График цены -  экспериментальные данные.
Хотя, если рассматривать формально (чисто формально), график цены, как  функцию от времени, то можно пробовать применять все мат методы (формально), которые применяются для анализа (обработки) таких графиков (мат функций).  Но термин волны тут вообще не уместен, на мой взгляд.  
А так-то Вы правы - в графике цены много чего отражается. Я имею ввиду различные механизмы влияния на цену. И все эти механизмы можно пытаться отлавливать с большим или меньшим успехом.
 
Цитата
VPM написал:
Предложенный подход  paluke,  t[I-3] = nil (в место limit_table_size), разложений по полочкам Nikolay,  

Если просто обнулять элементы таблицы, например, t[I-3] = nil, это приведет к тому, что в таблице появятся "дыры" (nil-значения).  Да, не требуется сдвигать элементы, что может быть быстрее для больших таблиц. Но при этом таблица будет содержать "дыры", что может привести к ошибкам при использовании функций, ожидающих последовательности.  "В Lua таблицы с nil-значениями могут вести себя неожиданно, особенно при использовании функций, которые работают с последовательностями (например, #t, table.concat, ipairs). Память не освобождается сразу, так как в этом варианте Lua использует сборщик мусора для удаления nil-элементов. Это может привести к увеличению потребления памяти".

Из выше всего сказанного, делаем выводы.
1) limit_table_size подходит для небольших размеров таблиц
2) Подход таблица содержащая "дыры", подходит для конечных вычислений, не требующий передачи таблиц дальше для использования, как это показал нам Nikolay.
3) В подходе с выводом таблиц и функции, как это предложилNikolay,  на мой не профессиональный взгляд, лучше использовать альтернативный метод как это предлагают разработчики, использовать кольцевой буфер (circular buffer). В этом случае таблица имеет фиксированный размер, и новые элементы записываются поверх старых. Вариант, избежать использования limit_table_size, но при этом не хотите сталкиваться с проблемами nil-значений, в случае дальнейшего использования таблиц. Это наиболее эффективный способ управления памятью для задач, где требуется хранить только последние N элементов.
Если nil элемент не таблица, то никакой памяти сборщик мусора не удаляет.
===========

Расскажу про свой  способ, который самый быстродействующий  для обработки событий колбеков , не имеет дыр, не требует работы сборщика, имеет ограниченный размер таблицы и не требует дополнительной синхронизации потоков.
-----------------.
1) Создаем очередь с двумя указателями для записи и чтения
2) колбеки помещают в эту очередь данные и ключ, если в очереди на данный момент нет данных от данного колбека для одноименного инструмента
3) Если колбек обнаруживает что очередь пустая, то устанавливает указатели на ноль.
Если есть желание сэкономить 1...10 Кбайт, то можно снова переопределить таблицу очереди.
-----------------
Максимальная длина массива определяется максимальным числом необработанных вызовов колбеков,  которые будут записаны в очередь.  
 
Цитата
VPM написал:
Не стоит питать иллюзий: рынок — это не место для легких денег!
---------------------------------------------------------------------------------------------
1) Открывая график в терминале, мы видим отражение цены во времени (массив), и это колебательный процесс, что в свою очередь равносильно волновой процесс.
Волновой процесс можно описать с помощь фазово - частотной характеристики.
Без обид, но не стоит нести в массы отсебятину и чушь.
--------------
Все это можно найти в интернете.
-----------------
Если хотите просвещать, то дайте просто ссылку, а не пытайтесь своими словами пересказывать то, в чем сами не разбираетесь.
=====================
Фазо-частотная характеристика применяется к линейным системам, а не к сигналам.
------------------------------------

Фа́зочасто́тная характери́стика (ФЧХ) — зависимость разности фаз между выходным и входным сигналами некоторой системы от частоты сигнала, функция, аналитически выражающая (описывающая) эту зависимость, также — график этой функции.

https://ru.wikipedia.org/wiki/Фазо-частотная_характеристика

==================
Применительно к сигналам получают не характеристику , а спектр.
================
Волна́ — изменение некоторой совокупности физических величин (характеристик некоторого физического поля или материальной среды), которое способно перемещаться, удаляясь от места своего возникновения, или колебаться внутри ограниченных областей пространства[
Многообразие волновых процессов приводит к тому, что никаких абсолютных общих свойств волн выделить не удаётся

https://ru.wikipedia.org/wiki/Фазо-частотная_характеристика
 
Цитата
nikolz написал:
Многообразие волновых процессов приводит к тому, что никаких абсолютных общих свойств волн выделить не удаётся
Физика колебаний и волн может быть разной.  Но общие свойства, естественно есть, и они находят своё выражение  в абстрактных физ и мат моделях (вспомним, например, чрезвычайно плодотворную модель гармонического осциллятора). Так, у всех волн есть такие характеристики, как длина волны, частота, фаза в данной точке в данный момент времени и т.п.  Есть же даже целая отрасль знаний - теория колебаний. "Теория колеба́ний — раздел математики, в котором рассматриваются всевозможные колебания, абстрагируясь от их физической природы."
Если вернуться к "колебаниям" цены акций, то эти графики тоже можно анализировать с  помощью формальных инструментов теории колебаний. Правомерно ли это? Торговля - сугубо практическая сфера. Если данный подход приносит прибыль - значит правомерно.
Кстати, у изменения рыночной цены акций объективно должны быть "колебания". Механизмы возникновения их различны. Некоторые лежат на поверхности. Некоторые сокрыты. Я даже не уверен, что термин колебания применительно к цене акций всегда нужно брать в кавычки. Для механических колебаний важно наличие периодического преобразования энергии из кинетической в потенциальную. Проще говоря - важно наличие обратной возвращающей силы. При отклонении некой системы от положения равновесия возвращающая сила стремится вернуть её к положению равновесия. "По инерции" система проскакивает положение равновесия. Опять возникает возвращающая сила.  Если изначально было некоторое воздействие, которое вывело эту колебательную систему из стабильного положения равновесия, то энергия этого воздействия потихоньку диссипирует.  Колебания затухают. Нечто подобное можно наблюдать и у курса акций. А что такое колебательная система? Практически всё в нашем мире является колебательной системой и/или её частью. Так устроен мир.
Поскольку цена и механизм её образования имеют в своей основе как ряд объективных, так и субъективных факторов, то её равновесное значение является результатом интерференции этих факторов разной природы. Субъективность - некие ожидания могут сдвигать положение равновесия. А поскольку субъективные представления человека тоже имеют некий колебательный характер, то...
Во всём этом главный и единственный практический вопрос одни - профит есть или нет)
 
Trbot,  Формирование цен отражает результат взаимодействия множества факторов, спрос / предложение, психология (страх / жадность), события экономического характера (процентные ставки, инфляция ...).
Отображение цен на графике в виде бара, это отображение на плоскости. Колебания цен в записи бар — это процесс, при котором цена может двигаться вверх и вниз, создавая амплитуду колебания, а также периодичность в изменениях.
Это легко проверить, кто бы что не писал, возьмем бар на интервале H1, и заполним его барами с формированными на М1, на том же самом интервале (к слову, это свойство называют фрактальностью)
Колебания можно рассматривать как волновой процесс? Термин "волновой процесс", используется в техническом анализе как метафора, а не в физическом смысле (распространение колебаний в среде).
Волны Эллиотта — модель, где цена движется в виде импульсных и коррекционных волн. Тренды и коррекции — их можно также условно можно назвать "волнами".
 
nikolz,  Ну что Вы такое пишете?
Цитата
nikolz написал:
Если nil элемент не таблица, то никакой памяти сборщик мусора не удаляет.
Ну как nil элемент, может быть таблица? Именно для запуска сборщика мусора и устанавливаем nil. А способ продемонстрируйте кодом, тогда можно, что то обсуждать, а так одна философия.
Цитата
nikolz написал:
Без обид, но не стоит нести в массы отсебятину и чушь. --------------Все это можно найти в интернете.-----------------Если хотите просвещать, то дайте просто ссылку, а не пытайтесь своими словами пересказывать то, в чем сами не разбираетесь.
"Предлагаемый подход в ВУЗах не преподаётся и не изучается, так как он - тайный, хотя бы потому что не имеет учебника". Сылка на авторов работ на которые я опираюсь в своих рассуждениях я даю.
 
Цитата
Trbot написал:
Проще говоря - важно наличие обратной возвращающей силы. При отклонении некой системы от положения равновесия возвращающая сила стремится вернуть её к положению равновесия
В своей "Общей теории цикла" (ОТЦ) Соколов Юрий Николаевич, такое взаимодействие называет "квант взаимодействия", мне же больше но нраву старинное название "Монада".
Здесь нужно понимать что авторы на которых я ссылаюсь, говорят о единых законах миро воздания, а это значит, терминология принимаемая в физике или химии вполне себе допустима и в нашем предмете.
Из теории систем известно, что любая система содержит в себе главное звено, которое нужно найти а затем, "потянув" за него можно "распутать" весь системный "клубок".

Решил человек заняться инвестициями, нужен капитал, приобретает актив, и у него остаются деньги.
Мат. запись такой монады, К = А + Д. если это от нормировать, получим доступ к структурному анализу. Именно такие подходы я пытаюсь обсуждать, и применить при анализе и прогнозировании у себя.
Еще один пример, вот Вы пишете:
Цитата
Trbot написал:
Для механических колебаний важно наличие периодического преобразования энергии из кинетической в потенциальную.
По сути Вы говорите о фазовых переходах, посмотрите как это описывает в своей "Ритмодинамика" (РД) Иванов Юрий Николаевич. Вообще читая РД, не покидает чувство, что читаешь фантастический роман.  
 
Цитата
VPM написал:
терминология принимаемая в физике или химии вполне себе допустима и в нашем предмете.
Если речь об анализе мат методами графиков цен, то достаточно, наверное и математики.
ОТЦ, РД, Монада - да как хотите называйте всё это лишь бы профит был.
(Хотя, мне кажется, что привлекать термины из этих сомнительных философских концептуальных трудов большого практического смысла нет)
Профит есть от роботов? Я имею ввиду вообще практику применения роботов, практику алготрейдинга.

Профит есть?
 
Цитата
Trbot написал:
Профит есть от роботов? Я имею ввиду вообще практику применения роботов, практику алготрейдинга. Профит есть?
Профит от роботов у каждого свой, алготрейдинг - это прежде всего создание алгоритмов, кто что на ваял, то и получил. Я лишь рассуждаю о новых подходах, которые реализуемы в этих алгоритмах. И моментах торговой деятельности на бирже? Например, в своей практике, использую два уровня защиты, стоп - лосс на сделку (небольшой) , и процент проигрыша от капитала, он реализован у меня как индикатор на графике для каждого инструмента отдельно, я им иногда пренебрегаю, как Вы думаете связан алгоритм и профит. Моя практика говорит да.

Повторюсь трейдинг иллюзия заработка легких денег, это полноценная профессиональная деятельность крупных игроков :smile:
Идеальная торговая стратегия: продал на верху, купил снизу. Алгоритмически это осциллятор,  идеально синусоидальная волна (про которую я тут распинаюсь рассказывая) . Ее применение позволяет перейти в Фазово - частотную область, рассчитав период несущей волны и получив фазу, строим опережающий индикатор с помощью сдвига фаз. Я только что  описал алгоритм, одного из подходов расчета опережающего индикатора, выше есть примеры.
Для сравнения, если использовать алгоритм простой средней  то лаг определяется в половину периода скользящего окна, то есть прошло  половина периода пока получен сигнал на сделку. Вот и сами ответьте что лучше, получить опережающий или пропущенный на половину сигнал.

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

"Сложность этого подхода - выше сложности высшей экономики. Он доступен для понимания и овладения лишь тем, кто имеет не только высокий интеллект, глубокие экономические знания, любознательность и трудолюбие, но и «души прекрасные порывы»." :smile:  
 
Цитата
Trbot написал:
ОТЦ, РД, Монада - да как хотите называйте всё это лишь бы профит был.
Для реализации профита, нужно другое согласен и это не только для алгоритмической
.
1) Положительное мат. ожидание вашей торговой системы, на статистически значимом периоде.
2) Система должна показывать Профит фактор не ниже 2 и Процент прибыльных сделок более 40%
3) Для улучшение результатов торговой системы нужно адекватное управление позицией ММ.
4) А может и первое, контроль рисков, РМ.
5) Ну и конечно самодисциплина, в прочем  алгоритмическая здесь сильно помогает.
Вроде ничего не забыл, если ваша система отвечает этим требования вперёд! :wink:  
 
Задачу прогнозирования, можно свести к решению краевой задачуи Коши, для системы дифференциальных уравнений, с заданными начальными условиями. Возможность решить, такую задачу прогнозирования, заключается в определении:
1. начальных условий – фазы,
2. алгоритма вычисления прогноза - функция.
Если известны начальные условия движения и алгоритм вычисления траектории, то мы можем вычислить (сделать) прогноз судьбы любой системы.
Страницы: Пред. 1 2 3 4 5 6
Читают тему
Наверх