Edit detail for Axiom-developer revision 1 of 1
| 1 | ||
|
Editor: page
Time: 2007/11/26 19:33:23 GMT-8 |
||
| Note: transferred from axiom-developer | ||
changed: - 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 *also* be subscribed to the MathAction wiki. But without some careful changes to the ZWiki mailin procedure, this would create a disastrous email loop! Right now we can have mathaction subscribed to axiom-developer *or* axiom- developer subscribed to MathAction but not both. From BillPage Fri Sep 24 14:59:12 -0500 2004 From: Bill Page Date: Fri, 24 Sep 2004 14:59:12 -0500 Subject: speakerscorner Message-ID: <003b01c4a270$f93455d0$6501a8c0@Asus> In-Reply-To: <16724.29018.34160.135098@gargle.gargle.HOWL> Martin, 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, *I think* I have set this up. It was a bit awkward to do it because of the "email reply required" type of authentication that is used by mailman. In order to post a message to axiom- developer the email address of the sender has to be subscribed to the email list. So I first have to subscribe mathaction to axiom-developer. Mailman sends an email to the address that you specify (in this case mathaction@axiom-developer.org) and it expects the receiver of the message to do something to confirm the address. Normally email sent to mathaction@axiom-developer.org will be appended to a page on the MathAction website. To confirm the mathaction email address as a subscriber to axiom-developer I first had to temporily re-direct the mathaction email address on axiom-developer.org to my own email address. Then I could confirm the request and have (apparently) managed to get mathaction subscribed. 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: 1 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!) 2 A user named axiom-developer is subscribed to the MathAction website using the email address axiom-developer@nongnu.org What I expect to happen: 1 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 2 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. From BillPage Mon May 16 20:05:25 -0500 2005 From: Bill Page Date: Mon, 16 May 2005 20:05:25 -0500 Subject: RE: [Axiom-developer] Re: about axiom documentation Message-ID: <000a01c55967$611903a0$6501a8c0@asus> In-Reply-To: <1116065921.8628.34.camel@83.82.146.62> Christophe, On 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? > > I just created a small page with all docs and infos about our work. > You can find them under: http://la.riverotte.free.fr/axiom Thank you very much for preparing this webpage! > 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 From billpage Tue Feb 28 17:23:22 -0600 2006 From: billpage Date: Tue, 28 Feb 2006 17:23:22 -0600 Subject: email problems at lists.gnu.org Message-ID: <20060228172322-0600@wiki.axiom-developer.org> 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 > > lists.gnu.org is being redone from scratch. The Savannah Hackers > are not involved in that process. Work is focused on the new > system rather than the current one. ETA is fall of March. > We'll post additional information here if available. 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 'subscribe' on the top right hand side menu bar of any Axiom Wiki page. 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. From WilliamSit Wed Mar 1 22:55:44 -0600 2006 From: William Sit Date: Wed, 01 Mar 2006 22:55:44 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <44067AE4.35B5B08C@cunyvm.cuny.edu> "Bill Page" <bill.page1@synthesis.anikast.ca> writes: > > [...] > > 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 From wyscc Thu Mar 2 07:39:40 -0600 2006 From: wyscc Date: Thu, 02 Mar 2006 07:39:40 -0600 Subject: emails Message-ID: <20060302073940-0600@wiki.axiom-developer.org> In-Reply-To: <20060228172322-0600@wiki.axiom-developer.org> > Replies should be sent to mathaction@axiom-developer.org and will > be distributed to the current subscriber list. I sent the above message $[{\rm Axiom-developer}]$ 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 From billpage Thu Mar 2 10:00:39 -0600 2006 From: billpage Date: Thu, 02 Mar 2006 10:00:39 -0600 Subject: emails to mathaction Message-ID: <20060302100039-0600@wiki.axiom-developer.org> William Sit asked: > Not exactly the right place? When an email is sent to 'mathaction@axiom-developer.org' the software looks for a $[{\rm page\ name}]$ embedded in the subject line. In this case the subject contained $[{\rm axiom-developer}]$ so your email ended up as a comment attached to this page. > 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 'axiom-developer@nongnu.org' is quite annoying. I hope they fix the problem soon. Otherwise we might want to consider setting up our own email list on the 'axiom-developer.org' server. From billpage Thu Mar 2 10:10:01 -0600 2006 From: billpage Date: Thu, 02 Mar 2006 10:10:01 -0600 Subject: email distributed from mathaction Message-ID: <20060302101001-0600@wiki.axiom-developer.org> William Sit wrote: > 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 'preferences') as 'William Sit' which is the name associated with your email. As a way of preventing the use of the wiki as a means of distributing SPAM, the software checks that the person who is posting the comment is known to the wiki. I need to change this so that the check is based on whether the email address is known rather than the user name. From wyscc Thu Mar 2 11:12:57 -0600 2006 From: wyscc Date: Thu, 02 Mar 2006 11:12:57 -0600 Subject: more on email Message-ID: <20060302111257-0600@wiki.axiom-developer.org> In-Reply-To: <20060302101001-0600@wiki.axiom-developer.org> Bill Page wrote: >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 'Email' in the 'preference' form and I did not want to receive duplicate broadcasts). >When an email is sent to mathaction@axiom-developer.org the software looks for a $[{\rm page-name}]$ 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 $[{\rm axiom-developer}]$ 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 From GabrielDosReis Thu Mar 2 12:59:22 -0600 2006 From: Gabriel Dos Reis Date: Thu, 02 Mar 2006 12:59:22 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <m3hd6g3c5s.fsf@uniton.integrable-solutions.net> In-Reply-To: <44067AE4.35B5B08C@cunyvm.cuny.edu> [ Woaw, I did not anticipate we would have so much fun with what I think is a mistake in Axiom/Aldor :-)] William Sit <wyscc@cunyvm.cuny.edu> writes: > Bill Page writes: > > [...] > > > > 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. 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 *kind of lookup*. For a system where all symbols are global with no proper scoping, then yes that is a problem. But then, if the system is designed to write mathematical software it should have lookup rules that make that possible. Said differently, the system should be designed to serve writing "natural" mathematical software. > 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 * with Integer, the system knows that (*, Int) is a monoidal structure. Same if (+, Int). > 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 *practical* point of view than a theoretical point of view. As the system currently stands, in practice, I cannot simply and clearly write once a generic function for monoidal structures and expect it to work for both for Abelian and non Abelian monoids. From a practical point of view, the system does not support a direct mapping from design to codes. 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. > 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: *why* should one be forced to duplicate codes for an algorithms that work on the same mathematical structure. The question arise from software engineering point of view, in general, and mathematical software in particular (I classified Axiom as a mathematical software). If the reasons for that are not theoretical, I believe we need to improve over the situation. 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 From billpage Thu Mar 2 15:29:48 -0600 2006 From: billpage Date: Thu, 02 Mar 2006 15:29:48 -0600 Subject: where does email end up? Message-ID: <20060302152948-0600@wiki.axiom-developer.org> 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). From Page,Bill Thu Mar 2 20:40:58 -0600 2006 From: Page, Bill Date: Thu, 02 Mar 2006 20:40:58 -0600 Subject: doyen and virtual appliance Message-ID: <CAE9B164E720CE4D8727792DF8F28AE33DE01D@corporateex02.Corporate.drdc-rddc.gc.ca> 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. From Page,Bill Fri Mar 3 05:25:07 -0600 2006 From: Page, Bill Date: Fri, 03 Mar 2006 05:25:07 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <CAE9B164E720CE4D8727792DF8F28AE33DE020@corporateex02.Corporate.drdc-rddc.gc.ca> The following paper contains a very useful summary of the object-oriented and functional programming aspects of Axiom: http://portal.axiom-developer.org/refs/articles/boulanger1.pdf/view 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 From Page,Bill Fri Mar 3 19:25:44 -0600 2006 From: Page, Bill Date: Fri, 03 Mar 2006 19:25:44 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <CAE9B164E720CE4D8727792DF8F28AE33DE0FE@corporateex02.Corporate.drdc-rddc.gc.ca> On Friday, March 03, 2006 11:26 AM Vanuxem Gr�gory wrote: > > ... > > Gabriel Dos Reis <gdr@integrable-solutions.net> writes:: > > > > > 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? > > > > Well, if you inherit an operation, you cannot alter the > > name of the operation. Rng inherits really two different > > monoids, one for addition and one for multiplication. > > > Thus there would be a name conflict... > > Does someone know the compiler and/or the interpreter behavior > (from which category the operation is selected if the categories > define this function ?) in this case ? > 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 '*' from AbelianGroup and SemiGroup. If the former it is multiplation of an element (%) of the domain by an Integer and in the latter it is the product of two elements (%) from the domain. This is not a conflict because the signatures are different. You can use 'tangle' and the selection box to quickly extract the code for 'category RNG Rng', 'category SGROUP SemiGroup' and 'category ABELGRP AbelianGroup' at http://wiki.axiom-developer.org/axiom--test--1/src/algebra/CatdefSpad Regards, Bill Page. From WilliamSit Sat Mar 4 10:30:32 -0600 2006 From: William Sit Date: Sat, 04 Mar 2006 10:30:32 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <4409C0C7.1DF05455@cunyvm.cuny.edu> Hi Gabe: Gabriel Dos Reis wrote: > William Sit <wyscc@cunyvm.cuny.edu> writes: > > Bill Page writes: > > > 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. > 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 (*) and addition (+) are adopted. You may almost forget about that a ring is a monoid wrt to * and an abelion monoid wrt + because what is important to a ring is the two together, how they interact via the distributive laws. A practical way to support the structure of a ring requires these two separate notations. Even in the simple case of your example for repeated operation (which you called "power"), the two operations * and + will produce (and should produce) outputs in two different notations: x^n (power) and n*x (multiple). In this case, the repeated operations in fact occur both in an *abelian* submonoid setting even if multiplication is non-commutative. 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 '&' by '#' in the category definition temporarily before matching the domain signatures with the category signatures. This necessitates that in the category definition of a monoid, and in the domain code of an actual monoid, we can identify and separate the defining operations from the derived operations -- which is currently not the case. Let's assume this is done nonetheless. Then the generic code of derived operations (such as 'square' or 'power'), if available, will have to be translated, duplicated, and inserted in the domain for correct signatures and implementation. Those derived operations that are not generically implemented will be handled like the defining operations except that their identifiers will not be changed. Finally, the properties of the defining operations must also be translated, duplicated and inserted into the domain. The code in the category should be restored afterwards. 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. > > That depends on the *kind of lookup*. For a system where all symbols > are global with no proper scoping, then yes that is a problem. But > then, if the system is designed to write mathematical software it > should have lookup rules that make that possible. Said differently, > the system should be designed to serve writing "natural" mathematical > software. 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? > > By adequate scoping rules. 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? > > When both will be in scope. If the user uses * with Integer, the > system knows that (*, Int) is a monoidal structure. Same if > (+, Int). 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? > > Yes, definitely. 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*4+5 correctly and give 60 (without package calls)? What if we have two copies of the ring of integers where in one the notations for * and + are interchanged? When this sort of arbitrary notations is allowed, every function call need to be a package call or else it would be a nightmare to explain all the "strange" answers. (The isomorphism mechanism does not seem to solve this problem). > | 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. 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*4+5 above. I don't disagree this state is non-optimal, but the proposed state has its problems. Your examples show three *different* binary operations with three *different* identifiers. If you want to inherit say the function 'square' for each, you need to, as explained above, establish three isomorphisms to the fictitious domain % in the categorical definition and translate, duplicate, and insert 'square' in each domain so that the Interpreter can find the translated defining operations and their properties, or else you have to package call because the Interpreter has no way to tell when you write 'square(5)' to which of the three monoids 5 would be in. It would be all the more of a problem when all the three monoid structures co-exist in the *same* domain (multiple inheritance). Notice that while the domain (NN, +, *, max) exists, the domains (NN, +), (NN, *), and (NN, max) are transiently constructed during compilation only! There is no (NN, +).NRLIB for example. Besides, you can only have ONE signature 'square: % -> %' in the domain (NN, +, *, max), not three. This possibly is an important reasons why !AbelianMonoid does not descend from Monoid. 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 'square', each replaced by a different identifier. But clearly, not only will this destroy the very desirable overloading of operators, it will also destroy the membership of the domain in the monoid category in each case. 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 'square' functions and each will have to be package called. Not a big deal, yet. However, there is then the danger of first too many NRLIBs and second there will be need for multiple copies of (NN, +).NRLIB, one for each time (NN, +) becomes a subdomain, and since the + may mean different operations (it is only an identifier, not a distinguished identifier), each will in turn need to be tagged by their superdomain! That will quickly become a nightmare. 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. > > I don't see what "renaming" has to do with this; from what I see, it > can only lead to greater confusion. 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 'true'. > However, passing the operation as a parameter to the structure is a > first approximation of a viable solution. The entire 'with' clause in constructors is to pass operations as parameters. But their identifiers cannot be changed! (see SandBoxMonoid). It is not how to specify an isomorphism that is the problem, it is how the compiler will interpret and act on that specification that is the problem. > > 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 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. > > 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. 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 *understand* abstractions by making jumps in our logic system (the brain). > 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. > > Well, I'm approaching the issue more from a *practical* point of view > than a theoretical point of view. As the system currently stands, in > practice, I cannot simply and clearly write once a generic function > for monoidal structures and expect it to work for both for Abelian and > non Abelian monoids. 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. > > 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. 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. > > 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 :-(( 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 'square' functions would produce x^2, 2*x, and x and the three 'power' functions produce x^n, n*x, and x. Clearly, in (NN, max), the 'square' and 'power' functions are superfluous, but this automatic application of the monoid construction will not simplify them. In AbelianMonoid, the 'square' function is simply not removed. So there are some simplification possibilities when a categorical constructor is duplicated in cases with special properties. 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: *why* should one be forced to duplicate codes for > an algorithms that work on the same mathematical structure. The > question arise from software engineering point of view, in general, > and mathematical software in particular (I classified Axiom as a > mathematical software). If the reasons for that are not theoretical, > I believe we need to improve over the situation. I hope this long message provides some answers to *why*. But duplicating code is not the main problem. The reasons are technical in nature, not theoretical. They include the role identifiers play in inheritance, in multiple inheritance, subdomains, the "un-overloading" of overloaded operators, and to some extent, in scoping and the proliferation of libraries, as well as complexity in calling sequences. > 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 From BillPage Sat Mar 4 12:46:23 -0600 2006 From: Bill Page Date: Sat, 04 Mar 2006 12:46:23 -0600 Subject: MediaWiki with literate programming Message-ID: <023201c63fbb$db9706a0$6900a8c0@asus> In-Reply-To: <87veuucwtn.fsf@linux-france.org> On March 4, 2006 5:46 AM David MENTRE wrote: > > Somebody pointed me to: > http://literateprograms.org/LiteratePrograms:Welcome > > This web site has adapted MediaWiki (the wiki engine behind > Wikipedia) to present literate programs in a wiki way and to > allow online edition. The infrastructure is based on noweb. > > It might be a source of inspiration and/or code for Axiom. > 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. From RalfHemmecke Tue Mar 7 04:38:59 -0600 2006 From: Ralf Hemmecke Date: Tue, 07 Mar 2006 04:38:59 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <440D1BA8.6060109@risc.uni-linz.ac.at> In-Reply-To: <4409C0C7.1DF05455@cunyvm.cuny.edu> Dear William, On 03/04/2006 05:31 PM, William Sit wrote: > Hi Gabe: > Gabriel Dos Reis wrote: >> William Sit <wyscc@cunyvm.cuny.edu> writes: > 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 $\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. 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://portal.axiom-developer.org/refs/articles/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 (*) and addition (+) are adopted. > You may almost forget about that a ring is a monoid wrt to * and an abelion > monoid wrt + because what is important to a ring is the two together, how they > interact via the distributive laws. A practical way to support the structure of > a ring requires these two separate notations. Even in the simple case of your > example for repeated operation (which you called "power"), the two operations * > and + will produce (and should produce) outputs in two different notations: x^n > (power) and n*x (multiple). In this case, the repeated operations in fact occur > both in an *abelian* submonoid setting even if multiplication is > non-commutative. 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 $\cdot$, $\times$, $\circ$, $\odot$, etc to denote multiplication? ;-) But let's continue with 'MyInteger1/2'. If I now ask:: 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 From WilliamSit Tue Mar 7 13:52:31 -0600 2006 From: William Sit Date: Tue, 07 Mar 2006 13:52:31 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <440DE468.3E6126DE@cunyvm.cuny.edu> Hi Ralf: Ralf Hemmecke wrote: > >> William Sit <wyscc@cunyvm.cuny.edu> writes: > > > 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); } > } 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. > > 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. 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 '#' for 'FixedArrayType' using the simpler code. > 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. > In 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) or default(#:% ->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 'lambda' instead. The palettes that allow you to enter nice looking expression as input are really mouse-click functions that display one thing and enter something else to the kernel. 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://portal.axiom-developer.org/refs/articles/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.) 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 *between* source objects (lists) to another morphism *between* the image objects (sets). The map '#' is not a morphism in the category of Lists, nor of Sets. If one must, then '#' is a functor from the category of Lists (and also for Sets) to the category whose objects are non-negative integers. But the composition of functors \phi \circ # does not make sense. What Doye has in mind is the following diagram: # 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 > > 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; > } > } Some typo above? should be '+: (%,%)->% == *' ? I am not following your syntax for MyTimesPlus either (why use "where"?) Parethesis not balanced also. I thought you meant: 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). > > 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. 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. > > Hmmm, don't some people use \cdot, \times, \circ, \odot, etc to denote > multiplication? ;-) 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 > > 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 Do you mean you have to use the macro to ask: MyInteger1 has MyTimesPlus while 'MyInteger1 has MyMonoid' works? > 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 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 From MartinRubey Wed Mar 8 03:22:48 -0600 2006 From: Martin Rubey Date: Wed, 08 Mar 2006 03:22:48 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <85k6b55m11.fsf@localhost.localdomain> In-Reply-To: <440DE468.3E6126DE@cunyvm.cuny.edu> William Sit <wyscc@cunyvm.cuny.edu> writes: > In 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) > > or > > default(#:% ->Integer == #$FixedArrayType(n,T) > > The compiler should not choose this and should flag it as a user error. 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: > > \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 *between* source objects (lists) to another morphism > *between* the image objects (sets). The map '#' is not a morphism in the > category of Lists, nor of Sets. If one must, then '#' is a functor from the > category of Lists (and also for Sets) to the category whose objects are > non-negative integers. But the composition of functors \phi \circ # does not > make sense. What Doye has in mind is the following diagram: > > # > 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. 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 From GabrielDosReis Mon Mar 13 18:07:12 -0600 2006 From: Gabriel Dos Reis Date: Mon, 13 Mar 2006 18:07:12 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <m3wtexopnd.fsf@uniton.integrable-solutions.net> In-Reply-To: <CAE9B164E720CE4D8727792DF8F28AE33DE0FE@corporateex02.Corporate.drdc-rddc.gc.ca> Bill Page writes: > On Friday, March 03, 2006 11:26 AM Vanuxem Gr�gory wrote: > > > ... > > > > > > Well, if you inherit an operation, you cannot alter the > > > name of the operation. Rng inherits really two different > > > monoids, one for addition and one for multiplication. > > > > > Thus there would be a name conflict... > > > > Does someone know the compiler and/or the interpreter behavior > > (from which category the operation is selected if the categories > > define this function ?) in this case ? > > > > 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. 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 From GabrielDosReis Mon Mar 13 18:09:59 -0600 2006 From: Gabriel Dos Reis Date: Mon, 13 Mar 2006 18:09:59 -0600 Subject: Curiosities with Axiom mathematical structures Message-ID: <m3r755opio.fsf@uniton.integrable-solutions.net> In-Reply-To: <85k6b55m11.fsf@localhost.localdomain> Martin Rubey writes: [...] > 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) if we wanted this to work, we should make sure that "square" is not automatically exported to the "global scope". By default it should be accessible/visible only through field member access syntax, e.g.:: Monoid(+).square Of course, one can devise an abbreviation, or aliasing mechanism when the context is unambiguous. -- Gaby
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 also be subscribed to the MathAction wiki. But without some careful changes to the ZWiki mailin procedure, this would create a disastrous email loop! Right now we can have mathaction subscribed to axiom-developer or axiom- developer subscribed to MathAction but not both.
6501a8c0@Asus">speakerscorner --Bill Page, 6501a8c0@Asus">Fri, 24 Sep 2004 14:59:12 -0500 reply
Martin,
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, I think I have set this up. It was a bit awkward to do it because of the "email reply required" type of authentication that is used by mailman. In order to post a message to axiom- developer the email address of the sender has to be subscribed to the email list. So I first have to subscribe mathaction to axiom-developer. Mailman sends an email to the address that you specify (in this case mathaction@axiom-developer.org) and it expects the receiver of the message to do something to confirm the address. Normally email sent to mathaction@axiom-developer.org will be appended to a page on the MathAction website. To confirm the mathaction email address as a subscriber to axiom-developer I first had to temporily re-direct the mathaction email address on axiom-developer.org to my own email address. Then I could confirm the request and have (apparently) managed to get mathaction subscribed.
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">RE: Axiom-developer Re: about axiom documentation --Bill Page, 6501a8c0@asus">Mon, 16 May 2005 20:05:25 -0500 reply
Christophe,
On 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?I just created a small page with all docs and infos about our work. You can find them under:
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 bylists.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 replylists.gnu.org is being redone from scratch. The Savannah Hackers are not involved in that process. Work is focused on the new system rather than the current one. ETA is fall of March. We'll post additional information here if available.
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
subscribe on the top right hand side menu bar of any Axiom Wiki
page.
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 mathaction@axiom-developer.org the software
looks for a 
embedded in the subject line. In this case the
subject contained 
so your email ended up as a comment
attached to this page.
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 axiom-developer@nongnu.org
is quite annoying. I hope they fix the problem soon. Otherwise we
might want to consider setting up our own email list on the
axiom-developer.org server.
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 preferences) as William Sit
which is the name associated with your email. As a way of preventing
the use of the wiki as a means of distributing SPAM, the software
checks that the person who is posting the comment is known to the
wiki. I need to change this so that the check is based on whether
the email address is known rather than the user name.
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 Email in the preference form and I did not want to receive duplicate broadcasts).
When an email is sent to mathaction@axiom-developer.org the software looks for aembedded 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