Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2007 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(73) 
_{Sep}
(57) 
_{Oct}
(138) 
_{Nov}
(91) 
_{Dec}
(99) 

2008 
_{Jan}
(91) 
_{Feb}
(53) 
_{Mar}
(37) 
_{Apr}
(125) 
_{May}
(176) 
_{Jun}
(23) 
_{Jul}
(135) 
_{Aug}
(119) 
_{Sep}
(26) 
_{Oct}
(38) 
_{Nov}
(46) 
_{Dec}
(11) 
2009 
_{Jan}
(4) 
_{Feb}
(2) 
_{Mar}
(5) 
_{Apr}
(15) 
_{May}
(4) 
_{Jun}
(18) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(17) 
_{Oct}
(9) 
_{Nov}
(14) 
_{Dec}
(11) 
2010 
_{Jan}
(9) 
_{Feb}
(6) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}
(4) 
_{Jun}
(3) 
_{Jul}

_{Aug}
(10) 
_{Sep}
(7) 
_{Oct}
(7) 
_{Nov}
(36) 
_{Dec}
(23) 
2011 
_{Jan}
(2) 
_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(11) 
_{May}
(5) 
_{Jun}
(17) 
_{Jul}
(2) 
_{Aug}
(26) 
_{Sep}
(14) 
_{Oct}
(51) 
_{Nov}
(39) 
_{Dec}
(7) 
2012 
_{Jan}
(24) 
_{Feb}
(7) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(9) 
_{Jun}
(7) 
_{Jul}
(3) 
_{Aug}
(1) 
_{Sep}
(8) 
_{Oct}
(12) 
_{Nov}
(1) 
_{Dec}

2013 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(35) 
_{May}
(28) 
_{Jun}
(14) 
_{Jul}
(10) 
_{Aug}
(3) 
_{Sep}
(6) 
_{Oct}

_{Nov}
(1) 
_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(4) 
_{May}
(3) 
_{Jun}
(2) 
_{Jul}
(2) 
_{Aug}
(2) 
_{Sep}
(1) 
_{Oct}
(3) 
_{Nov}
(5) 
_{Dec}
(8) 
2015 
_{Jan}
(3) 
_{Feb}
(2) 
_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(1) 
2016 
_{Jan}
(5) 
_{Feb}
(10) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(5) 
2017 
_{Jan}
(2) 
_{Feb}
(2) 
_{Mar}
(5) 
_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2

3

4

5

6
(2) 
7
(6) 
8

9

10
(2) 
11
(13) 
12
(5) 
13
(17) 
14
(15) 
15
(27) 
16
(33) 
17
(12) 
18
(1) 
19

20

21

22
(7) 
23
(1) 
24
(5) 
25
(10) 
26
(1) 
27

28
(4) 
29
(8) 
30
(4) 
31
(3) 
From: Ralf Hemmecke <ralf@he...>  20080531 16:55:39

