Looking for guidance on an OO implementation issue

[minesadorada]

I have found it's a good idea to design/develop your demo application at the same time as developing your classes.

In that way, you can be sure of encapsulation, and the most useful properties and methods to include/miss out.

Unit testing is really important in OO development.

my 2€

[engkin]

Engkin - forgot to ask: what would be the minimum requirements that the lib should cover for you to develope your "personal utility"?

I'm not sure yet, probably beside what I already have some basic trigonometric functions.

I noticed that we can use pascal version if we define use_pascal, but it does not give correct results on 32bit system. I had to change types of variables used in for loops from QWord to PtrUInt.

[MathMan]

...
I noticed that we can use pascal version if we define use_pascal, but it does not give correct results on 32bit system. I had to change types of variables used in for loops from QWord to PtrUInt.

I am baffled  I did not consider the lib to be used on 32 bit systems - and I am more than curious to understand how a change from QWord to PtrUInt did some magic correction. If it is working for you maybe I can easily adapt and provide a pure Pascal version for 32 bit too.

Can you do me a favour pls. - can you post what exactly you changed and give an example for an incorrect result with QWord and a correct result with PtrUInt. The lib has already developed a lot since the version I put online some time ago.

Kind regards,
MathMan

[engkin]

I am baffled  I did not consider the lib to be used on 32 bit systems - and I am more than curious to understand how a change from QWord to PtrUInt did some magic correction. If it is working for you maybe I can easily adapt and provide a pure Pascal version for 32 bit too.

I'm sorry, I should have explained more. On 32 bit, FPC does not allow QWord type for variables used in for loops. Your code will not compile. I had to change QWord to PtrUInt to keep your design intact on 64 bit, and to get it to compile on 32bit. So we still *need* the magic to get it to produce correct results.

Can you do me a favour pls. - can you post what exactly you changed

I also made a small change to RadixStp and RadixMax to make radix 10 suitable for 32 bit, but since QWord is supported on 32 bit - except in for loop vars - this change is not really necessary.

and give an example for an incorrect result with QWord and a correct result with PtrUInt.

The change from QWord to PtrUInt did not correct anything, it just allowed me to compile it on 32 bit. Here is an example:
converting this string
'36893488151714070528' which is equal to $20000000000000000 to number gives
$20000000100000000 instead. Most likely it is a carry error.

The lib has already developed a lot since the version I put online some time ago.

If I may ask, why did you exclude 32 bit from the pascal version? I understand that maintaining and optimizing the assembly version for 64 bit makes perfect sense, and that pascal version is not going to be geared toward speed.

[MathMan]

I am baffled  I did not consider the lib to be used on 32 bit systems - and I am more than curious to understand how a change from QWord to PtrUInt did some magic correction. If it is working for you maybe I can easily adapt and provide a pure Pascal version for 32 bit too.

I'm sorry, I should have explained more. On 32 bit, FPC does not allow QWord type for variables used in for loops. Your code will not compile. I had to change QWord to PtrUInt to keep your design intact on 64 bit, and to get it to compile on 32bit. So we still *need* the magic to get it to produce correct results.

Can you do me a favour pls. - can you post what exactly you changed

I also made a small change to RadixStp and RadixMax to make radix 10 suitable for 32 bit, but since QWord is supported on 32 bit - except in for loop vars - this change is not really necessary.

and give an example for an incorrect result with QWord and a correct result with PtrUInt.

The change from QWord to PtrUInt did not correct anything, it just allowed me to compile it on 32 bit. Here is an example:
converting this string
'36893488151714070528' which is equal to $20000000000000000 to number gives
$20000000100000000 instead. Most likely it is a carry error.

The lib has already developed a lot since the version I put online some time ago.

If I may ask, why did you exclude 32 bit from the pascal version? I understand that maintaining and optimizing the assembly version for 64 bit makes perfect sense, and that pascal version is not going to be geared toward speed.

Ok, I think I get it now. What I would have to do is define a generic counter type (tCounter), make that depending on the bitsize (QWord on 64 bit and Cardinal on 32 bit), and use tCounter in all loops. Doesn't look like too much effort ...

As for the example - '36893488151714070528' in fact is equal to $20000000100000000 while $20000000000000000 is equal to '18446744073709551616'*'2' = '36893488147419103232'. So the conversion function computes the correct value.

Re your final question. When I started this I thought "Come on now - 64 bit systems will soon be everywhere - don't bother with legacy, start fresh and focus on 64 bit!" And so it evolved ... You see FPC supports 64 bit datatypes even on 32 bit processors which is not neccessarily the case on other Pascal compilers and to really support 32 bit I would have to change a lot more in the sources than just loop control counters.

[engkin]

What I would have to do is define a generic counter type (tCounter), make that depending on the bitsize (QWord on 64 bit and Cardinal on 32 bit)

PtrUInt is what you just described.

Code: [Select]

tCounter = PtrUInt;

As for the example - '36893488151714070528' in fact is equal to $20000000100000000 while $20000000000000000 is equal to '18446744073709551616'*'2' = '36893488147419103232'. So the conversion function computes the correct value.

Huh!? You are right, the numbers above are obviously correct! Let me check.

[engkin]

It is the opposite direction. To keep this thread for its original purpose, I created a new thread here.