Why solve(5^( x -1) == (0.04)^(2*x), x) returns empty set?

[Chris Seberino]

command in subject line should return 1/5 not empty set right??? What gives?

[RRogers]

Apparently the default solver doesn't do logarithms.

For the default try: 

solve(log(5^( x -1)) == log((0.04)^(2*x)), x)

[x == 8104022*log(5)/(8104022*log(5) + 52171681)]

[Emmanuel Charpentier]

Why 0.04 ? Th notebook says :

S=(5^( x -1) == (0.04)^(2*x)).subs({0.04:1/25}).log().solve(x) ; S

[x == log(5)/(2*log(25) + log(5))]
bool(S[0].rhs()==1/5)
True

(The last step is easily done by mental computation ; this is only a check.).

HTH,

--
Emmanuel Charpentier

[Chris Seberino]

If you ask Sage to do something it can't, like solve a quintic polynomial equation, it will spit the question back at you.

If Sage did that I'd be fine.  However, Sage spit back the empty set which is the WRONG answer and far different yes?

[Chris Seberino]

I didn't *need* to have 0.04.  This is just a command that actually came up in real work.

I didn't want to alter it in any way lest it may be a genuine bug.

cs

[Emmanuel Charpentier]

Le lundi 17 novembre 2014 17:32:27 UTC+1, Chris Seberino a écrit :

If you ask Sage to do something it can't, like solve a quintic polynomial equation, it will spit the question back at you.

If Sage did that I'd be fine.  However, Sage spit back the empty set which is the WRONG answer and far different yes?

That weakness of sage's (maxima's, indeed) is well known. In maxima, an alternative solver (%solve, a. k. a. to_poly_solve) is available, that sage can use through the to_poly_solve option of sage's solve :

sage: solve(5^( x -1) == (1/25)^(2*x), x, to_poly_solve=True)
[x == (2*I*pi*z54 + log(5))/log(3125)]

which gives you also the set of complex solutions (log is multivalued in the complex plane...).

Sage seems to have trouble finding that log(3125)=log(5^5)=5*log(5), which it can easily check. So substitute it by hand to get an expression easier to handle.

HTH,

--
Emmanuel Charpentier

[Chris Seberino]

Emmanuel

Any way to make Sage act like it can't find the solution (emit question back to user) INSTEAD of emitting the empty set?

"I can't find the solution" and "There is no solution" are NOT the same thing?

cs

[Emmanuel Charpentier]

Indeed. But  proving that "There is no solution"  might inded invorve some serious work. Consider (pseudocode) :
var("a,b,c,n")
assume(a,"integer",b,"integer",c,"integer",n,"integer",a>0,b>0,c>0,n>2)
solve(a^n+b^n==c^n,[a,b,c,n])
which has, indeed no solution. Proving this has been found a bit involved...

So you can assume that an empty list means only that sage's algorithms find no solution.

Your point is that, in your example, sage returns (incorrectly) an empty list.In other cases, it returns the original equation.

Indeed. So what ?