src/interp/ax.boot contains the function makeAxExportForm(filename, constructors) == $defaultFlag : local := false $literals := [] axForms := [modemapToAx(modemap) for cname in constructors  (modemap:=GETDATABASE(cname,'CONSTRUCTORMODEMAP)) and (not cname in '(Tuple Exit Type)) and not isDefaultPackageName cname] if $baseForms then axForms := [:$baseForms, :axForms] if $defaultFlag then axForms := [['Foreign, ['Declare, 'dummyDefault, 'Exit], 'Lisp], :axForms] axForms := APPEND(axDoLiterals(), axForms) axForm := ['Sequence, _ ['Import, [], 'AxiomLib], ['Import, [], 'Boolean], :axForms] axForm Can someone more clearly explain what its output format is? Ralf PS: Why is there a parameter "filename" if it is not used in the function? (Well I don't understand boot, so that may be a stupid question.) 
From: Bill Page <bill.page@ne...>  20080531 15:18:56

On Sat, May 31, 2008 at 7:14 AM, Francois Maltey wrote: > ... > I'd prefer a syntax close from other CAS. > > Do you think I can write a "interface" Domain for this purpose ? > or must theses functions be in the axiom kernel ? > Addition forms of the 'draw' operator should best be added here: src/algebra/draw.spad.pamphlet It should be simple to include a version to allows plotting of lists of functions. Regards, Bill Page. 
From: Francois Maltey <fmaltey@ne...>  20080531 11:14:21

The Bill draws command is very pretty. > You could try something like this: > > draws(s,p,t) == ... > > draws([sin(x)^2, cos x], x=3..3, title=="Example 2") > Interal functions for drawing with axiom can plot very nice graphs. You can run /src/input/graphics.input. I test an *.input for for plotting field solutions (x(t),y(t)) about ODE with RungeKutta 4 method. The final plot is right. I'd prefer a syntax close from other CAS. Do you think I can write a "interface" Domain for this purpose ? or must theses functions be in the axiom kernel ? FranÃ§ois 
From: Bill Page <bill.page@ne...>  20080530 13:39:45

On Fri, May 30, 2008 at 7:01 AM, Ralf Hemmecke wrote: > > Can somebody explain how the code below can compile with SPAD. > Is SubsetCategory a builtin thing? > There is only one spad file, namely fraction.spad, which contains that > identifier. > Yes, it is builtin to SPAD. See: interp/cutil.boot: domain is only used for SubsetCategory resolution. interp/cutil.boot: form' is ["SubsetCategory",cat,dom] => interp/compiler.boot:compSubsetCategory: (%Form,%Mode,%Env) > %Maybe %Triple interp/compiler.boot:compSubsetCategory(["SubsetCategory",cat,R],m,e) == interp/compiler.boot: ["SubsetCategory", :"compSubsetCategory"],_ interp/define.boot: c is ['SubsetCategory,c',.] => c' interp/hashcode.boot: following two lines correct bad coSig properties due to SubsetCategory interp/mark.boot: ["SubsetCategory", :"compSubsetCategory"],_ interp/nrunopt.boot: v is ["SubsetCategory",cat,d] => extendsCategory(dom,u,cat) and isSubset(dom,d,$e) interp/sysconstants.boot: SubsetCategory _ and comments therein. E.g. compSubsetCategory(["SubsetCategory",cat,R],m,e) == 1. put "Subsets" property on R to allow directly coercion to subset;  allow automatic coercion from subset to R but not vice versa e:= put(R,"Subsets",[[$lhsOfColon,"isFalse"]],e) 2. give the subset domain modemaps of cat plus 3 new functions There is also the 'SubDomain' builtin which is similarly used in only one algebra file: algebra/integer.spad.pamphlet Regards, Bill Page. 
From: Ralf Hemmecke <ralf@he...>  20080530 11:02:02

Can somebody explain how the code below can compile with SPAD. Is SubsetCategory a builtin thing? There is only one spad file, namely fraction.spad, which contains that identifier. Ralf LocalAlgebra(A: Algebra R, R: CommutativeRing, S: SubsetCategory(Monoid, R)): Algebra R with if A has OrderedRing then OrderedRing _/ : (%,S) > % ++ x / d divides the element x by d. _/ : (A,S) > % ++ a / d divides the element \spad{a} by d. numer: % > A ++ numer x returns the numerator of x. denom: % > S ++ denom x returns the denominator of x. == Localize(A, R, S) add 1 == 1$A / 1$S x:% * y:% == (numer(x) * numer(y)) / (denom(x) * denom(y)) characteristic() == characteristic()$A 
From: Gabriel Dos Reis <gdr@in...>  20080530 05:19:44

> And I'm waiting about functions : what are the type/domain of functions > > f (x) == 2*x > g(x:Integer) : Integer==3*x > > h := x +> 4*x  an anonymous function > k: Integer > Integer := x +>5*x  not yet possible... I believe I fixed this some time ago, and I also thin the fix propagated to FriCAS. At any rate, I cannot reproduce a failure. Do you have more complicated examples where it fails?  Gaby 
From: Gabriel Dos Reis <gdr@in...>  20080530 05:15:32

On Wed, May 28, 2008 at 8:29 PM, Bill Page <bill.page@...> wrote: > Gaby, e. al. > > Although the type system of OpenAxiom has some improvements over Axiom > and FriCAS, I still find some of the fundamentals confusing (or > confused :) > > I would be very interested in your opinions on the following claims > and questions. Which of these are true "by definition" and which might > represent conceptual problems or bugs? What fundamental type > constructions am I missing? > > 1) Categories and domains are types. All types satisfy the category > 'Type' , i.e. > > x has Type > > is true for any domain X or category X, including: > > Type has Type true by definition. Note: this includes packages too. > > 2) Domains satisfy categories only by assertion, e.g. > > Integer():Join(IntegerNumberSystem, ...) >  > Integer has IntegerNumberSystem > true by definition. > 3) It is possible to construct domains that contain types > > x:List Type := [SetCategory,BasicType] True in OpenAxiom. You'll see buggy output for List Type, but not for List Category or List Domain. Fixing that requires clarifying along the lines of questions you are asking plus proper handling of types. This can be confusing in a system where we are trying hard to confuse everything :) > > 4) 'Void' is a domain that satisfies no categories except 'Type' > > Void has Type I would *think* that this is true by definition. > > 5) Objects /1 are members of 'Domains' > > 1$Integer true by definition. Domains are the types that provide representation for object, and an object can belong to exactly one domain. In some object oriented languages, this would correspond to the notion of `dynamic type'. > > 6) In the interpreter the type (domain) of variables can be declared > > x:Integer true by definition. > > 7) Categories can be passed as arguments > > f(x:Type):Integer == 1 > f(SetCategory) OpenAxiom wants to do this  and I think there already is basic support for that. > > 8) But at the present time the type of a variable cannot be a category > > x:Type := SetCategory This is a restriction of the original axiom system. I would like to remove it. That however poses some interesting problems for compilation. If we do only interpretation then I do not foresee any difficult problem. However, when we do compilation, it becomes tricky because we don't have types that oversees categories so we basically don't know how to typecheck them for compilation purposes, especially if they are used to describe domains. > > 9) Is 'Category' the domain of all categories Category is the category of all domains and packages. There are things that do not belong to Category. An example is Mode. Note that, although )show Category would report that it is a domain constructor, from the abstract semantics point of view, it is not a domain. > > )show Category > x:Category := Categoy > f(x:Category):Integer == 1 > f(Integer) > > 10) or is 'Category' a category? > > Category has Category > f(x:Category):Integer == 1 > f(SetCategory) > x:List Category := [SetCategory,BasicType] this is well formed in OpenAxiom. > > 11) 'Domain' is the domain of all domains. > > x:Domain := Domain This is correct. > > 12) The existence of the domain 'Domain' makes is possible for > functions in the interpreter to return domainvalues > > MyType(x:Integer):Domain == (x>0 => Float; Integer) > i:MyType(0) this is correct. > > 13) And to construct domains whose members are domains > > x:List Domain := [Integer,Float] this is correct. > > Ref: >  > > 1) Axiom Book > > 2) Aldor User's Guide > > 3) The file 'algebra/coerce.spad.pamphlet' contains the following definitions: > > )abbrev category TYPE Type > ++ The new fundamental Type (keeping Object for 1.5 as well) > ++ Author: Richard Jenks > ++ Date Created: 14 May 1992 > ++ Date Last Updated: 14 May 1992 > ++ Description: The fundamental Type; > Type(): Category == with nil > > 4) The file 'algebra/domain.spad.pamphlet' contains these definitions: > > )abbrev domain CATEGORY Category > ++ Author: Gabriel Dos Reis > ++ Date Create: February 16, 2008. > ++ Date Last Updated: February 16, 2008. > ++ Basic Operations: coerce > ... > > )abbrev domain DOMAIN Domain > ++ Author: Gabriel Dos Reis > ++ Date Create: October 18, 2007. > ++ Date Last Updated: January 19, 2008. > ++ Basic Operations: coerce, reify > ... > >  > > 1/ In a couple of places in the documentation reference is made to an > 'Object' type as well, but no definition of this type seems to remain > in the source. In some version of the system (a long time ago), there was a category called Object. It never existed in the open source version.  Gaby 
From: Bill Page <bill.page@ne...>  20080529 21:20:49

