axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Am I posing this solve problem wrong?


From: Ralf Hemmecke
Subject: Re: [Axiom-developer] Am I posing this solve problem wrong?
Date: Tue, 06 May 2008 22:33:24 +0200
User-agent: Thunderbird 2.0.0.14 (X11/20080421)

I do not know what is the general opinion, but in my opinion all
operations like 'solve' should have a well-defined and fairly simple
relationship to other operations in the same domain.  For example
something like the following should always be true:

    eval(E,solve(E,...))                                    (*)

We should be able to specify the behavior of 'solve' in terms of such
axioms.

You know that this is a *very* weak condition. Take E to be x^2+1=0 and solve returning only the imaginary i (no not -i). Than your condition (*) above is true, but solve gave only part of the answer. Now, if I want to find all real solutions and E has none, how is that covered in (*)?

For example,

(1) -> EQ1:=x+1=0

   (1)  x + 1= 0
                                            Type: Equation Polynomial Integer
(2) -> reduce(_and,[eval(EQ1,s) for s in solve(EQ1)],true)

   (2)  true

If you use that command for testing, the most bugfree implementation of solve would be to *always* return the empty list.

(3) -> EQ2:=[x+1=0,y+1=x]

   (3)  [x + 1= 0,y + 1= x]
                                       Type: List Equation Polynomial Integer
(4) -> reduce(_and,concat [map(x+->eval(x,s),EQ2) for s in solve(EQ2)],true)

   (4)  true
                                                                Type: Boolean

The axiom from above is getting more and more complicated and still only tests half of the properties that one could wish for solve.

Or did you have something else in mind?
Yep. I was looking for solutions that live in R.
Ok. A different problem, I think.
It depends. Cliff did not say where he expects the result to live.

Yes, therein lies the problem that the Axiom interpreter attempts to solve.

You know my attitude. The Axiom interpreter is quite smart, but I would rather like to see the information in the library and remove some more the burden of guessing from the interpreter. Things that could be made precise should live in the library.

Consider the simple equation.

 x + 1 = 0

What does "solve for x" actually mean? It is ambiguous.
I would like to say

 solve(x+1=0, x)$Set(PositiveInteger)
 solve(x+1=0, x)$Set(Integer)

(or similar) and get different results.
Ooops, I should have written "@Set(...)" above, because I wanted to specify
the result type. But maybe, it would even be better to give it as an
argument like

 solve(x+1=0, x, PositiveInteger)

or so.

No I think your first idea was correct. It should be possible to
specify the desired output in order to aid the function selection
process.

Whether to give more information as an argument or via specifying the result type doesn't matter too much now. More important is that a user should be able to specify the solution space (ehm, search space).

Unfortunately the Axiom interpreter still fails to find the
solution in this case:

I don't think that should be the task of finding the right function.
If there is none appropriate in the library, the interpreter should issue some warning and only then start guessing and coercing and whatever. But it should be pretty transparent what is actually computed until the result appears on screen.

(1) -> E3 := x^2*D1^2+(y-y1)^2*C1^2 - C1^2*D1^2

          2  2      2         2 2     2 2     2  2
   (1)  C1 y1  - 2C1 y y1 + C1 y  + D1 x  - C1 D1
                                                     Type: Polynomial Integer
(2) -> solve(E3,y)@List Equation Expression Integer
   There are 20 exposed and 3 unexposed library operations named solve
      having 2 argument(s) but none was determined to be applicable.
      Use HyperDoc Browse, or issue
                              )display op solve
      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 solve
      with argument type(s)
                             Polynomial Integer
                                 Variable y

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

But of course this works if we give the interpreter enough help...

(2) -> solve(E3::Expression Integer, y)@List Equation Expression Integer

               +----------+                 +----------+
               |   2     2                  |   2     2
            D1\|- x  + C1   + C1 y1    - D1\|- x  + C1   + C1 y1
   (2)  [y= -----------------------,y= -------------------------]
                       C1                          C1
                                       Type: List Equation Expression Integer

Uhhhh... Expression Integer again... That sounds so typeless. ;-)


Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]