I have downloaded and installed the last version of REDUCE rev 7327 (7-Mar-2026).
I'm using EXCALC. I would like to know if there is a way to obtain the geodesic equations given the coframe, preferable 4D, pseudo-Riemann? Thanks.
Hi Daniel,
This is more of a question than a bug.
If you are looking for the equation of geodesics, you could do it like in the snippet below. There it is for a Schwarzschild like geometry.
I was not able to find any mention of the command "remflag"
in the REDUCE User's manual (June 23, 2025), that you use
in your script: "remflag('(u a),'covariant);"
Daniel Volinski
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was not able to find any mention of the command "remflag"
in the REDUCE User's manual (June 23, 2025), that you use
in your script: "remflag('(u a),'covariant);"
Daniel Volinski
"remflag" is a function from "symbolic mode" ie the implmentation level so
you may find it rentioned in the explanation of "Standard Lisp". Names
(like u and a here) can be "flagged" and in excalc a flag "covariant" is
probably a concept you can guess the intent of. remflag removes that
property.
The quote marks there instruct the system to view the text (u a) and the
symbol covariant not as a function call to a function u and not to
reference to a variable called covariant but to be denotations of raw
data, and in a range of cases when it is used the system "understands" to
treat what it is doing as direct manipulation of data rather than
algebraic computation as such.
Arthur
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where exactly can I find documentation on symbolic mode function
remflag and others like it, that I can use in REDUCE but do not appear
in the REDUCE documentation?
Daniel Volinski
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Where exactly can I find documentation on symbolic mode function
remflag and others like it, that I can use in REDUCE but do not appear
in the REDUCE documentation?
Daniel Volinski
Using those things means you are moving down into the implementer or
maintainer world, so transcribing particular examples you see in working
code is OK but to go further you would in general need to be happy reading
the Reduce source code (which is of course all available to you, and many
people have found is not TOO hard to get into).
The place you can look is in the doc/primers directory in the full Reduce
source tree. There "sl.pdf" is a baseline explanation of lisp-level
functions that Reduce is built on top of, and eg with reflag what it says
is
REMFLAG{(\p{U}:{eval, spread}
Removes the flag V from the property list of each member of the list
U. Both V and all the elements of U must be ids or the type mismatch
error will occur.
which may or may not enlighten you just now! But primer.pdf and
insidereduce.pdf are attempts to help bridge the gap so that people can
see how higher level features and algebraic operations are built out of
operations on data structures.
Then all the main bits of Reduce source line in packages/<packagename>
in files with suffice ".red", so for instance excalc stuff is in
packages/excalc, where you find the current about 4000 lines that do all
that stuff. Obviously the code there calls on many many internal Reduce
functions from elsewhere in the system - for instance it may call "addsq"
to form the sum of two formulae that are at that stage stored in a
representation that Reduce calls a "standard form". But since you will
know what transformations it will be doing for you when you invoke it
there is a significant chance that you could make sense of it at a high
level after not too much effort reading one of the primers.</packagename>
When an operation becomes sufficiently important or commonly used a hook
so that a special keyword to do it from the user level gets put in,
and then somebody has to add that to the documentation that is aready
bulky enough that one can hardly be certain that people will find what
they are looking for!
The overall history of much of Reduce is that each package starts by
providing the facilities that its author or authors needed for their own
work or expected people in their field to need. Extras get put in when
a need is seen and the balance beteen demand and available time allows.
And MANY of the packages have arisen when somebody wishes to push their
particular area beyond the current capabilities, and they discover that
adding new features is not as terrifing as they first feared. The primers
are there to help people get started down that path. Those who are able
to contribute useful extensions can then be granted write-access to the
repository - and maybe by virtue of what they have learned they can join
in supporting others less far along the path.
The packages//.tst files are things provided by package authors to show
off or test some of what their code can do. I tends to view them as
another part of the explanation (ie documentation).
In the excalc case it maybe that the excalc.tst suggests that "remfdomain"
was viewed as important enough to be made user visible but that removing
the covariantness was going to be less command and
remflag('(u), 'covariant);
was so concise it would suffice and having a
uncovariant u;
statement would be overkill?
Hoep this helps - and apologies if it is a bit long. But I hope that some
of what is being said will be relevant in other cases regarding other
packages in the future.
Arthur
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Daniel,
This is more of a question than a bug.
If you are looking for the equation of geodesics, you could do it like in the snippet below. There it is for a Schwarzschild like geometry.
Eberhard
Hi Eberhard,
Thank you for the answer and sorry for my confusion.
Daniel Volinski
Hi Eberhard,
I was not able to find any mention of the command "remflag"
in the REDUCE User's manual (June 23, 2025), that you use
in your script: "remflag('(u a),'covariant);"
Daniel Volinski
On Fri, 13 Mar 2026, Daniel Volinski wrote:
"remflag" is a function from "symbolic mode" ie the implmentation level so
you may find it rentioned in the explanation of "Standard Lisp". Names
(like u and a here) can be "flagged" and in excalc a flag "covariant" is
probably a concept you can guess the intent of. remflag removes that
property.
The quote marks there instruct the system to view the text (u a) and the
symbol covariant not as a function call to a function u and not to
reference to a variable called covariant but to be denotations of raw
data, and in a range of cases when it is used the system "understands" to
treat what it is doing as direct manipulation of data rather than
algebraic computation as such.
Arthur
Thank you Arthur for your response.
Where exactly can I find documentation on symbolic mode function
remflag and others like it, that I can use in REDUCE but do not appear
in the REDUCE documentation?
Daniel Volinski
On Sat, 14 Mar 2026, Daniel Volinski wrote:
The place you can look is in the doc/primers directory in the full Reduce
source tree. There "sl.pdf" is a baseline explanation of lisp-level
functions that Reduce is built on top of, and eg with reflag what it says
is
REMFLAG{(\p{U}:{eval, spread}
Removes the flag V from the property list of each member of the list
U. Both V and all the elements of U must be ids or the type mismatch
error will occur.
which may or may not enlighten you just now! But primer.pdf and
insidereduce.pdf are attempts to help bridge the gap so that people can
see how higher level features and algebraic operations are built out of
operations on data structures.
Then all the main bits of Reduce source line in packages/<packagename>
in files with suffice ".red", so for instance excalc stuff is in
packages/excalc, where you find the current about 4000 lines that do all
that stuff. Obviously the code there calls on many many internal Reduce
functions from elsewhere in the system - for instance it may call "addsq"
to form the sum of two formulae that are at that stage stored in a
representation that Reduce calls a "standard form". But since you will
know what transformations it will be doing for you when you invoke it
there is a significant chance that you could make sense of it at a high
level after not too much effort reading one of the primers.</packagename>
When an operation becomes sufficiently important or commonly used a hook
so that a special keyword to do it from the user level gets put in,
and then somebody has to add that to the documentation that is aready
bulky enough that one can hardly be certain that people will find what
they are looking for!
The overall history of much of Reduce is that each package starts by
providing the facilities that its author or authors needed for their own
work or expected people in their field to need. Extras get put in when
a need is seen and the balance beteen demand and available time allows.
And MANY of the packages have arisen when somebody wishes to push their
particular area beyond the current capabilities, and they discover that
adding new features is not as terrifing as they first feared. The primers
are there to help people get started down that path. Those who are able
to contribute useful extensions can then be granted write-access to the
repository - and maybe by virtue of what they have learned they can join
in supporting others less far along the path.
The packages//.tst files are things provided by package authors to show
off or test some of what their code can do. I tends to view them as
another part of the explanation (ie documentation).
In the excalc case it maybe that the excalc.tst suggests that "remfdomain"
was viewed as important enough to be made user visible but that removing
the covariantness was going to be less command and
remflag('(u), 'covariant);
was so concise it would suffice and having a
uncovariant u;
statement would be overkill?
Hoep this helps - and apologies if it is a bit long. But I hope that some
of what is being said will be relevant in other cases regarding other
packages in the future.
Arthur
Hi Arthur,
Thank you for your response!
Daniel Volinski