Numerics for Delphi & FPC

I “officially” released first beta version of my multiple-precision integer arithmetic implementation – Numerics050. The project taken more time than I expected but now the design (I hope) become stable.

All that is needed to use BigCardinal and BigInteger types with Delphi or Lazarus/FPC is a single pascal unit Numerics.pas and a single dll (numerics32.dll for 32-bit Windows and numerics64.dll for 64-bit Windows). Both dll are built by FPC 2.6.2 and contain pure Pascal code without assembler optimization.

The archive also contains console application PiBench (for Delphi and Lazarus) which demonstrates how to use BigCardinal and BigInteger types (not much different from plain old Cardinal and Integer types).

The software contained in the archive (compiled dll’s numerics32.dll and numerics64.dll, dll wrapper unit Numerics.pas and demo benchmark application PiBench) is free and released under MIT license.


20 thoughts on “Numerics for Delphi & FPC

  1. nice, thanks, and word, why dlls?
    i think, its no warp tachyon space since, so you can release it in the wild without big danger, and wouldn’t have an alien invasion as consequence, i would bet.
    Maybe for Jedi Project`?

    • Dll source code is open and can be and used for educational purposes. I don’t hide it but I am not free licencing it, because I am currently developing the project as a language-agnostic library. I am planning to port the dll to C++ and maybe other languages.
      I recommend to use dll not only because of the licensing terms but because the dll implementation is clear and friendly to the end user while the repository code is for internal use only. The repository code has many options introduces for testing/debugging that are not intended to be used by the end user.

      • IMHO it reduces a lot the interest of your library.

        There are similar libraries for years, very tuned and polished, like the GNU Multiple Precision Arithmetic Library (GMP).

        The point of your code is to be released as pascal, and included in the main executable.

        Having the source open would increase a lot the reliability of your code, and allow others to fork the project when you are not able any more to work on it.

    • I will include C++ import hpp file in the next release. The dll is language agnostic and can be used with any language that can import Delphi-compatible interface. I know little about specific Borland C++ compiler, it will be general C++ import file.

  2. Hmm… If you’re going to rely on an external dll, then what is the advantage of your library vs using the gmp library? (which is not just highly optimized but also has been battle-tested)

    • I don’t think gmp code is really “battle-tested”. I’ve never seen unit tests for gmp. My own DUnit test project is currently about 10 times bigger than all numerics sources, and test coverage is far from being complete; the reason why I still avoid any low-level optimizations.

      • The GMP Test Suite is in the “tests” folder of the gmp repository, also GMP has been quite widely used on a vast array of hardware for quite a few years already.

  3. Lots of people seem surprised at a DLL! What about a linkable object file? That way distributing EXEs won’t need accompanying files.

    I’m actually quite interested why you’ve chosen a DLL: is it for performance reasons? Is the FPC compiler a better optimising compiler for Pascal than the Delphi one?

    • Why not DLL?

      I have chosen DLL because I wanted to write a language-agnostic library, Delphi/Pascal is an implementation language. It uses code I started to write many years ago, the current project adds interface-based design without performance compromises, “interfaces without objects” as I described in the blog before; it is ideally implemented in DLL, practically without performance loss compared with exe (only very small interface method’s call penalty, even just vtable method’s call penalty because my “handmade” interface does not use stub code).

      Sorry, I am not paid for the work. I am writing code at my leisure and I’ve not enough time to do even what I myself want to do.

      As for Delphi/FPC compiler performance – no I didn’t make any benchmarks, I think the difference will be negligible. The main reason to use FPC is I have no 64-bit Delphi. I left my last Delphi job in 32-bit XE times.

      • Makes sense! I don’t mind if it’s a DLL or not – just commenting out of interest, not to complain about one or the other :p

        If you do find any FPC/Delphi performance differences, I would be interested in reading about them. It’s something I plan to investigate in the future when I have enough time…

    • I don’t know these tools and how to port Numerics dll to them. I guess extending the dll to COM server will automatically make it available to many dev tools. I’m not sure is it a good idea or not.

      • @A. Bouchez – No, numerics types (BigInteger, BigCardinal) are just interface references internally. All values reside in DLL. COM server adds no performance penalty, except that 4 functions currently exported from DLL will be implemented via COM factory. And sure I will not drop this export even if I will add COM server functionality so that DLL can always be used as “light” without need to be registered as COM server.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s