Ask Your Question

brkirch's profile - activity

2016-08-02 20:36:05 +0200 received badge  Notable Question (source)
2015-01-18 08:43:05 +0200 received badge  Popular Question (source)
2014-01-20 17:28:10 +0200 received badge  Scholar (source)
2014-01-20 17:28:10 +0200 marked best answer simplify_full - is the mistake in the documentation or the source code?

Good catch ! simplify_radical() was removed from simplify_full() and full_simplify() in trac ticket 12737, but not from the documentation. I created trac ticket 15693 to solve this.

Thanks for reporting.

2014-01-19 02:57:16 +0200 received badge  Supporter (source)
2014-01-18 08:53:24 +0200 received badge  Student (source)
2014-01-17 16:38:00 +0200 asked a question simplify_full - is the mistake in the documentation or the source code?

Looking at the simplify_full documentation in Sage 6.0, it says that it

Applies simplify_factorial, simplify_trig, simplify_rational, simplify_radical, simplify_log, and again simplify_rational to self (in that order).

However the source code is

def simplify_full(self):
    x = self
    x = x.simplify_factorial()
    x = x.simplify_trig()
    x = x.simplify_rational()
    x = x.simplify_log('one')
    x = x.simplify_rational()
    return x

So where is the mistake? Should simplify_radical be added to the source code or removed from the documentation?

2014-01-16 03:57:21 +0200 received badge  Editor (source)
2014-01-15 20:17:23 +0200 asked a question How to simplify log expressions that result in an integer?

I'm having problems with Sage not simplifying log expressions that result in an integer. For example

x = var('x')
solve(2^x==4, x)


[x == log(4)/log(2)]

despite the fact that the more correct answer is [x == 2]. Is there any way to get Sage to simplify expressions like this to an integer? I already tried

y = log(4)/log(2)



but in both cases the expression was returned unchanged. I know it is possible to estimate the value (e.g. with n(log(4)/log(2)) ) or manually rewrite the expression to log(4, 2), but those workarounds are far from optimal.