Número mágico automático - página 3
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Se você não estivesse fechando parcialmente nenhum pedido, você poderia usar o comentário para armazenar as informações sobre o par/tempo de origem...
Se existem dois EAs no mesmo símbolo e no mesmo prazo, como eles sabem de qual dos pedidos históricos eles devem pegar suas respectivas identificações?
Tudo isso depende em parte das informações que se supõe que estarão disponíveis no reinício. Por exemplo, há algumas pessoas neste fórum que armazenam os dados ao longo destas linhas em objetos escondidos na janela do gráfico. Isso não é ruim, mas estou pessoalmente assustado por qualquer mecanismo que o usuário possa quebrar - sem perceber como ou por quê.
Se existem dois EAs no mesmo símbolo e no mesmo prazo, como eles sabem de qual dos pedidos eles devem pegar suas respectivas identificações?
Droga - isso estava no escopo do projeto :D
Acho que assumi que a EA (se diferente tipo ou versão) também teria um identificador nos comentários :)
-BB-
Não consigo ver como isso é possível sem o MT4 ou sem que o usuário atribua uma identificação a cada EA. Ou, mais precisamente, não consigo ver nada que não envolva algo muito desagradável, como gerar uma identificação única e depois modificar o arquivo .chr da EA para armazenar a identificação como parte dos parâmetros externos da EA.
E, para entretenimento geral, o seguinte não adianta de forma alguma a discussão, mas substitui a entrada para o hash djb2 por um valor que é garantido como único (ao custo de requerer chamadas DLL). Não sei como o djb2 deve ser bom em coisas como GUIDs, mas acabei de tentar gerar 1.000.000 de IDs sem nenhuma colisão. Mas ainda não resolve o problema do reinício.
Não consigo ver como isso é possível sem o MT4 ou sem que o usuário atribua um ID para cada EA. Ou, mais precisamente, não consigo ver nada que não envolva algo muito desagradável, como gerar uma ID única e depois modificar o arquivo .chr da EA para armazenar a ID como parte dos parâmetros externos da EA.
>> Como a enésima instância do EA p/u é o arquivo chartyy.chr?
.
supondo que uma instância possa realmente mapear seu próprio arquivo .chr:
se a fonte da EA tiver: extern int myID = <someCompileTimeVal>;
então qualquer instância vendo <algumCompileTimeVal> pode assumir que é 'primeira vez' -> gen it's id -> mod myID line -> criar arquivos de recuperação usando a singularidade de myID ,...
então, ao reiniciar o acesso de detecção, é um arquivo .chr para p/u myID que seria a chave mestra para permitir o remapeamento de arquivos...
.
por exemplo:
gráfico02.chr
<chart>
symbol=EURUSD
período=15
..
..
<especialista>
name=LMT 1.8
bandeiras=343
window_num=0
<inputs>
myID=algumCompileTimeVal>
...
<inputs>
</especialista>
EOF
Socorro!!
.
E, para entretenimento geral, o seguinte não adianta em nada a discussão, mas substitui a entrada para o hash djb2 por um valor que é garantido ser único (ao custo de requerer chamadas DLL). Não sei como o djb2 deve ser bom em coisas como GUIDs, mas acabei de tentar gerar 1.000.000 de IDs sem nenhuma colisão.
Usei o PsPad ed para sugar o 1mil e fiz uma espécie de remoção de dups assinalados.
>> Mas... COMO você fez isso "...sem nenhuma colisão" detecção?
"E, para entretenimento geral, o seguinte não adianta em nada a discussão, mas substitui a entrada para o hash djb2 por um valor que é garantido ser único (ao custo de requerer chamadas DLL). Não sei como o djb2 deve ser bom em coisas como GUIDs, mas acabei de tentar gerar 1.000.000 de IDs sem nenhuma colisão".
.
FYI, encontrei colisões em minhas chamadas de 1mil do código
EOF ordenado
.
classificados + dups removidos EOF
>> Como seria a enésima instância da EA p/u seu arquivo chartyy.chr?
.
supondo que uma instância possa realmente mapear seu próprio arquivo .chr:
se a fonte da EA tem: extern int myID = <someCompileTimeVal>;
então qualquer instância vendo <algumCompileTimeVal> pode assumir que é 'primeira vez' -> gen it's id -> mod myID line -> criar arquivos de recuperação usando a singularidade de myID ,...
então, ao reiniciar o acesso de detecção, é um arquivo .chr para p/u myID que seria a chave mestra para permitir o remapeamento de arquivos...
Você está certo. Eu tinha esquecido que não há maneira óbvia de um EA identificar seu arquivo .chr se houver vários EAs para o mesmo símbolo e período de tempo. Eu estava pensando que ele poderia criar um objeto de etiqueta oculta contendo algo como um GUID, e então procurar o arquivo .chr que contém o valor correto. Entretanto, tenho quase certeza que o arquivo .chr não é atualizado quando um novo objeto é adicionado ao gráfico.
E há outro problema. Tenho certeza de que o MT4 guarda as informações sobre o gráfico na memória, escreve no arquivo .chr quando o MT4 é fechado (ou uma alteração é feita nas propriedades da EA), e isto, portanto, sobregravaria quaisquer alterações que a própria EA fizesse no arquivo .chr enquanto ele estava em execução. Se você fosse incrivelmente corajoso, você poderia tentar configurar a propriedade externa simulando teclas - chamando a janela de propriedades, mudando para a configuração necessária, alterando-a, pressionando Enter etc.
FYI, encontrei colisões em minhas chamadas de 1mil do código
EOF ordenado
Ao voltar a executá-lo, eu também o fiz: 172 colisões em 1.000.000 tentativas.
Você está certo. Eu tinha esquecido que não há maneira óbvia de uma EA identificar seu arquivo .chr se houver múltiplos EAs para o mesmo símbolo e cronograma. Eu estava pensando que ele poderia criar um objeto de etiqueta oculta contendo algo como um GUID, e então procurar o arquivo .chr que contém o valor correto. Entretanto, tenho quase certeza que o arquivo .chr não é atualizado quando um novo objeto é adicionado ao gráfico.
E há outro problema. Tenho certeza de que o MT4 guarda as informações sobre o gráfico na memória, escreve no arquivo .chr quando o MT4 é fechado (ou uma alteração é feita nas propriedades da EA), e isto, portanto, sobregravaria quaisquer alterações que a própria EA fizesse no arquivo .chr enquanto ele estava em execução. Se você fosse incrivelmente corajoso, você poderia tentar configurar a propriedade externa simulando teclas - chamando a janela de propriedades, mudando para a configuração necessária, alterando-a, pressionando Enter etc.
Li acima -> saí para fazer algum exercício -> e durante o banho as células cinzas gritam OBJETO. Você mata a rota .chr, mas as duas palavras "objeto de etiqueta" provocaram essa explosão cerebral :)
Então, que tal? esquecendo-se por um momento de obter uma identificação com 100% de garantia de guerra. A outra parte é esta memória de estado recuperável contendo um EAs ID.
Bem...
1. vArchiveID vazio (int iID), int iRestoreID () [e int iGetNewID () chegar em outro posto SE este for ok :]
2. vArchiveID() cria [oculto?] label? objeto em EAs state memory chart.
O nome do objeto DEVE ser o mesmo para qualquer chamada EA... então .ex4 lib ou .mqh lib para (1)
3. A CT vai à falência ou a EA sobe de barriga etc.
4. No reinício, o primeiro trabalho da EA é chamar iRestoreID() que rets -1 se não houver objeção na tabela ou a identificação arquivada da execução anterior.
5. se não houver ID, chamar iGetNewID() então vArchiveID() e presumivelmente configurar [pela primeira vez] dump file stuff
6. Se a identificação 'restaurada', então, alegremente se recupera do último estado através de arquivos de despejo...
..
O que você acha?
[...]
O que você acha?
O que você está sugerindo é - eu acho - exatamente aquilo a que eu estava aludindo no meu post carimbado às 14:43. O único perigo com esta rota - e o único motivo de se fazer macaquices com o arquivo .chr diretamente, a fim de definir propriedades externas - é eliminar a possibilidade de os usuários apagarem acidentalmente objetos do gráfico. Mas mesmo isso pode ser amplamente superado assegurando que o obejto seja recriado, se necessário, em deinit().
Mas BB/CB pode considerar a confiança no arquivo .chr como inaceitável. Eles podem querer algo que possa ser recuperado apenas dos dados mantidos fora do local (ou seja, a lista de comércio mantida pelo corretor).
Eu tinha estado longe deste fio por um tempo.
Parece que estamos acrescentando algum grau de complexidade para permitir a recuperação com números mágicos automatizados, sim? Ie. assim um pedaço de código estúpido reencarnado pode descobrir quem ele foi em uma vida passada quando tudo o que ele sabe é o que ele é e onde ele está. Não necessariamente uma coisa ruim. Mas...
me fez pensar que seria útil documentar (muito concisamente):
- Critérios para a decisão de implementar números mágicos
- Critérios para decidir usar a geração automática de números mágicos
- Critérios para a decisão de implementar uma camada de persistência
- Critérios para decidir sobre globais versus acesso a arquivos por persistência
A razão pela qual sugiro isto é para evitar que todos pensem que têm que implementar a pia da cozinha em seus EAs.
Vistas ?
CB
- Só me restam 8 postos antes de fazer uma pausa por um tempo.
sim, bem no final, a pia da cozinha está muito provavelmente neste site, todo acadêmico. Para mim, a primeira preocupação prioritária é ter uma identificação de especialista garantida. Um valor que pode ser usado para muitos propósitos.
Ter uma maneira única de acessar arquivos de despejo no reinício é, na melhor das hipóteses, aleatório e, em qualquer caso, exige que os usuários adiram a um conjunto de regras de uso da EA. Muitas instâncias de ccy+period+EA não são uma opção.
Eu tinha a intenção de que qualquer instância fosse capaz de determinar quem era eu antes de reiniciar e isso se mostra impraticável. Pela minha parte, eu não confiaria em nenhum usuário para seguir até mesmo o conjunto de regras mais básico. Se eu não pudesse estar totalmente seguro de um método automático, eu não adotaria um meio termo em que a intervenção do usuário fosse necessária.
.
Usando o CoCreateGuid() i/f da jjc, vou gerar números suficientes e não repetitivos. O suficiente é subjetivo, mas eu vou para muitos... Juntamente com um pedaço de código de biblioteca como a função de servidor de acesso a recursos para os números de retenção de arquivos. A quantidade de números será tal que pelo menos 2yrs podem passar sem nunca reutilizar um número. No momento em que o EOF é alcançado, ele apenas se enrola no BOF e continua a servir números. Meu dedo no céu se baseará em 10 solicitantes correndo 5 dias por semana e 50 semanas por ano, onde a cada dia qualquer solicitante poderia requerer 20 novos ID's. Este resultado é então dobrado. Uma quantidade absurda de números - basicamente 200.000. Sim, a funcionalidade da idade da pedra, mas sem qualquer necessidade de confiar no terminal de qualquer forma além da capacidade de executar meu código. É claro que se poderia continuar por idades sobre as ramificações de um, 10 ou 100 arquivos e suas localizações físicas e mecanismos de acesso. No final das contas é muito melhor do que minha pena fazer com que a identificação de especialistas funcione e é estanque no que diz respeito à singularidade numérica para [na realidade] mais de 2 anos.
.
CB, 666 deve ser um número de sorte para os pilotos de helicóptero...