Hi, I'm stuck calculating percentages. What is the best way to do it? I think using FPU instructions is much better than CPU.



if I pass first argument less than percentage, it's always zero that's why I need best way to calculate it, thanks!

Multiply first, then divide.

Additionally you can add a rounding stage if wanted/needed.

damn you're right.. thank you!

Win32 has an API called MulDiv() -- very handy for this. It does the rounding too. But for percentage points, like 27.093% - you need FPU.

You can still use integers here also. Multiply by 100000 instead of 100 and print the decimal point in the proper position for display.

Yes, it is possible, but FPU is so much more fun!
Integers are boring!

Wow, didn't knew about that API

To call OS API for operation that needs 2 instructions is a serious step towards hell.

It does rounding, so you'll need more instructions than two and maybe a comparison.

Well, 7 actually (14 bytes).
Still not enough to use API call.

If it's a percentage of some task in progress to completion, the convention is to round down anyway (it's frustrating to see "100% done" when the task is not really done)

So, for how many seconds you see 100% done?
Like 2 secs? Or less?

In my opinion - this is a task for a progress bar control.
It supposed to have a value identifying the FULL process and
show 100% only if that value is reached.

Example: I need to copy 2,689,373,667 bytes (few files I selected)
When process goes - the copying thread sends messages to a control with a value how many bytes are copied as of now.

1. The control calculates percentage the usual way

2. If percentage is 100 (this may happen when 2,689,373,000 are copied) then control re-verifies that 100 using another way - comparing to a final value and if not same - shows 99%.

Well, in your example and rounding arithmetically, 100% will be displayer while 13,446,868 bytes remains to be processed. How long this 100% will stay on the display depends on the work speed. In some cases it can be really long, especially if the transfer speed is not constant.
So, Goplat is right here - on progress calculations "trunc" type rounding should be used.

JohnFound: did you miss #2? (that sounds funny... Mike Myers kind of funny)
100% will not be displayed until value is reached maximum.
So, for last 13,446,867 bytes it will show 99%.

AsmGuru62, I didn't miss 2. but it sounds really weird:

1. Calculate the percentage using incorrect for this context, more complex and slower algorithm.
2. Use some dirty hack (and more code) to circumvent the problems of p.1

Isn't it cleaner simply to round the percentage down???

yes - it is simpler, but then when it show 87% -- it may be actually 87.9999 - which is 88%.

AsmGuru: your proposed scheme would display anything in the (98.5%,100%) range as 99%, which means 99% is displayed for 1.5x longer than other percentages. That's inconsistent, and also potentially annoying - progress appears to have gotten "stuck" at 99%.

If you just round down, then each percentage from 0% to 99% is displayed for the same proportion of progress. So it never gets "stuck" at any percentage as long as the progress measurement is accurate.

Programs can be annoying, but must function properly.
In this case my code will function properly in 98 cases out of 100.
Also, annoying is relative term - some users may not notice the inconsistency.

AsmGuru62, if this 0.5% is important for you, you simply have to use one more digit and display 0.1% units (using the same "wrong" technique with rounding down). This way you will have small, compact and fast code. And no hacks at all.

I think it'd be better to let the code/thread enable the "Continue / Finish" button after actually finishing the job and not after the percentage hits 100. Because like AsmGuru pointed out, you may have 100% when actually it's 99.999%. If the thread terminated, some files would not be copied. Then things like file corruption would come up.