The various DAASE files exist because the original version of the system
was too large to contain that information in memory. The DAASE file
structure is a copy of the VMLISP file structure. The compress file
was added later because I needed to put Axiom on a tiny laptop (16k).
The idea was to keep long filenames in a compressed form.
Note also that the DAASE files are designed for random access hardware.
The first lookup is essentially a cylinder-track-sector for hard drives.
There is no point doing this on fully electronic hardware.
So the DAASE files are legacy and ought to be redesigned out of the work.
It might make sense to provide a graph structure with hash pointers
or to just use a standard database with a SQL lookup as those have been
optimized quite a bit over the years. It all depends on measuring the kind
of lookups.
Given my background I'd make the databases into a lisp data structure
which gives all kinds of access as well as dynamics addition / deletion,
etc.,
sits in memory, and can be used by all kinds of tools. It would also be
"in-line" accessible by SPAD code and Hyperdoc-replacement tools.
Languages like Python have sexpression reader libraries.
Tim
On Sunday, June 15, 2025 at 2:02:57 PM UTC-4 Waldek Hebisch wrote:
> 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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/a2a7accb-497c-4dc9-98ab-7408f0709096n%40googlegroups.com.
