Real symbolic variable

[Christophe Bal]

Hello.

How can I define a symbolic variable that is a real number ? Therer is an optional argument real in the latest versions of Sympy but this not work in Sage.

Christophe BAL

Enseignant de mathématiques en Lycée et développeur Python amateur

---

French math teacher in a "Lycée" and Python amateur developer

[Christophe Bal]

I've just tried

a = var("a")
assume(a, "real")

print a.is_real()

This prints False. Why ?

Christophe BAL

Enseignant de mathématiques en Lycée et développeur Python amateur

---

French math teacher in a "Lycée" and Python amateur developer

[Vegard Lima]

Hi,

On Thu, Jan 29, 2015 at 12:33 PM, Christophe Bal <proj...@gmail.com> wrote:
> I've just tried
>
> a = var("a")
> assume(a, "real")
>
> print a.is_real()
>
> This prints False. Why ?

I can't answer why, but an option is to use
var('a',domain='real')
but that seems to behave a bit strangely:

sage: a = var('a')
sage: a.is_real()
False

sage: assume(a,"real")
sage: a.is_real()
False

sage: a = var('a',domain='real')
sage: a.is_real()
True

sage: a = 2+2*I
sage: a.is_real()
False

sage: a = var('a')
sage: a.is_real()
True


Cheers,
--
Vegard Lima

[Christophe Bal]

Thanks for the argument domain.

For the end of the code, this sounds like a bug.

Christophe BAL

Enseignant de mathématiques en Lycée et développeur Python amateur

---

French math teacher in a "Lycée" and Python amateur developer

--
Vegard Lima

--
You received this message because you are subscribed to the Google Groups "sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-support...@googlegroups.com.
To post to this group, send email to sage-s...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.

[Michael Orlitzky]

On 01/28/2015 03:56 PM, Christophe Bal wrote:
> Hello.
>
> How can I define a symbolic variable that is a real number ? Therer is an
> optional argument real in the latest versions of Sympy but this not work in
> Sage.
>

There isn't much support for declaring a variable real in Sage. By
default every variable is complex, but there are some operations that
will treat them as real.

We have three ways to "declare" a variable real but they're all weird:

* assume(x, 'real')
* x = SR.var('x', domain='real')
* Set the maxima simplification domain to real through some backdoor

I don't know what (if anything) the second one does. The first allows
Maxima to make some simplifications it otherwise couldn't. The third
lets sqrt(x^2) be equal to abs(x) but there's no easy way to do it. And
even though #1 and #3 both use Maxima, #3 doesn't imply #1.

In the next release you'll be able to do expr.simplify_real() and have
it do #1 #2 and #3 all at once along with simplify_log().

So really what we need to know is, why do you want to declare a real
variable? You might be better served by a polynomial ring or some linear
algebra thing.

[William Stein]

On Thu, Jan 29, 2015 at 4:58 AM, Christophe Bal <proj...@gmail.com> wrote:
> Thanks for the argument domain.
>
> For the end of the code, this sounds like a bug.

No -- I thought somebody would answer, but nobody did. The following
is definitely *not* a bug:

>> sage: a = 2+2*I
>> sage: a.is_real()
>> False

What's happening here is that you assign a 2+2*I, which is complex.
At this point the variable a in Python is a reference to the symbolic
expression 2+2*I. It has absolutely nothing whatsoever to do with
what a was equal to when you typed:

>> sage: a = var('a',domain='real')
>> sage: a.is_real()
>> True

This is because Python is a *dynamically* typed language. Thinking
that doing something like

a = var('a',domain='real')

would have any impact on what

a = BLAH

means would only make sense in a statically typed programming
language, such as C++ or Java.

-- William

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Christophe Bal]

For the bug, in the following example proposed by Vegrad LIma, the 1st and last line look contradictory in a dynamical language.

sage: a = var('a')
sage: a.is_real()
False

sage: assume(a,"real")
sage: a.is_real()
False

sage: a = var('a',domain='real')
sage: a.is_real()
True

sage: a = 2+2*I
sage: a.is_real()
False

sage: a = var('a')
sage: a.is_real()
True

Christophe BAL

Enseignant de mathématiques en Lycée et développeur Python amateur

---

French math teacher in a "Lycée" and Python amateur developer

[Christophe Bal]

Hello.

Indeed, I just want to define complex number via the algebraic form z=a+i*b.

