MQL: segurança vs oportunidades - página 5

 
sergeev:

Vá lá, isso foi um número falso logo à saída do taco. Pedir ficheiros em memória, é suposto ser muito mais fácil de implementar do que cartografar e mais eficiente.

MQL: Segurança vs. Possibilidades

Renat, 2013.04.25 15:57

Apenas fizemos pips para não termos de utilizar ficheiros.

Não há uma comunicação bidireccional eficaz. Os tubos não funcionam, já todos devem ter percebido isso até agora. Ficheiros em memória?

Outra questão - é do meu entendimento que não pode divulgar ao mercado o código que obtém informações de um recurso de terceiros através de oleodutos?

 
Renat:

Acabámos de fazer os pips para que não tenha de utilizar ficheiros.

Compreendo perfeitamente porque é que o servidor pips no terminal. Apenas e só (tudo o resto são apenas desculpas) para uma tarefa - combinar terminais em nome da arbitragem. Mas isso não faz parte das nossas tarefas.

Quem quer realmente fazer troca entre processadores, basta implementar um servidor de tubos multicanais. Mas não se pode vender isso num mercado, e é exactamente esse o objectivo que se persegue.

Está enganado sobre apenas e só.

Arbitragem, copiadoras, misturadoras (isto é, quando se gerem vários Expert Advisors comprados num mercado e se cria uma posição de cobertura a partir deles), ...

Agora Joo precisa dele para a sua AG. Nunca se sabe qual será a fantasia do programador.

Quero dizer que é muito difícil prever o que se pode acumular com uma nova característica.

E de facto não é realmente necessário antecipar (como se não fosse uma prioridade), as pessoas têm uma necessidade,

verificado quanto à segurança, se assim for, porque não dar-lhes a oportunidade.

Sabe muito bem que qualquer extensão é uma vantagem para a língua de aplicação.

SZ

Compreendo que é difícil compreender a solução futura, mas já existe uma solução - "ficheiros".

Não estão satisfeitos com apenas uma coisa: "bate um parafuso" tudo o resto é verificado e duplamente verificado.

A questão não é reinventar a roda, a questão é dar uma solução mais orgânica ao que já existe.

SZY

Aqui está mais uma forma de utilizar ficheiros virtuais: em vez de uma interface de botões faz-se uma interface bitmap, interactiva ao vivo e altamente enganada (com botões redondos, por exemplo) e calcula-se tudo isso em OpenCL on the fly. Poderia ao menos transmitir notícias televisivas na tabela. Tem um exemplo de OpenCL, execute-o durante um mês e veja por si próprio o que vai acontecer com a unidade.

 
Renat:

Acabámos de fazer os pips para que não tenha de utilizar ficheiros.

Compreendo perfeitamente porque é que o servidor pips no terminal. Apenas e só (tudo o resto são apenas desculpas) para uma tarefa - combinar terminais em nome da arbitragem. Mas isso não faz parte das nossas tarefas.

Quem quer realmente fazer troca entre processadores, basta implementar um servidor de pip-servidor multicanal. Mas não se pode vender isso no mercado, e esse é o objectivo.

Mas e dentro da caixa de areia de um único terminal? E puramente dentro da MQL5, sem dll?

Compreendo que a dificuldade é que o consultor especializado no terminal e a EA no testador estão separados no espaço de memória devido ao facto de o terminal e o testador serem processos diferentes. Parece que esta mesma separação do testador do terminal leva a um tal "abismo".

 
joo:

Bem, e dentro de uma única caixa de areia terminal? E puramente dentro da MQL5, sem dlls?

Compreendo que a dificuldade é que o consultor especializado no terminal e o EA no testador estão separados no espaço de memória porque o terminal e o testador são processos diferentes. Parece que esta mesma separação do testador do terminal leva a um tal "abismo".

Apenas um perito no testador (mesmo num computador fisicamente diferente ou mesmo na nuvem) pode enviar dados para um perito no terminal utilizando frames. Assim, de facto, não há nenhuma lacuna
 
stringo:
Apenas o perito no testador (mesmo num computador fisicamente diferente ou mesmo na nuvem) pode transferir dados para o perito no terminal utilizando frames. Ou seja, não há realmente nenhuma lacuna

Yuk. Uck. (a pálpebra superior esquerda entrou em modo de vibração rasa)

E de volta? É necessário obter um lote de informações sobre o agente (destinado apenas a ele) que deve ser processado no início da execução e passar o resultado no final da execução.

 
joo:

Uck. Yuk. (a pálpebra superior esquerda entra em modo de vibração rasa)

E de volta? É necessário obter um lote de informações sobre o agente (destinado apenas ao agente) para ser processado no início da execução e para transmitir o resultado no final da execução.

Em termos simples, dar ao agente parâmetros de entrada que não os especificados pelo testador padrão.
 
joo:

Yuk. Uck. (a pálpebra superior esquerda entra em modo de vibração rasa)

E de volta? É necessário obter um lote de informações sobre o agente (destinado apenas a ele) para ser processado no início da execução e enviar de volta o resultado no final da execução.

É simultaneamente complicado e caro (especialmente nos cludes). É possível, no entanto.

Ainda não o faremos.

 
Urain:
Simplificando, dar ao agente um parâmetro de entrada diferente daquele definido pelo testador padrão.
Fazer. Mas também é necessária uma forma de passar esses parâmetros de instu personalizados. Esse é o problema.
 
Renat:

É simultaneamente complicado e caro (especialmente nos cludes). É possível, no entanto.

Ainda não o faremos.

A nuvem é fixe. Gostaria de lidar com agentes locais, por agora.
 

Para informação - os nossos servidores de nuvem MQL5 Cloud Network normalmente geram cerca de 5 terabytes de tráfego por dia, por vezes até 10 Tb.

Se o tráfego personalizado ilimitado for enviado para esta rede com a garantia de que cada agente pode ser alcançado, a rede não se sentirá muito bem.

Распределенные вычисления в сети MQL5 Cloud Network
Распределенные вычисления в сети MQL5 Cloud Network
  • cloud.mql5.com
Заработать деньги, продавая мощности своего компьютера для сети распределенных вычислений MQL5 Cloud Network