On Fri, Feb 2, 2018 at 5:25 PM, Prof. Dr. Johannes Grabmeier privat
<johan...@grabmeier.net> wrote:
> you are absolutely right, this argument was to quick and unprecise,
> I have to confess - after all, it was R. Wisbauer and myself who
> designed and implemented non-associative structures ages ago in
> 1991 and added recip to MagmaWithUnit (which was called
> MonadWithUnit at that time)
>

Actually, I was aware of that and I although it was "ages ago" I would
like to thank you very much for that work.  It has been very useful to
me on numerous occasions.

> So my remark should better read:
>
> All general functions as leftRecip and rightRecip and associator are 
> superfluous as
> soon as we have an associative structure, also it should not disappear
>

I wonder if you really intended the double-negative in "should not
disappear"? To be consistent with your earlier statement perhaps you
mean that these "superfluous" functions "should disappear".

> I hope, however, you agree with the intentions of my comment.
>

As I understood it, your intention was that these superfluous or
redundant functions should be omitted when providing basic structural
information to the user to make it easier for new users to find
relevant functions.  In principle I am in favor of making things
easier for new users however it worries me that it is precisely those
functions that are needed in order to state the axioms that are part
of the definition of a domain.

Rather than adding something new to the compiler and user interface, I
think it might be more appropriate if the FriCAS library was more
explicit about possibly independent properties such as 'Associative'
and 'Commutative'. FriCAS already has the category 'CommuativeStar'
which propagates to many of the relevant domains but as far as I can
see there is nothing like 'AssociativeStar'. If such categories are
used consistently it might be useful to make the exports of
'MagmaWithUnit' conditional, e.g.

wspage@strix ~/fricas $ git diff | cat
diff --git a/src/algebra/naalgc.spad b/src/algebra/naalgc.spad
index a9209da..6dc8ff9 100644
--- a/src/algebra/naalgc.spad
+++ b/src/algebra/naalgc.spad
@@ -84,15 +84,16 @@ MagmaWithUnit() : Category == Magma with
         ++ inverse of \spad{a},
         ++ or \spad{"failed"} if such an element doesn't exist or cannot
         ++ be determined (see unitsKnown).
-      leftRecip : % -> Union(%,"failed")
-        ++ leftRecip(a) returns an element, which is a left inverse
of \spad{a},
-        ++ or \spad{"failed"} if such an element doesn't exist or cannot
-        ++ be determined (see unitsKnown).
-      rightRecip : % -> Union(%,"failed")
-        ++ rightRecip(a) returns an element, which is a right inverse of
-        ++ \spad{a}, or \spad{"failed"} if such an element doesn't exist
-        ++ or cannot be determined (see unitsKnown).
-    add
+      if not(% has CommutativeStar) then
+        leftRecip : % -> Union(%,"failed")
+          ++ leftRecip(a) returns an element, which is a left inverse
of \spad{a},
+          ++ or \spad{"failed"} if such an element doesn't exist or cannot
+          ++ be determined (see unitsKnown).
+        rightRecip : % -> Union(%,"failed")
+          ++ rightRecip(a) returns an element, which is a right inverse of
+          ++ \spad{a}, or \spad{"failed"} if such an element doesn't exist
+          ++ or cannot be determined (see unitsKnown).
+  add
       import from RepeatedSquaring(%)
       one? x == x = 1
       sample() == 1
@@ -112,6 +113,9 @@ MagmaWithUnit() : Category == Magma with
       recip x ==
           (x = 1) => x
           "failed"
+      if not(% has CommutativeStar) then
+        leftRecip(x) == recip(x)
+        rightRecip(x) == recip(x)

 )abbrev category NASRNG NonAssociativeSemiRng
 ++ Author: Waldek Hebisch

----

Then at least in hyperdoc these functions exports do not appear in
domains like 'Integer' and 'Complex Integer'. For some reason they
still show up in domains like 'Polynomial Integer' although
'Polynomial Integer has CommutativeStar' is evaluated as 'true' in the
interpreter so perhaps the conditional type inference is not quite as
strong as one might like in hyperdoc.  And it seems that the ')show'
command in the interpreter does not attempt to eliminate these
functions from its list.

Or is making these export conditional more than what you had in mind?

Regards,
Bill Page.

-- 
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 post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to