m32lib GetPercent need a correction

[jj2007]

... and cover a wide range of input values

Indeed. Including negative ones like -1000 (which is what algos above do, except AxGetpercent)
:bg

[Antariy]

Yes, here we see drawbacks of the used testbed :bg

The testbed is transparent - anybody with basic search skills can search for "case" and find the "culprit", ChkPrecision was introduced because some results did not yield the expected results, and so I let it crash there for testing purposes. I didn't know that somebody would develop an algo that yields, as result for invoke GetPercent, -1000, 50 the number 2147483148 (and claims the result is correct...).

So stop blaming the testbed, and start explaining in which real coding situations an "unsigned" GetPercent algo is useful.

Well...

1. You always can use this algo with any (ANY) kind of numbers. If you want get percent of *negative* number - just NEG it before call, and NEG the result :P
2. Like Dave said, yes - if you copy a file with size of 3.21 GB, that's would be nice, if routine says: "Copied -808.96 MB" :P
3. With screen coordinates, as Hutch said, you is not needed in FPUs precisions and rounding, you can use short, fast integer i386 SX capable code :P

Stop blaming integer code due its "unsignedness". You can use unsigned algo with any kind of data, because it treat all bits as data bits. But, FPU code working with DWORD cannot work with unsigned numbers, because it treat only 31 bits as data. So, unsigned code have no limitations, signed - is.



Alex

[Antariy]

... and cover a wide range of input values

Indeed. Including negative ones like -1000 (which is what algos above do, except AxGetpercent)
:bg

Some algos produce wrong results. That's negative results, though.

[Antariy]

So stop blaming the testbed, and start explaining in which real coding situations an "unsigned" GetPercent algo is useful.

First. I said about that Steve was commented SSE2 code - that's the point of testbed "blaming" - old testbed is not skip not supported algos.
Second. You can use unsigned algo with signed numbers. It would cost ~1-2 clocks more, but it is more flexible than signed algo - which not work with unsigned numbers.
Third. This algo tweak is by 2 clocks faster (for me):

Code Select Expand


AxGetPercentInt proc source:DWORD, percent:DWORD

mov edx,[esp+8]
mov eax,[esp+4]
cmp edx,99
ja @F
imul edx,28F5C29h

mul edx
mov eax,edx
shr edx,32-2
sub eax,edx
@@:
ret 8

AxGetPercentInt endp


16 bytes of code is taken by loading and checking and exiting. As macro, this code would be 15 bytes long, some cycles long.

It *works* with negative numbers. Just 2 clocks and 4 bytes more as favour. And I claim that 50% of -1000 = 2147483148 is correct. Since -1000 is FFFFFC18h (4294966296).



Alex

[jj2007]

Ok, so we'll ask Hutch to put your fast unsigned AxGetPercent into Masm32.
Perhaps the documentatiosn should then contain a little example:

In case you have to translate the y coordinate of a sinus function into screen coordinates:
  call MySinus   ; get some value for the Y axis
  mov edx, ScreenFactorY   ; scale factor
  test eax, eax
  .if Sign?
     neg eax
     invoke AxGetPercent, eax, edx
     neg eax
  .else
     invoke AxGetPercent, eax, edx
  .endif

That is easy and elegant, and avoids starting a flame war here, right?

[Antariy]

That is easy and elegant, and avoids starting a flame war here, right?

Where you see flame war? There is not Soap-Box :bg

Just you did not understand what I want to say with "bad old testbed". I want to say that old testbed is not skip unsupported algos from test, and Steve (FORTRANS) was forced to comment SSE2 code.
All next - is answer about real coding situations.

Nothing flame. Just funny that such small piece of code lead to such discussion :bg
Jochen, it would be interesting if you will post timings for the new tweak, because your clocks is always very different.



Alex

[oex]

Just funny that such small piece of code lead to such discussion :bg

Small is big on the MASM32 forum :lol