Je cherche à tronquer une latitude/longitude au centième.
Exemple: 7.0275 devient 7.02, 44.2133 devient 44.21
Il faut absolument que le nombre soit tronqué et non arrondi.
Je n'ai pas trouvé de solution adaptée sur internet.
Ce serait possible en utilisant String et subString mais il paraît qu'il vaut mieux ne pas utiliser cela.
Comment faire ?
Solution:
Serial.begin(9600);
float number=7.0456;//nombre à tronquer
int internum=number*100;//100 pour tronquer au 100ième
float troncated=(float)internum/100;//100 pour tronquer au 100ième
Serial.println(troncated, 6);// affichage 6 chiffres après la virgule
la question est pourquoi ?
ça ressemble à un problème X-Y
pour la réponse vous multipliez par 100, prenez la partie entière et redisiez par 100.0
mais les floats ont une piètre précision donc vous pouvez ne pas retrouver exactement ce que vous vouliez
En fait, je reçois les coordonnées de la position exacte d'un GPS. D'autre part je dispose de données météorologiques sous forme d'une grille.
Dans un fichier JSON (qui sera extrait), on dispose d'une multitude de points, tous écarté de un 1 centième de latitude/longitude. Ex: premier point de la grille: lat=7.02, 2e=7.03, 3e=7.04...
En tronquant au centième la latitude et la longitude du point où se situe le gps on obtient les coordonnées du point inférieur droit le plus proche dont les données peuvent être extraites.
Ex: le gps se situe à 7.0456;44.2825
Le point de grille inférieur droit le plus proche est au coordonnées exactes 7.04;44.28
Les 3 autres points de la grille les plus proches peuvent être ensuite simplement trouvés également afin d'avoir une donnée moyenne plus précise à l'endroit où se situe le gps.
J'espère que vous m'avez compris, ce n'est pas très simple.
Quelque chose comme ça ?
Serial.begin(9600);
float number=7.0456;
int number2=number*100;
float number3=number2/100;
Serial.println(number2);
Serial.println(number3);
Si on ne met pas la virgule la division est entière.
Attention vous avez l’impression que ça fonctionne bien parce que
Serial.println(number3);
N’affiche que 2 chiffres et va donc arrondir si besoin
Essayez avec
Serial.println(number3,6); // affichage 6 chiffres après la virgule
Et vous verrez que de temps en temps vous n’êtes pas pile sur la grille
➜ si on joue avec des float, il faut travailler toujours avec des inégalités pour tester la présence dans un intervalle de confiance
➜ le plus simple et plus rapide serais de tout migrer en entier au centième. Comme ça les maths se font en nombre entier, c’est plus rapide et precis
Je t'ai donnée la solution pour arrondir, mais un float reste un float, un chiffre imprécis sans continuité, avec une limite de chiffre après la virgule très grand.
Pour un point GPS sur une grille, la meilleur solution ne serait pas au réel avec une précision sur 2 chiffre le plus prés et non au point inférieur droit le plus proche?
Je ne suis pas sûr d'avoir tout compris de ce que tu as dit mais j'ai besoin du point inférieur droit qui me permet également de trouver les 3 autres points les plus proches du GPS et de récupérer les données(température...), il ne me reste plus qu'à faire une moyenne où les données des points les plus proches du GPS bénéficient d'un coefficient plus important que les plus éloignés.
Je ne sais pas si c'est nécessaire d'avoir autant de précision(qui est bien sûr très limitée par d'autres facteurs) mais je préfère toujours le faire.
Dommage que la machine ne le fasse pas elle même sans qu'on ait besoin de tout modifier.
Je vais le faire mais cela va me sembler un peu bizarre je pense.
Et si je travaille avec des °C par exemple, si j'ai une bibliothèque qui me renvoie la température(ou autre) avec un chiffre à virgule. Il faut donc la convertir en entier, faire un petit calcul (juste une soustraction) puis de nouveau la convertir en nombre à virgule pour l'afficher ?
Pourquoi le point le plus proches du GPS serait-il le coin inférieur droit et pas le coin supérieur gauche ou même le coin supérieur droit?
Je ne sais pas vraiment comment le dire autrement, mais un arrondis "normal" au nombre le plus proche, ne serait-il pas mieux?
A près difficile de vraiment savoir ce qui serait le plus rapide, ça dépend surtout combien du reçois de point dans ta grille par rapport au point GPS.
si par exemple tu reçois une grille de 1000 points à convertir en entier et seulement 3 points GPS, le calcule flottant sera t-il toujours plus lent?
quel est le rapport entre un calcule flottant et un calcule sur entier?
de même pour des latitudes et longitudes je ne suis pas sûre que l'on puisse vraiment dire que se soit peu précis, enfin surtout en comparaison d'arrondir à deux chiffres.
Sur un processeur 8 bits sans coprocesseur arithmétique (FPU), le calcul ou les comparaison en virgule flottante sera toujours plus lent que le calcul en entier.
Ensuite tout est relatif bien sûr, ça peut ne pas avoir d'importance si on a peu de calculs à faire, pas souvent et qu'on n'est pas à quelques micro-secondes près.
Plus le calcul est au coeur de plusieurs boucles imbriquées et que l'on doit faire cela des millers de fois par secondes alors ça va jouer.
pour la précision comme tous les nombres ne sont pas représentables. Si par exemple vous avez en coordonnées GPS 1.3999999, il sera stocké sous forme 1.4 et donc au lieu d'avoir 1.39 en arrondi vous aurez 1.40
Je suis d'accord avec @terwal cela dit, il n'y a pas besoin d'arrondir pour trouver dans quelle zone de la grille vous êtes si votre grille a un pas constant. une simple division suffit
Justement pour le coup d'un point de vue localisation, 1.39 est moins précis que 1.40
@leg2027 il faudrait que tu décris un peu plus ce que tu fais.
J'aime bien la division, car cela te permet d'avoir directement un indice dans un tableau de valeur.
Je suppose que ta grille est dans un tableau?
Je dispose de vA,vB,vC et vD je cherche à estimer vN
J'ai calculé cette formule qui marche peu importe où se situe le point, y compris s'il arrive pile sur un point de grille.
*vN=[(xN+1-yN)*vD+(xN+yN)*vC+(1-xN+yN)vB+(1-xN+1-yN)]/4 xN étant égal à=latNGPS-latAGrille et yN=lonNGPS-lonAGrille
lonAGrille et latAGrille sont justement trouvés en tronquant lonNGPS et latNGPS au centième.
Même s'il y a 1.3999999 comme coordonnée, cela sera toujours plus précis avec cette méthode qu'avec l'arrondi à 1.4 (même si en pratique cela revient au même)
J'arrondirai où je souhaiterai selon la précision de mon GPS.
Je croix comprendre ce que vous voulez dire.
Cela me semble à peu près la même chose que les calculs utilisés pour tronquer au centième en fait.
Sauf que là on peut le faire avec n'importe quel pas, même si ce n'est pas un multiple de 10 c'est ça ?
C'est bon à savoir . Merci pour cette explication.
Au fait, je ne dispose pas d'un tableau type xml ou arrays mais d'un fichier json avec des "headers" suivi d'une suite de "data". isola-json.txt (42.9 KB)
Du coup tu en fais quoi de ton JSon, comment tu va chercher les informations qui t'intéresse en fonction de ta position GPS?
Si on prend le graphique de @J-M-L, le point qui est le plus près du coup est le supérieur droit, et non le inférieur droit.
Si on prend ton graphique c'est le point D, le plus près et non le A.
C'est pour sa que je ne comprends pas pourquoi tu cherches un arrondis à l'inférieur et non au plus près?
