Erros, bugs, perguntas - página 681

 
Renat:
Não parece estar a pensar com clareza.

Tem medo de gastar o seu próprio tempo no cálculo de características de barras adicionais para casos muito raros (perto de zero %), mas exige alegremente que sejamos nós a preparar muitos dados em casos a 100%, retardando e consumindo memória muitas vezes.

Algumas pessoas metodicamente dão conselhos tão simpáticos para se matarem contra a parede que é tempo de falar de pragas.

Os estrategas deste tipo são imediatamente visíveis.

Se analisar cuidadosamente todos os meus posts sobre este e vários anteriores, e depois brincar com o indicador multitemporal de marcação de TA gráfica nos fractais, já não vai querer discutir comigo sobre este tópico, como depois de um balde de água gelada. Mas o problema é que o indicador não está completamente optimizado (não diz respeito a este tópico) e não está funcionalmente completo. É por isso que desperdiço os meus recursos em disparates, não em completá-los e libertá-los.

Há muitos objectos gráficos. E ainda tem de as limpar... Já há problemas suficientes.

 
Este é um caso especial em questão.
 
Renat:
Este é um caso particular.
O rastreio automático ao vivo é procurado por um pouco menos do que todos os que negoceiam com as suas mãos. Quem escreve MTS/ATS em osciladores, deslizadores e afins, deixe-os fazê-lo. Eu utilizaria este indicador para auto-comercializar "a partir daquela linha ali", mas a MQL não consegue ver nenhuma linha por si só. Então pode dizer adeus aos recursos, mesmo 16 GiG parecerá um escárnio.
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы объектов / Типы объектов - Документация по MQL5
 
Yedelkin:

Tenho a sensação de que haverá uma votação :)

Ou matar alguém contra a parede :)
 

Tudo foi em tempos privado, a primeira ideia na mente do inventor-pioneer também se aninhava nele sozinho como algo privado. Depois tornou-se popular e espalhou-se... e até se tornou incorporado por defeito como uma ferramenta do sistema. Familiar, não é?

Caso contrário, nada se teria transformado em nada...

 
abolk:
Ou matar alguém contra a parede :)

Esse é o resultado mais provável.

E tenho a sensação de que a minha pergunta nunca será respondida e terei de escrever para a CBO... :(

 
MetaDriver:

2. já vi. Então? Muitas barras em falta? Também não tenho ilusões a esse respeito. Tenho uma pergunta. Não é de todo original e de forma alguma "exclusivamente privado". Nomeadamente: o modo de acesso (e exibição!) às cotações (incluindo, sim, sim!, as de baixa liquidez) automaticamente (!!) suportado pelo fabricante do terminal, no qual todos os buracos intra-sessão nas cotações são preenchidos com dodges com os parâmetros {Volume=0, Aberto=Alto=Baixo=Fechado=[preço anteriorde fecho de barra]}. Ou serei eu um grande original? Sê honesto, Renat. Colocando a mão direita no coração esquerdo.

A minha experiência indica claramente que o preenchimento dos espaços em branco é um disparate e uma auto-ilusão, que se desvendará imediatamente assim que a história for preenchida.

Esta questão foi levantada muitas vezes ao longo dos últimos 10 anos.

 
x100intraday:
O autoplotting ao vivo é procurado por um pouco menos do que todos os que negoceiam mãos. Quem escreve MTS/ATS em osciladores, deslizadores e afins - que o façam, eu utilizaria este indicador para auto-comercializar "a partir daquela linha ali", mas o próprio MQL não vê nenhuma linha, por isso tenho de ir à planimetria, procurar raízes de hipotenusa, preencher a matriz quadrada da Escala de Gann e aplicar uma EA a esse indicador. Então pode dizer adeus a todos os recursos. 16 gig será um escárnio aqui.

Ou seja, quer transferir para nós o pesado pré-cálculo dos estados para a sua solução, pensando que a felicidade se seguirá.

Ou seja, nem sequer se dá conta das consequências do facto de, como resultado, arruinarmos o desempenho do terminal 100% do tempo e desperdiçarmos muito mais memória. Esse é o conselho malicioso.

Se estiver a desenvolver uma solução complexa, utilize métodos algorítmicos para reduzir a quantidade de cálculos em cada caso , em vez de tentar resolver o problema directamente. Utilizar preparação de fundo de caches com os dados necessários.

 
Renat:

Ou seja, quer transferir para nós o pesado pré-cálculo dos estados para a sua solução, pensando que a felicidade se seguirá.

Ou seja, nem sequer se dá conta das consequências do facto de, como resultado, arruinarmos o desempenho do terminal 100% do tempo e desperdiçarmos muito mais memória. Este é um conselho malicioso.

Se criar uma solução complexa, utilize métodos algorítmicos para reduzir a quantidade de cálculos em cada caso particular , em vez de tentar resolver o problema de frente. Utilizar preparação de fundo de caches com os dados necessários.

As caches devem estar localizadas em disco, claro, e não em algum lugar... na RAM? Refere-se a operações de leitura/escrita de ficheiros? Mas, em primeiro lugar, não é mais conveniente do que se estiver a empilhar valores exactos_de_tempo[] na base de dados à custa do terminal. Um bom ambiente de desenvolvimento deve fornecer a todos os seus utilizadores ferramentas prontas a usar, que cada utilizador pode inventar por si próprio, mas esforçar cada utilizador com a mesma tarefa isoladamente é impiedoso. Trata-se de pormenores. Não existe tal coisa como especial e não se pode esperar, é uma ilusão. Eu próprio estou no fórum mais por causa de sugestões e de trazer novas ideias, e depois apenas por fazer perguntas sobre características já construídas (pode estudar a ajuda se quiser). E, em segundo lugar, lembro-me do absurdo da análise dos codificadores MQL - lembra-me de puxar todo o arquivo para um ficheiro em particular, e não de puxar um único ficheiro seleccionado com precisão. Se fizer um pré-cálculo dos tempos exactos dos extremos, levará sem dúvida tempo e recursos da máquina, mas não serão gastos menos recursos na nossa própria análise. Algo me diz que o C funciona um pouco mais rápido do que o MQL. Especulação ou facto? E o pior é que temos de verificar periodicamente o estado actual dos objectos expostos, ou seja, os recálculos parciais. Para evitá-los, é necessário tomar dados previamente calculados da cache, mas isso é do "primeiro" anterior.
 
Afinal de contas, isto é incorporado no terminal como uma característica para que se possa escolher opcionalmente se o terminal calcula ou não tempos de barra precisos. Esta é uma prática padrão, deixar o utilizador escolher entre precisão e tempo. No entanto, a possibilidade de os programadores de MQL acreditarem que os programadores de terminais devem pré-calcular atributos adicionais de barras é estranha e não séria. É claro que também podemos fazer muito, mas precisamos de ver e distribuir claramente os papéis entre os programadores de terminais e os programadores MQL que tentam ser objectivos.