[fricas-devel] Re: [Axiom-mail] Programming with BTREEs.

2009-04-07 Thread Ralf Hemmecke

 but 
 
 [e,[5,1],[[a,[1,1],b],[1,1],[c,[1,2],d...@bt
 
 cannot work, I think, because the argument types don't match.  You
 will need to allow also binary trees.

Ooops. You are completely right.

The last part in the input file can be replaced by


S==Symbol
L==List Integer
U==Union(BT,S)

construct(x: U, l: L, y: U): U ==
   u: BT := if x case S then binaryTree(x::N) else x::BT
   v: BT := if y case S then binaryTree(y::N) else y::BT
   binaryTree(u, l, v)::U

l: List U := [a,b,c,d,e]
(a,b,c,d,e):=(l 1, l 2, l 3, l 4, l 5)
u: U := [e,[5,1],[[a,[1,1],b...@u,[1,1],[c,[1,2],d...@u]@U]
bt2: BT := u :: BT


where the @U part is necessary (though ugly) since otherwise Axiom (oh, 
FriCAS in my case) falsely creates

(25) - [a,[1,2],b]

(25)  [a,[1,2],b]
 Type: List(Any)

which is a very unspecific (and bad) choice in the pressence of my new 
function from above and a and b being both variables of type U.

Yet another instance of why I hate Any.

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] input bug?

2009-04-07 Thread Martin Rubey

What's going on here?

(1) - 2r

   (1)  2R0
  Type: Variable(2R0)
(2) - 3r

   (2)  3R0
  Type: Variable(3R0)
(3) - 3s
 
   Cannot find a definition or applicable library operation named 3 
  with argument type(s) 
 Variable(s)
  
  Perhaps you should use @ to indicate the required return type, 
  or $ to specify which version of the function you need.


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: [Axiom-mail] Programming with BTREEs.

2009-04-07 Thread Ralf Hemmecke

 Yet another instance of why I hate Any.

... The interpreter seems to like List(Any) more than my specific types. 
See bolow... :-(

Let's do a little programming ... this is the more complicated form.

Simon, my example is not completely finished since the MyBinaryTree you 
find below, doesn't have much functionality (except equality), but it is 
preferable to BinaryTree, because if you construct a tree in 
MyBinaryTree(I, L) then you have no chance to construct a tree that has 
inner nodes that are not of type I and leaves of any other type than L.
So the code below is an example of how to translate your tree structure 
into SPAD code.

The input then is

B := MyBinaryTree(List Integer, Symbol)
t: B := [e,[5,1],[[a,[1,1],b...@b,[1,1],[c,[1,2],d...@b]]

The @B is still needed since otherwise the Axiom/FriCAS interpreter 
tries to construct again something of type List(Any)... Extremely bad
behaviour of the interpreter in my eyes...

The @B is even needed if you add

l: List Symbol := [a,b,c,d,e]
(a,b,c,d,e):=(l 1, l 2, l 3, l 4, l 5)

before the assignment to t.

You have to live with that for the moment, at least you have the chance 
that adding @B gives a hint to the interpreter of what you actually 
intended with your input.

Try for example

t: B := [a,b,c]

You get

(5) - t:B := [a,b,c]

Cannot convert right-hand side of assignment
[a,b,c]

   to an object of the type MyBinaryTree(List(Integer),Symbol) of
   the left-hand side.

Seeing such error message in Axiom is quite common, but wait. Think of 
it for a moment. You just asked to system to create a tree for you 
(namely an element t of type B) which would have the inner node b. 
However, b is of type Symbol and inner nodes should not be of type 
Symbol, but rather of type List(Integer). So the system is completely 
right throwing that error message at you.

Imagine you are inside a big program and you've put there an assignment 
like (5). The SPAD compiler will detect that you are doing things where 
the types do not match and will tell you at compile time (not at runtime).

So here is your code... put it into aaa.spad and in Axiom say

)co aaa.spad

followed by the assignments at the beginning of this mail.

Ralf

---rhxBEGIN aaa.spad
-- Note that I and L must always be different types.
-- MyBinaryTree(Integer, Integer) is forbidden.

COUT==CoercibleTo(OutputForm)

)abbrev domain MBTREE MyBinaryTree
MyBinaryTree(I: COUT, L: COUT): COUT with
   construct: L - %
   construct: (L, I, L) - %
   construct: (%, I, L) - %
   construct: (L, I, %) - %
   construct: (%, I, %) - %
  == add
   N := Union(I, L)
   Rep := BinaryTree N
   construct(l: L): % == binaryTree(l::N)$Rep
   V == construct
   construct(l: L, i: I, r: L): % == binaryTree(V l, i, V r)
   construct(l: %, i: I, r: L): % == binaryTree(  l, i, V r)
   construct(l: L, i: I, r: %): % == binaryTree(V l, i,   r)
   construct(l: %, i: I, r: %): % == binaryTree(  l, i,   r)
   coerce(x: %): OutputForm == coerce(x)$Rep
   ((x: %) = (y: %)): Boolean == (x::Rep) =$Rep (y::Rep)
---rhxEND aaa.spad

--~--~-~--~~~---~--~~
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: input bug?

2009-04-07 Thread Bill Page

Martin,

As you may or may not know the 'r' in your input below is supposed to
stand for radix. So '2r...' indicates an integer written in base 2
notation. 8r would be octal notation etc. This works in OpenAxiom:

wsp...@debian:~$ open-axiom -nox
GCL (GNU Common Lisp)  2.6.7 CLtL1Sep  1 2008 14:01:57
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
 OpenAxiom: The Open Scientific Computation Platform
 Version: OpenAxiom 1.3.0-2009-03-08
Built on Tuesday March 17, 2009 at 08:13:56
-
   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) - 2r101

   (1)  5
Type: PositiveInteger
(2) - 8r777

   (2)  511
Type: PositiveInteger

---

But this is apparently currently broken in FriCAS. I vaguely recall a
patch Gaby made to OpenAxiom some months ago which may have been the
correction to this problem.

Regards,
Bill Page.

On Tue, Apr 7, 2009 at 9:52 AM, Martin Rubey wrote:

 What's going on here?

 (1) - 2r

   (1)  2R0
                                                          Type: Variable(2R0)
 (2) - 3r

   (2)  3R0
                                                          Type: Variable(3R0)
 (3) - 3s

   Cannot find a definition or applicable library operation named 3
      with argument type(s)
                                 Variable(s)

      Perhaps you should use @ to indicate the required return type,
      or $ to specify which version of the function you need.


 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: input bug?

2009-04-07 Thread Martin Rubey

Bill Page bill.p...@newsynthesis.org writes:

 Martin,
 
 As you may or may not know the 'r' in your input below is supposed to
 stand for radix. 

No, I didn't.

 So '2r...' indicates an integer written in base 2
 notation. 8r would be octal notation etc. This works in OpenAxiom:
 
 wsp...@debian:~$ open-axiom -nox
[...]
 (1) - 2r101
 
(1)  5

Oh dear, this looks terribly dangerous.  My 2r was a typo, I wanted
to type 2*r.  I just checked OpenAxiom, it gives 0 for 

2r*x

I'd vote for turning this feature off in FriCAS altogether (and
replace it by something less error prone)!

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: input bug?

2009-04-07 Thread Alfredo Portes

On Tue, Apr 7, 2009 at 12:44 PM, Martin Rubey
martin.ru...@math.uni-hannover.de wrote:

 Oh dear, this looks terribly dangerous.  My 2r was a typo, I wanted
 to type 2*r.  I just checked OpenAxiom, it gives 0 for

 2r*x

What result were you expecting? Just curious.

--~--~-~--~~~---~--~~
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: input bug?

2009-04-07 Thread Ralf Hemmecke

http://www.aldor.org/docs/HTML/chap5.html#2

'2r' should give a syntax error if neither 0 or 1 is following.

Ralf

On 04/07/2009 06:55 PM, Martin Rubey wrote:
 Alfredo Portes doyenatc...@gmail.com writes:
 
 On Tue, Apr 7, 2009 at 12:44 PM, Martin Rubey
 martin.ru...@math.uni-hannover.de wrote:

 Oh dear, this looks terribly dangerous.  My 2r was a typo, I wanted
 to type 2*r.  I just checked OpenAxiom, it gives 0 for

 2r*x
 What result were you expecting? Just curious.
 
 I'd hope for an error.  r is a variable name I use often, and at
 times I miss the multiplication sign.
 
 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: input bug?

2009-04-07 Thread Gabriel Dos Reis

Alfredo Portes doyenatc...@gmail.com writes:

| On Tue, Apr 7, 2009 at 12:44 PM, Martin Rubey
| martin.ru...@math.uni-hannover.de wrote:
| 
|  Oh dear, this looks terribly dangerous.  My 2r was a typo, I wanted
|  to type 2*r.  I just checked OpenAxiom, it gives 0 for
| 
|  2r*x
| 
| What result were you expecting? Just curious.

I think the scanner should have signaled a syntax error.  I'll fix
that tonight.  

Except that, I don't think integer literals expressed in radix
other than 10 are dangerous at all.


-- Gaby

--~--~-~--~~~---~--~~
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] Issue 443 and order on expressions.

2009-04-07 Thread Waldek Hebisch

AFAICS issue 443 is a latent bug which surfaced due to changes
in FriCAS-1.0.4.  Namely, keep kernels unique: when created
kerenel is inserted into a cache and later comparison just use
position in the cache.  Currently kernels in the cache are sorted.
Earlier versions used linear search, starting from 1.0.4 we use
binary search.

The core problem is that up to now order on kernels is _not_
a mathematical order.  Namely, it is possible to have kernels
k1, k2, k3 such that k1  k2, k3  k3, but k1 = k3.  This
can happen due to %specialEqual property -- using this
property we can cause some kernels to be treated us equal, but
for unequal kernels we use old comparison function.  In particular,
product(f(j), j = 1..n) and product(f(k), k = 1..n) are considered
equal.  OTOH product(f(k), k = 1..i) may be bigger or smaller
than the other depending on order in which they are created.

Using binary search for k3, after inserting k1 and k2 may
search for k3 in wrong part of the cache (the one which does
not contain k1), so that k3 is suddenly treated as different 
than k1.  AFAICS the same problem may happen using linear
search, but with much lower probability (the search for k3 is
considered unsuccessful if we find k2  k3, so k3 will be
inserted twice, however all subseqent searches will find k3
which limits potential for damage).

Now, how to solve the problem?  One way is to avoid using
order for searching (more on this later).  Another is to
make sure that we have mathematical order.  Note: by
mathematical order I mean that '=' and '' satisfy axioms
of ordered sets -- relations of '=' and '' to any
natural notions of equality and order is a separate topic.
Unfortunatly, the problem is deeper.  One thing is a technical
difficulty: to compare product(f(j), j = 1..n) and
product(f(k), k = 1..n) we substitute into f the same dummy
variable.  However, the result of ordered comparison may depend
on choice of variable, so we would need to come with some
canonical choice.  Another problem is that in the process
we need to compare fractions.  However '' on fractions is
a mathematical order only if base ring is ordered ring or
represetation is canonical.  Neither of them is satisfied
for expressions: algebraic numbers do not form ordered ring
and we keep algebraic quantities both in numerator and denominator,
which means that the mathematically equal expressions may
have quite different forms as fractions.  ATM it is not
clear for me fixing this issue is feasible: eliminating
algebraic quantities from denominators should may help but
it is not clear what would be performance impact and how
much code would we need to get proper order.

Concerning avoiding order: we need order for printing so we
can not avoid it completely.  For search we could use linear
search (without early exit) and only later ordered insertion
(if we know that the kernel is different that the old ones).
However linear search may be a too costly.  Alternatively
we could spead up search using hashing.  For that we need
a mathematical hash function, that is a functions h, such
that if k1 = k2 than h(k1) = h(k2).  Defining such function
has similar problems to defining mathematical order.  ATM
I am not sure if problems of hash function are easier to
solve than problems of order.

-- 
  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-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
-~--~~~~--~~--~--~---