Un peu surpris :) J'ai pensé que je devais partager et poser une question NON rhétorique. - page 22

Nouveau commentaire
 
MetaDriver:

1. il s'agit d'une opération unique pour chaque prise. La perte est insignifiante, puis les gains solides. :) Je suppose que le quotient d'origine est logarithmé une fois et converti en représentation entière.

2. C'est correct. Bien que ce soit rapide, car il existe un algorithme rapide qui utilise des décalages de bits.

3. pas plus que les contrôles de débordement.

4. la partie entière n'a pas besoin d'être allouée du tout. la fraction est stockée comme une paire de longs. et si possible, comme une paire d'ints.

5. exactement la même quantité si elle est stockée comme une paire de longs, et la moitié dans le cas où il y a assez d'ints (cela dépend des exigences de l'algorithme).

Si l'on considère que le principal consommateur de mémoire est un devis, alors avec la représentation en nombres entiers, le gain d'espace est indéniable.

Alors que le point principal n'est pas dans l'économie de mémoire, mais dans l'accélération. C'est beaucoup plus important.

--

Le problème avec Academician n'est pas qu'il a tort. C'est qu'il fait paraître les autres mauvais.

C'est ce qui irrite les personnes présentes et rejette les idées saines... Avec l'eau sale... :(

Vladimir, tu n'es pas confus ? Ce que vous avez décrit est de l'arithmétique de bas niveau double et flotte, la même arithmétique que "l'Académicien" propose d'introduire nécessite (même sans allocation d'une partie entière) au moins deux mantis pour le stockage.

Eh bien, où est l'économie dans tout ça ? 8 octets pour le double et 2*4 octets pour l'int.

Au mieux, vous arriverez au résultat déjà mis en œuvre.

 
Urain:

Vladimir, tu n'es pas confus ? Ce que vous avez décrit est une arithmétique de bas niveau de double et de flotte, la même arithmétique que "Akademik" propose d'introduire nécessite au moins deux mantis pour le stockage (même sans la partie entière).

Alors où est l'économie dans tout ça. 8 octets pour le double et 2*4 octets pour l'int.

Au mieux, vous arriverez au résultat déjà mis en œuvre.

Stockez donc tous les points ( dénominateurs) des quantités unidimensionnelles au même endroit - ils sont les mêmes. :)

Créez un type - une valeur en un dixième de point et c'est tout. Et stockez ce dénominateur séparément.

 
MetaDriver:

Je vais essayer. Sur mql5, si vous voulez... :)

J'ai juste besoin de temps. Je vais devoir écrire une bibliothèque.

J'ai essayé une fois, il n'y a pas de bonbons, c'est juste une perte de temps.

Décomposez le double en un nombre binaire et représentez-le comme deux ints et vous vous rendrez compte que tout ce que vous décrivez est déjà implémenté en arithmétique double.

Seule l'arithmétique est implémentée à un niveau bas, et vous la ferez à un niveau plus élevé, ce qui vous fera perdre en performance et en mémoire.

 

Mes cinq centimes.

Les nombres entiers sont une manière plus naturelle de présenter les informations relatives aux quotas. Après tout, il est impossible qu'un nombre de points ne soit pas un nombre entier. Le stockage de tels nombres est plus économique, et donc la vitesse de téléchargement aux niveaux disque-mémoire et mémoire-processeur est plus élevée. Les algorithmes sont beaucoup plus rapides que les algorithmes en nombres réels, et l'ESS en général est hors compétition. Mais il y a un gros problème avec les nombres entiers : seules les personnes qui comptent peuvent travailler avec eux. Et bien sûr, le terminal doit avoir le support asm. Pour le consommateur de masse MQ, ces chiffres ne sont pas adaptés.


D'ailleurs, le problème de la vérification du débordement est mis en œuvre au niveau des interruptions matérielles, il n'y a rien de mal à cela, au contraire, les gens y ont pensé il y a longtemps, lorsque les processeurs ont été créés. En principe, il existe de nombreux moyens et astuces de programmation d'algorithmes entiers, mais tout ceci, je le répète, n'est pas destiné aux utilisateurs de masse.


Je ne vois pas où est l'argument. Pouvez-vous créer un algorithme de test/optimisation plus rapide que celui que vous avez dans votre testeur ? Vous pouvez, mais ce ne sera pas un algorithme universel qui vivra dans une serre en présence de l'auteur - très peu de gens ont besoin d'une telle chose - ce n'est pas un produit de masse. Pour cette raison, les déclarations dans l'esprit de "le mien est plus rapide" ne peuvent être considérées que comme une preuve d'incomparabilité et de manque de compréhension du fait que vous ne pouvez pas comparer l'incomparable.

 
Urain:

J'ai essayé une fois, il n'y a pas de bonbons, c'est juste une perte de temps.

Décomposez le double en un nombre binaire et représentez-le comme deux ints et vous vous rendrez compte que tout ce que vous décrivez est déjà implémenté en arithmétique double.

ZZY Seule l'arithmétique est implémentée à un niveau bas, et vous la ferez à un niveau plus élevé, où vous perdrez en performance et en mémoire.

"Si je ne rattrape pas mon retard, je reste au chaud", comme disait le coq qui chassait la poule... :)

En fait, j'y pense depuis longtemps, il est probablement temps d'essayer.

 
MetaDriver:

"Si je ne les rattrape pas, je reste au chaud", disait le coq en poursuivant la poule... :)

En fait, cela fait un moment que j'y pense, alors je pense qu'il est temps d'essayer.

Algorithme NOD récursif à donner ?
 
TheXpert:

Pour quoi faire ? Le C++ est accepté.

Je vais regarder. Je dois d'abord le sentir. Je suis moi-même curieux de le savoir.
 
Urain:
Voulez-vous un algorithme NOD récursif ?
Si avec des décalages de bits, allez-y. Si avec la division modulo, ne le faites pas.
 
MetaDriver:
Si c'est avec des décalages de bits, allez-y. Si avec la division par modulo, alors ne le faites pas.

Allez-vous diviser un nombre (pas nécessairement un multiple de 2) par un autre nombre (pas nécessairement un multiple de 2) en utilisant un décalage de bits ?

Bon, je vais vous donner ce que j'ai, et vous déciderez ensuite si vous en avez besoin ou pas.

//+------------------------------------------------------------------+
long GreatestCommonDivisor(long v0,long v1)
  {
   return(GCD(fmax(fabs(v0),fabs(v1)),fmin(fabs(v0),fabs(v1))));
  }
//+------------------------------------------------------------------+
long GCD(long max,long min)
  {
   if(min>0)return(GCD(min,max%min));
   else return(max);
  }
//+------------------------------------------------------------------+
 
DDFedor:
Les smileys de vos futurs messages seront coupés. Gardez cela à l'esprit.

Merci de l'admettre - tu as supprimé les émoticônes, mais qui supprime des messages entiers ?

En passant, l'académie, Je pense que c'est génial que vous ayez une "calculatrice", mais je voudrais savoir si vous pouvez l'optimiser automatiquement pendant le trading ?

1...1516171819202122232425
Nouveau commentaire