Results in following bug: (1) > X:Integer:=1 (1) 1 Type: Integer (2) > )display value X >> System error: getConstructorKindDB is invalid as a function. (2) > )version Value = "Thursday May 29, 2008 at 17:07:23 "  Patch: bash3.00$ svn diff Index: isyscmd.boot ===================================================================  isyscmd.boot (revision 619) +++ isyscmd.boot (working copy) @@ 1111,7 +1111,7 @@ STRCONC('"Value of ", PNAME $op,'": ") labmode := prefix2String objMode(u) if ATOM labmode then labmode := [labmode]  getConstructorKindDB expr = "domain" => + getConstructorKindFromDB expr = "domain" => sayMSG concat('" ",label,labmode,rhs,form2String expr) mathprint ['CONCAT,label,:labmode,rhs, outputFormat(expr,objMode(u))]  Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@in...>  20080529 16:31:11

On Thu, May 29, 2008 at 10:56 AM, Aleksej Saushev <asau@...> wrote: > "Gabriel Dos Reis" <gdr@...> writes: > >> On Sun, May 18, 2008 at 2:43 PM, Aleksej Saushev <asau@...> wrote: >> >>> This scheme actually is problematic. We need tarballs or other >>> reliable forms of distribution (like ZIP archives), so that we >>> could have reliable cryptographic sums. VCS access is problematic. >> >> OpenAxiom has regular tarballs for its releases. >> >> http://www.openaxiom.org/download.html >> >> The latest release is OpenAxiom1.1.0  following on the >> openaxiom1.1.0 link should >> lead you to the SF download area. > > I know. It doesn't build. > If you want detailed report, let me know, I'll provide one. yes, please; that would be very helpful  as I consider any build failure as a bug, by default. Thanks!  Gaby 
From: Bill Page <bill.page@ne...>  20080529 16:03:13

