Fwd: Does FriCAS support units of measure (like meters, seconds, ...)

[Michael Soegtrop]

Dear FriCAS team,

I had a deeper look at the FriCAS book and must say I really like the
concepts compared to other CAS software (I am mostly using Maxima and
Mathematica).

The only thing I am missing (as physicist) are units of measure (like
meters, seconds) - does FriCAS support computing with units of measure?
If so could you please point me to the relevant documentation?

Without this I fear that FriCAS cannot be used for my applications,
which would be really sad.

Best regards,

Michael

[Waldek Hebisch]

On Thu, Oct 03, 2024 at 04:24:54PM +0200, Michael Soegtrop wrote:
> Dear FriCAS team,
>
> I had a deeper look at the FriCAS book and must say I really like the
> concepts compared to other CAS software (I am mostly using Maxima and
> Mathematica).
>
> The only thing I am missing (as physicist) are units of measure (like
> meters, seconds) - does FriCAS support computing with units of measure? If
> so could you please point me to the relevant documentation?

There is no official support. Part of the problem is what such
support should do? Many years ago, in Axiom era there was a discussion
about units:

https://wiki.fricas.org/UnitsAndDimensions

and some code:

https://wiki.fricas.org/SandBoxUnitsAndDimensions

There is different newer code by Kurt Pagani:

https://wiki.fricas.org/SandBoxPhysicalUnitSystem

--
Waldek Hebisch

[Michael Soegtrop]

Dear Waldek,

> There is no official support. Part of the problem is what such
> support should do?

Indeed supporting units properly is a rather tricky problem. E.g. when
solving differential equations in Mathematica I frequently end up with
terms like a^e/b^e or log a - log b where a and b have the same unit.
This must be converted to (a/b)^e or log (a/b) - frequently manually -
to compute properly.

Thank you for the links! I browsed the discussion and code. As FriCAS
noob I can't say much about the code, though. From a helicopter
perspective it looks like a traditional solution like in Maxima /
Mathematica, that is units and dimensions are computed at run time. I
didn't work with it, but the unit system of F# might be more suitable
for FriCAS. In F# units are described as parameterized number types.
That is unit computations and checks are done at type check time and not
at run time. This looks more appealing to my for many a reason. E.g. one
can check the correctness of units on symbolic terms and not only when
one inserts numerical values with units - a point at which things get
really messy in Maxima and Mathematica frequently. Having unit factors
(say x*kg) in symbolic terms as suggested in some of the discussions is
also not a feasible solution IMHO.

Here is a paper on the F# solution:
http://typesatwork.imm.dtu.dk/material/TaW_Paper_TypesAtWork_Kennedy.pdf

In how far one can solve the a^e/b^e or log a - log b problems this way
I cannot tell, but one could try it in F#. Also if such types would fit
well into the symbolic machinery of FriCAS I can't tell either - I am a
complete FriCAS noob and only read pieces of the FriCAS book.

It is unlikely that the F# solution works as is in FriCAS - e.g. one
somehow has to handle the issue that a definite integral is no longer a
difference of anti-derivative values if logarithms are involved, e.g. by
giving a meaning to the logarithm of a unit. But if one finds a solution
to this, it would likely be very much superior to what other CAS have.

Best regards,

Michael

[Hill Strong]

Good evening Waldek,

Trying to get access to the wiki site, get a 502 Proxy Error now.

Was able to get access much earlier today

Hill Strong

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/21b85099-654c-4df1-9770-eb5c225b254f%40michael-soegtrop.de.

[Waldek Hebisch]

On Sat, Oct 05, 2024 at 11:23:54PM +1000, Hill Strong wrote:
> Good evening Waldek,
>
> Trying to get access to the wiki site, get a 502 Proxy Error now.
>
> Was able to get access much earlier today

I do not know why, but the wiki frequently dies, I need to
restart it.

--
Waldek Hebisch

[Hill Strong]

Good afternoon Waldek,

Thanks

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZwH3pZoPIW5UKGQ0%40fricas.org.

[Hill Strong]

Now, what would be required to load units,txt from Frink into FriCAS?

On Sun, Oct 6, 2024 at 1:36 PM Waldek Hebisch <de...@fricas.org> wrote:

--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/ZwH3pZoPIW5UKGQ0%40fricas.org.

[Waldek Hebisch]

On Sun, Oct 06, 2024 at 02:50:37PM +1100, Hill Strong wrote:
> Now, what would be required to load units,txt from Frink into FriCAS?

First step would be to get units.txt. Then look what is inside.
After that one could say how much work remins to do.

--
Waldek Hebisch

[Michael Soegtrop]

Dear FriCas Developers & Users,

I wonder what the opinion of the FriCAS experts is on the question if
the F# approach (units are parts of types) or the "traditional" approach
(units are part of the value) approach looks more suitable for FriCAS.

IMHO it is conceptually better to treat units as part of the type, so
that one can check dimensionality of equations without inserting actual
values.

The question is if the symbolic mathematics engine of FriCAS could
handle number types extended with a unit.

In either case the unit system should support

- rational exponents for dimensions

- logarithms of units

