Selected Messages from the Axiom-developer email mailing list - axiom-developer@nongnu.org
are collected as comments here. Content that seems relevant for reference and further discussion here on MathAction will likely be moved to other relevant places on this web site. Other material will usually be deleted. The entire archive of messages from the Axiom-developer mailing list can be found here: http://lists.nongnu.org/mailman/listinfo/axiom-developer On Friday, September 24, 2004 6:14 AM Martin Rubey wrote: > I do believe that it cannot serve as a replacement for the > mailing list. But it does function (in principle) in exactly the same way, don't you agree? In any case, since you and I seem to be the only ones who really care about this right now and there are some technical limitations that make it less than ideal, I think I will take your advice and not link MathAction and the axiom-developer mailing list at this time. In the mean time, provided that one is also subscribed to MathAction, then simply including mathaction@axiom-developer.org in the Cc list will send a copy to the Axiom-developer page on MathAction. If the sender is not subscribed, then currently the ZWiki mailin procedure will ignore the incoming mail. This is configurable security policy. If we wanted we could relax this restriction so that any email sent by anyone to the above address would be automatically archived somewhere on MathAction (attached to wiki page [xxx]? based on [xxx]? in the subject line if present). : > > On the other hand, I do *not* like the idea of having *all* > of axiom-developer copied to mathaction. I cannot really say why, > it is a (probably completely irrational) feeling. Maybe it does > have to do with some sort of privacy. > > There is another important detail: I think it is *very* > important to summarize the discussion from time to time, > and for a "clean" look, I'd like to remove the exchange then. > So, unless the discussion is copied (CC'd) to one of the > mailing lists, it will be lost. > Well, the general idea would be that the axiom-developer
mail list Ok, I have done (I think) the server-side installation of ExternalEditor?. The pencil icon now appears on the upper right of the MathAction menu line. I have never used ExternalEdit? successfully before however I have only tried on Windows and I still get the same error as before about the file failing to open - but I think that this is not too surprizing under Windows... When I get around to it, I will try to see what I am doing wrong - probably some configuration thing needs to change. As I understand it, what you need to do now is to follow the client-side (helper) installation here: http://zope.org/Members/Caseman/ExternalEditor or here: http://zope.org/Members/Caseman/ExternalEditor/install-unix See specific instructions for Konqueror. Let me know how it goes and if you need me to tweak anything else on the server. (Wow, you mean I actually edited this using WORD?) Regards, Bill Page. --------- Martin, On Friday, December 17, 2004 1:36 PM you wrote: > maybe this is the point where we could subscribe axiom-developer > to mathaction, i.e., any time mathaction is changed, a note > is sent to axiom-developer@nongnu.org. Ok, But there is a potential problem. If the mathaction email address is also subscribed to the MathAction wiki - what we really want to do - then that could create a nasty email loop since anything sent to the axiom-developer email list by the MathAction website would be echoed back to MathAction and trigger another outgoing email. It turns out there are some options that I can specify for subscriptions to the axiom-developer list, one of these is to disable echoing of emails to the original sender. This would prevent the loop but it would result in every message to the axiom-developer email list to be duplicated since a posting would be sent to MathAction who would update some webpage on the site and then send the changes to the site subscribers one of which is mathaction on the axiom-developer email list. I have instead choosen to disable all emails to the mathaction address (on permantent vacation :) but the address remains subscribed. So this is what I have set up: - A user with the name Relay from MathAction is subscribed to the axiom-developer email list using the email address mathaction@axiom-developer.org. Email delivery to that address is disabled. (I hope that this does not also disable posting of messages by that address!)
- A user named axiom-developer is subscribed to the MathAction website using the email address axiom-developer@nongnu.org
What I expect to happen: - If a change or comment is made to the MathAction web site by someone, that will generate an email to the subscribers to MathAction, one of which will go to axiom-developer@nongnu.org. It should be recognized by mailman as coming from a subscriber with email address mathaction@axiom-developer.org
- The email from MathAction will in turn be distributed by the email server (mailman) at nongnu.org to all the other subscribers on the axiom-developer email list.
However... I have just made a test change on MathAction. I received a notice of the change at my own email address since I am a subscriber (you must of received it too), but since I am also a subscriber to axiom-developer, I expected to see the notice again a short time later echoed from that list. But so far it has not shown up. Sometimes postings do seem to take a long time, so I will continue to wait. In the meantime I am sending this message to axiom-developer only and I will see which of these messages arrives back in my inbasket first. As Tim always says: There is no such thing as a simple job ... :) Regards, Bill Page. 6501a8c0@asus"> Christophe,
RE: Axiom-developer Re: about axiom documentation --Bill Page, 6501a8c0@asus">Mon, 16 May 2005 20:05:25 -0500 replyOn May 14, 2005 6:19 AM you wrote: Tim asked:Thanks for the info on the french documentation. Can you give me a URL for the docs? http://la.riverotte.free.fr/axiom Thank you very much for preparing this webpage! Tim wrote:Tim wrote: I'm interested in making Axiom more international ... I also think in would be great to have more Axiom material that would be easily accessible to non-English readers on the MathAction/Axiom web site. I would be very pleased if you or your colleagues were interested in helping to develop and maintaining some French language web pages on MathAction. Since MathAction is a wiki, these pages can be created and updated directly by you through your browser. If you (or anyone else reading this list) would like some help getting started, please let me know. Regards, Bill Page. PS. I added a link to your new web page here: http://page.axiom-developer.org/zope/mathaction/AxiomDocumentation The axiom-developer email list on Savannah is operated by`lists.gnu.org` . Apparently there are serious problems with
this list as reported at: http://savannah.nongnu.org
lists.gnu.org delays posted by Beuc, Sat 02/25/06 at 17:33 - 1 reply Due to this problem there have been no emails distributed on the axiom-developer list since Sun 26/02/2006 5:06 PM. Therefore as an experimental interim measure, for at least until the current problems with the axiom-developer email list are resolved, I have copied all of the active axiom-developer email list subscriptions directly to the Axiom Wiki subscriber list. As a result, you are receiving this email and will continue to receive email notices of updates to the Wiki. These are the same notices that you have been receiving via the axiom-developer list. If you want to change your subscription you can do so by clicking
If you have any questions, comments or objections to about this change, please let me know. Replies should be sent to mathaction@axiom-developer.org and will be distributed to the current subscriber list. Thanks. Bill Page. "Bill Page"> [...]? > I don't think there is any essential reason why SemiGroup? and > Monoid could not be implemented in the way you suggest. For > example: > > )abbrev category SGROUP SemiGroup? > SemiGroup?(m:Symbol): Category == SetCategory with > m: (%,%) -> % ++ returns the product of x and y. > associative(m) > > )abbrev category ABELSQ AbelianSemiGroup? > AbelianSemiGroup?(m:Symbol): Category == SemiGroup?(m) with > abelian(m) Yes, there are no theoretical reasons, but there are plenty of practical ones. I think such constructs will make it more difficult for the Interpreter to work since it would not be able look up the appropriate signature from domains that have not been instantiated during the session. Of course, if the Interpreter knows what to instantiate, that won't be a problem. But how will the Interpreter be able to know? Indeed, how is a user to know what symbol was used, say, for the operations? What if the user instantiates Integer with both * and + for the same operations in two instances? Can a compiler or interpreter catch this? If not, it would be a nightmare of bug reports. By allowing renaming of operations (even just all binary operations), the categorical notation for * or + no longer exists and it would be impossible for the Interpreter to search for a suitable signature in a categorical manner --- only on a specific domain by domain (and for instantiated domains only for that matter) basis. I do recognize some limitations for having two monoid categories structured on two different operator notations. For example, there is no commutative monoid with * as the multiplication and these are needed (if one wants to look at the set of monomials in several variables as a multiplicative monoid). However, it is far easier to have say, AbelianAdditiveMonoid? and AbelianMultipicativeMonoid? categories (cf. one AbelianMonoid? where the operator must be "+") than to implement all operators used in algebras as parameters. For CAS to be practical, certain compromises are necessary. I do not question the theorectical advantage of rebuilding all algebra based on properties of operators (there is research in theory of operads which would support such a design) but I doubt their practicality, especially when the notation for the operators can only be known dynamically at run-time. As already well-known, with the current status, all properties of operators are declarative and not verified. There is a certain degree of trust that users know what they are doing. Creating examples that deliberately violate these conventions and implicit assumptions of the system and show the "weakness" or "buggiess" of Axiom (or any other CAS) is not productive. One consequence of these examples is confusion of the real issues: the lack of documentation on the conventions and implicit assumptions, and real bugs. William Replies should be sent to mathaction@axiom-developer.org and will be distributed to the current subscriber list. I sent the above message Curiosities ... to mathaction@axiom-developer.org (not as a reply from this page) and the email ends up on this Wiki page. Not exactly the right place? Apparently, the email has not been distributed either. William William Sit asked:Not exactly the right place? When an email is sent to the email has not been distributed I think it should have been distributed. That seems to be a bug. :( I recall previous tests of this (old ago) that used to work. I will look more closely at the problem. Using the Axiom Wiki subscription mechanism as an interim email
list does seem to have it's limitations - maybe some of these I
can fix. But this problem with emails at the email has not been distributed Ah, I think I know why this might have happened. It is apparently
because you are not registered (using It is apparently because you are not registered (using preferences) as William Sit which is the name associated with your email That is true. The reason is I did not subscribe (which would be the case had I filled in the When an email is sent to mathaction@axiom-developer.org the software looks for a embedded in the subject line. In this case the subject contained axiom-developer so your email ended up as a comment attached to this page. Where would an email end up if prefix to the title is removed? As a way of preventing the use of the wiki as a means of distributing SPAM, If that is the reason, why import the email into a Wiki page at all? Wouldn't it be neater simply to discard the email if the originating email address is not in registered email address list? Thanks a lot for tracking this down. You are doing a fantastic job overall! William Curiosities with Axiom mathematical structures --Gabriel Dos Reis, Thu, 02 Mar 2006 12:59:22 -0600 replyWilliam Sit Bill Page writes: In fact, practicality dictates that the implementations in Axiom/Aldor closely follow the mathematical structures. For example, the only assumption I need to define the power of an element is that its domain has a monoidal structure. From software engineering point of view, Practicality dictates that I should not have to write duplicate codes, one for additive operation, one for multiplicative operation when the underlying mathematical structure is the same. That is the least I expect from a non-mathematically-oriented system. If the system does not let one do that, then the system is practically defective :-) I think such constructs will make it more difficult for the Interpreter to work since it would not be able look up the appropriate signature from domains that have not been instantiated during the session. That depends on the Of course, if the Interpreter knows what to instantiate, that won't be a problem. But how will the Interpreter be able to know? By adequate scoping rules. Indeed, how is a user to know what symbol was used, say, for the operations? What if the user instantiates Integer with both * and + for the same operations in two instances? When both will be in scope. If the user uses Can a compiler or interpreter catch this? Yes, definitely. If not, it would be a nightmare of bug reports. It would be a nightmare only if one takes the rules that a type has a unique algebraic structure. That is both theoretically and practically false. See the examples (+, NN), (*, NN), (NN, max) I gave earlier. By allowing renaming of operations (even just all binary operations), the categorical notation for * or + no longer exists and it would be impossible for the Interpreter to search for a suitable signature in a categorical manner --- only on a specific domain by domain (and for instantiated domains only for that matter) basis. I don't see what "renaming" has to do with this; from what I see, it can only lead to greater confusion. However, passing the operation as a parameter to the structure is a first approximation of a viable solution. I do recognize some limitations for having two monoid categories structured on two different operator notations. For example, there is no commutative monoid with * as the multiplication and these are needed (if one wants to look at the set of monomials in several variables as a multiplicative monoid). However, it is far easier to have say, AbelianAdditiveMonoid? and AbelianMultipicativeMonoid? categories (cf. one AbelianMonoid? where the operator must be "+") than to implement all operators used in algebras as parameters. I beg to differ. Having to write duplicate codes is known to be a nightmare and fruitful source of bugs. It does not really encourage abstractions. I wanted to use Axiom to teach generic programming here, but I'm being forced to walk away from it :-(( How can I convince students of the value of the system when it does not support their knowledge? CAS to be practical, certain compromises are necessary. 100% agreed. However, uniformity and coherence should not be compromised. The current approach does not even support the mathematical or "categorial" approach we would like to recommend. How can we explain the that concepts we clearly and unambiguously explained to the students or engineering cannot translate directly to code in a mathematically-oriented system? How can we convince the engineer that he has to duplicate code, when he knows from practice that it is a source of disaster? I do not question the theorectical advantage of rebuilding all algebra based on properties of operators (there is research in theory of operads which would support such a design) but I doubt their practicality, especially when the notation for the operators can only be known dynamically at run-time. Well, I'm approaching the issue more from a As already well-known, with the current status, all properties of operators are declarative and not verified. My problem is simpler than that. I'm not asking for the definition of the algebraic properties of operators. I'm trying to have a way to convince Axiom/Aldor to support sound software engineering practice. Even better if I can take the standard library as an example. There is a certain degree of trust that users know what they are doing. I understand that. But that issue is different from what mine. Creating examples that deliberately violate these conventions and implicit assumptions of the system and show the "weakness" or "buggiess" of Axiom (or any other CAS) is not productive. if you are talking about the issue I raised, then I believe you profoundly misunderstood it. And claiming it deliberately violates conventions and implicit assumptions of Axiom is very unproductive. I'm deeply disappointed :-(( The issue is this: I'm asking the question as someone interested in (mathematical) software engineering teaching and someone interested in Axiom. One consequence of these examples is confusion of the real issues: the lack of documentation on the conventions and implicit assumptions, and real bugs. I fear you did not see what I was talking about. -- Gaby William Sit asked:Where would an email end up if [Axiom Developer] prefix to the title is removed? That is configurable. Right now it is set to AxiomMail?. BTW. I notice you are using LaTeX markup: $[{\rm page\ name}]$ to avoid having the wiki treat this as a link. That is ok, but keep in mind that like all LaTeX code on the wiki, it is rendered as an image. The preferred method is to write an ! escape character before the [, like this: ![page name] (use just one !) which is displayed as [page name] with no link and no blue ? (which is otherwise used to create new links). On Thursday, March 02, 2006 9:25 PM Doug Stewart asked:where do I get the doyen CD. The DoyenCD is still work in progess by Jose Alfredo Perez and Wilken Rivera who were students of Tim Daly when Tim was still at City College in New York. Details about the Doyen project here: http://wiki.axiom-developer.org/Doyen How it was built here: http://wiki.axiom-developer.org/DoyenCD Latest CD image here: http://alfredo.axiom-developer.org/redhatbuild/pkgs/doyenfc3.iso There are still a few known problems. Check here: http://wiki.axiom-developer.org/IssueTracker I hope you get a chance to download the iso image, burn a CD and try it. I think Jose and Wilken could probably use some encouragement to complete the project! :) When it is ready there are plans to distribute it at several computer algebra oriented conferences and also via CafePress? and/or Lulu. Regards, Bill Page. The following paper contains a very useful summary of the object-oriented and functional programming aspects of Axiom:http://axiom-wiki.newsynthesis.org/public/refs/boulanger1.pdf Object Oriented Method for Axiom. Abstract: Axiom is a very powerful cornputer algebra system which combines two languages paradigms (functional and OOP). Mathematical world is complex and mathematicien use abstraction to design it. This paper presents some aspects of the object oriented developnlent in Axiom. The axiom programming is based on several new tools for object oriented development, it uses two levels of class and some operations such that coerce: retract or convert which permit the type evolution. These notions introduce the concept of multi-view. Size 260.8 kB - File type application/pdf Contributors : Jean-Louis Boulanger, Laboratoire d'Informatique Fondamentale de Lille Universite de Lille 1, 59 655 Villenenve d'ascq Cedex, FRANCE January 1995 On Friday, March 03, 2006 11:26 AM Vanuxem Gr�gory wrote:> ... Gabriel Dos Reis > > > In fact it seems that this problem cannot be properly > > solved with Aldor. There was some discussion on this > > list, too. > > > > The reason is:: > > > > Rng(): Category == Join(AbelianGroup?,SemiGroup?) > > > > would give a problem... > > > What problems?
If there really is a conflict, i.e. if the name of the operation as well as the source and target domains match exactly, in the case of Aldor, you get an error message telling you there is more than one possible selection for the function. Something similar but messier happens in SPAD. We are talking about categories here, so this does not have any effect on the Axiom interpreter. Every function that the interpreter calls in located in some package or domain and if necessary the function can be selected based on the package or domain name. In the interpreter, since it is interactive if you define the same function more than once on the same source and target domains, then the secobd definition simply replaces the first. In the case of Rng it is interesting to see that in fact
it does obtain two different definitions of You can use http://wiki.axiom-developer.org/axiom--test--1/src/algebra/CatdefSpad Regards, Bill Page. Hi Gabe:Gabriel Dos Reis wrote: William Sit In fact, practicality dictates that the implementations in Axiom/Aldor closely follow the mathematical structures. You probably misread my response to Bill. I was saying there are plenty of practical reasons NOT to implement in the way suggested, but no theoretical reasons NOT to implement the goal you suggested, in some way. For example, the only assumption I need to define the power of an element is that its domain has a monoidal structure. From software engineering point of view, Practicality dictates that I should not have to write duplicate codes, one for additive operation, one for multiplicative operation when the underlying mathematical structure is the same. That is the least I expect from a non-mathematically-oriented system. Agreed in theory, not in practice. We should distinguish two issues: (1) derived operations that depend only on the defining operations should be generically implemented and inherited, and (2) how to handle the notations (equivalently, identifiers in computer science terminology) for the defining operations and derived operations. Notations (resp. identifiers) are extremely important in mathematics(resp. computer programming). Mathematics can only progress and make strides when good notations are invented AND agreed to. Examples are the notations for differentiation and integration. A software system that deviates from the universally accepted mathematical notations, even if for the sake of valid ideals, will not be usable and at best be hardly usable. Computer programs can work correctly only if identifiers are scoped correctly and such scoping should be transparent when identifiers are overloaded. The concept of a ring is almost omnipotent in all branches of mathematics, and
the standard notations for the multiplication ( So I hope we need not argue a third issue: (3) maintaining standard notations for the defining operations in common algebraic structures. I think your ideal of avoiding "duplicate codes" (much like the ideal of sharing dll libraries) is misplaced. In order to avoid duplicating code due to the dual use of * and + in the monoid structures, one will have to, as admitted throughout these discussions by everyone, ADD tons of code and in the end making writing software for a ring more difficult, not less. Not only that, I doubt if the experts here could agree to how that additional code should be written, even if everything were started from scratch. I think a proper way to "allow" the kind of identification of underlying mathematical structures that are the same is the concept of "isomorphism". For isomorphisms between two domains in Axiom, this is approximated via facilities called "map". In the ideal world, one should design code that can implement inheritance via isomorphisms. However, it should be emphasized that implementing isomorphisms involves extra code as well as duplicating code, but it will allow flexibility in notations that is the facilitator of all mathematics thinking (and in contrast, it creates a tedious complexity in programming due to the rigidity of computer languages). However, there is a caveat. Isomorphisms between a category specification and an actual domain in that category are meaningless, mathematically speaking. The categorical specification has no default sample domain. So we need a simulated isomorphism mechanism. The parameter passing method is one way to indicate an isomorphism but for more complicated structures, this becomes very clumbersome. We need to figure out a way to indicate isomorphisms that will allow, as did the parameter passing method, multiple isomorphisms involving the same domain (or subdomains) and category constructor. Putting this aside for future discussions, let's concentrate on the interpretation for just a single isomorphism. Let's say in Monoid, I used & for the defining monoid operation. If I want to
form a monoid domain with set Integer and operation #, (Integer, #), I would
have to specify to the compiler an isomorphism. The compiler would have to
execute this isomorphism by replacing each occurrence of Of course, in the cases where the default notations are used, none of the above is necessary and thus using default notations gain efficiency over a new set of notations. Moreover, when the notations are changed, even the properties of the defining operations must be copied to the domain itself. This creates extra search info in the database for the compiler and interpreter. Thus this mechanism "duplicates" code, much like the templates in C++ classes. This mechanism is different from parameter passing in its details but not in essense. The difference is that it emphasizes the role of isomorphisms and suggests a way to retain default notations in the categorical definitions while allowing new notations. The details also highlight some requirements for implementation. As we shall see later, there are more. A similar isomorphism mechanism already exists between two implementations of the same mathematical object where the two data representations of objects in the domains differ. The domains in POLYCAT are nothing but such and are viewed as isomorphic using an extensive set of map facilities (which typically translates by deconstructing a polynomial in one domain and then reconstructing it in the other domain). The different implementations of these domains are not considered duplicated code for the mathematical structure of a polynomial ring, and indeed are essential to the efficient implementation of certain algorithms in polynomial rings. These map facilities need to be updated in case notations for defining operations of the two domains are different. If the system does not let one do that, then the system is practically defective :-) All systems have defects. Be realistic! | I think such constructs will make it more difficult for the | Interpreter to work since it would not be able look up the | appropriate signature from domains that have not been instantiated | during the session. These "look-up" rules are generated precisely by the isomorphisms discussed above. However, to write "natural" mathematical software, we need to adopt the "natural" mathematical notations accepted by the mathematical and scientific community. | Of course, if the Interpreter knows what to instantiate, that won't | be a problem. But how will the Interpreter be able to know? Scoping rules play a small part in the isomorphism mechanism. Scoping rules are needed when the same identifiers (minus the prefixes or info used to aid proper scoping) are used in different contexts (scopes). Isomorphisms (as described above) are needed to inherit properties when corresponding operators (between a domain and its category, or between two domains) have different identifiers (notatiosn) for the defining operations. The Interpreter needs the duplicated code in its database for domains which use a non-standard set of identifiers for the defining operations. The non-standard set of identifiers are distinct from the standard identifiers. Indeed, how is a user to know what symbol was used, say, for the operations? What if the user instantiates Integer with both * and + for the same operations in two instances? I meant using * for multiplication of integer in one instantiation, and using + for multiplication of integer in another instantiation, two notations for the same set and operation. (I am not advocating this! see original message for the context, please). | Can a compiler or interpreter catch this? Really? The two copies of the multiplicative monoid of integers are compiled at
different times and instantiatiated in the SAME interpreter session. Can the
interpreter execute something like 3 | If not, it would be a nightmare of bug reports. Quite the contrary. When a type has a unique algebraic structure (I presume you
meant only default notations for its defining operators are allowed), there is
no ambiguity possible like the 3 There seems to be no good way to solve this multiple inheritance problem.
One way is for the compiler to tag each of the derived operations differently
for each instance of a category constructor, so we can have three different
Another way will be to ask the compiler to create the missing (NN,+).NRLIB and
the other two. Then (NN, +, *, max) will have three imported Needless to add, such automated translation, duplication and insertion are simply not supported currently (see SandBoxMonoid). By allowing renaming of operations (even just all binary operations), the categorical notation for * or + no longer exists and it would be impossible for the Interpreter to search for a suitable signature in a categorical manner --- only on a specific domain by domain (and for instantiated domains only for that matter) basis. Renaming is really setting up an isomophism using the identity map (if the underlying sets are the same set, or the vacuous map if between a category and a domain). This is similar to the renaming of ? to x for the main variable in domains like UP(x, INT). The current renaming mechanism is too simplistic and superficial and in my opinion, is the cause for errors. In your idealized version of a monoid definition, the monoid operation should have no name, like a ?, because it is abstracted. But in any real monoid (domain), the operation must have a name, just like a polynomial in UP needs a name for the main variable (which is passed as a parameter). Without a name categorically, there can be no search categorically. The way the Interpreter currently matches ? in UP(x, INT) can easily be made to say x = y when they are distinct variables: x:=variables (2*x::UP(x,INT)); y:=variables (2*y::UP(y,INT)); t:Boolean:= x=y would return However, passing the operation as a parameter to the structure is a first approximation of a viable solution. The entire I do recognize some limitations for having two monoid categories structured on two different operator notations. For example, there is no commutative monoid with * as the multiplication and these are needed (if one wants to look at the set of monomials in several variables as a multiplicative monoid). However, it is far easier to have say, AbelianAdditiveMonoid? and AbelianMultipicativeMonoid? categories (cf. one AbelianMonoid? where the operator must be "+") than to implement all operators used in algebras as parameters. I said it is far easier, not that it is the correct solution. However, I don't agree duplicated code should be the reason for objection to the easier way out. Code efficiency is the least of our problems. I wanted to use Axiom to teach generic programming here, but I'm being forced to walk away from it :-(( How can I convince students of the value of the system when it does not support their knowledge? Your students should be able to learn the abstract concepts abstractly :-) You can teach them about isomorphisms. Also, tell your students life is always a compromise. CAS to be practical, certain compromises are necessary. The current approach does support, within the limits of the programming language. The Axiom designers are mathematicians and computer scientists and they must have thought about this before deciding on the compromise. Remember, that was in the 1970's and I think their compromise is quite reasonable and have served the community well for over 30 years. Regarding uniformity, I am not totally satisfied with the isomorphism mechanism. For example, the domain that uses a new set of notations "belongs" to the category in a way slightly different from another one that uses the default notations. This non-uniformity may be a problem. But to uniformize would require one to abandon the notion of default notations. Coherence, if I understand what you meant by that, requires confluence in rewriting rules. As far as I know, this property has not been proven with the coercion system. So I don't know how you propose to improve this aspect (Axiom is not coherent at this time). If you think now one can redo Axiom in a better way, we are all for it. What's your priorities? (in other words, when can you start? :-) How can we explain the that concepts we clearly and unambiguously explained to the students or engineering cannot translate directly to code in a mathematically-oriented system? Indeed, computer programming and even mathematics, have their (different degrees of) limitations (google theories by Godel, Turing, and Chaitain). Humans can learn abstraction, the computer cannot. Natural languages do not
express abstractions well (otherwise, we don't need lawyers). It takes a human
being to interpret between the lines to understand abstraction. We How can we convince the engineer that he has to duplicate code, when he knows from practice that it is a source of disaster? (with a million dollars dangling over their heads?) Code duplication is a fact of programming life. The difference is simply whether it is done automatically or manually. If a little bit of manual duplication can be used to avoid a lot of automatic duplications, I'll choose the former, and do it and monitor it VERY CAREFULLY. It is a temporary solution, until better times.
I do not question the theorectical advantage of rebuilding all algebra based on properties of operators (there is research in theory of operads which would support such a design) but I doubt their practicality, especially when the notation for the operators can only be known dynamically at run-time. This is not true. First, you don't mean non-Abelian monoids, you meant not-necessarily Abelian monoids (or simply monoids). An abelian monoid IS also a monoid and hence it will work! (You just need to redefine AbelianMonoid to use * instead of +, showing it is not an inherent weakness of the system but just a matter of notations). Axiom chooses to allow different notations for the monoid operation, to distinguish between the commutative case using the more common + notation. The problem as the system stands is due to the rigidity of the computer programming languages in general, which does not exist in mathematical abstractions. From a practical point of view, the system does not support a direct mapping from design to codes. Well, I doubt any system will ever do, at least not without adding on so much baggage that most will shunt away. Even if the isomorphisms mechanisms (in the sense above) are fully implemented it still will not support the mapping from design to codes because of problems discussed above. In a sense, we want the input and output to be simple and ambiguous, but the computation to be exactly what we have in our mind. And if I cannot directly see the design in the code, how do I know the code reflects the design and my intent. If I have duplicate codes floating around, how do I know for sure that I've fixed the bugs I have identified through testing with some parameters? If I do not have a direct mapping from design to code, how do evolve my software in a sound and controlled manner? Those are practical questions. Sure, these questions exist independent of the problem we are discussing here. Recompiling the world may allow a well-designed system to propagate fixes automatically while regenerating duplicated codes. For manually duplicated code, we have to rely on documentation. As already well-known, with the current status, all properties of operators are declarative and not verified. No, you are not discussing "sound software engineering practice". You are arguing about how to inherit abstract algebraic properties. If all you are arguing is for absolutely avoiding manually duplicating code or maintaining it, I'll say that is not a sound software engineering practice to begin with. Here is a sound principle: Avoid duplication code if you can, but you do what you have to do to make things work (and you better check the code and document it well :-). There is a certain degree of trust that users know what they are doing. Sorry. Nothing personal and that was a general, misplaced, remark. I understand your points. There are many monoid structures in any algebraic object because monoid is a very simple structure. Nothing I said disagrees with your premise that (NN,+), (NN,*), (NN, max) are all abelian monoids. I agree also that currently, you cannot tell Axiom that NN (Integer or even NNI) has all three operations as monoid operators and that is a limitation due to the rigidity of computer languages. To do that, you have to create something like AbelianAdditiveMonoid? (same as AbelianMonoid?), AbelianMultipicativeMonoid?, and AbelianMaxMonoid?, and that, while not entirely satisfactory, does not have the problem discussed earlier. Moreover, the three While manually duplicating this for the most common notations is not a problem, I admit this can generalize and we may have to duplicate a complicated structure in more advanced mathematics. An example would be Set(S), which is a commutative ring (and a Boolean algebra) in two different ways at least. In such case, the current practice would be to declare implictly the properties of a Boolean algebra and use different notations for its operators. Since algebraic properties of operations are only declarative, it is easy enough to state these again. However, Set(S) will not inherit from CommutativeRing? and so Matrix Set(S) will not be a valid type construction. So my objections are not targeted to your proposal to find a way to allow such inheritance. My objection is based on practical difficulties: not only is the modifications proposed (even via isomorphism) very involved, they do not solve all the problems. As far as I know, most standard higher algebraic structures use well-established notations. (In fact, if a mathematical paper deviates significantly from de facto notations, the paper will probably be rejected! Have you seen ANY paper which interchanges the * and + notations in a commutative ring?) This does not mean one cannot form a commutative ring with other operators. To allow such inheritance needs a different yet undiscovered mechanism, one which, like isomorphism, will likely require at least duplication of code, albeit automatically. The issue is this: I hope this long message provides some answers to I'm asking the question as someone interested in (mathematical) software engineering teaching and someone interested in Axiom. Glad to know you. A rare combination. | One consequence of these examples is confusion of the real issues: | the lack of documentation on the conventions and implicit | assumptions, and real bugs. I withdraw that comment, with apology. I fear you did not see what I was talking about. Is this better? (Boy, I'm beginning to feel that I don't know what I was talking about!) William 6900a8c0@asus"> On March 4, 2006 5:46 AM David MENTRE wrote:
MediaWiki? with literate programming --Bill Page, 6900a8c0@asus">Sat, 04 Mar 2006 12:46:23 -0600 reply
For obvious reasons, I think this is a fantastic idea! :) See the link "Scientific computing" ... I hope someone will post some SPAD and Aldor programs to this site. Thanks. Bill Page. Curiosities with Axiom mathematical structures --Ralf Hemmecke, Tue, 07 Mar 2006 04:38:59 -0600 replyOn 03/04/2006 05:31 PM, William Sit wrote: Hi Gabe: Gabriel Dos Reis wrote:Hi Gabe: Gabriel Dos Reis wrote: William Sit Agreed in theory, not in practice. We should distinguish two issues: (1) derived operations that depend only on the defining operations should be generically implemented and inherited, and (2) how to handle the notations (equivalently, identifiers in computer science terminology) for the defining operations and derived operations. By (1) you probably mean to say something like: define PrimitiveType: Category == with { =: (%, %) -> Boolean; ~=: (%, %) -> Boolean; default { (a:%) ~= (b:%):Boolean == ~(a = b); } } I must say that I liked this idea of "default implementations" when I've encountered it. But it also introduces all the complications with multiple inheritance. For example, assume we have: define ContainerType(T: Type): Category == with { bracket: Tuple Type -> %; -- constructor generator: % -> Generator T; -- yields all the elements #: % -> Integer; -- size default { #(x: %): Integer == { n: Integer := 0; for element in x repeat n := n + 1; } return n; } } define FixedArrayType(n: Integer, T: Type): Category == with { ContainerType(T); default {#(x: %): Integer == n;} } Theoretically, there is no difference in the two # functions, but practically, one would prefer the second one for FixedArray?'s since it is a little bit faster. Now, assume I have some other category MyFancyCat that inherits from ContainerType, but not from FixedArrayType. Then I create: define MyFixedCat(n: Integer, T: Type): Category == with { MyFancyCat T; FixedArrayType(n, T); } Of course, MyFixedCat also inherits defaults, but which one? (The current compiler takes the first one.) Changing the order of the categories results in more efficient code. However, think of a second default function that could be implemented in both categories, but the more efficient one in ContainerType. Then you can choose any order for MyFixedCat and get always only one efficient default. When I started with Aldor, I used defaults a lot, but I encountered exactly the above scenario and then removed the defaults in almost all places and shifted it to the actual domains. Default implementations should be used with great care. Computation time is never an issue in mathematics, but one should not (totally) neglect it in computer algebra. Your (2) from above refers to the idea of renaming operators. Currently, apart from the "renaming during inheritance", we are restricted anyway quite a bit. For example, I would like my multiplication sign to look like or . Well, Aldor does not (yet) handle Unicode. But even if it did, I would probably have to disambiguate certain mathematical expressions so that they become Aldor programs. But actually that is another issue: How to write a good user interface (notations) that maps nice looking expressions to the right underlying algorithm. Maple and Mathematica know already quite a bit of such user interfaces. However, they don't have the beauty of types. There is Chapter 9 of Doye's PhD thesis http://axiom-wiki.newsynthesis.org/public/refs/doye-aldor-phd.pdf which deals in part with the renaming. From what I understand, it simply makes two mathematically distinct things (operator symbols and operator names) distinct in the programming language. (Though I don't quite like the syntax.) The concept of a ring is almost omnipotent in all branches of mathematics, and the standard notations for the multiplication ( It would certainly make sense to print "a + a" as "2*a", but how an element of a domain is printed is decided by the domain. If we have: define MyMonoid: Category == with { 1: %; *: (%, %) -> %; power: (%, Integer) -> %; } and (now fancy notation with renaming): define MyTimesPlus: Category == with MyMonoid; MyMonoid where { 0: % == 1; +: (%, %) -> % == +; ntimes: (%, Integer) -> % == power; } } Then MyTimesPlus has 6 different signatures. If one removes the line "ntimes" then it would be only 5 and "power" would correspond to the multiplication (or (more correctly) to the actual implementation of it in a corresponding domain). So, operator symbols and operator names agree as long as they are not renamed. And one could also build: MyInteger1: MyTimesPlus == add { Rep == Integer; 0: % == per 0; 1: % == per 1; ... } MyInteger2: MyTimesPlus == add { Rep == Integer; 0: % == per 1; 1: % == per 0; (x: %) + (y: %): % == per (rep x * rep y); (x: %) * (y: %): % == per (rep x + rep y); ... } Now, clearly, it can easily be figured out what 0, 1, +, etc. mean if MyInteger1 or MyInteger2 is in scope. If both are in scope then nobody can infer what "0 + 1" should return. In fact, constructing implementations like that is also currently possible without renaming. So I hope we need not argue a third issue: (3) maintaining standard notations for the defining operations in common algebraic structures. Hmmm, don't some people use , , , , etc to denote multiplication? ;-) But let's continue with MyInteger1 has MyMonoid then that refers to the multiplicative structure. I have, however, to say: macro MyAdditiveMonoidMacro == { MyMonoid where { 0: % == 1; +: (%, %) -> % == +; ntimes: (%, Integer) -> % == power; } } MyInteger1 has MyAdditiveMonoidMacro So what do I gain by a "renaming feature"? Not much, since now I must add the corresponding "with respect to addition" or create another category. (Isn't that very similar to the case when Monoid and AbelianMonoid are totally unrelated?) In fact, if I now define a new category: define MyAdditiveMonoidCategory == { MyMonoid where { 0: % == 1; +: (%, %) -> % == +; ntimes: (%, Integer) -> % == power; } } and ask: MyInteger1 has MyAdditiveMonoidCategory then this should (and must) return false since MyInteger1 is not explicitly declared to be a member of that category. Ralf Hi Ralf:Ralf Hemmecke wrote: William Sit That is right, but I forgot to point out that the generic implementation may be overriden. I must say that I liked this idea of "default implementations" when I've encountered it. But it also introduces all the complications with multiple inheritance. Yes, a default implementation, because it is more general, may be less
efficient. However, in Axiom, I trust Aldor also, any default implementation can
be overriden by simply defining the same operations in the domain constructor.
So in the example above, the compiler will compile the function Now, assume I have some other category MyFancyCat? that inherits from ContainerType?, but not from FixedArrayType?. Then I createIn case of multiple inheritance, it is the responsibility of the user to choose, not asking the compiler to choose for you (that would be equivalent to asking the Interpreter to coerce and then complain about the result or resulting type). It would be trivial to override (and choose) by something like: default(#: %)->Integer == #$(MyFancyCat? T) ## ordefault(#:% ->Integer == #$FixedArrayType?(n,T) The compiler should not choose this and should flag it as a user error. When I started with Aldor, I used defaults a lot, but I encountered exactly the above scenario and then removed the defaults in almost all places and shifted it to the actual domains. Default implementations should be used with great care. Are you telling me that Aldor does not allow overriding a default implementation? I know Axiom allows. Computation time is never an issue in mathematics, but one should not (totally) neglect it in computer algebra. Well, you need mathematics to prove computation time complexities. Then you let computer programs worry about the details. Your (2) from above refers to the idea of renaming operators. Currently, apart from the "renaming during inheritance", we are restricted anyway quite a bit. For example, I would like my multiplication sign to look like \times or \circ. Well, Aldor does not (yet) handle Unicode. But even if it did, I would probably have to disambiguate certain mathematical expressions so that they become Aldor programs. First of all, it is not I who suggested this renaming. I am opposing it, if anything, as a solution to the problem raised because Axiom did not consider AbelianMonoid? as inherited from Monoid. I think "duplicating code", to some extent, ease the problem, but down the road, it may not be a satisfactory option. How to handle renaming is of course a very difficult problem. The idea, in both mathematics and symbolic computation, to overload operators (symbols) is to reduce the number of different notations when the operators have essentially the same properties. Let's not even discuss the complication that arises when typesetting (which is when \cdot or \times or simply concatenation may be used for the same multiplication). Thus * is commonly used for commutative multiplication and sometimes for noncommutative multiplication as well, + is always for addition, \circ for composition (non-commutative of course), \cdot for matrix product or vector dot product, etc. When an algebraic structure involves more than one kind of multiplication, sometimes mathematicians "abuse" notations by not distinguishing them, like k(yz) could mean a scalar multiplication by k to an algebra product y and z. In computer algebra, this is clearly not allowed because, as I said, computer languages are rigid. So there has to be a proliferation of symbols (operators, function names, etc) to make every operation unique and unambiguous. In CAS, the best that can be done is to retain a small set of symbols commonly used, and then use long function names for others. Overloading helps to hide this proliferation. In choosing this set, we must agree to the properties of each so that + will never be used for non-commutative binary operation. Allowing arbitrary user selected symbols is simply looking for trouble. But actually that is another issue: How to write a good user interface (notations) that maps nice looking expressions to the right underlying algorithm. Maple and Mathematica know already quite a bit of such user interfaces. However, they don't have the beauty of types. I don't see how Maple or Mathematica handle this any better than Axiom. They
still fix properties of commonly used notations (perhaps not in a way that
everyone agrees, but if you use their system, you have to: for example,
Mathematica uses ** for non-commutative multiplication). What Maple and
Mathematica did better for user I/O is in their display technology, not their
input technology. You can type tex expressions like \lambda and it will display
the Greek font for lambda and it is treated just like any other symbol for input
purposes. There is no difference (other than display) if you use the identifier
I believe we were not discussing user interface earlier. We were discussing whether one should be allowed to use arbitrary operators (or functions) for, say the multiplication of a monoid. We are trying to find a way to express the mathematical fact that an abelian monoid is a monoid, despite the difference in notation for the monoid operation. As I pointed out in previous email, the problem is not simply "renaming" (and certainly not I/O) but rather the concept of isomorphism is behind it. There is Chapter 9 of Doye's PhD? thesis http://axiom-wiki.newsynthesis.org/public/refs/doye-aldor-phd.pdf which deals in part with the renaming. Thanks for the pointer. Glad that someone actually thought about this issue already. After glancing Chap. 9 and guessing at the notations from earlier chapters, it seems to me Doye is making each defining operation into an equivalent class, or may be just a set, (\sigma (source target)) where \sigma would be the default and hard coded symbol for the operation, and source and targets are uniquely identifiable as sorted domains. The user can then declare another symbol, say \lambda, to belong to this equivalent class or set, thus changing the notation (renaming the function). So in effect, \lambda is tagged by (\sigma (source target)). This seems to be the reverse of overloading. I'll reserve judgement until I have read the thesis in more details. By the way, I don't follow his example at bottom of p. 127: If \phi is a functor (he said homomorphism, but that is wrong, because a list and a set are from different categories), he wants the equation to hold: \phi(#([1,1]?) = #(\phi([1,1]?)) The right hand side makes sense, with answer 1, but the left hand side does not,
since #([1,1]?) = 2 is a number, not a list. He claimed \phi(2) = 2.
In addition, there is no requirement that a functor commutes with operations. A
functor should, in addition to taking objects (lists) to objects (sets), also
has to take a morphism # Lists --> NNI | | \phi | | id v # v Sets --> NNI But there is no reason to expect this to be a commutative diagram of functors. So I think his example illustrates nothing. It would certainly make sense to print "a + a" as "2*a", but how an element of a domain is printed is decided by the domain. It is more than just "certainly make sense to print". In a ring, a+a IS 2a. The additive group structure is the same as a Z-module structure and hence 2a is the correct way to denote the answer. How it is displayed in a CAS is something else, and my argument is that this answer not only "makes sense", but it "should" be displayed as 2a. If we have Some typo above? should be define MyTimesPlus?: Category == MyMonoid? with { 0: %; +: (%,%); ntimes: (%, INteger?) -> %; default { 0: % == 1; +: (%, %) -> % == *; ntimes: (%, Integer) -> % == power; } } which says a domain of category MyTimesPlus? belongs to the category of MyMonoid? but has three additional objects 0, + and ntimes, and here're the default implementations. Or do you really mean the defaults are compulsory? (If so, then I don't know why in MyInteger1? (and MyInteger2?) below you define 0 (and +). You would be overriding the defaults.) Then MyTimesPlus? has 6 different signatures. If one removes the line "ntimes" then it would be only 5 and "power" would correspond to the multiplication (or (more correctly) to the actual implementation of it in a corresponding domain). Depends. Most likely, MyInteger1? and MyInteger2? would have coercion to and from Integer (to enable input). Unless you type qualify the constants, it is not clear what an interpreter would do. If both are in scope then nobody can infer what "0 + 1" should return. In fact, constructing implementations like that is also currently possible without renaming. No one can tell what "0+1" is unless the 0 and 1 are qualified as to which domain each belongs. You are creating an ambiguous situation deliberately, and so you have to make it unambiguous again by package call (which is in some sense the same as renaming). But what is your point? You know, there is some mathematics behind these constructions, but that is bad mathematics: it may be fun to confuse students to switch the two monoid structures in Integer and even to interchange the notation for 0 and1 and + and *. But no real mathematics is done that way, even if it is "allowed" AND correct! We don't say this is a bug in the mathematical system and we don't view it as a problem at all. So why should computer algebra systems be different? So I hope we need not argue a third issue: (3) maintaining standard notations for the defining operations in common algebraic structures. There are many kinds of multiplication. Sometimes people overload a symbol and sometimes to emphasize the distinction, they use different ones. Very often, these distinctions are unnecessary as they can be deduced from context (by intelligent human). In symbolic computation, that is different. Without detail package call or domain declaration, the computer cannot tell the context. Computer can handle "overloading" so let's use it, and use it in a way in agreement with mathematics when mathematical symbols of operations are used as identifiers. But let's continue with MyInteger1?/2. If I now ask ## Do you mean you have to use the macro to ask:while So what do I gain by a "renaming feature"? Not much, since now I must add the corresponding "with respect to addition" or create another category. (Isn't that very similar to the case when Monoid and AbelianMonoid? are totally unrelated?) I think you just demonstrated the rigidity of computer languages. I believe allowing "user renaming" of functions sets up another level of abstraction that will only cause more confusion and will not solve the problem of multiple inheritance (I may change my mind after reading Doye). The designers of Axiom made a good compromise, even though it does not reflect the true mathematics algebraic hierarchy. One possible improvement (but far from a total solution) is to include inheritance via isomorphisms, but even that is a lot of work. William Curiosities with Axiom mathematical structures --Martin Rubey, Wed, 08 Mar 2006 03:22:48 -0600 replyIn case of multiple inheritance, it is the responsibility of the user to choose, not asking the compiler to choose for you (that would be equivalent to asking the Interpreter to coerce and then complain about the result or resulting type). It would be trivial to override (and choose) by something like:
William, I agree! (in both points) By the way, I don't follow his example at bottom of p. 127: If \phi is a functor (he said homomorphism, but that is wrong, because a list and a set are from different categories), he wants the equation to hold: Thank you for pointing out this. I had the same feeling, but I wasn't sure enough about it. Now it's settled. I think you just demonstrated the rigidity of computer languages. I believe allowing "user renaming" of functions sets up another level of abstraction that will only cause more confusion and will not solve the problem of multiple inheritance (I may change my mind after reading Doye). The designers of Axiom made a good compromise, even though it does not reflect the true mathematics algebraic hierarchy. One possible improvement (but far from a total solution) is to include inheritance via isomorphisms, but even that is a lot of work. Do you mean that passing operations to the categories would be a feasible approach? I.e., being allowed to say something like Monoid(m:(%,%)->%): Category == with square: % -> % add square a == m(a,a) Of course, one would have to rethink this several times, the suggested notation here is clearly not yet perfect. One might object that this notation violates the possibility of creating anonymous categories, but I suspect that this wouldn't make sense anyway. Martin Curiosities with Axiom mathematical structures --Gabriel Dos Reis, Mon, 13 Mar 2006 18:07:12 -0600 replyOn Friday, March 03, 2006 11:26 AM Vanuxem Gr�gory wrote:... A conflict can come only if the scope rules, we decided to ignore that the neutral, inverse (and other associated operations and values) are functions of the monoid parameter. So, as a first approximation, they should work like fields in a Record: Monoid(Integer, +).neutral Monoid(Integer, *).neutral -- Gaby Curiosities with Axiom mathematical structures --Gabriel Dos Reis, Mon, 13 Mar 2006 18:09:59 -0600 reply[...]? Do you mean that passing operations to the categories would be a feasible approach? I.e., being allowed to say something like:Monoid(m:(%,%)->%): Category == with square: % -> % add square a == m(a,a)</blockquote> |

speakerscorner--Bill Page, 6501a8c0@Asus">Fri, 24 Sep 2004 14:59:12 -0500 reply