koffice/krita/image

[Matthew Woehlke]

Matthew Woehlke wrote:
> On 2009-11-04 05:18, Cyrille Berger wrote:
>> SVN commit 1044629 by berger:
>>
>> revert to 936510 (the reason is that after 944988, the algorithm 
>> return either a very small value or UINT64_MAX)
>>
>> It might be worth, at some point to backport to branch 2.1
> 
> Um... guys? r93651 doesn't seem to be any better. Also what I'm seeing 
> out of krita isn't remotely like what I got from my test application.

Huh, now I am not seeing that. Odd. But still...

> I'm going to compare notes here... the r944988 version should have been 
> the same as what's in my test app.
> 
> ...and I'm going to check in my test app (to krita/image/tests).

Eureka!

(...But still) there is nothing wrong with the algorithm in r944988. 
There is, however, a small error in the code that has a... very, very 
bad effect.

Here is mine version of part():
     inline quint64 part(quint64 n1, quint64 n2, int p)
     {
         int b = p * 8;
         int i = (n1 >> b) & 0xFF;
         int j = (n2 >> b) & 0xFF;
         return quint64(salt[i][j]) << b;
     }

...and here is what got committed:
     inline quint64 part(quint64 n1, quint64 n2, int p)
     {
         int b = p * 8;
         int i = (n1 >> b) & 0xFF;
         int j = (n2 >> b) & 0xFF;
         return salt[i][j] << b;
     }

(Granted, mea culpa, though I'm also a bit frightened no one noticed 
until now. Well the test app is in koffice's svn now, so hopefully that 
will keep this sort of thing from happening again.)

Please don't backport the reversion; there is no need, the old code 
(that is now in trunk again) is messy, and the old algorithm is slightly 
worse.

If there are no objections within 48 hours, I am going to revert the 
revert, and then check in the fix for the above bug. (Of course, I'll do 
the work sooner if I hear an affirmative.)

-- 
Matthew
ENOWIT: .sig file for this machine not set up yet