Anyone interested in testing a new Big Integer library?

[ad1mt]

It would be helpful if you provide a link to that thread, cause I'm unable to locate it.

Here's the link:
   https://forum.lazarus.freepascal.org/index.php/topic,65453.0.html
It took me a while to formulate exactly what my questions were...  without making a fool of myself  .

[ad1mt]

Many thanks for this... I will take a look shortly.

I was unable to compile the code.
Would you be able to give me a small/minimal program that uses your unit to divide two numbers, and does nothing else. Something like this...

Code: Text  [Select][+][-]

1. program Div;
2. uses LongDivMod,LongTypes;
3. var a,b,c:tLimb;
4. begin
5. a:= tLimb(8);
6. b:= tLimb(4);
7. c:= (a div b);
8. writeln(c);
9. end.

This example program is pseudo-code, it will not compile.
I have another question... does your big integer type allow an arbitrarily large number of "limbs". From a quck glance at the LongTypes.pas code, it looks like it might be fixed at either two or four 64-bit limbs, but I'm probably mistaken.
Many thanks.

[MathMan]

Many thanks for this... I will take a look shortly.

I was unable to compile the code.

Could you please be a bit more specific. What exactly did not compile and what error message did you receive from the compiler?

I'm pretty sure that the units & programs I provided do compile.

Would you be able to give me a small/minimal program that uses your unit to divide two numbers, and does nothing else. Something like this...

Code: Text  [Select][+][-]

1. program Div;
2. uses LongDivMod,LongTypes;
3. var a,b,c:tLimb;
4. begin
5. a:= tLimb(8);
6. b:= tLimb(4);
7. c:= (a div b);
8. writeln(c);
9. end.

This example program is pseudo-code, it will not compile.
I have another question... does your big integer type allow an arbitrarily large number of "limbs". From a quck glance at the LongTypes.pas code, it looks like it might be fixed at either two or four 64-bit limbs, but I'm probably mistaken.
Many thanks.

Actually you already have that - take a look at the benchmark program 'bench.lpr' - there you can study how it is working. It handles integers of arbitrary size.

In general - an arbitrary precision integer is an array of limb and functions get activated with pointers to the arrays plus a length. W.r.t. your pseude code - you have to create two arrays with length one, store the values in there, create two additional arrays with length one to hold the resulting quotient & remainder and then call 'lDivMod' with pointers to these arrays plus size=1 for dividend & divisor.

Cheers,
MathMan

[ad1mt]

Could you please be a bit more specific. What exactly did not compile and what error message did you receive from the compiler?

When I load the projects from your zip, I get "The project has no main source file". I've had this problem before with example project/code sent by others. I've tried several times to fix the problem, without success.
I know it is probably a trivial problem, which makes it even more embarrassing that I've been unable to fix it.

[TRon]

When I load the projects from your zip, I get "The project has no main source file". I've had this problem before with example project/code sent by others. I've tried several times to fix the problem, without success.
I know it is probably a trivial problem, which makes it even more embarrassing that I've been unable to fix it.

Which exact version of Lazarus are you using ? I tried with both 2.2.6 and 3.0rc and both load the bench and divmodtest lpi project files without issues.

[ad1mt]

Which exact version of Lazarus are you using ? I tried with both 2.2.6 and 3.0rc and both load the bench and divmodtest lpi project files without issues.

I thought I was using a recent version, but my version 2.0.12 is dated Dec 2021.
Time to upgrade I think.

[Josh]

Have you tried

Project->Project Options->Miscallenaous and checking the box Maximise Compatibility of Project Files

[ad1mt]

What exactly did not compile and what error message did you receive from the compiler?
I'm pretty sure that the units & programs I provided do compile.

I've upgraded to v2.2.6 and everything works now.

[TRon]

Have you tried

Project->Project Options->Miscallenaous and checking the box Maximise Compatibility of Project Files

Although in general a good advise two remarks:
1 - as far as my knowledge goes that only influences things on the "writing" side, meaning that the person offering his/her work should set this option (preferably before publishing  ) .
2 - also afaik that only works for a small amount of backward generations. E.g. don't expect newly introduced settings in 3.0RC to be 'converted' for 1.0.12 (most of the time such older version have no idea what to do with some of the newly introduced settings and sometimes a certain change in settings (handling) makes it near impossible to keep things 100% backwards compatible).

Note the afaik's, this is not an official endorsed statement but my personal experience. I don't believe there is official documentation on the subject other than this.

[ad1mt]

I've just made version 4.31 available.
It has many improvements and bug fixes.
As usual, feedback or criticism is welcome.

[ad1mt]

Unfortunately, I cannot get big integer to float-type conversion working in the 32bit version of the compiler.
The problem seems to be inconsistent/unreliable handling of overflow exceptions.
All other functionality seems to be ok. A fix for this might come later.
FIXED - FPC generated code is broken for exception handling for Single type on 32bit compiler, unless you set {$SAFEFPUEXCEPTIONS ON}.

[ad1mt]

I've just made v4.32 available.
This has two major bug fixes that prevented some functionality working in a 32bit environment.

[ad1mt]

If you did not notice: I wrote few 'issues' to the Github.

Hi Alex,
I value all input regarding my library.
However, while I am the only developer, I regard it as my privilege to style the code in a way that makes it easy for me to work with.
Once the library is finished, I intend to donate it to the Free Pascal project. At that point, I would consider the Free Pascal project to be the owner, would be happy for anyone to restyle the code however they like.
Can I ask: have you tried/tested the library? If yes, do you have any comments regarding the functionality, reliability, usability, etc?

[ad1mt]

For anyone who might be curious about my Big Integer library, here is a small demo program that demonstrates how easy it is to use:

Code: Pascal  [Select][+][-]

1. Program hello_multi_int;
2. uses    Multi_Int;
3. type
4. Big_Int = Multi_int_XV;
5.  
6. var     N,P,R,Q :Big_Int;
7. begin
8. // literal numbers > 64bit MAXINT can be specified as strings
9.  
10. N:= '340282366920938463463374607431768211455';  // equals ((2 ** 128) - 1)
11. P:= ((Big_Int(2) ** Big_Int(128)) - 1);  // sometimes explicit type casting is necessary
12. if ((P - N) <> 0) then writeln('Fail!');
13.  
14. P:= (N ** 2);
15. R:= (P div N);
16. if (R <> N) then writeln('Fail!')
17. else writeln('R = N = ',R.ToStr);
18.  
19. sqroot(P,R,Q);
20. if (R <> N) or (Q <> 0)
21. then writeln('Fail!')
22. else writeln('Hex R = N = ',R.ToHex);
23.  
24. end.

My intention is that if you have an existing code base which uses 64 bit integers, and you make changes that require integers > 64 bits, you can use my library with minimal code changes. This is exactly what happened to me, and what prompted me to the create the library.

[PascalDragon]

FIXED - FPC generated code is broken for exception handling for Single type on 32bit compiler, unless you set {$SAFEFPUEXCEPTIONS ON}.

FPC isn't broken. This is by design due to how the x87-coprocessor behaves. Exceptions are only returned upon the next instruction involving the coprocessor. Inserting FWAIT after any instruction would result in a significant performance penalty, thus this is only done when {$SafeFPUExceptions On} is used.
Please note that this is also the case on any x86_64 target except for x86_64-win64, because they also use the x87-coprocessor. Only on x86_64-win64 the x87 coprocessor isn't used.