dll e mercado. - página 6

 
TheXpert:

A sua lógica é imperfeita, amigo. Se usar soluções como essa, não está a pensar direito.

Está muito cruelmente enganado ) o utilizador ressonante é, por exemplo, hrenfx, e este ... é apenas um nerd ressentido do mundo.

Bem... disse lá três palavras e recebeu uma página de posts com consoantes e dissidentes. E eu estou lá na língua inglesa com alguns tópicos com o meu conteúdo + indicadores + EAs que não estão em mais lado nenhum, etc ... Não quero continuar e continuar ...

As pessoas têm simplesmente talento, mas não o utilizam para o fim a que se destinam. Chamo a essas pessoas "ressonantes".

 
sergeev:

Deixem-me esclarecer um pouco, se não estavam bem certos do que estava a falar.

Não estou a falar do dll, estou a falar da falta de capacidade na actual implementação de tubos para se tornar um servidor.
Sem tubos de servidor, tem de trocar informações através de ficheiros.
E nem mesmo através do MemoryMapping, mas sim através da caixa de areia.
isto foi exactamente o que eu disse: "dentro da MQL [troca de informação] é resolvido limpando um buraco no disco. Esta solução não pode ser usada no seu perfeito juízo".

Portanto, mais uma vez, não estou a falar da falta de dll, mas da incapacidade de não fazer buracos no disco rígido. Pode usar tal solução, mas é uma má solução.

Para resumir. Vamos discutir esta questão.
 
sergeev:

:)

A tarefa é trocar informações entre os agentes da máquina local.

No âmbito do MQL é resolvido através da limpeza de um buraco no disco rígido.

Esta solução não deve ser utilizada no seu juízo perfeito.

Não, não é uma tarefa, é uma tarefa de escrever soluções simples e compreensíveis para a maioria dos utilizadores. Esta é a sexta página de discussão, e ainda não percebi qual é o objectivo do produto. É uma troca de informações consigo próprio para troca de informações? Coisas como engineer2engineer são produtos com zero potencial comercial. Não se paga dinheiro para entrar na mesquinhez do mapeamento de ficheiros e intercâmbio de dados, paga-se dinheiro para a realização das expectativas, tarefas, aqui e agora, sem formação, preparação ou trabalho. Portanto, se o produto que está a criar é complexo e não pode ser explicado no tempo que leva a queimar um fósforo, não deve sequer tentar implementá-lo para uso comercial.
 
C-4:
Página seis da discussão, e ainda não compreendo do que se trata o produto em si.
Tanto quanto sei, é uma espécie de auto-optimização genética.
 
TheXpert:
Tanto quanto sei, algo como a auto-optimização genética.

C-4 apenas não quer ler o fio, a resposta do autor está no fio, na página 3.

 
Urain:

C-4 simplesmente não tem o coração para ler o fio, a resposta do autor está no fio, na página 3.

A C.O. parece ser uma boa ideia em termos de acesso a recursos informáticos, mas a própria coruja tem de ser rentável. Isto é, não comprarão para o desempenho informático, mas para o resultado, e estas são coisas algo diferentes.
 
C-4:
O.C. parece ser uma boa ideia em termos de acesso a recursos informáticos, mas as próprias corujas precisam de ser rentáveis. Por outras palavras, eles não comprarão por desempenho informático, mas por resultados, e estas são coisas um pouco diferentes.

O desempenho, neste caso, é um elemento secundário. A essência é a capacidade de gerir o processo de optimização.

E o mercado não está apenas cheio de corujas.

 
joo:

O desempenho é, neste caso, um elemento secundário. O objectivo é ser capaz de gerir o processo de optimização.

E o mercado não está apenas cheio de corujas.

Presumo que é uma dica para algum tipo de produto, m-m-m-m-mm... como um gestor de optimização ou algo assim, capaz de utilizar o optimizador em tempo real.
 
C-4:
Presumo que isto seja uma dica para algum tipo de produto, m-m-m-m-mm... como um gestor de optimização ou algo assim, capaz de usar o optimizador em tempo real.
Se for dada a opção de executar o optimizador a partir da coruja, então também em tempo real a pedido.
 
Renat, é muito interessante conhecer a sua opinião sobre o assunto em questão.