count digit afer decimal point

[Deanmon]

How can i count digit after a decimal point.
The value is supposed to be entered by user. I want to know how many values he added after decimal point so i can muliply it that much zeroes to change it in to integer.

[Repeater]

Just remove the decimal point.

#include <iostream>
#include <string>
using namespace std;

int main()
{
    string input;
    cin >> input;
    input.erase(input.find('.'), 1);
    cout << input;
}

[Deanmon]

Thanks mate. but i dont know this method. Is there not any way by math?

[Repeater]

i dont know this method

You only want methods that you already know? Surely you're asking because you don't know.

The short answer is that there is no reliable way to do it "by math" because it's almost guaranteed that whatever decimal number the user types in will NOT be stored exactly the same in a double or float.

For example, if the user types "123.5748" and you store that as a 32-bit float, the value stored will be "123.574798583984375" https://www.h-schmidt.net/FloatConverter/IEEE754.html

So, you have to work with a string input in order to count how many values the user entered after the decimal point. But if you have to work with the string, why waste your time trying to make it work "by math" when you can just remove the decimal point from the string.

[Deanmon]

they havent taught us that in class so how am i supposed to use that ?

[Repeater]

Perhaps you're expected to learn things for yourself sometimes, rather than just blindly repeat exactly what you're told and nothing more. I guarantee you that if you only ever use the C++ you see in class, you will never be any good at it, and if you only ever use programming techniques you see in class, you will be a truly awful programmer.

[jonnin]

there is always some smart* in every class that is ahead of the curve, doing things that has not been presented in the book or classroom, getting A++ or 110% on his homework because he researched the problem and found a better way to do it. Why not BE that guy? If your professor complains about you doing something using a solid approach and for taking some initiative and learning stuff outside of class, your professor is no good -- you should get praise for this.

It could be the point of the exercise is to show you that trying to do it via math is not going to work for all values. There are other ways to do it -- there is probably a way with logs(I need to think about this) and I am pretty sure that a page of code to parse the floating point format will tell you its base-2 exponent allowing you to raise it to a power of 2. But these approaches are significantly more complicated than what you were shown. I don't think schools even TEACH in depth log manipulations anymore, but you can find it online. You can do so many things with them it is mind blowing, but its left out of most schools for some unclear reason.

[Satan]

I think this topic is a bit biased so I'll add in my opinion. It's true that finding a better way SHOULD be appreciated by teachers, especially since the student has done his effort to come up with something BETTER and in this case more ACCURATE.

But guys this is an entirely new concept we're talking about. It's really easy learning about new concepts, it's harder to learn to tackle a problem with given circumstances.

The teacher did not give this assignment to you so that you could go and search something new on google and give that as your assignment, but he wants you to use what you have ALREADY LEARNT. There's no point in learning new stuff if you aren't creative enough to work with just what you have learnt.

So in my opinion, it's better you do the assignment with what you already know even if it's wrong.

Okay now to OP,

What Repeater said might be true, he has much more knowledge than I would have in like 10 years man. But from what I see that shouldn't affect what we're doing here.

You have to worry about losing precision while working with large floating point numbers and operations with them. Which is not what we are dealing with.


Over here we are dealing with small floating point numbers, hey man this isn't for practical applications it's just for helping you learn to think creatively and work on logics.

And the only operation happening over here is multiplication and division by 10.

