Re: [fricas-devel] DirectProduct?
Ralf, Here is a test example: (1) - )sys cat test-coerce1.input -- test-coerce1.input )cl co R:=Integer F:=Fraction R M:=SquareMatrix(2,F) m:M:=[[1,1],[1,1]] f:F:=1 r:R:=1 f*m r*m -- )cl co R:=Polynomial Integer F:=Fraction R M:=SquareMatrix(2,F) m:M:=[[1,1],[1,1]] f:F:=1 r:R:=1 f*m r*m -- (1) - )r test-coerce1.input -- test-coerce1.input )cl co All user variables and function definitions have been cleared. All )browse facility databases have been cleared. Internally cached functions and constructors have been cleared. )clear completely is finished. R:=Integer (1) Integer Type: Type F:=Fraction R (2) Fraction Integer Type: Type M:=SquareMatrix(2,F) (3) SquareMatrix(2,Fraction Integer) Type: Type m:M:=[[1,1],[1,1]] +1 1+ (4) || +1 1+ Type: SquareMatrix(2,Fraction Integer) f:F:=1 (5) 1 Type: Fraction Integer r:R:=1 (6) 1 Type: Integer f*m +1 1+ (7) || +1 1+ Type: SquareMatrix(2,Fraction Integer) r*m +1 1+ (8) || +1 1+ Type: SquareMatrix(2,Fraction Integer) -- )cl co All user variables and function definitions have been cleared. All )browse facility databases have been cleared. Internally cached functions and constructors have been cleared. )clear completely is finished. R:=Polynomial Integer (1) Polynomial Integer Type: Type F:=Fraction R (2) Fraction Polynomial Integer Type: Type M:=SquareMatrix(2,F) (3) SquareMatrix(2,Fraction Polynomial Integer) Type: Type m:M:=[[1,1],[1,1]] +1 1+ (4) || +1 1+ Type: SquareMatrix(2,Fraction Polynomial Integer) f:F:=1 (5) 1 Type: Fraction Polynomial Integer r:R:=1 (6) 1 Type: Polynomial Integer f*m +1 1+ (7) || +1 1+ Type: SquareMatrix(2,Fraction Polynomial Integer) r*m (8) [2,2] Type: DirectProduct(2,Fraction Polynomial Integer) (9) - Why is this 2nd result for (8) not of the same form as the first result for (8)? The only difference is R:=Polynomial Integer instead of R:=Integer Regards, Bill Page. On Fri, Jun 11, 2010 at 9:05 AM, Bill Page bill.p...@newsynthesis.org wrote: Ralf, No. I asked why *: (R, SquareMatrix(2, F) - something is easy when R = Integer. But it is not easy when R = Polynomial(Complex Integer))? Regards, Bill Page. On Fri, Jun 11, 2010 at 2:04 AM, Ralf Hemmecke r...@hemmecke.de wrote: But note, my question was about looking for an appropriate operation * (or rather an appropriate coercion) so that R and SquareMatrix(2,Fraction R) can be connected. Why is there no automatic coercion when R = Polynomial(Complex Integer))? Is this some limitation of Fraction? Oh, that's easy. Then for F = Fraction(R) I ask for a multiplication *: (F, SquareMatrix(2, F) - something And the probably easiest * that can be found, is the one from BiModule(F, F). Best regards Ralf -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] DirectProduct?
Ralf, What does the following have to do with Monoid? On Thu, Jun 10, 2010 at 1:06 PM, Ralf Hemmecke r...@hemmecke.de wrote: On 06/10/2010 06:33 PM, Bill Page wrote: Ralf, I think that the map coerce : Fraction Polynomial Complex Integer - % which is apparently x+- [x,x] in )sh DirectProduct(2,Fraction Polynomial Complex Integer) should not be called a coercion. From DirectProduct ... if R has Monoid then 1 == new(dim, 1)$Vector(R) pretend % u : % * r : R == map(x +- x*r, u) r : R * u : % == map(x +- r*x, u) x:% * y:% == [x.i * y.i for i in 1..dim]$Vector(R) pretend % That makes sense. Well... automatic coercion cannot always be right. There is such a thing as being too automatic - especially when the results are unintuitive and of limited utility. Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] DirectProduct?
Ralf, In another thread Gaby observed that for a Field F SquareMatrix(n,F) should satisfy VectorSpace(F), but unfortunately at present it does not: (1) - SquareMatrix(2,Fraction Integer) has VectorSpace(Fraction Integer) (1) false Or perhaps even better if every SquareMatrix(n,R) satisfied Module(R). If it did, then I think the question of coercion would be moot. Regards, Bill Page. On Thu, Jun 10, 2010 at 2:05 PM, Ralf Hemmecke r...@hemmecke.de wrote: On 06/10/2010 07:17 PM, Bill Page wrote: Ralf, What does the following have to do with Monoid? On Thu, Jun 10, 2010 at 1:06 PM, Ralf Hemmecke r...@hemmecke.de wrote: On 06/10/2010 06:33 PM, Bill Page wrote: Ralf, I think that the map coerce : Fraction Polynomial Complex Integer - % which is apparently x+- [x,x] in )sh DirectProduct(2,Fraction Polynomial Complex Integer) should not be called a coercion. If R is a Monoid then DirectProduct(2,R) is and the natural 1 in this monoid is (1,1) since the multiplication is component-wise. So x - [x,x] looks like quite a natural lift. No? As I said, automatic choice of the coercion without giving a hint that there are also other options is the problem. I'd rather like my first example to fail with an error message that there is an ambiguity instead of returning me an unwanted DirectProduct. If it fails, and gives me the possible sigatures, I know that I have (for example) to specify the return type more precisely. Without any hint and just being left with DirectProduct, I guess any user will be confused. I consider this a bug in the sense of leaving the user clueless. Well, you all know my (non-)preference of automatic coercion. ;-) Ralf -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] multiple values vs records as return values
On Wed, Jun 9, 2010 at 4:15 PM, Ralf Hemmecke r...@hemmecke.de wrote: You've certainly tested the speed of your new implementation, but what surprises me is that creating a record on the heap does not to be so time consuming than I thought. Or is FriCAS managing the return value of times2 on the stack? Well, ATM FriCAS does not optimize such return values. BTW, I guess that is the reason why Aldor has multiple values. http://www.aldor.org/docs/HTML/chap6.html#1 I don't know exactly whether multiple values are passed via the stack, but why else would one want to have them in such a language like Aldor? Everything could have been modelled by Cross. +1 I think everything (multiple values) *should* be modeled by Cross. A notation like f: (A,B,C) - (D,E) where there is no danger of confusing it with the notation of a tuple should be considered just a short form of f: CROSS(A,B,C) - CROSS(D,E) There could be a similar short notation for UNION perhaps using [A, B, C] where again A, B, and C are Types and there is no danger of confusion with a list, Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] support for bundled gcl in configure?
On Mon, Mar 22, 2010 at 4:21 PM, Waldek Hebisch wrote: ... Note: this is about reomoving support for building gcl inside FriCAS build tree. Building FriCAS using already installed gcl giving --with-lisp option should work as before. Anybody opposed this idea? +1 Good idea! -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] Hypercomplex numbers
Rather than lying or expecting the system prove that x^2+1 is irreducible in R I think the usual approach in Axiom would be to introduce a declaration in the algebra library to this effect, i.e. introduce a new category such as Irreducible(x^2+1,R). On Fri, Mar 19, 2010 at 3:31 AM, Ralf Hemmecke r...@hemmecke.de wrote: I think that to understand Waldek's point it is import to look at ComplexCategory. if R has Field then -- this is a lie; we must know that Field -- x^2+1 is irreducible in R Exactly. If we want to do mathematics, why do you distribute lies? Unfortunately, we probably cannot easily change it, but I am much in favour of a consistent algebra library. Ralf -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] Hypercomplex numbers
On Thu, Mar 18, 2010 at 1:53 PM, Martin Baker wrote: ... The problem is that complex numbers are defined over CommutativeRing and even types like this are not valid. (1) - myType:Complex Complex Integer Complex(Complex(Integer)) is not a valid type. (1) - Even if this was accepted as a valid type we would need to be able to define how the product of the two algebras would be calculated, not necessarily direct product but semi-direct product or Cayley-Dickson doubling process. I think the interpreter is being unnecessarily restrictive, perhaps in some attempt at premature optimization of a particular type of complex domain. But this is not really a problem in the FriCAS/Axiom type system. See for example: http://axiom-wiki.newsynthesis.org/MyComplex There would also be practical issues like if the outer Complex uses %i then the inner Complex would need to use %j and so on. I realise that in this case we could just use quaternion but I am interested what the general solution would be. This isn't really necessary. There are other cases like this, for instance Clifford algebras over Clifford algebras? Would I be right in assuming that FriCAS can't do this sort of thing at the moment? I do not think there are any fundamental restrictions. Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] Hypercomplex numbers
On Thu, Mar 18, 2010 at 8:27 PM, Waldek Hebisch wrote:
Ralf Hemmecke wrote:
On 03/18/2010 11:17 PM, Waldek Hebisch wrote:
It is a math problem: if base R is a field that does not contain
square root of -1, then Complex(R) is again a field. But we have
no way to check this condition, so need hardcode the choice.
...
According to the specification...
++ \spadtype {Complex(R)} creates the domain of elements of the form
++ \spad{a + b * i} where \spad{a} and b come from the ring R,
++ and i is a new element such that \spad{i^2 = -1}.
^^^
why shouldn't Complex(Complex(Integer)) make sense.
...
Yes, asserting Field or IntegralDomain is the problem. Otherwise
such constructions would be OK.
I think that to understand Waldek's point it is import to look at
ComplexCategory.
http://axiom-wiki.newsynthesis.org/Complex
E.g.
if R has IntegralDomain then
IntegralDomain
_exquo : (%,R) - Union(%,failed)
++ exquo(x, r) returns the exact quotient of x by r, or
++ failed if r does not divide x exactly.
if R has EuclideanDomain then EuclideanDomain
if R has multiplicativeValuation then multiplicativeValuation
if R has additiveValuation then additiveValuation
if R has Field then-- this is a lie; we must know that
Field-- x^2+1 is irreducible in R
...
Regards,
Bill Page.
--
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-de...@googlegroups.com.
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
Re: function definition revisited was: Re: [fricas-devel] Issue 122?
Ralf,
Isn't this an example of what you want?
(1) - bar0:=(Float,String)-DoubleFloat
(1) ((Float,String) - DoubleFloat)
Type: Domain
(2) - bar1:=Integer-bar0
(2) (Integer - ((Float,String) - DoubleFloat))
Type: Domain
(3) - (a:Integer):bar0 +- (
(x:Float,y:String)+-((x+a::Float)::DoubleFloat) )
(3) theMap(*1;anonymousFunction;10;frame1;internal)
Type: (Integer - ((Float,String) - DoubleFloat))
(4) - foo == (a:Integer):bar0 +- (
(x:Float,y:String)+-((x+a::Float)::DoubleFloat) )
Function declaration foo : Integer - ((Float,String) - DoubleFloat
) has been added to workspace.
Type: Void
(5) - foo(3)
Compiling function foo with type Integer - ((Float,String) -
DoubleFloat)
(5) theMap(#FUNCTION (LAMBDA (#:G747 #:G748 |envArg|)) {BD3015D},303)
Type: ((Float,String) - DoubleFloat)
(6) - (foo(3))(1.2,abc)
(6) 4.199
Type: DoubleFloat
(7) - )version
Value = Saturday November 28, 2009 at 18:17:42
Regards,
Bill Page.
On Fri, Mar 5, 2010 at 9:22 AM, Ralf Hemmecke r...@hemmecke.de wrote:
This one deserves its own thread.
Another problem is that I am somehow
unable to define a function like this:
foo(a: A)(b: B, C: C): D == ...
:-(
What does it mean? Do you want:
foo(a: A) ==
(b: B, C: C) +-
...
or something different?
More precisely
foo(a: A): (B, C) - D == (b: B, c: C): D +- ...
Well, but this is the same as
foo: A - (B, C) - D == (a: A): (B, C) - D +-
-- continue with what comes after == above
Yes, exactly, that should be the same.
http://www.aldor.org/docs/HTML/chap6.html
under Function definition revisited. Or see the AUG p.70.
In fact, a function is nothing else than the definition of a constant (like
foo) using == with the meaning assignment to a constant.
If this could be somehow achieved, that would be wonderful. But, I know that
this will take some time.
Ralf
--
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-de...@googlegroups.com.
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-de...@googlegroups.com.
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] case and Union
Ralf, I think the semantics of union and case are quite clear (provided of course that the types in the union are unique). It seems fine to me to read u case A as telling me explicitly that in the body of this condition u *is* A. For the purposes of writing self-documenting easy to read code perhaps f(u: Union(A, B)): String u case A = u.x u.case B = u.x might be preferable but it seems to me that in this example explicit coercions such as f(u: Union(A, B)): String u case A = (u::A).x u.case B = (u::B).x do not add much to the readability though perhaps if u occurs somewhere deeper in the body of the conditions it might help u case A = ... (u::A).x ... ( At least for those people who remain indentation challenged. :-) Regards, Bill Page. On Fri, Feb 26, 2010 at 5:19 AM, Ralf Hemmecke r...@hemmecke.de wrote: The compiler is supposed to know that after 'case' test one of branches is impossible and automatically coerce to the other. That sounds similar to the fact that in a construction like if Dom has SomeCat then THEN_BODY else ELSE_BODY Aldor will augment Dom inside THEN_BODY to additionally make the exports of SomeCat available. (Which is a good thing.) In my opinion A and Union(A,B) are two different types and I don't want any _implicit_ coercion. Well, after 'case' test such coercion is quite analogous to allowing NonNegativeInteger in place where Integer is expected. That's probably true, but I still don't want implicit coercion. If I were a machine, I probably wouldn't care, because when I read the sources I would always exactly know the type of the variable at hand. As a human, it is much harder to keep track of the variable types. Just read the current algebra sources. A lot of functions just mention their type only in the category part and not again in the implementation part. Suppose the category part is just a big join of a lot of categories. If you now want to find a bug (suppose you are not the original programmer), you just have to waste time to figure out the input and output types of the function. I wouldn't probably care if we have a proper IDE like eclipse that shows me the type of a variable when I hover over it with my mouse. But as long as we don't have that I will be much in favour of adding redundancy to the source code, just because it becomes easier to understand the code of others. Just a quick example where implicit coercion is bad. Suppose A and B are given as A === Record(x: String, y: String, z: Integer) B === Record(y: String, x: String, z: String) and u is of type Union(A, B). What code should the compiler produce for f(u: Union(A, B)): String u case A = u.x u.x ? Just compute f([a, b, c]...@b). Is the result a or b? Should be b. If you want to report bug say what you get. I'v tested that and it indeed returns b. But now as a human I look at the source code and see that strange looking code. It returns u.x for case A and otherwise it returns u.x. Sure why check for being in case A? From a human point of view f(u: Union(A, B)): String == u.x is much simpler to understand. Arrrhhh, well, it's wrong. (Except, we add another implicit behaviour to the compiler that inserts this if case A since the compiler sees that u is a Union. Br. I wouldn't like that.) Ralf -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
[fricas-devel] Re: Issuse 305
Waldek, I just checked this and as you say it is no longer possible reproduce this bug in FriCAS so I have marked this issue as Fixed in FriCAS. I expect there have been several internal changes in FriCAS since I reported this issue that might have affected the results but I am not sure which specific change might have corrected the problem. http://axiom-wiki.newsynthesis.org/305 Thanks. Regards, Bill Page. On Sun, Feb 21, 2010 at 6:23 PM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: Bill, Did you wrote Issue 305 and SandBox Lorentz Transformations? Examples in the sandbox use Aldor. I tried to reproduce the issue in FriCAS interpeter but apparently the statement which is supposed to fail works fine. Also in the sandox I see no failure. I wonder if this was is real FriCAS bug or just weird Aldor problem (which may be gone after interface update). Do you know something more about this? -- Waldek Hebisch hebi...@math.uni.wroc.pl -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] tex
I use
\def\zag#1#2{
{{\hfill \left. {#1} \right|}
\over
{\left| {#2} \right. \hfill}
}
}
on the axiom-wik.newsynthesis.org
I think I got that from either axiom.sty or perhaps some code embedded
in the Axiom book.
Regards,
Bill Page.
On Fri, Jan 15, 2010 at 11:32 AM, leh...@bayou.uni-linz.ac.at wrote:
Hello,
does anyone know how $\zag$ (for continued fractions)
could be nicely implemented?
It does not seem to be a tex command, yet is used in several places.
For this reason continued fractions are not displayed
in Martin's emacs TeX display mode and
hyperdoc crashes for me when I search for it:
System error:
junk in string ozag
Currently I use
\newcommand{\zag}[2]{\frac{\left.#1\right|}{\left|#2\right.}}
in my files, but it looks ugly.
At the same time I would like to fix the missing space
at the end of \rightarrow in tex.spad.
regards,
Franz
--
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-de...@googlegroups.com.
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] comparable patches and comments on unparse
On Sat, Dec 5, 2009 at 8:12 AM, Waldek Hebisch wrote: Bill Page wrote: Martin Rubey wrote: I would also like to see the rudimentary test file I sent to go with this patch. ?One remark: as you probably know, I'm strongly in favour of having InputForm keep all type information. ?I tried to prepare such a patch, but there is a small problem in the way the InputForm of certain elements of EXPR is created. ?I know how to fix it (and it shouldn't be too much work), but I won't do it without being completely sure that there is consensus that INFORM should keep type information. Yes, we have discussed this before. I am not in favor of adding explicit domain/package calls or inserting coercions. I think that every domain for which we need to create an InputForm should have it's own construction function. These function names should be unique and related to the domain name in an obvious manner. Eg. (1) - unparse(3.141592::InputForm) (1) float(231808574432053350722,-66,2) Type: String AFAICS explicit constructors really do not work for parametric domains: currently result type can not depend on values of argument so you have only overloading to choose correct type. But interpreter currently only allows 'Type' as category of type-valued arguments, so it can not resolve interesting cases. Let me add that overloading on types arguments would significantly complicate typchecking, so I am not sure if we ever will support it. So explicit constructors are really only for 'special cases' and general case needs type annotations. As an example consider: (14) - MP := SparseMultivariatePolynomial(Float, Integer) (14) SparseMultivariatePolynomial(Float,Integer) Type: Type (15) - monomial(3.14, 1, 1)$MP (15) 3.14 1 Type: SparseMultivariatePolynomial(Float,Integer) (16) - (monomial(3.14, 1, 3)$MP)::InputForm (16) (float 231691105565791968297 - 66 2) Type: InputForm As you see currently coercion to InputForm gives bogus result. How you want to introduce explicit constructors for polynomials with variables from an arbitrary set? BTW: You may think of polynomials having integers as variables as a perversion, but in fact such choice is natural if you want to do arithmetic on variables. I do not have any problem with polynomials with integer variables. This is certainly ok for certain technical applications although for users the notation generated by OutputForm might be a bit confusing. I agree the result in (16) is wrong but isn't this just a result of the poor method by which the Polynomial domains produce their InputForm? As I recall it just maps the polynomial into the InputForm domain, so the confusion is similar to the odd visual result in OutputForm. No? Before we can agree whether a result is bogus or not I still think we need to agree on the specifications for coercion to InputForm. I proposed in another thread that this should involve interpret$InputFormFunctions1(T) where T is a known type such as MP above. However even in this case I agree the result in (16) is wrong but I am not convinced that this means we should add explicit type information to InputForm. I think we just need a better way of representing polynomials. E.g. (17) - ['monomial, ['float, 231691105565791968297, -66, 2]$List(SExpression),1,3]$List(SExpression)::SExpression::InputForm (17) (monomial (float 231691105565791968297 - 66 2) 1 3) Type: InputForm (18) - interpret(%)$InputFormFunctions1(MP) 3 (18) 3.14 1 Type: SparseMultivariatePolynomial(Float,Integer) Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
Re: [fricas-devel] Multiplication of power series
On Sat, Dec 5, 2009 at 5:30 PM, Ralf Hemmecke wrote: On 12/05/2009 04:54 PM, Waldek Hebisch wrote: Ralf Hemmecke wrote: Waldek, Since we have literate programming, I think your explanation would be best put just next to your implementation. Can you commit that? No!!! I _really_ do not want to see such texts inside source files. Such for given person such text may be useful once, maybe few times, but having to read it or even only look at it every time when looking at code is simply too distracting. Hmmm. OK, I cannot and will not force anybody to find literate programming important. There are still proper tools missing to support LP. Thank you, Martin and Franz, that now I know you are more or less on the LP side and find this a good thing. ... Perhaps there are also people like me who have lost faith in the concept of literate programming. When I first started with the Axiom project several years ago I originally thought it was a good idea and a reasonable response to the serious problem of lack of documentation of the Axiom system. But now I agree with Waldek that almost always the documentation part of the pamphlet files gets in the way of my understanding of the code and work almost exclusively with the .spad files until forced to re-assemble them into the pamphlet form. I do not think that this is only a result of the lack of proper tools to support LP although I have long argued that there are better approaches than the one originally advocated by Donald Knuth. There are multiple problems but I think the most serious problem is that the methodology just does not fit the psychology of many (most?) of the talented people who are able to do this kind of work - particularly when they do it voluntarily. Advocated re-education and greater self-discipline is simply impractical. And hoping that other motivated users/developers will appear who are willing to put an effort into documenting other people's code is simply unrealistic. Having worked with Sage for awhile it seems to me that the doc string methodology much better suits the current state-of-the-art and state-of-mind in software development. Ironically this is very similar to the ++ style comments in Spad and how they interact with hyperdoc. I am very happy that Waldek has stated elsewhere that he considers the hyperdoc documentation to be the definitive source for documentation of FriCAS and that he spent considerable effort to resurrect the tools from the original Axiom source code to help keep Hyperdoc up to date. It seems that even more can be done in this direction to advance the original approach developed before Axiom became an open source project. For example as I understand it the Axiom book was originally extracted from the same set of enhanced tex files combined with documentation in the Axiom source code and derived by running Axiom itself. I think that it was a great experiment but in the end it is rather unfortunate that Tim Daly choose to adopt a new technology based on the Knuth literate programming approach when initiating the first open source Axiom project rather than focusing on extending and expanding the use of hyperdoc. I cannot see any evidence at all that the use of literate programming as such in the original Axiom project has contributed anything to the acceptance of Axiom in the potential user/developer community. Needless to repeat I suppose that this is of course only my personal opinion. :-) Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
[fricas-devel] FreeMonoidCat, FreeCommutativeMonoid and OrderedMonoid
Waldek,
Thank you for posting the change that adds 'Comparable' to XPOLY and
Tensor domains. I am sorry that I did not have time to do it earlier.
The following patch defines FreeMonoidCat as a separate category, adds
a new domain for FreeCommuativeMonoid and declares a FreeMonoid over
OrderedSet to be an OrderedMonoid.
Question 1: What do you think in general about the Ordered... domains?
Does it really make sense to define higher-level domains that are
unconditionally ordered in this way? Isn't it better in general to
make ordering a conditional attribute?
Question 2: Do you see any issues with the change of order in 'plus(f,
g)' below?
Question 3: Do you think the order defined on FreeGroup is a good one?
Regards,
Bill Page.
wsp...@debian:~/fricas-sources$ svn status
? src/share/spadhelp
--- Changelist 'free':
M src/algebra/boo-cat.input
M src/algebra/free.spad.pamphlet
M src/algebra/boo-dom1.input
M src/algebra/Makefile.in
--- Changelist 'hash':
M src/algebra/list.spad.pamphlet
--- Changelist 'combfunc':
M src/algebra/combfunc.spad.pamphlet
M src/algebra/tex.spad.pamphlet
M src/interp/i-output.boot
--- Changelist 'unparse':
M src/interp/format.boot
wsp...@debian:~/fricas-sources$ svn diff
src/algebra/free.spad.pamphlet ~/algebra-free-1.patch
wsp...@debian:~/fricas-sources$ svn diff src/algebra/free.spad.pamphlet
Index: src/algebra/free.spad.pamphlet
===
--- src/algebra/free.spad.pamphlet (revision 745)
+++ src/algebra/free.spad.pamphlet (working copy)
@@ -155,7 +155,7 @@
plus(f, g) ==
#f #g = localplus(f, g)
- localplus(g, f)
+ localplus(f, g)
localplus(f, g) ==
g := copy g
@@ -165,8 +165,8 @@
@
\section{domain FMONOID FreeMonoid}
-domain FMONOID FreeMonoid=
-)abbrev domain FMONOID FreeMonoid
+category FMONCAT FreeMonoidCat=
+)abbrev category FMONCAT FreeMonoidCat
++ Free monoid on any set of generators
++ Author: Stephen M. Watt
++ Date Created: ???
@@ -175,11 +175,10 @@
++ The free monoid on a set S is the monoid of finite products of
++ the form \spad{reduce(*,[si ^ ni])} where the si's are in S, and the ni's
++ are nonnegative integers. The multiplication is not commutative.
-FreeMonoid(S: SetCategory): FMcategory == FMdefinition where
+FreeMonoidCat(S:SetCategory):Category == FMcategory where
NNI == NonNegativeInteger
REC == Record(gen: S, exp: NonNegativeInteger)
Ex == OutputForm
-
FMcategory == Join(Monoid, RetractableTo S) with
*:(S, %) - %
++ s * x returns the product of x by s on the left.
@@ -221,8 +220,24 @@
++ mapExpon(f, a1\^e1 ... an\^en) returns \spad{a1\^f(e1)
... an\^f(en)}.
mapGen : (S - S, %) - %
++ mapGen(f, a1\^e1 ... an\^en) returns \spad{f(a1)\^e1 ...
f(an)\^en}.
-if S has OrderedSet then OrderedSet
+if S has OrderedSet then OrderedMonoid
+@
+domain FMONOID FreeMonoid=
+)abbrev domain FMONOID FreeMonoid
+++ Free monoid on any set of generators
+++ Author: Stephen M. Watt
+++ Date Created: ???
+++ Date Last Updated: 6 June 1991
+++ Description:
+++ The free monoid on a set S is the monoid of finite products of
+++ the form \spad{reduce(*,[si ^ ni])} where the si's are in S, and the ni's
+++ are nonnegative integers. The multiplication is not commutative.
+FreeMonoid(S: SetCategory): FreeMonoidCat(S) == FMdefinition where
+NNI == NonNegativeInteger
+REC == Record(gen: S, exp: NonNegativeInteger)
+Ex == OutputForm
+
FMdefinition == ListMonoidOps(S, NonNegativeInteger, 1) add
Rep := ListMonoidOps(S, NonNegativeInteger, 1)
@@ -347,6 +362,36 @@
empty? la and not empty? lb
@
+domain FCMON FreeCommutativeMonoid=
+)abbrev domain FCMON FreeCommutativeMonoid
+++ Description:
+++ Free commutative monoid on any set of generators
+++ Original Author: Bill Page
+++ Date Created: 30 Sept 2009
+++ Date Last Updated:
+++
+)abbrev domain FCMON FreeCommutativeMonoid
+FreeCommutativeMonoid(S:Join(Comparable,SetCategory)):FreeMonoidCat(S)
== FreeMonoid (S) add
+Rep == ListMonoidOps(S, NonNegativeInteger, 1)
+rep(x:%):Rep == x pretend Rep
+per(x:Rep):% == x pretend %
+Term == Record(gen: S, exp: NonNegativeInteger)
+
+mult(terms:List Term):List Term ==
+ if #terms1 then
+f:=first terms
+m:=mult(rest terms)
+l:=first m
+if f.gen=l.gen then
+ concat([f.gen, f.exp+l.exp]$Term,rest m)
+else concat(f,m)
+ else
+ terms
+
+(x:% * y:%):% == per makeMulti mult sort( (a:Term,b:Term):Boolean
+- smaller?(a.gen,b.gen),
+concat(listOfMonoms rep x, listOfMonoms rep y) ) )
+
+@
\section{domain FGROUP FreeGroup}
domain FGROUP FreeGroup=
)abbrev domain FGROUP FreeGroup
@@ -377,6 +422,7 @@
++ mapGen(f, a1\^e1 ... an\^en) returns \spad{f(a1)\^e1 ...
f(an)\^en}.
factors : % - List
Re: [fricas-devel] comparable patches and comments on unparse
Martin Rubey wrote: I would also like to see the rudimentary test file I sent to go with this patch. One remark: as you probably know, I'm strongly in favour of having InputForm keep all type information. I tried to prepare such a patch, but there is a small problem in the way the InputForm of certain elements of EXPR is created. I know how to fix it (and it shouldn't be too much work), but I won't do it without being completely sure that there is consensus that INFORM should keep type information. Yes, we have discussed this before. I am not in favor of adding explicit domain/package calls or inserting coercions. I think that every domain for which we need to create an InputForm should have it's own construction function. These function names should be unique and related to the domain name in an obvious manner. Eg. (1) - unparse(3.141592::InputForm) (1) float(231808574432053350722,-66,2) Type: String (This possibly affects also speed of operations like draw, that use InputForm for creating compiled functions from expressions. If things go badly, it may even affect speed of the created functions.) On Sun, Nov 22, 2009 at 8:18 PM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: Let me say that I am not sure if InputForm is best solution for problems where it is used now, in particular it looks that there are better ways of converting expressions to functions. But if we keep using InputForm for such purposes, then fully typed InputForm is the correct way. Current use of InputForm for plotting is a hack, I think it does not work for really general input form. As long as we keep the simplest forms untyped there should be no negative impact on plotting. If every domain had a constructor function I think there would be no negative impact - perhaps in some special cases even an improvement. No? Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=.
Re: [fricas-devel] Stuck with lazy argument in an operator
Waldek wrote:
AFAICS in current Spad it is impossible to export type in way allowing
_compile time_ use and checking (basically except for builtin types
like Record all types are abstract). We could add to SMP function
called 'SmpRepresentation' which would return type used for SMP
representation and use it like this:
if SmpRepresentation()$MP1 is SmpRep1 and
SmpRepresentation()$MP2 is SmpRep2 then
-- Use representation
...
else
error representation of SMP has changed, fix the code
On Fri, Nov 20, 2009 at 9:28 AM, Ralf Hemmecke wrote:
Nothing that I would prefer. Such code looks just horrible and is only a
sequence of ifs for all the special cases ... (there might be several
such things).
A little correction to the above: we could export types using
include files. Such method is widely used in C, but I am not
sure how you like it...
I don't like it. It would also be a dependency. If you change the
representation drastically enough, you still cannot be sure that things
work as they should.
In 'src/algebra/table.spad.pamphlet' there is the following code:
\section{domain INTABL InnerTable}
domain INTABL InnerTable=
)abbrev domain INTABL InnerTable
++ Author: Barry Trager
++ Date Created: 1992
++ Date Last Updated: Sept 15, 1992
++ Related Domains: HashTable, AssociationList, Table
++ Description:
++ This domain is used to provide a conditional add domain
++ for the implementation of \spadtype{Table}.
InnerTable(Key: SetCategory, Entry: SetCategory, addDom):Exports ==
Implementation where
addDom : Join(TableAggregate(Key, Entry), finiteAggregate)
Exports == Join(TableAggregate(Key, Entry), finiteAggregate)
Implementation == addDom
@
\section{domain TABLE Table}
domain TABLE Table=
)abbrev domain TABLE Table
++ Author: Stephen M. Watt, Barry Trager
++ Date Created: 1985
++ Date Last Updated: Sept 15, 1992
++ Related Domains: HashTable, EqTable, StringTable, AssociationList
++ Description:
++ This is the general purpose table type.
++ The keys are hashed to look up the entries.
++ This creates a \spadtype{HashTable} if equal for the Key
++ domain is consistent with Lisp EQUAL otherwise an
++ \spadtype{AssociationList}
Table(Key: SetCategory, Entry: SetCategory):Exports == Implementation where
Exports == Join(TableAggregate(Key, Entry), finiteAggregate)
Implementation == InnerTable(Key, Entry,
if hashable(Key)$Lisp then HashTable(Key, Entry, UEQUAL)
else AssociationList(Key, Entry))
@
I think that one might claim that this approach does allow some degree
of compile-time checking. But I admit that I am not sure how well
this model fits what you want to do with SMP.
Regards,
Bill Page.
--
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-de...@googlegroups.com.
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=.
Re: [fricas-devel] How do I add infix operators?
Martin, Perhaps I do not understand your question but I do not see any problem defining /\ and \/ as operators. They are treated as infix operators by default in the interpreter even though you define them using a standard prefix notation. For example see the page: http://axiom-wiki.newsynthesis.org/SandBoxTensorProductPolynomial On Sat, Nov 14, 2009 at 11:08 AM, Martin Baker wrote: I am modifying the CliffordAlgebra domain and I would like to add /\, \/ and _| operators to represent exterior,inner and contraction inner products (in addition to the existing * Clifford product). Is it possible to add these as infix operators from within the spad domain code and define their precedence? From searching this forum I get the impression that this involves a command like: )Lisp (push _/_\) Although I can't find any instructions about how to do it, how to set the precedence and so on? Changing precedence might not be so easy. The code in the example above does not attempt to change that. This involves at least temporary changes to the Axiom interpreter as Waldek's email suggests. Also is this generally encouraged or discouraged? Are there examples in the codebase where I could see how to do this? Vectors don't seem to do this for cross and dot products? I could just provide this as functions like: z := /\(x,y) but this would be much less readable, especially for complicated equations with mixed operations. What do you think would be the best way to do this (keeping in mind that I am a beginner with FriCAS) I think you bring up a good point that this should be made easier to do. Regards, Bill Page -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=.
Re: [fricas-devel] comparable patches and comments on unparse
Waldek, Thank you for your testing and comments about 'algebra-comparable-1.patch' On Wed, Nov 11, 2009 at 10:57 PM, Waldek Hebisch wrote: The algebra-comparable-1.patch mostly looks OK. However I have doubts about the followig hunk: Index: src/algebra/variable.spad.pamphlet === --- src/algebra/variable.spad.pamphlet (revision 730) +++ src/algebra/variable.spad.pamphlet (working copy) @@ -35,7 +35,7 @@ for i in 1.. for exp2 in VariableList repeat if exp=exp2 then return i::PositiveInteger::% failed - s1 s2 == s2 $Rep s1 + s1 s2 == s1 $Rep s2 s1 = s2 == s1 =$Rep s2 latex(x:%):String == latex(convert(x)@Symbol) At first glance what you do is very natural change. Yes, I had forgotten about this little change. Do you understand why the natural order was reversed in the original code? But order has crucial importance to correctness and efficiency of Groebner bases and triangular sets. While your change _may_ have no ill effects, I would not dare to make such change without extensive checking. I am surprised that these algorithms are sensitive to the absolute ordering of an OrderedVariableList. I suppose that there must be some undocumented assumption about the representation built in to some of the code that uses OrderedVariableList. If we could find where this assumption is is made I think we would be better off. But of course this can wait. I also tried to bootstrap with your patch. It seems that AXIOMsys went into infinite loop processing LazardSetSolvingPackageXmpPage. Similarly during testsuite run. ATM I have no time to investigate -- all I can say is that on the test machine trunk builds fine, but with your patch build fails. It is strange that in my test build this did not happen. But I admit that I did not run any additional testsuite. On Thu, Nov 12, 2009 at 7:41 AM, Waldek Hebisch wrote: After deleting the hunk changing variable ordering bootstrap went fine and tests show no regressions. Bill, please commit the algebra-comparable-1.patch _without_ the variable hunk (this hunk definitely causes trouble). Ok I will do that. I am mildly surprised and annoyed that such a natural change results in such drastic failure. One reason I am anxious now to complete this is that I have other things in my local patch queue that need to make independent changes to 'src/algebra/Makefile.in'. It is a (serious!) limitation of the changelist functionality in subversion that a change to a single file is the smallest atomic change and a modified file can be a member of only one changelist. I have not efficient way to keep independent changes separate if I try to merge more of what's waiting. One remark: I may experiece it is bad to keep uncommited changes for long time. However for short time management of chages I found patches quite effective. Namely deleting unneeded parts from a patch I can easily separate changes, even if they are to the same file. Of course, this is problematic if changes overlap or if there are too many changes... Because of the work I was doing the last few months I accumulated quite a few local changes to various parts of FriCAS. This is mostly a matter of trying to untangle these into stuff that can actually be committed as patches to the main line. But I agree in principle about having too many uncommitted changes. My experience trying to edit patch files is all quite negative. Usually I end up with a modified patch file that will not apply to the existing source. One advantage of darcs is that it always breaks down changes to a sequential set of (usually) very small patches - often many per file. When committing changes to the repository one can interactively choose which of these small patches should be included and which should not. Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=.
Re: [fricas-devel] comparable patches and comments on unparse
Waldek, Thanks for the example of where the ordering of an OrderedVariableList is important in the library. As I said, I will commit the code for comparable without this change. But I will be traveling for the next few days and may not be able to do the commit until some time next week. On Thu, Nov 12, 2009 at 11:00 PM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: Look at DistributedMultivariatePolynomial, note that order is taken from DirectProduct(#vl,NonNegativeInteger). In direct product we have lexicographic order in which _lower numbered_ coordinate has more weight. Isn't this rather peculiar? Why does a lower numbered coordinate have more weight? In lexicograhic order on monomials larger variable has more weight. So order coming from representation agrees with order from documentation only if you use current definition of order for OrderedVariableList. I see. Thanks for finding this example. You probably think that all algebra code is completely generic, but this is not the case: lexicographic order is used because it has very specific properties. Generic code means that code makes only _necessary_ assumptions and properties of monomial order are necessary for many computations. I have no problem to understand that properties of monomial order are necessary but I would prefer that it be specified explicitly by the organization of the code and not deeply hidden by unspecified assumptions. Also, you may think that DistributedMultivariatePolynomial should not make assumptions about representation of OrderedVariableList. But representation is crucial for efficiency and OrderedVariableList exist mainly to support efficient polynomial computations with fixed set of variables. Yes I do think in general that DistributedMultivariatePolynomial (and other similar domains) should avoid making assumptions about representation where ever possible. I think that in most cases the representation can export methods that do not compromise performance significantly. In my opinion performance at the cost of maintainability is a questionable trade-off. Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-de...@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=.
[fricas-devel] Re: Newbie cant get started
Martin, Please try this without moving fricas first: wget http://downloads.sourceforge.net/project/fricas/fricas/1.0.8/fricas-.0.8.amd64.tar.bz2 (or equivalent) tar tjf fricas-1.0.8.amd64.tar.bz2 | more ulimit -v unlimited export AXIOM=/home/page/usr/local/lib/fricas/target/x86_64-unknown-linux $AXIOM/bin/AXIOMsys This should give a FriCAS startup prompt as shown below. The command ulimit -v unlimited removes any limit on the amount of virtual memory available to the programs that you run from your user account. It seems that on SuSE the limit is set rather low by default. --- Waldek, I have never tried to install a FriCAS binary before. It seems rather strange to me to see the directory structure of the archive begin with usr/ ... and not some directory like fricas-1.0.8.amd64/usr/ ... but anyway, this is what I get on my 64 bit SuSE 11 system: p...@asus:~ wget http://downloads.sourceforge.net/project/fricas/fricas/1.0.8/fricas-1.0.8.amd64.tar.bz2?use_mirror=softlayer ... Length: 26535343 (25M) [application/x-bzip2] Saving to: `fricas-1.0.8.amd64.tar.bz2' 100%[==] 26,535,343 311K/s in 84s 2009-11-10 09:25:29 (310 KB/s) - `fricas-1.0.8.amd64.tar.bz2' saved [26535343/26535343] p...@asus:~ tar tjf fricas-1.0.8.amd64.tar.bz2 | more usr/ usr/local/ usr/local/lib/ usr/local/lib/fricas/ usr/local/lib/fricas/emacs/ usr/local/lib/fricas/emacs/fricas-cpl.el usr/local/lib/fricas/emacs/fricas.el usr/local/lib/fricas/target/ usr/local/lib/fricas/target/x86_64-unknown-linux/ ... p...@asus:~ tar xjf fricas-1.0.8.amd64.tar.bz2 p...@asus:~ export AXIOM=/home/page/usr/local/lib/fricas/target/x86_64-unknown-linux p...@asus:~ $AXIOM/bin/AXIOMsys mmap: Cannot allocate memory ensure_space: failed to validate 8589869056 bytes at 0x10 (hint: Try ulimit -a; maybe you should increase memory limits.) p...@asus:~ --- Perhaps this is related to what is happening to Martin. p...@asus:~ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 16381 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) 1745812 open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 16381 virtual memory (kbytes, -v) 3326720 file locks (-x) unlimited p...@asus:~ ulimit -v unlimited p...@asus:~ $AXIOM/bin/AXIOMsys Checking for foreign routines AXIOM=/home/page/usr/local/lib/fricas/target/x86_64-unknown-linux spad-lib=/home/page/usr/local/lib/fricas/target/x86_64-unknown-linux/lib/libspad.so foreign routines found openServer result -2 FriCAS (AXIOM fork) Computer Algebra System Version: FriCAS 1.0.8 Timestamp: Saturday October 24, 2009 at 02:03:04 - Issue )copyright to view copyright notices. Issue )summary for a summary of useful system commands. Issue )quit to leave FriCAS and return to shell. - (1) - --- Regards, Bill Page. On Tue, Nov 10, 2009 at 7:56 AM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: Martin Baker wrote: Waldek and Bill, I have tried everything Waldek suggested and I am still getting the same result. Rather than list it all here I put it on this web page so that I could include screenshots. http://www.euclideanspace.com/maths/standards/program/fricas/ I guess I will have to try compiling from source as Bill suggests but I don't have much expertise in that area. I must say that from the web page it is not clear if you really followed the instruction. For example in yellow box you first show commands to unpack the tarball, but do not show value you gave to the AXIOM variable. OTOH if './fricas -list' works then you probably got it right. Two extra things to check: ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] comparable patches and comments on unparse
Waldek,
Attached and below is the patch rebased to revision 730 that adds
Comparable to the XPOLY and Tensor domains (and others that depend on
FreeModuleCategory). Among other things this change permits these
domains to participate with domains like Expression again, although
there are some additional extensions and corrections needed in
Expression to make this work properly. Also related to this and
included is the patch to constantOperator to remove dependence on
OrderedSet. I have tested this fairly well but I think it would be
prudent if you (or anyone else) also give it a try.
If you agree it is ok, I will commit it ASAP.
One reason I am anxious now to complete this is that I have other
things in my local patch queue that need to make independent changes
to 'src/algebra/Makefile.in'. It is a (serious!) limitation of the
changelist functionality in subversion that a change to a single file
is the smallest atomic change and a modified file can be a member of
only one changelist. I have not efficient way to keep independent
changes separate if I try to merge more of what's waiting.
On Wed, Oct 28, 2009 at 2:06 PM, Waldek Hebisch wrote:
Well, first I prefer to have good patches committed quickly instead
of sitting in the patch queue. Second, it would be good if person
working on a patch explicitely said that he/she supends it. For
example, you Bill had patch adding 'Comparable' to some domains.
The patch looks good but I do not know if you hit some problems
during testing and are busy solving them or you are occupied with
something else...
On Wed, Oct 28, 2009 at 5:05 PM, Bill Page wrote:
About Comparable: Yes, it was important for some things I was working
on at the time and I did commit at least part of these changes. But
they were also became part of something more ambitious involving
changing Void to a domain in SetCategory which did not work out so
well and I have set aside for now. I guess I still do not really know
how to properly organize and discipline my play so that it results
in some things that can be easily salvaged. I am inclined to blame the
tools such as limitations of svn but really it just comes down again
to a lack of time and excess of ambition. BTW, maybe I will start
using darcs again locally as a way of more easily staging patches.
Well for now I am still trying to live with changelists in subversion ... :-(
wsp...@debian:~/fricas-sources$ svn status
? src/share/spadhelp
--- Changelist 'free':
M src/algebra/free.spad.pamphlet
--- Changelist 'hash':
M src/algebra/list.spad.pamphlet
--- Changelist 'comparable':
M src/algebra/op.spad.pamphlet
M src/algebra/Makefile.in
M src/algebra/variable.spad.pamphlet
M src/algebra/poly.spad.pamphlet
--- Changelist 'combfunc':
M src/algebra/combfunc.spad.pamphlet
M src/algebra/tex.spad.pamphlet
M src/interp/i-output.boot
--- Changelist 'unparse':
M src/interp/format.boot
Here is the patch:
wsp...@debian:~/fricas-sources$ svn diff --changelist comparable
~/algebra-comparable-1.patch
wsp...@debian:~/fricas-sources$ cat ~/algebra-comparable-1.patchIndex:
src/algebra/op.spad.pamphlet
===
--- src/algebra/op.spad.pamphlet(revision 730)
+++ src/algebra/op.spad.pamphlet(working copy)
@@ -234,11 +234,11 @@
++ derivative(op) returns the value of the %diff property of
++ op if it has one, and failed otherwise.
constantOperator: A - OP
-++ constantOperator(a) returns a nullary operator op
-++ such that \spad{op()} always evaluate to \spad{a}.
+ ++ constantOperator(a) returns a nullary operator op
+ ++ such that \spad{op()} always evaluate to \spad{a}.
constantOpIfCan : OP - Union(A, failed)
-++ constantOpIfCan(op) returns \spad{a} if op is the constant
-++ nullary operator always returning \spad{a}, failed otherwise.
+ ++ constantOpIfCan(op) returns \spad{a} if op is the constant
+ ++ nullary operator always returning \spad{a}, failed otherwise.
Implementation == add
@@ -271,43 +271,44 @@
derivative(op, [(l1: List(A)): A +- f first l1]$List(List A - A))
error Operator is not unary
-if A has OrderedSet then
- cdisp : (OutputForm, List OutputForm) - OutputForm
- csex: (InputForm, List InputForm) - InputForm
- eqconst?: (OP, OP) - Boolean
- ltconst?: (OP, OP) - Boolean
- constOp : A - OP
+cdisp : (OutputForm, List OutputForm) - OutputForm
+csex: (InputForm, List InputForm) - InputForm
+eqconst?: (OP, OP) - Boolean
+constOp : A - OP
- opconst:OP :=
-comparison(equality(operator('constant, 0), eqconst?),
- ltconst?)
+cdisp(a, l) == a
+csex(a, l) == a
- cdisp(a, l) == a
- csex(a, l) == a
-
- eqconst?(a, b) ==
-(va := property
[fricas-devel] Re: Newbie cant get started
Martin, I do not see a binary named 'fricas-1.0.8 x86_64-unknown-linux' on the FriCAS sourceforge site: http://sourceforge.net/projects/fricas/files/ Can you say where you found this version? It's been a long time since I have installed a binary version of FriCAS on linux but this looks like the binary is not compatible with your system. I almost always build all flavors for Axiom from current source. Would this be difficult for you? Regards, Bill Page. On Mon, Nov 9, 2009 at 1:43 PM, Martin Baker gad9...@martinb.com wrote: Hi, I am attempting to install and run fricas-1.0.8 x86_64-unknown-linux to my openSUSE (64-bit) system for the first time. I believe I have followed the instructions correctly but every time I run the script the cursor steps down about 3 lines and then, after a short delay, returns to the command line prompt. There are no error messages on the command line and no messages in the system log. if I enter: ./fricas -list I get: AXIOM workspaces in $AXIOM/bin = /usr/share/fricas/bin: -rwxr-xr-x 1 root root 72421424 2009-10-24 01:13 AXIOMsys Would now start the processes. exec /usr/share/fricas/bin/sman -ws /usr/share/fricas/bin/AXIOMsys Running sman directly has the same effect as running the script (once I copied bin lib files where it expected them). Running as root has the same effect. Running ./fricas -iw momentarily opens then closes an empty window Running outside the graphical window produces a message about the lack of x window I can't think of anything else to try? - any ideas appreciated. Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: hashing
Bertfried,
Probably you are surprised by the implementation of the 'Reference':
domain REF Reference=
)abbrev domain REF Reference
++ Author: Stephen M. Watt
++ Date Created:
++ Change History:
++ Basic Operations: deref, elt, ref, setelt, setref, =
++ Related Constructors:
++ Keywords: reference
++ Description: \spadtype{Reference} is for making a changeable instance
++ of something.
Reference(S:Type): Type with
ref : S - %
++ ref(n) creates a pointer (reference) to the object n.
elt : % - S
++ elt(n) returns the object n.
setelt: (%, S) - S
++ setelt(n,m) changes the value of the object n to m.
-- alternates for when bugs don't allow the above
deref : % - S
++ deref(n) is equivalent to \spad{elt(n)}.
setref: (%, S) - S
++ setref(n,m) same as \spad{setelt(n,m)}.
_= : (%, %) - Boolean
++ a=b tests if \spad{a} and b are equal.
if S has SetCategory then SetCategory
== add
Rep := Record(value: S)
p = q== EQ(p, q)$Lisp
ref v== [v]
elt p== p.value
setelt(p, v) == p.value := v
deref p == p.value
setref(p, v) == p.value := v
if S has SetCategory then
coerce p ==
prefix(message(ref@String), [p.value::OutputForm])
@
The key part being the representation:
Rep := Record(value: S)
On Mon, Nov 9, 2009 at 12:14 PM, Bertfried Fauser
bertfried.fau...@googlemail.com wrote:
Hi,
I just did a grep to try to find out where the domain 'Reference'
is defined, but that seems a far too common name to search for...
The most reliable way to search for where a domain is defined in the
src/algebra directory is based on the the abbreviation.
The following command:
$ grep ')abbrev domain REF' *.pamphlet
Is guaranteed to find which pamphlet file contains the code for the
'Reference' domain. If don't what to bother to find out the
abbreviation and whether it is a package, domain or category first you
could also search using a regular expression like this:
$ grep -e ')abbrev .* Reference' *.pamphlet
Anyhow, in the domain Reference (see )sh REF ) one has functions
which obviously get the pointer to an algebra object.
As you see above, there is not explicit pointer to an algebra object.
Rep := Record(value: S)
is simply a container for things of type S.
ref v== [v]
returns this container as an object.
Unfortunately there is also the stupid coercion to single interger
(hash) which is trivial. But one possibly could be to simply set the
hash of any object to the pointer referencing it.
Of course with the definition above this is not possible. *If* FriCAS
did provide a good hash value for things of type Record (it currently
does not), then what you suggest would be possible. In that case one
would return the hash for the container.
That should be fairly distinctive easy(?) to implement and very fast,
morover, things located in memory nearby would get similar pointers (if
they are really pointers to memory positions?
They are not. :-(
[I have no Idea about the underlying structure])
This is surely not a good hash, but a better one than the default hash
anyhow.
So could one not set the default hash function to use just the pointer
(would need a coercion to SingleInteger(?) of the pointer obtained by
ref ...
With a little Lisp magic I think it would be possible to create a
SingleInteger for any Axiom object based on it's memory address. But I
am not sure that this very useful. One feature that I think we want
for a hash code is that identical *values* should always hash to the
the same code. The address is not of much importance. Or did I
misunderstand your proposal?
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: hashing of Record, Union, Mapping
On Mon, Nov 9, 2009 at 4:33 PM, Gabriel Dos Reis wrote: Bill Page writes: [...] | Of course with the definition above this is not possible. *If* FriCAS | did provide a good hash value for things of type Record (it currently | does not), then what you suggest would be possible. In that case one | would return the hash for the container. OpenAxiom provides hashes for Record and Union; whether that is a good hash depends on the underlying Lisp runtime. Thanks Gaby. I think FriCAS really should follow OpenAxiom's lead here. With my current version of OpenAxiom compiled using SBCL I get: wsp...@debian:~/fricas-sources/src/algebra$ open-axiom -nox OpenAxiom: The Open Scientific Computation Platform Version: OpenAxiom 1.4.0-2009-10-01 Built on Tuesday October 6, 2009 at 10:11:25 - Issue )copyright to view copyright notices. Issue )summary for a summary of useful system commands. Issue )quit to leave OpenAxiom and return to shell. - (1) - x:Record(val:Integer):=[1] (1) [val= 1] Type: Record(val: Integer) (2) - hash(x) There are 1 exposed and 1 unexposed library operations named hash having 1 argument(s) but none was determined to be applicable. Use HyperDoc Browse, or issue )display op hash to learn more about the available operations. Perhaps package-calling the operation or using coercions on the arguments will allow you to apply the operation. Cannot find a definition or applicable library operation named hash with argument type(s) Record(val: Integer) Perhaps you should use @ to indicate the required return type, or $ to specify which version of the function you need. (2) - )sh Record(val:Integer) Record(val: Integer) is a domain constructor. --- Operations ?=? : (%,%) - Booleancoerce : % - OutputForm construct : Integer - % copy : % - % ?.val : (%,val) - Integer?~=? : (%,%) - Boolean setelt : (%,val,Integer) - Integer --- wsp...@debian:~/open-axiom-src$ svn info Path: . URL: https://open-axiom.svn.sf.net/svnroot/open-axiom/trunk Repository Root: https://open-axiom.svn.sf.net/svnroot/open-axiom Repository UUID: f499efd5-9937-0410-b36a-d3739c31ded8 Revision: 1310 Node Kind: directory Schedule: normal Last Changed Author: dos-reis Last Changed Rev: 1310 Last Changed Date: 2009-10-03 03:51:58 -0400 (Sat, 03 Oct 2009) When did you add support for hash in Record? Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Newbie cant get started
On Mon, Nov 9, 2009 at 5:13 PM, Waldek Hebisch wrote: fricas-1.0.8.amd64.tar.bz2 tarball is organized as follows: usr/ local/ bin/ fricas efricas lib/ fricas/ emacs/ target/ x86_64-unknown-linux/ algebra/ autoload/ bin/ doc/ lib/ share/ src/ Waldek, Why does the tarball 'fricas-1.0.8.amd64.tar.bz2' use the name 'x86_64-unknown-linux'? That confused me. Isn't it conventional to distinguish between amd64 (AMD extensions of x86_64) and Intel 64 (Intel's extension of x86_64)? http://en.wikipedia.org/wiki/X86-64 I guess it's probably true that this 64-bit binary does not use any vendor specific extensions. Maybe the name should really be 'fricas-1.0.8.x86_64.tar.bz2' ? Not a big deal. I was just confused when I saw your reply to Martin. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: hashing of Record, Union, Mapping
On Mon, Nov 9, 2009 at 5:06 PM, Gabriel Dos Reis wrote: ... I've noticed that you (or axiom-wiki.newsynthesis.org) don't always run a recent enough verson of OpenAxiom ;-p Actually I usually do update my version of OpenAxiom whenever I notice some posted change that seems especially significant. And I update the axiom-wiki site if there is some feature of OpenAxiom that is important to the discussion there. In this case I guess I did not read far enough since the log entry was a bit misleading... -- Forwarded message -- From: dos-r...@users.sourceforge.net Date: Thu, Oct 15, 2009 at 4:52 AM Subject: [open-axiom-commit] SF.net SVN: open-axiom:[1319] trunk/src To: open-axiom-com...@lists.sf.net Revision: 1319 http://open-axiom.svn.sourceforge.net/open-axiom/?rev=1319view=rev Author: dos-reis Date: 2009-10-15 09:52:30 + (Thu, 15 Oct 2009) Log Message: --- * interp/buildom.boot: Tidy. --- When ever you think the version of OpenAxiom installed on axiom-wiki should be updated, please let me know and I will do so as soon as I am able. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: hashing
On Mon, Nov 9, 2009 at 10:54 PM, Waldek Hebisch wrote: Bill Page wrote: As you see above, there is not explicit pointer to an algebra object. Rep := Record(value: S) is simply a container for things of type S. ref v == [v] returns this container as an object. Unfortunately there is also the stupid coercion to single interger (hash) which is trivial. But one possibly could be to simply set the hash of any object to the pointer referencing it. Of course with the definition above this is not possible. *If* FriCAS did provide a good hash value for things of type Record (it currently does not), then what you suggest would be possible. In that case one would return the hash for the container. Actually, reasonable hash for Record is unreasonable for references: for Records use equality of components, for Reference we have: p = q == EQ(p, q)$Lisp which is quite different. Yes you are right. I was wrong.(again) The hash function for Record does not make sense here. (Although a hash function for Record does make sense for it's own sake independent of this.) Actually, looking at the above I think that if we want to use Reference as pointers we really want: p = q == EQ(p.value, q.value)$Lisp which still is different than Record equality (which would uses equality of values, Values of type Reference are not necessarily pointers but they are like memory addresses or variables that are not automatically de-referenced. This is just like x in the C language. A pointer would be a reference to a reference, i.e. something like this: q:=ref(3)$Reference(Integer) p:=ref(q)$Reference(Reference Integer) why we want identity (Lisp EQ) here. If p and q were pointers (references to references) you would be comparing their dereferenced values by EQ. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: unparsing subscripts
On Sat, Nov 7, 2009 at 4:26 AM, Martin Rubey wrote: Afterthought: maybe generate a list of all domains D with Finite, and write a unparse(random()$D::INFORM) to a file, and generate a testsuite starting with that. You'll sure find many bugs :-) I am not sure how to make such a list. If this is of special interest to you it would be best if you did this. :-( I am not looking for additional work! ) (2) - D := PF 1783 (2) PrimeField(1783) Type: Domain (3) - ex := random()$D (3) 760 Type: PrimeField(1783) (4) - ex::INFORM Cannot convert from type PrimeField(1783) to InputForm for value 760 Why does this fail? (8) - coerce(ex)@InputForm An expression involving @ InputForm actually evaluated to one of type None . Perhaps you should use :: InputForm . If this is a systematic failure someone should look at the code rather than generating a lot of test cases. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: unparsing subscripts
On Sat, Nov 7, 2009 at 1:24 PM, Martin Rubey wrote:
Bill Page writes:
On Sat, Nov 7, 2009 at 4:26 AM, Martin Rubey wrote:
Afterthought:
maybe generate a list of all domains D with Finite, and write a
unparse(random()$D::INFORM)
to a file, and generate a testsuite starting with that.
You'll sure find many bugs :-)
I am not sure how to make such a list. If this is of special interest
to you it would be best if you did this. :-( I am not looking for
additional work! )
(19) - )read /tmp/fricas4253K6t.input
getDomains(cat: Symbol): Set Symbol ==
set map(d +- symbol first destruct first destruct d,destruct
domainsOf(cat, nil)$Lisp)
Function declaration getDomains : Symbol - Set(Symbol) has been
added to workspace.
Type: Void
(21) - getDomains('Finite)
(21)
{AlgebraicFunctionField, Boolean, Character, CharacterClass, Complex,
DirectProduct, DirectProductMatrixModule, DirectProductModule,
FiniteField,
FiniteFieldCyclicGroup, FiniteFieldCyclicGroupExtension,
FiniteFieldCyclicGroupExtensionByPolynomial, FiniteFieldExtension,
FiniteFieldExtensionByPolynomial, FiniteFieldNormalBasis,
FiniteFieldNormalBasisExtension,
FiniteFieldNormalBasisExtensionByPolynomial,
HomogeneousDirectProduct,
InnerFiniteField, InnerPrimeField, IntegerMod, LieSquareMatrix,
MachineComplex, ModMonic, MonoidRing, Octonion,
OrderedDirectProduct,
OrderedVariableList, PrimeField, Product, RadicalFunctionField,
RectangularMatrix, Set, SetOfMIntegersInOneToN,
SimpleAlgebraicExtension,
SplitHomogeneousDirectProduct, SquareMatrix}
Thanks for the example code. It might be quite useful to know how to
call 'domainsOf(cat, nil)$Lisp'. Maybe there are some other functions
like this that really should be documented for the potential user.
Of course, most domains only export Finite conditionally. I'd omit those
at first, then the list is short, you can walk through it by hand.
Boolean
Character
CharacterClass
FiniteField,
FiniteFieldCyclicGroup
FiniteFieldCyclicGroupExtension,
FiniteFieldCyclicGroupExtensionByPolynomial
FiniteFieldExtension,
FiniteFieldExtensionByPolynomial
FiniteFieldNormalBasis,
FiniteFieldNormalBasisExtension,
FiniteFieldNormalBasisExtensionByPolynomial,
IntegerMod
...
No thanks, I really don't have time or sufficient interest to look at
each domain by hand. Also I do not see any automatic way to choose
parameters for those that are constructors. I think this idea will
have to wait for someone else looking for a small project to
contribute to FriCAS.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: hashable
On Wed, Nov 4, 2009 at 6:51 AM, Ralf Hemmecke wrote: What is bit juggling? Are you implying that Morton codes are not good hashing algoritms? No. It just looked to me as if the algorithm is rather costly. But I have not analysed anything, so I'll better be quiet. I do appreciate your comments. I think some kind of objective analysis would be a good idea but it is not immediately clear to me how to go about this. In particular I worry about apparent systematic flaws of the kind mentioned by Waldek. But since hashing is only approximate and statistical in nature I am not sure how to set up a good test for such cases. ... I wonder whether /src/interp/hashcode.boot could be of any help? Looks to me like a simple modulo operation with machine shifts, some additions. Why cannot that be used for lists of integers? I guess you mean the following code: $hashModulus := 1073741789 -- largest 30-bit prime -- Produce a 30-bit hash code. This function must produce the same codes -- as the asharp string hasher in src/strops.c ... -- Combine two hash codes to make a new one. Must be the same as in -- the hashCombine function in aslib/runtime.as in asharp. hashCombine(hash1, hash2) == MOD(ASH(LOGAND(hash2, 16777215), 6) + hash1, $hashModulus) -- Yes, I think this is a practical alternative to the simple xor in my first patch to lisp.spad. Because of MOD it is probably similar in computational complexity to a good implementation of Morton, but I am worried that using this iteratively does not treat all list elements equally - after a certain size higher weight is given to the last element hashed. I am not sure how to change that. Maybe one should adjust the modulus? But I guess that detecting the difference between this simple shift and merge versus Morton statistically would probably be difficult for most practical applications. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: domain definition
On Tue, Nov 3, 2009 at 7:05 AM, Bertfried Fauser wrote: Hi Ralf, the below attached code seems to compile OK. When I try to do a lehmerCodeToPermutation [2,1,3,4] I get a message: (2) - lehmerCodeToPermutation([1,3,2,4]) LISP output: UNPRINTABLE I guess I have to add an output form. I did it as -- declaration OUT == OutputForm coerce(%) - OUT -- exports coerce(x:%):OUT == (members x)::OUT (actually I would prefer round parentheses, but have no idea how this works, and its not necessary, users will not see this output finally. =no action needed) For future reference I think you should look at the function paren( ...)$OutputForm Probably the following will do what you want: coerce(x:%):OUT == paren((members x)::OUT) If that's OK, I can live with that, indeed it compiles and I can see a result as expected. Anyhow, I did not really understand what your code did differently? You need to know what 'import' does. It might seem strange at first but you can get exactly the same effect of import Vector Integer by just entering Vector(Integer) So the keyword 'import' is more of less just documentation. As I understand it evaluating this type expression has the affect of making all the exports of 'Vector(Integer)' visible by default to the code that follows (similar to ')expose' in the interpreter. As Ralf said, import Vector doesn't really make sese because Vector takes a parameter before it becomes a type. But now I can proceed, thank's, I need a further domain LehmerCode, but that schould be analogous. Earlier: On the axiom-wiki I found definitions where Rep == Vector Integer was used in stead of Rep := Vector Integer but changing this also does not help. Although Rep == Vector Integer is technically more correct since Rep is indeed supposed to be constant in the body of a domain definition, the Spad compiler in FriCAS does not quite treat it the same way. (Note: This behavior is changed significantly in OpenAxiom.) Although it is not required in Spad code, for type safety, compatibility with Aldor and also to make your code easier to write and read, I usually prefer to include definitions for 'rep' and 'per'. Look for example at the Tensor code written by Franz. In your case you can write: Rep := Vector Integer rep(x:%):Rep == x::Rep per(x:Rep):% == x::% FlatListPermutation: Exports == Implementation where L == List I == Integer OUT == OutputForm V == Vector Exports == Join(ConvertibleTo List Integer) with coerce: List Integer - % coerce: % - List Integer lehmerCodeToPermutation: L I - % Implementation == add import Vector Integer Rep := Vector Integer rep(x:%):Rep == x::Rep per(x:Rep):% == x::% coerce(lst: List Integer): % == vector lst coerce(lst: List Integer): % == per vector lst coerce(x: %): List Integer == entries x coerce(x: %): List Integer == entries rep x lehmerCodeToPermutation(lst:L I):% == perm: % := (vector lst) perm per vector lst --- Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: svn vs. darcs vs. git
On Wed, Oct 28, 2009 at 7:23 PM, Waldek Hebisch wrote: ... Distributed systems allow to easily create a lot of branches. This is certainly important for big projects. But we have only few developers. Given that for small changes the best strategy probably is to develop them outside the tree and then commit quickly I do not see need for many branches (a single person can meaningfully only work on few longer-lived branches). For this svn seem to be good enough. Let me say this in different way: when we have ten developers who want to use git I will happily switch too. I just discovered something new in svn that seems sure to make my life easier ... changelists There is a good description here: http://svnbook.red-bean.com/en/1.5/svn.advanced.changelists.html http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.changelist.html Subversion's changelist support allows you to create changelists by applying labels to files you want to be associated with that changelist, remove those labels, and limit the scope of the files on which its subcommands operate to only those bearing a particular label. Harry first creates a changelist and associates with it the two files he's already changed. He does this by using the svn changelist command to assign the same arbitrary changelist name to those files: $ svn changelist math-fixes integer.c mathops.c Path 'integer.c' is now a member of changelist 'math-fixes'. Path 'mathops.c' is now a member of changelist 'math-fixes'. $ svn status --- Changelist 'math-fixes': M integer.c M mathops.c $ Harry now sets off to fix the secondary UI problem. Since he knows which file he'll be changing, he assigns that path to a changelist, too. $ svn changelist ui-fix button.c svn: warning: Removing 'button.c' from changelist 'math-fixes'. Path 'button.c' is now a member of changelist 'ui-fix'. $ svn status --- Changelist 'ui-fix': button.c --- Changelist 'math-fixes': M integer.c M mathops.c $ And when it's time to commit, Harry can again use the --changelist option to limit the scope of the commit to files in a certain changelist. He might commit his user interface fix by doing the following: $ svn ci -m Fix a UI bug found while working on math logic. --changelist ui-fix Sendingbutton.c Transmitting file data . Committed revision 1158. $ This solves a problem that I have frequently - I have simultaneous changes in my source tree for different reasons but I sometimes want to commit just some of these changes as a related group. Finding out about svn changelists has delayed my decision to resort to a more intelligent local source repository manager. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: hashable
Bill Page wrote: Well as Waldek pointed out: The whole point of hashing is performance. Having all hashing implemented in Spad might be nice conceptually but it is quite possible that it might be difficult to obtain sufficiently high performance to justify the effort - at least not without some basic support at the Lisp level. On Tue, Nov 3, 2009 at 5:34 PM, Ralf Hemmecke wrote: I'm sorry. If because of performance reasons there has to be done something in LISP, that's not for me. Hashing is a concept that the right to be implemented at library level. (There might be another hashing mechanism at a lower level, but that is another business. I mainly care about the higer-level hashing.) If hashing at library level is too slow then one should improve the compiler and not require to add some LISP tricks to make it faster. Library code should be pure SPAD code. Nothing else and no tricks. Clean and pure. It's a lot of work to achieve that. I find it difficult to distinguish between improving the compiler and what you call LISP tricks. In some sense almost all compiler optimizations amount to tricks, i.e. they make use of special features of the underlying architecture whether it is hardware or the Lisp run-time system. An alternative to improving the compiler might be to hide all such tricks in a specially designed abstraction layer which is a domain that provides a higher level interface to the rest of the library. To some extent the library domain SExpression and the built-in domain Lisp already do this. Unfortunately they are rather low level and their use is currently scattered throughout the library. (In OpenAxiom Gaby has already begun to build such a machine abstraction layer.) Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: hashable
On Tue, Nov 3, 2009 at 5:44 PM, Ralf Hemmecke wrote: What is your opinion of the Morton code method of combining hash codes that I suggested in a previous email in this thread? No opinion. But instead of bit juggling one should rather check out what good hashing algorithms are. What is bit juggling? Are you implying that Morton codes are not good hashing algoritms? FriCAS certainly already computes hash values for its types, no? Why not lift similar algorithms to SPAD level. What algorithms already in FriCAS would apply to problems like computing a good hash for a list? And there is certainly a theory of hashes. http://en.wikipedia.org/wiki/Hash_function The good old Art of Computer Programming should be a reference. Yeah! We have literate programming so a chance to describe the theory accurately before there is the code. ;-) Who will do it? ;-) Must of the above is rather trivial. I think just listing such references should be adequate. For the record here are a few references to Morton codes: http://www.codexon.com/posts/morton-codes http://en.wikipedia.org/wiki/Z-order_%28curve%29 http://www.cs.umd.edu/~hjs/pubs/bulkload.pdf Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: build hangs building hyperdoc pages
Bill Page wrote: Does any of this give you a better clue what is happening? On Sun, Nov 1, 2009 at 11:33 PM, Waldek Hebisch wrote: Not much. One thing is if '/tmp/jazz1' was correctly created. Second, if '/tmp/jazz1' is owned by user trying to build FriCAS, etc. Output from strace should contain info if AXIOMsys actually got to execute 'rm' and wheter 'rm' succeeded. That is a very good question! The build stalled here again: p...@billpage:~/fricas-build$ tail nohup.out writing:write!(ifile, [7]) writing:reopen!(ifile, input) writing:read! ifile writing:read! ifile writing:readIfCan! ifile writing:readIfCan! ifile writing:iomode ifile writing:name ifile writing:close! ifile writing:)system rm /tmp/jazz1 So as you suggested I took a look at the file /tmp/jazz1 p...@billpage:~/fricas-build$ ls -l /tmp/jazz1 -rw-r--r-- 1 zope zope 36 2009-10-29 18:04 /tmp/jazz1 Now I notice the user and the date are NOT what I expect!. This file was created by another user and never removed. I manually removed this file and killed, then restarted make and it continues past this point.. Another mystery (almost) solved ... It stuck again at: writing:close! ey writing:keys ey writing:members ey writing:)system rm -r /tmp/editor.year Again I find: p...@billpage:~$ ls -l /tmp/editor.year total 4 -rw-r--r-- 1 zope zope 380 2009-10-29 18:04 index.KAF So rinse and repeat ... And it continues again, completing normally this time. I still do not know why the previous build apparently run by the user 'zope' (which is the user name used internally by the axiom-wiki) created these files but never deleted them. That is strange - both that it was user 'zope' that created these files and that neither file was deleted. Apparently this never had anything to do with parallel make - that was just inadequate control of my attempt at debugging. Thanks for your help! Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: hashable
Waldek, Thank you for your comments on hash tables. Bill Page wrote: So I think it would be a good idea to make the 'hashable' function in 'spad.lisp': (defun |knownEqualPred| (dom) (let ((fun (|compiledLookup| '= '((|Boolean|) \$ \$) dom))) (if fun (get (bpiname (car fun)) '|SPADreplace|) nil))) (defun |hashable| (dom) (memq (|knownEqualPred| dom) #-Lucid '(EQ EQL EQUAL) #+Lucid '(EQ EQL EQUAL EQUALP) )) a little smarter. This test only seems to check if the compiler was able to optimize equality to a lisp operator. I suppose we could improve the compiler but even failing that, there should be a way to recognize it at this level. I think it's something like having the 'Canonical' property all the way down. Any ideas? On Mon, Nov 2, 2009 at 2:46 PM, Waldek Hebisch wrote: Currently equality for List(Integer) is different than Lisp equality. We could try to change this. I think that solving the problem by adapting just one type like List to be compatible with 'hashable' is probably not worth the effort - unless we have a particular application in mind that would benefit greatly by this. Another possibility is to change hashable, hardcoding knowledge about FriCAS domains and Lisp equality. It does not sound like a good idea to hardcode knowledge of FriCAS domains in the Spad compiler if we can avoid it - except for a few bootstrap domains that must necessarily be at least partially built-in, e.g. Boolean, Record, Union etc. We could try to encode rules of Lisp equality in properties. But given that Lisp has four equality predicates and they behave differently with respect to recursion we probably would need 6 - 7 properties and a bunch of rules. I am affraid it would be more messy than puting all this into hashable. If we do this I think I would prefer a combination of the last two options. Perhaps we could choose just one Lisp equality, say EQUAL, than flag FriCAS domains by conditionally assigning a property (category), say 'CanonicalEqual' that implies that equality in this domain is consistent with Lisp EQUAL. Then 'hashable' would only have to know about this one built-in property. This might also have to be done by the compiler in some cases, e.g. Record and Union. I was also just a little surprised that this has nothing to do with the 'hash' function that is defined in almost all FriCAS domains. 'hash' defaults to 0 in a lot of important domains - even List! Here is a small patch to 'list.spad.pamphlet' to add a sensible hash function: wsp...@debian:~/fricas-sources/src/algebra$ svn diff list.spad.pamphlet Index: list.spad.pamphlet === --- list.spad.pamphlet (revision 713) +++ list.spad.pamphlet (working copy) @@ -114,6 +114,13 @@ z := concat((first x)::OutputForm, z) bracket concat_!(y, overbar commaSeparate reverse_! z) + hash(x: %):SingleInteger == + h:SingleInteger:=0 + while not Qnull x repeat + h := xor(h,hash Qfirst x) + x := Qrest x + h + xor has tendency to produce bad hashes, for example all two element lists having both elements equal will hash to 0. Better than what we how now, but still not production ready. I understand the limitations of xor but before we can evaluate the quality of a particular hash function I think it is necessary to make some assumptions about the population and desired properties of the distribution of the hash codes. That is, we need to first say In your example why we think it is interesting to treat two element lists having both elements equal as especially deserving of attention. In this case it is rather easy to resolve a collision by comparing just the first component of each list. But it general there are potentially many alternatives to consider since no hash method and no method of combining hash codes is both efficient and perfect. Right? xor does have the advantage of being very efficient and of treating all elements of the list with equal weight. If you think we can afford the cpu cycles (maybe a good assumption these days) I suppose that I would prefer to use a Morton code (z-order) for combining hash codes. Such codes try to preserve locality while mapping higher dimensions to one dimension and are used in efficient coding of spatial data and in database systems. Maybe locality is not so important but they also do not have the flaw that you observed in the simple xor. Unfortunately as a consequence they are much more expensive to compute, though Morton is a fairly low-level bit-oriented method that can be optimized at machine level. I think the following interpreter code works and should provide a clear example but may not be the most efficient implementation in Spad code. We start by mixing the bits of the hash codes of the first two elements (alternating) to produce a new hash code
[fricas-devel] Re: build hangs building hyperdoc pages
Bill Page wrote:
(1) - writing: ifile:File List Integer:=open(/tmp/jazz1,output)
writing: write!(ifile, [-1,2,3])
writing: write!(ifile, [10,-10,0,111])
writing: write!(ifile, [7])
writing: reopen!(ifile, input)
writing: read! ifile
writing: read! ifile
writing: readIfCan! ifile
writing: readIfCan! ifile
writing: iomode ifile
writing: name ifile
writing: close! ifile
writing: )system rm /tmp/jazz1
(At this point after waiting several hours I killed the make and sman
processes. I was expecting to see: 'making FILE.input', etc.
make[2]: *** [all] Terminated
/bin/bash: line 1: 1054 Terminated make
make[1]: *** [all-paste] Error 143
make[1]: Leaving directory `/home/page/fricas-build/src'
make: *** [all-src] Error 2
make[3]: *** Deleting file `FILE.pht'
make[3]: *** [FILE.pht] Terminated
p...@billpage:~/fricas-build$
---
I was able to determine that the code that generates these messages is
in 'src/hyper/htinp.c' but I do not know enough about this program to
even guess what might be suddenly going wrong. I do vaguely recall
your comments about a possible race condition.
Waldek wrote:
Yes, the communication between processes is not doing any
synchronization. But in non-parallel build on unloaded machine
we should always win races. I wonder if your problem is related
to bug 145 (it seems that bug 145 is appears because part of
input to AXIOMsys got discarded).
Is anyone else seeing these sort of failures? Do you have any ideas
for what I might try in order to debug this?
One thing I did was to move AXIOMsys to AXIOMsys.bin and
insted of binary AXIOMsys use script like:
#!/bin/sh
exec strace -o srapp.$$ /path/to/target/directory/AXIOMsys.bin $@
I tried this but the output looks complex and confusing to me. At some
point in the srapp file I begin to see Segmentation Fault:
...
open(/usr/lib/locale/ISO-8859-1/LC_CTYPE, O_RDONLY) = -1 ENOENT (No
such file or directory)
open(/usr/share/locale-langpack/ISO-8859-1/LC_CTYPE, O_RDONLY) = -1
ENOENT (No such file or directory)
readlink(/proc/self/exe,
/home/page/fricas-build/target/x86_64-unknown-linux/bin/AXIOMsys.bin...,
4096) = 68
open(/home/page/fricas-build/target/x86_64-unknown-linux/bin/AXIOMsys.bin,
O_RDONLY) = 3
lseek(3, -8, SEEK_END) = 74674216
read(3, LCBS\0\0\0\0..., 8) = 8
lseek(3, -16, SEEK_END) = 74674208
read(3, \...@\t\0\0\0\0\0..., 8)= 8
lseek(3, 606208, SEEK_SET) = 606208
lseek(3, 0, SEEK_CUR) = 606208
read(3, LCBS\0\0\0\0..., 8) = 8
lseek(3, -48, SEEK_END) = 74674176
read(3, U\363\3531\0\0\0\0\1\0\0\0\0\0\0\0\0\0\377\377\1\0\0\0\0\0
\0\0\0\0\0..., 32) = 32
close(3)= 0
uname({sys=Linux, node=billpage, ...}) = 0
personality(0x /* PER_??? */) = 4456448
mmap(NULL, 33554432, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x2b4c9000
mmap(0x2000, 1044480, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2000
mmap(0x2010, 1044480, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2010
mmap(0x10, 8589869056, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10
mmap(0x2020, 1044480, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2020
mmap(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2d4c9000
mprotect(0x2d4c9000, 4096, PROT_NONE) = 0
open(/etc/localtime, O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2d4ca000
read(3, TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0\0...,
4096) = 2819
lseek(3, -1802, SEEK_CUR) = 1017
read(3, TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0\0...,
4096) = 1802
close(3)= 0
munmap(0x2d4ca000, 4096)= 0
open(/home/page/fricas-build/target/x86_64-unknown-linux/bin/AXIOMsys.bin,
O_RDONLY) = 3
lseek(3, 606208, SEEK_SET) = 606208
read(3, LCBS\0\0\0\0\24\17\0\0\0\0\0\0\3\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0;...,
4096) = 4096
mmap(0x2000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x95000) = 0x2000
mmap(0x2010, 4096, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x97000) = 0x2010
mmap(0x10, 73904128, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x98000) = 0x10
lseek(3, 74526720, SEEK_SET)= 74526720
read(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
4096) = 4096
read(3, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
[fricas-devel] Re: tensor and the limits of spad
Franz, On Sat, Oct 31, 2009 at 4:24 AM, you wrote: On Fri, Oct 30, 2009 at 11:51:03PM -0400, Bill Page wrote: like to try to encourage you to commit the tensor code first in its current state without resolving this design decision. This was my intention, but I wouldn't commit if the build process breaks:) Coalgebra(R : CommutativeRing, RR : TensorPowerCategory(R, %)): Category == _ Module(R) with coproduct : % - RR Of course this has a rather different meaning! Also it includes an apparently recursive self-reference to the domain in which this category appears. Do you know if this sort of self-reference is used successfully elsewhere in the FriCAS/Axiom library? no, and aldor would have detected it :) But it compiles and runs in current spad as proven by Bertfrieds symmetric functions. Do you think we can define exactly what it should mean? Are you saying that you would like to be able to write something like: TensorPowerCategory(n:NonNegativeInteger,R:CommutativeRing, M : snip without limiting the ultimate value of n? no, just dropping n entirely (there is no significant use for it anyway), just as in Vector and Matrix for example. My questions was intended to ask why you considered this too rigid. I resist this given the usual mathematical treatment of tensor product. In the mean time I still would encourage you to commit first and ask questions later. :-) as soon as the aldor breakage is sorted out ... I meant of course only that part which does compile without errors using Spad. Aldor is not really part of FriCAS. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: tensor and the limits of spad
On Sat, Oct 31, 2009 at 12:53 PM, leh...@bayou.uni-linz.ac.at wrote: On Sat, Oct 31, 2009 at 10:30:31AM -0400, Bill Page wrote: Do you think we can define exactly what it should mean? I don't understand this question. What does the following recursive definition mean? Coalgebra(R : CommutativeRing, RR : TensorPowerCategory(R, %)): Category == _ Module(R) with coproduct : % - RR Specifically, if you specify that a domain satisfies this category what does RR represent? It appears that the domain is somehow recursive since we cannot know what is this domain unless we know what is RR. We cannot know what is RR unless we first know what is the domain. So the meaning is not immediately clear to me. I wonder how you and Bertfried interpret this definition? My questions was intended to ask why you considered this too rigid. because I do not know how to define tensor: (TensorPower(m,M),TensorPower(n,M)) - TensorPower(m+n,M) without a lot of typing. The same decision apparently was made with Matrix and Vector. I think the appropriate mode for Tensor is not Matrix (which has a clear and simple category) but rather SquareMatrix. See especially the definition: SquareMatrixCategory(ndim,R,Row,Col): Category == Definition where ndim : NonNegativeInteger R: Ring Row : DirectProductCategory(ndim,R) Col : DirectProductCategory(ndim,R) ... Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] building rev 717
Franz,
I had trouble building FriCAS revision 717. It stopped with an error
involving BIALG.spad. No BIALG.NRLIB was found.
I made the following changes to 'tensor.spad.pamphlet'
wsp...@debian:~/fricas-sources$ svn diff --changelist tensor
Index: src/algebra/tensor.spad.pamphlet
===
--- src/algebra/tensor.spad.pamphlet(revision 717)
+++ src/algebra/tensor.spad.pamphlet(working copy)
@@ -456,7 +456,7 @@
@
\section{category COALG Coalgebra}
-category COALG Coalgebra TensorPower=
+original category COALG Coalgebra TensorPower=
--Bialgebra(R : CommutativeRing, MxM : TensorPowerCategory(2, R, %))
: Category == _
@
but this is too restrictive and fails with aldor.
@@ -491,7 +491,7 @@
\section{category BIALG Bialgebra}
Originally it was
-category BIALG Bialgebra TensorPower=
+original category BIALG Bialgebra TensorPower=
--Bialgebra(R : CommutativeRing, MxM : TensorPowerCategory(2, R, %))
: Category == _
@
but this is too restrictive and fails with aldor.
@@ -524,7 +524,7 @@
\section{category HOPFALG HopfAlgebra}
Originally it was
-category HOPFALG HopfAlgebra TensorPower=
+original category HOPFALG HopfAlgebra TensorPower=
HopfAlgebra(R : CommutativeRing, MxM : TensorPowerCategory(2, R, %))
: Category _
@
but this is too restrictive and fails with aldor.
---
The explanation is that there is something magic about pamphlet
chunk names of the form
category BIALG Bialgebra TensorPower=
(for category, domain, and package)
There is an awk script that searches through all the pamphlet files in
order to create rules to tell make how to extract 'BIALG.spad'. It
seems that the way you wrote the names, the first occurrence of
category BIALG ... gets overridden by the second chunk with the
same prefix. By adding original category ... awk no longer sees
these chunks.
With this change the build proceeds to completion and I am now
enjoying the new Tensor domain in FriCAS. Thank you!
Regards,
Bill Page.
On Sat, Oct 31, 2009 at 7:25 PM, ceram...@users.sourceforge.net wrote:
Revision: 717
http://fricas.svn.sourceforge.net/fricas/?rev=717view=rev
Author: cerambyx
Date: 2009-10-31 23:25:19 + (Sat, 31 Oct 2009)
Log Message:
---
new categories, domains and output routines for tensor products of free
modules.
...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: tensor and the limits of spad
Franz,
On Fri, Oct 30, 2009 at 3:22 PM, you wrote:
I was about to commit tensor, however there is a design decision
to be made first.
I will comment later on the substantive question but first I would
like to try to encourage you to commit the tensor code first in its
current state without resolving this design decision. Committing early
and committing often is a natural part of open source software
development. It allows more people to participate in the work at an
earlier stage. One should not fear that what one commits to the
repository is written in stone since it is the very purpose of these
source code control tools to make it easy to manage continual bug
fixes and even major changes in design. This way of working is a
serious departure from previous writing software and it seems to work
well for those people who subscribe to it in a whole hearted manner.
For example, I think the Sage project is an excellent confirmation of
this claim.
Currently, for Coalgebras we have
coproduct:%- TensorPowerCategory(2,R,%)
this compiles fine with spad, but aldor complains.
This looks very strange to me. Maybe it is only a typographical error?
Is this function really supposed to return a domain as it's value? If
so, I would not be confident at all that this will work as expected
(if at all) in most versions of Axiom although it might be possible in
Aldor. Note especially that there are likely now significant
differences in how OpenAxiom would treat such functions.
In a later email I see that you wrote:
Coalgebra(R : CommutativeRing, RR : TensorPowerCategory(R, %)): Category == _
Module(R) with
coproduct : % - RR
Of course this has a rather different meaning! Also it includes an
apparently recursive self-reference to the domain in which this
category appears. Do you know if this sort of self-reference is used
successfully elsewhere in the FriCAS/Axiom library?
Anyways TensorPowerCategory(n,R,M) is rather rigid and I am
going to drop n to simplify a few things. There are ups and
downs to this.
...
Are you saying that you would like to be able to write something like:
TensorPowerCategory(n:NonNegativeInteger,R:CommutativeRing, M :
Module(R)):Category == Module(R) with
tensor: (List M) - %
++ \spad{tensor([x1,x2,...,xn])} constructs the tensor
++ product of \spad{x1,x2,...,xn}.
if M has Algebra(R) then Algebra(R)
if n=2 then TensorProductCategory(R,M,M)
if n=3 then TensorProductCategory(R,M,TensorProductCategory(R,M,M))
if n=4 then
TensorProductCategory(R,M,TensorProductCategory(R,M,TensorProductCategory(R,M,M)))
...
without limiting the ultimate value of n?
I would like to comment on this but it is going to take me some more
time to consider the alternatives.
In the mean time I still would encourage you to commit first and ask
questions later. :-)
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] hashable
I was trying to add an example of using Ralf's new CachedFunction domain
http://axiom-wiki.newsynthesis.org/SandBoxCachedFunction
with a function with more than one argument. I was surprised to learn
that 'Table' only uses an efficient hashing method if
'hashable(Key)$Lisp' is true, where 'Key' is
the first domain of 'Table(Key,Entry)'. This is true for 'Integer' and
'String' but not 'Record(x1:Integer,x2:Integer)' or even
'List(Integer)'. But as far as I can see the implementation of 'List'
and 'Record' in Axiom do satisfy the requirements for the use of
HashTable:
++ This creates a \spadtype{HashTable} if equal for the Key
++ domain is consistent with Lisp EQUAL otherwise an
++ \spadtype{AssociationList}
if their component domains do. So I think it would be a good idea to
make the 'hashable' function in 'spad.lisp':
(defun |knownEqualPred| (dom)
(let ((fun (|compiledLookup| '= '((|Boolean|) \$ \$) dom)))
(if fun (get (bpiname (car fun)) '|SPADreplace|)
nil)))
(defun |hashable| (dom)
(memq (|knownEqualPred| dom)
#-Lucid '(EQ EQL EQUAL)
#+Lucid '(EQ EQL EQUAL EQUALP)
))
a little smarter. This test only seems to check if the compiler was
able to optimize equality to a lisp operator. I suppose we could
improve the compiler but even failing that, there should be a way to
recognize it at this level. I think it's something like having the
'Canonical' property all the way down.
Any ideas?
I was also just a little surprised that this has nothing to do with
the 'hash' function that is defined in almost all FriCAS domains.
'hash' defaults to 0 in a lot of important domains - even List! Here
is a small patch to 'list.spad.pamphlet' to add a sensible hash
function:
wsp...@debian:~/fricas-sources/src/algebra$ svn diff list.spad.pamphlet
Index: list.spad.pamphlet
===
--- list.spad.pamphlet (revision 713)
+++ list.spad.pamphlet (working copy)
@@ -114,6 +114,13 @@
z := concat((first x)::OutputForm, z)
bracket concat_!(y, overbar commaSeparate reverse_! z)
+ hash(x: %):SingleInteger ==
+ h:SingleInteger:=0
+ while not Qnull x repeat
+ h := xor(h,hash Qfirst x)
+ x := Qrest x
+ h
+
x = y ==
Qeq(x,y) = true
while not Qnull x and not Qnull y repeat
But like I said, this does not have any affect on whether or not
domains like 'List(Integer)' are hashed in the 'Table'.
I suppose another option besides making 'hashable' smarter would be to
add a new 'HashTable' type to 'table.spad.pamphlet' that actually
makes use of the FriCAS hash function.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: Generic Cached Functions
I looked at this is some detail and tried several things via the interpreter. Dynamically modifying $clamList is not sufficient to cause a previously compiled SPAD function to be cached. To the best of the my ability to tell this facility is intended to be used with the BOOT compiler for the functions collected in the file 'clammed.boot'. It seems to me that support for caching these functions is buit-in to the lisp code generated by the BOOT compiler. I do not see any way to use this without writing the code to be cached at the BOOT level. But I would be glad to be shown that I am wrong. Here is a partial interpreter session showing my attempt to understand what is going on in the code. One thing I am least certain about is what to use as the name of the SPAD function to be cached. Normally Spad functions are called at the BOOT level via a lisp macro named SPADCALL and the mangled function name (as shown below for the gcd function) is only a part of this process but I do not see anything else that might be intended to server this purpose for the clam caching mechanism. (1) - _$clamList$Lisp (1) ((canCoerce hash UEQUAL count) (canCoerceFrom hash UEQUAL count) (coerceConvertMmSelection hash UEQUAL count) (hasFileProperty hash UEQUAL count) (isLegitimateMode hash UEQUAL count) (isValidType hash UEQUAL count) (resolveTT hash UEQUAL count) (selectMms1 hash UEQUAL count) (underDomainOf hash UEQUAL count)) Type: SExpression (2) - )set message time on (2) - for i in 1..1000 repeat for j in 1..100 repeat gcd(i,j) Type: Void Time: 0.06 (IN) + 2.12 (EV) = 2.18 sec (3) - -- get the internal name of the gcd function (3) - (gcd$Integer::OutputForm::SEX).2 There is more than one gcd in the domain or package Integer . The one being chosen has type ((Integer,Integer) - Integer) . (3) INT;gcd;3$;51 Type: SExpression Time: 0.01 (OT) = 0.01 sec (4) - -- add it to $clamList (4) - )lisp (setq |$clamList| (concatenate 'list |$clamList| '((|INT;gcd;3$;51| |hash| UEQUAL |count| Value = ((|canCoerce| |hash| UEQUAL |count|) (|canCoerceFrom| |hash| UEQUAL |count|) (|coerceConvertMmSelection| |hash| UEQUAL |count|) (|hasFileProperty| |hash| UEQUAL |count|) (|isLegitimateMode| |hash| UEQUAL |count|) (|isValidType| |hash| UEQUAL |count|) (|resolveTT| |hash| UEQUAL |count|) (|selectMms1| |hash| UEQUAL |count|) (|underDomainOf| |hash| UEQUAL |count|) (|INT;gcd;3$;51| |hash| UEQUAL |count|)) (4) - for i in 1..1000 repeat for j in 1..100 repeat gcd(i,j) Type: Void Time: 2.10 (EV) = 2.10 sec (5) - -- see if anything happened (5) - clamStats()$Lisp canCoerce ( 1 entries) canCoerceFrom ( 1 entries) coerceConvertMmSelection ( 4 entries) hasFileProperty ( 0 entries) isLegitimateMode ( 4 entries) isValidType ( 3 entries) resolveTT ( 0 entries) selectMms1 ( 6 entries) underDomainOf ( 6 entries) Internal Error Unexpected error in call to system function clamStats (5) - -- try to clean up (5) - clearClams()$Lisp Internal Error The cache for INT;gcd;3$;51 cannot be cleared because that function is not privately clammed. (6) - )lisp (setq |$clamList| (reverse (rest (reverse |$clamList| Value = ((|canCoerce| |hash| UEQUAL |count|) (|canCoerceFrom| |hash| UEQUAL |count|) (|coerceConvertMmSelection| |hash| UEQUAL |count|) (|hasFileProperty| |hash| UEQUAL |count|) (|isLegitimateMode| |hash| UEQUAL |count|) (|isValidType| |hash| UEQUAL |count|) (|resolveTT| |hash| UEQUAL |count|) (|selectMms1| |hash| UEQUAL |count|) (|underDomainOf| |hash| UEQUAL |count|)) You can find a few possibly relevant details about internal organization written by Tim Daly here: http://axiom-wiki.newsynthesis.org/book--main--1/Bookvol4 (recently updated from the Axiom git repository) Regards, Bill Page. On Thu, Oct 29, 2009 at 4:01 PM, Ralf Hemmecke wrote: Tim Daly allowed me to post this message to the mailing list... so... if somebody is interested to dig deeper into boot code... Ralf On 10/28/2009 03:59 AM, Tim Daly wrote: See src/interp/clam.boot for an internal mechanism for caching functions. You could dynamically add the compiled function to the internal clam list. I wrote some documentation at the head of the clam.boot file. Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email
[fricas-devel] Re: InputForm, was: output
Yes, strange. Which Lisp? Which version? On Wed, Oct 28, 2009 at 11:14 AM, Martin Rubey wrote: Bill Page writes: On Wed, Oct 28, 2009 at 4:01 AM, Martin Rubey wrote: Bill Page writes: Do you mean that 'unparse(%)' works for you? What version of FriCAS and lisp are you using? fricas 711, your patch and OH, I just realised: the patch I send some time ago to the list for segment... You did not answer the question: Do you mean that 'unparse(%)' works for you? Oh, sorry. yes, it did work for me. I presume that the answer is that it does *not* work for you either in spite of your additional patch since the problem seems to be unrelated. Strange. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: InputForm, was: output
Thanks. Maybe that explains the difference. I've got: wsp...@debian:~/fricas-build$ sbcl --version SBCL 1.0.30 Built from source, bootstrapped from the original Debian 5.0 binary. I don't recall exactly right now but I think there was some reason why the Debian version was too old for FriCAS. Waldek, do you recall? Maybe newer versions of sbcl are better at trapping errors? On Wed, Oct 28, 2009 at 11:37 AM, Martin Rubey wrote: Bill Page writes: Yes, strange. Which Lisp? Which version? sbcl, I think 1,0.11 debian. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: generating matrices with complicated entries
On Wed, Oct 28, 2009 at 12:54 PM, Bertfried Fauser wrote: isn't it rather Polynomial Fraction Integer then? I am actually not sure what kind of difference there is between FPI == Fraction Polynomial(Integer) and FPFI == Fraction Polynomial(Fraction Integer) I a (formal) polynomial ring, I can specialize the values of the polynomials to any (transcendent) value and get a ring extension. I do not know how FriCAS deals with that, but I would guess that in FPI I can substitite a variable only by an Integer FPFI I can substitute a variable by a Fraction Integer No, this is a fairly common confusion about 'Polynomial' and related domains like 'Expression'. The parameter 'Integer' or 'Fraction Integer' refers only and specifically to the domain of the coefficients of the polynomial. This domain must be a Ring. FriCAS does not place any conditions or restrictions on substitutions of a variable. A variable is only an abstract symbol with no other type associated with it at all. It is usually correct to think of the variables as generators and this can be made explicit by an assignment such as: x:Polynomial(Integer):='x (Here 'x means explicitly the Symbol x and not the variable or polynomial generator x.) If you are thinking about division of polynomials the domain 'Fraction Polynomial Integer' might also be interesting. Or in more general contexts you might be interested in Laurent polynomials which you can get in FriCAS by a somewhat different construction. ... Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: generating matrices with complicated entries
On Wed, Oct 28, 2009 at 1:54 PM, Bertfried Fauser wrote:
Bill Page wrote:
No, this is a fairly common confusion about 'Polynomial' and related
domains like 'Expression'. The parameter 'Integer' or 'Fraction
Integer' refers only and specifically to the domain of the
coefficients of the polynomial.
OK, that is very fine, but confusing. So a 'generator' has no special type?
I am happy that you continue to ask questions. But also I do not want
to give the impression that I am necessarily the person with
definitive answers ... I also have questions too and sometimes what I
write is based on only what I know at the time. So it is good to be a
little skeptical and to continue to ask questions at least until you
start to think you can answer similar questions from someone else. :-)
It's usually better to deal with specific examples rather than
generalities. So in this case first consider a polynomial domain such
as
(1) - )sh MultivariatePolynomial
MultivariatePolynomial(vl: List(Symbol),R: Ring) is a domain constructor
Abbreviation for MultivariatePolynomial is MPOLY
...
I will talk about the domain Polynomial a little further on. I think
that just to get to the point of writing:
(1) - MultivariatePolynomial(['x,'y,'z],Integer)
(1) MultivariatePolynomial([x,y,z],Integer)
Type: Domain
requires a bit of explanation. Something are made a bit less clear
because the interpreter is try (perhaps to hard) to make things easier
for you. The notation 'x above (with a leading ' ) is the standard way
to specify a value in the domain Symbol. But if you type this in
FriCAS
(2) - 'x
(2) x
Type: Variable(x)
(3) - x
(3) x
Type: Variable(x)
it might seem like both 'x and x are equivalent. What is happening is
that the interpreter is already applying some automatic coercions from
the domain Symbol to the domain constructor Variable( )
(4) - )sh Variable('x)
Variable(x) is a domain constructor.
Abbreviation for Variable is VARIABLE
This constructor is not exposed in this frame.
--- Operations
?=? : (%,%) - Booleancoerce : % - OutputForm
coerce : % - Symbol hash : % - SingleInteger
latex : % - String variable : () - Symbol
?~=? : (%,%) - Boolean
And by default since x has not yet been assigned any type or value, it
is temporarily treated as just a Symbol which gets coerced to the
domain Variable(x). So it means that initially and often, we can use x
instead of always writing 'x.
All of this probably sounds like it is more than you really wanted to
know ... but I think it is really necessary in order to answer your
question: So a 'generator' has no special type? You see that in
spite of (1) above nothing has changed in the treatment of x, y and z
yet.
(4) - x:MultivariatePolynomial(['x,'y,'z],Integer)
Type: Void
(5) - x
(5) x
Type: MultivariatePolynomial([x,y,z],Integer)
Now x has been given a type but it still does not have any value. In
spite of this, FriCAS allows you to use it in computations as if if
it was a generator.
(7) - p:=x+1
(7) x + 1
Type: MultivariatePolynomial([x,y,z],Integer)
Suppose we do assign it some value.
(8) - x:=1
(8) 1
Type: MultivariatePolynomial([x,y,z],Integer)
Now x is the **polynomial**
1$MultivariatePolynomial([x,y,z],Integer). But x remains a symbol in p
(9) - p
(9) x + 1
Type: MultivariatePolynomial([x,y,z],Integer)
This probably seems odd for example to someone who is used to Maple.
We could just as easily have written:
(10) - x:='x
(10) x
Type: MultivariatePolynomial([x,y,z],Integer)
or
(11) - )clear value x
(11) - x
(11) x
Type: MultivariatePolynomial([x,y,z],Integer)
I think you would agree that a polynomial generator is necessarily a
polynomial, right? I guess I would have to say that the only thing
that could be called a generator so far is the 'x **in the appropriate
context**, e.g. in (10) above. Immediately after (10) we have the
situation where the value of x is exactly this generator.
Perhaps I should stop at this point and ask if this is just trivial or
something that really needs to be explained in such seemingly pedantic
detail?
About the domain Polynomial. Polynomial(Integer) is almost like
MultivariatePolynomial(['x,'y,'z],Integer) except the parameter
List(Symbol) is replaced with the domain Symbol itself. In fact there
are several other sets of polynomial-style domains which take domains
like Symbol and other more restrictive domains
[fricas-devel] Re: generating matrices with complicated entries
On Wed, Oct 28, 2009 at 2:17 PM, Martin Rubey wrote: Bill Page writes: On Wed, Oct 28, 2009 at 12:54 PM, Bertfried Fauser wrote: isn't it rather Polynomial Fraction Integer then? I am actually not sure what kind of difference there is between FPI == Fraction Polynomial(Integer) and FPFI == Fraction Polynomial(Fraction Integer) I a (formal) polynomial ring, I can specialize the values of the polynomials to any (transcendent) value and get a ring extension. I do not know how FriCAS deals with that, but I would guess that in FPI I can substitite a variable only by an Integer FPFI I can substitute a variable by a Fraction Integer No, this is a fairly common confusion about 'Polynomial' and related domains like 'Expression'. I disagree. As a good friend of mine often says: It is good that you disagree - otherwise there would not be much point in continuing this conversation - but with what exactly to you not agree? If you mean that you disagree that this is a fairly common confusion then I think I could quite easily cite emails in the archives to demonstrate otherwise. But maybe that is not such an important point. The parameter 'Integer' or 'Fraction Integer' refers only and specifically to the domain of the coefficients of the polynomial. This domain must be a Ring. FriCAS does not place any conditions or restrictions on substitutions of a variable. But specific domains do: POLY R exports InnerEvalable(Symbol, R), which means that there is a function eval : (%,Symbol,R) - % It is however correct to say that a priori, the symbols have no meaning, i.e., just because you see an x printed on the screen does not mean that there is a function that allows you to substitute something for that x... Note that all of the 'eval' operations return values in %, i.e. the domain in which they are defined. So nothing about 'eval' means that values of a domain like Polynomial(R) are in any sense R-valued. Bertfried wrote: _all_ I want for the moment is the following: I have a polynomial in a formal parameter (which I not yet want to specify), say q. If you have only one parameter, SparseUnivariatePolynomial (short: SUP) is a good choice. In this case, there is a simpler way to substitute for the variable: (7) - p := univariate(x^2+z*x+1, x) 2 (7) ? + z ? + 1 Type: SparseUnivariatePolynomial(Polynomial(Integer)) (8) - p.2 (8) 2z + 5 Type: Polynomial(Integer) This polynomial lives in Fraction Polynomial(Fraction Integer) (at the moment). I know that for integral q the polynomial is an integer, for rational q it is a rational, for generic q it may live where ever q lives. domains in UnivariatePolynomialCategory(R) export Eltable(Fraction(%),Fraction(%)) if R has IntegralDomain Eltable(%,%) Eltable(R,R) I guess the latter of which means they can always be viewed as a function into the base ring (39) - )show Eltable Eltable(S: SetCategory,Index: Type) is a category constructor Abbreviation for Eltable is ELTAB This constructor is exposed in this frame. --- Operations ?.? : (%,S) - Index I don't see any reason why this notion could not be extended to multivariate polynomials, i.e. NaryEltable ... I suppose that this is saying something like we can consider a polynomial over the ring R that has NaryEltable(R,R) to be R-valued. There is a mapping package called PolynomialCategoryLifting (POLYLIFT) that allows such generic substitutions. However, if you know where your q will live, say in a domain X, you should consider using SUP(X), because then substitution operations are provided. Yes, I like that. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Generic Cached Functions
On Wed, Oct 28, 2009 at 4:53 PM, Ralf Hemmecke wrote:
http://axiom-wiki.newsynthesis.org/SandBoxCachedFunction
Because we must explicitly say that domains
A and B are in SetCategory it makes sense that all cached functions
A-B should be treated as being in SetCategory.
Why?
++ \spadtype{SetCategory} is the basic category for describing a collection
++ of elements with \spadop{=} (equality) and \spadfun{coerce} to output
form.
The name is actually misleading. We have a difference between
constructive and non-constructive mathematics. FriCAS deals only with
the constructive part.
As Martin said to me earlier: I disagree. :-)
So existence of = means that I can compute it.
But for general functions I cannot.
My proposal is that a CachedFunction is not a general function because
we have said that it's domain and co-domain are from SetCategory.
Just comparing the cache is completely useless, because when you suppose
that f: INT-INT is some function and
g := cachedFunction f
h := cachedFunction f
then
(h = g)@Boolean
would probably return true, but
x := g 0
(h = g)@Boolean
would return false. You cannot want that.
It depends entirely what you want = to mean. We could say that it
means only that two CachedFunctions are equal *in the domain over
which they have so far been evaluated*. I think this is a perfectly
consistent definition although whether it is useful or not depends on
just what you want to do.
For this reason I reject your suggestion to make CachedFunction export
SetCategory.
SetCategory is also unwanted. One cannot usually print a function. What
should this be? It's memory location?
I would like the OutputForm of a CachedFunction to be the same as the
underlying Table (i.e. the cache).
Since a CachedFunction is obviously more than just it's cache perhaps
this is debatable but as far as I can see otherwise FriCAS does not
define equality for functions at all. I.e. All functions are in the
built-in domain 'Mapping' but '=' is not exported by 'Mapping'.
As I said: its debatable. I hope I provided a reasonable possible
use-case above.
Also I wonder if it might not be more useful to define 'function' as follows:
function(x: %): A - B == (a:A):B +- apply(x,a)
in order to take advantage of the cache but still treat it as a real
function to the rest of FriCAS instead of having to depend on 'apply'.
I think there are some instances where 'apply' does not apply such as
when passing a function to 'map'.
Look at the timings at the bottom of
http://axiom-wiki.newsynthesis.org/SandBoxCachedFunction and you will
see that you don't need such a definition.
The definition
recursiveDefine(fib,(n:I):I+-if n2 then 1 else fib(n-1) + fib(n-2))
is enough.
I mean, can you use the output of recursiveDefine directly in a map, e.g.
map(fib,[10,20,30,40])
If you could, how would that compare to?
map(function fib,[10,20,30,40])
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: InputForm, was: output
about it. But you are right about not having enough time to do everything we want to do. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Generic Cached Functions
On Wed, Oct 28, 2009 at 6:19 PM, Ralf Hemmecke wrote: You are a hard nut. :-) OK. Then let's disagree. Thanks. I mean, can you use the output of recursiveDefine directly in a map, e.g. map(fib,[10,20,30,40]) If you could, how would that compare to? map(function fib,[10,20,30,40]) If fib: CachedFunction(I, I) then clearly map(fib,[10,20,30,40]) must give a compile time error unless you define another map function that accepts a CachedFunction as its first argument. Why don't you like the second option with function fib? Just that given: function(x: %): A - B == x.fun the operation map(function fib,[10,20,30,40]) is not cached. But it's not such a big deal. One can always write: map(x+-fib(x),[10,20,30,40]) Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: svn vs. darcs vs. git
On Wed, Oct 28, 2009 at 6:40 PM, Bertfried Fauser wrote: I have tried to set up a git repository on my ancient server in Konstanz, unfortunately the SuSE 8.1 running there is to old to compile it. Anyhow the server is very unstable, but I could ask local computer people to get access to a machine here and set up a git ? As I understand it, git like darcs does not require anything other than a common web server to be able to distribute a public repository. All of the rest of the work is done by the programs installed on your local workstation/laptop. No? Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: svn vs. darcs vs. git
On Wed, Oct 28, 2009 at 6:28 PM, Ralf Hemmecke wrote: BTW, maybe I will start using darcs again locally as a way of more easily staging patches. Why not use git? Not just locally but switch the whole fricas tree at sourceforge? Using git is for the basic things that we use as easy as using svn. But it would be much easier to keep track of other people's work outside of sourceforge. Comparison GIT -- SVN: http://git.or.cz/course/svn.html Thanks Ralf that was useful although I did not intend to start a sccs war here. :-) The only reason I can give is a platitude: One should not use a tool that is more complicated than necessary for the task. Like svn, git seems too complicated to me. But I am sure it could do the job and it is fully distributed too. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Generic Cached Functions
On Wed, Oct 28, 2009 at 6:42 PM, Bertfried Fauser wrote: Uff I am sorry I started this, I will store all these mails and look at them later, have to fokus on plethysms Don't worry. This is not typical. There will be long periods of silence where you can get some real work done. It is just interesting suddenly that someone new is asking interesting questions here. :-) Am I naive with the following (down to earth) approach: Given I have a function, say: MurNak(Partition,Partition) - Integer May I not just implement inside the function a table with key= (part,part) (possibly somehow turned into a hash value) value = result of Murnak(part,part) for that pair. If the function is called, it looks up if a value is in the cache/table, if so fine, else compute the value, store it and return it. The outside world never wold even see that some caching is going on. Anyhow, caching can cause side effects, and may need vast amount of memory, so it has to be used with care and hindsight anyhow. Yes you can - well almost. The slight complication is to decide where you are going to store the table. A possible answer is that it might be part of the domain where the function is defined. The domains that Franz and Ralf have designed on the other hand are intended essentially to act like such containers for the table. It is really not much more complicated than that. In the case of a two argument function you first need to define a simple domain of SetCategory that combines two domains into one. Examples of such domains are 'Product' and 'Record' (also 'List' and 'DirectProduct' are good if the same domain is used twice). So given that you want a function with the signature MurNak: (Partition,Partition) - Integer what you do is first define a related function such as MurNak2: Record(x1:Partition,x2:Partition) - Integer And where you might have written the function like this: MurNak(x1:Partition,x2:Partition):Integer == ... x1 ... x2 ... with 'x1' and 'x2' parameters of the function, you now write instead MurNak2(arg):Integer == ... arg.x1 ... arg.x2 ... Here 'arg' is a single parameter that refers to the Record. 'arg.x1' is it's first component and 'arg.x2' is it's second component. One calls MurNak2 like this MurNak2 [a,b] for some values a and b. The brackets [a,b] construct a value of type Record(x1:Partition,x2:Partition) on which MurNak2 operates. Now you can define a cached version of this using Ralf's new domain constructor: MurNakCached2:CachedFunction(Record(a1:Partition,a2:Partion),Integer) := cachedFunction(MurNak2) and you call it like this MurNakCached2 [a,b] Or if you want you can wrap it up as the original two argument function like this: MurNak(x,y) == MurNakCached2 [x,y] It's easier than this sounds. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: output
On Mon, Oct 26, 2009 at 11:02 PM, Waldek Hebisch wrote:
Martin wrote:
unparse((2*product(factorial i, i=0..n))::OUTFORM::INFORM)
makes fricas crash...
The crash was due to spurious line that from the rewrite time.
And it crashed on legal input too...
Thanks for finding the problem!
Bill Page wrote:
I guess it's no excuse for a break condition but I presume you
intended to write:
(11) - unparse((2*product(factorial i, i=0..n))::INFORM)
(11) 2*%defprod(factorial(%A),%A,i,0,n)
Type: String
Another question is what we should generate for products,
sums and integrals. The current result is _not_ valid as input...
Yes, that is an important point. Considering just product for the
moment, I took a quite look at the code in 'combfunc.spad.pamphlet'.
It seems that what one might like to produce as a general InputForm in
this case is
opdprod(factorial(%A),%A,i,0,n)
but 'opdprod' is not exported by 'CombinatorialFunction'. We do have
opdprod := operator('%defprod)$CommonOperators
evaluate(opdprod, iidprod)
iidprod l ==
(r1:=retractIfCan(fourth l)@Union(Z,failed))
case failed or
(r2:=retractIfCan(fourth rest l)@Union(Z,failed))
case failed or
(k:=retractIfCan(second l)@Union(K,failed)) case failed
= idprod l
*/[eval(first l,k::K,i::F) for i in r1::Z .. r2::Z]
and of course 'iidprod' is exported so we can write:
(5) - iidprod([factorial(%A),%A,i,0,n])$CombinatorialFunction(INT,EXPR INT)
n
++-++
(5) | | i!
| |
i = 0
Type: Expression(Integer)
Really I suppose it would make sense to make the operators such as
'opdprod' available for this purpose and define
opdprod := operator('opdprod)$CommonOperators
But watch out for infinite loops here!
I was not able to locate any explicit code for coercion to InputForm.
Did I just miss it? If not I presume that the coercion is done via
OutputForm as Martin's original example may have implied:
setProperty(opdprod, SPECIALDISP, ddprod@(List F - O) pretend None)
ddprod l ==
prod(summand(l)::O, third(l)::O = fourth(l)::O, fourth(rest l)::O)
Do you see any other way?
It seems that Martin re-wrote major parts of this pamphlet file. I
hope he has time to take a look at this.
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: HTML Dyperdoc
On Tue, Oct 27, 2009 at 10:09 AM, John Thingstad wrote: I would like to participate by writing a browser interface to Fricas Hypercdoc. Also I feel the graphics system should be replaced by GNU Plot. This would free you from the dependencies of X Windows and allow a cleaner Windows port. In general it makes it easier to maintain the code. I ask some time however to familiarize myself with axiom and the source code before I would partake in such a endeavour. Say 6 month's. Tell me if this is interesting. Certainly it is interesting! :-) Maybe we have just been waiting for your arrival here ... there have never been enough resources to work on FriCAS or Axiom in general. A few comments: I think that compared to the existing FriCAS graphics GNU Plot has some limitations but an additional graphics interface would certainly be welcome. David Cyganski and I have done some very preliminary work on this here: http://axiom-wiki.newsynthesis.org/GnuDraw Interfacing to Hyperdoc as such is probably not a good idea. Hyperdoc itself is a kind of special purpose browser which as Martin noted was written long before there even was a general concept of such things. Instead of HTML it uses an extended subset of TeX as the markup language. What might be interesting however is the application interface between Hyperdoc and FriCAS. Unfortunately, like many of the other parts of FriCAS, this is still very poorly documented so you will have to learn to read the C, Lisp and Boot code that implements the current interface before being able to make use of it. If you undertake to do this I think you will find a few other people on this list willing to help. You might be interested to know that converting Hyperdoc to a more conventional browser has been done before. As usual with Axiom this is a long story, but again, before web browsers became common there was a browser-like system called TechExplorer. When the commercial version of Axiom was ported to run on Windows Hyperdoc was replaced with a TechExplorer-based user interface. Some of the hooks for this integration still exist in FriCAS. Unfortunately due to commercial licensing restrictions this work was never made available as open source. TechExplorer continues to exist as a web-browser plugin: http://www.integretechpub.com/techexplorer/ It is not open source but it is free http://www.integretechpub.com/news/license.php Probably the licensing issues have prevented anyone from seriously considering it as an option but if there was interest there is a possibility that Integre might be convinced to release in source form for use with FriCAS... Just an idea. Maybe it is no longer an interesting option now that MathML is more widely available. There is also the project by Arthur Ralfs and Alfredo Portes http://code.google.com/p/jyperdoc/ This has mostly been developed with the original Axiom project and FriCAS's sister project OpenAxiom but the same methods will (for the most part) work with FriCAS. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: InputForm, was: output
Waldek writes:
Another question is what we should generate for products,
sums and integrals. The current result is _not_ valid as input...
On Tue, Oct 27, 2009 at 7:15 PM, Martin Rubey wrote:
why not similar to
(9) - integrate(f i, i)::INFORM
(9) (integral (fun i) (:: i Symbol))
Type: InputForm
just replacing integral by product or summation?
...
the right thing to do is to set a %specialInput property, as in
fspace.spad.pamphlet:596: setProperty(opdiff,SPECIALINPUT,indiff@(List %
- InputForm) pretend None)
liouv.spad.pamphlet:198: setProperty(opint, SPECIALINPUT, inint@(List F
- INP) pretend None)
liouv.spad.pamphlet:199: setProperty(opdint, SPECIALINPUT, indint@(List
F - INP) pretend None)
Martin,
I have attached a patch 'combfunc.spad.pamphlet' that implements
InputForm as you suggest above.
if F has ConvertibleTo(I) then
setProperty(opdprod, SPECIALINPUT, indprod@(List F - I) pretend None)
setProperty(opdsum, SPECIALINPUT, indsum@(List F - I) pretend None)
...
if F has ConvertibleTo(I) then
indprod l ==
convert([convert(_product)$I, convert(summand l)@I, _
convert([convert(=::Symbol)$I, convert(third l)@I, _
convert([convert('SEGMENT)$I, _
convert(fourth l)@I, convert(fourth rest l)@I]$List(I)) _
]$List(I)) _
]$List(I))
indsum l ==
convert([convert(_summation)$I, convert(summand l)@I, _
convert([convert(=::Symbol)$I, convert(third l)@I, _
convert([convert('SEGMENT)$I, _
convert(fourth l)@I, convert(fourth rest l)@I]$List(I))@I _
]$List(I))@I _
]$List(I))@I
With this patch I get:
(1) - summation(factorial(i+1),i=0..n)::InputForm
(1) (summation (factorial (+ i 1)) (= i (SEGMENT 0 n)))
Type: InputForm
(2) - interpret %
n
--+
(2) (i + 1)!
--+
i = 0
Type: Expression(Integer)
(3) - product(sin x,x=1..n+1)::InputForm
(3) (product (sin x) (= x (SEGMENT 1 (+ n 1
Type: InputForm
(4) - interpret %
n + 1
++-++
(4) | | sin(x)
| |
x = 1
Type: Expression(Integer)
---
However I still have problems with a crash in 'unparse' for example:
(5) - product(sin x,x=1..n+1)::InputForm
(5) (product (sin x) (= x (SEGMENT 1 (+ n 1
Type: InputForm
(6) - unparse %
debugger invoked on a SIMPLE-CONDITION: break
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Return from BREAK.
(BREAK break)
0]
I am up to date with the FriCAS repository:
wsp...@debian:~/fricas-sources/src/algebra$ svn diff
combfunc.spad.pamphlet ~/algebra-combfunc-1.patch
wsp...@debian:~/fricas-sources/src/algebra$
wsp...@debian:~/fricas-sources/src/algebra$ svn update
At revision 711.
which includes Waldek's recent related patch:
Modified: trunk/src/interp/format.boot
===
--- trunk/src/interp/format.boot2009-10-26 22:48:47 UTC (rev 708)
+++ trunk/src/interp/format.boot2009-10-27 02:44:28 UTC (rev 709)
@@ -461,7 +461,6 @@
$curExpr : local := x
x is [=, arg1, arg2] or x is ['=, arg1, arg2] =
concat(sumOrParen(arg1), '=, sumOrParen(arg2))
-sumOrParen(x)
sumOrParen(x)
sumOrParen(x) ==
---
Perhaps there is another bug lurking there?
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: Generic Cached Functions
On Tue, Oct 27, 2009 at 7:22 PM, Ralf Hemmecke r...@hemmecke.de wrote: To cache an arbitrary function one can use the following domain. http://axiom-wiki.newsynthesis.org/SandBoxCachedFunction Ralf, I think that looks great. Because we must explicitly say that domains A and B are in SetCategory it makes sense that all cached functions A-B should be treated as being in SetCategory. This requires a coercion to OutputForm and equality. Here is a suggestion to make CachedFunction satisfy SetCategory by simply interpreting these operations as applying to the cache only: CachedFunction(A: SetCategory, B: SetCategory): Exports == Implementation where ! Exports == SetCategory with function: % - (A - B) cachedFunction: (A - B) - % apply: (%, A) - B recursiveDefine: (%, f: A - B) - % Implementation == add Rep := Record(cache: Table(A, B), fun: A - B) +coerce(x: %): OutputForm == (x.cache)::OutputForm +(x: % = y: %): Boolean == (x.cache) = (y.cache) ... Since a CachedFunction is obviously more than just it's cache perhaps this is debatable but as far as I can see otherwise FriCAS does not define equality for functions at all. I.e. All functions are in the built-in domain 'Mapping' but '=' is not exported by 'Mapping'. Also I wonder if it might not be more useful to define 'function' as follows: function(x: %): A - B == (a:A):B +- apply(x,a) in order to take advantage of the cache but still treat it as a real function to the rest of FriCAS instead of having to depend on 'apply'. I think there are some instances where 'apply' does not apply such as when passing a function to 'map'. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: output, was: the symmetric functions..
Martin,
I am far from an expert but I am beginning to understand this code a
little better.
Please try the attached patch and let me know if it produces the
results you expect.
Note: You really only need chunk @@ -1073,7 +1107,11 @@ in
'i-output.boot' but the rest of the patch which concerns the output
for tensor product should not cause any trouble.
With this patch I get:
(1) - guess([factorial i for i in 0..10])
n - 1
++-++
(1) [ | | (p + 1)]
| |11
p = 0
11
Type: List(Expression(Integer))
I have not tried to look at the TEX output yet.
Regards,
Bill Page.
On Mon, Oct 26, 2009 at 2:35 AM, Martin Rubey wrote:
since you are an expert of i-output now, could you have a look at
http://axiom-wiki.newsynthesis.org/8SavannahBug9297OutputMissesSomeParenthesis
I admit, I do not know the current state of affairs, except that the
output of
(6) - guess([factorial i for i in 0..10])
n - 1
++-++
(6) [ | | p + 1]
| | 11
p = 0
11
is incorrect in both TeX and algebra.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
Index: property.lisp
===
--- property.lisp (revision 704)
+++ property.lisp (working copy)
@@ -51,10 +51,9 @@
(REPEAT (IN X '(
(LET := )
- (= =)
(|/| /)
- (+ +)
(* *)
+ (TENSOR # )
(** **)
(^ ^)
(|:| :)
@@ -78,12 +77,15 @@
(JOIN JOIN )
(EQUATNUM )
(IQUOTIENT //)
- (= = )
+;; (= =)
+;; (= = )
+ (= = )
(|=| = )
(|| )
(|=| = )
(|| )
(\| \| )
+;; (+ +)
(+ + )
(- - )
(WHERE WHERE )
@@ -101,7 +103,6 @@
)) (MAKEPROP (CAR X) 'PREFIXOP (CADR X)))
(REPEAT (IN X '(
- (+ WIDTH |sumWidth|)
(- APP |appneg|)
(- WIDTH |minusWidth|)
(/ APP |appfrac|)
@@ -194,8 +195,11 @@
(REPEAT (IN X '(
(+ APP |plusApp|)
+ (+ WIDTH |sumWidth|)
(* APP |timesApp|)
(* WIDTH |timesWidth|)
+ (TENSOR APP |tensorApp|)
+ (TENSOR WIDTH |tensorWidth|)
(** APP |exptApp|)
(** WIDTH |exptWidth|)
(** SUBSPAN |exptSub|)
@@ -281,7 +285,7 @@
(|NegativeInteger| . (|| * 0))
))
-(FLAG '(* + AND OR PROGN) 'NARY)
+(FLAG '(TENSOR * + AND OR PROGN) 'NARY)
(REPEAT (IN X '(
(|Record| |mkRecordFunList|)
Index: i-output.boot
===
--- i-output.boot (revision 704)
+++ i-output.boot (working copy)
@@ -494,6 +494,40 @@
argl = [superSub,:argl]
superSub
+tensorApp(u,x,y,d) ==
+ rightPrec:= getOpBindingPower(*,Led,right)
+ firstTime:= true
+ for arg in rest u repeat
+op:= keyp arg
+if not firstTime then
+ opString:= GETL('TENSOR,INFIXOP) or '#
+ d:= APP(opString,x,y,d)
+ x:= x + #opString
+[d,x]:= appInfixArg(arg,x,y,d,rightPrec,left,nil) --app in a right arg
+wasSimple:= atom arg and not NUMBERP arg or isRationalNumber arg
+wasQuotient:= isQuotient op
+wasNumber:= NUMBERP arg
+lastOp := op
+firstTime:= nil
+ d
+
+tensorWidth u ==
+ rightPrec:= getOpBindingPower(*,Led,right)
+ firstTime:= true
+ w:= 0
+ for arg in rest u repeat
+op:= keyp arg
+if not firstTime then
+ opString:= GETL('TENSOR,INFIXOP) or '#
+ w:= w + #opString
+if infixArgNeedsParens(arg, rightPrec, left) then w:= w+2
+w:= w+WIDTH arg
+wasSimple:= atom arg and not NUMBERP arg --or isRationalNumber arg
+wasQuotient:= isQuotient op
+wasNumber:= NUMBERP arg
+firstTime:= nil
+ w
+
timesApp(u,x,y,d) ==
rightPrec:= getOpBindingPower(*,Led,right)
firstTime:= true
@@ -1073,7 +1107,11 @@
3
maxWidth := MAX(opWidth,botWidth,topWidth)
xCenter := (maxWidth-1)/ 2 + x
- d:=APP(arg,x+2+maxWidth,y,d)
+
+ --d:=APP(arg,x+2+maxWidth,y,d)
+ prec := 1002 -- binding power of ELT
+ [d,x1]:=appInfixArg(arg,x+maxWidth,y,d, prec,left,nil)
+
d:=
atom bot and SIZE atom2String bot = 1 = APP(bot,xCenter,y-2,d)
APP(bot,x + (maxWidth - botWidth)/2,y-2-superspan bot,d)
[fricas-devel] Re: output, was: the symmetric functions..
Martin,
On Mon, Oct 26, 2009 at 5:32 PM, you wrote:
Bill Page writes:
Please try the attached patch and let me know if it produces the
results you expect.
well, nearly. First of all, please don't change = to = in the
same patch, because it makes comparing the testsuite more difficult.
(I'm not even sure it's desirable...)
As I said, the only part of the patch that is related to this problem
is @@ -1073,7 +1107,11 @@ in 'i-output.boot'. The rest can be ignored.
It is only there because I did not take the time to create a separate
test environment and this is in my current working directory. I do not
know how to use svn to stage patches, i.e. to select only some of
the changes in a working set, except in very limited ways. (cf.
exchange with Ralf re advantages of other source code control
systems).
It seems to me that testsuite should be insensitive to the whitespace
around an equal sign and most other operators. No?
Although I now realize that it is very easy to configure dynamically, e.g.
(1) - PUT('=,'INFIXOP,= )$Lisp
I am interested in the issue of ' = ' versus '= '. What argument do
you see in favor of having whitespace only to the right of '='? To me
this has always just looked odd - another thing that got lost in the
priorities of the original developers.
Second, although maybe only a cosmetic issue, the patch adds
parens slightly too often, I think it should only print the paren when
the output would become ambigous:
(7) - product(factorial i, i=0..n)*product(j+2, j=0..n)
n n
++-++ ++-++
(7) | | (j + 2) | | (i!)
| | | |
j = 0 i = 0
I.e., the parens around j+2 are great, but the parens around i! should
maybe go away? (I'm not entirely sure...)
I guess that is the point: How do you define ambigous in this case?
It seems to me that by default this fairly common mathematical
notation is already quite ambiguous. Is it obvious that ! binds more
tightly that product and sum? If so then we can just change the
precedence to something just less that !. E.g.
...
prec := 1000 -- binding power of ! -1
[d,x1]:=appInfixArg(arg,x+maxWidth,y,d, prec,left,nil)
...
The results I show below are for this case. E.g.
(2) - product(factorial i, i=0..n)*product(j+2, j=0..n)
n n
++-++ ++-++
(2) | | (j + 2) | | i!
| | | |
j = 0 i = 0
Type: Expression(Integer)
Note that in fricas factors always come before a product, so there is no
ambiguity:
(20) - a+z*product(factorial i, i=0..n)
n
++-++
(20) z | | (i!) + a
| |
i = 0
here the parens are also unnecessary, I'd say - product binds stronger
than summation.
I am not sure what you mean by summation in this context. Maybe sum?
If yes, then that is true already. With a precedence of 1002, they
bind as tightly as any other function, at 1000 it is just less than !
but still higher than any other. In this case the parens are there
only because of the factorial. E.g.
(3) - a+z*product(i, i=0..n)
n
++-++
(3) z | | i + a
| |
i = 0
Type: Expression(Integer)
So, a paren should only be printed if the argument of the product is a
sum or a difference, or the product is an argument of power. The
*same* rule holds for a sum...
This patch affects both sum and product equally. So as far as I can
see the result for a sum or difference is as you expect:
(4) - a+z*product(i+j, i=0..n)
n
++-++
(4) z | | (j + i) + a
| |
i = 0
Type: Expression(Integer)
No?
The result for power is:
(5) - a+z*product(i, i=0..n)^2
n 2
++-++
(5) z | | i+ a
| |
i = 0
Type: Expression(Integer)
I do not consider this ambiguous because of the height of the exponent. E.g.
(6) - a+z*product(i^2, i=0..n)
n
++-++ 2
(6) z | | (i ) + a
| |
i = 0
Type: Expression(Integer)
In the case of
(38) - (summation(i^2, i=a..b)^(d-c+1))
b d - c + 1
--+ 2
(38) (i )
--+
i = a
I'd say that the parens should rather be around the sum than the i^2.
I disagree. As above, parens around the sum would be redundant because
of the height of the exponents. I think that changing this behavior
would require rather deep and dangerours changes to the logic of
'i-output.boot'.
I think that Waldek once suggested playing around with leds and nuds,
but I never tried.
From 'newaux.lisp' you can see that the left and right binding powers
of '!' is 1002 and 1001 respectively, thus the choice of 1000
[fricas-devel] Re: output, was: the symmetric functions..
Martin,
Could you please try the attached file containing a patch to
'tex.spad.pamphlet'? I think it solves the problem of missing
parenthesis in the case of ')set output tex on' but the coding here is
very different than in the case of 'i-ouput.boot' so more testing is
important. Again this patch comes from my current working directory
so it also includes the chunks necessary for tensor product. The
chunks that affect the tex output of product and sum are: @@ -37,8
+37,8 @@ and @@ -493,7 +493,7 @@.
With this patch and the previous one (with prec := 1000) I get the
following results:
(1) - )set output tex on
(1) - a+z*product(factorial i + 1, i=0..n)
n
++-++
(1) z | | (i! + 1) + a
| |
i = 0
$$
{z \ {\prod \sb{\displaystyle {i=0}} \sp{\displaystyle n} {\left( {i!}+1
\right)}}}+a
\leqno(1)
$$
Type: Expression(Integer)
(2) - a+z*product(factorial i * 2, i=0..n)
n
++-++
(2) z | | (2i!) + a
| |
i = 0
$$
{z \ {\prod \sb{\displaystyle {i=0}} \sp{\displaystyle n} {\left( 2 \ {i!}
\right)}}}+a
\leqno(2)
$$
Type: Expression(Integer)
(3) - product(summation(i*j, i=a..b),j=c..d)
db
++-++ --+
(3) | | (i j)
| | --+
j = ci = a
$$
\prod \sb{\displaystyle {j=c}} \sp{\displaystyle d} {\sum \sb{\displaystyle
{i=a}} \sp{\displaystyle b} {\left( i \ j
\right)}}
\leqno(3)
$$
Type: Expression(Integer)
Regards,
Bill Page
On Mon, Oct 26, 2009 at 10:28 PM, Bill Page bill.p...@newsynthesis.org wrote:
Martin,
On Mon, Oct 26, 2009 at 5:32 PM, you wrote:
Bill Page writes:
Please try the attached patch and let me know if it produces the
results you expect.
well, nearly. First of all, please don't change = to = in the
same patch, because it makes comparing the testsuite more difficult.
(I'm not even sure it's desirable...)
As I said, the only part of the patch that is related to this problem
is @@ -1073,7 +1107,11 @@ in 'i-output.boot'. The rest can be ignored.
It is only there because I did not take the time to create a separate
test environment and this is in my current working directory. I do not
know how to use svn to stage patches, i.e. to select only some of
the changes in a working set, except in very limited ways. (cf.
exchange with Ralf re advantages of other source code control
systems).
It seems to me that testsuite should be insensitive to the whitespace
around an equal sign and most other operators. No?
Although I now realize that it is very easy to configure dynamically, e.g.
(1) - PUT('=,'INFIXOP,= )$Lisp
I am interested in the issue of ' = ' versus '= '. What argument do
you see in favor of having whitespace only to the right of '='? To me
this has always just looked odd - another thing that got lost in the
priorities of the original developers.
Second, although maybe only a cosmetic issue, the patch adds
parens slightly too often, I think it should only print the paren when
the output would become ambigous:
(7) - product(factorial i, i=0..n)*product(j+2, j=0..n)
n n
++-++ ++-++
(7) | | (j + 2) | | (i!)
| | | |
j = 0 i = 0
I.e., the parens around j+2 are great, but the parens around i! should
maybe go away? (I'm not entirely sure...)
I guess that is the point: How do you define ambigous in this case?
It seems to me that by default this fairly common mathematical
notation is already quite ambiguous. Is it obvious that ! binds more
tightly that product and sum? If so then we can just change the
precedence to something just less that !. E.g.
...
prec := 1000 -- binding power of ! -1
[d,x1]:=appInfixArg(arg,x+maxWidth,y,d, prec,left,nil)
...
The results I show below are for this case. E.g.
(2) - product(factorial i, i=0..n)*product(j+2, j=0..n)
n n
++-++ ++-++
(2) | | (j + 2) | | i!
| | | |
j = 0 i = 0
Type: Expression(Integer)
Note that in fricas factors always come before a product, so there is no
ambiguity:
(20) - a+z*product(factorial i, i=0..n)
n
++-++
(20) z | | (i!) + a
| |
i = 0
here the parens are also unnecessary, I'd say - product binds stronger
than summation.
I am not sure what you mean by summation in this context. Maybe sum?
If yes, then that is true already. With a precedence of 1002, they
bind as tightly as any other function, at 1000 it is just less than !
but still higher than any other. In this case the parens are there
only because of the factorial. E.g.
(3) - a+z*product(i, i=0..n)
n
++-++
(3) z | | i + a
| |
i = 0
[fricas-devel] Re: for loops
Bertfried, I think that in principle there is not restriction on how complicated an expression inside a for loop (or anywhere else in Spad) might be. But there are for example serious limitations in how well the compile can impute any coercions that might be required. Could you please send some actual example code and the specific error message generated? Regards, Bill Page. On Sun, Oct 25, 2009 at 7:44 AM, Bertfried Fauser wrote: Hi, I have a question about the constructon of for loops. I noticed the following (odd?) behaviour in spad code: dumy: Partition := partition [] for par in entries complete partitions(4) repeat dymmy := dymmy + par this code does _not_ compile with some awkward error messages, if I write lipar: List Partiitons := entries complete partitotns(4) for par in lipar repeat dummy := dymmy + par then the code compiles, but possibly at the cost of producing some overhead in defining the variable 'lipar'. However, somtimes the spad compiler does compile more complex conditions inside the for .. reapeat statement. Is there a rule when and why? I guess that the compiler is not able to detect the type correctly if an expression inside the for loop gets too(modestly) complex To handle this border is actually very time consuming and boring. To summarize, I have two questions: a) is there a rule how complicated statements inside of a for ... loop can maximally be? b) is the code slower when I generally define the lists befor I iterate over them in a for .. loop? Thank you for any comment/help BF. -- % PD Dr Bertfried Fauser % Research Fellow, School of Computer Science, Univ. of Birmingham % Honorary Associate, University of Tasmania % Privat Docent: University of Konstanz, Physics Dept http://www.uni-konstanz.de % contact |- URL : http://clifford.physik.uni-konstanz.de/~fauser/ % Phone : +49 1520 9874517 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: for loops
There is a similar problem with permutations that makes it a little awkward to use. E.g. (1) - permutations(3) (1) [[3,2,1],[2,3,1],[2,1,3],[3,1,2],[1,3,2],[1,2,3]] Type: Stream(List(Integer)) (2) - for i in permutations(3) repeat output i FriCAS cannot iterate with i over your form now. Perhaps you should try using a conversion to make sure your form is a list or stream, for example. (2) - permutations(3)::List List Integer Cannot convert from type Stream(List(Integer)) to List(List(Integer) ) for value [[3,2,1],[2,3,1],[2,1,3],[3,1,2],[1,3,2],[1,2,3]] (2) - entries complete permutations(3) (2) [[3,2,1],[2,3,1],[2,1,3],[3,1,2],[1,3,2],[1,2,3]] Type: List(List(Integer)) -- Is there a good reason for a permutation to be returned as a Stream? It would of course be less inconvenient if FriCAS could easily iterate over a Stream. On Sun, Oct 25, 2009 at 8:11 AM, Martin Rubey martin.ru...@math.uni-hannover.de wrote: Bertfried Fauser bertfried.fau...@googlemail.com writes: Hi, I have a question about the constructon of for loops. I noticed the following (odd?) behaviour in spad code: dumy: Partition := partition [] for par in entries complete partitions(4) repeat dymmy := dymmy + par this code does _not_ compile with some awkward error messages, if I write (I assume dumy=dymmy) look at the type of (1) - entries complete partitions(4) (1) [[4],[3,1],[2,2],[2,1,1],[1,1,1,1]] Type: List(List(Integer)) Yes, it should be List Partitions, butit isn't. (2) - )di op partitions There are 3 exposed functions called partitions : [1] (Integer,Integer,Integer) - Stream(List(Integer)) from PartitionsAndPermutations [2] Integer - Stream(List(Integer)) from PartitionsAndPermutations [3] (Integer,Integer) - Stream(List(Integer)) from PartitionsAndPermutations PartitionsAndPermutations need fixing :-) Please go ahead and do so. partitions is not much used, so there is no danger of breakage. I agree that it would be good to re-think these domains. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: for loops
Waldek, Do you agree that it is desirable to extend FriCAS to permit streams in for-loops? Regards, Bill Page. On Sun, Oct 25, 2009 at 5:20 PM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: FriCAS can iterate over streams: (4) - ss0 := [i for i in 0..] (4) [0,1,2,3,4,5,6,7,8,9,...] Type: Stream(NonNegativeInteger) (5) - ss1 := [i + 1 for i in ss0] (5) [1,2,3,4,5,6,7,8,9,10,...] Type: Stream(NonNegativeInteger) (6) - ss2 := [i^2 for i in ss1] (6) [1,4,9,16,25,36,49,64,81,100,...] Type: Stream(NonNegativeInteger) FriCAS can not do 'for' loops over streams. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: the symmetric functions..
Franz,
Thank you for the explanation. After reverting 'poly.spad' the
symmetric functions code compiles as expected.
To correct the problem you noted in your email, I have attached
updated patches for 'src/interp/i-output.boot' and
'src/interp/property.lisp'. This new version treats the tensor product
operator without the special exceptions that apply only to '*'
(times). FriCAS renders '*' as BLANK only when required to avoid
ambiguity, otherwise '*' is simply juxtaposition (such as in the case
where the symbols are subscripted). The tensor product operator on
the other hand should always appear in full.
Also I took this opportunity to make the tensor product symbol
configurable at run time. This can be done by modifying the associated
property, e.g.
PUT('TENSOR, 'INFIXOP, # )$Lisp
Of course this could be made to look prettier with a spad function
call but for now I am satisfied that it works.
BTW, I think the symbol # looks better when separated by spaces. Do you agree?
After reverting the previous patches to 'i-output.boot' and
'property.lisp' and applying the attached patch I get the following
result from your example below:
(1) - M:=FreeModule(Integer,Symbol);ymbol,M)
Type: Domain
(2) - M2 == TensorPower(2,Integer,Symbol,M)
Type: Void
(3) - c1:=subscript(c,[123])::M
(3) c
123
Type: FreeModule(Integer,Symbol)
(4) - d1:=subscript(d,[1])::M
(4) d
1
Type: FreeModule(Integer,Symbol)
(5) - tensor([c1,d1])$M2
(5) c# d
1231
Type: TensorPower(2,Integer,Symbol,FreeModule(Integer,Symbol))
Changing the tensor operator symbol to something I like better :-) gives:
(6) - PUT('TENSOR,'INFIXOP, (*) )$Lisp
(6) (*)
Type: SExpression
(7) - tensor([c1,d1])$M2
(7) c(*) d
123 1
Type: TensorPower(2,Integer,Symbol,FreeModule(Integer,Symbol))
---
Addenda: I noticed a small peculiarity about the INFIXOP values for
'=' and '+' apparently at some time in the past conflicting changes
had been made to these so I explicitly commented out the old values.
Also I finally found why Axiom has the annoying (to me) behavior of
showing equality like this:
a= b
(i.e. with no space preceding the equal sign but one space after) and
changed that to be consistent with the treatment of '+' with spaces on
both sides.
Regards,
Bill Page.
On Sun, Oct 25, 2009 at 6:08 PM, Franz Lehner
leh...@finanz.math.tu-graz.ac.at wrote:
On Sun, 25 Oct 2009, Bill Page wrote:
I tried quickly to compile the code you sent. While running command
')r make1' I received an error message regarding the 'mapLinear'
function. I recall that this is something that Franz may have changed
recently since 'mapLinear' was included in a patch which he sent to me
on Friday.
sorry, I messed up two patches.
We had some discussion on function names and I was outvoted to rename
mapLinear to linearExtend.
I prepared this patch and then applied the new tensor patch.
You need to revert poly.spad to the trunk version currently.
BTW the ASCII tensor output somehow fails with indexed variables, try
M:=FreeModule(Integer,Symbol);
M2 == TensorPower(2,Integer,Symbol,M)
c1:=subscript(c,[123])::M
d1:=subscript(d,[1])::M
tensor([c1,d1])$M2
Franz
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
Index: property.lisp
===
--- property.lisp (revision 704)
+++ property.lisp (working copy)
@@ -51,10 +51,9 @@
(REPEAT (IN X '(
(LET := )
- (= =)
(|/| /)
- (+ +)
(* *)
+ (TENSOR # )
(** **)
(^ ^)
(|:| :)
@@ -78,12 +77,15 @@
(JOIN JOIN )
(EQUATNUM )
(IQUOTIENT //)
- (= = )
+;; (= =)
+;; (= = )
+ (= = )
(|=| = )
(|| )
(|=| = )
(|| )
(\| \| )
+;; (+ +)
(+ + )
(- - )
(WHERE WHERE )
@@ -101,7 +103,6 @@
)) (MAKEPROP (CAR X) 'PREFIXOP (CADR X)))
(REPEAT (IN X '(
- (+ WIDTH |sumWidth|)
(- APP |appneg|)
(- WIDTH |minusWidth|)
(/ APP |appfrac|)
@@ -194,8 +195,11 @@
(REPEAT (IN X '(
(+ APP |plusApp|)
+ (+ WIDTH |sumWidth|)
(* APP |timesApp|)
(* WIDTH |timesWidth|)
+ (TENSOR APP |tensorApp|)
+ (TENSOR WIDTH |tensorWidth|)
(** APP |exptApp|)
(** WIDTH |exptWidth|)
(** SUBSPAN
[fricas-devel] Re: CYGWIN binary -- deliberately off list!
Martin, Seems to work for me on Windows 7 with new Cygwin install. I've uploaded it here: http://axiom-wiki.newsynthesis.org/FriCASonCygwin I think more people should try it. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: und danke....
Franz,
On Fri, Oct 23, 2009 at 12:10:51AM -0400, Bill Page wrote:
I am sorry that this took me a little longer than I had hoped. As
usual some other activities interfered with my time available for
FriCAS programming... :-(
On Fri, Oct 23, 2009 at 5:28 AM, you wrote:
thank you very much, this would have taken me a lot of time to
figure out.
No problem. I don't know who's bright idea it was to try and collect
all properties into a single file and not leave any hints behind in
the original source code but I think it was a mistake. It makes it
especially hard to understand the code in 'i-output.boot' at first
glance.
It did not work rightaway due to a few typos (?)
Yes, sorry. You can tell I was in a hurry and a little too tired.
@@ -53,8 +53,9 @@
- (+ + )
+ (+ ++ )
this one is a typo I guess?
Yes, it was a left-over from an earlier test that I forgot to cleanup.
+ opString:= GETL(TENSOR,INFIXOP) or '(*)
I don't understand this one.
The point was to allow a choice of symbol by a simple change to the
'property.lisp'. This is used elsewhere in 'i-output.boot' but not
consistently.
Using this, I get output like
a2(*) + a2(*) + a1(*) + a1(*)b1
instead of
a2(*)b2 + a2(*)b1 + a1(*)b2 + a1(*)b1
Sorry. As you can tell I really didn't have enough time to do more
than a simple test.
However changing this and the following line to
opString:= '#
d:= APP(opString,x,y,d)
x:= x+1
and also
(TENSOR #)
in the other file instead of (TENSOR (*))
it works as expected.
Great.
I could not get (*) to work along these lines.
Another thing I forgot I think. If the symbol is more than a single
character a few more changes are required. E.g.
(TENSOR WIDTH |tensorWidth|)
(TENSOR SUBSPAN |tensorSub|)
(TENSOR SUPERSPAN |tensorSuper|)
Anyways it takes too much space and sage people also decided
to use #.
I really dislike the use of the symbol '#' for this purpose. For one
thing, # is a very common prefix operator that usually denotes the
size or length of something in FriCAS/Axiom. Second # just doesn't
seem to me tensor to me. Third, I do not think that what the Sage
people are doing constitutes a particularly good model for FriCAS
(except perhaps in terms of the functionality). I think FriCAS should
focus on greater rigor and consistency.
In ASCII output I would much rather live with a symbol that takes more
space but sort of looks like \otimes
(i-output.boot can be read in live without compilation,
this saves a lot of time).
What command do you use to compile live boot code? I use something
like this on the axiom-wiki but I do not believe that it is optimal.
Did you also try
)lisp (compile-file property.lisp)
to make live changes to the properties? It seems to me that that did
not work for me and I was not sure why.
I have attached a complete patch file that adds the tensor package to
the FriCAS build system. One needs to apply this patch plus add the
file 'tensor.spad.pamhlet' to the 'algebra' subdirectory. (Renamed
from 'tensor.spad.nw'. Note: I also would prefer to use the '.nw'
extension instead of '.pamphlet' - maybe we can petition Waldek and
other FriCAS developers to adopt this change?)
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
Index: src/algebra/boo-cat.input
===
--- src/algebra/boo-cat.input (revision 704)
+++ src/algebra/boo-cat.input (working copy)
@@ -207,6 +207,9 @@
)compile SPACEC.spad
)compile SRAGG.spad
)compile STRICAT.spad
+)compile TENSCAT.spad
+)compile TENSPC.spad
+)compile TENSPRP.spad
)compile UPSCAT.spad
)compile ULSCAT.spad
)compile ULSCCAT.spad
Index: src/algebra/boo-pack2.input
===
--- src/algebra/boo-pack2.input (revision 704)
+++ src/algebra/boo-pack2.input (working copy)
@@ -207,6 +207,7 @@
)compile TANEXP.spad
)compile TBCMPPK.spad
)compile TEMUTL.spad
+)compile TENSPO2.spad
)compile TEX1.spad
)compile TOOLSIGN.spad
)compile TOPSP.spad
Index: src/algebra/outform.spad.pamphlet
===
--- src/algebra/outform.spad.pamphlet (revision 704)
+++ src/algebra/outform.spad.pamphlet (working copy)
@@ -325,6 +325,8 @@
++ f super \spad{iv}.
binomial: (%, %) - %
++ binomial(n,m) creates a form for the binomial coefficient of n and m.
+tensor: (%, %) - %
+ ++ tensor(a,b) creates a form for a tensor b
--% Scripts
[fricas-devel] Re: cygwin
Ralf, On Fri, Oct 23, 2009 at 7:29 AM, Ralf Hemmecke wrote: What about fricas in a virtual box for Windows? Doesn't someone here know how to do this? Doing that is very easy but I do not think it would be very satisfying to Windows users. Running VirtualBox in seamless mode is about as close as you can get to the look-and-feel of a real native Windows application but as far as I know making the installation and startup of FriCAS in this environment transparent to Windows users is not easily possible. Perhaps it might be possible using Python scripting to initiate the virtual machine plus some careful linux startup code. But this is certainly beyond my current skill set. If not then it is even more important that fricas works fine as an optional package for sage. Since the sage community seems produce easily installable virtual machines. Creating virtual machine images is easy (though a bit time consuming). Making them easy to use for users with no linux experience is much harder. The Sage notebook makes this much easier. In fact, now that the Sage developers have separated the notebook component from the main body of the Sage code I think there is a good chance that it could be fairly easily adapted as a stand alone front-end to FriCAS. I think doing this would be worthwhile but I am not certain if it would appeal to other FriCAS users and I have doubts that there are other developers out there waiting to do this for us - and I just don't have enough time. I just hope that there is enough space to add fricas to this VM. If the Sage people don't do this then we certainly could distribute a version of it that does include FriCAS. If you would like to work on this Ralf, I would be glad to help. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: und danke....
Martin, Perhaps you misunderstood my comment. I did not intend to claim that FriCAS was any more rigorous than Sage. I said: I think FriCAS should focus on greater rigor and consistency.. The point is that these two projects have quite different goals. Or rather at least I think they should have - this is obviously my personal rather subjective view. Sage claims that it's goal is to become an open source alternative to Magma, Maple, Mathematica and Matlab. As you know I strongly support this goal. However, with the possible partial exception of Magma, I would not like to choose any of these or in combination as models for FriCAS/Axiom. It seems to me that at the outset Axiom started with very different goals. Axiom specifically included the development of a programming language (Spad, then later Aldor) that was intended to capture the essence of doing mathematics with a computer. At least 3 of the 4 M's had the seemingly less ambitious goal of simply using a computer to do mathematics. It seems to me that Sage is (for the most part) focused on this latter point of view. That is, in spite of (or perhaps because of?) the fact that it is for the most part being developed by mathematicians, I think Sage development takes a very pragmatic/engineering view of the problem - one that mostly focuses on programming. So when I say FriCAS should focus on greater rigor and consistency. what I intend is that the development of FriCAS should continue to focus on the subject for which it was originally developed. To me this is the more idealist view of the problem that emphasizes mathematics as the foundation and at least in principle focuses on mathematical rigor and consistency. I guess that is why whenever I think about library design in Axiom my first thought is about category theory since it seems clear to me that category theory has become exactly that sort of foundation for most of mathematics over the last 50 years. Admittedly, again a personal opinion. That said, I am willing to spend some time comparing FriCAS and Sage on a number of points but I am not so sure how much you know about Sage and I don't think our time would be well spent unless we could agree first on those areas where we both feel qualified to comment. Regards, Bill Page. On Fri, Oct 23, 2009 at 1:31 PM, Martin Rubey martin.ru...@math.uni-hannover.de wrote: Bill Page bill.p...@newsynthesis.org writes: Anyways it takes too much space and sage people also decided to use #. I really dislike the use of the symbol '#' for this purpose. For one thing, # is a very common prefix operator that usually denotes the size or length of something in FriCAS/Axiom. Second # just doesn't seem to me tensor to me. Third, I do not think that what the Sage people are doing constitutes a particularly good model for FriCAS (except perhaps in terms of the functionality). I think FriCAS should focus on greater rigor and consistency. I would not dare say that FriCAS is any more rigorous than sage. However, since this comes up again and again, it might serve both sage and FriCAS to give examples where you think sage is not rigorous or inconsistent. BEst, Martin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Symmetric Functions
Franz, On Wed, Oct 21, 2009 at 9:59 AM, you wrote: On Sat, Oct 17, 2009 at 09:57:43AM +0100, Bertfried Fauser wrote: Bases of symmetric function Hopf algebras: At the moment we concentrate on PowerSum, Elementary, Complete, Schur symmetric functions. This is always the same algebra with different basis. All these bases are indexed by Partition, therefore I suggest the following model (of course more general bases will need other implementations). For SymmetricFunctions We need products inner, outer ...: (%,%)-% and coproducts: coinner, coouter ...: % - TensorPower(2,...,%) I worry about the situation in which we must write something like: outerProduct: (%:TensorPower(n,...),%:TensorPower(m,...)) - TensorPower(n+m, ... ) I think this will cause some difficulty. If this can be solved by a recursive definition something like below, I think that would be quite beautiful. All these products are defined on the basis and then linearly extended, the latter code is always the same. Therefore I propose SymmetricFunction(R:CommutativeRing,B:SymmetricFunctionBasisCategory) with inner, outer:(%,%)-% coinner,couter:%-TensorPower(2,...,%) add inner(x,y) = bilinearExtend(inner$B,x,y) SymmetricFunctionBasisCategory == with inner:(%,%) - SymmetricFunction(Integer,%) ... then all there is to do is to implement the different bases, the linear extensions are always the same. The above code however is recursive: SymmetricFunction uses SymmetricFunctionBasisCategory and SymmstricFunctionBasisCategory uses SymmetricFunction. Apparently the spad compiler accepts this. ... Yes, this is a very important feature of spad! However I suspect problems when the file is split. How can this be solved? Compiling together is preferred. Then the compiler can automatically solve the recursion. If you must split the code, the usual approach is to use a kind of iterative bootstrap: Define one of the categories twice, first a dummy one without the recursion, then the one that depends on it, finally re-define the first one. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: und danke....
Franz, Thank you for sending the code. Yes, I would be glad to help with generating nicer output. I will try to get back to you some time in the next 24 hours. On Wed, Oct 21, 2009 at 9:30 AM, you wrote: ... The major missing feature is ASCII output, something like x # y or x (*) y instead of TENSOR(x,y). (tex was easy, and output in Martin's emacs interface is working nicely). Waldek pointed me to i-output.boot but I am clueless what to do there. In OutputForm I put tensor(l) == convert [eform TENSOR,a,b] but how to treat that in i-output.spad? At the moment I decided to make Hopf algebra based on TensorPower(n:Integer,R:CommutativeRing,B:OrderedSet,M:FreeModuleCategory(R,B)) It would be nice too have TensorPowerCategory(n:NonNegativeInteger, R:CommutativeRing, M :Module(R)):Category == Module(R) with ... if n is 2 then TensorProductCategory(R,B,B,M,M) but apparently the compiler does not swallow this at the moment. Sorry, I don't quite understand. Your definition 'TensorProductCategory' is: TensorProductCategory(R:CommutativeRing, M : Module(R), N : Module(R)):Category == Module(R) with tensor: (M, N) - % What is: TensorProductCategory(R,B,B,M,M) ? Do you expect to overload the definition of 'TensorProductCategory'? (Using the same type name in different ways is not possible in spad.). Did you write literally 'n is 2' as opposed to 'n=2' ? 'is' is a pattern operator. It is quite low level and I think now treated differently between FriCAS and OpenAxiom. Could you explain a little more your intention here? Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: und danke....
Ralf, It's an old subject, but yes I would be in favor of a change to git. And as you say: we could do it without moving away from SourceForge. BTW, as far as I know darcs was the first distributed source code contol system to offer this kind of cherry picking. It is something that I really miss with svn. The darcs project is still alive and evolving a little but it only seems to favored by people with a natural interest in exotic languages like Haskell and Lisp ... ;-) Regards, Bill Page. On Wed, Oct 21, 2009 at 11:41 AM, Ralf Hemmecke r...@hemmecke.de wrote: On 10/21/2009 05:23 PM, Bill Page wrote: I agree that this might be a good idea - if we really do start working seriously on this. Sometimes the extra work overhead and the self-discipline seem to get in the way. What? Version control is overhead? I don't ever start editing any file without previously putting it under version control. cd somedir git init git add . git commit -m 'initial data' Finished. You have your working repository. What could be easier than that? ;-) Maybe this opens another discussion but even though I am now used to svn I also wish we were using a more distributed source code control model. Once you get more used to git, you will believe that SVN is from the last century. Using git help is so easy. It's just a bit difficult to understand how git works. But it's so nice that it allows staging your code. So you can easily commit only some of the modified files. Git even allows you to only commit parts of the changes to a file. In this way you can just work and sort out the patches that belong to just one idea later, ie, to clear the mess that coding usually brings. I agree that it changes the way you work - for the better. I always preferred darcs - git still seems kind of quirky to me but I suppose I could get used to it too. :-) Do you know that sourceforge offers Git? http://sourceforge.net/apps/trac/sourceforge/wiki/Git Ralf Regards, Bill Page. On Wed, Oct 21, 2009 at 10:25 AM, Ralf Hemmecke r...@hemmecke.de wrote: Hey guys, what about opening up a public repository for your work? I'm sure you find some place where you can do that. If Waldek agrees, the most natural way would be to work at a branch on sourceforge. Nowadays, however, I would prefer to see a git repository, though. ;-) It really changes the way you work. Ralf --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Something missing in new Aldor interface?
Ralf,
It looks very likely to me that this is all related to
AXL_EDIT_1_1_13_18 in 'aldor/src/gf_add.c' but I have to admit that
this twist in the hash algorithm still seems rather opaque to me.
Regards,
Bill Page.
On Tue, Oct 20, 2009 at 2:00 AM, Ralf Hemmecke r...@hemmecke.de wrote:
What I am interested in is a hint of _where_ the hashes for the various
domains are actually coded.
Is it in the following file?
https://aquarium.aldor.csd.uwo.ca/svn/trunk/aldor/aldor/src/syme.c
But the only connection to strHash there is:
Hash
symeNameCode(Syme syme)
{
return strHash(symeString(syme));
}
It would be really helpful to find out about the hash algorithm for both
FriCAS and Aldor in order to keep them in sync.
...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: infinite loop during trace
Waldek, On Mon, Oct 19, 2009 at 6:51 AM, you wrote: Bill Page wrote: wsp...@debian:~$ echo ')lisp (setf *print-circle* t) atan(tan(3)) )tr EF_;iatan atan(tan(3)) )quit' | fricas -nosman | tail #822#))) (|%eval| #829# . #(#1856# #822#)) (|rtrig|) (|trig|) (|elem|) (|odd| (((1 #820# (1 . #831#)) . #831#)) 2 5120) (1 . #831#)) . #831#) (2) atan(tan(3)) Type: Expression(Integer) wsp...@debian:~$ echo ')lisp (setf *print-circle* t) atan(tan(3)) )tr EF_;iatan atan(tan(3)) )quit' | fricas -nosman | wc 117389 201051 12509518 --- However I seriously doubt that a trace that is over 100,000 lines in length is likely to be of much use to anyone... but perhaps I just don't understand how this )trace command is intended to be used. Setting *print-circle* to t is easy. ?But somebody using debugging commands still may be overwhelmed by the size of output. ?I am not sure if we should set *print-array* to nil -- this make output much smaller, but also means that most interesting parts of some structures are no longer shown... It seems to me that the shortest output is desirable by default since it simply confirms that the trace itself worked. If a user really does want to see the whole 100,000 lines of output I think it makes sense that they should have to ask for it by setting *print-array* to true. I expect that as a minimum they would want to spool this to a file. I don't understand why the output produced by FriCAS compiled with SBCL differs so much from that produced by FriCAS compiled by GCL. Using GCL I do not get an trace over 100,000 lines long. It seems to me that I am not able to reproduce that same output under under SBCL no matter which default settings I change. I am afraid I was not clear: easy way is to set global default. However, when you set *print-array* to nil this affects not only trace, but also several other print commands. Also, IHMO main use of ')trace' without ')math' is tracing non-Spad functions, where the problematic part (that is type argument) is not present. If )math was the default behavior of )trace I would be much happier. Then only if the user entered an additional option, say )lisp, would it produce the current huge output. This seems acceptable since the user explicitly choose a low-level lisp debugging option. So, *print-circle* set to t has clear advantages -- only drawback is longer execution time and higher memory usage. OTOH *print-array* set to nil has some disadvantages. But probably for Spad developer it is better choice. I looked for how this flag is set in FriCAS right now. In 'setq.lisp' I see (setq *print-array* nil) So I don't see why it isn't already being set by default. Is this code not used in the interpreter? Regards, Bill Page --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: See *print-level* and *print-length*
Thanks, Tim. That seems to work very well. It completely prevents the infinite loop and allows some measure of control over the detail. Does anyone see any disadvantage to making (setq *print-level* 1) the default? Regards, Bill Page. On Mon, Oct 19, 2009 at 9:51 AM, Tim Daly d...@axiom-developer.org wrote: http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/var_stprint-l_int-lengthst.html For example: wsp...@debian:~$ fricas -nox Checking for foreign routines AXIOM=/usr/local/lib/fricas/target/i686-pc-linux spad-lib=/usr/local/lib/fricas/target/i686-pc-linux/lib/libspad.so foreign routines found openServer result 0 FriCAS (AXIOM fork) Computer Algebra System Version: FriCAS 2009-10-10 Timestamp: Saturday October 10, 2009 at 01:32:44 - Issue )copyright to view copyright notices. Issue )summary for a summary of useful system commands. Issue )quit to leave FriCAS and return to shell. - (1) - (1) - atan(tan(3)) (1) atan(tan(3)) Type: Expression(Integer) (2) - )lisp (setq *print-level* 1) Value = 1 (2) - )tr EF_;iatan Function traced: EF;iatan (2) - atan(tan(3)) 1enter EF;iatan : (# 0 . 1)\#(# # NIL 0 # NIL # # |elem| # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) 1exit EF;iatan : (# 0 . 1) (2) atan(tan(3)) Type: Expression(Integer) (3) - )lisp (setq *print-level* 2) Value = 2 (3) - atan(tan(3)) 1enter EF;iatan : ((1 # #) 0 . 1)\#((|ElementaryFunction| # #) (#FUNCTION |lookupComplete| # #) NIL 0 (# # . #) NIL #(# # NIL 0 # NIL # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) #(# # NIL 135291459439 # NIL # |%symbol| |%alg| # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) |elem| (|BasicOperator|) (|Symbol|) #(# # NIL 0 # NIL # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #) (#FUNCTION |COMMONOP;operator;SBo;1| . #) #(|pi| 0 #) #(|log| 1 #) #(|exp| 1 #) #(|sin| 1 #) #(|cos| 1 #) #(|tan| 1 #) #(|cot| 1 #) #(|sec| 1 #) #(|csc| 1 #) #(|asin| 1 #) #(|acos| 1 #) #(|atan| 1 #) #(|acot| 1 #) #(|asec| 1 #) #(|acsc| 1 #) #(|sinh| 1 #) #(|cosh| 1 #) #(|tanh| 1 #) #(|coth| 1 #) #(|sech| 1 #) #(|csch| 1 #) #(|asinh| 1 #) #(|acosh| 1 #) #(|atanh| 1 #) #(|acoth| 1 #) #(|asech| 1 #) #(|acsch| 1 #) (#FUNCTION
[fricas-devel] aldor interface and lisp trace
Ralf, Apparently the Aldor interface build uses lisp trace and the changes discussed here on another thread about preventing infinite loops and limiting the output of the )trace command break this process. Have I understood correctly that the output of trace might differ significantly between versions of Lisp? Is using trace a good idea? Is there a more robust way to do the same thing? I'll try this again setting *print-level* as Tim Daly suggests. Perhaps that will work better. Do you think (setf *print-level* 1) will be sufficient? I am using the newest FriCAS sources plus one small patch: wsp...@debian:~/fricas-build$ svn info ~/fricas-sources Path: /home/wspage/fricas-sources URL: https://fricas.svn.sourceforge.net/svnroot/fricas/trunk Repository Root: https://fricas.svn.sourceforge.net/svnroot/fricas Repository UUID: b0c55286-4f34-0410-a049-a1e7e93b0762 Revision: 686 Node Kind: directory Schedule: normal Last Changed Author: whebisch Last Changed Rev: 686 Last Changed Date: 2009-10-18 16:09:56 -0400 (Sun, 18 Oct 2009) wsp...@debian:~/fricas-build$ svn status ~/fricas-sources M /home/wspage/fricas-sources/src/lisp/fricas-lisp.lisp wsp...@debian:~/fricas-build$ svn diff ~/fricas-sources Index: /home/wspage/fricas-sources/src/lisp/fricas-lisp.lisp === --- /home/wspage/fricas-sources/src/lisp/fricas-lisp.lisp (revision 686) +++ /home/wspage/fricas-sources/src/lisp/fricas-lisp.lisp (working copy) @@ -19,6 +19,8 @@ #-:cmu (defun set-initial-parameters() +(setf *print-circle* t) +(setq *print-array* nil) (setf *read-default-float-format* 'double-float)) #+:cmu wsp...@debian:~/fricas-build$ ../fricas-sources/configure -with-lisp=sbcl --enable-aldor ... wsp...@debian:~/fricas-build$ nohup make ... wsp...@debian:~/fricas-build$ tail -25 nohup.out echo ')lisp (generate-ax-file BASTYPE (quote (BASTYPE)) (quote ()))' ap/BASTYPE.lsp DAASE=/home/wspage/fricas-build/target/i686-pc-linux /home/wspage/fricas-build/target/i686-pc-linux/bin/AXIOMsys ap/BASTYPE.lsp tmp/BASTYPE.log test -f ap/BASTYPE.ap ar r al/libaxiom_BASTYPE.al ao/lang.ao ao/boolean0.ao ao/minimach.ao ao/subsetc.ao ar: creating al/libaxiom_BASTYPE.al aldor -Wname=axiom -Mno-abbrev -Mpreview -Y al -L AxiomLib=axiom_BASTYPE -fao=ao/BASTYPE.ao ap/BASTYPE.ap echo ')lisp (load ../../../fricas-sources/src/aldor/gendepap.lsp)' ap/KOERCE.lsp echo ')lisp (trace |makeAxExportForm|)' ap/KOERCE.lsp echo ')lisp (trace |modemapToAx|)' ap/KOERCE.lsp echo ')lisp (trace getdatabase)' ap/KOERCE.lsp echo ')lisp (generate-ax-file KOERCE (quote (KOERCE)) (quote ()))' ap/KOERCE.lsp DAASE=/home/wspage/fricas-build/target/i686-pc-linux /home/wspage/fricas-build/target/i686-pc-linux/bin/AXIOMsys ap/KOERCE.lsp tmp/KOERCE.log test -f ap/KOERCE.ap ar r al/libaxiom_KOERCE.al ao/lang.ao ao/boolean0.ao ao/minimach.ao ao/subsetc.ao ar: creating al/libaxiom_KOERCE.al aldor -Wname=axiom -Mno-abbrev -Mpreview -Y al -L AxiomLib=axiom_KOERCE -fao=ao/KOERCE.ao ap/KOERCE.ap Compiler bug...Bug: Inappropriate shared structure for reposition make[3]: *** [ao/KOERCE.ao] Error 1 rm ao/.dir make[3]: Leaving directory `/home/wspage/fricas-build/src/aldor' make[2]: *** [al/libaxiom.al] Error 2 make[2]: Leaving directory `/home/wspage/fricas-build/src/aldor' make[1]: *** [all-aldor] Error 2 make[1]: Leaving directory `/home/wspage/fricas-build/src' make: *** [all-src] Error 2 wsp...@debian:~/fricas-build$ gcc --version gcc (Debian 4.3.2-1.1) 4.3.2 ... wsp...@debian:~/fricas-build$ sbcl -version This is SBCL 1.0.30, an implementation of ANSI Common Lisp. ... This was run under 32 bit Debian 5.0. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Something missing in new Aldor interface?
Ralf, Peter Broadberry never explained this patch way back when he first provided the initial code for the interface. (I think it's mentioned only in one place back in the axiom-devel archives.) This is why I find it surprising but maybe my understanding is not sufficiently deep. Consider the following code in 'src/interp/hashcode.boot': Note: 1073741789 is the largest prime that can be represented in 30 bits. Assuming Lisp integers are not less than 30 bits (maybe not a good assumption?) one might expect this code to behave the same way in FriCAS whether it compiled for a 32 bit or 64 bit machine. ... $hashModulus := 1073741789 -- largest 30-bit prime -- Produce a 30-bit hash code. This function must produce the same codes -- as the asharp string hasher in src/strops.c hashString str == h := 0 for i in 0..#str-1 repeat j := CHAR_-CODE char str.i h := LOGXOR(h, ASH(h, 8)) h := h + j + 200041 h := LOGAND(h, 1073741823) -- 0x3FFF REM(h, $hashModulus) -- Combine two hash codes to make a new one. Must be the same as in -- the hashCombine function in aslib/runtime.as in asharp. hashCombine(hash1, hash2) == MOD(ASH(LOGAND(hash2, 16777215), 6) + hash1, $hashModulus) ... This does not appear to confirm what you say: hashCombine(32236,hash) just cuts it down to 16 bit or so'. Off hand I do not see anything remarkable about the value 32236. This patch has something to do with changing the hash produced for the Mapping type - apparently adding an additional offset. But I still don't see why this only affects the interface on a 64 bit machine unless there is something special built-in to the Aldor source code for Mapping types in this architecture. If this was not due to Aldor one would expect the patch to cause the interface to fail when used on a 32 bit machine. No? Can you see anything else happening here? Regards, Bill Page. On Mon, Oct 19, 2009 at 4:28 PM, Ralf Hemmecke r...@hemmecke.de wrote: Waldek, can you explain, why you find it surprising? Aldor is the same on 32 and 64 bit machines. The only differences I could imagine are that the wordsize is different and therefore aldor uses more bits on 64 bit machines. Or is it rather that fricas and the underlying lisp uses more bits and this hashCombine(32236,hash) just cuts it down to 16 bit or so? Maybe I should really also try at least with ecl to see whether it's indeed independent of the underlying lisp. What makes you so certain about that patch being independent from the Lisp flavour? Ralf PS: Adam, if you have a 64 bit machine, then you should probably patch your fricas-sources. Otherwise you might hit an error reported by Bill. http://groups.google.com/group/fricas-devel/browse_thread/thread/c1d1ccc263415ba5 On 10/19/2009 09:59 PM, Waldek Hebisch wrote: Ralf Hemmecke wrote: I Just want to report successful compilation with revision 686 + the patch git diff src/interp/hashcode.boot diff --git a/src/interp/hashcode.boot b/src/interp/hashcode.boot index 745a88c..49713a4 100644 --- a/src/interp/hashcode.boot +++ b/src/interp/hashcode.boot @@ -55,7 +55,7 @@ hashType(type, percentHash) == hash := hashCombine(hashType(arg, percentHash), hash) retCode := hashType(retType, percentHash) EQL(retCode, $VoidHash) = hash - hashCombine(retCode, hash) + hashCombine(retCode, hashCombine(32236,hash)) op = 'Enumeration = for arg in args repeat hash := hashCombine(hashString(STRING arg), hash) on a 32 bit Ubuntu 9.04 machine. As you see below, I also can compile and execute the program Bill mentioned at the beginning of this thread. Since without that patch the Aldor interface does not work on a 64 bit machine, I'd rather prefer to have this patch added before 1.0.8 comes out. Is the patch in any way related to what the underlying lisp is? I am using SBCL 1.0.18.debian here. The code above should work the same in all Lisps. AFAIUI what matters is that we compute the same values as Aldor. I am surprised that 32-bit version works both with and without the patch. However, given your result the patch is OK. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Fwd: Building the Aldor interface on FriCAS or OpenAxiom
For some reason this historically important email does not appear in
the fricas-devel archives (nor open-axiom-devel or anywhere else on
the Web, I think). Perhaps Peter was not subscribed to either group at
the time he sent the message so only Martin and I received it -
although it was clearly intended to appear here. Below is a copy for
our reference from my own email archive.
See also the thread which followed this email:
http://groups.google.com/group/fricas-devel/browse_thread/thread/e618d8d7274282ae/bea8a95ec3cb73be#bea8a95ec3cb73be
As you can see Peter says very little about the patch, only: Against
aldor-1.1 you'll need a small patch to the way axiom computes hash
codes.
-- Forwarded message --
From: Peter Broadbery p_broadb...@hotmail.com
Date: Fri, Nov 9, 2007 at 4:45 PM
Subject: RE: Building the Aldor interface on FriCAS or OpenAxiom
To: Bill Page bill.p...@newsynthesis.org, Martin Rubey
martin.ru...@univie.ac.at
Cc: fricas-devel@googlegroups.com, open-axiom-de...@lists.sourceforge.net
On 08 Nov 2007 14:48:12 +0100, Martin Rubey wrote:
Bill Page writes:
Have you been able to compile the Axiom/Aldor interface for a recent
version of FriCAS or OpenAxiom? As you know the instructions here:
No, so far I have only a build with the very last wh-sandbox. I will try it as
soon as I can. But really, it's Peter who is the boss of the axiom-aldor
interaction.
Indeed! :-)
Um, I'll not be the boss of anything. I just hack stuff sometimes...
From the output
`/home/page/fricas-test/src/aldor/as//home/page/fricas-test/src/aldor/aldor/ap/axlit.as',
looks like you've got a full path where a relative one was expected.
Difficult to say what exactly, as I don't have that code to hand any
more (I decided that the way it was put together was a bit too mad, so
moved the logic away from the makefiles into the java sorting code).
Will release soon.. Against aldor-1.1 you'll need a small patch to
the way axiom computes hash codes (I couldn't have got this without
the source code, by the ways..):
Peter
hashType(type, percentHash) ==
SYMBOLP type =
type = '$ = percentHash
type = % = percentHash
hashString SYMBOL_-NAME type
STRINGP type = hashCombine(hashString type,
hashString('Enumeration))
type is ['QUOTE, val] = hashType(val, percentHash)
type is [dom] = hashString SYMBOL_-NAME dom
type is ['_:, ., type2] = hashType(type2, percentHash)
isDomain type = getDomainHash type
[op, :args] := type
hash := hashString SYMBOL_-NAME op
op = 'Mapping =
hash := hashString '-
[retType, :mapArgs] := args
for arg in mapArgs repeat
hash := hashCombine(hashType(arg, percentHash), hash)
retCode := hashType(retType, percentHash)
EQL(retCode, $VoidHash) = hash
hashCombine(retCode, hashCombine(32236, hash))
op = 'Enumeration =
for arg in args repeat
hash := hashCombine(hashString(STRING arg), hash)
hash
op in $DomainsWithoutLisplibs =
for arg in args repeat
hash := hashCombine(hashType(arg, percentHash), hash)
hash
cmm := CDDAR getConstructorModemap(op)
cosig := CDR GETDATABASE(op, 'COSIG)
for arg in args for c in cosig for ct in cmm repeat
if c then
hash := hashCombine(hashType(arg, percentHash), hash)
else
hash := hashCombine(7, hash)
-- !!! If/when asharp hashes values using their type, use instead
-- ctt := EQSUBSTLIST(args, $FormalMapVariableList, ct)
-- hash := hashCombine(hashType(ctt, percentHash), hash)
hash
_
The next generation of MSN Hotmail has arrived - Windows Live Hotmail
http://www.newhotmail.co.uk
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: infinite loop during trace
On Sun, Oct 18, 2009 at 9:04 PM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: Bill Page wrote: I think think it is bad to have a default that can cause an infinite loop in an FriCAS command even if it is a system level command like ')trace'. So if setting this flag prevents such loops, I think it would be a good idea. However when I tried this I *still* get an infinite loop with the example above (although the output is changed subtly).. Worse, it seems to be an infinite loop that does not respect control-C. I had to kill the process in order to proceed. From your comments I can understand that you expected this should work. If you try this on your system does the trace terminate normally? Yes. Are you sure it was infinite loop? On my machine it took some time, I did not measure it but please allow few minutes. You are right I did not wait long enough! Here is a test: wsp...@debian:~$ echo ')lisp (setf *print-circle* t) atan(tan(3)) )tr EF_;iatan atan(tan(3)) )quit' | fricas -nosman | tail #822#))) (|%eval| #829# . #(#1856# #822#)) (|rtrig|) (|trig|) (|elem|) (|odd| (((1 #820# (1 . #831#)) . #831#)) 2 5120) (1 . #831#)) . #831#) (2) atan(tan(3)) Type: Expression(Integer) wsp...@debian:~$ echo ')lisp (setf *print-circle* t) atan(tan(3)) )tr EF_;iatan atan(tan(3)) )quit' | fricas -nosman | wc 117389 201051 12509518 --- However I seriously doubt that a trace that is over 100,000 lines in length is likely to be of much use to anyone... but perhaps I just don't understand how this )trace command is intended to be used. Setting *print-circle* to t is easy. But somebody using debugging commands still may be overwhelmed by the size of output. I am not sure if we should set *print-array* to nil -- this make output much smaller, but also means that most interesting parts of some structures are no longer shown... It seems to me that the shortest output is desirable by default since it simply confirms that the trace itself worked. If a user really does want to see the whole 100,000 lines of output I think it makes sense that they should have to ask for it by setting *print-array* to true. I expect that as a minimum they would want to spool this to a file. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: und danke....
a better language than SPAD in several ways. It remains a tragedy that those people responsible for it's licensing seem to be devoted mostly to destroying any future this language might have. :-( Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Something missing in new Aldor interface?
Waldek, I am sorry I was a little confused, mixing two different problems. The problem I have with Aldor and FriCAS is not on my Debian machine but rather on the Sage virtual machine that I use to run the Axiom wiki. That machine is running Ubuntu p...@billpage:~$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=9.04 DISTRIB_CODENAME=jaunty DISTRIB_DESCRIPTION=Ubuntu 9.04 and the FriCAS is from p...@billpage:~$ svn info ~/fricas-src Path: /home/page/fricas-src URL: https://fricas.svn.sourceforge.net/svnroot/fricas/trunk Repository Root: https://fricas.svn.sourceforge.net/svnroot/fricas Repository UUID: b0c55286-4f34-0410-a049-a1e7e93b0762 Revision: 684 Node Kind: directory Schedule: normal Last Changed Author: whebisch Last Changed Rev: 684 Last Changed Date: 2009-10-14 17:47:54 -0700 (Wed, 14 Oct 2009) -- Other than this one example (so far) Aldor and the Aldor interface in FriCAS seem to be working fine. But thank you for reminding me about the hashcode.spad patch. That may very well be the problem. I think we should commit this patch to FriCAS and just make the new version of Aldor a requirement. Regards, Bill Page. On Thu, Oct 15, 2009 at 3:36 AM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: Bill Page wrote: Ralf, I just built FriCAS and the Aldor interface from the most recent source: ... This is _not_ the most recent source. New makefiles for Aldor interface are revision 677 and current revision is 684. I can not say if that matters, but: - this is likely old problem - given changes to makefiles it would be good to check if the new version works better And of course to old question about hashing types: IIRC come Aldor versions need a patch to 'src/interp/hashcode.boot'. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: Something missing in new Aldor interface?
Thanks, :-) I guess I have forgotten about almost as many problems as I have ever solved ! My example in this old thread mentioned by Waldek is exactly the case I mentioned above. Getting old, working to many late nights... As I said, I think we should commit this patch or else I will probably forget it again. ;-) Regards, Bill Page. On Thu, Oct 15, 2009 at 4:25 AM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: Ralf Hemmecke wrote: This is _not_ the most recent source. New makefiles for Aldor interface are revision 677 and current revision is 684. For just compiling fricas+aldorinterface that should not matter. The aldor interface has worked before. That must be another issue. I can not say if that matters, but: - this is likely old problem - given changes to makefiles it would be good to check if the new version works better And of course to old question about hashing types: IIRC come Aldor versions need a patch to 'src/interp/hashcode.boot'. Oh I certainly don't have that patch, but I'll check a fresh build tonight. Do you quickly have a pointer to that patch or must I search the mailing list? For example see thread: http://groups.google.com/group/fricas-devel/browse_thread/thread/727f3b35da110e6d?hl=en# In the fourth e-mail the same erorr message is reported by Bill. In the e-mail 7 there is the patch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: FriCAS status
Waldek, I have a few more patches that I would like to get into FriCAS before the next release but really none of them are critical. Here's one for XPOLY. It adds a couple of missing functions. I first mentioned this patch here: http://lists.gnu.org/archive/html/axiom-math/2006-03/msg3.html Index: src/algebra/xpoly.spad.pamphlet === --- src/algebra/xpoly.spad.pamphlet (revision 684) +++ src/algebra/xpoly.spad.pamphlet (working copy) @@ -116,6 +116,27 @@ (r := lquo (u,l)) case failed = failed reverse_! (r::%) +-- Inserted by Bill Page, based on 'divide' from 'FreeMonoid' +(lar:% div a:%) == +(a = 1) = [lar, 1] +Na : Integer := #(la := listOfMonoms(a)$Rep) +Nlar : Integer := #(llar := listOfMonoms(lar)$Rep) +l:List(REC) := empty() +while Na = Nlar repeat + if llar.first.gen = la.first.gen and + llar.first.exp = la.first.exp then +-- Can match a portion of this lar factor. +-- Now match tail. +(q:=lquo(makeMulti rest llar,makeMulti rest la))case $ = + if llar.first.exp la.first.exp then + l := concat_!(l, [la.first.gen, + (llar.first.exp - la.first.exp)::NNI]) + return [makeMulti l, q::%] + l:= concat_!(l, first llar) + llar := rest llar + Nlar := Nlar - 1 +failed + length x == reduce(+ ,[f.exp for f in listOfMonoms x], 0) varList x == @@ -517,6 +538,8 @@ -- definitions + monom(w, r) == [[w,r]] + coerce(x:WORD):% == monom(x,1$R) mindegTerm p == last(p)$Rep if R has CommutativeRing then --- I will try to send a few more like this ASAP. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~--- Index: src/algebra/xpoly.spad.pamphlet === --- src/algebra/xpoly.spad.pamphlet (revision 684) +++ src/algebra/xpoly.spad.pamphlet (working copy) @@ -116,6 +116,27 @@ (r := lquo (u,l)) case failed = failed reverse_! (r::%) +-- Inserted by Bill Page, based on 'divide' from 'FreeMonoid' +(lar:% div a:%) == +(a = 1) = [lar, 1] +Na : Integer := #(la := listOfMonoms(a)$Rep) +Nlar : Integer := #(llar := listOfMonoms(lar)$Rep) +l:List(REC) := empty() +while Na = Nlar repeat + if llar.first.gen = la.first.gen and + llar.first.exp = la.first.exp then +-- Can match a portion of this lar factor. +-- Now match tail. +(q:=lquo(makeMulti rest llar,makeMulti rest la))case $ = + if llar.first.exp la.first.exp then + l := concat_!(l, [la.first.gen, + (llar.first.exp - la.first.exp)::NNI]) + return [makeMulti l, q::%] + l:= concat_!(l, first llar) + llar := rest llar + Nlar := Nlar - 1 +failed + length x == reduce(+ ,[f.exp for f in listOfMonoms x], 0) varList x == @@ -517,6 +538,8 @@ -- definitions + monom(w, r) == [[w,r]] + coerce(x:WORD):% == monom(x,1$R) mindegTerm p == last(p)$Rep if R has CommutativeRing then
[fricas-devel] Re: Something missing in new Aldor interface?
Yes I believe that is correct: This problem apparently only manifests on 64 bit systems. Perhaps it would also be a problem to build the FriCAS Aldor interface with a 64 bit FriCAS system and an older version of Aldor but I do not have much experience with running the older version in 64 bits. The only old version I know for 64 bits systems is the one here: http://axiom-wiki.newsynthesis.org/Aldor that I built and distributed in binary before Aldor was officially available as open source. But I have never tried it with the Aldor interface. Regards, Bill Page. On Thu, Oct 15, 2009 at 5:58 PM, Waldek Hebisch hebi...@math.uni.wroc.pl wrote: My impression was that your anwers were yes, unpatched, yes. IIRC there was difference between 64-bit and 32-bit Aldor. So, we need to check first if both 64-bit and 32-bit Aldor 1.1.0 work with the patch. If yes, then I leave it to you to go on with the patch. If no, then switching at runtime looks like best way. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Guessing formulas for sequences - new Fricas Version
Martin, Waldek, I have installed Revision: 680 of FriCAS on axiom-wiki and I notice that there are a few index out of range errors on this summary page for the GUESS package: http://axiom-wiki.newsynthesis.org/GuessingFormulasForSequences Are these known problems or is there something wrong with the examples? Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Something missing in new Aldor interface?
Ralf,
I just built FriCAS and the Aldor interface from the most recent source:
wsp...@debian:~$ svn info ~/fricas-src
Path: /home/wspage/fricas-src
URL: https://fricas.svn.sourceforge.net/svnroot/fricas/trunk
Repository Root: https://fricas.svn.sourceforge.net/svnroot/fricas
Repository UUID: b0c55286-4f34-0410-a049-a1e7e93b0762
Revision: 675
Node Kind: directory
Schedule: normal
Last Changed Author: whebisch
Last Changed Rev: 675
Last Changed Date: 2009-10-02 12:41:58 -0400 (Fri, 02 Oct 2009)
on my Debian 5.0 system using sbcl:
wsp...@debian:~$ sbcl --version
SBCL 1.0.30
and
wsp...@debian:~$ aldor -version
Aldor version 1.1.0 for LINUX(glibc-unknown)
The build completed without errors and I can run other simple test
programs but the following common test fails:
p...@billpage:~$ fricas -nox
Checking for foreign routines
AXIOM=/usr/local/lib/fricas/target/x86_64-unknown-linux
spad-lib=/usr/local/lib/fricas/target/x86_64-unknown-linux/lib/libspad.so
foreign routines found
openServer result 0
FriCAS (AXIOM fork) Computer Algebra System
Version: FriCAS 2009-10-10
Timestamp: Wednesday October 14, 2009 at 18:57:56
-
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-
(1) -
(1) - )sys cat sieve.as
# include axiom.as
import from Boolean, Integer, NonNegativeInteger;
sieve(n: Integer): Integer == {
isprime: OneDimensionalArray Boolean :=
new(n::NonNegativeInteger, true);
np:Integer := 0;
for p in 2..n | isprime p repeat {
np := np + 1;
for i in (p+p)..n by p repeat isprime i := false;
}
np
}
(1) - )co sieve.as
Compiling FriCAS source code from file /home/page/sieve.as using
AXIOM-XL compiler and options
-O -Fasy -Fao -Flsp -laxiom -Mno-ALDOR_W_WillObsolete -DAxiom -Y
$AXIOM/algebra -I $AXIOM/algebra
Use the system command )set compiler args to change these
options.
Compiling Lisp source code from file ./sieve.lsp
Issuing )library command for sieve
Reading /home/page/sieve.asy
(1) - sieve(10)
Looking in OneDimensionalArray(Boolean()) for new with code 1050701442
System error:
The function FOAM-USER::|fiRaiseException| is undefined.
(1) -
Any ideas what might be wrong? Are you able to reproduce this problem?
Regards,
Bill Page.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: nasty little bug in pattern matching
On Fri, Oct 9, 2009 at 8:55 PM, Waldek Hebisch wrote:
Bill, I am not sure if I was clear enough. I think that we should
commit your patch from Septeber 12 with extra applyQuote chunk.
The OrderedSet to Comparable change in op.spad.pamphlet should go
in a separate patch together with patch to FreeModuleCategory.
Can you do this?
Ok, done. It took me two commits to get it right. The 2nd commit
reverted some changes I did not intend to make (yet). Below is the end
result.
Regards,
Bill Page.
wsp...@debian:~/fricas-sources$ svn diff -r 677:head
Index: src/algebra/op.spad.pamphlet
===
--- src/algebra/op.spad.pamphlet(revision 677)
+++ src/algebra/op.spad.pamphlet(revision 679)
@@ -380,7 +380,7 @@
opacsch := operator('acsch, 1)
opbox := operator('%box)$OP
oppren := operator('%paren)$OP
-opquote := operator('applyQuote)$OP
+opquote := operator('%quote)$OP
opdiff := operator('%diff, 3)
opsi:= operator('Si, 1)
opci:= operator('Ci, 1)
Index: src/algebra/fspace.spad.pamphlet
===
--- src/algebra/fspace.spad.pamphlet(revision 677)
+++ src/algebra/fspace.spad.pamphlet(revision 679)
@@ -220,7 +220,7 @@
operator op ==
is?(op, PAREN) = oppren
is?(op, BOX) = opbox
- error Unknown operator
+ error concat(Unknown operator 1: ,string(name(op)))$String
mainKernel x ==
empty?(l := kernels x) = failed
@@ -250,14 +250,14 @@
s
kernel(op:OP, args:List %) ==
- not belong? op = error Unknown operator
+ not belong? op = error concat(Unknown operator 2:
,string(name(op)))$String
okkernel(op, args)
okkernel(op, l) ==
kernel(op, l, 1 + reduce(max, [height f for f in l], 0))$K :: %
elt(op:OP, args:List %) ==
- not belong? op = error Unknown operator
+ not belong? op = error concat(Unknown operator 3:
,string(name(op)))$String
((u := arity op) case N) and (#args ~= u::N)
= error Wrong number of arguments
(v := evaluate(op,args)$BasicOperatorFunctions1(%)) case % = v::%
@@ -556,7 +556,7 @@
equaldiff : (K,K)-Boolean
debugA: (List % ,List %,Boolean) - Boolean
opdiff := operator('%diff)$CommonOperators()
-opquote := operator('applyQuote)$CommonOperators
+opquote := operator('%quote)$CommonOperators
ground? x== retractIfCan(x)@Union(R,failed) case R
ground x== retract x
@@ -573,7 +573,7 @@
operator op ==
is?(op, '%diff) = opdiff
is?(op, '%quote) = opquote
- error Unknown operator
+ error concat(Unknown operator 4: ,string(name(op)))$String
if R has ConvertibleTo InputForm then
INP==InputForm
Index: ChangeLog
===
--- ChangeLog (revision 677)
+++ ChangeLog (revision 679)
@@ -1,3 +1,8 @@
+2009-10-10 Bill Page bill.p...@newsynthesis.org
+
+* Fix bug: Error detected within library code: Unknown operator
+* change 'applyQuote to '%quote
+
2009-10-10 Ralf Hemmecke r...@hemmecke.de
* configure.ac src/aldor/Makefile.in src/aldor/Makefile3.in
wsp...@debian:~/fricas-sources$
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
FriCAS - computer algebra system group.
To post to this group, send email to fricas-devel@googlegroups.com
To unsubscribe from this group, send email to
fricas-devel+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en
-~--~~~~--~~--~--~---
[fricas-devel] Re: nasty little bug in pattern matching
Waldek,
On Fri, Oct 9, 2009 at 8:55 PM, you wrote:
Bill Page wrote:
... so I modified 'FreeModuleCategory' as follows:
snip
to provide a default 'smaller?' operation inherited by the XPOLY domains.
That looks like good change.
Testing revealed the 'constandOperator' problem. Then by changing:
--- op.spad.pamphlet (revision 666)
+++ op.spad.pamphlet (working copy)
@@ -271,7 +271,7 @@
derivative(op, [(l1: List(A)): A +- f first l1]$List(List A - A))
error Operator is not unary
- if A has OrderedSet then
+ if A has Comparable then
I found the problem went away. We need at least Comparable in order to
define 'ltconst?', 'opconst' and 'constOp'.
Yes, at least without deeper changes we need Comparable to define
constOp, and constOp is needed in some versions of Expression.
So I think we should do the change you propose.
Bill, I am not sure if I was clear enough. I think that we should
commit your patch from Septeber 12 with extra applyQuote chunk.
The OrderedSet to Comparable change in op.spad.pamphlet should go
in a separate patch together with patch to FreeModuleCategory.
Can you do this?
Yes, I can do this. The applyQuote chunk is part the patch below. I
can separate it out and commit it.
Please also take a look at this patch. It removes the need for
Comparable when defining constOp.
wsp...@debian:~/my-fricas/src/algebra$ svn diff op.spad.pamphlet
Index: op.spad.pamphlet
===
--- op.spad.pamphlet(revision 675)
+++ op.spad.pamphlet(working copy)
@@ -234,11 +234,11 @@
++ derivative(op) returns the value of the %diff property of
++ op if it has one, and failed otherwise.
constantOperator: A - OP
-++ constantOperator(a) returns a nullary operator op
-++ such that \spad{op()} always evaluate to \spad{a}.
+ ++ constantOperator(a) returns a nullary operator op
+ ++ such that \spad{op()} always evaluate to \spad{a}.
constantOpIfCan : OP - Union(A, failed)
-++ constantOpIfCan(op) returns \spad{a} if op is the constant
-++ nullary operator always returning \spad{a}, failed otherwise.
+ ++ constantOpIfCan(op) returns \spad{a} if op is the constant
+ ++ nullary operator always returning \spad{a}, failed otherwise.
Implementation == add
@@ -271,43 +271,46 @@
derivative(op, [(l1: List(A)): A +- f first l1]$List(List A - A))
error Operator is not unary
-if A has OrderedSet then
- cdisp : (OutputForm, List OutputForm) - OutputForm
- csex: (InputForm, List InputForm) - InputForm
- eqconst?: (OP, OP) - Boolean
- ltconst?: (OP, OP) - Boolean
- constOp : A - OP
+cdisp : (OutputForm, List OutputForm) - OutputForm
+csex: (InputForm, List InputForm) - InputForm
+eqconst?: (OP, OP) - Boolean
+constOp : A - OP
- opconst:OP :=
-comparison(equality(operator('constant, 0), eqconst?),
- ltconst?)
+cdisp(a, l) == a
+csex(a, l) == a
- cdisp(a, l) == a
- csex(a, l) == a
-
- eqconst?(a, b) ==
-(va := property(a, CONST)) case failed = not has?(b, CONST)
-((vb := property(b, CONST)) case None) and
- ((va::None) pretend A) = ((vb::None) pretend A)
-
+eqconst?(a, b) ==
+ (va := property(a, CONST)) case failed = not has?(b, CONST)
+ ((vb := property(b, CONST)) case None) and
+ ((va::None) pretend A) = ((vb::None) pretend A)
+if A has Comparable then
+ ltconst?: (OP, OP) - Boolean
ltconst?(a, b) ==
(va := property(a, CONST)) case failed = has?(b, CONST)
((vb := property(b, CONST)) case None) and
- ((va::None) pretend A) ((vb::None) pretend A)
-
+ smaller?((va::None) pretend A,(vb::None) pretend A)
+ opconst:OP :=
+comparison(equality(operator('constant, 0), eqconst?), ltconst?)
constOp a ==
-setProperty(display(copy opconst, (l1: List(OutputForm)):
OutputForm +- cdisp(a::OutputForm, l1)),
- CONST, a pretend None)
+setProperty(display(copy opconst,
+ (l1: List(OutputForm)): OutputForm +- cdisp(a::OutputForm, l1)),
+CONST, a pretend None)
+else
+ opconst:OP := equality(operator('constant, 0), eqconst?)
+ constOp a ==
+setProperty(display(copy opconst,
+ (l1: List(OutputForm)): OutputForm +- cdisp(a::OutputForm, l1)),
+CONST, a pretend None)
- constantOpIfCan op ==
-is?(op, 'constant) and
- ((u := property(op, CONST)) case None) = (u::None) pretend A
-failed
+constantOpIfCan op ==
+ is?(op, 'constant) and
+((u := property(op, CONST)) case None) = (u::None) pretend
[fricas-devel] Re: VOID and NONE
On Mon, Oct 5, 2009 at 2:03 PM, Waldek Hebisch wrote:
Bill Page wrote:
...
Although it is currently a stand alone domain, 'Void' could be easily
made to satisfy 'SetCategory' by providing a simple '=' operation.
Since by definition 'Void' has only a single canonical value we can
simply write:
(x:% = y:%):Boolean == true
I think this is misguided: fundamental property of Void is that
its values are _not used_ in normal computation. The coercion
to OutputForm exists only because our printing and tracing routines
use it. So from fundamental point of view Void should have no
operations. Once you have no operations there is no need
for representation.
I hope you do not mind continuation of this discussion. Perhaps I am
wrong but for me it seems important to agree on basic concepts such as
these. To often in the past I think the Axiom developers have started
to deal with these sort of issues but then stopped short of a good
general solution because other issues were seen as having higher
priority.
I do not agree that a value of type Void is not used in computation,
the requirement is only that we do not care what it's value is for a
particular computation. This does not preclude the definition of
certain useful formal operations on such a value. Equality is an
example. As far as I can see every domain in Axiom must have a
representation - even if it is just implicit.
Unfortunately the following simple patch causes the unexpected
regression that I mentioned in a previous thread (see bad code or
side-effects?).
snip
I do not yet know why this causes a regression and because 'Void' is
used so extensively it might be hard to track down on a case-by-case
basis.
While I can not see any specific reason for failure, let me say
that what you are trying to do is asking for trouble. Namely,
since everything can be coerced to Void you risk that instead
of operation you want you will use operation from Void. Typically
coercions are homomorhisms, so spurious coercion may be
performance loss but should preserve correctness. But coercion
to Void almost surely will break things.
Axiom already has coercion to Void from every domain. This is not
something that is changed by my patch. What is a little different is
that equality is defined.
Do you mean that because we can do
x::Void = y::Void
for any domains x:X, and y:Y? This does not happen in the interpreter
and coercions must be explicit in the compiler so I am not convinced.
(1) - test(1::Void = 2::Void)
(1) true
Type: Boolean
(2) - test(1=2)
(2) false
Type: Boolean
On the other hand I agree that it does not really make sense that the
map from some domain to Void is called a coercion. I would prefer
that every domain X in BasicType (including those in SetCategory)
export a special operation called:
terminal: X - Void
The idea that Void should be automatically involved in the resolution
of types in expressions like
if n=0 then x::Integer else y::Float
does not make sense to me. See 'void.spad.pamphlet'
)abbrev package RESLATC ResolveLatticeCompletion
++ Author: Stephen M. Watt
++ Date Created: 1986
++ Date Last Updated: May 30, 1991
++ Related Domains: ErrorFunctions, Exit, Void
++ Keywords: mode, resolve, type lattice
++ Description:
++ This package provides coercions for the special types \spadtype{Exit}
++ and \spadtype{Void}.
ResolveLatticeCompletion(S: Type): with
coerce: S - Void
++ coerce(s) throws all information about s away.
++ This coercion allows values of any type to appear
++ in contexts where they will not be used.
--
It seems to me that there are better ways to do this and it is not
even really clear to me that Axiom currently does use this straegy.
In principle I do not see any reason why 'Void' needs to be canonical
so long as equality is defined as above.
I think you are confused about names. 'None' would be a reasonable
alternative name, except that the name 'Void' is used also in other
languages (and 'None' is taken for different use).
No I am not concerned about names. I am worried about logical
consistency. 'None' is something different, in fact quite opposite
from 'Void'. 'Void' is the empty or initial domain. It is (should
be) the result of an empty 'Union()'. 'Void' on the other hand is the
empty product or terminal domain. It should be the result of an
empty 'Record()' (or similar fundamental cross-product type).
Some folks tried to have multiple 'Void' type (lazy and eager ones
IIRC), but still 'Void' is special because it represents very special
concept. You are trying to turn 'Void' into ordinary type,
which would make is useless from compiler point of view.
Could you explain again why you thing this change makes 'Void' useless?
'None' on the other hand is called a domain
[fricas-devel] Re: bad code or side-effects?
On Sun, Oct 4, 2009 at 10:42 PM, Waldek Hebisch wrote: ... Bill Page wrote: (4) 1 Type: BadCode(Integer) -- Notice the result in (4) above. I expected to see the output more. snip Can you reproduce this? Can anyone see why this happens? What am I missing? Which version of FriCAS are you using? Current version (revision 675) build on top of sbcl-1.0.16 running on 64-bit Fedora 9 for (4) above gives me more. The same using ecl-9.8.4 and gcl. Thanks for checking. What I am running is based on wsp...@debian:~/fricas-src$ svn info Path: . URL: https://fricas.svn.sourceforge.net/svnroot/fricas/trunk Repository Root: https://fricas.svn.sourceforge.net/svnroot/fricas Repository UUID: b0c55286-4f34-0410-a049-a1e7e93b0762 Revision: 672 Node Kind: directory Schedule: normal Last Changed Author: mantepse Last Changed Rev: 672 Last Changed Date: 2009-09-27 12:48:37 -0400 (Sun, 27 Sep 2009) Compiled with sbcl 1.0.30 on 32-bit Debian 5.0. But I do have some significant local changes. However I did not expect it to cause this sort of behavior (famous last words ... :-) BTW: I get (1) - solve([tan(b) = a],[b]) (1) [] Interesting. I guess I may have done more damage than I thought! I'll revert changes and take another more careful look. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: bad code or side-effects?
On Sun, Oct 4, 2009 at 10:53 PM, Bill Page wrote: ... I guess I may have done more damage than I thought! I'll revert changes and take another more careful look. Sorry. I confirm that it's my fault. (Don't know exactly what yet.) Both problems disappear when I revert and rebuild. Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: build problem
Ralf, It looks like maybe you were doing a parallel build because of the order of the output near the end of the log. I have sometimes had problems. Maybe you could try it without this option? Regards, Bill Page. On Tue, Sep 29, 2009 at 4:47 PM, Ralf Hemmecke r...@hemmecke.de wrote: Hello, I am trying to compile a r672 of fricas. Unfortunately, I am unable to compile on the sage.math server. Setup is ECL (Embeddable Common-Lisp) 9.4.1 as comes with the Sage that is installed on that machine. Could someone have a look at the log make | tee make.log which can be found at http://sage.math.washington.edu/home/hemmecke/pub I have no idea why that would fail. Ralf --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: build problem
Ralf, Do you recall the following email concerning the ecl upgrage? sage -i -s http://sage.math.washington.edu/home/ghitza/ecl-9.8.4.spkg Regards, Bill Page. -- Forwarded message -- From: Bill Page bill.p...@newsynthesis.org Date: Thu, Sep 3, 2009 at 6:01 PM Subject: Re: [sage-devel] Re: [fricas-devel] Re: Aldor interface To: sage-de...@googlegroups.com Cc: fricas-devel@googlegroups.com Ralf, On Thu, Sep 3, 2009 at 5:32 PM, Ralf Hemmecke wrote: On 09/03/2009 02:48 PM, Bill Page wrote: I am sorry, I don't the logs to send but if you have any problems with the instructions below, then I can reproduce and send them later. Assuming that you already have Aldor and Sage installed, the commends: $ cd ~/sage-4.1.1 $ wget http://www.mediafire.com/file/im5zd201mh0/fricas-1.0.7.p0.spkg $ ./sage -f fricas-1.0.7.spkg Produces the error: undefined reference to `log' . (about 15 minutes) Your wget does not quite work that way, but I got the file anyway from there to my ~/scratch directory. Ok, sorry. I guess it is on some kind of sharing site that forces you to read annoying advertisements or something. I don't know why the developer did not put it directly on the sage site. Then I issued sage -f fricas-1.0.7.spkg inside ~/scratch. sage is in my PATH. That seems to extract and then starts doing something, but without success. I have sage 4.1. Do I really need 4.1.1? I don't think so. I think 4.1 should be ok. But for sure you do need a version of Sage where ECL is the default lisp. Is it relevant whether or not I run on a 32bit system? No, I don't think so. I don't have ecl on my system. Shouldn't the fricas spkg just use the lisp provided by sage? Yes. Your log shows that it found ECL (Embeddable Common-Lisp) 9.4.1. Or do I have to install ECL? No, it is not necessary to install ECL separately to install FriCAS in Sage. But as Nils pointed out, ECL 9.4.1 is now also a little old. I think Waldek mentioned earlier that he had a problem building FriCAS with 9.4.1 or similar version. I had forgotten that for other reasons I had already upgraded the ECL version in version 4.1.1 of Sage that I have installed on my system. You should definitely ECL also upgrade via sage -i -s http://sage.math.washington.edu/home/ghitza/ecl-9.8.4.spkg ... Regards, Bill Page. On Tue, Sep 29, 2009 at 5:50 PM, Ralf Hemmecke r...@hemmecke.de wrote: It looks like maybe you were doing a parallel build because of the order of the output near the end of the log. I have sometimes had problems. Maybe you could try it without this option? Well, I started with 'make -j9' and then (after it failed) wanted to check without the -j option. So I really typed make | tee make.log. And now checkt again with 'make -j1'. == Failed in exactly the same way. But anyway, 'make -j9' should also work. Hasn't Waldek enabled a parallel build? I really don't understand that. Maybe I should try with sbcl. By the way, compiling the same code with ECL (Embeddable Common-Lisp) 9.8.4 on my laptop works fine (linear build on a 32bit machine). Ralf --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: build error of fricas-1.0.7
On Fri, Sep 25, 2009 at 5:49 AM, Ralf Hemmecke wrote: ... Waldek, if you think it's wiser to ask the user to explicitly give the --enable-aldor switch at configure time, I don't oppose too much. I think the situation is different now. I also think that it's wiser. Furthermore, William Stein allowed me to distribute a fricasaldor.spkg (which would basically just contain libaxiom.al). So when we generate a new fricas release, we could upload an appropriate .spkg and also ask users (or have a script) to fetch that spkg from http://sagemath.org/packages/optional/. They would thus get libaxiom.al from there and can (without much build time) complete the necessary compilation of just the runtime files locally. Excellent. Ralf PS: Just give me a few more days to finish the infrastructure stuff. +1 :-) Thanks Ralf! Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] lexical or machine order and smaller? versus before?
I've been bugged a little lately by a minor issue of nomenclature. Both FriCAS and OpenAxiom have implemented a distinction between some mathematical or natural ordering and equality of the members of a domain - which might not always be defined or may be defined in different ways, versus the machine ordering of the elements which is always defined (perhaps even between members of different domains) and is constant at least within a given a given session. The machine order is not natural in the sense that it does not depend on any consistent mathematical semantics, but rather could be implemented for example by the ordering of the machine memory address of objects. Such an ordering might change each time you restart the interpreter or if you run the program on different machines. (Does this strategy work if memory garbage collection is allowed to move objects in memory?) Or with a little more work the machine ordering might be defined in a lexical or syntactic manner in which case the ordering will not depend on the details of the representation. In any case the machine ordering is important for the efficiency and effectiveness of some algorithms. The problem is that FriCAS and OpenAxiom have choosen different names for the machine ordering. In FriCAS it is called smaller?. smaller?(alpha,beta) evaluates to true if the value of alpha comes before the value of beta in the machine ordering. OpenAxiom calls the same thing before?. The problem is that the English root word smaller has the connotation of size rather than order. But even the OpenAxiom name seems vague and a little awkward to read. I would like to propose that both FriCAS and OpenAxiom change and adopt a common standard name that makes better sense (at least in English :-) How about sorted? For example if sorted?(alpha,beta) then ... This seems easy to read for me. Or if you want a more specific name maybe if machineSorted?(alpha,beta) then ... Ideas? Opinions? Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: lexical or machine order and smaller? versus before?
On Wed, Sep 16, 2009 at 2:41 PM, Gabriel Dos Reis wrote: Bill Page writes: [...] | The problem is that FriCAS and OpenAxiom have choosen different | names for the machine ordering. In FriCAS it is called smaller?. | smaller?(alpha,beta) evaluates to true if the value of alpha comes | before the value of beta in the machine ordering. OpenAxiom calls the | same thing before?. The problem is that the English root word | smaller has the connotation of size rather than order. But even the | OpenAxiom name seems vague and a little awkward to read. The OpenAxiom choice was based on long experience with that sort problem for a difference language but in a much wider context and audience: The C++ programming, as you know, has a limited support for reflection called Run Time Type Identification (RTTI) that is used for various things, including dynamic dispatch and exception handling. I think it is good to cite an existing standard but I am not so sure how relevant it is in this context. Perhaps C++ is a little obscure for the average mathematically-oriented developer ... but no matter. In various situations, it is necessary to order types in a some way. Yes. The C++ standard uses the name 'before' (member function for the class std::type_info) that tells whether a given type object comes before another in the implementation-defined ordering. That solution has been implemented and in use for nearly two decades; I have not had heard of any complaints. Perhaps there are better things to complain about? ;-) Granted: 'before?' is definitely better than 'smaller?' ! I do not want to include any 'machine' in the name; Why? How about if implementationOrder?(alpha,beta) then ... and I'm reluctant to let people believe that I'm sorting stuff. This is just binary relation. Fair enough. Sorting is just one application of a defined order. We could say that alpha,beta is sorted if 'implementationOrder?(alpha,beta)' is true. It is an obscure binary relation, much of which not related to the actual mathematics that OpenAxiom wants to deal with. That is part of the reasons why it is not glorified into a category of its own. In OpenAxiom 'before?' is exported by SetCategory (1) - )di op before? There is one exposed function called before? : [1] (D,D) - Boolean from D if D has SETCAT In FriCAS it is exported by the category 'Comparable' (1) - )di op smaller? There is one unexposed function called smaller? : [1] (D,D) - Boolean from D if D has COMPAR and it is inherit by OrderedSet it from Comparable. Note: In FriCAS not all domains in OrderedSet are Comparable. It is an obscure relation that is best ignored by most users (including library writers.) Only OpenAxiom *runtime system* developers (not the library developers) have to care about it. Could you explain why you say only run-time system developers have to care about it? Are you claiming that this order relation it is not important for mathematical algorithms? Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: lexical or machine order and smaller? versus before?
Gaby, On Wed, Sep 16, 2009 at 2:41 PM, you wrote: ... This is just binary relation. It is an obscure binary relation, much of which not related to the actual mathematics that OpenAxiom wants to deal with. That is part of the reasons why it is not glorified into a category of its own. ... Instead of being exported by a category perhaps 'before?' (or equivalent) should be part of a machine-oriented or reflection-oriented package? So then it is not part of the normal namespace of any domain and the programmer would have to specifically import the domain reflection package in order to use it. Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: lexical or machine order and smaller? versus before?
On Wed, Sep 16, 2009 at 4:21 PM, Gabriel Dos Reis wrote: Bill Page writes: | I think it is good to cite an existing standard but I am not so sure | how relevant it is in this context. Perhaps C++ is a little obscure | for the average mathematically-oriented developer ... but no matter. Obscure enough for many prominent scientific and mathematical software are written in that language; but as you say but no matter. You are right. Perhaps I have been hanging around the Sage people too long ... ;-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
[fricas-devel] Re: lexical or machine order and smaller? versus before?
On Wed, Sep 16, 2009 at 6:20 PM, Waldek Hebisch wrote: Concerning having the same name as OpenAxiom: AFAICS 'smaller?' and 'before?' are different and have different names. I doubt we gain much by making name the same. Although the implementation is different as far as I can see the purpose in the existing code base is the same: to provide a standard (not necessarily mathematical ordering for all values in all (almost all?) domains. Is that not correct? Do you propose then, that we should not try to make it easy to write code that can be easily transported between FriCAS and OpenAxiom (and original Axiom)? Do we need to implement some kind of compatibility layer such as a 'Comparable' category for OpenAxiom and a 'before?' operator in FriCAS? Regards, Bill Page. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups FriCAS - computer algebra system group. To post to this group, send email to fricas-devel@googlegroups.com To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en -~--~~~~--~~--~--~---
