On Sun, Feb 09, 2025 at 02:20:54PM +0000, Martin Baker wrote:
> On 09/02/2025 12:58, Waldek Hebisch wrote:
> > To say the truth, before trying to fix the functions one should ask
> > if this code is ever used? Function in categories are only used via
> > inheritance to domains. If a domain provides its own representation,
> > then it probably also provides all functions depeneding on representation
> > (doing otherwise risks bugs when code changes). So possibly
> > simplest fix would just remove the problematic code.
>
> Well I often get thrown by the differences between SPAD categories and
> say Java interfaces so the code may well be sub optimal.
I have no deep knowledge of Java, but I do not think there are big
conceptual differences between Spad categories and Java interfaces.
Spad category lists signatures (functions) that should be available
in all domains declared to belong to given category. Implementation
part of category gives default implementation. IIUC the same thing
holds in Java: interface specifies functions and may give default
implementation. Spad categories can do a bit more. In Spad there
are parameters. In old Java there were no parameters (later Java
added generics which probably changed that). If you want analogy
with other languages, Spad parametrized domains and categories
are similar to C++ templates (there are also differences). But
this difference is in a sense not essential: to use a domain you
plug in values for parameters. So you may think of parameters as
a shortcut way to define many similar categories or domains.
In practice it would be possible to use say macros to expand
single parametized source into several variants (parameters are
more flexible than this, but there is little paractical difference).
OTOH you may be confused by Spad terminology. At least your
usage is less usual compared to other parts of FriCAS.
Namely, a domain of category Group is a _single_ group.
AFAICS your domain FinitePoset(S) is intended to be a domain of
all finite posets withe elements form S. In other words, domain
of category Poset(S) is actually a set of posets (with elements
from S), not a single poset. But once this is stated explicitely,
there should be no confusion.
Concerning confusion: IIUC the intent is to deal with posets
having elements from S. So natural functions would be
for example:
addArrow! : (%, S, S)
++ addArrow!(p, a, b) adds to p arrow from a to b
Actually, I mentioned this function because it appears close to
start of list of functions. However, such signature actually
promises more than a poset: it promises mutable poset. This
difference is significant for two reasons. One, most mathematical
objects in FriCAS are immutable, and without immutably normal
mathematical reasoning does not work (intead one needs to work
with states and consider how assignment changes state before
into state after). Second, bulk operations on posets may be
more efficient if result is not modified after creation
(for example most operations would be faster if you used
array as representation, but adding nodes forces use of
flexible arrays and we currently only have one dimensional
flexible arrays).
Anyway, coming back to signature above, instead of elements of
S you have integer indices. So anybody using your domain must
deal with integers. So really, from point of view of a user
this is poset on subset of integers and relation to S is
somewhat fuzzy.
Coming back to basics: notion of poset is rather fundamental and
having operations on posets is desirable. There is natural
connection to graphs. But it is undesirable to force essentially
presentational aspects on _all_ posets. Rather, I would expect
mathematical Poset and separate say PosetVisualisation to handle
presentational aspects.
> So feel free to do whatever you want with IsArrow?
Well, from the above you can see that I would write rather different
categories and domains that you did. But I do not want to break
what works, so I will probably do only minimal changes.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to fricas-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/Z6kKLd0EgOSG5iHK%40fricas.org.