Francois, Thank you for reading and considering this list. To some people this exercise may seem a little pointless  being concerned with mostly "abstract nonesense" as opposed to "real" programming problems. But I think the situation is rather similar here to category theory in mathematics: It seems that if we could just get these fundamentals correct (e.g. the axioms of category theory), then we can be confident that a very large part of mathematics can then be consistently and accurately expressed in this language. On Thu, May 29, 2008 at 7:59 AM, Francois Maltey wrote: > Bill Page wrote : >> 1) Categories and domains are types. >> 2) Domains satisfy categories only by assertion, >> 3) It is possible to construct domains that contain types >> 4) 'Void' is a domain that satisfies no categories except 'Type' >> 5) Objects /1 are members of 'Domains' >> 6) In the interpreter the type (domain) of variables can be declared >> 7) Categories can be passed as arguments >> 8) But at the present time the type of a variable cannot be a category >> 9) Is 'Category' the domain of all categories >> 10) or is 'Category' a category? >> > For 6) and 1) I never see x:CategoryXX := ... > So it seems that variable has ONE value in ONE domain > Yes, variables in the interpreter are "domainvalued". Categories are not a source of "values" as such. Rather we say that some domain "satisfies" some category, e.g. Integer has IntegerNumberSystem True Float has IntegerNumberSystem False But we also have Integer has Ring True Integer has AbelianGroup True etc. This not the same as saying that: "Integer *is* an IntegerNumberSystem" in the same sense as when we say: "1 is an Integer". Categories are logical statements  sometimes called "contracts", or interfaces or perhaps, abstract algebras. Maybe a bit like PROPS as discussed here: http://golem.ph.utexas.edu/category/2008/05/theorems_into_coffee_iii.html On the other hand Integer is a Domain, in the same sense as 1 is an Integer,so we can write: x:Domain := Integer and even x:Domain := Domain i.e. Domain is a Domain. In the compiler however when we write: )abbrev domain COMPLEX Complex Complex(R:CommutativeRing): ComplexCategory(R) with if R has OpenMath then OpenMath == add Rep := Record(real:R, imag:R) ... R does play a role like a variable. The intention is that one can write x:Complex X only if X has CommutativeRing The set of domains that satisfy some categoy {x for x in Domain  x has SomeCategory} is a kind of subset (subdomain?) of Domain. I think the interpreter could treat categories this way. > x :=Integer claims that Integer is a member of a domain : Domains. > x : Domains := Integer > Yes. > x :Category:= ThisCategory means that Category is also a domain. > I proposed above that in this context a category should denote a subdomain of Domain, i.e. those domains that satisfy the category. > I feel that no axiom can hold any category. A category adds functions to > an "object". > In the compiler categories are used to specify exports. Because the concept of "satisfaction" is defined (in part) in terms of the operations exported by a domain, I think this difference in usage remains consistent. > And I'm waiting about functions : what are the type/domain of functions > The domain of a function is called 'Mapping'. > f (x) == 2*x This is not a function  it is a "mode". In a given context it can be compiled into a function. The underlying domains of the mapping will be inferred. > g(x:Integer) : Integer==3*x > The domain of g is Integer > Integer which is also written Mapping(Integer,Integer) > h := x +> 4*x  an anonymous function > k: Integer > Integer := x +>5*x  not yet possible... > This works for me: (1) > k: Integer > Integer := x +>5*x ; (DEFUN *1;anonymousFunction;1;frame1392;internal ...) is being compiled. ;; The variable *1;anonymousFunction;1;frame1392;internal;MV is undefined. ;; The compiler will assume this variable is a global. (1) theMap(*1;anonymousFunction;1;frame1392;internal) Type: (Integer > Integer) (2) > k(3) (2) 15 Type: PositiveInteger > Last related question : > > Imagine I want to have rewrite functions over every trigonometric > expressions, not only Expression Integer, nor Expression > DomainXXX, but over all sort of expressions. > Becareful! 'Expression Integer' means rational functions (a ratio of polynomials) with Integer coefficients, defined recursively over a large set of additional kernels. Do not confuse this with the general concept of a general "expression". > The place of this rewrite/expand/combine function is in > TrigonometricFunctionCategory (see trigcat.spad file). > I disagree. This category only specifies the trigometric functions, not manipulations of trigonometric expressions. )abbrev category TRIGCAT TrigonometricFunctionCategory ++ Description: Category for the trigonometric functions; TrigonometricFunctionCategory(): Category == with cos: $ > $ ++ cos(x) returns the cosine of x. cot: $ > $ ++ cot(x) returns the cotangent of x. csc: $ > $ ++ csc(x) returns the cosecant of x. sec: $ > $ ++ sec(x) returns the secant of x. sin: $ > $ ++ sin(x) returns the sine of x. tan: $ > $ ++ tan(x) returns the tangent of x. add if $ has Ring then csc x == (a := recip(sin x)) case "failed" => error "csc: no reciprocal" a::$ sec x == (a := recip(cos x)) case "failed" => error "sec: no reciprocal" a::$ tan x == sin x * sec x cot x == cos x * csc x > In this case I must be able to pick up the x in sin x, and play with > this x even if I don't know the domain of x... This is what the definitions of 'csc', 'sec', 'tan' and 'cot' do above. They only require that the domain of x has Ring. But I do not think that is what you have in mind. > > How is it possible ? > I have 2 examples in mind. > How can I expand (sin (3*x)) ? > > and how can I expand (exp (a+%i*b)) in exp a * (cos b + %i * sin b). Manipulating expressions is a completely different problem then the definition of various trigonometric functions. Probably the right place for this would be in a package like TRIGMNIP (TrigonometricManipulations). > In this last case I must be able to recognize the domain : > Expression Complex Integer or Expression XXXX Complex YYYYYYY, as > Expression Fraction Complex Integer and Expression Complex Fraction > Integer or others. > Even if you do not allow Complex coefficients in the rational functions, that does not imply that the expressions are realvalued. For example, I can write: (1) > sin(sqrt(1)*x+1) ++ (1) sin(x\ 1 + 1) Type: Expression Integer Currently there is no symbolic domain in panAxiom where symbols like 'x' are restricted to values from a given domain. If I write: n:Integer then I cannot write sin(2*%pi*n) The best I can do is: (1) > n:Union(Variable n,Integer) Type: Void (2) > sin(2*%pi*n) (2) sin(2n %pi) Type: Expression Integer But then in (2) n is treated like any other Symbol. See: http://axiomwiki.newsynthesis.org/SandBoxSymbolic for some more musings about this issue. Regards, Bill Page. 
From: Ralf Hemmecke <ralf@he...>  20080529 13:09:32

On 05/29/2008 02:48 PM, Francois Maltey wrote: > Ralf wrote : > > >> In this last case I must be able to recognize the domain : > >> Expression Complex Integer or Expression XXXX Complex YYYYYYY, as > >> Expression Fraction Complex Integer and Expression Complex Fraction > >> Integer or others. > > > What does "Expression(X)" actually tell you? Why the X at all? > > Is the imaginary i an element of Expression(Integer)? > This is the question. > I want to code functions for expressions which depend if %i is in the > domain or not. > If I code it in expr.spad I write inside Domain Expression (R) ... > > if R has imaginary:()>R and conjugate:()>R > then > expand x == > a function which separates real and imaginary parts. > exp (1+%i*%pi/7) = exp 1 * (cos (%pi/7) + %i * sin (%pi/7)) > else > expand x == expands terms in (nx) to x+x+x+x...+x and a+b That is wrong by design as you have seen by my previous example. Think yourself about an expression. Isn't that simply a tree of nodes? If you rething that in terms of "Expression(X)", where does the type X come in in that tree? Nowhere. The X is, in fact, an implementation detail. In some situations it is clever, but using Expression(X) everywhere actually says that you like to compute without types. So why do you use Axiom? > I hope I can explain what perplexity I feel in this example. Just look at the implementation of Expression(X) and see what it really does. An expression in Axiom is not a tree. Search for "Rep :=". Ralf 
From: Francois Maltey <fmaltey@ne...>  20080529 12:48:13

Ralf wrote : >> In this last case I must be able to recognize the domain : >> Expression Complex Integer or Expression XXXX Complex YYYYYYY, as >> Expression Fraction Complex Integer and Expression Complex Fraction >> Integer or others. > What does "Expression(X)" actually tell you? Why the X at all? > Is the imaginary i an element of Expression(Integer)? This is the question. I want to code functions for expressions which depend if %i is in the domain or not. If I code it in expr.spad I write inside Domain Expression (R) ... if R has imaginary:()>R and conjugate:()>R then expand x == a function which separates real and imaginary parts. exp (1+%i*%pi/7) = exp 1 * (cos (%pi/7) + %i * sin (%pi/7)) else expand x == expands terms in (nx) to x+x+x+x...+x and a+b Trigonometric functions are described in the trigcat.spad file. and expand/rewrite/combine are related to theses functions, So [a part of] the code might be in this category trigcat.spad. but in this category I can't get any information about type of x in sin x. The paradox is : trigonometric transforms can't be code in the category trigcat. Methods of expand/rewrite/combine are free of representation, but must(?) be code in the domain Expression not in the category. I hope I can explain what perplexity I feel in this example. F. 
From: Ralf Hemmecke <ralf@he...>  20080529 12:18:03

