Re: ezunits fundamental_units quite slow

On Sat, May 16, 2026 at 1:35 AM Michael Soegtrop via Maxima-discuss
<[email protected]> wrote:

> 100ms per call on a reasonable CPU. This are several 100 million
> instructions to convert N to kg*m/s^2 - which is weird.

Yeah, one of the drawbacks of the existing ezunits is that some
operations are very slow. I have focused on getting stuff to work
correctly, but getting it to work more efficiently is also a
reasonable goal.

I've tried some operations, derived from examples posted recently by
Mateusz Mroz, which taken several seconds. However, I wonder if there
is some interference from Maxima's stuff around operations on
apparently-complex expressions (rectform, cabs, imagpart, realpart). I
will try to sort out what's going on with the slowest examples.

I'm pretty happy with ezunits as a whole at this point, and I feel
like some substantial speed-ups might be pretty easy to implement, so
I will try to take a look at that in the near future. I suspect a lot
of the slow operations have to do with processing the same expressions
over and over and over.

> Using fundamental_units_cached[u]:=fundamental_units(u)$ instead gets
> one project down from 26s to 20s, even though I use fundamental_units
> only on input parameters (otherwise terms get too large because ezunits
> does not add compatible but not identical units).

You may be interested to hear I have pushed commit 6da388 which
implements a new function, all_fundamental_units, which converts all
explicit dimensional expressions (i.e., stuff like a ` b) to
fundamental units. This is a function which can be applied explicitly;
it isn't applied automatically, since in a lot of cases one would want
to work with non-fundamental units.

Thanks for your comments on this stuff. The opinions of well-informed
users are very valuable to the developers.

best,

Robert


_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss