Para uma função tão simples, você complicou demais a interface. Muitas exportações desnecessárias, enquanto faltam as coisas necessárias. Não consigo entender seu código imediatamente, posso imaginar como se sentem as pessoas que não são tão boas em programação.
Agora vou pensar e propor minha própria versão de exportação simplificada e operação de roteiro de teste.
Talvez a abordagem "evolucionária" de encontrar valores dos parâmetros da equação FF não seja tanto com o propósito de melhorar a eficiência de encontrar valores, mas sim para modelar o processo de evolução por software.
Bem, como a evolução é representada pelos cientistas...
A abordagem é muito consistente em sua conformidade com todos os cânones evolutivos.
1. uma função de adequação toma um conjunto de parâmetros do tipo duplo e retorna um número quanto maior for o número, melhor são escolhidos os parâmetros. O protótipo da função fitness é o seguinte:
double FF(double &array[]);
2. A função fitness tem alguns parâmetros, que são especificados na estrutura FitnessParams. Uma descrição da estrutura é dada abaixo:
//+------------------------------------------------------------------+//| Параметры фитнес-функции (FF) |//+------------------------------------------------------------------+struct FitnessParams
{
int limit_runs; // Максимально допустимое количество вызовов FFint count_params; // Количество параметров, которое необходимо оптимизироватьint current_runs; // Текущее количество вызовов функцииdouble current_max_value; // Текущее найденное максимальное значениеdouble step_value; // Минимальный шаг изменения параметра. double max_value; // Максимальное значение, которое может принимать параметрdouble min_value; // Минимальное значение, которое может принимать параметр
FitnessParams(void);
};
//+------------------------------------------------------------------+//| Инициализация параметров фитнес-функции (FF) по-умолчанию |//+------------------------------------------------------------------+
FitnessParams::FitnessParams(void) : limit_runs(1000),
count_params(2),
step_value(0.1),
max_value(10.0),
min_value(-10.0),
current_runs(0)
{
current_max_value = min_value;
}
3. A função de aptidão e seus parâmetros são protegidos de influências externas e são armazenados em uma biblioteca independente. Os valores dos parâmetros da função de aptidão e seu próprio algoritmo são definidos no momento da compilação por um árbitro independente e não podem mais ser alterados por ninguém.
4. Um algoritmo de otimização personalizado e um roteiro de verificação podem encontrar parâmetros de uma função de adequação. Para este fim, o arquivo Export.mqh contém os protótipos necessários desta função e seus parâmetros. Para obter os parâmetros FF, é utilizada a função de exportação, que também está localizada em ...FFFF.ex5:
void GetFitnessParams(FitnessParams& params);
5. O algoritmo de otimização do usuário está localizado em uma biblioteca separada e fechada...FFFFUserFindExtremum.ex5 e é compilado separadamente, no lado do usuário. A função FindExtremum deve ser exportada para a biblioteca do usuário. Esta função será chamada pelo roteiro de verificação. O protótipo completo da função é apresentado abaixo:
//+------------------------------------------------------------------+//| Экспорт пользовательской библиотеки поиска экстремума |//+------------------------------------------------------------------+#import "..\\Scripts\\FF\\UserFindExtremum.ex5"void FindExtremum(void);#import
6. O script de verificação carrega para seu espaço de endereçamento a biblioteca da função de adequação ..ScriptsFFFFFF.ex5 com seus parâmetros, e a biblioteca do membro FindExtremum..ScriptsFFFFUserFindExtremum.ex5. Depois disso, chama a função do membro FindExtremum.
7. Após a execução da função participante, o roteiro de verificação consulta os parâmetros da função de adequação, que contêm o valor máximo encontrado pela função participante e o número de chamadas necessárias para encontrar esse máximo. Com base nestes dados, um relatório do resultado do participante é gerado na forma de uma tabela:
Para uma função tão simples, você complicou demais a interface. Muitas exportações desnecessárias, enquanto faltam as coisas necessárias pelo contrário. Não entendi seu código na primeira tentativa, e posso imaginar o que as pessoas que não são tão boas em programação sentem.
Vou pensar sobre isso e propor minha própria versão de exportação simplificada e roteiro de teste.
Por que isso não é necessário?
Que tipo de coisas estão faltando?
Afinal, não apenas para tornar a vida o mais difícil possível para os participantes, então eu fiz tudo isso, e não no primeiro dia em que pensei em tudo isso e nem mesmo no segundo.
Afinal, não apenas para tornar a vida o mais difícil possível para os participantes, então eu fiz tudo, e não no primeiro dia em que pensei em tudo, e nem mesmo no segundo.
Andrew, eu não sei sobre outros, mas pessoalmente, gostei mais do exemplo de Vasily. Sem ofensa. Esta é apenas a minha percepção subjetiva.
Para ser justo, proponho colocar à votação a questão sobre a escolha da interface de conexão (sua ou de Vasiliy).
Não foi apenas para tornar a vida o mais difícil possível para os participantes que o fiz, e não foi no primeiro dia que pensei sobre isso, ou mesmo no segundo.
Em seu exemplo, a tarefa de busca é parcialmente delegada ao roteiro de verificação. Isto é incorreto. O roteiro do verificador deve chamar a busca e verificar seu resultado e nada mais.
Nem todos os parâmetros FF estão disponíveis. Por exemplo, como obter o passo de parâmetro (valor 0,1), possível máximo e mínimo? É ótimo, é claro, que cada usuário leia este fórum e entenda que o passo acaba sendo 0,1, o mínimo -10,0 e o máximo +10,0, então insira estas constantes em seu código e espere que a função FF pense da mesma forma. Mas esta não é a maneira de fazer isso de uma boa maneira.
Muitas funções de exportação como ServiceFunc1 são utilizadas apenas em algoritmos de busca específicos. Por exemplo, eles não devem ser usados em buscas aleatórias. Então, por que uma biblioteca de usuários deve exportá-los? Basta separar a tarefa de teste da tarefa de busca para perceber que toda essa combinação complicada de funções de exportação é desnecessária.
Há muito mais coisas que tornam desnecessários os acréscimos.
E o exemplo de Basil do segundo tipo de conexão, e onde no primeiro?
Você não precisa do segundo, terceiro, 110 tipo de conexão. Você só precisa de uma, mas de um tipo de conexão universal. Sem utilizar construções sintáticas desnecessárias. Ninguém quer confundir sobre o significado abreviado da função ServiceFunc1. Ao invés disso, deve-se dar uma função de adequação e regras de preenchimento de seus parâmetros. E nada mais.
Roteiro de teste na primeira versão do algoritmo:
Para uma função tão simples, você complicou demais a interface. Muitas exportações desnecessárias, enquanto faltam as coisas necessárias. Não consigo entender seu código imediatamente, posso imaginar como se sentem as pessoas que não são tão boas em programação.
Agora vou pensar e propor minha própria versão de exportação simplificada e operação de roteiro de teste.
Talvez a abordagem "evolucionária" de encontrar valores dos parâmetros da equação FF não seja tanto com o propósito de melhorar a eficiência de encontrar valores, mas sim para modelar o processo de evolução por software.
Bem, como a evolução é representada pelos cientistas...
A abordagem é muito consistente em sua conformidade com todos os cânones evolutivos.
Proposta:
1. uma função de adequação toma um conjunto de parâmetros do tipo duplo e retorna um número quanto maior for o número, melhor são escolhidos os parâmetros. O protótipo da função fitness é o seguinte:
2. A função fitness tem alguns parâmetros, que são especificados na estrutura FitnessParams. Uma descrição da estrutura é dada abaixo:
3. A função de aptidão e seus parâmetros são protegidos de influências externas e são armazenados em uma biblioteca independente. Os valores dos parâmetros da função de aptidão e seu próprio algoritmo são definidos no momento da compilação por um árbitro independente e não podem mais ser alterados por ninguém.
4. Um algoritmo de otimização personalizado e um roteiro de verificação podem encontrar parâmetros de uma função de adequação. Para este fim, o arquivo Export.mqh contém os protótipos necessários desta função e seus parâmetros. Para obter os parâmetros FF, é utilizada a função de exportação, que também está localizada em ...FFFF.ex5:
void GetFitnessParams(FitnessParams& params);5. O algoritmo de otimização do usuário está localizado em uma biblioteca separada e fechada...FFFFUserFindExtremum.ex5 e é compilado separadamente, no lado do usuário. A função FindExtremum deve ser exportada para a biblioteca do usuário. Esta função será chamada pelo roteiro de verificação. O protótipo completo da função é apresentado abaixo:
6. O script de verificação carrega para seu espaço de endereçamento a biblioteca da função de adequação ..ScriptsFFFFFF.ex5 com seus parâmetros, e a biblioteca do membro FindExtremum..ScriptsFFFFUserFindExtremum.ex5. Depois disso, chama a função do membro FindExtremum.
7. Após a execução da função participante, o roteiro de verificação consulta os parâmetros da função de adequação, que contêm o valor máximo encontrado pela função participante e o número de chamadas necessárias para encontrar esse máximo. Com base nestes dados, um relatório do resultado do participante é gerado na forma de uma tabela:
O seguinte post irá anexar os arquivos necessários e um exemplo de uso
Export.mqh file - uma lista de funções disponíveis e estrutura de parâmetros comum a todos os participantes
Arquivo FF.mq5 - exemplo de uma função de adequação como uma biblioteca.
Arquivo TestFF.mq5 - algoritmo de verificação como um script
UserFindExtremum.mq5 file - função personalizada para busca de um extremo na forma de uma biblioteca. Uma busca aleatória é usada como exemplo
Export.mqh file - uma lista de funções disponíveis e estrutura de parâmetros comum a todos os participantes
Arquivo FF.mq5 - exemplo de uma função de adequação como uma biblioteca.
Arquivo TestFF.mq5 - algoritmo de verificação como um script
UserFindExtremum.mq5 file - função personalizada para busca de um extremo na forma de uma biblioteca. Uma busca aleatória é usada como exemplo
Para uma função tão simples, você complicou demais a interface. Muitas exportações desnecessárias, enquanto faltam as coisas necessárias pelo contrário. Não entendi seu código na primeira tentativa, e posso imaginar o que as pessoas que não são tão boas em programação sentem.
Vou pensar sobre isso e propor minha própria versão de exportação simplificada e roteiro de teste.
Por que isso não é necessário?
Que tipo de coisas estão faltando?
Afinal, não apenas para tornar a vida o mais difícil possível para os participantes, então eu fiz tudo isso, e não no primeiro dia em que pensei em tudo isso e nem mesmo no segundo.
Por que não os certos?
Quais estão faltando?
Afinal, não apenas para tornar a vida o mais difícil possível para os participantes, então eu fiz tudo, e não no primeiro dia em que pensei em tudo, e nem mesmo no segundo.
Andrew, eu não sei sobre outros, mas pessoalmente, gostei mais do exemplo de Vasily. Sem ofensa. Esta é apenas a minha percepção subjetiva.
Para ser justo, proponho colocar à votação a questão sobre a escolha da interface de conexão (sua ou de Vasiliy).
O que você acha?
Andrew, eu não sei sobre os outros, mas pessoalmente, gostei mais do exemplo de Vasily. Sem ofensa. É apenas a minha percepção subjetiva...
Para ser justo, proponho colocar à votação a questão de escolher uma interface de conexão (sua ou de Vasiliy).
O que você acha?
Por que não os certos?
Quais estão faltando?
Não foi apenas para tornar a vida o mais difícil possível para os participantes que o fiz, e não foi no primeiro dia que pensei sobre isso, ou mesmo no segundo.
Em seu exemplo, a tarefa de busca é parcialmente delegada ao roteiro de verificação. Isto é incorreto. O roteiro do verificador deve chamar a busca e verificar seu resultado e nada mais.
Nem todos os parâmetros FF estão disponíveis. Por exemplo, como obter o passo de parâmetro (valor 0,1), possível máximo e mínimo? É ótimo, é claro, que cada usuário leia este fórum e entenda que o passo acaba sendo 0,1, o mínimo -10,0 e o máximo +10,0, então insira estas constantes em seu código e espere que a função FF pense da mesma forma. Mas esta não é a maneira de fazer isso de uma boa maneira.
Muitas funções de exportação como ServiceFunc1 são utilizadas apenas em algoritmos de busca específicos. Por exemplo, eles não devem ser usados em buscas aleatórias. Então, por que uma biblioteca de usuários deve exportá-los? Basta separar a tarefa de teste da tarefa de busca para perceber que toda essa combinação complicada de funções de exportação é desnecessária.
Há muito mais coisas que tornam desnecessários os acréscimos.
O que exatamente você gosta mais?