> In this last case I must be able to recognize the domain : > Expression Complex Integer or Expression XXXX Complex YYYYYYY, as > Expression Fraction Complex Integer and Expression Complex Fraction > Integer or others. What does "Expression(X)" actually tell you? Why the X at all? Is the imaginary i an element of Expression(Integer)? Ralf (1) > a: Expression(Integer) := sqrt(1) ++ (1) \ 1 Type: Expression Integer (2) > b: Expression(Integer) := %i There are 1 exposed and 0 unexposed library operations named complex having 2 argument(s) but none was determined to be applicable. Use HyperDoc Browse, or issue )display op complex to learn more about the available operations. Perhaps packagecalling the operation or using coercions on the arguments will allow you to apply the operation. Cannot find a definition or applicable library operation named complex with argument type(s) NonNegativeInteger PositiveInteger Perhaps you should use "@" to indicate the required return type, or "$" to specify which version of the function you need. (2) > c: Complex Integer := %i (2) %i Type: Complex Integer (3) > b:=c::Expression(Integer) Cannot convert from type Complex Integer to Expression Integer for value %i 
From: Francois Maltey <fmaltey@ne...>  20080529 11:59:07

Bill Page wrote : > 1) Categories and domains are types. > 2) Domains satisfy categories only by assertion, > 3) It is possible to construct domains that contain types > 4) 'Void' is a domain that satisfies no categories except 'Type' > 5) Objects /1 are members of 'Domains' > 6) In the interpreter the type (domain) of variables can be declared > 7) Categories can be passed as arguments > 8) But at the present time the type of a variable cannot be a category > 9) Is 'Category' the domain of all categories > 10) or is 'Category' a category? > For 6) and 1) I never see x:CategoryXX := ... So it seems that variable has ONE value in ONE domain x :=Integer claims that Integer is a member of a domain : Domains. x : Domains := Integer x :Category:= ThisCategory means that Category is also a domain. I feel that no axiom can hold any category. A category adds functions to an "object". And I'm waiting about functions : what are the type/domain of functions f (x) == 2*x g(x:Integer) : Integer==3*x h := x +> 4*x  an anonymous function k: Integer > Integer := x +>5*x  not yet possible... Last related question : Imagine I want to have rewrite functions over every trigonometric expressions, not only Expression Integer, nor Expression DomainXXX, but over all sort of expressions. The place of this rewrite/expand/combine function is in TrigonometricFunctionCategory (see trigcat.spad file). In this case I must be able to pick up the x in sin x, and play with this x even if I don't know the domain of x... How is it possible ? I have 2 examples in mind. How can I expand (sin (3*x)) ? and how can I expand (exp (a+%i*b)) in exp a * (cos b + %i * sin b). In this last case I must be able to recognize the domain : Expression Complex Integer or Expression XXXX Complex YYYYYYY, as Expression Fraction Complex Integer and Expression Complex Fraction Integer or others. Have a nice day ! F. 
From: Bill Page <bill.page@ne...>  20080529 01:29:00

Gaby, e. al. Although the type system of OpenAxiom has some improvements over Axiom and FriCAS, I still find some of the fundamentals confusing (or confused :) I would be very interested in your opinions on the following claims and questions. Which of these are true "by definition" and which might represent conceptual problems or bugs? What fundamental type constructions am I missing? 1) Categories and domains are types. All types satisfy the category 'Type' , i.e. x has Type is true for any domain X or category X, including: Type has Type 2) Domains satisfy categories only by assertion, e.g. Integer():Join(IntegerNumberSystem, ...)  Integer has IntegerNumberSystem 3) It is possible to construct domains that contain types x:List Type := [SetCategory,BasicType] 4) 'Void' is a domain that satisfies no categories except 'Type' Void has Type 5) Objects /1 are members of 'Domains' 1$Integer 6) In the interpreter the type (domain) of variables can be declared x:Integer 7) Categories can be passed as arguments f(x:Type):Integer == 1 f(SetCategory) 8) But at the present time the type of a variable cannot be a category x:Type := SetCategory 9) Is 'Category' the domain of all categories )show Category x:Category := Categoy f(x:Category):Integer == 1 f(Integer) 10) or is 'Category' a category? Category has Category f(x:Category):Integer == 1 f(SetCategory) x:List Category := [SetCategory,BasicType] 11) 'Domain' is the domain of all domains. x:Domain := Domain 12) The existence of the domain 'Domain' makes is possible for functions in the interpreter to return domainvalues MyType(x:Integer):Domain == (x>0 => Float; Integer) i:MyType(0) 13) And to construct domains whose members are domains x:List Domain := [Integer,Float] Ref:  1) Axiom Book 2) Aldor User's Guide 3) The file 'algebra/coerce.spad.pamphlet' contains the following definitions: )abbrev category TYPE Type ++ The new fundamental Type (keeping Object for 1.5 as well) ++ Author: Richard Jenks ++ Date Created: 14 May 1992 ++ Date Last Updated: 14 May 1992 ++ Description: The fundamental Type; Type(): Category == with nil 4) The file 'algebra/domain.spad.pamphlet' contains these definitions: )abbrev domain CATEGORY Category ++ Author: Gabriel Dos Reis ++ Date Create: February 16, 2008. ++ Date Last Updated: February 16, 2008. ++ Basic Operations: coerce ... )abbrev domain DOMAIN Domain ++ Author: Gabriel Dos Reis ++ Date Create: October 18, 2007. ++ Date Last Updated: January 19, 2008. ++ Basic Operations: coerce, reify ...  1/ In a couple of places in the documentation reference is made to an 'Object' type as well, but no definition of this type seems to remain in the source. Regards, Bill Page. 
From: Ralf Hemmecke <ralf@he...>  20080528 08:14:49