expr.simplify_real() will be a great tool. I will be patient...

Christophe BAL

Enseignant de mathématiques en Lycée et développeur Python amateur

---

French math teacher in a "Lycée" and Python amateur developer

[Michael Orlitzky]

On 01/29/2015 06:14 PM, Christophe Bal wrote:
> Hello.
>

> Indeed, I just want to define complex number via the algebraic form z=a+i*b.
>
> expr.simplify_real() will be a great tool. I will be patient...
>
>

It's actually already there, but at moment all you'll get out of it is
abs(x) == sqrt(x^2). It's also safe to call simplify_full() on a real
symbolic variable -- simplify_real() will contain only those
simplifications that *aren't* safe for complex numbers.

I've tried to do something similar before with multiple real
coefficients; something like z = a + i*b + j*c + ... + k*m. It got ugly
real quick, and depending on the operations I was doing, sage wasn't
always able to group the results by i,j,k, etc. Since you only need two
dimensions, you might try using symbolic matrices containing real
variables instead:

a + b*i ~ [a, -b]
[b, a]

You can do complex arithmetic using matrix operations, but you'll always
know that the entries of the matrices are real so you can call
simplify_real/full() on them.

[Vegard Lima]

On Thu, Jan 29, 2015 at 11:55 PM, William Stein <wst...@gmail.com> wrote:
> This is because Python is a *dynamically* typed language. Thinking
> that doing something like
>
> a = var('a',domain='real')
>
> would have any impact on what
>
> a = BLAH
>
> means would only make sense in a statically typed programming
> language, such as C++ or Java.

But I think that was my point...

If you do something like this

sage: a = var('a',latex_name='BLAH')

and then

sage: a = var('a')

sage: latex(a)
BLAH

So the first a=var(...) did have an impact on the second one, no?


Cheers,
--
Vegard

[Christophe Bal]

I also think that the 2nd use if var should erase the 2nd.

[Christophe Bal]

I would like to say that the 2nd use of the function var should erase the settings of the 1st one.

Christophe BAL

Enseignant de mathématiques en Lycée et développeur Python amateur

---

French math teacher in a "Lycée" and Python amateur developer

[Christophe Bal]

Hello.

Thanks for the information about simplify_full().

For the use of matrix instead of complexes, I can't do that with my students because they don't know matrices.

Christophe BAL

Enseignant de mathématiques en Lycée et développeur Python amateur

---

French math teacher in a "Lycée" and Python amateur developer

[Lee Worden]

On Thursday, January 29, 2015 at 10:17:32 PM UTC-8, Vegard Lima wrote:

But I think that was my point...

If you do something like this

sage: a = var('a',latex_name='BLAH')

and then

sage: a = var('a')

sage: latex(a)
BLAH

So the first a=var(...) did have an impact on the second one, no?

 
I think this is this issue: http://trac.sagemath.org/ticket/17559

I've just updated that bug report to include this example.
lw

[Christophe Bal]

Sorry for m'y repeated mails. I do not want to do that. I beg your pardon.

--

[Vegard Lima]

On Fri, Jan 30, 2015 at 8:05 PM, Lee Worden <worde...@gmail.com> wrote:
> On Thursday, January 29, 2015 at 10:17:32 PM UTC-8, Vegard Lima wrote:
>> But I think that was my point...
>>
>> If you do something like this
>>
>> sage: a = var('a',latex_name='BLAH')
>>
>> and then
>>
>> sage: a = var('a')
>>
>> sage: latex(a)
>> BLAH
>>
>> So the first a=var(...) did have an impact on the second one, no?
>
> I think this is this issue: http://trac.sagemath.org/ticket/17559

I've looked at this again, and I don't think your bug is related.

The problem above is caused by sage reusing
"already existing variables" in the symbol function
in sage/symbolic/ring.pyx. This "fixes" the above bug:

diff --git a/src/sage/symbolic/ring.pyx b/src/sage/symbolic/ring.pyx
index f87f622..6972018 100644
--- a/src/sage/symbolic/ring.pyx
+++ b/src/sage/symbolic/ring.pyx
@@ -555,7 +555,7 @@ cdef class SymbolicRing(CommutativeRing):
e = pynac_symbol_registry.get(name)

# fast path to get an already existing variable
- if e is not None:
+ if False: # e is not None:
if domain is None:
if latex_name is None:
return e

--
Vegard Lima