Запрет на повторный перерасчет функции - страница 2

Новый комментарий
 
Aleksey Vyazmikin:

Да, и если это произошло на новом баре. Так как параметры могут передаваться одни и те же, но при этом на разных барах будет разный результат.

Можно например сделать класс в котором хранятся предыдущие параметры. И перед расчетом проверять изменились ли они.

class Trader
{
private:
 int Param1;
....
int function(int param1, ....)
}

int Trader::function(int param1 ...)
{
  if (param1!=Param1)
  {
    //расчеты
    Param1 = param1
  }
}
 
Georgiy Merts:

У тебя должны сохраняться входные переменные функции и результат. (Лично я бы сделал их членами класса, в котором эта самая функция выполняется, статическими или нет - в зависимости от конкретной архитектуры системы).

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

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

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

 
Vitalii Ananev:

Можно например сделать класс в котором хранятся предыдущие параметры. И перед расчетом проверять изменились ли они.

Вот в ООП я полный дуб! Однако, кроме параметров надо сохранять и дату бара тогда, что б учитывать необходимость перерасчета при появлении баров в будущем?

 
Aleksey Vyazmikin:

Вот в ООП я полный дуб! Однако, кроме параметров надо сохранять и дату бара тогда, что б учитывать необходимость перерасчета при появлении баров в будущем?

Aleksey Vyazmikin:

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

Многомерный массив из разных типов переменных не надо делать. Если с ОПП не дружите, тогда храните параметры в структуре (struct). В ней можно объединить разные типы  переменных, в том числе и дату бара. Потом при вызове функции проверять данные хранящиеся в структуре и переданные параметры. Если какой то из параметров отличается выполнять расчеты и запомнить новые параметры.

struct SParam
{ 
   int   Param1;     
   ....
   double  ParamN;     
   datetime BarTime;
};
 
Aleksey Vyazmikin:

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

Ну тут получается что-то вроде кэша.

Я бы сделал так.

Берешь структуру - поля это входные данные и выходное значение. Кроме того - одно поле - это счетчик обращений.

Создаешь массив этих структур. Максимальный размер массива - надо глядеть по сложности вычисления. Если функция очень сложная - то и размер массива можно брать побольше.

Первоначально заполняешь массив невалидными входными значениями с нулевыми счетчиками обращений.

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

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

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

Вот и все.

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

Ну и можно брать не массив, а список, и организовать очередь - при этом вызываемая структура - будет переноситься в начало очереди. Это уже - по ситуации... Да и организация списка удобна через потомков CObject, а ты, как говоришь, не больно-то с ООП дружишь..

Весь кэш я, конечно, сделал бы отдельным классом (возможно, даже темплейтом, чтобы можно было менять структуру входных данных), но это не обязательно.

 
Aleksey Vyazmikin:

Да, и если это произошло на новом баре. Так как параметры могут передаваться одни и те же, но при этом на разных барах будет разный результат.

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

Сам флаг контролировать в начале онтика.

 

Georgiy Merts, идея правильная. Но на фига нужно сохранять все в структуре. Я в таких случаях делаю так:

1. Захожу в функцию.

2. Перевожу все параметры в строку.

3. Перевожу строку в число например с помощью функции Adler32. которая тут есть где то в статьях.

4. Ищу допустим это число в массиве long Kesh. Если нахожу то результат работы функции лежит по соответствующему элементу double KeshOtvet.

5. Если не удалось найти число из пункта 3 в массиве . То выполняю функцию и сохраняю пару новых значений.

 
pivomoe:

Georgiy Merts, идея правильная. Но на фига нужно сохранять все в структуре. Я в таких случаях делаю так:

1. Захожу в функцию.

2. Перевожу все параметры в строку.

3. Перевожу строку в число например с помощью функции Adler32. которая тут есть где то в статьях.

4. Ищу допустим это число в массиве long Kesh. Если нахожу то результат работы функции лежит по соответствующему элементу double KeshOtvet.

5. Если не удалось найти число из пункта 3 в массиве . То выполняю функцию и сохраняю пару новых значений.

Всякая структура, по сути - строка, поэтому п.2 - лишний. 

Если в п.4 искать эту строку, без какого-либо ее преобразования, то и п.3 станет лишним. 

Экономия, однако... 

 
Алексей Тарабанов:

Всякая структура, по сути - строка, поэтому п.2 - лишний. 

Если в п.4 искать эту строку, без какого-либо ее преобразования, то и п.3 станет лишним. 

Экономия, однако... 

C точки зрения реальной торговли вы правы, если конечно параметры не занимают мегабайты.  С точки зрения оптимизации ( если использовать этот подход для оптимизации, сохранять результаты на диск ) наверное прав я т.к процедура скачивания с диска занимает много времени.

 
Aleksey Vyazmikin:

Вот в ООП я полный дуб! Однако, кроме параметров надо сохранять и дату бара тогда, что б учитывать необходимость перерасчета при появлении баров в будущем?

Алексей, Виталий показал простейший пример ООП, но самый эффективный. Все остальные примеры так или иначе сводятся к такому-же алгоритму, но со своеобразным вывертом. Как например второй вариант Виталия со структурой. Всё то-же самое, но с определёнными сложностями. Постарайся понять пару элементарных понятий ООП и всё встанет на свои места.

Плюс ко всему можно создать переменную из какого места программы вызывалась функция. На мой взгляд это будет своеобразным флагом от повторного вызова.

123
Новый комментарий
Причина обращения: