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

 
Renat:

Il est facile de passer d'une déclaration ratée à une autre.

Lorsque vous disposez d'un processeur avec des types de données rationnels et qu'un autre ensemble de commandes SSExxx peut les traiter plus rapidement que le double, vous pouvez alors introduire les nombres rationnels dans la discussion sur l'accélération des calculs. Lorsque vous publierez des tests de calcul de la SMA avec différentes méthodes et que vous montrerez des gains supérieurs au double, alors ce sera un discours de pratique.

Entre-temps, la déclaration initiale concernant l'accélération des calculs mathématiques réels par le passage aux nombres entiers a échoué.

Tu quoi ? ! Je n'ai pas sauté quoi que ce soit. Si tu n'en lis que la moitié. Hélas. J'ai parlé des fractions rationnelles une vingtaine de fois. Mais jusqu'à ce que je précise qu'il s'agit de fractions, personne n'a compris. :) Je te le dis, c'est ridicule. Hélas. :(


:) Raté - Je parlais de nombres entiers et du concept de POINT, et un point est toujours le dénominateur. 13000 points si un point est égal à 10000 - alors la valeur est = 13000/10000 = 1.3 :)

 
Academic:

Qu'est-ce que tu fais ? Je n'ai sauté nulle part. Si tu n'en lis que la moitié. Je suis désolé. Je vous ai déjà parlé des citernes rationnelles vingt fois. Mais jusqu'à ce que je précise qu'il s'agit de fractions, personne n'a compris. :) Je te le dis, c'est ridicule. Hélas. :(


:) Raté - Je parlais de nombres entiers et du concept de POINT, et un point est toujours le dénominateur. 13000 points si un point est égal à 10000 - alors la valeur est = 13000/10000 = 1.3 :)

Vous proposez de traiter trois longueurs de 8 octets (partie entière + dénominateur + numérateur) au lieu d'un double de 8 octets. Et si vous commencez à couper les longs en quelque chose de plus court, vous obtiendrez un dépassement dans des calculs tout à fait adéquats.

Même trois ints et c'est plus qu'une prise.

 
Urain:
Vous proposez de traiter trois longueurs de 8 octets (partie entière + dénominateur + numérateur) au lieu d'un double de 8 octets. Et si vous commencez à couper les longs en quelque chose de plus court, vous obtiendrez un dépassement dans des calculs tout à fait adéquats.

Vous avez choisi la pire façon de l'appliquer. Vu ce que vous m'avez dit, ça ne colle pas. Lequel d'entre nous est le mieux placé pour le savoir ?

Il y a un nombre en kilomètres - c'est int32 et il n'a pas besoin d'autre chose. Vous n'avez pas besoin de l'additionner avec une valeur dans une autre dimension. :) Si vous voulez plus de précision que les kilomètres, passez aux nanomètres. :) Et les stocker comme un nombre entier. :)

 

TheXpert:

Et deuxièmement, je doute fortement que l'arithmétique avec des doubles soit plus lente qu'avec des nombres rationnels.

Le ralentissement de Wapchet. Mais il nous a fourni un mauvais lien.

1. L'implémentation dans BOOST normalise les nombres rationnels à chaque opération avec eux. Il n'est pas nécessaire de le faire sur chaque personne, car cela coûte cher. Il est préférable de ne le faire que lorsqu'il existe une menace réelle de débordement du dénominateur.

2. La réduction à un dénominateur commun (plus précisément, le calcul du plus grand diviseur commun) n'y est pas effectuée par l'algorithme le plus rapide. C'est de loin le plus rapide.

Avec correction, il a raison sur la vitesse des nombres rationnels.

Je les aurais dans mql, si le rechargement des opérations arithmétiques était disponible. Sans elle, ma syntaxe serait très fastidieuse (fonctionnelle), alors oubliez-la... С++ :-)

--

Mais ce serait vraiment cool s'il y avait un support au niveau du processeur...

 
MetaDriver:

