rappel : auto-pebkac = BEDP

Surtout pour des floats!

Sans utiliser la fonction abs(), tu as pas pensé à un truc du genre

 if(x > 0)
   xAbs = x;
 else
   xAbs = -x;

Ça me fait penser à un collègue qui utilisait la fonction pow() pour faire des décalages de bits. Me demandez pas comment, mais il arrivait à un résultat correct.

Pour les entiers : http://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs

xabs = (x>0) ? x : -x;

quand tu fais un abs, tu dois regarder le signe de la valeur. En faisant sqrt(x*x), tu fais une sorte de linéarisation , x carré est forcement positif donc pas de problèmes pour faire la racine carrée

un décalage de n bits correspond à une multiplication ou une division par 2 puissance n

Bah en l'absence d'une fonction abs() (hypothèse puisqu'on ne connaît pas le langage en question), perso je trouve ça pas si con (mais seulement si on parle d'entiers, sur des float on doit perdre en précision), et plus compact qu'un test if/else.

D'ailleurs, sur la TI-89, taper √(x²) renvoie bien |x|

Il ne faisait apparemment pas de multiplication ou division, directement un xdecale = pow(x, n)

Je vois quand même un gros problème, en imaginant un int standard sur 32 bits, le carré provoquerait un oveflow dès 46341, qui se traduirait de la manière suivante :
46341^2 = 2147488281, soit en binaire 10000000000000000001001000011001. Donc, pour un integer sur 32 bits, ça donne le résultat suivant :
46341^2 = -2147479015

Je n'ai pas essayé le sqrt sur un nombre négatif, mais à mon avis ce n'est pas beau à voir.

"Plus compact qu'un test if/else"

Peut-être au niveau du code, mais il faut peut-être rappeler que le processeur ne sait pas faire de x² nativement. Ça se traduit par plusieurs multiplications.

Faire faire au processeur plusieurs multiplications (qui prennent pas mal de temps), et en plus avoir un overflow très rapidement (cf mon post au dessus), au lieu d'une simple comparaison qui prend 1 cycle suivie d'une éventuelle affectation du complément à 2 (qui prend 1 cycle également, en fonction de l'affectation, c'est quelques cycles en plus), ce n'est vraiment pas une bonne idée.

yep je parlais plus d'un point de vue théorique. après l'informatique à ses limites

Et pour la racine carrée, je ne pense pas qu'un processeur sache le faire nativement non plus. Ca doit surement impliquer quelques divisions, qui sont des opérations très lourdes pour un processeur (plus que les multiplications si mes souvenirs sont bons).

Tout à fait Acorah, la division est une opération plus complexe que la multiplication pour un processeur.

Toutefois, la majorité des processeurs actuels ont une ALU qui fait des divisions aussi rapidement que des multiplications.

Exact, mais j'ai pas dit que c'était plus rapide, simplement plus compact (en parlant du code). Et pour le calcul de la racine carrée, je ne sais pas si c'est standardisé ou si chacun fait à sa sauce, mais si on part sur l'hypothèse de divisions successives, alors à mon avis on utilise ça:
https://fr.wikipedia.org/wiki/Fraction_continue_d%27un_irrationnel_qua[...]

En plus de permettre le calcul des racines carrées, ça a un nom qui en jette quand tu claque ça au détour d'une conversation :D

int pow(int x, int n)
 {
      if(n=0)
           x<<0;
      else if(n=1)
           x<<1;
      else if(n=2)
           x<<2;
      else if(n=3)
           x<<3;
      
      ...
      
      return x;
 }

L'overflow sur le carré ne retourne pas un truc du genre NaN ? Du coup le programme ne devrait même pas essayer de faire le moindre calcul avec et déclencher une erreur, non ?

Acorah > sur un float, certainement, mais là on parlait uniquement du cas des entiers.

Oui, mais que ce soit avec la racine du carré ou avec la condition, c'est faux puisque ça ne marche pas avec les nombres complexes.

@Moot

Ile censé faire quoi ton code ?
1) x<<y ça fait une opération dans le vide, il faut réaffecter le résultat à x.
2) Au lieu d'écrire des if et else if à l'infini, tu ferais mieux de faire directement x = x << n;
3) Ton code est faux, il ne fonctionne que si x est une puissance de 2. Exemple : 5^3 = 125. Mais 5 = 101b, 125=1111101b.

Heureusement que ce n'est pas un entretien d'embauche ;)

J'en rajoute :
4) Même pour les puissances de 2, ton code est faux. Il faudrait :
if (n == 0)
return 1;
else
return x << (n - 1);

J'espère que c'est un troll.

Dans le doute:
1) Si le langage n'a pas de fonction "valeur absolue", il n'aura certainement pas de fonction "carré", et encore moins de fonction "racine".
2) Du point de vue performance, faire deux opérations lourdes au lieu d'un test et d'une inversion de signe est catastrophique.
3) Si c'est juste une question de compacité du code, le mieux est d'écrire la fonction/macro dans une bibliothèque perso et de simplement l'appeler dans le code.
4) Entre x = racine(x * x) et si (x < 0) x = -x on est kif-kif niveau compacité du code.

et personne n'a pense a clearer le bit de poid fort ?

Faites entrer le poney xD

Pour le calcul de racine carré l'algo utilisé dans les calculatrices est la méthode de Héron, qui fournit une convergence assez rapide:
https://fr.wikipedia.org/wiki/M%C3%A9thode_de_H%C3%A9ron

J'espère que personne n'y a pensé, effectivement, car tous les processeurs (sauf peut-être 1 ou 2 exceptions) utilisent le complément à 2.

J'espère que vous parlez tous de programmation assembleur parce qu'en n'importe quel langage de 3e génération, il est vraiment préférable de laisser le compilateur choisir la méthode la plus appropriée. Votre code sera plus lisible et il est fort probable que le compilateur fera moins de fautes que vous, le tout pour gagner des clopinettes.

Je vois souvent des gens écrire des trucs bizarres en Java ou .NET pensant que ça va optimiser le code alors que le résultat est, au mieux, le même, au pire, une bombe à retardement.