On 05/28/2008 03:43 AM, Gabriel Dos Reis wrote: > Openaxiom1.2.0 now has OrderedSemiGroup  which had been missing > from all flavours of AXIOM, I think. And it still has OrderedMonoid(): Category == Join(OrderedSet, Monoid) i.e., an OrderedMonoid is not (yet) a OrderedSemiGroup. I guess, OrderedMonoid(): Category == Join(OrderedSemiGroup, Monoid) would make more sense. Ralf 
From: Bill Page <bill.page@ne...>  20080528 03:13:29

Dear Axiom Wiki Users and Contributors: Due to popular request ;) and because I decided that I also miss them, I have reimplemented the comment preview and the edit assistant enhancement from the old wiki to the new axiomwiki at: http://axiomwiki.newsynthesis.org Try this on the SandBox page: http://axiomwiki.newsynthesis.org/SandBox You can use 'Preview' before adding a comment to a wiki page to check the page formatting. Cancel it if you decide not to comment. On the 'edit' page you will also see a short table of commonly used codes and constructs. (Don't forget to click 'login' and identify yourself before using 'edit'.) Clicking on the tools displayed at the bottom of the page will insert commonly used text into the edit page. For example, you can enter the Axiom command: (1) > integrate(exp x,x) using about 8 mouse clicks or key strokes as follows: Under the column labeled Axiom click the following widgets: 1) \begin{axiom} 2) sqrt symbol (expands list of functions) 3) exp Press key: 4) x Use mouse or cursor to select the expression: 5) exp x Click 6) integration symbol (expands list of operators) 7) integrate(sin x, x) Press key: 8) x You have now entered a complete Axiom command that will be executed when you click 'Preview' or 'Save'. Please try it. If you have any questions about these wiki features just ask or comment on the Axiom Wiki. Regards, Bill Page. On Mon, Apr 28, 2008 at 2:35 PM, Bill Page wrote: > On Mon, Apr 28, 2008 at 1:37 PM, Ralf Hemmecke wrote: > ... >> And what I also miss... in the previous version of axiomwiki there was >> a short table at the bottom of the editing window that explained in short >> what syntax one should use to edit a page. Where has this gone. >> > > I still have the code for that somewhere. This was a rather complex > customization of the ZWiki page layout that I did not have time to > reimplement during the move. I used to think it was "pretty neat" for > new users but a little "too bulky" for more experienced users. No one > commented on it's absence after the move so I decided to wait. If you > really think we should implement it again, I can look after doing > that. Also missing is the the preview function on the comment box. It > is a similar complex customization to the standard wiki page layout. > ... 
From: Gabriel Dos Reis <gdr@in...>  20080528 01:54:01

On Tue, May 27, 2008 at 8:41 PM, Bill Page <bill.page@...> wrote: > Gaby, > > When building rev: 614 on a nonwindows machine (Debian) with no X > libraries installed I got the following build error: > > ... > ../../libtool mode=compile gcc c o htadd.o g O2 O2 Wall > D_GNU_SOURCE I../../../openaxiomsrc/src/include I../../config > I. ../../../openaxiomsrc/src/hyper/htadd.c > gcc c g O2 O2 Wall D_GNU_SOURCE > I../../../openaxiomsrc/src/include I../../config I. > ../../../openaxiomsrc/src/hyper/htadd.c fPIC DPIC o > .libs/htadd.o > In file included from ../../../openaxiomsrc/src/hyper/htadd.c:52: > ../../../openaxiomsrc/src/hyper/node.h:53: error: syntax error > before 'openaxiom_window' > ../../../openaxiomsrc/src/hyper/node.h:53: warning: type defaults to > 'int' in declaration of 'openaxiom_window' > ../../../openaxiomsrc/src/hyper/node.h:53: warning: data definition > has no type or storage class > ../../../openaxiomsrc/src/hyper/node.h:54: error: syntax error > before 'openaxiom_pixmap' > ... > > It is apparently something to do with the (missing?) definition of HANDLE. You are right. Before that revision, we used to just skip the src/hyper directory when X11 is not available (mainly on windows). But there are programs there such as htadd hat really do not need X11 (as you can now see after the restructure). I failed to consistently follow my own rule: don't test for platforms, instead test for features. So, indeed I tested for features, but I failed with HANDLE. Will be fixed shortly. Thanks!  Gaby > > Regards, > Bill Page. > >  > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > openaxiomdevel mailing list > openaxiomdevel@... > https://lists.sourceforge.net/lists/listinfo/openaxiomdevel > 
From: Bill Page <bill.page@ne...>  20080528 01:41:18

Gaby, When building rev: 614 on a nonwindows machine (Debian) with no X libraries installed I got the following build error: ... ../../libtool mode=compile gcc c o htadd.o g O2 O2 Wall D_GNU_SOURCE I../../../openaxiomsrc/src/include I../../config I. ../../../openaxiomsrc/src/hyper/htadd.c gcc c g O2 O2 Wall D_GNU_SOURCE I../../../openaxiomsrc/src/include I../../config I. ../../../openaxiomsrc/src/hyper/htadd.c fPIC DPIC o .libs/htadd.o In file included from ../../../openaxiomsrc/src/hyper/htadd.c:52: ../../../openaxiomsrc/src/hyper/node.h:53: error: syntax error before 'openaxiom_window' ../../../openaxiomsrc/src/hyper/node.h:53: warning: type defaults to 'int' in declaration of 'openaxiom_window' ../../../openaxiomsrc/src/hyper/node.h:53: warning: data definition has no type or storage class ../../../openaxiomsrc/src/hyper/node.h:54: error: syntax error before 'openaxiom_pixmap' ... It is apparently something to do with the (missing?) definition of HANDLE. Regards, Bill Page. 
From: Bill Page <bill.page@ne...>  20080526 05:26:19