Deanmon the logic has to do with multiplication of the floating point with 10 to get an integer (which we can do by multiplying float by either arbitrary amount of 10's powers or by calculating it accordingly) and then getting the integer equivalent of the floating point by negating the trailing zeroes and then finally comparing this number with the floating point.

^^ That is just my thought, haven't thought about how the logic would work (but there are a lot of smart people in this forum who could help you with this, like the people above me)

But we have to find the number of floating points.. let me think about it.. I want to work on this myself in fact.

Ugh maybe next week or something I have a barrage of tests to attend and I really should be studying right now ;'(

[jonnin]

its not going to work with that approach. its not about losing precision. LOOK at the example.

"123.5748" typed in should yield 1235748. Not 123574798583984375
but if you do it via base 10 math, that is what you will get, even if you do it 100% correctly.

there is no way to get the correct answer with a 'math' approach for all possible values, not even for all possible values between 1 and 2.

there are a dozen ways to do it otherwise... you can read input as 2 integers and ignore the decimal point and cook up the answer that way.

[Satan]

Can you give a programming example where a floating point is losing precision or rather losing its base identity when you're multiplying or dividing by 10? Thanks jonnin

Powers of 10*

[tpb]

Nwb wrote:

losing its base identity

?

[Satan]

Suppose 2302 should be 23030000 or 0.0002303 but it must have 2303 regardless of trailing and preceeding zeroes. Basically multiplying our dividing with 10s should be able to give you back the original number.

Sorry didn't know the word for it :p

[Ganado]

Nwb, I'm not sure if this answers your question but the issue is that information is lost once you save 0.0002303 as a double. It is saved as its closest IEEE-754 approximation, 0.000230299992836080491542816162109375.
The number "2303" does not exist in its base-10 representation.

[Peter87]

Nwb, I'm not sure I understand exactly what you mean but do you realize that a simple value such as 0.3 can't be stored exactly as a floating point value?

#include <iostream>
#include <iomanip>

int main()
{
	double value = 0.3;
	std::cout << std::setprecision(100);
	std::cout << value << '\n';
}

output:
0.299999999999999988897769753748434595763683319091796875

[Satan]

But after rounding we should get the accurate value right? Other than using setprecision, can some show an example where the input value is lost by only using multiplication and division with 10, count and cin?

[Peter87]

The biggest problem, as I see it, is how to decide how many times we should multiply by 10.

[Satan]

My point was that reaper was wrong in that this cannot be done with math.
Peter I was thinking of something like this :

Multiply input number (long double) and multiply the number until its lesser than say 10^8. (use while)

Next subtract the ceil from the number to check if any floating points are still left over. If yes then print not supported.

If not then while loop which divides number by 10 until rightmost digit is not 0. This is the integer equivalent for the float.

Now we compare this with original number

[jonnin]

yes, it will work if you correctly figure out rounding. But the trouble is that you can't store the initial value! (as a double)

what you don't seem to be getting is this.

double d;
cin >>d; //user types 0.3
//d is not 0.3 ... you have nothing to compare against to check to see if your integer and the original input are compatible because the original input is damaged from the get go!

can you multiply it by 10 to the 8th? sure.
but how do you know the user did not type 0.2999999999?
rounding it is an *assumption*. It will work for the 0.3 but not for user typed 0.2999999999 ... rounding that changes the user's input.

If approximate values are good enough, sure, you can round it and do this as you like and it will work fine. That is a perfectly acceptable approach --- in reality, even in scientific computing, it is uncommon to need more than 4 or 5 digits of precision. You need a lot of precision for some few things, but not for everything you do.

Go for it!

But, having done it this way, realize that the first solution provided is still the best. When you learn about strings and whatnot, remember what he taught you :)

[Ganado]

Nwb, sorry but I don't see how that's a reliable way to do things. I don't see how that counters what Repeater said -- once converted into a double, the information is lost.
There's no way of knowing if the user typed in "123.5748" (multiply by 10, 4 times) or typed in "123.57479858398437" (multiply by 10, 13 times). Maybe show code and I'll understand more?

There's not even any use case I can see for this sort of thing. Especially if we're talking about something like money (there are precise rounding rules for money when it comes to things like exchange rates, and money should never be stored as a floating point).

[jonnin]

you can peel off part of a float this way to feed it forward as an integer to do some sort of bucket sorting or hashing of the value or storing it as a smaller type for transmission or bulk storage. Image you had a few billion doubles of the format 123.456.. you could store those as X*1000 in a 32 bit int instead of a 64 bit float, which might have merits for someone somewhere. /shrug.