sprintf('%d',x) prints out exponential notation instead of decimal notation

349 vues (au cours des 30 derniers jours)
Jeffrey Wildman
Jeffrey Wildman le 26 Août 2014
Commenté : Sebastian Mader le 27 Juil 2018
I am using version '8.3.0.532 (R2014a)'. The sprintf command seems to print out exponential notation when decimal notation is requested (second and third example):
sprintf('%d',1.05*100)
sprintf('%d',1.10*100)
sprintf('%.0d',1.10*100)
ans = 105
ans = 1.100000e+02
ans = 1e+02
Is there any reason why the last two calls are not printing '110'?
  4 commentaires
Afficher 2 commentaires plus anciens
Jeffrey Wildman
Jeffrey Wildman le 26 Août 2014
Modifié(e) : Jeffrey Wildman le 26 Août 2014
Oops, typo, changed 115 to 110.
summyia qamar
summyia qamar le 16 Déc 2016
what if we want to change 10.3?what will be the format?%g is not working.

Connectez-vous pour commenter.

Connectez-vous pour répondre à cette question.

Réponse acceptée

per isakson
per isakson le 26 Août 2014
Modifié(e) : per isakson le 26 Août 2014
What you see is a consequence of how floating point arithmetic works.
See:
1.05*100 evaluates to a whole number (flint). The other two don't.
  2 commentaires
Jeffrey Wildman
Jeffrey Wildman le 26 Août 2014
Thanks for the links. I was aware of floating point representation/arithmetic, but had assumed MATLAB would perform some implicit conversion of types from float to int based on the conversion type specified in sprintf. This assumption must be incorrect.
per isakson
per isakson le 26 Août 2014
Modifié(e) : per isakson le 30 Août 2014
Somewhere down the page fprintf, Write data to text file it says:
If you specify a conversion that does not fit the data, such as
a string conversion for a numeric value, MATLAB overrides the
specified conversion, and uses %e.
To me this was "expected behavior", but I had to look it up now. One cannot read and remember everything. Thus, when in doubt make a test
>> sprintf( '%d', 1/3 )
ans =
3.333333e-01

Connectez-vous pour commenter.

Plus de réponses (2)

Andrew Reibold
Andrew Reibold le 26 Août 2014
Modifié(e) : Andrew Reibold le 26 Août 2014
Use f instead of d for floating point notation will stop the scientific I believe.
sprintf('%f',1.05*100)
sprintf('%f',1.10*100)
sprintf('%.0f',1.10*100)
ans = 105.000000
ans = 110.000000
ans = 110
Notice I can stop the decimals by using .0f like I did in the last example.
For additional reference:
  3 commentaires
Afficher 1 commentaire plus ancien
per isakson
per isakson le 26 Août 2014
"Still kinda curious" &nbsp Don't you trust my answer?
James Tursa
James Tursa le 17 Déc 2016
Modifié(e) : James Tursa le 17 Déc 2016
This is what is happening "under the hood" with the floating point numbers (neither 1.05 nor 1.10 can be represented exactly in IEEE double):
>> num2strexact(1.05)
ans =
1.0500000000000000444089209850062616169452667236328125
>> num2strexact(1.05*100)
ans =
1.05e2
>> num2strexact(1.10)
ans =
1.100000000000000088817841970012523233890533447265625
>> num2strexact(1.10*100)
ans =
1.100000000000000142108547152020037174224853515625e2
You got lucky on the 1.05*100 that it resulted in 105 exactly, but you didn't get lucky in the 1.10*100 case.

Connectez-vous pour commenter.

Sebastian Mader
Sebastian Mader le 27 Juil 2018
So why did Mathworks introduce %d and %i at all? It would be safer to use %.0f in any case.
  2 commentaires
Stephen23
Stephen23 le 27 Juil 2018
Modifié(e) : Stephen23 le 27 Juil 2018
They are not the same thing at all! For integer types, %u, %d and %i formats give the full precision, whereas what you propose does not:
>> sprintf('%.0f',intmax('uint64')) % rounded
ans =
18446744073709552000
>> sprintf('%u',intmax('uint64')) % full precision
ans =
18446744073709551615
>> sprintf('%.0f',intmax('int64')) % rounded
ans =
9223372036854775800
>> sprintf('%i',intmax('int64')) % full precision
ans =
9223372036854775807
It is obvious from the number of output digits that the '%f' format performs rounding operations using double class.
Sebastian Mader
Sebastian Mader le 27 Juil 2018
I see your Point, thanks for being very clary on this, much appreciated. I am far from the Limits, where rounding becomes an issue with '%.0f', so I can savely use this approach.
Nonetheless, I believe that the comments on "Notable Behavior of Conversions with Formatting Operators" should be moved up in the documentation and the special case of using %d with double precison numbers mentioned. It is at least to me not obvious at all, that an implicit type conversion is not performed by fprintf despite my desire to print an integer.

Connectez-vous pour commenter.

Catégories

En savoir plus sur MATLAB dans Help Center et File Exchange

Tags

Produits

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by