Bill Page wrote:
>
> 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?
1) Such use of conditionals is unsupported. Essentially only at
runtime we know for sure is condtion is satisfied or not. But
FriCAS needs list of signatures at compile time. To avoid
this problem Spad compiler uses "positive logic with closed
word assumption": is something is known true it is considered
true regardless of possible new information. If something is
not known to be true it is treaded as false. Such logic works
OK if there are no negation, but negation almost immediately
leads to contradictions.
2) Correct version of the above can be obtained by introducing
extra attribute, say TrurlyNonAssociative. However, this
would defeat the purpose of original unification of
associative and nonassociative words: you are supposed to be
able to pass associatieve algebra to an algorithm working
with general algberas. For this associatieve algebra must
have all functions present in nonnonassociative ones,
in particular leftRecip and rightRecip.
3) I am not sure about wisdom of hiding functions. In old days
a lot of folks used simple strategy to learn a new program:
go trough menus or list of functions and look at things
with "promising" names. Now programs got much harder to use:
they hide menu positions and to see them you need to satisfy
precoditions. In other words, to see a function you need to
know where it is and how to use it. Much harder to discover
anything...
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
