A little cheat-sheet, on how to wrap Python mpmath procedurals inside regular SageMath expressions.

The following link should not be taken, as the complete solution to anybody else’s computing task, in which my readers might want to wrap Python code for use in SageMath. In fact, I don’t even consider myself an expert in either of these subjects.

For people who do not know, “SageMath” is a combination of “Computer Algebra System” – ‘CAS’ – and ‘Numerical Toolbox’. SageMath is written using multiple languages, mainly Python. And, the ‘Maxima’ CAS back-end was written in LISP. ‘mpmath’ is a specific Python package, that allows Multi-Precision Arithmetic.

The integration of ‘mpmath’ is particularly straightforward, because Sage already uses this package. But the principles that would be used for other Python packages are similar. An interface must be established, by which Sage objects can be translated into the objects specific to the external Python packages, and back into objects that Sage can recognize again. Objects that Sage finds particularly useful, are ‘Symbolic Functions’ – that are to be manipulated algebraically – and ditto for ‘Symbolic Expressions’.

If worse comes to worst, then the data generated by the external, ‘wrapped’ code, may be converted into native Python objects such as ~Strings~. However, Sage does not recognize strings as valid Symbolic Expressions. So, one way around that could be, to call Sage’s ‘sage_eval()‘ function on the strings. (:1)




(Updated 7/28/2021, 12h15… )

Continue reading A little cheat-sheet, on how to wrap Python mpmath procedurals inside regular SageMath expressions.

Whether to Refer to PHP Extensions or to PHP Libraries

In This Earlier Posting, I wrote that the PHP5 packages I have installed, include extensions that allow the PHP Scripts to act as a MySQL Client.

I suppose that one picky question to ask might be, ‘Should those not be referred to as PHP Libraries?’ Unfortunately, the answer is not as cut-and-dry as that might sound.

The way these files work is similar to how ‘Java Native Includes’ work. It has frequently been possible to do ‘Multi-Language Programming’, in which some subroutines are programmed in C or in C++, but are made visible to the interpreted language – that being Java, Python, PHP, etc., so that they can be called from that parent context.

But AFAIK, the way JNIs are usually linked, it is that actual File belonging to the Java installation, that receives the object code, from what started out as C or C++ source code. Therefore, this File would correctly be the Library.

A regular Library would just be an .SO File in Linux, or a .DLL File under Windows, which contains this compiled code, that resulted from C or C++.

The hesitation that I see, before referring to PHP Libraries, is twofold:

  1. The Modules were not themselves written in PHP.
  2. The File in question depends on the .SO File, but does not contain the actual object code, which has been linked into that .SO File. Therefore, the actual package ‘php5-mysql‘ depends on the additional package ‘libmysqlclient18‘, but contains the files





OTOH, The package ‘libmysqlclient18‘ contains the files




What this means is that although the Files that actually belong to the PHP Package are linked as .SO Library Files, they merely act as a Wrapper for the files that do the work, and which were in the MySQL Clients Library Package, without which the PHP components could not work.

And so we do refer to these as “Bindings”, and I prefer to call them ‘Extensions’. The package manager refers to it as a “Module”.