Portanto, se uma ordem é fechada, ela deve ser "riscada" da matriz. Nesses casos, eu costumava copiar a matriz "em si mesma" e reduzir o tamanho em um.
Nesse caso, eu escreveria um bilhete inexistente na matriz -1 , esperaria até que todos os pedidos fossem fechados e apagaria toda a matriz (o tamanho da matriz deve ser ajustado para 1).
Nesta abordagem, um elemento do conjunto de bilhetes (se não houver ordem) é verificado com apenas uma condição: if(ArrayOfTicket[i] > 0) .....
imho, é mais rápido do que "sacudir" constantemente a matriz
Nesse caso, eu escreveria um bilhete inexistente no array -1 , esperaria até que todos os pedidos fossem fechados e apagaria o array inteiro (tamanho do array = 1).
Nesta abordagem, um elemento do conjunto de bilhetes (se não houver ordem) é verificado com apenas uma condição: if(ArrayOfTicket[i] > 0) .....
imho, é mais rápido do que "sacudir" constantemente a matriz
Eu não entendo... Que diferença faz se apagar elemento por elemento ou verificar os índices de ordens inexistentes... a matriz é abalada de qualquer forma...
De qualquer forma, como eles disseram nas notícias de hoje, é impossível patentear o sabor. Os floureshers só diferem na cor, mas todos eles têm o mesmo sabor.
Eu não entendo... Que diferença faz se você quer apagar itens um a um ou verificar índices de ordens inexistentes... De qualquer forma, a matriz é ultrapassada...
De qualquer forma, como eles disseram nas notícias de hoje, é impossível patentear o sabor. Os floureshers só diferem na cor, mas todos eles têm o mesmo sabor.
Eliminar um elemento implica copiar os elementos restantes da matriz, não elimino elementos da matriz, marco elementos inexistentes (bilhetes) com valor -1, e elimino uma matriz de bilhetes quando não há ordens de mercado
Quanto aos marcadores de flutuação, é definitivamente verdade, depende do problema, em princípio, há normalmente 2 soluções durante a otimização:
- ou acrescentar complexidade ao algoritmo, mas salvar a memória e os recursos computacionais do PC
- ou simplificar o algoritmo e economizar recursos computacionais, mas desperdiçar memória
O checksum não está correto, se houver 0 na matriz pode haver um erro
A variante de Nikitin funciona exatamente para tal erro.
Sim, você está certo. Somente Nikitin adicionalmente jogou fora zero elementos. É por isso que seu código parecia estar com defeito. Na verdade, era resolver a tarefa que você havia definido originalmente. Se você documentar seu cheque por elementos nulos, o resultado é o mesmo:
2018.11.1413:50:34.481 ArrayDeleteValue (BTCUSD,M15) вариант Pastushak: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 133765 микросекунд
2018.11.1413:50:34.486 ArrayDeleteValue (BTCUSD,M15) вариант Korotky: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 2330 микросекунд
2018.11.1413:50:34.489 ArrayDeleteValue (BTCUSD,M15) вариант Fedoseev: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 1840 микросекунд
2018.11.1413:50:34.492 ArrayDeleteValue (BTCUSD,M15) вариант Semko: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 777 микросекунд
2018.11.1413:50:34.497 ArrayDeleteValue (BTCUSD,M15) вариант Pavlov: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 2818 микросекунд
2018.11.1413:50:34.503 ArrayDeleteValue (BTCUSD,M15) вариант Nikitin: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 3922 микросекунд
2018.11.1413:50:34.510 ArrayDeleteValue (BTCUSD,M15) вариант Vladimir: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 4239 микросекунд
2018.11.1413:50:34.519 ArrayDeleteValue (BTCUSD,M15) вариант Peter: Контрольная сумма = 7192.975450836821; элементов - 998993; время выполнения = 7307 микросекунд
2018.11.1413:50:34.522 ArrayDeleteValue (BTCUSD,M15) вариант Kuznetsov: Контрольная сумма = 7185.677992388435; элементов - 998993; время выполнения = 683 микросекунд
Mais uma vez, o checksum agora leva em conta a ordem dos elementos, o que não acontecia antes.
Sim, você está certo. Somente Nikitin também estava jogando fora elementos nulos adicionais. É por isso que seu código parecia errado. Na verdade, era resolver a tarefa que você havia definido originalmente. Se você documentar seu cheque para itens nulos, o resultado é o mesmo:
Mais uma vez, o checksum agora leva em conta a ordem dos elementos, o que não acontecia antes.
A propósito, se a ordem for muito importante, você pode adicionar ArraySort no final da minha variante e ver o quão eficaz é o ArraySort.
Agora estou interessado em outra pergunta, para a qual não consigo encontrar resposta. Talvez alguém possa explicar por que esta variante do código de Kuznetsov:
A propósito, se a ordem é muito importante, posso adicionar o ArraySort no final de minha versão, ao mesmo tempo vamos ver o quão eficaz é o ArraySort.
Eu já tentei. É uma função bastante dispendiosa. É mais fácil jogar fora depois, porém. Todos os necessários vão em fila.
Nikolai Semko:
Sim, você está certo. Somente Nikitin estava jogando itens nulos além disso. É por isso que seu código parecia errado. Na verdade, era a tarefa que você havia definido logo no início. Se você documentar seu cheque para itens nulos, o resultado é o mesmo:
Quase todas as funções podem ser adaptadas a ela. Aqui está o meu último (que foi puramente experimental, mas parece ser um dos menos caros).
template<typename T>
int arrayFilter(T &data[],const T value=NULL)
{
int s, _s = s = ArraySize(data);
bool result = false;
for(int i=0, j=0; i<_s; i++)
{
if( data[i] == value || data[i] == NULL )
{
result = true;
s--;
continue;
}
if( result )
data[j] = data[i];
j++;
}
if(s < _s)
ArrayResize(data, s);
return s;
}
Portanto, se uma ordem é fechada, ela deve ser "riscada" da matriz. Nesses casos, eu costumava copiar a matriz "em si mesma" e reduzir o tamanho em um.
Nesse caso, eu escreveria um bilhete inexistente na matriz -1 , esperaria até que todos os pedidos fossem fechados e apagaria toda a matriz (o tamanho da matriz deve ser ajustado para 1).
Nesta abordagem, um elemento do conjunto de bilhetes (se não houver ordem) é verificado com apenas uma condição: if(ArrayOfTicket[i] > 0) .....
imho, é mais rápido do que "sacudir" constantemente a matriz
Nesse caso, eu escreveria um bilhete inexistente no array -1 , esperaria até que todos os pedidos fossem fechados e apagaria o array inteiro (tamanho do array = 1).
Nesta abordagem, um elemento do conjunto de bilhetes (se não houver ordem) é verificado com apenas uma condição: if(ArrayOfTicket[i] > 0) .....
imho, é mais rápido do que "sacudir" constantemente a matriz
Eu não entendo... Que diferença faz se apagar elemento por elemento ou verificar os índices de ordens inexistentes... a matriz é abalada de qualquer forma...
De qualquer forma, como eles disseram nas notícias de hoje, é impossível patentear o sabor. Os floureshers só diferem na cor, mas todos eles têm o mesmo sabor.
Eu não entendo... Que diferença faz se você quer apagar itens um a um ou verificar índices de ordens inexistentes... De qualquer forma, a matriz é ultrapassada...
De qualquer forma, como eles disseram nas notícias de hoje, é impossível patentear o sabor. Os floureshers só diferem na cor, mas todos eles têm o mesmo sabor.
Eliminar um elemento implica copiar os elementos restantes da matriz, não elimino elementos da matriz, marco elementos inexistentes (bilhetes) com valor -1, e elimino uma matriz de bilhetes quando não há ordens de mercado
Quanto aos marcadores de flutuação, é definitivamente verdade, depende do problema, em princípio, há normalmente 2 soluções durante a otimização:
- ou acrescentar complexidade ao algoritmo, mas salvar a memória e os recursos computacionais do PC
- ou simplificar o algoritmo e economizar recursos computacionais, mas desperdiçar memória
O checksum não está correto, se houver 0 na matriz pode haver um erro
A variante de Nikitin trabalha exatamente em tal erro.
O checksum não está correto, se houver 0 na matriz pode haver um erro
A variante de Nikitin funciona exatamente para tal erro.
Sim, você está certo. Somente Nikitin adicionalmente jogou fora zero elementos. É por isso que seu código parecia estar com defeito. Na verdade, era resolver a tarefa que você havia definido originalmente.
Se você documentar seu cheque por elementos nulos, o resultado é o mesmo:
Mais uma vez, o checksum agora leva em conta a ordem dos elementos, o que não acontecia antes.
Sim, você está certo. Somente Nikitin também estava jogando fora elementos nulos adicionais. É por isso que seu código parecia errado. Na verdade, era resolver a tarefa que você havia definido originalmente.
Se você documentar seu cheque para itens nulos, o resultado é o mesmo:
Mais uma vez, o checksum agora leva em conta a ordem dos elementos, o que não acontecia antes.
A propósito, se a ordem for muito importante, você pode adicionar ArraySort no final da minha variante e ver o quão eficaz é o ArraySort.
Agora estou interessado em outra pergunta, para a qual não consigo encontrar resposta.
Talvez alguém possa explicar por que esta variante do código de Kuznetsov:
funciona mais que o dobro da velocidade deste, que faz exatamente a mesma coisa:
Quais são as maravilhas do compilador?
É possível que para um projeto desse tipo:
while(arr[i]!=x && i<j) i++;o compilador encontra algum comando especial de busca do assembler para o processador?
Alguém é forte nos comandos dos processadores modernos?
A propósito, se a ordem é muito importante, posso adicionar o ArraySort no final de minha versão, ao mesmo tempo vamos ver o quão eficaz é o ArraySort.
Eu já tentei. É uma função bastante dispendiosa. É mais fácil jogar fora depois, porém. Todos os necessários vão em fila.
Sim, você está certo. Somente Nikitin estava jogando itens nulos além disso. É por isso que seu código parecia errado. Na verdade, era a tarefa que você havia definido logo no início.
Se você documentar seu cheque para itens nulos, o resultado é o mesmo:
:
funciona mais do dobro da velocidade de um que faz exatamente a mesma coisa:
o otimista é irrelevante - as comparações são menos da metade.