On Sun, Jun 15, 2025 at 06:44:18PM +0200, Grégory Vanuxem wrote:
> I have deleted my mails, sorry. But something like:
>
> 7) -> jlDocumentation mod <TAB> <TAB>
> modTree modifyPointData modularFactor
> modularLambda moduleSum
> mod_exp modpeval modularGcdPrimitive
> modular_compose moduloP
> modifyPoint modpreduction modularInvariantJ module
> modulus
>
> (7) -> jlDocumentation moduleSum
>
> moduleSum(m1, m2) returns the sum of two modules in the framed
> algebra F. Each module mi is represented as fol
> lows: F is a framed algebra with R-module basis w1, w2, ..., wn and
> mi is a record [basis, basisDen, basisInv]
> . If basis is the matrix (aij, i = 1..n, j = 1..n), then a basis v1,
> ..., vn for mi is given by vi = (1/basisD
> en) * sum(aij * wj, j = 1..n), i.e. the ith row of 'basis' contains
> the coordinates of the ith basis vector. S
> imilarly, the ith row of the matrix basisInv contains the
> coordinates of wi with respect to the basis v1, ...,
> vn: if basisInv is the matrix (bij, i = 1..n, j = 1..n), then wi =
> sum(bij * vj, j = 1..n). From: IntegralBas
> isTools
>
>
>
> Type: Void
> (7) -> jlDocumentation mod <TAB><TAB>
> modTree modifyPointData modularFactor
> modularLambda moduleSum
> mod_exp modpeval modularGcdPrimitive
> modular_compose moduloP
> modifyPoint modpreduction modularInvariantJ module
> modulus
> (7) -> jlDocumentation modpreduction
>
>
> modpreduction(r, p) reduces a rational function r modulo prime p.
> From: PolynomialEvaluationUtilities
>
>
> modpreduction(p, q) reduces all coefficients of p modulo q. From:
> ModularEvaluationCategory
>
>
> modpreduction(pol, p) reduces polynomial pol modulo prime p. From:
> PolynomialEvaluationUtilities
>
>
>
> Type: Void
>
> That uses a regular expressions system, sorry, strings are very bad
> handled in panAxiom. But just that's would be very handy.
ATM FriCAS does not support regular expressions. But, AFAICS main
functionality of the above can be done like:
)boot grepConstruct("mod*", "o", [])
This returns documentation lines from libdb.text or comdb.text.
Currently 'grepConstruct' calls external 'grep', that is one of
things that I would like to change. Information in libdb.text
and comdb.text can be generated from other sources, and it is
not clear to me if we need libdb.text and comdb.text in longer
term.
Concerning regular expressions, they are sometimes handy. OTOH
using regular expression search pattern above would be "mod.*"
which is more complicated than wildcards that we use now. So
regular expressions may be an extra (optional) interface, but
probaly not the main one.
There is trouble that thare are several syntaxes for regular
expressions and actually several different things called
"regular expressions". Namely, classic regular expressions
are equvalent to finite automata. There are restricted
classes of regular expressions where equvalent automaton is
easier to build. OTOH there are extentions, for example
Perl regular expression can do more than finite automata,
but sometimes execution time is enormous. But implementing
something is not a big trouble, simply other things
looked more useful.
--
Waldek Hebisch
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/aE8KzvJvjGugzODY%40fricas.org.