Otherwise perfectly valid equations would not type check or compute. In
general it doesn't make a lot of sense to have fractional units in end
results (square roots happen) but it is quite frequent that intermediate
results have fractional units and then cancel out in the end.

The code in https://wiki.fricas.org/SandBoxPhysicalUnitSystem will only
work in rather simple cases (it supports neither of the above). The
extension to rational units should be easy, but the support for log
units might be tricky.

If one puts units in types, one needs a fairly flexible unit system to
avoid that e.g. results of an integration don't type check. If one puts
units into values things are more relaxed because one can do some
simplifications before one substitutes values with units into a term.
E.g. what I do frequently in Mathematica is to fully expand and then
ReplaceAll (/.) with

a_^e_*b_^f_ /; ! IntegerQ[e] && ! IntegerQ[f] && IntegerQ[Simplify[e +
f]] -> (a/b)^e*b^(Simplify[e + f])

Here the (a/b)^e part always ends up to have unit 1 because in final
results fractional units don't make sense (and I did expand before). The
b^(e+f) part can have arbitrary units because the exponent is known to
be an integer. I use similar simplifications for logarithms and
exponentials.

Note that in a programming language like F# fractional units and log
units are not required, because one would generally use reasonably "unit
nice" simplified forms of terms. But a CAS has to be able to handle
intermediate results and simplifications - unless one wants to delegate
this to the user in a "units in values" concept as e.g. Mathematica and
Maxima do.

Best regards,

Michael

[Waldek Hebisch]

On Sun, Oct 06, 2024 at 03:34:36PM +0200, Michael Soegtrop wrote:
> Dear FriCas Developers & Users,
>
> I wonder what the opinion of the FriCAS experts is on the question if the F#
> approach (units are parts of types) or the "traditional" approach (units are
> part of the value) approach looks more suitable for FriCAS.
>
> IMHO it is conceptually better to treat units as part of the type, so that
> one can check dimensionality of equations without inserting actual values.
>
> The question is if the symbolic mathematics engine of FriCAS could handle
> number types extended with a unit.

FriCAS types are parametrized, to you could have a unit as type
parameter. So one can make "units as part of the type" work.
However, one of fundamental FriCAS types is Ring. Once you have
units multiplication produces a new type. So your type no longer
is a Ring and you can no longer use significant part of FriCAS
library.

So "units as part of the value" look more viable, but even there
you can hit problems.

> In either case the unit system should support
>
> - rational exponents for dimensions
>
> - logarithms of units
>
> Otherwise perfectly valid equations would not type check or compute. In
> general it doesn't make a lot of sense to have fractional units in end
> results (square roots happen) but it is quite frequent that intermediate
> results have fractional units and then cancel out in the end.
>
> The code in https://wiki.fricas.org/SandBoxPhysicalUnitSystem will only work
> in rather simple cases (it supports neither of the above). The extension to
> rational units should be easy, but the support for log units might be
> tricky.

I am not sure what you mean by "log units". AFAICS fundamental property
of units system is that units form a group. You can make a group
containing say 'log(kg)' as new element. But alone it looks
useless. And naive definition of operatation leads to contradiction:
for normal units say kg adding two things dimensioned as kg again
gives you kg. But one would expect that if a is dimensioned in kg
than log(a) + log(a) should be dimensioned the same as log(a^2),
which is quite different than normal units.

> If one puts units in types, one needs a fairly flexible unit system to avoid
> that e.g. results of an integration don't type check. If one puts units into
> values things are more relaxed because one can do some simplifications
> before one substitutes values with units into a term.

Natural way of doing units in FriCAS would simply signal unit error
at runtime. By natural way I mean checking that units match in
addition/subtraction and computing new unit in other operations.
And during intermediate calculations FriCAS may transform expressions
in various ways which are likely to lead to wrong units (for example,
when perfoming operations on homogeneous polynomials FriCAS may
use non-homogeneous polynomials in intermediate steps).

AFAICS "interesting" computations are dimensionless, so natural way
is "unit erasure": extract dimensionless coefficients, do computations
on them and then restore units.

> E.g. what I do
> frequently in Mathematica is to fully expand and then ReplaceAll (/.) with
>
> a_^e_*b_^f_ /; ! IntegerQ[e] && ! IntegerQ[f] && IntegerQ[Simplify[e + f]]
> -> (a/b)^e*b^(Simplify[e + f])
>
> Here the (a/b)^e part always ends up to have unit 1 because in final results
> fractional units don't make sense (and I did expand before). The b^(e+f)
> part can have arbitrary units because the exponent is known to be an
> integer. I use similar simplifications for logarithms and exponentials.
>
> Note that in a programming language like F# fractional units and log units
> are not required, because one would generally use reasonably "unit nice"
> simplified forms of terms. But a CAS has to be able to handle intermediate
> results and simplifications - unless one wants to delegate this to the user
> in a "units in values" concept as e.g. Mathematica and Maxima do.
>
> Best regards,
>
> Michael
>

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/4027bf63-80e2-4dc8-a665-c375c619d909%40michael-soegtrop.de.

--
Waldek Hebisch