On Wed, Sep 24, 2025 at 04:27:50AM +0200, Grégory Vanuxem wrote:
> Hello Waldek, *,
>
> Sorry for the late mail, summer, etc.
>
> Le lun. 4 août 2025 à 19:59, Waldek Hebisch <[email protected]> a écrit :
>
> [snip]
>
> > Currently the only user of comdb.text and libdb.tex is
> > IndexCard and related database in 'alql.spad'. I am
> > not sure what to do with this. In principle we could
> > create strings on the fly form other info, but that
> > means keeping code which is not needed for other purpose.
> > We could modify IndexCard to internally use representaion
> > like used for searches. But exposing S-expression in
> > user interface is not exactly nice, an having convertion
> > to strings means keeping extra code. We could entirely
> > remove IndexCard. I am not sure if anybody uses it,
> > but it is mentioned in FriCAS book, so removal of
> > IndexCard would mean removing or rewritning corresponding
> > part.
>
> I am using IndexCard behind the scene of my code. My code is basically, a
> Spad adaptation from a previous mail of you:
>
> jlDocumentation : Symbol -> Void
> ++ jlDocumentation(op) shows the documentation of the
> ++ Julia operation op. Trivial implementation.
>
> jlDocumentation(op) ==
> ops := getDatabase("o")$OperationsQuery
> req := elt(ops,equation('name, string op)$QueryEquation)
> -- See alql.spad
> docs : DataList(String) := elt(req,'doc)
> origs : DataList(String) := elt(req,'origin)
> types : DataList(String) := elt(req, 'type)
>
> The rest is a grep clean code of the result. But frankly, removing
> IndexCard is not a problem for me as far as it is possible to retrieve in
> some manner the ++ documentation strings, the origins and the types
> involved. Maybe this can be kept.
Well, this is important part of my work. I have domain which I currently
call BrowserInformation which allows to do searches. For operations
it has types like:
Sig_doc ==> Record(signature : SE, condition : SE, origin : SE,
documentation : String)
Op_rec ==> Record(name : SY, sdl : List(Sig_doc))
So when you get Op_rec is represents a list of operations with common
name and for each operation Sig_doc gives you relevant info:
signature (return type first, followed by types of arguments),
condition, origin and the docstring.
Constructors are normally represented by their name, there are
functions like:
constructor_documentation : SY -> String
constructor_form : SY -> SE
constructor_kind : SY -> SY
but most information is accessed via calls to boot like:
(1) -> getConstructorSignature('Polynomial)$Lisp
(1)
(
(Join (PolynomialCategory #1 (IndexedExponents (Symbol)) (Symbol))
(CATEGORY domain
(IF (has #1 (Algebra (Fraction (Integer))))
(SIGNATURE integrate (% % (Symbol))) noBranch)
(IF (has #1 (Canonical)) (ATTRIBUTE (Canonical)) noBranch))
)
(Ring))
Type: SExpression
That probably should be improved.
> I wonder where you are at your stage.
Replacement code works well for me. Interfaces should be improved
(like for constructors as noted above). I plan to run comparison
with Ralf's API code, that probably will lead to some changes.
Currently I made a little pause. I need to restructure the code and
it is better to do this when code is not so frash in my mind.
> Example (awful, but panAxiom/Mathematica kernels vs numerical softwares use
> different parameter order):
>
> (1) -> jlDocumentation atan
> atan(x) represents the Fortran intrinsic function ATAN
> Signature:
> (%)->%
> From:
> FortranExpression
<snip rest>
I see, good. AFAICS BrowserInformation has available at Spad level all
info needed for this:
(2) -> search_operations("atan")$BRINFO
(2)
[
[name = atan,
sdl
=
[
[signature = ((Stream Coef) (Stream Coef)), condition = T,
origin = (StreamTranscendentalFunctions Coef),
documentation
=
"\spad{atan(st)} computes arctangent of a power series \spad{st}.
"
]
,
[signature = ((Stream Coef) (Stream Coef)), condition = T,
origin = (StreamTranscendentalFunctionsNonCommutative Coef),
documentation
=
"\spad{atan(st)} computes arctangent of a power series \spad{st}.
"
]
,
[signature = (% %), condition = T,
origin = (ArcTrigonometricFunctionCategory),
documentation
=
"\spad{atan(x)} returns the arc-tangent of \spad{x}. When evaluat
ed into some subset of the complex numbers, one branch cut for at
an lies along the positive imaginary axis above \%\spad{i} (exclu
sive), continuous with the left half plane, the other along the n
egative imaginary axis below -\%\spad{i} (exclusive) continuous w
ith the right half plane. The domain does not contain \%\spad{i}
and -\%\spad{i}."
]
,
[signature = (% %), condition = T,
origin = (FortranExpression basicSymbols subscriptedSymbols R),
documentation
=
"\spad{atan(x)} represents the Fortran intrinsic function ATAN"
]
,
[signature = (% % %), condition = T, origin = (DoubleFloat),
documentation
=
"\spad{atan(x, y)} computes the arc tangent from \spad{x} with ph
ase \spad{y}."
]
,
[signature = (% % %), condition = T, origin = (Float),
documentation
=
"\spad{atan(x, y)} computes the arc tangent from \spad{x} with ph
ase \spad{y}."
]
,
[signature = (F F), condition = T,
origin = (ElementaryFunction R F),
documentation
=
"\spad{atan(x)} applies the inverse tangent operator to \spad{x}"
]
,
[signature = (ULS ULS), condition = T,
origin = (ElementaryFunctionsUnivariateLaurentSeries Coef UTS ULS),
documentation
=
"\spad{atan(z)} returns the arc-tangent of Laurent series \spad{z
}."
]
,
[signature = (UPXS UPXS), condition = T,
origin
=
(ElementaryFunctionsUnivariatePuiseuxSeries Coef ULS UPXS EFULS)
,
documentation
=
"\spad{atan(z)} returns the arc-tangent of a Puiseux series \spad
{z}."
]
]
]
]
Type: Union(List(Record(name: Symbol,sdl: List(Record(signature:
SExpression,condition: SExpression,origin: SExpression,documentation:
String)))),...)
--
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/aNUo5zXSaXJgaOh-%40fricas.org.