I have not (yet) found a specification for those two cases, but I think it depends on which algorithm has been used. (Maxima may return the empty list in cases solve'() does not succeds).

Beware : in other cases, sage might return an implicit solution, given as an equation.

cs

[Jakob Kroeker]

So you can assume that an empty list means only that sage's algorithms find no solution.

I just looked at the documentation of solve and could not find an explicit statement about missed solutions.

Even if it is expectable that in some cases (which?) solve may not return all solutions, it should be explicitly pointed out;
Especially it should be stated that an empty list does not necessarily imply there are no solutions.

Other opinions? If everybody agrees, I will open a ticket.


Jakob

[kcrisman]

So you can assume that an empty list means only that sage's algorithms find no solution.

I just looked at the documentation of solve and could not find an explicit statement about missed solutions.

Even if it is expectable that in some cases (which?) solve may not return all solutions, it should be explicitly pointed out;
Especially it should be stated that an empty list does not necessarily imply there are no solutions.

Other opinions? If everybody agrees, I will open a ticket.

Updating the documentation of both solve? and x.solve? to make it clear that this is the case would be very helpful.  It is similar to how our Booleans on expression comparisons return False if we can't prove True. 

[Jakob Kroeker]

kcrisman:
 

It is similar to how our Booleans on expression comparisons return False if we can't prove True

Could the usage of a sort of Tristate/multistate implementation kill that universe of worms?
(With the following design: Tristate only comparable to Tristate objects)


Jakob

[Emmanuel Charpentier]

Le mercredi 19 novembre 2014 16:31:35 UTC+1, Jakob Kroeker a écrit :

kcrisman:
 

It is similar to how our Booleans on expression comparisons return False if we can't prove True

Could the usage of a sort of Tristate/multistate implementation kill that universe of worms?
(With the following design: Tristate only comparable to Tristate objects)

That's opening another (large) can of worms... ('bout the size of an oil barrel...) : this might give you an estimate of the size of the problem. Furthermore, use of that extension would have pervasive effects in the whole of Sage.For example, what should do a function expecting either True or False when getting an hypothetical Unknown ? One might map (coerce) the Tristate Unknown to False and get the same behaviour, but wouldn't this defeat the very purpose of adding Tristate ? Furthermore, most of Sage has been written with the assumption "not(not(X))==X", which no longer holds...

BTW, Maxima has this kind of logic (for example, "is" can return "true", "false" or "unknown") and uses it, so it's at least conceptually doable. And useful ! But with very deep consequences.

Shouldn't this be discussed on sage-devel ?

HTH,

--
Emmanuel Charpentier

[Robert Dodier]

On 2014-11-20, Emmanuel Charpentier <emanuel.c...@gmail.com> wrote:

> BTW, Maxima has this kind of logic (for example, "is" can return "true",
> "false" or "unknown") and uses it, so it's at least conceptually doable.
> And useful ! But with very deep consequences.

For the record, Maxima has a global flag prederror which governs the
evaluation of predicates. When prederror=false (default), is(p) =>
unknown when p is not known (to Maxima) to be true or false, and
if p then ... evaluates to a partially-evaluated conditional
expression. When prederror=true, is(p) and if p then ... trigger
an error.

In practice, this has worked well enough, i.e. without causing too
much confusion -- I don't remember any complaints about programs
assuming true/false not working as expected. A more theoretical
problem is that Maxima's partial evaluation policy isn't entirely
consistent -- when p isn't decidable to Maxima, you can get a
partially-evaluated conditional, but not a partially-evaluated
loop (triggers an error), and various programming functions (e.g.
length, first, integerp) might act in an unexpected way. This, too,
hasn't caused trouble, from what I remember.

FWIW

Robert Dodier

[Chris Seberino]

On Wednesday, November 19, 2014 8:48:07 AM UTC-6, Jakob Kroeker wrote:

Even if it is expectable that in some cases (which?) solve may not return all solutions, it should be explicitly pointed out;
Especially it should be stated that an empty list does not necessarily imply there are no solutions.

Yes!  Actually adding something like the following would be an improvement....

if (answer == []) and not_sure_there_are_no_solutions:

        print question

else:

        print answer

I heard Emmanuel's warning that the not_sure_there_are_no_solutions boolean may be hard to calculate in some cases.

In my opinion, not_sure_there_are_no_solutions should default to True unless it is a case where

we can with certaintly set not_sure_there_are_no_solutions = False.

Other opinions? If everybody agrees, I will open a ticket.

Please do!  Thanks! 

 

[Raymond Rogers]

In general people don't like double negatives :)  How about
"solution(s) not found"

[Jakob Kroeker]

Other opinions? If everybody agrees, I will open a ticket.

 

Please do!  Thanks!

here is the corresponding ticket:

http://trac.sagemath.org/ticket/17412