On Sun, May 25, 2008 at 5:56 AM, Gabriel Dos Reis wrote: > ... > The fundamental point is that this particular semantics seriously > inhibits code reuse. There is no way to extend a domain. Spad > seems to promote copynpaste as way to add new domains. > That is contrary to established software engineering practice. > > Martin Rubey writes: >  I think, A add B is (currently) only well defined when the value of Rep in A >  and B is the same. (well, at least roughly the same.) >  >  I admit that I do not understand (yet) why >  >  > my `*' was not being picked if I test with R=Integer. Rather the one from >  > IndexedDirectProductAbelianMonoid was being used, yet my coerce to >  > OutputForm was used for printing >  >  I'd like to. > > signature subsumption. > > http://axiomportal.newsynthesis.org/refs/articles/Davenport1984a_new_algebra_system.pdf I think Gaby's answer makes good sense. The only thing that seems missing is that the compiler give some kind of warning that operator subsumption has occurred. Concerning code reuse in SPAD: It seems to me that to a certain extent, the "generic programming" features of SPAD trump the need for extensive code reuse. I think this tends to promote abstraction over reuse. Considering how difficult it sometimes is to use large libraries in C++ and Java, I am inclined to think that this might be a good thing. The Axiom library already presents a large challenge to new users of the system and it only covers a tiny part of all the mathematics that might be of interest. I think reusing code is not so much a problem as making sure that the resulting code remains accessible  especially to the mathematicians. It seems to me that code reuse in SPAD naturally takes a different form than in conventional objectoriented programming languages. There needs to be new constructions in the language (i.e. at the source level) which more fully enable it. As I have said several times before, I believe this depends on implementing a more complete categorical approach ("categorical" in the mathematical sense). Nonetheless, some thought has already been given to this in the current design. For example, it is interesting in Davenport1984 to read about the importance of the concept of SubDomain to operator subsumption  the subject of this thread. Regards, Bill Page. 
From: Gabriel Dos Reis <gdr@cs...>  20080525 20:07:12

Martin Rubey <martin.rubey@...> writes:  Gabriel Dos Reis <gdr@...> writes:   > Martin Rubey <martin.rubey@...> writes:  >  >  Gabriel Dos Reis <gdr@...> writes:  >   >  >  Gaby, after some experiments, I could not find an example where "A add B", A  >  >  and B sharing representation, exports an operation from A instead of from B,  >  >  when the signature is present in both.  >  >  >  > That is basically what my oiriginal example was about   >   >  Sorry, I don't understand. In the example below, the representations differ   >  IndexedDirectProductAbelianGroup(R,S) is (I'd say) different from List  >  Pair(S,R).  >  > No, they have the same layout  would you mind having a look at  > IndexedDirectProductAbelianGroup?   I did. Only, I was thinking of IndexedDirectProductAbelianGroup(R,S) being  different from List Pair(S,R), because I did *not* identify   IndexedDirectProductAbelianGroup(R,S) with Rep in   Term:= Record(k:S,c:A)  Rep:= List Term yeah, a record with at most two elements is a cons  otherwise it is a vector. A Pair is a cons. So we have list of conses.  >  I wonder whether this strange behaviour also occurs when the representations  >  are the same.  >  > I think I said yes in my previous message. Which point point isn't clear?   Maybe I should have said, "when the representations are identical".   But I admit that I didn't notice at first that the representations are, in some  sense, "compatible", and that this could be allowed. It is not just `compatible in some sense': The data representations are the same. Almost all of the algebra  as currently written  depend ciritcally on this identity principle. As ingrained in the `pretend' operator.  Gaby 
From: Martin Rubey <martin.rubey@un...>  20080525 19:42:57

Gabriel Dos Reis <gdr@...> writes: > Martin Rubey <martin.rubey@...> writes: > >  Gabriel Dos Reis <gdr@...> writes: >  >  >  Gaby, after some experiments, I could not find an example where "A add B", A >  >  and B sharing representation, exports an operation from A instead of from B, >  >  when the signature is present in both. >  > >  > That is basically what my oiriginal example was about  >  >  Sorry, I don't understand. In the example below, the representations differ  >  IndexedDirectProductAbelianGroup(R,S) is (I'd say) different from List >  Pair(S,R). > > No, they have the same layout  would you mind having a look at > IndexedDirectProductAbelianGroup? I did. Only, I was thinking of IndexedDirectProductAbelianGroup(R,S) being different from List Pair(S,R), because I did *not* identify IndexedDirectProductAbelianGroup(R,S) with Rep in Term:= Record(k:S,c:A) Rep:= List Term >  I wonder whether this strange behaviour also occurs when the representations >  are the same. > > I think I said yes in my previous message. Which point point isn't clear? Maybe I should have said, "when the representations are identical". But I admit that I didn't notice at first that the representations are, in some sense, "compatible", and that this could be allowed. I'm not sure whether this is good or bad. I find it interesting (I didn't know) that it seems to be allowed in Aldor, and the behaviour is, that in A add B operations defined in B are preferred over operations in A. (page 228 and 229 of the Aldor User Guide). But I did not check all the details. What would interest me most: which "*" is taken in line 50 of the program there? OK, I checked. It takes the one from ModularIntegerNumberRep Martin 
From: Gabriel Dos Reis <gdr@cs...>  20080525 19:12:48

