Replacing HyperDoc
61 views
Skip to first unread message
Waldek Hebisch
Jun 11, 2025, 11:25:30 AMJun 11
to fricas...@googlegroups.com
I am looking at replacing HyperDoc code in Boot by Spad code.
You can ask why bother? Do not Ralf API code cover all? Well,
HyperDoc provides _much_ more functionality. Namely,
HyperDoc provides several views, with possibility of filtering.
Basic view, that is constructors allows selecting categories,
domains or packages (or all). One gets list of operations
in one of several forms:
- names
- signatures
- descriptions
- parameters
- conditions
- origins
- implementations
One can look at exports, ancestors, etc.
Having API on the web is very good, but trying API it I must say
that for me it is much less usable than current HyperDoc.
Simply current API lacks many features. Any single feature
of HyperDoc may look not very important, but there are several
features and together they make a difference. So, we should
look at adding new features, not at removing them.
Technically, HyperDoc functionality requires code to compute
relevant info (signature lists, constructor lists) and presentation
code. Of course presentation code must take into accout medium.
So we need different presentation code for Html (API and potential
use via browser), current HyperDoc and text (system commands).
But most complicated part of work is computation of relevant
information. Currently system commands reuse part of HyperDoc
code but do part of work in their own way. HyperDoc computes
info in several different ways, it is not clear to me if all
this variation is needed. API has its own way to compute
constructor info. api2.spad that I did reuses computation
of info from API, but has different presentation layer.
As I wrote I have part of HyperDoc code in Spad. HyperDoc
page has the following representation:
Rep := Record(name : Symbol, domain_conditions : LSE,
variable_alist : ALS, pattern_vars : List(PSR),
radio_buttons : ALS, input_areas : ALS,
property_list : ALS, page_description : LSE,
work_area : List(String))
where ALS is List(Record(key : Symbol, entry : SExpression)),\
LSE is just list of S-expressions and PSR is list of
Record(var : Symbol, pvar : Symbol).
This representation actually is representation used by Boot code,
so that Spad code can cooperate reasonably well with Boot code.
Each HyperDoc page has an associated symbol, and content of the
page is stored in value slot of the symbol. When C code sends
request to FRICASsys, this request is in form of S-expression
that is evaluated by FRICASsys. One of arguments is name of
symbol associated to the page, so evaluation gets value of
the symbol and in this way HyperDoc functions know which page
to handle. The record above is in a way unbalenced, general
info is stored in property list and page description, while
other fields have more special use. But this way, that is
symbol per page and page data in a record is reasonable
(alternatively, we can store pages in a hash table, currently
use of symbols avoids use of hash table).
Currently page description is a mixture of higher level symbolic
data (which in principle could be presented in any sufficiently
expressive format) and literal HyperDoc data. Of course literal
data means that just now this is good only for HyperDoc.
My code handles just HyperDoc page data and communiation to C
code. Next stage is to generate content of pages, in particular
to generate needed info. I would like to reuse Ralf code for
this, but I am not sure if this will be possible: Ralf uses
data structures (in particular XHashTable) which are problematic
to access from Boot. I would like to do things in incremental
way, so just now I need data structures that allow easy cooperation
with Boot code.
Extra remarks: my goal is to allow dynamic interface either using
current C code or a web browser (depending on user choice).
Command line interface can not support hyperlinks, but I think
that most info should be also available via command line.
At logical level most HyperDoc constructs can be
represented in Html. HyperDoc uses just a handful of rendering
constructs, AFAICS this is small subset of what Html can do.
HyperDoc has allows control if new page replaces existing one,
or if it is open in a new window. I am not sure if this can
be represented in pure Html, but certainly can be done using
some extra Javascript. C side of HyperDoc sends explicit commands
to destroy pages, we can not expect web browser to do this,
but I do not think this is a big problem.
--
Waldek Hebisch
You can ask why bother? Do not Ralf API code cover all? Well,
HyperDoc provides _much_ more functionality. Namely,
HyperDoc provides several views, with possibility of filtering.
Basic view, that is constructors allows selecting categories,
domains or packages (or all). One gets list of operations
in one of several forms:
- names
- signatures
- descriptions
- parameters
- conditions
- origins
- implementations
One can look at exports, ancestors, etc.
Having API on the web is very good, but trying API it I must say
that for me it is much less usable than current HyperDoc.
Simply current API lacks many features. Any single feature
of HyperDoc may look not very important, but there are several
features and together they make a difference. So, we should
look at adding new features, not at removing them.
Technically, HyperDoc functionality requires code to compute
relevant info (signature lists, constructor lists) and presentation
code. Of course presentation code must take into accout medium.
So we need different presentation code for Html (API and potential
use via browser), current HyperDoc and text (system commands).
But most complicated part of work is computation of relevant
information. Currently system commands reuse part of HyperDoc
code but do part of work in their own way. HyperDoc computes
info in several different ways, it is not clear to me if all
this variation is needed. API has its own way to compute
constructor info. api2.spad that I did reuses computation
of info from API, but has different presentation layer.
As I wrote I have part of HyperDoc code in Spad. HyperDoc
page has the following representation:
Rep := Record(name : Symbol, domain_conditions : LSE,
variable_alist : ALS, pattern_vars : List(PSR),
radio_buttons : ALS, input_areas : ALS,
property_list : ALS, page_description : LSE,
work_area : List(String))
where ALS is List(Record(key : Symbol, entry : SExpression)),\
LSE is just list of S-expressions and PSR is list of
Record(var : Symbol, pvar : Symbol).
This representation actually is representation used by Boot code,
so that Spad code can cooperate reasonably well with Boot code.
Each HyperDoc page has an associated symbol, and content of the
page is stored in value slot of the symbol. When C code sends
request to FRICASsys, this request is in form of S-expression
that is evaluated by FRICASsys. One of arguments is name of
symbol associated to the page, so evaluation gets value of
the symbol and in this way HyperDoc functions know which page
to handle. The record above is in a way unbalenced, general
info is stored in property list and page description, while
other fields have more special use. But this way, that is
symbol per page and page data in a record is reasonable
(alternatively, we can store pages in a hash table, currently
use of symbols avoids use of hash table).
Currently page description is a mixture of higher level symbolic
data (which in principle could be presented in any sufficiently
expressive format) and literal HyperDoc data. Of course literal
data means that just now this is good only for HyperDoc.
My code handles just HyperDoc page data and communiation to C
code. Next stage is to generate content of pages, in particular
to generate needed info. I would like to reuse Ralf code for
this, but I am not sure if this will be possible: Ralf uses
data structures (in particular XHashTable) which are problematic
to access from Boot. I would like to do things in incremental
way, so just now I need data structures that allow easy cooperation
with Boot code.
Extra remarks: my goal is to allow dynamic interface either using
current C code or a web browser (depending on user choice).
Command line interface can not support hyperlinks, but I think
that most info should be also available via command line.
At logical level most HyperDoc constructs can be
represented in Html. HyperDoc uses just a handful of rendering
constructs, AFAICS this is small subset of what Html can do.
HyperDoc has allows control if new page replaces existing one,
or if it is open in a new window. I am not sure if this can
be represented in pure Html, but certainly can be done using
some extra Javascript. C side of HyperDoc sends explicit commands
to destroy pages, we can not expect web browser to do this,
but I do not think this is a big problem.
--
Waldek Hebisch
Ralf Hemmecke
Jun 11, 2025, 2:59:23 PMJun 11
to fricas...@googlegroups.com
Hi Waldek,
as you know, I would like to let HyperDoc die.
But, maybe that sound too extreme for what I actually mean.
And I agree to some extend to your plan for a new hyperdoc.
Let me explain my wishes.
FriCAS should have an interface (in LISP or SPAD) that let's
SPAD or external programs get information about
categories/domains/packages/documentation.
From such an interface it should be easy to generate any output format
be it html, rst or pdf.
I think this can be started without changing any code for hyperdoc.
Such an interface should already contain code to compute a datastructure
representing the data for a page (not actually rendered in any format),
in particular, conditional exports should be computed and the
datastructure should have enough information to produce links to other data.
Yes, that is good for a getting a "static" view of a constructor similar
to what is presented at fricas.io/api, but computable on-the-fly.
You also want such a view in a "dynamic" form, i.e. (similar to what
current hyperdoc provides) getting information about
- usage of domains
- fuction implementation (in which package/domain)
- etc.
Shouldn't it be possible to create an API that let's query such
information by just sending strings to specify the arguments?
Why would that need Boot code if there is a function that translates the
string "Polynomial Integer" into the respective domain and uses that in
querying the various places where the wanted information is stored in
FriCAS?
Whether you then program in interface to present such information, is
another business. I wouldn't do that but rather rely on ordinary
webbrowsers to display such information. One can probably extent jfricas
to start queries and have examples executed in a notebook interface.
Yes, I like to be able to get more information out of FriCAS than just a
static API page (although I think that having them static on the web is
still a good idea). What I am not in favour of is the current HyperDoc
window. That looks old and not very attractive. That should die. Not the
information it shows, of course.
At the same time, I would like to put the HyperTeX format to sleep.
This format was interesting 30 years ago, but now there are better
formats like rst of markdown or ... Why should we keep our specific
HyperTeX-Format that nobody outside FriCAS cares about?
I do not know whether my code is good to be adapted, because initially,
I only had the presentation into an .rst page in my mind. I think one
should carefully separate code that "provides" information from code
that translates that into a certain format.
Can we create a new branch and work (as a first step) at an interface
that provides all the necessary information in form of SExpression?
> As I wrote I have part of HyperDoc code in Spad. HyperDoc
> page has the following representation:
>
> Rep := Record(name : Symbol, domain_conditions : LSE,
> variable_alist : ALS, pattern_vars : List(PSR),
> radio_buttons : ALS, input_areas : ALS,
> property_list : ALS, page_description : LSE,
> work_area : List(String))
That is seemingly taylored for a hyperdoc page. Why should one have
radio_buttons in an information record? I would rather have several data
structures like
FUN ==> Record(
name: Symbol,
source: SEX,
target: SEX,
doc: String,
condition: SEX)
CAT ==> Record(
name: Symbol,
args: List SEX,
cats: List Record(cat: CAT, condition: SEX)
funs: List FUN)
etc. (Don't take that too serious. It's just a draft.)
Anyhow, we should come up with a good datastructure that provide
easy access to the information.
If you want a datastructure that is just representing the current
hyperdoc structure, I am not interested. That is too much presentation
oriented already.
> this, but I am not sure if this will be possible: Ralf uses
> data structures (in particular XHashTable) which are problematic
> to access from Boot.
There is nothing specific about XHashTable. Any hash structure will do.
Use an association list, if you like.
> Extra remarks: my goal is to allow dynamic interface either using
> current C code or a web browser (depending on user choice).
As I said, I would rather like a generic interface to all the
information, separated from code that does the presentation.
Just my two cents...
Ralf
as you know, I would like to let HyperDoc die.
But, maybe that sound too extreme for what I actually mean.
And I agree to some extend to your plan for a new hyperdoc.
Let me explain my wishes.
FriCAS should have an interface (in LISP or SPAD) that let's
SPAD or external programs get information about
categories/domains/packages/documentation.
From such an interface it should be easy to generate any output format
be it html, rst or pdf.
I think this can be started without changing any code for hyperdoc.
Such an interface should already contain code to compute a datastructure
representing the data for a page (not actually rendered in any format),
in particular, conditional exports should be computed and the
datastructure should have enough information to produce links to other data.
Yes, that is good for a getting a "static" view of a constructor similar
to what is presented at fricas.io/api, but computable on-the-fly.
You also want such a view in a "dynamic" form, i.e. (similar to what
current hyperdoc provides) getting information about
- usage of domains
- fuction implementation (in which package/domain)
- etc.
Shouldn't it be possible to create an API that let's query such
information by just sending strings to specify the arguments?
Why would that need Boot code if there is a function that translates the
string "Polynomial Integer" into the respective domain and uses that in
querying the various places where the wanted information is stored in
FriCAS?
Whether you then program in interface to present such information, is
another business. I wouldn't do that but rather rely on ordinary
webbrowsers to display such information. One can probably extent jfricas
to start queries and have examples executed in a notebook interface.
Yes, I like to be able to get more information out of FriCAS than just a
static API page (although I think that having them static on the web is
still a good idea). What I am not in favour of is the current HyperDoc
window. That looks old and not very attractive. That should die. Not the
information it shows, of course.
At the same time, I would like to put the HyperTeX format to sleep.
This format was interesting 30 years ago, but now there are better
formats like rst of markdown or ... Why should we keep our specific
HyperTeX-Format that nobody outside FriCAS cares about?
I do not know whether my code is good to be adapted, because initially,
I only had the presentation into an .rst page in my mind. I think one
should carefully separate code that "provides" information from code
that translates that into a certain format.
Can we create a new branch and work (as a first step) at an interface
that provides all the necessary information in form of SExpression?
> As I wrote I have part of HyperDoc code in Spad. HyperDoc
> page has the following representation:
>
> Rep := Record(name : Symbol, domain_conditions : LSE,
> variable_alist : ALS, pattern_vars : List(PSR),
> radio_buttons : ALS, input_areas : ALS,
> property_list : ALS, page_description : LSE,
> work_area : List(String))
radio_buttons in an information record? I would rather have several data
structures like
FUN ==> Record(
name: Symbol,
source: SEX,
target: SEX,
doc: String,
condition: SEX)
CAT ==> Record(
name: Symbol,
args: List SEX,
cats: List Record(cat: CAT, condition: SEX)
funs: List FUN)
etc. (Don't take that too serious. It's just a draft.)
Anyhow, we should come up with a good datastructure that provide
easy access to the information.
If you want a datastructure that is just representing the current
hyperdoc structure, I am not interested. That is too much presentation
oriented already.
> this, but I am not sure if this will be possible: Ralf uses
> data structures (in particular XHashTable) which are problematic
> to access from Boot.
Use an association list, if you like.
> Extra remarks: my goal is to allow dynamic interface either using
> current C code or a web browser (depending on user choice).
information, separated from code that does the presentation.
Just my two cents...
Ralf
Peter Broadbery
Jun 11, 2025, 5:18:59 PMJun 11
to fricas...@googlegroups.com
Hi,
I started on something similar to replacing Hyperdoc a while ago - in
the context of an unfinished Aldor/Fricas IDE. The main idea is that
Spad types held in daase files should be representable as Aldor
objects, and from those one can do all the querying needed to generate
HTML. Overall, it worked reasonably well.
The next hard part would be integrating with a web service..
Code is here: https://github.com/pbroadbery/fricas-aldor-types - It
won't work in Fricas at the moment (due to non-essential java
dependencies), but might contain some ideas.
I will see if it can be tweaked into something that additionally works
with the Fricas runtime.
Peter
> --
> 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 visit https://groups.google.com/d/msgid/fricas-devel/1483f2d5-22a4-45a9-8f08-d9e182b8cf5c%40hemmecke.org.
I started on something similar to replacing Hyperdoc a while ago - in
the context of an unfinished Aldor/Fricas IDE. The main idea is that
Spad types held in daase files should be representable as Aldor
objects, and from those one can do all the querying needed to generate
HTML. Overall, it worked reasonably well.
The next hard part would be integrating with a web service..
Code is here: https://github.com/pbroadbery/fricas-aldor-types - It
won't work in Fricas at the moment (due to non-essential java
dependencies), but might contain some ideas.
I will see if it can be tweaked into something that additionally works
with the Fricas runtime.
Peter
> 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 visit https://groups.google.com/d/msgid/fricas-devel/1483f2d5-22a4-45a9-8f08-d9e182b8cf5c%40hemmecke.org.
Tim Daly
Jun 12, 2025, 2:58:10 AMJun 12
to FriCAS - computer algebra system
The function showdatabase might be useful. -- Tim
Tim Daly
Jun 12, 2025, 3:12:03 AMJun 12
to FriCAS - computer algebra system
There was prior work with Dick Jenks, Jim Griesmer, etc but the Scratchpad
effort was later. James Davenport or Barry Trager might have the required historical
knowledge.
Given the early time frame this could possibly support the Fortran rumor.
My understanding is that the initial Scratchpad syntax effort was in Meta.
Tim
Grégory Vanuxem
Jun 12, 2025, 5:06:31 AMJun 12
to fricas...@googlegroups.com
Hello,
Le mer. 11 juin 2025 à 20:59, 'Ralf Hemmecke' via FriCAS - computer
algebra system <fricas...@googlegroups.com> a écrit :
For what I am interested in right now, is displaying '++'
documentation in text form, and. readable directly in the interpreter
console.
From what I have read in api.spad and api2.spad the implementations
are tightly related the reST and HTML formats and I would like
plain/text format also. I do not want to use a Regex style replacement
method as it requires Julia or cl-ppcre and/or, for my concern,
cl-ppcre-unicode. Looking at api2 for example there is code to return
TexTree as a SEX expression. There is a TeXTree to HTML converter
which outputs the conversion in a file, no routine from what I have
seen that converts it to a String. I will eventually code something in
this regard. Maybe Waldek, you have already done this privately?
Having a generic parser would be a very good idea, I think. Gathering
the two parser implementations.
jlDocumentation(op) ==
ops := getDatabase("o")$OperationsQuery
docs := elt(ops,equation('name, op)$QueryEquation)
elts : DataList(String) := elt(docs,'doc)
for i in 1 .. #elts repeat
output((elts.i)::OutputForm)$OutputPackage
-- PPRINT(jlEvalString(concat(["replace(raw_"",
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition of the matrix \spad{
m}."
Type: Void
And regexing/replacing, completely irrelevant for me, some Tex-like
construct I would like to obtain something like:
(25) -> jlDocumentation "svd"
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition of the matrix m."
Type:
Void
or:
(26) -> jlDocumentation "string"
"string(f) gives string corresponding to f. Valid only when string?(f) is true"
"string(i) returns the decimal representation of i as a string."
"string(s) returns s as an element of Str. Error: if s is not an atom
that also belongs to Str."
"string(jt) returns the string representation of jt."
"string(x) stringifies x."
"string(s) converts the symbol s to a string. Error: if the symbol is
subscripted."
(27) -> jlDocumentation "str"
Type: Void
But with more information (conditional exports, origins etc.) and
more options. Probably as a system command?
)display doc string as an example.
Just my two cents.
- Greg
Le mer. 11 juin 2025 à 20:59, 'Ralf Hemmecke' via FriCAS - computer
algebra system <fricas...@googlegroups.com> a écrit :
>
> Hi Waldek,
>
> as you know, I would like to let HyperDoc die.
> But, maybe that sound too extreme for what I actually mean.
> And I agree to some extend to your plan for a new hyperdoc.
>
> Let me explain my wishes.
>
> FriCAS should have an interface (in LISP or SPAD) that let's
> SPAD or external programs get information about
> categories/domains/packages/documentation.
> From such an interface it should be easy to generate any output format
> be it html, rst or pdf.
+1
> Hi Waldek,
>
> as you know, I would like to let HyperDoc die.
> But, maybe that sound too extreme for what I actually mean.
> And I agree to some extend to your plan for a new hyperdoc.
>
> Let me explain my wishes.
>
> FriCAS should have an interface (in LISP or SPAD) that let's
> SPAD or external programs get information about
> categories/domains/packages/documentation.
> From such an interface it should be easy to generate any output format
> be it html, rst or pdf.
For what I am interested in right now, is displaying '++'
documentation in text form, and. readable directly in the interpreter
console.
From what I have read in api.spad and api2.spad the implementations
are tightly related the reST and HTML formats and I would like
plain/text format also. I do not want to use a Regex style replacement
method as it requires Julia or cl-ppcre and/or, for my concern,
cl-ppcre-unicode. Looking at api2 for example there is code to return
TexTree as a SEX expression. There is a TeXTree to HTML converter
which outputs the conversion in a file, no routine from what I have
seen that converts it to a String. I will eventually code something in
this regard. Maybe Waldek, you have already done this privately?
Having a generic parser would be a very good idea, I think. Gathering
the two parser implementations.
jlDocumentation(op) ==
ops := getDatabase("o")$OperationsQuery
docs := elt(ops,equation('name, op)$QueryEquation)
elts : DataList(String) := elt(docs,'doc)
for i in 1 .. #elts repeat
output((elts.i)::OutputForm)$OutputPackage
-- PPRINT(jlEvalString(concat(["replace(raw_"",
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition of the matrix \spad{
m}."
Type: Void
And regexing/replacing, completely irrelevant for me, some Tex-like
construct I would like to obtain something like:
(25) -> jlDocumentation "svd"
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition of the matrix m."
Type:
Void
or:
(26) -> jlDocumentation "string"
"string(f) gives string corresponding to f. Valid only when string?(f) is true"
"string(i) returns the decimal representation of i as a string."
"string(s) returns s as an element of Str. Error: if s is not an atom
that also belongs to Str."
"string(jt) returns the string representation of jt."
"string(x) stringifies x."
"string(s) converts the symbol s to a string. Error: if the symbol is
subscripted."
(27) -> jlDocumentation "str"
Type: Void
But with more information (conditional exports, origins etc.) and
more options. Probably as a system command?
)display doc string as an example.
Just my two cents.
- Greg
Tim Daly
Jun 12, 2025, 6:29:38 AMJun 12
to fricas...@googlegroups.com
Within algebra documentation for a function there are ++ and -- comments
The ++ comments are intended as documentation.
I have extended the meaning of ++ comments by appending a single letter.
For example in the 'map' function from 'StreamFunction3' you'll see
map : ((A,B) -> C,ST A,ST B) -> ST C
++ map(f,st1,st2) returns the stream whose elements are the
++ function f applied to the corresponding elements of st1 and st2.
++ \spad{map(f,[x0,x1,x2,..],[y0,y1,y2,..]) = [f(x0,y0),f(x1,y1),..]}.
++
++S
++X m:=[i for i in 1..]::Stream(Integer)
++X n:=[i for i in 1..]::Stream(Integer)
++X f(i:Integer,j:Integer):Integer == i+j
++X map(f,m,n)
++ map(f,st1,st2) returns the stream whose elements are the
++ function f applied to the corresponding elements of st1 and st2.
++ \spad{map(f,[x0,x1,x2,..],[y0,y1,y2,..]) = [f(x0,y0),f(x1,y1),..]}.
++
++S
++X m:=[i for i in 1..]::Stream(Integer)
++X n:=[i for i in 1..]::Stream(Integer)
++X f(i:Integer,j:Integer):Integer == i+j
++X map(f,m,n)
The ++X comments are part of the output shown during display functions, e.g.
)d op map
will show the ++X comments as "examples" of how to use the function.
There is also the 'ApplicationProgramInterface' which allows user-level access
to various data structures:
)abbrev package API ApplicationProgramInterface
++ Author: Timothy Daly, Martin Rubey
++ Date Created: 3 March 2009
++ Date Last Updated: 24 March 2012
++ Description:
++ This package contains useful functions that expose Axiom system internals
ApplicationProgramInterface() : SIG == CODE where
SIG ==> with
getDomains : Symbol -> Set Symbol
++ getDomains(s) takes a category and returns the list of domains
++ that have that category
++
++X getDomains 'IndexedAggregate
getAncestors : Symbol -> Set Symbol
++ getAncestors(s) takes a category and returns the list of domains
++ that have that category as ancestors
++
++X getAncestors 'IndexedAggregate
credits : () -> Void
++ credits() prints a list of people who contributed to Axiom
++
++X credits()
summary : () -> Void
++ summary() prints a short list of useful console commands
++
++X summary()
reportInstantiations : Boolean -> Void
++ reportInstantiations(bool) is a debugging tool to show
++ instantiation information
++
++X reportInstantiations(true)
++X 1
++X reportInstantiations(false)
CODE ==> add
getDomains(cat:Symbol):Set(Symbol) ==
set [symbol car first destruct a _
for a in (destruct domainsOf(cat,NIL$Lisp)$Lisp)::List(SExpression)]
getAncestors(cat:Symbol):Set(Symbol) ==
set [symbol car first destruct a _
for a in (destruct ancestorsOf(cat,NIL$Lisp)$Lisp)::List(SExpression)]
credits() == ( credits()$Lisp ; void() )
summary() == ( summary()$Lisp ; void() )
reportInstantiations(b:Boolean): Void ==
REPORTINSTANTIATIONS(b)$Lisp
void
++ Author: Timothy Daly, Martin Rubey
++ Date Created: 3 March 2009
++ Date Last Updated: 24 March 2012
++ Description:
++ This package contains useful functions that expose Axiom system internals
ApplicationProgramInterface() : SIG == CODE where
SIG ==> with
getDomains : Symbol -> Set Symbol
++ getDomains(s) takes a category and returns the list of domains
++ that have that category
++
++X getDomains 'IndexedAggregate
getAncestors : Symbol -> Set Symbol
++ getAncestors(s) takes a category and returns the list of domains
++ that have that category as ancestors
++
++X getAncestors 'IndexedAggregate
credits : () -> Void
++ credits() prints a list of people who contributed to Axiom
++
++X credits()
summary : () -> Void
++ summary() prints a short list of useful console commands
++
++X summary()
reportInstantiations : Boolean -> Void
++ reportInstantiations(bool) is a debugging tool to show
++ instantiation information
++
++X reportInstantiations(true)
++X 1
++X reportInstantiations(false)
CODE ==> add
getDomains(cat:Symbol):Set(Symbol) ==
set [symbol car first destruct a _
for a in (destruct domainsOf(cat,NIL$Lisp)$Lisp)::List(SExpression)]
getAncestors(cat:Symbol):Set(Symbol) ==
set [symbol car first destruct a _
for a in (destruct ancestorsOf(cat,NIL$Lisp)$Lisp)::List(SExpression)]
credits() == ( credits()$Lisp ; void() )
summary() == ( summary()$Lisp ; void() )
reportInstantiations(b:Boolean): Void ==
REPORTINSTANTIATIONS(b)$Lisp
void
--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/mb_O0196RMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dY5SH52A0U56a8kSqSBO%2BFX0Lzsq%3Dw6hzBCfcuBd20m8Q%40mail.gmail.com.
Tim Daly
Jun 12, 2025, 6:32:44 AMJun 12
to FriCAS - computer algebra system
Taking the idea from Ralf it seems that there could be a "hyperdoc" domain
that implements all of the functions necessary to create user documentation
with both text output and HTML output forms. From that domain it should
be possible to re-create Hyperdoc in a browser.
Grégory Vanuxem
Jun 15, 2025, 12:44:57 PMJun 15
to fricas...@googlegroups.com
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.
BTW: Timothy, your 'X' is already implemented in HyperTex with:
++ For example, using JLMatrix(JLObjFloat64):
++ \example{M:=nrand(4,4);}
++ \example{jlApply("svd", M::JLMatrix(JLObjFloat64)).S}
++ should be "equivalent" to svdvals(M)
Maybe I do not understand your 'X'.
BTW2: All my reconnaissance, of course, Tim.
Cheers,
Greg
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/d2b4d3a4-ce9e-4483-9d10-83f4add78e06n%40googlegroups.com.
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.
BTW: Timothy, your 'X' is already implemented in HyperTex with:
++ For example, using JLMatrix(JLObjFloat64):
++ \example{M:=nrand(4,4);}
++ \example{jlApply("svd", M::JLMatrix(JLObjFloat64)).S}
++ should be "equivalent" to svdvals(M)
Maybe I do not understand your 'X'.
BTW2: All my reconnaissance, of course, Tim.
Cheers,
Greg
> 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 visit https://groups.google.com/d/msgid/fricas-devel/d2b4d3a4-ce9e-4483-9d10-83f4add78e06n%40googlegroups.com.
Tim Daly
Jun 15, 2025, 1:49:23 PMJun 15
to fricas...@googlegroups.com
Greg,
I used the ++(letter) and --(letter) form for various things.
++X is used for algebra examples as shown above
These lines are output from )d op foo showing the user how to construct valid
input to the function foo. This is useful because it is hard to guess how to
contruct input of the required type. Since there are many functions with the same
name there will be many examples, each associated with one function.
In input files (src/input) they are decorated with
--S n of m which gives the number of the test, e.g. 5 of 23 indicating starting a new test
--R which gives the expected result (usually many --R lines)
--I which tells the test comparison to ignore that line (e.g. when gensyms occur)
--E n which ends the test n
This allows the test to run ignoring the --(number) decoration and output the result.
Then a program runs over the output (which includes the -- comments) and
does a text comparison of the expected result --R with the actual result. For example
-- factorization of polynomials over finite fields
--S 5 of 21
u:UP(x,PF(19)) :=3*x^4+2*x^2+15*x+18
--R
--R
--R 4 2
--R (5) 3x + 2x + 15x + 18
--R Type: UnivariatePolynomial(x,PrimeField(19))
--E 5
--S 6 of 21
factor u
--R
--R
--R 3 2
--R (6) 3(x + 18)(x + x + 8x + 13)
--R Type: Factored(UnivariatePolynomial(x,PrimeField(19)))
--E 6
Creating new tests amounts to running an expression then decorating the output with --R lines
--S 5 of 21
u:UP(x,PF(19)) :=3*x^4+2*x^2+15*x+18
--R
--R
--R 4 2
--R (5) 3x + 2x + 15x + 18
--R Type: UnivariatePolynomial(x,PrimeField(19))
--E 5
--S 6 of 21
factor u
--R
--R
--R 3 2
--R (6) 3(x + 18)(x + x + 8x + 13)
--R Type: Factored(UnivariatePolynomial(x,PrimeField(19)))
--E 6
Creating new tests amounts to running an expression then decorating the output with --R lines
surrounded by the --S and --E boundaries. Creating tests is a simple text edit. Failing tests are
indentified by file and test number showing both the computed and expected results.
--U is an external URL marker used to link to a paper that contains the algorithm.
For example, about Groebner Basis:
--P was intended to jump to the PDF output in the literate program so a user could directly
access the function sources in the correct domain along with the literate explanation.
In general since ++ and -- comments are ignored the ++(letter) and --(letter) make it easy
to add information that does not need compiler support.
Tim
++
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dYuiju2PAUO3GyADN1TXYBsaYE-MYKrUsCA-ZL9_g_4kg%40mail.gmail.com.
Waldek Hebisch
Jun 15, 2025, 2:02:57 PMJun 15
to fricas...@googlegroups.com
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
Tim Daly
Jun 15, 2025, 2:58:50 PMJun 15
to FriCAS - computer algebra system
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
Waldek Hebisch
Jun 18, 2025, 11:43:21 PMJun 18
to 'Ralf Hemmecke' via FriCAS - computer algebra system
Thank to all for comment. Ralf raised most important points,
so I will answer this first.
difference that I want Symbol-s in many places.
> Why would that need Boot code if there is a function that translates the
> string "Polynomial Integer" into the respective domain and uses that in
> querying the various places where the wanted information is stored in
> FriCAS?
My point is about doing change in incremental way. There is about
6000 lines of Boot code doing things related to HyperDoc, ')show'
and similar. Replacement preserving functionality may be smaller,
but also may be bigger. There are redundancies in existing code
so we may be able to delete some code. But Spad needs declarations,
type differences may force some duplication, so there is good
chance that Spad version may be bigger.
Doing change of this scale at "one shot" is likely to be a failure.
Keeping parallel "old" and "new" versions is a pain. That is
why I want new code to work smootly with old, in particular
using the same data structures in both.
> Whether you then program in interface to present such information, is
> another business. I wouldn't do that but rather rely on ordinary webbrowsers
> to display such information. One can probably extent jfricas to start
> queries and have examples executed in a notebook interface.
>
> Yes, I like to be able to get more information out of FriCAS than just a
> static API page (although I think that having them static on the web is
> still a good idea). What I am not in favour of is the current HyperDoc
> window. That looks old and not very attractive. That should die. Not the
> information it shows, of course.
Well, current HyperDoc window has its problems. But I hear "old
and not very attractive", but did not see mention of what I consider
to be main problem. So most of HyperDoc critique looks shallow
to me. I like fact that HyperDoc executable is quite lightweight
by modern criteria.
> At the same time, I would like to put the HyperTeX format to sleep.
> This format was interesting 30 years ago, but now there are better formats
> like rst of markdown or ... Why should we keep our specific HyperTeX-Format
> that nobody outside FriCAS cares about?
There are rather strong reasons to have format that "nobody outside
FriCAS cares about", that is format that _we_ control. Namely, in
opposite case we have to deal with changes, regardless if like
them or not. If we need extra features we can add them, we can
implement extra features. HyperTeX is a subset of TeX, which
puts some limitations, but TeX format is quite extensible so
that is not a big problem and we get advantage of reusing
existing machinery.
> I do not know whether my code is good to be adapted, because initially, I
> only had the presentation into an .rst page in my mind. I think one should
> carefully separate code that "provides" information from code that
> translates that into a certain format.
>
> Can we create a new branch and work (as a first step) at an interface
> that provides all the necessary information in form of SExpression?
Well, branch implies extra effort and I would prefer to avoid it
if possible. I started from different point, that is communitation
with HyperDoc window and now I moving towards core part, that is
search functionality. So, the interface should appear, but there
is more code than this.
> > As I wrote I have part of HyperDoc code in Spad. HyperDoc
> > page has the following representation:
> >
> > Rep := Record(name : Symbol, domain_conditions : LSE,
> > variable_alist : ALS, pattern_vars : List(PSR),
> > radio_buttons : ALS, input_areas : ALS,
> > property_list : ALS, page_description : LSE,
> > work_area : List(String))
>
> That is seemingly taylored for a hyperdoc page. Why should one have
> radio_buttons in an information record?
This record describes single page of interface. Such pages are
supposed to be interactive, so may contain buttons. For example
"Detailed search" page contains buttons for various options
affecting search. Also, HyperDoc handles example pages and
those pages also contain buttons.
As I wrote, this is rather unbalanced, most features are crammed
into 'property_list' and 'page_description' and most pages have
empty list as 'domain_conditions, 'variable_alist', 'pattern_vars',
'radio_buttons' and 'input_areas' but ATM this is needed for
compatibility with Boot code. 'work_area' is new thing, I
need it to avoid global variables used in old Boot code.
> I would rather have several data
> structures like
>
> FUN ==> Record(
> name: Symbol,
> source: SEX,
> target: SEX,
> doc: String,
> condition: SEX)
>
> CAT ==> Record(
> name: Symbol,
> args: List SEX,
> cats: List Record(cat: CAT, condition: SEX)
> funs: List FUN)
>
> etc. (Don't take that too serious. It's just a draft.)
>
> Anyhow, we should come up with a good datastructure that provide
> easy access to the information.
Well, it is not clear to me what types will be best for quering
(searching). The type I showed has quite different purpose,
it represents basic unit (that is page) of user interface.
> If you want a datastructure that is just representing the current hyperdoc
> structure, I am not interested. That is too much presentation oriented
> already.
Yes, it is presentation oriented. I would like to make it more
logical, but I do not know how far one can go in this direction
without excessive effort. However, presentation part is
necessary. Simply I want to decouple search and gathering of
information from presentation part. Currently search and
gathering of information is partly intertwined with presentation.
In better structured code presentation part should call
search and information gathering routines. Technically,
calling Boot from Spad is easier than calling Spad from
boot, that is why I prefer to start at presentation layer
and work toward more fundamental layers (and not in
opposite direction).
> > this, but I am not sure if this will be possible: Ralf uses
> > data structures (in particular XHashTable) which are problematic
> > to access from Boot.
>
> There is nothing specific about XHashTable. Any hash structure will do. Use
> an association list, if you like.
>
> > Extra remarks: my goal is to allow dynamic interface either using
> > current C code or a web browser (depending on user choice).
>
> As I said, I would rather like a generic interface to all the information,
> separated from code that does the presentation.
Yes, I want such an interface too. Simply I want woring code
in intermediate stages and staring from presentation looks
easier. Also, having working presentation gives me assurance
that I did not forget something important for presentation.
--
Waldek Hebisch
so I will answer this first.
On Wed, Jun 11, 2025 at 08:59:14PM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
>
> as you know, I would like to let HyperDoc die.
> But, maybe that sound too extreme for what I actually mean.
> And I agree to some extend to your plan for a new hyperdoc.
>
> Let me explain my wishes.
>
> FriCAS should have an interface (in LISP or SPAD) that let's
> SPAD or external programs get information about
> categories/domains/packages/documentation.
> From such an interface it should be easy to generate any output format
> be it html, rst or pdf.
>
> I think this can be started without changing any code for hyperdoc.
> Such an interface should already contain code to compute a datastructure
> representing the data for a page (not actually rendered in any format), in
> particular, conditional exports should be computed and the datastructure
> should have enough information to produce links to other data.
>
> Yes, that is good for a getting a "static" view of a constructor similar to
> what is presented at fricas.io/api, but computable on-the-fly.
>
> You also want such a view in a "dynamic" form, i.e. (similar to what current
> hyperdoc provides) getting information about
> - usage of domains
> - fuction implementation (in which package/domain)
> - etc.
>
> Shouldn't it be possible to create an API that let's query such information
> by just sending strings to specify the arguments?
Yes, that is part of my plan, with possibly not so important
>
> as you know, I would like to let HyperDoc die.
> But, maybe that sound too extreme for what I actually mean.
> And I agree to some extend to your plan for a new hyperdoc.
>
> Let me explain my wishes.
>
> FriCAS should have an interface (in LISP or SPAD) that let's
> SPAD or external programs get information about
> categories/domains/packages/documentation.
> From such an interface it should be easy to generate any output format
> be it html, rst or pdf.
>
> I think this can be started without changing any code for hyperdoc.
> Such an interface should already contain code to compute a datastructure
> representing the data for a page (not actually rendered in any format), in
> particular, conditional exports should be computed and the datastructure
> should have enough information to produce links to other data.
>
> Yes, that is good for a getting a "static" view of a constructor similar to
> what is presented at fricas.io/api, but computable on-the-fly.
>
> You also want such a view in a "dynamic" form, i.e. (similar to what current
> hyperdoc provides) getting information about
> - usage of domains
> - fuction implementation (in which package/domain)
> - etc.
>
> Shouldn't it be possible to create an API that let's query such information
> by just sending strings to specify the arguments?
difference that I want Symbol-s in many places.
> Why would that need Boot code if there is a function that translates the
> string "Polynomial Integer" into the respective domain and uses that in
> querying the various places where the wanted information is stored in
> FriCAS?
6000 lines of Boot code doing things related to HyperDoc, ')show'
and similar. Replacement preserving functionality may be smaller,
but also may be bigger. There are redundancies in existing code
so we may be able to delete some code. But Spad needs declarations,
type differences may force some duplication, so there is good
chance that Spad version may be bigger.
Doing change of this scale at "one shot" is likely to be a failure.
Keeping parallel "old" and "new" versions is a pain. That is
why I want new code to work smootly with old, in particular
using the same data structures in both.
> Whether you then program in interface to present such information, is
> another business. I wouldn't do that but rather rely on ordinary webbrowsers
> to display such information. One can probably extent jfricas to start
> queries and have examples executed in a notebook interface.
>
> Yes, I like to be able to get more information out of FriCAS than just a
> static API page (although I think that having them static on the web is
> still a good idea). What I am not in favour of is the current HyperDoc
> window. That looks old and not very attractive. That should die. Not the
> information it shows, of course.
and not very attractive", but did not see mention of what I consider
to be main problem. So most of HyperDoc critique looks shallow
to me. I like fact that HyperDoc executable is quite lightweight
by modern criteria.
> At the same time, I would like to put the HyperTeX format to sleep.
> This format was interesting 30 years ago, but now there are better formats
> like rst of markdown or ... Why should we keep our specific HyperTeX-Format
> that nobody outside FriCAS cares about?
FriCAS cares about", that is format that _we_ control. Namely, in
opposite case we have to deal with changes, regardless if like
them or not. If we need extra features we can add them, we can
implement extra features. HyperTeX is a subset of TeX, which
puts some limitations, but TeX format is quite extensible so
that is not a big problem and we get advantage of reusing
existing machinery.
> I do not know whether my code is good to be adapted, because initially, I
> only had the presentation into an .rst page in my mind. I think one should
> carefully separate code that "provides" information from code that
> translates that into a certain format.
>
> Can we create a new branch and work (as a first step) at an interface
> that provides all the necessary information in form of SExpression?
if possible. I started from different point, that is communitation
with HyperDoc window and now I moving towards core part, that is
search functionality. So, the interface should appear, but there
is more code than this.
> > As I wrote I have part of HyperDoc code in Spad. HyperDoc
> > page has the following representation:
> >
> > Rep := Record(name : Symbol, domain_conditions : LSE,
> > variable_alist : ALS, pattern_vars : List(PSR),
> > radio_buttons : ALS, input_areas : ALS,
> > property_list : ALS, page_description : LSE,
> > work_area : List(String))
>
> That is seemingly taylored for a hyperdoc page. Why should one have
> radio_buttons in an information record?
supposed to be interactive, so may contain buttons. For example
"Detailed search" page contains buttons for various options
affecting search. Also, HyperDoc handles example pages and
those pages also contain buttons.
As I wrote, this is rather unbalanced, most features are crammed
into 'property_list' and 'page_description' and most pages have
empty list as 'domain_conditions, 'variable_alist', 'pattern_vars',
'radio_buttons' and 'input_areas' but ATM this is needed for
compatibility with Boot code. 'work_area' is new thing, I
need it to avoid global variables used in old Boot code.
> I would rather have several data
> structures like
>
> FUN ==> Record(
> name: Symbol,
> source: SEX,
> target: SEX,
> doc: String,
> condition: SEX)
>
> CAT ==> Record(
> name: Symbol,
> args: List SEX,
> cats: List Record(cat: CAT, condition: SEX)
> funs: List FUN)
>
> etc. (Don't take that too serious. It's just a draft.)
>
> Anyhow, we should come up with a good datastructure that provide
> easy access to the information.
(searching). The type I showed has quite different purpose,
it represents basic unit (that is page) of user interface.
> If you want a datastructure that is just representing the current hyperdoc
> structure, I am not interested. That is too much presentation oriented
> already.
logical, but I do not know how far one can go in this direction
without excessive effort. However, presentation part is
necessary. Simply I want to decouple search and gathering of
information from presentation part. Currently search and
gathering of information is partly intertwined with presentation.
In better structured code presentation part should call
search and information gathering routines. Technically,
calling Boot from Spad is easier than calling Spad from
boot, that is why I prefer to start at presentation layer
and work toward more fundamental layers (and not in
opposite direction).
> > this, but I am not sure if this will be possible: Ralf uses
> > data structures (in particular XHashTable) which are problematic
> > to access from Boot.
>
> There is nothing specific about XHashTable. Any hash structure will do. Use
> an association list, if you like.
>
> > Extra remarks: my goal is to allow dynamic interface either using
> > current C code or a web browser (depending on user choice).
>
> As I said, I would rather like a generic interface to all the information,
> separated from code that does the presentation.
in intermediate stages and staring from presentation looks
easier. Also, having working presentation gives me assurance
that I did not forget something important for presentation.
--
Waldek Hebisch
James Cloos
Jun 19, 2025, 1:23:58 AMJun 19
to fricas...@googlegroups.com
btw, speaking of hyperdoc,
have the default fonts ever been updated to ones available in recent
distributions?
the original probably were fine on an ibm box, but were never okon an
xfree or xorg box.
i currently have:
FriCAS.hyperdoc.RmFont: -bitstream-charter-medium-r-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-*-120-*-*-m-*-iso8859-1
FriCAS.hyperdoc.ActiveFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.FriCASFont: -bitstream-charter-bold-i-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.EmphasizeFont: -bitstream-charter-medium-i-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.BoldFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
on this laptop. and used this on my workstation before it died:
! FriCAS.hyperdoc.RmFont: -b&h-lucidabright-medium-r-normal--20-*-*-*-p-*-iso8859-1
! FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-20-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.ActiveFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.FriCASFont: -b&h-lucidatypewriter-bold-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.EmphasizeFont: -b&h-lucidatypewriter-medium-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.BoldFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
not as good as client-side fonts would look, of course,
but at least readable.
(I don't recall why i used [20 0 2 20] rather than 20.
that bit of slant must have had some meaning....)
In any case, using faces which are directly available as bfd or pcf and
thus do not require scaling by the X server is vital to readability.
client-side font support would be better, but using unscaled server-side
fonts gets the job done. defaulting to widely installed faces is therefore
important.
-JimC
--
James Cloos <cl...@jhcloos.com>
OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc
have the default fonts ever been updated to ones available in recent
distributions?
the original probably were fine on an ibm box, but were never okon an
xfree or xorg box.
i currently have:
FriCAS.hyperdoc.RmFont: -bitstream-charter-medium-r-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-*-120-*-*-m-*-iso8859-1
FriCAS.hyperdoc.ActiveFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.FriCASFont: -bitstream-charter-bold-i-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.EmphasizeFont: -bitstream-charter-medium-i-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.BoldFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
on this laptop. and used this on my workstation before it died:
! FriCAS.hyperdoc.RmFont: -b&h-lucidabright-medium-r-normal--20-*-*-*-p-*-iso8859-1
! FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-20-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.ActiveFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.FriCASFont: -b&h-lucidatypewriter-bold-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.EmphasizeFont: -b&h-lucidatypewriter-medium-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.BoldFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
not as good as client-side fonts would look, of course,
but at least readable.
(I don't recall why i used [20 0 2 20] rather than 20.
that bit of slant must have had some meaning....)
In any case, using faces which are directly available as bfd or pcf and
thus do not require scaling by the X server is vital to readability.
client-side font support would be better, but using unscaled server-side
fonts gets the job done. defaulting to widely installed faces is therefore
important.
-JimC
--
James Cloos <cl...@jhcloos.com>
OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc
Waldek Hebisch
Jun 19, 2025, 11:04:51 AMJun 19
to fricas...@googlegroups.com
On Thu, Jun 19, 2025 at 01:23:55AM -0400, James Cloos wrote:
> btw, speaking of hyperdoc,
>
> have the default fonts ever been updated to ones available in recent
> distributions?
>
> the original probably were fine on an ibm box, but were never okon an
> xfree or xorg box.
I do not think that we changed anything in font setting. In the past
> btw, speaking of hyperdoc,
>
> have the default fonts ever been updated to ones available in recent
> distributions?
>
> the original probably were fine on an ibm box, but were never okon an
> xfree or xorg box.
I have looked at available fonts and they seem to differ quite a lot
between systems. AFAICS the best thing that we can do in general
(as opposed to customised user settings) is to pick default system
font. And IIUC current configuration is more or less doing this.
It is possible that we could do better to respect default system
choices, but we should make fonts less (and no more) specific.
> i currently have:
>
> FriCAS.hyperdoc.RmFont: -bitstream-charter-medium-r-normal--*-120-*-*-p-*-iso8859-1
> FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-*-120-*-*-m-*-iso8859-1
> FriCAS.hyperdoc.ActiveFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
> FriCAS.hyperdoc.FriCASFont: -bitstream-charter-bold-i-normal--*-120-*-*-p-*-iso8859-1
> FriCAS.hyperdoc.EmphasizeFont: -bitstream-charter-medium-i-normal--*-120-*-*-p-*-iso8859-1
> FriCAS.hyperdoc.BoldFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
>
> on this laptop. and used this on my workstation before it died:
>
> ! FriCAS.hyperdoc.RmFont: -b&h-lucidabright-medium-r-normal--20-*-*-*-p-*-iso8859-1
> ! FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-20-*-*-*-m-*-iso8859-1
> ! FriCAS.hyperdoc.ActiveFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
> ! FriCAS.hyperdoc.FriCASFont: -b&h-lucidatypewriter-bold-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
> ! FriCAS.hyperdoc.EmphasizeFont: -b&h-lucidatypewriter-medium-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
> ! FriCAS.hyperdoc.BoldFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
>
> not as good as client-side fonts would look, of course,
> but at least readable.
>
> (I don't recall why i used [20 0 2 20] rather than 20.
> that bit of slant must have had some meaning....)
>
> In any case, using faces which are directly available as bfd or pcf and
> thus do not require scaling by the X server is vital to readability.
> client-side font support would be better, but using unscaled server-side
> fonts gets the job done. defaulting to widely installed faces is therefore
> important.
application like HyperDoc should be able to work with system
fonts, we are not in font business.
--
Waldek Hebisch
Hill Strong
Jun 20, 2025, 7:44:02 AMJun 20
to fricas...@googlegroups.com
I know that many projects don't want to consider that fonts should be included, however, when you include a specific set of fonts and install them as a part of the build/installation process, you are giving a bit of polish to your application.
Likewise, making it easy for the user to specify specific fonts applicable to them also shows polish on your part.
If you leave it up to some possible set of standard fonts that you expect to already exist then people who may have been interested can and do walk away as they can often think that your application is not worth the effort.
Something to consider.
--
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 visit https://groups.google.com/d/msgid/fricas-devel/aFQnED_pH5oqBgDI%40fricas.org.
James Cloos
Jun 20, 2025, 8:36:52 AMJun 20
to Waldek Hebisch, fricas...@googlegroups.com
>>>>> "WH" == Waldek Hebisch <de...@fricas.org> writes:
WH> I understand that some applications want custom fonts. But simple
WH> application like HyperDoc should be able to work with system
WH> fonts, we are not in font business.
i cettainly never suggested custom fonts.
axiom from its initial floss release defaulted to fonts ibm x servers
supported due to ibm licensing adobe's t1 fonts.
floss distributions only eber had a small, fixed number of bitmap
strikes of those fonts. and the sizes axiom specified were not amoung
those available to users of xfree86 (and later xorg) servers.
thus hyperdoc was entirely unreadable.
one had to come up with values for each of:
Axiom.hyperdoc.RmFont
Axiom.hyperdoc.TtFont
Axiom.hyperdoc.ActiveFont
Axiom.hyperdoc.AxiomFont
Axiom.hyperdoc.EmphasizeFont
Axiom.hyperdoc.BoldFont
which were listed in the output of xlsfonts(1) on one's server to be able
to read any of the hyperdoc output.
when the xserver has to scale bitmap strikes the output is crap.
as i recall, xorg dropped support for type1 and ttf fonts some time ago.
they certainly do not show up in xlsfonts(1)'s output on this xserver.
so if fricas still defaults to the faces ibm used to specify, hyperdoc
will be unreadable without local customization until it switches to
client-side fonts.
so until that occurs (not demanding that or anything!) the default fonts
should be chosen from what xlsfonts(1) reports, which means not only the
face's name but also the pointsize.
WH> I understand that some applications want custom fonts. But simple
WH> application like HyperDoc should be able to work with system
WH> fonts, we are not in font business.
i cettainly never suggested custom fonts.
axiom from its initial floss release defaulted to fonts ibm x servers
supported due to ibm licensing adobe's t1 fonts.
floss distributions only eber had a small, fixed number of bitmap
strikes of those fonts. and the sizes axiom specified were not amoung
those available to users of xfree86 (and later xorg) servers.
thus hyperdoc was entirely unreadable.
one had to come up with values for each of:
Axiom.hyperdoc.RmFont
Axiom.hyperdoc.TtFont
Axiom.hyperdoc.ActiveFont
Axiom.hyperdoc.AxiomFont
Axiom.hyperdoc.EmphasizeFont
Axiom.hyperdoc.BoldFont
which were listed in the output of xlsfonts(1) on one's server to be able
to read any of the hyperdoc output.
when the xserver has to scale bitmap strikes the output is crap.
as i recall, xorg dropped support for type1 and ttf fonts some time ago.
they certainly do not show up in xlsfonts(1)'s output on this xserver.
so if fricas still defaults to the faces ibm used to specify, hyperdoc
will be unreadable without local customization until it switches to
client-side fonts.
so until that occurs (not demanding that or anything!) the default fonts
should be chosen from what xlsfonts(1) reports, which means not only the
face's name but also the pointsize.
Tim Daly
Jun 20, 2025, 9:47:48 AMJun 20
to fricas...@googlegroups.com, Waldek Hebisch
Correction:
JimC> axiom from its initial floss release defaulted to fonts ibm x servers
JimC> supported due to ibm licensing adobe's t1 fonts.
JimC> supported due to ibm licensing adobe's t1 fonts.
Scratchpad development started on X10 and the fonts were a carry-over.
There was some discussion in 2005 or so related to the Adobe SVG viewer.
There is a reference to adobe-courier-{medium,bold}...iso8859-1
Font choice is painful as not all fonts contain the mathematical symbols.
It might be worthwhile testing on Wayland as I understand it is supposed to
replace X11.
Tim
--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/mb_O0196RMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/m3sejuzj24.fsf%40lugabout.jhcloos.org.
James Cloos
Jun 20, 2025, 11:33:16 AMJun 20
to Tim Daly, fricas...@googlegroups.com, Waldek Hebisch
>>>>> "TD" == Tim Daly <axio...@gmail.com> writes:
TD> Correction:
TD> Scratchpad development started on X10 and the fonts were a carry-over.
TD> There was some discussion in 2005 or so related to the Adobe SVG viewer.
TD> There is a reference to adobe-courier-{medium,bold}...iso8859-1
thanks for the correction.
i thought i also recalled use of times and/or helvetica.
but always at a point size not coverred by the bfd/pcf bitmap fonts
included in xfree and later xorg.
TD> Correction:
TD> Scratchpad development started on X10 and the fonts were a carry-over.
TD> There was some discussion in 2005 or so related to the Adobe SVG viewer.
TD> There is a reference to adobe-courier-{medium,bold}...iso8859-1
thanks for the correction.
i thought i also recalled use of times and/or helvetica.
but always at a point size not coverred by the bfd/pcf bitmap fonts
included in xfree and later xorg.
Tim Daly
Jun 20, 2025, 1:40:34 PMJun 20
to James Cloos, fricas...@googlegroups.com, Waldek Hebisch
Hyperdoc, as Ralf points out, is outdated and needs to be replaced.
Browser-based Hyperdoc is clearly the last-years-technology way to go.
That would solve the font problem but is still "old school".
Actually, LLMs are clearly the way to go but I don't think most people
are up-to-speed on creating LLM apps yet. The LLM approach could
not only explain the available integration functions and choose the
right signature, it could explain why a Sylvester matrix is used to
compute the resultant used in the algorithm.
The Model-Context Protocol (MCP) is clearly the best way to replace Hyperdoc
as MCP allows LLMs to interact and access external data sources. A computer
algebra MCP adapter is clearly the best choice going forward. It gives access to
all of the existing LLMs in a uniform and universal way.
With such an adapter you could just ask for the integration and/or ask a lot of
questions about the integral. In fact, as a research tool such an MCP interface
would help answer questions the LLM knows about limits, alternate approaches,
etc. which allows "discussing" the integral with the LLM. The LLM could suggest
and summarize available relevant papers in real time.
If I were still active I'd choose that path forward.
Tim
Grégory Vanuxem
Jun 20, 2025, 4:16:31 PMJun 20
to fricas...@googlegroups.com
Hello Tim, *,
Thanks for your response, but frankly speaking, I do not know how to
find your code. I tried to download Axiom, it is not easy.
I just found axiom_20210105dp1.tar.gz but apparently, right now, Camm
has done some improvements to find better/recent source code.
I have to try it.
- Greg
PS/ sorry for the delay
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3DKecxUfnoxp1sLEQOnY06s3RSrWejf2C%3DrzPCnZ%2BbdP7A%40mail.gmail.com.
Thanks for your response, but frankly speaking, I do not know how to
find your code. I tried to download Axiom, it is not easy.
I just found axiom_20210105dp1.tar.gz but apparently, right now, Camm
has done some improvements to find better/recent source code.
I have to try it.
- Greg
PS/ sorry for the delay
Grégory Vanuxem
Jun 20, 2025, 5:01:29 PMJun 20
to fricas...@googlegroups.com
Yes of couse. But you're looking very forward a lot I think. I follow that since a lot of time.
I have asked, personally, to Brent, Nocedal etc. in 2007, for using their code sources, https://metacpan.org/pod/PDL::Opt::NonLinear
they were very moneyable at that time. They agreed. I agree with Linus Torvalds, AI, 95% of marketing.
But I think you see to a lot forward. Fonts, is another matter, it is a real problem BTW, just this week because of a dist-upgrading I had to wait for an update. To small to read without glasses. An unknown reason.
I think your idea Tim can be very good. But a lot of things in the numerical world need to be done/added.
- Greg
Waldek Hebisch
Jun 20, 2025, 5:09:58 PMJun 20
to fricas...@googlegroups.com
On Fri, Jun 20, 2025 at 08:36:19AM -0400, James Cloos wrote:
> >>>>> "WH" == Waldek Hebisch <de...@fricas.org> writes:
>
> WH> I understand that some applications want custom fonts. But simple
> WH> application like HyperDoc should be able to work with system
> WH> fonts, we are not in font business.
>
> i cettainly never suggested custom fonts.
>
> axiom from its initial floss release defaulted to fonts ibm x servers
> supported due to ibm licensing adobe's t1 fonts.
>
> floss distributions only eber had a small, fixed number of bitmap
> strikes of those fonts. and the sizes axiom specified were not amoung
> those available to users of xfree86 (and later xorg) servers.
FriCAS specifies the following fonts:
> >>>>> "WH" == Waldek Hebisch <de...@fricas.org> writes:
>
> WH> I understand that some applications want custom fonts. But simple
> WH> application like HyperDoc should be able to work with system
> WH> fonts, we are not in font business.
>
> i cettainly never suggested custom fonts.
>
> axiom from its initial floss release defaulted to fonts ibm x servers
> supported due to ibm licensing adobe's t1 fonts.
>
> floss distributions only eber had a small, fixed number of bitmap
> strikes of those fonts. and the sizes axiom specified were not amoung
> those available to users of xfree86 (and later xorg) servers.
-adobe-courier-medium-r-normal--18-*-*-*-m-*-iso8859-1
-adobe-courier-medium-o-normal--18-*-*-*-m-*-iso8859-1
-adobe-courier-bold-r-normal--18-*-*-*-m-*-iso8859-1
-adobe-courier-bold-o-normal--18-*-*-*-m-*-iso8859-1
Fonts matching that appear in output of xlsfonts on my machine,
which IIUC means that they are available.
> thus hyperdoc was entirely unreadable.
>
> one had to come up with values for each of:
>
> Axiom.hyperdoc.RmFont
> Axiom.hyperdoc.TtFont
> Axiom.hyperdoc.ActiveFont
> Axiom.hyperdoc.AxiomFont
> Axiom.hyperdoc.EmphasizeFont
> Axiom.hyperdoc.BoldFont
>
> which were listed in the output of xlsfonts(1) on one's server to be able
> to read any of the hyperdoc output.
>
> when the xserver has to scale bitmap strikes the output is crap.
>
> as i recall, xorg dropped support for type1 and ttf fonts some time ago.
news that FreeType dropped support for hints in fonts. This
was after a patent dispute, but FreeType folks claimed that
they get better results without hints.
> they certainly do not show up in xlsfonts(1)'s output on this xserver.
>
> so if fricas still defaults to the faces ibm used to specify, hyperdoc
> will be unreadable without local customization until it switches to
> client-side fonts.
>
> so until that occurs (not demanding that or anything!) the default fonts
> should be chosen from what xlsfonts(1) reports, which means not only the
> face's name but also the pointsize.
My understanding was that available fonts differ widely between
systems, in particular there are silly renamings due to trandmark
reasons and essentially identical fonts with widely different
names. Anyway, the discussing did not found better default
than the one we have now.
--
Waldek Hebisch
Tim Daly
Jun 20, 2025, 5:36:00 PMJun 20
to fricas...@googlegroups.com
git clone https://github.com/axiom/daly
should give you the last known public version.
Camm has a public copy at
If you look at axiom/src/input you will find *.pamphlet test files.
They are really just *.tex (as are all .pamphlet files)
You can also find various tests against other published collections
which I call the "Computer Algebra Test Suite" (CATS), with the
intention of collecting and testing against other public collections
(see chapter 5 of bookvol8.1 related to pasta for fun examples)
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2datEvCjyDs2qb%3D-PTxfHkOfPvmPF9NJpVDYVwt-gCMtXw%40mail.gmail.com.
Tim Daly
Jun 20, 2025, 5:48:00 PMJun 20
to fricas...@googlegroups.com
Wow. I really love that PDL:: site!
On the numeric front I have created a lisp version of BLAS and LAPACK
as part of the distribution. There needs to be a test suite created as well
as SPAD "cover functions" and further detailed documentation.
On the ambitious front there should be CUDA code versions included.
Tim
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZcOdhgXR6wHJ99Pgf9oEjCAos1OpWsf4mthFB2qmUxnw%40mail.gmail.com.
James Cloos
Jun 20, 2025, 10:02:00 PMJun 20
to Waldek Hebisch, fricas...@googlegroups.com
WH> FriCAS specifies the following fonts:
WH> -adobe-courier-medium-r-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-medium-o-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-bold-r-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-bold-o-normal--18-*-*-*-m-*-iso8859-1
WH> Fonts matching that appear in output of xlsfonts on my machine,
WH> which IIUC means that they are available.
Ah. xorg only ships 11, 14 and 17 point versions of those.
not 18 pt.
from the fonts.dir file:
courB12-ISO8859-1.pcf.gz -adobe-courier-bold-r-normal--17-120-100-100-m-100-iso8859-1
courBO12-ISO8859-1.pcf.gz -adobe-courier-bold-o-normal--17-120-100-100-m-100-iso8859-1
courO12-ISO8859-1.pcf.gz -adobe-courier-medium-o-normal--17-120-100-100-m-100-iso8859-1
courR12-ISO8859-1.pcf.gz -adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1
so the xserver has to scale the 17 to 18. which looks ugly.
s/18/17/ would at least solve that visual annoyance.
WH> -adobe-courier-medium-r-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-medium-o-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-bold-r-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-bold-o-normal--18-*-*-*-m-*-iso8859-1
WH> Fonts matching that appear in output of xlsfonts on my machine,
WH> which IIUC means that they are available.
Ah. xorg only ships 11, 14 and 17 point versions of those.
not 18 pt.
from the fonts.dir file:
courB12-ISO8859-1.pcf.gz -adobe-courier-bold-r-normal--17-120-100-100-m-100-iso8859-1
courBO12-ISO8859-1.pcf.gz -adobe-courier-bold-o-normal--17-120-100-100-m-100-iso8859-1
courO12-ISO8859-1.pcf.gz -adobe-courier-medium-o-normal--17-120-100-100-m-100-iso8859-1
courR12-ISO8859-1.pcf.gz -adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1
so the xserver has to scale the 17 to 18. which looks ugly.
s/18/17/ would at least solve that visual annoyance.
James Cloos
Jun 21, 2025, 12:50:14 AMJun 21
to fricas...@googlegroups.com
so, obviouly my recall is not as good as it used to be...
(and it has been a couple of decades since i did much with the server-
side fonts.....)
so some corrections to my statements:
after further review, i see that the 18pt adobe-courier strikes are in
the 75dpi/fonts.dir which (obviously) was not in this box's font path.
and Type1/fonts.scale (also was not in my fp) has:
cour.pfa -ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
courb.pfa -ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
courbi.pfa -ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1
couri.pfa -ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1
which can fully scale.
so perhaps the best change would be s/adobe/*/ so that the ibm-courier
pfb file get chosen when Type1 is in the fp, but the adobe-courier still
can get used when only bfd or pcf fonts are in the fp.
i thought i recalled that xorg removed the type1 server-side renderer.
but perhaps that was only proposed and rejected? or reversed?
too many decades. and two many strokes.
(and it has been a couple of decades since i did much with the server-
side fonts.....)
so some corrections to my statements:
after further review, i see that the 18pt adobe-courier strikes are in
the 75dpi/fonts.dir which (obviously) was not in this box's font path.
and Type1/fonts.scale (also was not in my fp) has:
cour.pfa -ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
courb.pfa -ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
courbi.pfa -ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1
couri.pfa -ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1
which can fully scale.
so perhaps the best change would be s/adobe/*/ so that the ibm-courier
pfb file get chosen when Type1 is in the fp, but the adobe-courier still
can get used when only bfd or pcf fonts are in the fp.
i thought i recalled that xorg removed the type1 server-side renderer.
but perhaps that was only proposed and rejected? or reversed?
too many decades. and two many strokes.
Tim Daly
Jun 23, 2025, 6:25:20 PMJun 23
to FriCAS - computer algebra system
It seems that it might take a day of hacking to connect to Claude AI
or other AI systems. The clearest example with code is at
So if you want to try to connect to an AI to answer integration questions
this should provide sufficient background to get it running quickly.
An MCP server could even be customized to read and format database
information to answer questions about available domains, functions,
and documentation. It could even be formatted similar to Hyperdoc output.
Suddenly all of the AIs know how to do computer algebra.
Tim
Nasser M. Abbasi
Jun 27, 2025, 6:55:03 AMJun 27
to FriCAS - computer algebra system
"
Suddenly all of the AIs know how to do computer algebra."
When chaptGPT 3.5 came out in 2022, I run one integration test file (MIT integration problems) using
chaptgpt 3.5. At the time just to try it.
Had to type each problem by hand one by one into the command and copy
the result. May be these days this can be automated with the new API's.
But at the time chaptGPT did not do well. It scored lowest in percentage solved. I am sure it has improved by now.
Here is the HTML (there is also PDF file)
Here is the HTML (there is also PDF file)
This was the result (percentage solved)
Mathematica 99.38
Fricas 96.57
Maple 95.33
Rubi 94.08
Maxima 92.52
Giac 91.59
Mupad 90.03
Sympy 82.24
ChatGPT 14.33
Mathematica 99.38
Fricas 96.57
Maple 95.33
Rubi 94.08
Maxima 92.52
Giac 91.59
Mupad 90.03
Sympy 82.24
ChatGPT 14.33
--Nasser
Tim Daly
Jun 27, 2025, 8:21:00 AMJun 27
to fricas...@googlegroups.com
The AI isn't doing the problem solving. It is using the computer algebra system
as a problem solver. This is similar to the way William Stein's Sagemath
connects to other systems to supply answers. The key difference is that
MCP is an open standard that can be used by anything, including LLMs.
The MCP idea is to set up a server that advertises the ability to answer
mathematical questions and provide a client that provides the actual
answers. The various computer algebra systems provide their own client.
All of the LLMs can use MCP. They can know the services provided by
the server (e.g. computer algebra) and will ask the server for answers.
This is different than asking ChatGPT to provide answers.
This is standards based and much more general than having a system
like Hyperdoc. A new Hyperdoc would communicate with an MCP
server to provide a "hyperdoc-like" page. This is the same argument
used for HTML, JSON, and other general standards behind a browser.
Tim
--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/mb_O0196RMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/0fafdeb1-f723-4f4b-8f80-f1f7758d8b05n%40googlegroups.com.
Grégory Vanuxem
Jun 28, 2025, 2:04:59 AMJun 28
to fricas...@googlegroups.com
This is already available, here, using a very experimental FriCAS extension to VSCode and Gemini. The question is: how to integrate sin(x):
Hoping, the pictures are only downloaded if necessary.
- Greg
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 visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3DKEHpmcJHqkz_SyHaGwyhwDghzbV_SDKA_0R7MExu8nRA%40mail.gmail.com.
Tim Daly
Jun 28, 2025, 11:01:57 AMJun 28
to fricas...@googlegroups.com
That's a beautiful piece of work!
I might suggest including external links to related information,
e.g. a youtube video discussing the algorithm or a technical
paper / book that contains the algorithm such as Trager's PhD thesis:
Raab,Clemens G., Singer, Michael F.
-"Integration In Finite Terms: Fundamental Sources"
Springer, 2022, ISBN 978-3-030-97866-4
Tim
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dbxAmXFbvUO42y8ivvcDn1DKhGcdOESb56qF3BgLoPgUw%40mail.gmail.com.
Waldek Hebisch
Jun 28, 2025, 1:03:11 PMJun 28
to fricas...@googlegroups.com
On Sat, Jun 21, 2025 at 12:45:10AM -0400, James Cloos wrote:
> so, obviouly my recall is not as good as it used to be...
>
> (and it has been a couple of decades since i did much with the server-
> side fonts.....)
>
> so some corrections to my statements:
>
> after further review, i see that the 18pt adobe-courier strikes are in
> the 75dpi/fonts.dir which (obviously) was not in this box's font path.
>
> and Type1/fonts.scale (also was not in my fp) has:
>
> cour.pfa -ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
> courb.pfa -ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
> courbi.pfa -ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1
> couri.pfa -ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1
>
> which can fully scale.
>
> so perhaps the best change would be s/adobe/*/ so that the ibm-courier
> pfb file get chosen when Type1 is in the fp, but the adobe-courier still
> can get used when only bfd or pcf fonts are in the fp.
We could drop 'adobe' part of the font. On my machine there is
> so, obviouly my recall is not as good as it used to be...
>
> (and it has been a couple of decades since i did much with the server-
> side fonts.....)
>
> so some corrections to my statements:
>
> after further review, i see that the 18pt adobe-courier strikes are in
> the 75dpi/fonts.dir which (obviously) was not in this box's font path.
>
> and Type1/fonts.scale (also was not in my fp) has:
>
> cour.pfa -ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
> courb.pfa -ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
> courbi.pfa -ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1
> couri.pfa -ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1
>
> which can fully scale.
>
> so perhaps the best change would be s/adobe/*/ so that the ibm-courier
> pfb file get chosen when Type1 is in the fp, but the adobe-courier still
> can get used when only bfd or pcf fonts are in the fp.
no ibm courier font. I have probably fake adobe "scalable" font
(it appears as a scalable font in font list, but AFAICS there
is no correspondingh real scalable font). There are also
'courier 10 pitch' fonts which seem to be true scalable
fonts.
AFAICS Reduce ships a few fonts.
--
Waldek Hebisch
Grégory Vanuxem
Jun 28, 2025, 3:10:00 PMJun 28
to fricas...@googlegroups.com
This is a plugin in VSCode: https://marketplace.visualstudio.com/items?itemName=Google.geminicodeassist&ssr=false#overview
You open axiom or fricas source code directory in VSCode and the Gemini AI will help you for coding or using panAxiom. Copilot is also available. The advantage of Gemini is that is not as restricted as Copilot for example.
- Greg
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3DKQWGM5d%3D0R-m1XyvbkwNP4repBR8Xk-PqGab_DigEvaQ%40mail.gmail.com.
James Cloos
Jun 29, 2025, 12:57:41 AM (14 days ago) Jun 29
to fricas...@googlegroups.com
and one last thought.
i was reading thru fricas-book. it notes:
FriCAS.hyperdoc.RmFont: Rom14
FriCAS.hyperdoc.ActiveFont: Bld14
FriCAS.hyperdoc.FriCASFont: Bld14
FriCAS.hyperdoc.BoldFont: Bld14
FriCAS.hyperdoc.TtFont: Rom14
FriCAS.hyperdoc.EmphasizeFont: Itl14
so the answer to my original q is: yes, you did change from axiom's
original hyperdoc font defaults to ones at least shipped by xfree and
now xorg.
the scalable ibm-courier is, on gentoo, in the package font-ibm-type1,
with homepages:
https://www.x.org/wiki/
https://gitlab.freedesktop.org/xorg/font/ibm-type1
so shipped by xorg; but i've no idea which packages to suggest for other
distributions. i should have looked deeper before suggesting that....
i was reading thru fricas-book. it notes:
FriCAS.hyperdoc.RmFont: Rom14
FriCAS.hyperdoc.ActiveFont: Bld14
FriCAS.hyperdoc.FriCASFont: Bld14
FriCAS.hyperdoc.BoldFont: Bld14
FriCAS.hyperdoc.TtFont: Rom14
FriCAS.hyperdoc.EmphasizeFont: Itl14
so the answer to my original q is: yes, you did change from axiom's
original hyperdoc font defaults to ones at least shipped by xfree and
now xorg.
the scalable ibm-courier is, on gentoo, in the package font-ibm-type1,
with homepages:
https://www.x.org/wiki/
https://gitlab.freedesktop.org/xorg/font/ibm-type1
so shipped by xorg; but i've no idea which packages to suggest for other
distributions. i should have looked deeper before suggesting that....
Grégory Vanuxem
Jun 29, 2025, 2:07:21 AM (14 days ago) Jun 29
to fricas...@googlegroups.com
Hello James, *,
On Debian like system:
└─$ apt-cache search ibm |grep font
console-cyrillic - Cyrillic fonts and keyboard layouts for Linux console
fonts-3270 - monospaced font based on IBM 3270 terminals
fonts-pc - TrueType conversions of PC ROM fonts
fonts-pc-extra - TrueType conversions of PC ROM fonts (less popular variants)
fonts-texgyre - OpenType fonts based on URW Fonts
fonts-yusei-magic - handwritten letters written with permanent marker
golang-github-pbnjay-pixfont-dev - pixel font package for Go (library)
librust-ab-glyph-dev - API for loading, scaling, positioning and
rasterizing OpenType font glyphs - Rust source code
texlive-fonts-extra - TeX Live: Additional fonts
xfonts-scalable - scalable fonts for X
xfonts-x3270-misc - Font files for the x3270(1) IBM 3270 emulator
fonts-ibm-plex - extensive typeface family designed by IBM
t1-xfree86-nonfree - non-free Postscript Type 1 fonts from XFree86
There is also:
└─$ apt-cache show fonts-ibm-plex
Package: fonts-ibm-plex
Version: 6.1.1-1
Installed-Size: 41800
Maintainer: Debian Fonts Task Force <debian...@lists.debian.org>
Architecture: all
Size: 26024764
SHA256: 682528a0832d8c5c3a92c64434c99fcceb1d2836ce7cf3cced902dcd86a188b2
SHA1: e4200c0e48bae0a7a34948927fc024c9791794e6
MD5sum: c047e907d3f395e2de6b70881327877b
Description: extensive typeface family designed by IBM
IBM Plex is an extensive font family developed by IBM. It comes in four
subfamilies (Sans, Sans Condensed, Mono and Serif) and 8 weights (Thin,
Extralight, Light, Regular, Text, Medium, Semibold, Bold), with true italics
to complement them. A variable-weight counterpart of IBM Plex Sans is also
available.
.
The four basic subfamilies support most of the languages using the Latin
alphabet (including Vietnamese), the Cyrillic writing system and monotonic
Greek. Hebrew (including cantillation marks), Thai (both looped and loopless),
Devanagari and Arabic are supported as separate typefaces.
.
There is also support for common mathematical and currency symbols as well as
ligatures and stylistic alternates.
.
This package contains the TrueType (CFF) flavored OpenType fonts and
the WOFF/WOFF2 web fonts.
Description-md5:
Multi-Arch: foreign
Homepage: https://www.ibm.com/plex/
Section: contrib/fonts
Priority: optional
Filename: pool/contrib/f/fonts-ibm-plex/fonts-ibm-plex_6.1.1-1_all.deb
But I think they are more recent fonts.
- Greg
On Debian like system:
└─$ apt-cache search ibm |grep font
console-cyrillic - Cyrillic fonts and keyboard layouts for Linux console
fonts-3270 - monospaced font based on IBM 3270 terminals
fonts-pc - TrueType conversions of PC ROM fonts
fonts-pc-extra - TrueType conversions of PC ROM fonts (less popular variants)
fonts-texgyre - OpenType fonts based on URW Fonts
fonts-yusei-magic - handwritten letters written with permanent marker
golang-github-pbnjay-pixfont-dev - pixel font package for Go (library)
librust-ab-glyph-dev - API for loading, scaling, positioning and
rasterizing OpenType font glyphs - Rust source code
texlive-fonts-extra - TeX Live: Additional fonts
xfonts-scalable - scalable fonts for X
xfonts-x3270-misc - Font files for the x3270(1) IBM 3270 emulator
fonts-ibm-plex - extensive typeface family designed by IBM
t1-xfree86-nonfree - non-free Postscript Type 1 fonts from XFree86
There is also:
└─$ apt-cache show fonts-ibm-plex
Package: fonts-ibm-plex
Version: 6.1.1-1
Installed-Size: 41800
Maintainer: Debian Fonts Task Force <debian...@lists.debian.org>
Architecture: all
Size: 26024764
SHA256: 682528a0832d8c5c3a92c64434c99fcceb1d2836ce7cf3cced902dcd86a188b2
SHA1: e4200c0e48bae0a7a34948927fc024c9791794e6
MD5sum: c047e907d3f395e2de6b70881327877b
Description: extensive typeface family designed by IBM
IBM Plex is an extensive font family developed by IBM. It comes in four
subfamilies (Sans, Sans Condensed, Mono and Serif) and 8 weights (Thin,
Extralight, Light, Regular, Text, Medium, Semibold, Bold), with true italics
to complement them. A variable-weight counterpart of IBM Plex Sans is also
available.
.
The four basic subfamilies support most of the languages using the Latin
alphabet (including Vietnamese), the Cyrillic writing system and monotonic
Greek. Hebrew (including cantillation marks), Thai (both looped and loopless),
Devanagari and Arabic are supported as separate typefaces.
.
There is also support for common mathematical and currency symbols as well as
ligatures and stylistic alternates.
.
This package contains the TrueType (CFF) flavored OpenType fonts and
the WOFF/WOFF2 web fonts.
Description-md5:
Multi-Arch: foreign
Homepage: https://www.ibm.com/plex/
Section: contrib/fonts
Priority: optional
Filename: pool/contrib/f/fonts-ibm-plex/fonts-ibm-plex_6.1.1-1_all.deb
But I think they are more recent fonts.
- Greg
> --
> 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 visit https://groups.google.com/d/msgid/fricas-devel/m3ldpbw3em.fsf%40lugabout.jhcloos.org.
> 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.
Reply all
Reply to author
Forward
0 new messages