Le ralentisseur Wapchetta. Seul le lien qu'il a donné était faux.

1. L'implémentation dans BOOST normalise les nombres rationnels à chaque opération sur eux. Vous n'avez pas besoin de le faire sur chacun d'entre eux, parce que c'est cher. Il est préférable de ne le faire que lorsqu'il existe une menace réelle de débordement du dénominateur.

2. La réduction à un dénominateur commun (plus précisément, le calcul du plus grand diviseur commun) n'y est pas effectuée par l'algorithme le plus rapide. De loin, il y en a un plus rapide.

Cela dit, il a raison au sujet de la vitesse des chiffres.

Je les aurais dans mql, si le rechargement des opérations arithmétiques était disponible. Mais sans cela, j'obtiendrais une syntaxe très fastidieuse (fonctionnelle), alors oubliez-la... С++ :-)

--

Mais ce serait vraiment cool s'il y avait un support au niveau du CPU...

L'arithmétique elle-même est plus lente parce que nous devons toujours gérer la virgule flottante (si nous comparons l'arithmétique pure des doubles et des longs), si nous convertissons les doubles en arithmétique des entiers, nous perdons. Le calcul récurrent de NOD nécessiterait à lui seul log(N) opérations, sans parler du fait que chaque opération de multiplication nécessiterait de vérifier le débordement. Puis 4 autres divisions (deux par NOD et pour extraire la partie entière et le reste fractionnaire).

En plus de cela, vous devrez toujours allouer plus de mémoire pour stocker toutes ces bêtises que vous n'en avez besoin pour la prise.

 
MetaDriver:

Le ralentissement de Wapchet. Seul le lien qu'il a cité était malheureux.

Une preuve ? Vous faites certainement plus autorité à mes yeux que l'auteur original, mais c'est une affirmation forte.

C'est pourquoi j'aimerais voir des tests comparatifs.

 
Urain:

L'arithmétique elle-même est plus lente parce qu'elle doit encore gérer la virgule flottante (si vous comparez l'arithmétique pure des doubles et des longs),

1. si vous convertissez les doubles en arithmétique entière, vous perdez.

2. le calcul récurrent de NOD nécessiterait à lui seul log(N) opérations, sans parler du fait que

3. chaque opération de multiplication nécessitera un contrôle de débordement.

4. Puis 4 autres divisions (deux par NOD et pour extraire la partie entière et le reste fractionnaire).

5. En plus de tout cela, vous devrez toujours allouer plus de mémoire pour stocker toutes ces absurdités que ce qui est nécessaire pour la prise.

1. Il s'agit d'une opération unique pour chaque prise. La perte est insignifiante, puis les gains sont 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... :(

 
TheXpert:

C'est pourquoi j'aimerais voir des tests comparatifs.

Je vais essayer. Sur le mql5, si on en arrive là... :)

J'ai juste besoin de temps. Il faudrait que j'écrive une bibliothèque.

 
MetaDriver:

Je vais essayer. Dans le MQL5, si on en arrive là... :)

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

MetaDriver:

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

Le problème est qu'il se croit plus intelligent que les autres et qu'il essaie constamment de ridiculiser quelqu'un d'autre.

Et il se plante. Dans certains endroits, beaucoup.

 
MetaDriver:

Le problème de l'universitaire n'est pas qu'il a tort. C'est qu'il donne l'impression que les autres ont tort.

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

Je ne me mets pas dans la tête des gens. Mais je suis inversé. :) Qui a demandé des conseils pour savoir si je devais suivre le thème ? :)

Et puis je suis celui qui est celui qui est celui qui est celui... :) Eh bien, ne venez pas me voir.

Quelle est la différence en général ? Qu'y a-t-il à discuter ? IMHO - tout reste au même niveau embryonnaire qu'avant. Donc il n'y a pas de problème avec moi - c'est comme si je n'existais pas. :)