Idéias ambiciosas!!! - página 7

 
Mathemat:

Errado novamente. A interpretação do fluxo de entrada é a tarefa daquele que está acima do receptor e estabelece as condições do jogo. O receptor é de ferro; ele tritura as informações de acordo com o algoritmo definido para ele pelo Game Master. Neste sentido, é completamente e estritamente objetivo, porque é um ferro burro. Mas é o Mestre que é subjetivo.

Você sabe que as informações podem ser definidas de diferentes maneiras, dependendo do contexto do problema que está sendo resolvido?

Por subjetividade do receptor quero dizer que ele pode interpretar a informação de entrada de forma arbitrária, de acordo com o algoritmo implícito nela. Neste caso, a informação objetiva de entrada é transformada pelo receptor em uma informação subjetiva. O contexto e tudo mais não tem nada a ver com isso.
 
Obrigado, não é um site ruim.
 
Algumas pessoas pensam que o OOP é realmente eficaz em grandes projetos, enquanto que nos pequenos é melhor usar a boa e velha programação de procedimentos. Mas não estou de acordo com esta opinião. Se o programa que você deseja escrever for maior do que "Olá palavra" por pelo menos uma linha, é melhor usar o OOP do que a programação processual. Pela minha própria experiência, posso dizer que mesmo os menores programas são melhorados, novas funcionalidades, novas verificações, novas tarefas são acrescentadas a eles. Como resultado, um programa que foi inicialmente concebido como um programa pequeno se transforma em um verdadeiro monstro. É muito importante lançar aqui as bases. Se isto for programação processual, um projeto será superado com um monte de funções incontroláveis, conversões de ponteiro, etc., etc. O OOP é uma coisa ruim. Escreva programas nele, começando com "Hello Word", e depois facilmente e de bom grado desenvolva sua funcionalidade. Por exemplo, é impossível escrever até mesmo o menor programa em C# sem usar o OOP. Você acha que os desenvolvedores desta linguagem são idiotas míopes?
 
C-4:
Mas eu não concordo com essa opinião. Se o programa que você quer escrever é mais do que "Olá palavra" por pelo menos uma linha, é melhor usar o OOP em vez de
Você poderia nos dar um exemplo concreto para comparar com ele, para não ser infundado?
 

Aí está, o tema foi desviado, estávamos falando de outra coisa:

>OCULTO 10.11.2010 22:39

>Há alguns anos, tenho sido assombrado pela idéia de implementar um testador de estratégia com várias moedas.

Se você não gosta do OOP, não o use, é um argumento inútil.

 
xeon:

Aí está, o tema foi desviado, estávamos falando de outra coisa:

>OCULTO 10.11.2010 22:39

>Há alguns anos, tenho sido assombrado pela idéia de implementar um testador de estratégia com várias moedas.

Se você não gosta do OOP, não o use, é um argumento inútil.


Li tudo o que foi escrito aqui, e agora tenho muito medo do MT5 porque estou obcecado com ele, e quero implementá-lo o mais rápido possível.

Graças a todos aqueles que sabem como colocar os cérebros corretamente (razoavelmente) no lugar.

Se eu acho que o MT5 é desenvolvido por uma equipe de pessoas, e todos nós estamos testando-o, quanto tempo eu vou gastar para sua implementação na MQL4? E o MT4 estará morto mais cedo ou mais tarde, é apenas uma questão de tempo. Acho que o MT5 vai durar 5-10 anos de qualquer maneira.

 
HIDDEN:

Depois de ler tudo o que foi escrito aqui, comecei a olhar para o MT5 porque estou realmente atraído por ele, e quero implementá-lo o mais rápido possível.

Graças a todos aqueles que sabem como colocar os cérebros corretamente (razoavelmente) no lugar.

Se eu acho que o MT5 é desenvolvido por uma equipe de pessoas, e todos nós estamos testando-o, quanto tempo eu vou gastar para sua implementação na MQL4? E o MT4 estará morto mais cedo ou mais tarde, é apenas uma questão de tempo. Acho que o MT5 vai durar 5-10 anos de qualquer maneira.

No momento no testador MT5, há um obstáculo intransponível (pelo menos por enquanto), que pode colocá-lo (para alguns usuários) fora, é a impossibilidade de definir para teste/optimização o próprio histórico (de terceiros).
 
xeon:
No momento, no testador MT5, há um obstáculo insuperável (pelo menos por enquanto) que pode desistir dele (para alguns usuários), é a impossibilidade de usar seu próprio histórico (de terceiros) para testes/optimização.


Infelizmente, existem alguns "pontos sensíveis" no MT5 - indicadores multimoedas - muito instáveis trabalhando no testador, é difícil depurar indicadores multimoedas devido à necessidade de carregamento independente de matrizes de séries de tempos - ainda não feito, mas em breve eu irei - mover o cálculo de indicadores multimoedas para o próprio Expert Advisor - então os problemas devem ir embora

SBS: graças ao iniciante do tópico por entender - ficamos bastante ocupados em seu tópico :), com a implementação de um autoteste multi-divisas no MT4, não há problemas particulares - exemplos decentes no fórum, mas como um testador totalmente funcional não funcionará, e se esforçará para criar seu próprio testador - perda de tempo - com o mesmo sucesso você pode analisar o comércio multi-divisas no mesmo Exel

 
IgorM:


infelizmente, há algumas "questões delicadas" no MT5 - indicadores multimoedas - eles não funcionam com confiança no testador, é difícil depurar indicadores multimoedas devido à necessidade de carregamento independente de conjuntos de séries temporais - ainda não feito, mas em breve eu o farei - eu moverei o cálculo de indicadores multimoedas para o próprio Expert Advisor - então os problemas devem ir embora

O histórico de bombeamento do banco de dados do MQ é fácil, especialmente porque existe um exemplo pronto: - https://www.mql5.com/ru/docs/series/timeseries_access

p.s. se entendi a tarefa corretamente...

 
xeon:
No momento no testador MT5, há um obstáculo intransponível (pelo menos por enquanto) que pode acabar com ele (para alguns usuários), que é a incapacidade de substituir seu próprio histórico (de terceiros) para testes/optimização.


Isso é um dado adquirido. Os principiantes não precisam realmente dele, mas no comércio real é uma coisa necessária.