Martin Rubey <martin.rubey@...> writes:  Gabriel Dos Reis <gdr@...> writes:   >  Gaby, after some experiments, I could not find an example where "A add B", A  >  and B sharing representation, exports an operation from A instead of from B,  >  when the signature is present in both.  >  > That is basically what my oiriginal example was about    Sorry, I don't understand. In the example below, the representations differ   IndexedDirectProductAbelianGroup(R,S) is (I'd say) different from List  Pair(S,R). No, they have the same layout  would you mind having a look at IndexedDirectProductAbelianGroup?  I wonder whether this strange behaviour also occurs when the representations  are the same. I think I said yes in my previous message. Which point point isn't clear?  What do you mean with   > you just needed to flip the component to match exact layout. I'm reproducing  > it below   ??? Are you saying that List Pair(S, R) is the same as  IndexedDirectProductAbelianGroup(R,S)? from the representation point of veiw, I believe I emphatically said yes. Would you mind looking at the implementation of IndexedDirectProductAbelianGroup?  Gaby 
From: Martin Rubey <martin.rubey@un...>  20080525 18:56:08

Gabriel Dos Reis <gdr@...> writes: >  Gaby, after some experiments, I could not find an example where "A add B", A >  and B sharing representation, exports an operation from A instead of from B, >  when the signature is present in both. > > That is basically what my oiriginal example was about  Sorry, I don't understand. In the example below, the representations differ  IndexedDirectProductAbelianGroup(R,S) is (I'd say) different from List Pair(S,R). I wonder whether this strange behaviour also occurs when the representations are the same. What do you mean with > you just needed to flip the component to match exact layout. I'm reproducing > it below ??? Are you saying that List Pair(S, R) is the same as IndexedDirectProductAbelianGroup(R,S)? Martin > )sys cat left.spad > )abbrev domain LFREEMOD LeftFreeModule > LeftFreeModule(R: Ring, S: OrderedSet): > Join(LeftModule R, IndexedDirectProductCategory(R,S)) with > linearCombination: List Pair(S,R) > % > == IndexedDirectProductAbelianGroup(R,S) add > Rep == List Pair(S,R) > linearCombination x == > per [u for u in x  second u ~= 0$R ] > if R has EntireRing then > (r: R) * (x: %) == > r = 0$R => 0$% > r = 1$R => x > messagePrint("from LeftFreeModule")$OutputForm > per [pair(first u, r * second u) for u in rep x] > else > (r: R) * (x: %) == > r = 0$R => 0$% > r = 1$R => x > messagePrint("from LeftFreeModule")$OutputForm > per [pair(first u,c) for u in rep x  (c := r *second u) ~= 0$R] > coerce(x: %): OutputForm == > x' := rep x > null x' => 0$R :: OutputForm > res : List OutputForm := nil > for u in reverse x' repeat > second u = 1$R => res := cons(first(u)::OutputForm, res) > res := cons(second(u)::OutputForm * first(u)::OutputForm, res) > reduce("+",res) 
From: Gabriel Dos Reis <gdr@cs...>  20080525 17:50:16

Martin Rubey <martin.rubey@...> writes:  Gabriel Dos Reis <gdr@...> writes:   >  So, my question is: how would you interpret an operation that is inherited from  >  IndexedDirectProductAbelianGroup(R,S), when the representations are  >  incompatible as they are here?  >  > Of course when the data layout are not right, disaster. But, that is beside  > the fundamental point. There are many domains that do not manipulate their  > representations directly.  >  > The fundamental point is that this particular semantics seriously inhibits  > code reuse. There is no way to extend a domain. Spad seems to promote  > copynpaste as way to add new domains. That is contrary to established  > software engineering practice.   Gaby, after some experiments, I could not find an example where "A add B", A  and B sharing representation, exports an operation from A instead of from B,  when the signature is present in both. That is basically what my oiriginal example was about  you just needed to flip the component to match exact layout. I'm reproducing it below )sys cat left.spad )abbrev domain LFREEMOD LeftFreeModule LeftFreeModule(R: Ring, S: OrderedSet): Join(LeftModule R, IndexedDirectProductCategory(R,S)) with linearCombination: List Pair(S,R) > % == IndexedDirectProductAbelianGroup(R,S) add Rep == List Pair(S,R) linearCombination x == per [u for u in x  second u ~= 0$R ] if R has EntireRing then (r: R) * (x: %) == r = 0$R => 0$% r = 1$R => x messagePrint("from LeftFreeModule")$OutputForm per [pair(first u, r * second u) for u in rep x] else (r: R) * (x: %) == r = 0$R => 0$% r = 1$R => x messagePrint("from LeftFreeModule")$OutputForm per [pair(first u,c) for u in rep x  (c := r *second u) ~= 0$R] coerce(x: %): OutputForm == x' := rep x null x' => 0$R :: OutputForm res : List OutputForm := nil for u in reverse x' repeat second u = 1$R => res := cons(first(u)::OutputForm, res) res := cons(second(u)::OutputForm * first(u)::OutputForm, res) reduce("+",res) )co left x := 'x::OrderedVariableList ['x,'y] x := 'y::OrderedVariableList ['x,'y] 2 * linearCombination([pair(x,2), pair(y,3)]) There is no 'from LeftFreeModule' printed out. [...]  In any case, I think that the compiler should complain when the Rep's don't  match. If you read the paper I referenced earlier, you'll see hat both BMT and JHD have (had?) different opinions on this :) But, yes the compiler should warn about differing representations. the problem is that in general, the cmpiler does not have that information. compounded by the heavy uses of `pretend'.  Gaby 