[fpc-pascal] Comparing version numbers

[Eduardo]

At 01:41 03/06/2006, you wrote:

> > Simple, just a variation of your first try. Use ASCII comparation,
> > but all parts must have the same digits, in your case, you padd the
> > 3rd part (or any part) with any letter down the ascii code of 0, for
> > example ' ' (a space)
>This was a brilliant idea as far as I can see. MUCH simpler than the debian
>way.
>And my code for it is a LOT shorter than yours ;)
>
>function CompareVersion(Version1,Version2:String):Boolean;
>Var
>    L1,L2,I : Integer;
>    V1,V2 : String;
>Begin
>  V1 := Version1;
>  V2 := Version2;
>  L1 := Length(V1);
>  L2 := Length(V1);
>  If L1 > L2 then
>       For I := L2 to L1 do
>        V2 := V2 + ' ';
>  If L2 > L1 then
>       For I := L1 to L2 do
>        V1 := V1 + ' ';
>  CompareVersion := V1 > V2;
>end;
>
>The debian version on the other hand is well over 200 lines of code 
>by itself,
>and I am not entirely sure my version is going to be stable on all testdata
>yet.

That's the c way of do the things. I have seen deterministic code in 
c that works very well, but if you compile the code with 2 different 
compilers you get different output from same input. (Determinist 
algorithms always out  the same output from the same input, by definition).

Your code can't work with these ones, 4.1.15  and 4.12.1 because you 
only pad the 3rd (15 and 1), you need to pad each part of the 
version, my pseudocode out 4.1[space].15 and 4.12.1[space]. You can 
call your function with the 4,4; again with 12,1 utnil you get a 
result.... but you need a ternary boolean, as 4,4 generates an 
invalid result state.

>With the testdata I have right now, which is a very good representation of
>INTENDED usage (and we all know how rarely that is only usage) both now seem
>to give the exact same results.
>So - I am leaving the debian version in the code, but commented out, 
>and going
>with Eduardo's unless I find a VERY good reason to go with the other later -
>because THIS one is guaranteed WAY easier to maintain, much less likely to
>puke on bad data and I cannot see a difference in results.
>
>Thanks a great deal.
>A.J.