1

I wanted to have a converter in C# to convert inputs like 123.456 to numbers like 0.123456 and also 0.123456 back to 123.456

The problem is when I use double.TryParse(...) to parse the input, I often ran into a floating point problem, that the numbers get rounded to 123.999999 instead of 124 for instance (just an example to show what I mean).

This can happen depending on the number that I have in the string.

How can I deal with that and convert these values correctly?

OXO
  • 391
  • 1
  • 8
  • 4
    To avoid such issues you need to use `decimal`, but still I think your explanation is not right as from what you say, you seem to be simply dividing by 1000. – Andrew Jul 27 '23 at 16:13
  • I'm finding your examples a bit confusing. Why does "123.456" get converted to 0.123456? Where did 124 come from? Could you include a couple code examples that demonstrate the problems you're trying to fix? – Jack A. Jul 27 '23 at 16:14
  • While I personally think the question is extremely unclear I still voted to close as duplicate instead - my reasoning for a sub-optimal vote is that the duplicate explains problems with floating point numbers and that should allow OXO to clarify the technical part of the question. Ideally after an [edit] the question also will include the goal author wants to achieve. Clarifying why standard fixed point approaches (`decimal` or [fixed point](https://en.wikipedia.org/wiki/Floating-point_arithmetic) numbers in general) did not work for that case. – Alexei Levenkov Jul 27 '23 at 16:52
  • I admit, that my numbers are not facing the real issue. I am working under .NET MAUI and have an Entry which should only allow floating point inputs, which is evaluated subclassed. Additionally, a user enters values like 12.345 or so, which needs be converted and stored in the way it is needed for calculations. To still present the inputs a user entered it then needs to be converted back. I used a double.TryParse(…) before diving it by 100 for storage. By using this, I can run into floating point problematic. Since evaluated during input via it ie strange to a user as he did not enter the valu – OXO Jul 27 '23 at 17:46
  • You should edit your question so it's totally clear. If you are forced to work with `float`, then there's not much you can do, it's not totally precise. You will have to perform rounding while displaying the values. – Andrew Jul 28 '23 at 18:44
  • The problem actually is that the TryParse(..) is done while entering values. During that a parse to a value that is not what you saw before (double precision) a user gets confused. Maybe it is better to let the user enter the value she wants, save this value as a string in the database and when it is used for calculations later on do the division by 100 and calculate with this. Maybe less confusing for a user than changing a value she just entered by double.TryParse(…) while entering values? – OXO Jul 28 '23 at 18:56
  • But you need to validate what the user entered. What if it's an invalid number? If you can choose, use `decimal` instead of `string`. I still don't understand at which point you have to use `float`. If it's at the end, just cast as `float` at the very end of the process. – Andrew Jul 29 '23 at 01:06
  • The calculations are done very late in the process and when a user made a selection and clicked on a Calculate-Button. Currently it is like she does her inputs, and while doing it, the number format is checked so it is not possible to enter 00.124 for instance. Then, I already did parse (which changed the inputs some times) and do divide by 100. Then a save button has to be clicked to store it in the DB. Later on a user can do selections from its saved values and do the calculations. When doing the selections I also would like to show the actual value that was entered and not a rounded value – OXO Jul 29 '23 at 04:42
  • What I don’t want is that enter a value and by double.TryParse(..) it is parsed to a number that was not entered. And the other thing is, when a value was entered and at some point presented to the user again it is a different value due to double.TryParse(..). On the other hand, there is an overhead so that each time the value is used in a calculation or presented in a dialog before the calculations, it has to be divided by 100. So you enter values like Fat, Protein and Carb values per 100g and calculations are done per 1g and have to do the divisions first. Finally less problematic? – OXO Jul 29 '23 at 05:07
  • I don't understand the problem. Why not just use `decimal`? Do `/100` whenever it's easier and less repetitive, no big deal. BTW, `00.124` is a valid number. – Andrew Jul 30 '23 at 06:46

0 Answers0