[Top][All Lists]
[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
- Re: [Axiom-developer] Am I posing this solve problem wrong?, (continued)
- Re: [Axiom-developer] Am I posing this solve problem wrong?, C Y, 2008/05/04
- Re: [Axiom-developer] Am I posing this solve problem wrong?, Bill Page, 2008/05/04
- Re: [Axiom-developer] Am I posing this solve problem wrong?, Ralf Hemmecke, 2008/05/05
- Re: [Axiom-developer] Am I posing this solve problem wrong?, Bill Page, 2008/05/05
- Re: [Axiom-developer] Am I posing this solve problem wrong?, Ralf Hemmecke, 2008/05/05
- Re: [Axiom-developer] Am I posing this solve problem wrong?, Bill Page, 2008/05/05
- Re: [Axiom-developer] Am I posing this solve problem wrong?, Ralf Hemmecke, 2008/05/05
- Re: [Axiom-developer] Am I posing this solve problem wrong?, Bill Page, 2008/05/06
- Re: [Axiom-developer] Am I posing this solve problem wrong?, Martin Rubey, 2008/05/06
- Re: [fricas-devel] Re: [Axiom-developer] Am I posing this solve problem wrong?, Bill Page, 2008/05/06
- Re: [Axiom-developer] Am I posing this solve problem wrong?,
Ralf Hemmecke <=