[sage-devel] Access to old binaries

[Ondřej Čertík]

Hi,

We test our library against Sage on Travis-CI, so we install it like this:

wget -O- 
http://files.sagemath.org/linux/64bit/sage-6.9-x86_64-Linux-Ubuntu_12.04_64_bit.tar.lrz
| lrzip -dq | tar x

and lately the sage-6.9-x86_64-Linux-Ubuntu_12.04_64_bit.tar.lrz
version is not available anymore, so our Travis-CI fails. We are
having some issues with the newer version of Sage, so until we fix our
library, it would make our life a lot easier if we can simply continue
testing a given Sage version, and upgrade when we are ready.

Is there a way to access this particular binary
sage-6.9-x86_64-Linux-Ubuntu_12.04_64_bit.tar.lrz? I tried to google
it, but I was unsuccessful.

I'll be archiving the binaries that we need on Travis from now on, I
just didn't know that it would disappear.

Ondrej

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

Re: [sage-devel] Re: Access to old binaries

[Ondřej Čertík]

On Thu, Jan 28, 2016 at 12:55 PM, Volker Braun  wrote:
> We do delete old binaries to not over stay our welcome with the mirror
> admins...
>
> I restored (note gz instead of lrz)
> http://files.sagemath.org/linux/64bit/sage-6.9-x86_64-Linux-Ubuntu_12.04_64_bit.tar.gz

Yes, that's a good thing. Thanks for restoring it, I downloaded and
I'll host it myself for our Travis-CI.

Ondrej

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

Re: [sage-devel] packaging vision (pip etc)

[Ondřej Čertík]

On Tue, Aug 11, 2015 at 7:44 AM, William Stein wst...@gmail.com wrote:
 On Tue, Aug 11, 2015 at 1:15 AM, Volker Braun vbraun.n...@gmail.com wrote:
 [Top-posted to stop threadjacking the SymEngine post]

 I'm sorry for doing that -- it was sort of relevant to his question,
 but starting a new thread is much better.


 Just have the sage-python-library install using pip, assuming your system
 has all the dependencies, is almost trivial. The real question is always how
 to handle the dependencies, starting at a Fortran compiler. Also, just to
 establish a baseline for discussion, Daniel Holth (pip author) said: When
 people ask whether wheel can be used to distribute any other kind of
 software or dependency (libsdl, libqt, etc.) I recommend they take a look at
 system packaging tools or conda (comment at
 http://continuum.io/blog/conda_packaging).

 So IMHO the right solution is to first separate all the C/C++-level
 dependencies (gcc, pari, python itself,...) from the Python libraries. We
 still need a way to have a canonical stack of the C/C++ dependencies to
 test against and patch if necessary, but you could switch that for OS
 packages (if there is such a thing on your platform). There are various ways
 to do this, hashdist being one of them, and we can likely share at least
 some of the package maintenance effort with others.

 +1  -- this makes good sense.

I like this. I was going to ask about it, because SymEngine depends on
CMake, and that's not very practical to build using pip. Also, we are
discussing to split the symengine C++ library and its Python wrappers
into separate packages (so that the Python wrappers can be installed
against multiple Python versions at once, if needed, and also so that
other wrappers like Julia/Ruby can reuse the same C++ library --- it
can be done already, but it's cleaner if it is separate). The C++
package can be installed using cmake and would be part of the C/C++
level dependencies. The Python wrappers would be installed using pip,
and those would be tightly integrated with SymPy and Sage.

That seems to be aligned with what Volker proposed. Let me know.

Ondrej


 Then sage-the-python-library could just install itself and its Python
 dependencies with pip and requirements.txt

 That would be awesome.



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



 --
 William (http://wstein.org)

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

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

Re: [sage-devel] packaging vision (pip etc)

[Ondřej Čertík]

On Sun, Aug 16, 2015 at 3:33 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Aug 11, 2015 at 7:44 AM, William Stein wst...@gmail.com wrote:
 On Tue, Aug 11, 2015 at 1:15 AM, Volker Braun vbraun.n...@gmail.com wrote:
 [Top-posted to stop threadjacking the SymEngine post]

 I'm sorry for doing that -- it was sort of relevant to his question,
 but starting a new thread is much better.


 Just have the sage-python-library install using pip, assuming your system
 has all the dependencies, is almost trivial. The real question is always how
 to handle the dependencies, starting at a Fortran compiler. Also, just to
 establish a baseline for discussion, Daniel Holth (pip author) said: When
 people ask whether wheel can be used to distribute any other kind of
 software or dependency (libsdl, libqt, etc.) I recommend they take a look at
 system packaging tools or conda (comment at
 http://continuum.io/blog/conda_packaging).

 So IMHO the right solution is to first separate all the C/C++-level
 dependencies (gcc, pari, python itself,...) from the Python libraries. We
 still need a way to have a canonical stack of the C/C++ dependencies to
 test against and patch if necessary, but you could switch that for OS
 packages (if there is such a thing on your platform). There are various ways
 to do this, hashdist being one of them, and we can likely share at least
 some of the package maintenance effort with others.

 +1  -- this makes good sense.

 I like this. I was going to ask about it, because SymEngine depends on
 CMake, and that's not very practical to build using pip. Also, we are
 discussing to split the symengine C++ library and its Python wrappers
 into separate packages (so that the Python wrappers can be installed
 against multiple Python versions at once, if needed, and also so that
 other wrappers like Julia/Ruby can reuse the same C++ library --- it
 can be done already, but it's cleaner if it is separate). The C++
 package can be installed using cmake and would be part of the C/C++
 level dependencies. The Python wrappers would be installed using pip,
 and those would be tightly integrated with SymPy and Sage.

 That seems to be aligned with what Volker proposed. Let me know.

And my next question is what should we do currently to make it easy
for Sage users to install SymEngine. Should we continue using the spkg
to install the C++ dependencies (cmake, the C++ libsymengine.so
library) and then use pip to install the Python wrappers?

Ondrej

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

Re: [sage-devel] packaging vision (pip etc)

[Ondřej Čertík]

On Sun, Aug 16, 2015 at 8:08 PM, François Bissey
francois.bis...@canterbury.ac.nz wrote:
 On 08/17/15 09:46, Ondřej Čertík wrote:
 And my next question is what should we do currently to make it easy
 for Sage users to install SymEngine. Should we continue using the spkg
 to install the C++ dependencies (cmake, the C++ libsymengine.so
 library) and then use pip to install the Python wrappers?

 As far as I can see the biggest obstacle is the inclusion of cmake
 in sage.
 While functionally equivalent autotools has a strong lead in mind
 share and length of its proven record.
 The fact that autotools doesn't need anything to be installed for the
 user deploying is also usually seen as a bonus. If you had
 50 packages using cmake, having to install one more wouldn't
 seem such a bad deal but that's not where we are.

So now when we agreed to split the C++ library from the Python
wrappers (and use pip for those), the C++ library itself is actually
relatively easy to build, and so in principle we can also support
autotools, especially if we only support the Release configuration
using it. For development we would still use cmake.

But I think getting cmake into Sage would be worthy, there are a lot
of packages that use it and it has wide adoption (e.g. VTK, Paraview,
Piranha, Armadillo, CGAL, Dolfin, Eigen, GiNaC, Gromacs, HPX, ITK,
Lapack, LLVM, MPQC, Trilinos, ...). Even Google trends (I don't know
if it is representative) shows that cmake is more searched than
autotools/automake:

https://www.google.com/trends/explore#q=cmake%2C%20autotools%2C%20automakecmpt=qtz=Etc%2FGMT%2B6

Ondrej

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

[sage-devel] SymEngine 0.1.0 released

[Ondřej Čertík]

Hi,

We just released SymEngine 0.1.0:

https://github.com/sympy/symengine/releases/tag/v0.1.0

SymEngine (https://github.com/sympy/symengine) is a standalone fast
C++ symbolic manipulation library. Optional thin wrappers allow usage
of the library from other languages, we currently have C, Python, Ruby
and Julia wrappers. The Python wrappers allow integration with SymPy
and Sage.

SymEngine was previously called CSymPy, but we renamed it, since it
can be used from any language, not just Python. Even though the Python
wrappers are the most developed, and I am personally heavily invested
in Python and my long term goal is to figure out how to port SymPy on
top of SymEngine, as well as Sage on top of SymEngine. So that we can
have just one symbolic library, that is fast, but also has a lot of
features, either in terms of SymPy in Python, or eventually in C++
(that way other languages can benefit as well).

Here are build instructions for Sage:
https://github.com/sympy/symengine/wiki/Building-SymEngine#installing-into-sage,
we tested it on Sage Math Cloud. You can then use Sage with SymEngine
in it to run your favorite benchmark.

We also have some automatic benchmarks, some timings are posted here:
https://github.com/sympy/symengine/pull/579


We benchmark both the Python wrappers (against Sage or SymPy), as well
as just the raw C++ library (against e.g. GiNaC).

Most of these benchmarks are synthetic, and so the problem with them
is that you can for example use a fast polynomial library to do them
faster. SymEngine seems to be faster than Sage on all of them, but if
you find some where Sage is faster, definitely let me know.

However, much better is to benchmark on some real applications. Here
is an example: 
https://github.com/certik/symengine/pull/10#issuecomment-129199481,
that uses symbolics (as it has square roots, fractions, sin, cos and
other things) and it is benchmarking how long it takes to do a
derivative (once the expression is fully converted to Sage, SymEngine
or SymPy). The expression comes up when calculating equations of
motion for a bicycle using PyDy (http://www.pydy.org/), you actually
need a Jacobian, but this is just one element of it.
And Sage seems 6x slower. The benchmark is here:
https://github.com/sympy/symengine/pull/580, it's the kane3.py. It
should be pointed out that Sage might arrange the final expression a
bit differently, so a meaningful benchmark is to do the whole bicycle
application, not just one derivative.

But so far my experience has been that SymEngine is faster than Sage
(sometimes significantly, I think 6x is a good speedup) and if you
find some application or a case when Sage is faster, please let me
know.


What is the best way to maintain a package like this for Sage --- we
currently create an spkg, but I read somewhere that spkgs will be
deprecated? Right now we want to maintain it ourselves and make it
easy for people to try out and if enough people like it, we can start
discussing more how to make Sage use it by default.

As I said, that is my long term goal, but it is a lot of work. If
successful though, users and developers of Sage can then contribute to
it and then anybody else who uses SymEngine outside of Sage will
immediately benefit, and vice versa. And by being in C++, not just
Python users will benefit, since the main development is done in C++.
There are lots of people in Ruby, Julia, even Haskell who ask for a
symbolic package. And this can be it.

The C++ code is truly cross platform, we test every commit with
gcc/clang on linux, gcc/apple clang on OS X and MSVC/mingw on Windows.
I also test manually with Intel and PGI compilers. See here for more
details: https://github.com/sympy/symengine/wiki/Compiler-Support

There will be bugs that you might discover during building it, but
they can be fixed if you report them. Inherently it should build using
any recent C++11 compiler on any platform.

If you try it out, we would be interested in any feedback, both
positive and negative. Isuru has spent most of the summer making it
working well with Sage and improving the code overall. And several
other GSoC students have been working on it as well.

Ondrej

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

Re: [sage-devel] The fastest way to expand((a1+a2+a3+a4+sqrt(3)*a5)^25)

[Ondřej Čertík]

Hi Miguel,

On Mon, Jan 19, 2015 at 4:03 PM, mmarco mma...@unizar.es wrote:
 It is much faster to work with absolute fields instead of towers of
 extensions:

 sage: K.sqrt3=QuadraticField(3)
 sage: F.sqrt5=K.extension(x^2-5)
 sage: R.a1,a2,a3,a4,a5 = F[]
 sage: %time _=(a1+a2+a3+sqrt5*a4+sqrt3*a5)^25
 CPU times: user 27.4 s, sys: 12 ms, total: 27.4 s
 Wall time: 27.5 s
 sage: FF.a=F.absolute_field()
 sage: fsqrt3=FF(F(sqrt3))
 sage: fsqrt5=FF(sqrt5)
 sage: RR.a1,a2,a3,a4,a5 = FF[]
 sage: %time _=(a1+a2+a3+fsqrt5*a4+fsqrt3*a5)^25
 CPU times: user 1.26 s, sys: 3 ms, total: 1.27 s
 Wall time: 1.27 s

Thanks. I tried it on SMC:

sage: K.sqrt3=QuadraticField(3)
sage: F.sqrt5=K.extension(x^2-5)
sage: R.a1,a2,a3,a4,a5 = F[]
sage: %time _=(a1+a2+a3+sqrt5*a4+sqrt3*a5)^18
CPU times: user 2.76 s, sys: 12.5 ms, total: 2.77 s
Wall time: 2.77 s
sage: len(str(_).split(+))
7315
sage: FF.a=F.absolute_field()
sage: fsqrt3=FF(F(sqrt3))
sage: fsqrt5=FF(sqrt5)
sage: RR.a1,a2,a3,a4,a5 = FF[]
sage: %time _=(a1+a2+a3+fsqrt5*a4+fsqrt3*a5)^18
CPU times: user 320 ms, sys: 0 ns, total: 320 ms
Wall time: 320 ms
sage: len(str(_).split(+))
12430

and your approach returns a wrong number of terms, so something is
wrong. But it is quite fast.

Ondrej

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

Re: [sage-devel] The fastest way to expand((a1+a2+a3+a4+sqrt(3)*a5)^25)

[Ondřej Čertík]

On Mon, Jan 19, 2015 at 11:19 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 Hi Vincent,

 On Sun, Jan 18, 2015 at 10:06 AM, Vincent Delecroix
 20100.delecr...@gmail.com wrote:
 Hi,

 2015-01-18 18:03 UTC+01:00, Ondřej Čertík ondrej.cer...@gmail.com:
 Can you invent an example, that can't be converted to polynomials?
 Perhaps (a1+a2+a3+sqrt(5)*a4+sqrt(3)*a5)^25?

 Still doable. You need to involve log, exp, cos or similar
 transcendental functions.

 Can you show me how to do that? I tried:

 sage: K.sqrt3 = QuadraticField(3)
 sage: K.sqrt5 = QuadraticField(5)
 sage: R.a1,a2,a3,a4,a5 = K[]
 sage: time f = (a1+a2+a3+sqrt5*a4+sqrt3*a5)^25

 But I got:

 TypeError: unsupported operand parent(s) for '*': 'Number Field in
 sqrt3 with defining polynomial x^2 - 3' and 'Multivariate Polynomial
 Ring in a1, a2
 , a3, a4, a5 over Number Field in sqrt5 with defining polynomial x^2 - 5'

 Full stacktrace here:

 https://gist.github.com/certik/a7f2434820f8dbf890b9


I think I figured it out:

sage: K.sqrt3 = QuadraticField(3)
sage: L.sqrt5 = K.extension(x^2-5)
sage: R.a1,a2,a3,a4,a5 = L[]
sage: time f = (a1+a2+a3+sqrt5*a4+sqrt3*a5)^18
CPU times: user 2.43 s, sys: 3.94 ms, total: 2.44 s
Wall time: 2.44 s

(I did smaller exponent so that it finishes.)

Ondrej

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

Re: [sage-devel] The fastest way to expand((a1+a2+a3+a4+sqrt(3)*a5)^25)

[Ondřej Čertík]

Hi Vincent,

On Mon, Jan 19, 2015 at 11:30 AM, Vincent Delecroix
20100.delecr...@gmail.com wrote:
 Hello Ondrej,

 For such questions of Sage usage, it is better to discuss on
 ask.sagemath.org or sage-support.

 You can also deal with all algebraic numbers at once with QQbar

 sage: sqrt3 = QQbar(sqrt(3))
 sage: sqrt5 = QQbar(sqrt(5))

 But then polynomials over QQbar are much slower.

Thanks, I'll ask there the next time. Since I started the thread here,
I'll keep it here so that everything is in one place.

So if you agree that I did things correctly, let's compare timings
(and lengths of expressions --- any idea how to get the number of
terms in a better way in Sage?):

sage: K.sqrt3 = QuadraticField(3)
sage: L.sqrt5 = K.extension(x^2-5)
sage: R.a1,a2,a3,a4,a5 = L[]
sage: time f = (a1+a2+a3+sqrt5*a4+sqrt3*a5)^18
CPU times: user 2.43 s, sys: 3.94 ms, total: 2.44 s
Wall time: 2.44 s
sage: len(str(f).split(+))
7315

Now compare this to CSymPy:


In [1]: from csympy import *

In [2]: var('a1 a2 a3 a4 a5 a6 a7')
Out[2]: (a1, a2, a3, a4, a5, a6, a7)

In [3]: %time f = ((a1+a2+a3+sqrt(5)*a4+sqrt(3)*a5)**18).expand()
CPU times: user 125 ms, sys: 7.73 ms, total: 133 ms
Wall time: 133 ms

In [4]: len(f.args)
Out[4]: 7315


You can also compare this to Sage symbolics (which should use the same
algorithm as CSymPy):


sage: var('a1 a2 a3 a4 a5 a6 a7')
(a1, a2, a3, a4, a5, a6, a7)
sage: %time f = ((a1+a2+a3+sqrt(5)*a4+sqrt(3)*a5)**18).expand()
CPU times: user 4.98 s, sys: 76.4 ms, total: 5.05 s
Wall time: 4.95 s
sage: len(f.operands())
7315


Which is also very slow.

I will try this in ginac directly, as that's what pynac is forked
from, maybe it's just the Python overhead. Also, I will carefully
check that we don't have a bug in csympy.

Ondrej

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

Re: [sage-devel] The fastest way to expand((a1+a2+a3+a4+sqrt(3)*a5)^25)

[Ondřej Čertík]

Hi Vincent,

On Sun, Jan 18, 2015 at 10:06 AM, Vincent Delecroix
20100.delecr...@gmail.com wrote:
 Hi,

 2015-01-18 18:03 UTC+01:00, Ondřej Čertík ondrej.cer...@gmail.com:
 Can you invent an example, that can't be converted to polynomials?
 Perhaps (a1+a2+a3+sqrt(5)*a4+sqrt(3)*a5)^25?

 Still doable. You need to involve log, exp, cos or similar
 transcendental functions.

Can you show me how to do that? I tried:

sage: K.sqrt3 = QuadraticField(3)
sage: K.sqrt5 = QuadraticField(5)
sage: R.a1,a2,a3,a4,a5 = K[]
sage: time f = (a1+a2+a3+sqrt5*a4+sqrt3*a5)^25

But I got:

TypeError: unsupported operand parent(s) for '*': 'Number Field in
sqrt3 with defining polynomial x^2 - 3' and 'Multivariate Polynomial
Ring in a1, a2
, a3, a4, a5 over Number Field in sqrt5 with defining polynomial x^2 - 5'

Full stacktrace here:

https://gist.github.com/certik/a7f2434820f8dbf890b9


Ondrej

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

Re: [sage-devel] The fastest way to expand((a1+a2+a3+a4+sqrt(3)*a5)^25)

[Ondřej Čertík]

Hi Vincent,

On Sun, Jan 18, 2015 at 1:18 AM, Vincent Delecroix
20100.delecr...@gmail.com wrote:
 Your example can be reduced to polynomials

 sage: K.sqrt3 = QuadraticField(3)
 sage: R.a1,a2,a3,a4,a5 = K[]
 sage: timeit((a1+a2+a3+a4+sqrt3*a5)^25)
 5 loops, best of 3: 81 ms per loop

That's cool, I wasn't aware you can do that. Thanks.

Can you invent an example, that can't be converted to polynomials?
Perhaps (a1+a2+a3+sqrt(5)*a4+sqrt(3)*a5)^25?

Ondrej

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

[sage-devel] The fastest way to expand((a1+a2+a3+a4+sqrt(3)*a5)^25)

[Ondřej Čertík]

Hi,

I was wondering what the fastest way is to do this benchmark in Sage:

┌┐
│ Sage Version 6.4, Release Date: 2014-11-14 │
│ Enhanced for SageMathCloud.│
└┘
sage: var('a1 a2 a3 a4 a5 a6 a7')
(a1, a2, a3, a4, a5, a6, a7)
sage: time f = expand((a1+a2+a3+a4+sqrt(3)*a5)^25)
CPU times: user 9.02 s, sys: 281 ms, total: 9.3 s
Wall time: 8.91 s
sage: len(f.operands())
23751


I took the Expanding a Symbolic Expression from
http://www.sagemath.org/tour-benchmarks.html, but made it shorter and
added sqrt(3) in there. I tried to use the polynomials way, i.e.
R.a1,a2,a3,a4,a5,a6,a7 = QQ[], but that didn't expand it at all. The
above is using SMC.

On my slow laptop, using our CSymPy library
(https://github.com/sympy/csympy), written in C++, I get:

In [4]: time f = ((a1+a2+a3+a4+sqrt(3)*a5)**25).expand()
CPU times: user 201 ms, sys: 23.9 ms, total: 225 ms
Wall time: 226 ms

In [5]: len(f.args)
Out[5]: 23751

Which is almost 40x faster.

Essentially I am wondering, if there is any software in Sage that can
do this faster. In other words, whether this is a good benchmark to
test general symbolic manipulation, that cannot be trivially converted
to a polynomial manipulation (for which there are great libraries out
there, that one should just call).

Ondrej

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

[sage-devel] Re: [sage-cloud] Sympy needs to be updated in SMC and Sage

[Ondřej Čertík]

On Thu, Jan 8, 2015 at 12:02 PM, William Stein wst...@gmail.com wrote:
 On Thu, Jan 8, 2015 at 10:16 AM, Андрей Ширшов sh.andr@gmail.com wrote:
 Hello!
 There is the following example on
 http://docs.sympy.org/latest/modules/sets.html:

 from sympy import FiniteSet, EmptySet
 A = EmptySet()
 A.powerset()
 {EmptySet()}
 A = FiniteSet(1, 2)
 A.powerset() == FiniteSet(FiniteSet(1), FiniteSet(2), FiniteSet(1, 2),
 EmptySet())
 True


 If you'll try this code in SMC you will get error, that 'EmptySet' object
 has no attribute 'powerset'. Now in SMC sympy version is 0.7.4,
 while this example seems to be for sympy version 0.7.6

 Please update sympy for Sage and SMC.

 Best regards, Andrei

 I tried pip installing the latest version and it breaks everything
 (see below).  This request should go to sage-devel, by the way.


 /projects/4a5f0542-5873-4eed-a85c-a18c706e8bcd/sage/libs/mpmath/ext_main.pyx
 in init sage.libs.mpmath.ext_main
 (build/cythonized/sage/libs/mpmath/ext_main.
 c:29967)()

 /usr/local/sage/sage-6.4/local/lib/python2.7/site-packages/mpmath/__init__.py
 in module()
   4
   5 from .ctx_fp import FPContext
  6 from .ctx_mp import MPContext
   7 from .ctx_iv import MPIntervalContext
   8

 /usr/local/sage/sage-6.4/local/lib/python2.7/site-packages/mpmath/ctx_mp.py
 in module()
  47 from sage.libs.mpmath.ext_main import Context as BaseMPContext
  48 # pickle hack
 --- 49 import sage.libs.mpmath.ext_main as _mpf_module
  50 else:
  51 from .ctx_mp_python import PythonMPContext as BaseMPContext

 AttributeError: 'module' object has no attribute 'ext_main'

Is that a bug in sympy?

Note that in the latest git master, we removed mpmath from sympy and
now simply depend on it. So since Sage ships mpmath, sympy would just
use it. Once a new sympy release is made, then one will have to
account for this change (the latest release as of today is 0.7.6 and
that still includes its own mpmath, which maybe clashes with the
mpmath in sage in the above stacktrace?).

Ondrej

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

Re: [sage-cloud] Re: [sage-devel] Re: SageMathCloud now open source

[Ondřej Čertík]

On Fri, Dec 12, 2014 at 1:37 PM, William Stein wst...@gmail.com wrote:
 On Fri, Dec 12, 2014 at 12:19 PM, mmarco mma...@unizar.es wrote:
 My impression is that open sourcing SMC wouldn't have a big impact on the
 business oportunity.

 The main niche of clients would be universities that want to move their math
 courses to the cloud. For them, having the source code mean that it would be
 possible to set up their own server, but they still would need to buy
 hardware, set it up and maintain it, and hire personel with the expertise to
 administer it. That is a big investment just to start, i guess that you
 (having already the expertise and some hardware to start with) could offer
 prices that beat that option, specially in the short term.

 It's not so simple.  When SMC was closed source, UW would do the work
 involving taking payments, legal stuff, and allow me to use the
 hardware/people/resource that UW has.  Since SMC is now open source,
 they won't allow any of that in a business context.   (This was part
 of the reason SMC was closed source.)   This means that
 commercialization of SMC can't happen until several relatively
 expensive things along the lines of they still would need to buy
 hardware, set it up and maintain it, and hire personnel with the
 expertise to administer it happen, which must get paid for by private
 money.  The expenses are way more than an order of magnitude more than
 I personally have available.   Exactly what prevents the competitor
 you are imagining is also an obstruction to commercialization of SMC
 now.  It's even a little scarier right now, because much of SMC is
 running on Google Compute Engine, and those free credits are rapidly
 running out (commercialization was going to take care of that).  There
 is enough hardware at UW to keep things running, though I also pay
 over $7K/year just for physical rack space for hosting that hardware
 at UW.

 But don't worry --  there is a potential private investor, and I think
 things will work out very well.

 The possible risk is that somebody could start a company to offer the same
 service, but again you have the starting advantage.

 About this... what about AGPL? Would that be possible?

 I can't make any license changes in the shortterm, though eventually
 it may be possible.   AGPL would mean that if somebody else makes an
 SMC competitor they would have to share any modifications they make to
 the backend code.  That would be reassuring.

There is at least one company (https://about.gitlab.com/) that run web
service completely using open source (MIT licensed) code:

https://gitlab.com/gitlab-org/gitlab-ce/tree/master

I don't know how much they earn though, but this suggest they have at
least 6 full time employees:

http://thenextweb.com/insider/2014/06/04/github-rival-gitlab-building-business-just-0-1-paying-customers/

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

Hi Bill,

I thought about this a lot (essentially I studied complex analysis
from several books as well as consulted with many colleagues) and I
figured out some answers to my questions.

In the approach (A), you have:

log(a*b) = log(a) + log(b)

What that means is that log() is multivalued, so you can add 2*pi*i*n
for all n. The way to do arithmetic and compare multivalued
functions is simply to make sure that the infinite (sometimes it could
be finite) set of values on the left is equivalent to the infinite set
of values on the right. In other words, if you pick a value on the
left, for the sake of an argument let's say a=b=-1 and we pick n = 5,
so we get log(a*b) = log(1) = 0 + 2*pi*i*5 = 10*pi*i, then if you can
find combinations of values on the right hand side to make the result
equal to 10*pi*i, and you can do this for all integer n, and if you
can do the opposite, i.e. that you pick any combination of values on
the right hand side and are able to find a value on the left hand side
that is equal to it, then you prove the equality. I.e. you prove that
the infinite set of multivalues on the left hand side and right hand
side are equal.

Once we have an understanding how log(z) works, we simply can derive
all kinds of formulas in the approach (A). The way it works is that
you put in the 2*pi*n factors, i.e. you explicitly enumerate all
possibilities, then you derive some formulas, and at the end you
absorb the 2*pi*n factors into the multivalued functions, i.e. you can
always absorb 2*pi*i*n into log(). But sometimes it might not be
possible to completely absorb all these factors.

Now let's apply this to the problems below:

On Wed, Nov 26, 2014 at 10:27 PM, Bill Page bill.p...@newsynthesis.org wrote:
 On 26 November 2014 at 12:58, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Wed, Nov 26, 2014 at 10:17 AM, Bill Page bill.p...@newsynthesis.org 
 wrote:

 Does it help if a say the operations are defined symbolically?

 All I want is if you can give me an algorithm of your approach
 in sufficient detail, so that it can be implemented by me on a
 computer.  And by your approach, I mean an approach, where
 conjugate(log(x)) = log(conjugate(x)) for all x.


 I am sorry, we seem to be having some trouble communicating. Is that
 something infecting this email list? :)

 Making  conjugate(log(x)) = log(conjugate(x)) for all x is trivial
 so long as it is treated symbolically: the 'conjugate' operation is
 just defined to rewrite itself (auto-simplify) when applied to any
 operand of the form log(_), so 'conjugate(log(_))' is evaluated as
 'log(conjugate(_))', where _ stands for any element of the domain
 Expression.  This is what I meant when I said it was considered true
 by definition, i.e. by definition of the symbolic 'conjugate'
 operation.  Exactly the same sort of thing happens when the
 'conjugate' operation acts on 'conjugate'  so that
 'conjugate(conjugate(x))' is simply rewritten as 'x'.

Sure, on this level you can implement it. I was thinking on a deeper
level, i.e. imagining putting a number x=-1 in and see how could this be true:

conjugate(log(-1)) = log(conjugate(-1))

The answer that I was looking for is this:

LHS: conjugate(log(-1)) = conjugate(i*pi + 2*pi*i*n) = -i*pi-2*pi*i*n
RHS: log(conjugate(-1)) = log(-1) = i*pi + 2*pi*i*m

If we pick n=-m-1, we always get LHS=RHS, so the two infinite set of
multivalues are equivalent, and the relation conjugate(log(-1)) =
log(conjugate(-1)) holds.
When you evaluate log(-1), you cannot just give i*pi, you need to give
all the multivalues. But otherwise it works.


 I have provided all the details of the algorithm (B). In approach (B),
 it is not true that
 conjugate(log(x)) = log(conjugate(x)) for all x.

 This equation (when conjugate(log(x)) = log(conjugate(x)) holds)
 started this whole discussion.

 That

   log(a*b) = log(a) + log(b)

 is considerably less trivial that the case of 'conjugate'.  From my
 point of view that is what actually started this branch of the
 fabric of this discussion.  That is where 'normalize' comes in.

I think the above answers both, it all works and is consistent in the
approach (A). You just need to remember that if a function is
multivalued, e.g. log(z), then you always need to enumerate all the
values and prove that the LHS is equivalent to RHS.

There is a theorem, that says that actually, if you give me a complex
function values on just one branch, I can reconstruct the function in
all branches. So it is probably the case that you only need to find
one set of n, m and k to satisfy the equation and it will then
hold for the other values as well. But for clarity, I always prove it
for all values.


 So I was trying to understand your approach how to make this hold
 for all x, and I suggested various ways how maybe it could be
 implemented, and to most of it you said that's not how FriCAS does
 it. At this point I don't have any more ideas how it could be done,
 so I don't know how to implement your approach

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Fri, Dec 5, 2014 at 1:20 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 Hi Bill,

 I thought about this a lot (essentially I studied complex analysis
 from several books as well as consulted with many colleagues) and I
 figured out some answers to my questions.

 In the approach (A), you have:

 log(a*b) = log(a) + log(b)

 What that means is that log() is multivalued, so you can add 2*pi*i*n
 for all n. The way to do arithmetic and compare multivalued
 functions is simply to make sure that the infinite (sometimes it could
 be finite) set of values on the left is equivalent to the infinite set
 of values on the right. In other words, if you pick a value on the
 left, for the sake of an argument let's say a=b=-1 and we pick n = 5,
 so we get log(a*b) = log(1) = 0 + 2*pi*i*5 = 10*pi*i, then if you can
 find combinations of values on the right hand side to make the result
 equal to 10*pi*i, and you can do this for all integer n, and if you
 can do the opposite, i.e. that you pick any combination of values on
 the right hand side and are able to find a value on the left hand side
 that is equal to it, then you prove the equality. I.e. you prove that
 the infinite set of multivalues on the left hand side and right hand
 side are equal.

 Once we have an understanding how log(z) works, we simply can derive
 all kinds of formulas in the approach (A). The way it works is that
 you put in the 2*pi*n factors, i.e. you explicitly enumerate all
 possibilities, then you derive some formulas, and at the end you
 absorb the 2*pi*n factors into the multivalued functions, i.e. you can
 always absorb 2*pi*i*n into log(). But sometimes it might not be
 possible to completely absorb all these factors.

 Now let's apply this to the problems below:

 On Wed, Nov 26, 2014 at 10:27 PM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 On 26 November 2014 at 12:58, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Wed, Nov 26, 2014 at 10:17 AM, Bill Page bill.p...@newsynthesis.org 
 wrote:

 Does it help if a say the operations are defined symbolically?

 All I want is if you can give me an algorithm of your approach
 in sufficient detail, so that it can be implemented by me on a
 computer.  And by your approach, I mean an approach, where
 conjugate(log(x)) = log(conjugate(x)) for all x.


 I am sorry, we seem to be having some trouble communicating. Is that
 something infecting this email list? :)

 Making  conjugate(log(x)) = log(conjugate(x)) for all x is trivial
 so long as it is treated symbolically: the 'conjugate' operation is
 just defined to rewrite itself (auto-simplify) when applied to any
 operand of the form log(_), so 'conjugate(log(_))' is evaluated as
 'log(conjugate(_))', where _ stands for any element of the domain
 Expression.  This is what I meant when I said it was considered true
 by definition, i.e. by definition of the symbolic 'conjugate'
 operation.  Exactly the same sort of thing happens when the
 'conjugate' operation acts on 'conjugate'  so that
 'conjugate(conjugate(x))' is simply rewritten as 'x'.

 Sure, on this level you can implement it. I was thinking on a deeper
 level, i.e. imagining putting a number x=-1 in and see how could this be true:

 conjugate(log(-1)) = log(conjugate(-1))

 The answer that I was looking for is this:

 LHS: conjugate(log(-1)) = conjugate(i*pi + 2*pi*i*n) = -i*pi-2*pi*i*n
 RHS: log(conjugate(-1)) = log(-1) = i*pi + 2*pi*i*m

 If we pick n=-m-1, we always get LHS=RHS, so the two infinite set of
 multivalues are equivalent, and the relation conjugate(log(-1)) =
 log(conjugate(-1)) holds.
 When you evaluate log(-1), you cannot just give i*pi, you need to give
 all the multivalues. But otherwise it works.


 I have provided all the details of the algorithm (B). In approach (B),
 it is not true that
 conjugate(log(x)) = log(conjugate(x)) for all x.

 This equation (when conjugate(log(x)) = log(conjugate(x)) holds)
 started this whole discussion.

 That

   log(a*b) = log(a) + log(b)

 is considerably less trivial that the case of 'conjugate'.  From my
 point of view that is what actually started this branch of the
 fabric of this discussion.  That is where 'normalize' comes in.

 I think the above answers both, it all works and is consistent in the
 approach (A). You just need to remember that if a function is
 multivalued, e.g. log(z), then you always need to enumerate all the
 values and prove that the LHS is equivalent to RHS.

 There is a theorem, that says that actually, if you give me a complex
 function values on just one branch, I can reconstruct the function in
 all branches. So it is probably the case that you only need to find
 one set of n, m and k to satisfy the equation and it will then
 hold for the other values as well. But for clarity, I always prove it
 for all values.


 So I was trying to understand your approach how to make this hold
 for all x, and I suggested various ways how maybe it could be
 implemented, and to most of it you said that's not how

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Wed, Nov 26, 2014 at 10:17 AM, Bill Page bill.p...@newsynthesis.org wrote:
 On 25 November 2014 at 14:51, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Nov 25, 2014 at 11:30 AM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 ...
 Try it this way:

   a*b = exp(?1)
   a = exp(?2)
   b = exp(?3)

 I think 'normalize' is saying that there is a solution that makes

   ?1 - ?2 - ?3  = 0.

 Ok, but why wouldn't normalize return 2*pi*i instead? Or 4*pi*i?

 These are equivalent in the sense of having the same number of
 algebraically independent transcendental kernels, i.e. none.

 I don't understand that. Is the result of normalize() multivalued?

 No.

 Or how else could 0 be equivalent to 2*pi*i or 4*pi*i?

 It is not equality it is an equivalence relation i.e. modulo
 constants.  To dig deeper on this I think would need to consult the
 source code and someone who is much more of an expert in this subject:
 Waldek Hebisch.

 In other words, how exactly are the operations on the multivalued
 sets log(x) defined?

 FriCAS does not perform operations on multivalued sets to determine
 the above.

 Ok. Though my question stands, how are the operations defined in your
 approach?


 Does it help if a say the operations are defined symbolically?

All I want is if you can give me an algorithm of your approach in
sufficient detail, so that it can be implemented by me on a computer.
And by your approach, I mean an approach, where conjugate(log(x)) =
log(conjugate(x)) for all x.

I have provided all the details of the algorithm (B). In approach (B),
it is not true that
conjugate(log(x)) = log(conjugate(x)) for all x.

This equation (when conjugate(log(x)) = log(conjugate(x)) holds)
started this whole discussion.
So I was trying to understand your approach how to make this hold for
all x, and I suggested various ways how maybe it could be
implemented, and to most of it you said that's not how FriCAS does
it. At this point I don't have any more ideas how it could be done,
so I don't know how to implement your approach. Which is sad -- even
though I am not advocating for your approach, I wanted to really
understand it, so that I can make my own opinion on the pros and cons.

 Maybe we need to define exactly what operations we are talking about.

Sure. Let's just stick to one example, let me just copy  paste it
from my previous email:

 from cmath import log
 a = -1
 b = -1
 log(a*b)
0j
 log(a)+log(b)
6.283185307179586j

 def arg(x): return log(x).imag
...
 from math import floor, pi
 I = 1j
 log(a)+log(b)+2*pi*I*floor((
pi-arg(a)-arg(b))/(2*pi))
0j


As you confirmed, even if you evaluate this in FriCAS, log(a*b) is not
equal to log(a) + log(b), when a=b=-1.
However, you claim that symbolically it is true that log(a*b) =
log(a) - log(b) for all a and b and you provided a FriCAS function
normalize that does it, but you said that for deeper understanding
you would need to consult Waldek Hebisch. Can you explain the
discrepancy/inconsistency?

How exactly are the operations in log(a*b) = log(a) - log(b) defined,
so that this equation holds, even though when you put in a=b=-1, you
get a different number on the LHS and RHS, as confirmed by FriCAS?

Once we resolve this, we can get back to conjugate(log(x)) =
log(conjugate(x)) which also clearly doesn't hold for x=-1 for the
same reason, and so you must be able to somehow extend the operations
so that this equation holds even for x=-1 somehow in your approach.


 ...
 Essentially the [derivative] formula with theta is equivalent to just
 returning a tuple of the two Wirtinger derivatives. So what holds for
 one approach holds for the other one.


 Yes, so we agree that in general more than one derivative operator is 
 necessary.

 ...
 My current best solution is to define a function `diff(x, theta=0)`,
 where the theta argument is 0 by default, but you can pass any
 angle into it, or a symbol theta if you want. That way you won't get
 the theta factors by default, but if in doubt, you can always get them.


 It seems that you prefer an infinite number of derivative operators
 while I still think it is best to define only two.

The two approaches are equivalent, as I just pointed out. Even if you
define only the two Wirtinger derivatives, nothing stops you from
adding the theta factor and you also obtain the infinite number of
derivatives.


 Let me know if you have a better proposal.


 After continued thinking about this and my current experiments in
 FriCAS I am still of the opinion that the best option is to implement
 just the Wirtinger derivative (only one since the other can be
 obtained by 'conjugate'). This has the affect of making the derivative
 of non-analytic functions subtly different than what you call the
 conventional real derivative (e.g. factor of 1/2 in derivative of
 'abs').  I have decided that I would prefer to explain this difference
 to a less experienced user, rather than to get into a discussion of
 theta and directional derivatives.

Cool

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 25, 2014 at 11:30 AM, Bill Page bill.p...@newsynthesis.org wrote:
 On 25 November 2014 at 01:11, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Mon, Nov 24, 2014 at 10:23 PM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 ...
 I am not very interested in real numbers.  I am interested in the
 algebra.  Would you say that

   sqrt(x^2).diff(x) = sqrt(x^2)/x

 is OK?

 I think so, using the following calculation:

 sqrt(x^2).diff(x) = exp(1/2*log(x^2)).diff(x) = exp(1/2*log(x^2)) *
 1/2 * 1/x^2 * 2*x = sqrt(x^2)/x

 The function exp(1/2*log(x^2)) that we differentiate is analytic, so I
 don't see any issue here.


 I did not ask whether it was technically correct or not.  What I meant
 was is this expression what you would expect given the rest of the
 machinery of differentiation in any given computer algebra system?

Ah ok. I would actually expect to get x/sqrt(x^2), which is equivalent.



 But I don't want to be forced to make a choice of branch until
 I actually need to evaluate an expression numerically.

 I understand that's what you want. I am just trying to understand how
 exactly this works.


 OK.

 ...
 I think what you are trying to say is

  (A) log(exp(z)) = { z + 2*pi*i*n | for all n in Integer}

 Exactly, that's what I meant.
 ...

 Although it may seem simple in this case, in general implementing
 sets with comprehension like this requires logic and takes us
 outside of algebra as such into the realm of theorem proving.

 Sure. But that's what you want, correct?


 No, not at all.  I want this to be algebraic, not some theorem of
 predicate calculus.  That is what I meant by taking

   x + conjugate(x)

 as the definition of a real valued variable.

Ok.


 ...


 This is precisely the part that I don't understand with the approach
 (A). log(a*b), log(a) and log(b) are all multivalued, so you would
 naively think, that log(a*b)-log(a)-log(b) = 0 + 2*pi*i*n, for all
 n. But I think this is not the case, I think the n in log(a*b) is
 coupled to the implicit n in log(a) and log(b) in such a way, that
 the result is exactly 0. Can you clarify exactly how this works?

 Try it this way:

   a*b = exp(?1)
   a = exp(?2)
   b = exp(?3)

 I think 'normalize' is saying that there is a solution that makes

   ?1 - ?2 - ?3  = 0.

 Ok, but why wouldn't normalize return 2*pi*i instead? Or 4*pi*i?

 These are equivalent in the sense of having the same number of
 algebraically independent transcendental kernels, i.e. none.

I don't understand that. Is the result of normalize() multivalued?
Or how else could 0 be equivalent to 2*pi*i or 4*pi*i?



 In other words, how exactly are the operations on the multivalued
 sets log(x) defined?

 FriCAS does not perform operations on multivalued sets to determine the above.

Ok. Though my question stands, how are the operations defined in your approach?



 I meant that I did not understand what you are proposing for how to
 represent the value of 'log(z)' symbolically, i.e. when the value of z
 is unknown.

 Ah ok. I would represent it by the approach (B). But then, as we
 talked about, it's not true that conjugate(log(z)) = log(conjugate(z)).
 Since you want this property to hold, then the approach (B) does
 not work for you, obviously. So I am trying to understand how
 exactly are all the operations defined in your approach. You said
 your approach is not (A) exactly. So I am just trying to understand.


 OK.


 This discussion is about how a CAS should handle (complex)
 differentiation. Since it started here, I would finish it here, so
 that the whole thread is in one mailinglist for future reference.


 OK.  It would be nice to know if other sage-devel subscribers actually
 remain interested...

 Let's return to differentiation for a moment.  Using your definitions
 what would you say is the correct result for

   log(exp(z-conjugate(z))).diff(z)

 My patched version of FriCAS based your definition in this thread
 currently returns 0. Do you get the same result?

No, the derivative is most definitely not zero:

log(exp(z-conjugate(z))).diff(z) =
exp(z-conjugate(z))/exp(z-conjugate(z)) * [1 - 1*exp(-2*i*theta)] = 1
- exp(-2*i*theta)

In other words, the two Wirtinger derivatives are 1 and -1. You can
easily check numerically that this formula is correct for all complex
x and angles theta, I've done it here:

https://github.com/certik/theoretical-physics/blob/f9406a02ef8e04b2daa669f444148186b6b892e8/src/math/code/test_complex_diff.py#L118

and it works.


 Since the derivative is 0 would we want to say therefore that

   log(exp(z-conjugate(z)))

 is a constant?

If you got 0, then I think you can say that the function is constant.
We didn't get 0, so the function is not constant.

 If not, isn't this an argument for needing another
 derivative?

In some of your previous emails you wrote that this theta factor
still looks ugly to you. Maybe it's ugly, but it's correct, as you
fell into this trap yourself: if you omit theta and implicitly assume
theta

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Mon, Nov 24, 2014 at 1:57 PM, Bill Page bill.p...@newsynthesis.org wrote:
 On 22 November 2014 at 12:34, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Sat, Nov 22, 2014 at 7:23 AM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 ...
 FriCAS currently does not implement a symbolic 'conjugate' operator.
 The issue concerns whether adding 'conjugate' is a good idea and only
 secondly how to differentiate it.

 Ah, I had no idea that FriCAS does not implement conjugate(x).
 How do you handle complex numbers then?

 Sorry, I gave you the wrong impression. I specifically referred to the
 lack of symbolic 'conjugate operator.  By that I meant that the
 'Expression' functor does not export a 'conjugate' operator.  My patch
 adds such an operator to Expression.  But FriCAS has many domains of
 computation besides those constructed by 'Expression' and some of them
 do include 'conjugate'. For example the 'Complex' functor includes
 'conjugate' so we can write:

 (1) - x:Complex Expression Integer := a + %i*b

(1)  a + b %i
Type: Complex(Expression(Integer))
 (2) - conjugate(x)

(2)  a - b %i
Type: Complex(Expression(Integer))

 This effectively and implicitly treats symbols as real valued.

 (3) - D(x,a)

(3)  1
Type: Complex(Expression(Integer))
 (4) - D(x,b)

(4)  %i
Type: Complex(Expression(Integer))
 (5) - y:=log(x)

  22
 log(b  + a )b
(5)   + 2atan(--)%i
   2   +---+
   | 22
  \|b  + a   + a
Type: Complex(Expression(Integer))
 (6) - conjugate(y)

  22
 log(b  + a )b
(6)   - 2atan(--)%i
   2   +---+
   | 22
  \|b  + a   + a
Type: Complex(Expression(Integer))

 But not this:

 (7) - D(y,x)
 ...
Cannot find a definition or applicable library operation named D
   with argument type(s)
 Complex(Expression(Integer))
 Complex(Expression(Integer))

 So there is no complex derivative as such.

 We can also define things this way:

 (8) - z:Expression Complex Integer := a + %i*b

(8)  %i b + a
Type: Expression(Complex(Integer))
 (9) - D(z,a)

(9)  1
Type: Expression(Complex(Integer))
 (10) - D(z,b)

(10)  %i
Type: Expression(Complex(Integer))
 (11) - w:=log(z)

(11)  log(%i b + a)
Type: Expression(Complex(Integer))

 But now we get:

 (12) - conjugate(z)
  ...
Cannot find a definition or applicable library operation named
   conjugate with argument type(s)
 Expression(Complex(Integer))

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

 (13) - D(w,z)
 ...
Cannot find a definition or applicable library operation named D
   with argument type(s)
 Expression(Complex(Integer))
 Expression(Complex(Integer))

 The FriCAS 'Expression' functor extends multivariate rational
 functions over a specified domain with a large number of
 transcendental kernels (symbolic functions) as well as differentiation
 and integration operators.  No explicit assumption is made about the
 domain of the variables.  My proposed patch to FriCAS adds 'conjugate'
 as another kernel function and provides a 'conjugate' as an operator.

Ok, thanks for the clarification.


 In SymPy and Sage, conjugate(x) is in it, so then adding a derivative
 of abs(x) does not make things worse.


 In FriCAS 'abs' is already a kernel function and it implemented the
 derivative of 'abs' even before my proposed patch but I think the
 current definition is wrong:

 (14) - D(abs(x),x)

  abs(x)
(14)  --
 x
 Type: Expression(Integer)

I think that's correct for real numbers, i.e. x/abs(x) = abs(x) / x.




 In FriCAS with my patch functions defined by

   f := operator 'f

 are currently assume to be holomorphic and log is holomorphic by definition 
 so

 conjugate(log(x)) = log(conjugate(x))

 Perhaps you are considering the wrong branch.
 ...
 Complex 'log' is a multi-valued like 'sqrt' so you need to consider
 more than one branch.

 Well, you are right that in theory you define log(z) as
 log(z)=log|z|+i*arg(z), and you define arg(z) as multivalued,
 i.e. you can add 2*pi*n to it, then you can

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Mon, Nov 24, 2014 at 10:23 PM, Bill Page bill.p...@newsynthesis.org wrote:
 On 24 November 2014 at 17:43, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Mon, Nov 24, 2014 at 1:57 PM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 ...

 In FriCAS 'abs' is already a kernel function and it implemented the
 derivative of 'abs' even before my proposed patch but I think the
 current definition is wrong:

 (14) - D(abs(x),x)

  abs(x)
(14)  --
 x
 Type: 
 Expression(Integer)

 I think that's correct for real numbers, i.e. x/abs(x) = abs(x) / x.


 I am not very interested in real numbers.  I am interested in the
 algebra.  Would you say that

   sqrt(x^2).diff(x) = sqrt(x^2)/x

 is OK?

I think so, using the following calculation:

sqrt(x^2).diff(x) = exp(1/2*log(x^2)).diff(x) = exp(1/2*log(x^2)) *
1/2 * 1/x^2 * 2*x = sqrt(x^2)/x

The function exp(1/2*log(x^2)) that we differentiate is analytic, so I
don't see any issue here.


 Rather, I think the correct definition of 'log(z)' is the solution of

   z = exp(?)

 So we can write z=exp(log(z)) by definition.

 Indeed, exp(log(z))=z always,

 Not just true always. It is the definition of 'log(z)'.


 In both (A) and (B),
 it is true that z = exp(log(z)). However, these are different:

 (A) log(exp(z)) = z + 2*pi*i*n
 (B) log(exp(z)) = z + 2*pi*i*floor((pi-Im z) / 2*pi)

 In (B), you get a single value, but in (A) you get multiple values,
 one for each n.


 Better to say (A) is true \forall n \in Integer

Yes.


 I am very familiar with the approach (B) and I think I understand
 exactly what follows from what and how to derive all the formulas.

 (B) is about choosing a particular branch of 'log' - the principal
 value.

Correct.

 But I don't want to be forced to make a choice of branch until
 I actually need to evaluate an expression numerically.

I understand that's what you want. I am just trying to understand how
exactly this works.


 But I am not 100% sure with (A), I was hoping you can help, since
 that's the approach that you want to use in FriCAS.

 (A) is not quite the approach I want to use for 'Expression' in
 FriCAS.  I want 'log(exp(z))' to be the solution of

   exp(z) = exp(?)

 The best way to say that algebraically (symbolically) is just
 'log(exp(z))', i.e. without evaluation.  This is what FriCAS already
 does in the case of

 (1) - z:Expression Complex Integer
Type: Void
 (2) - exp(log(z))

(2)  z
Type: Expression(Complex(Integer))
 (3) - log(exp(z))

   z
(3)  log(%e )
Type: Expression(Complex(Integer))

 but unfortunately not in the case of 'Expression Integer'.

 (4) - z:Expression Integer
Type: Void
 (5) - log(exp(z))

(5)  z
 Type: Expression(Integer)

 I think that what it currently does for 'Expression Integer' should be
 considered a bug.

 I think what I wrote is correct for (A), but please correct me if I am wrong.

 This is exactly analogous
 to the treatment of 'sqrt(z)' as the solution to

   z = ? * ?


 We have

   sqrt(z)^2 = z

 but

   sqrt(z^2) = sqrt(z^2)

 However, this definition quickly becomes impractical, because you
 need to be able to numerically evaluate symbolic expressions, and
 you would need to carry the symbolic term 2*pi*i*n around.

 We do not need an extra term.  We only need axioms for the correct
 behavior of the expression 'log(z)'. But 'log(z)' does not denote a
 function in the sense of a many-to-one mapping.  The inverse of a
 function is only a function (possibly partial) if the function is
 injective (one-to-one).

 Sure, that's why you have n in the formula for log(z) in (A), and
 the function is multivalued over all n.


 No.  As you have written it, it is a function of two variables with
 one value for each z and n.

   f(z,n) = z + 2*pi*i*n

 I think what you are trying to say is

  (A) log(exp(z)) = { z + 2*pi*i*n | for all n in Integer}

Exactly, that's what I meant.


 and

   sqrt(z) = {  x | x^2 =z }

Sure, though I would just define

sqrt(z) = exp(1/2 * log(z))


 Although it may seem simple in this case, in general implementing sets
 with comprehension like this requires logic and takes us outside of
 algebra as such into the realm of theorem proving.

Sure. But that's what you want, correct?



 The Riemann surface is an important tool in complex analysis but I
 have yet to see it used explicitly in any computer algebra system as
 a representation of complex functions.

 I thought the Riemann surface gives you a way to couple n in
 log(a*b), log(a) and log(b) in such a way that you get exactly
 log(a*b)-log(a)-log(b)=0. I.e. that the Riemann surface is (A).
 I agree that I haven't seen it used in CAS. But I

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Sat, Nov 22, 2014 at 7:23 AM, Bill Page bill.p...@newsynthesis.org wrote:
 On 21 November 2014 at 20:18, Ondřej Čertík ondrej.cer...@gmail.com wrote:

 I am still confused about one thing: is this issue is already
 present in FriCAS before your changes? Because you can
 already use conjugate, sin, +, *, ..., even without defining the
 derivative for abs(x). I fail to see how defining the abs(x).diff(x)
 in the way you did it  can introduce issues that weren't present
 in the first place.


 FriCAS currently does not implement a symbolic 'conjugate' operator.
 The issue concerns whether adding 'conjugate' is a good idea and only
 secondly how to differentiate it.

Ah, I had no idea that FriCAS does not implement conjugate(x). How do
you handle complex numbers then?
In SymPy and Sage, conjugate(x) is in it, so then adding a derivative
of abs(x) does not make things worse.


 -

 I have finished the writeup, it starts here (you might want to refresh
 your browser to see the latest changes):

 http://www.theoretical-physics.net/dev/math/complex.html#complex-conjugate

 and it was implemented with these two PRs:

 https://github.com/certik/theoretical-physics/pull/39
 https://github.com/certik/theoretical-physics/pull/40


 Thanks.

 I must say one thing that I like about the theta is that it tells
 you immediately if the function is analytic or not (if theta is
 present it is not, if it is not present, then the expression does not
 depend on theta, and thus is analytic). For example, for log(z),
 the theta cancels, and so the result 1/z is analytic.


 Still looks ugly to me.

 I found a bug in these results from FriCAS:

 (4) - D(abs(f(x)),x)

  , _  _  ,
 f(x)f (x) + f(x)f (x)

(4)  -
   2abs(f(x))
 Type:
 Expression(Integer)
 (5) - D(abs(log(x)),x)

 __
 xlog(x) + x log(x)
(5)  --
 _
   2xxabs(log(x))
 Type:
 Expression(Integer)

 The bar must be over the whole f(x) as well as log(x), because
 conjugate(log(x)) is only equal log(conjugate(x)) if x is not
 negative real number.

 In FriCAS with my patch functions defined by

   f := operator 'f

 are currently assume to be holomorphic and log is holomorphic by definition so

 conjugate(log(x)) = log(conjugate(x))

 Perhaps you are considering the wrong branch.

 See the example here:
 http://www.theoretical-physics.net/dev/math/complex.html#id1 where I
 have it explicitly worked out. You can also check that easily in
 Python:

 In [1]: from cmath import log

 In [2]: x = -1+1j

 In [3]: log(x).conjugate()
 Out[3]: (0.34657359027997264-2.356194490192345j)

 In [4]: log(x.conjugate())
 Out[4]: (0.34657359027997264-2.356194490192345j)

 In [5]: x = -1

 In [6]: log(x).conjugate()
 Out[6]: -3.141592653589793j

 In [7]: log(x.conjugate())
 Out[7]: 3.141592653589793j

 In [8]: log(x.conjugate()) - 2*pi*1j
 Out[8]: -3.141592653589793j


 Where [3] and [4] are equal, but [6] and [7] are not (you need to
 subtract 2*pi*i from [7], as in [8], in order to recover [6],
 consistent with the formula in the writeup).


 Complex 'log' is a multi-valued like 'sqrt' so you need to consider
 more than one branch.

Well, you are right that in theory you define log(z) as
log(z)=log|z|+i*arg(z), and you define arg(z) as multivalued, i.e. you
can add 2*pi*n to it, then you can add 2*pi*i*n to log(z). Since [6]
and [7] differs by 2*pi*i, they are indeed the same number.
However, this definition quickly becomes impractical, because you need
to be able to numerically evaluate symbolic expressions, and you would
need to carry the symbolic term 2*pi*i*n around. This multivalued
approach has always been very confusing to me. But it is a valid
approach (i.e. see http://en.wikipedia.org/wiki/Riemann_surface), so
let's call this is an approach (A).

The other approach, let's call it approach (B), is that languages like
Fortran, C, Python, and CAS like Mathematica, SymPy, Sage all pick a
branch cut, and all of them (as far as I know) pick it along the
negative real axis. For this example I think it doesn't matter where
you choose the branch cut, as the conjugate of log(-1) simply flips
the sign of it, so it won't be equal to log(-1) anymore. In this
approach you need to carry the corrections for branch cuts.

Some examples of identities valid in each approach:

(A) conjugate(log(z)) = log(conjugate(z))
(B) conjugate(log(z)) = log(conjugate(z)) -2*pi*i*floor((arg(z)+pi)/(2*pi))

or

(A) log(a*b) = log(a) + log(b)
(B) log(a*b) = log(a) + log(b) + 2*pi*i*floor((pi-arg(a)-arg(b))/(2*pi))

And so on. I have written a Python script to check many of these
identities in (B), available here:

http://www.theoretical-physics.net/dev/math/complex.html#testing-identities-using-computer-code

and it works like a charm, i.e. those identities are valid for any
complex numbers

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

I've written up all the equations from this thread together with
detailed step by step derivation:

http://www.theoretical-physics.net/dev/math/complex.html

e.g. the derivatives are here:

http://www.theoretical-physics.net/dev/math/complex.html#complex-derivatives

Most of the examples from this thread are there, but few are still
missing, I'll add them tomorrow.

Bill, please let me know if you have any feedback/comments to it.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Fri, Nov 21, 2014 at 9:37 AM, Bill Page bill.p...@newsynthesis.org wrote:
 On 20 November 2014 22:08, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Thu, Nov 20, 2014 at 7:53 PM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 ...
 This problem can be reduced to finding an algorithm to determine
 if f(x) is everywhere non-negative. Richardson proves that no such
 algorithm exists.

 I see. But what does this have to do with the derivative of |f(x)| that
 we are trying to figure out?


 This has to do with 'conjugate' in general, not just derivatives of
 expressions containing 'conjugate'.  The problem is that 'conjugate'
 is transcendental but it cannot be written in terms of log and exp.

 As you pointed out, the challenge is that if you include conjugate(x),
 then you might be out of luck. But aren't you out of luck already if
 you have abs(x) in the expression in the first place? I.e. taking a
 derivative is not going to change anything, you are still out of luck.


 You are right about the derivative.  But my limited understanding is
 that the strategy is not to avoid 'abs(x)' but rather to avoid 'sin'.
 We cannot similarly avoid 'conjugate' and in general the effect of
 including 'conjugate' is apparently unknown.  But one effect of
 including 'conjugate' is that we can have expressions like

   x+conjugate(x)

 which is necessarily real-valued, rather like 'abs(x)' for x
 real-valued is non-negative.  So it would be nice to know, for example
 for any expression composed of x, integers, +, *, sin, and conjugate,
 if there is an algorithm to determine if this expression is everywhere
 real-valued.

I am still confused about one thing: is this issue is already present
in FriCAS before your changes?
Because you can already use conjugate, sin, +, *, ..., even without defining
the derivative for abs(x). I fail to see how defining the
abs(x).diff(x) in the way you did it
can introduce issues that weren't present in the first place.

-

I have finished the writeup, it starts here (you might want to refresh
your browser
to see the latest changes):

http://www.theoretical-physics.net/dev/math/complex.html#complex-conjugate

and it was implemented with these two PRs:

https://github.com/certik/theoretical-physics/pull/39
https://github.com/certik/theoretical-physics/pull/40

I must say one thing that I like about the theta is that it tells
you immediately if the function is analytic or not (if theta is
present it is not, if it is not present, then the expression does not
depend on theta, and thus is analytic). For example, for log(z), the
theta cancels, and so the result 1/z is analytic.

I found a bug in these results from FriCAS:

 (4) - D(abs(f(x)),x)

  , _  _  ,
 f(x)f (x) + f(x)f (x)

(4)  -
   2abs(f(x))
 Type:
 Expression(Integer)
 (5) - D(abs(log(x)),x)

 __
 xlog(x) + x log(x)
(5)  --
 _
   2xxabs(log(x))
 Type:
 Expression(Integer)

The bar must be over the whole f(x) as well as log(x), because
conjugate(log(x)) is only equal log(conjugate(x)) if x is not negative
real number. See the example here:
http://www.theoretical-physics.net/dev/math/complex.html#id1 where I
have it explicitly worked out. You can also check that easily in
Python:

In [1]: from cmath import log

In [2]: x = -1+1j

In [3]: log(x).conjugate()
Out[3]: (0.34657359027997264-2.356194490192345j)

In [4]: log(x.conjugate())
Out[4]: (0.34657359027997264-2.356194490192345j)

In [5]: x = -1

In [6]: log(x).conjugate()
Out[6]: -3.141592653589793j

In [7]: log(x.conjugate())
Out[7]: 3.141592653589793j

In [8]: log(x.conjugate()) - 2*pi*1j
Out[8]: -3.141592653589793j


Where [3] and [4] are equal, but [6] and [7] are not (you need to
subtract 2*pi*i from [7], as in [8], in order to recover [6],
consistent with the formula in the writeup).


Apart from this issue, all other examples that you posted seem to be
correct and agree with my hand based step by step calculation in the
writeup.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Thu, Nov 20, 2014 at 7:41 AM, Bill Page bill.p...@newsynthesis.org wrote:
 On 20 November 2014 01:54, Ondřej Čertík ondrej.cer...@gmail.com wrote:

 What you posted looks good. But we need to test it for arg(z), re(z),
 im(z) and any other non-analytic function that we can find.


 (1) - re(x)==(conjugate(x)+x)/2
Type:
 Void
 (2) - im(x)==%i*(conjugate(x)-x)/2
Type:
 Void
 (3) - arg(x)==log(x/abs(x))/%i
Type:
 Void
 (4) - re %i
Compiling function re with type Complex(Integer) - Fraction(Complex
   (Integer))

(4)  0
  Type:
 Fraction(Complex(Integer))
 (5) - im %i
Compiling function im with type Complex(Integer) - Fraction(Complex
   (Integer))

(5)  1
  Type:
 Fraction(Complex(Integer))
 (6) - arg %i
Compiling function arg with type Complex(Integer) - Expression(
   Complex(Integer))

(6)  - %i log(%i)
Type:
 Expression(Complex(Integer))
 (7) - complexNumeric %

(7)  1.5707963267_948966192
  Type:
 Complex(Float)
 (8) - D(re(x),x)
Compiling function re with type Variable(x) - Expression(Integer)

(8)  1
 Type:
 Expression(Integer)
 (9) - D(im(x),x)
Compiling function im with type Variable(x) - Expression(Complex(
   Integer))

(9)  0
Type:
 Expression(Complex(Integer))
 (10) - D(arg(x),x)
Compiling function arg with type Variable(x) - Expression(Complex(
   Integer))

  _ 2   2
  %i xx - 2%i abs(x)  + %i x
(10)  ---
2
   2x abs(x)
Type:
 Expression(Complex(Integer))


 I had a thought. I suppose that all non-analytic (nonholomorphic) functions
 of interest can be written in terms of conjugate and some analytic
 functions, e.g.

   abs(x)=sqrt(x*conjugate(x))

 so perhaps all we really need is to know how to differentiate conjugate
 properly?

I haven't thought of that, but I think you are right. It's definitely
true for abs(x), arg(x), re(x), im(x) and conjugate(x). Other
non-analytic functions are combinations of those. The only other way
to create some non-analytic functions is to define their real and
complex parts using x and y, e.g.

f(x+iy) = (x^2+y^2) + i*(2*x*y)

You can imagine arbitrary complicated expressions. But then you just
substitute z, conjugate(z) for x, y.

So I think that for most things that people would use a CAS for, this is true.


 Bill

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

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Thu, Nov 20, 2014 at 7:52 AM, Bill Page bill.p...@newsynthesis.org wrote:
 So here (20) is a simpler expression for derivative of arg:

 (16) - abs(x)==sqrt(x*conjugate(x))
Compiled code for abs has been cleared.
Compiled code for arg has been cleared.
1 old definition(s) deleted for function or rule abs
Type:
 Void
 (17) - arg(x)==log(x/abs(x))/%i
1 old definition(s) deleted for function or rule arg
Type:
 Void
 (18) - arg %i
Compiling function abs with type Complex(Integer) - Expression(
   Complex(Integer))
Compiling function arg with type Complex(Integer) - Expression(
   Complex(Integer))

(18)  - %i log(%i)
Type:
 Expression(Complex(Integer))
 (19) - complexNumeric %

(19)  1.5707963267_948966192
  Type:
 Complex(Float)
 (20) - D(arg(x),x)
Compiling function abs with type Variable(x) - Expression(Integer)
Compiling function arg with type Variable(x) - Expression(Complex(
   Integer))

  _
  - %ix + %i x
(20)  
 _
   2xx
Type:
 Expression(Complex(Integer))


 In general I am a little uncertain if, how and when to deal with
 simplifications of expressions like abs that can be expressed in terms of
 more fundamental/elementary functions.  What do you think?

The identity abs(z) = sqrt(z*conjugate(z)) is just the same problem as
for things like exp(x) = E^x, csc(x) = 1/sin(x), sinh(x) =
(exp(x)-exp(-x)/2, asin(x) = -i*log(i*x+sqrt(1-x^2)), asinh(x) =
log(x+sqrt(1+x^2)), ...

Essentially a lot of functions can be written using simpler functions.
The expression is sometimes simpler using abs() and sometimes simpler
using sqrt(x*conjugate(x)), and that is true for all the other cases
too. So a CAS needs to be able to handle both, and allow the user to
convert one to the other. For example in SymPy, we can do:

In [1]: sinh(x)**2+1
Out[1]:
2
sinh (x) + 1

In [2]: (sinh(x)**2+1).rewrite(exp)
Out[2]:
  2
⎛ x-x⎞
⎜ℯℯ  ⎟
⎜── - ───⎟  + 1
⎝2 2 ⎠

In [3]: _.expand()
Out[3]:
 2⋅x-2⋅x
ℯ  1   ℯ
 + ─ + ─
 4 2 4


In general, my approach is that I try to define the derivative of
abs(x) in the simplest possible way, which seems to be in terms of
abs(x) as well, instead of sqrt(x*conjugate(x)). But the CAS needs to
be able to rewrite it later if needed, because sometimes things can
simplify.

Ondrej


 Bill.

 On 20 November 2014 09:41, Bill Page bill.p...@newsynthesis.org wrote:
 ...

 I had a thought. I suppose that all non-analytic (nonholomorphic)
 functions of interest can be written in terms of conjugate and some analytic
 functions, e.g.

   abs(x)=sqrt(x*conjugate(x))

 so perhaps all we really need is to know how to differentiate conjugate
 properly?

 Bill

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

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Thu, Nov 20, 2014 at 9:16 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Thu, Nov 20, 2014 at 7:52 AM, Bill Page bill.p...@newsynthesis.org wrote:
 So here (20) is a simpler expression for derivative of arg:

 (16) - abs(x)==sqrt(x*conjugate(x))
Compiled code for abs has been cleared.
Compiled code for arg has been cleared.
1 old definition(s) deleted for function or rule abs
Type:
 Void
 (17) - arg(x)==log(x/abs(x))/%i
1 old definition(s) deleted for function or rule arg
Type:
 Void
 (18) - arg %i
Compiling function abs with type Complex(Integer) - Expression(
   Complex(Integer))
Compiling function arg with type Complex(Integer) - Expression(
   Complex(Integer))

(18)  - %i log(%i)
Type:
 Expression(Complex(Integer))
 (19) - complexNumeric %

(19)  1.5707963267_948966192
  Type:
 Complex(Float)
 (20) - D(arg(x),x)
Compiling function abs with type Variable(x) - Expression(Integer)
Compiling function arg with type Variable(x) - Expression(Complex(
   Integer))

  _
  - %ix + %i x
(20)  
 _
   2xx
Type:
 Expression(Complex(Integer))


 In general I am a little uncertain if, how and when to deal with
 simplifications of expressions like abs that can be expressed in terms of
 more fundamental/elementary functions.  What do you think?

 The identity abs(z) = sqrt(z*conjugate(z)) is just the same problem as
 for things like exp(x) = E^x, csc(x) = 1/sin(x), sinh(x) =
 (exp(x)-exp(-x)/2, asin(x) = -i*log(i*x+sqrt(1-x^2)), asinh(x) =
 log(x+sqrt(1+x^2)), ...

 Essentially a lot of functions can be written using simpler functions.
 The expression is sometimes simpler using abs() and sometimes simpler
 using sqrt(x*conjugate(x)), and that is true for all the other cases
 too. So a CAS needs to be able to handle both, and allow the user to
 convert one to the other. For example in SymPy, we can do:

 In [1]: sinh(x)**2+1
 Out[1]:
 2
 sinh (x) + 1

 In [2]: (sinh(x)**2+1).rewrite(exp)
 Out[2]:
   2
 ⎛ x-x⎞
 ⎜ℯℯ  ⎟
 ⎜── - ───⎟  + 1
 ⎝2 2 ⎠

 In [3]: _.expand()
 Out[3]:
  2⋅x-2⋅x
 ℯ  1   ℯ
  + ─ + ─
  4 2 4


 In general, my approach is that I try to define the derivative of
 abs(x) in the simplest possible way, which seems to be in terms of
 abs(x) as well, instead of sqrt(x*conjugate(x)). But the CAS needs to
 be able to rewrite it later if needed, because sometimes things can
 simplify.

Or to say it with different words, the reason we even have functions
like exp(x), csc(x), sinh(x), asin(x), asinh(x) is that things are
simpler if you use those as opposed to their more elementary function
definition. Perhaps with the exception of csc(x) = 1/sin(x), where I
personally don't see an advantage of introducing a new function for
just 1/sin(x). But with all the other ones, they simplify things,
sometimes. And so the art is to use those in  a way to create the most
simple expression at the end. I think that's all there is to it.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Thu, Nov 20, 2014 at 9:59 AM, Bill Page bill.p...@newsynthesis.org wrote:
 Perhaps this is more or less where Richardson's theorem enters.

 http://en.wikipedia.org/wiki/Richardson%27s_theorem

 We badly want a reliable way to determine when an expression is
 identically zero. In general this is not possible, but if we restrict
 our selves to a subset of elementary functions, in particular if we
 can avoid 'abs', then it is in principle decidable (not withstanding
 the possible undecidability of equality of constants). As I understand
 it FriCAS effectively relies on this as part of the machinery for
 integration, e.g. in 'rischNormalize'.  Waldek's challenge to me on
 the FriCAS list in regards to my proposals related to conjugate and
 this thread was to show that it is possible to include 'conjugate' and
 still have a decidable system given the complex equivalent of
 Richardson's theorem.

 So far I have not been able to meet this challenge or even to find any
 specific relevant related publications.  Perhaps it is obvious that
 this is not possible given the definition of abs in terms of conjugate
 and sqrt. I would be interested in anyone here has considered this
 issue or might suggest some leads.  Of course this is likely not of
 too much interest in computer algebra systems that take a more
 pragmatic approach than FriCAS/Axiom.

Can you give an example of an expression that cannot be decided by the
Richardson's theorem? How does FriCAS do the zero testing? I.e. if you
give it

f(x) = sin(x)^2 + cos(x)^2-1

how does it decide that it is equal to 0?

Are we talking about functions of just one variable (f(x)) or more
(f(x, y, z, ...))?

Why cannot you just use the probabilistic testing, where you plug in
various (complex) numbers into f(x) and test that it is equal to zero,
numerically.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Thu, Nov 20, 2014 at 7:53 PM, Bill Page bill.p...@newsynthesis.org wrote:
 On 20 November 2014 12:56, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 ...
 Can you give an example of an expression that cannot be decided by
 the Richardson's theorem?

 Well, no not exactly.  Richardson's theorem is not about individual
 expressions, it is about decidability, i.e. computability, in general.
 Consider an expression of the form

   f(x) - | f(x) |

 where f(x) is composed from integers, the variable x, +, * and sin.
 The question that Richardson's theorem answers is whether or not there
 exists a program that can determine if f(x) - |f(x)| = 0 for all x.
 This problem can be reduced to finding an algorithm to determine if
 f(x) is everywhere non-negative. Richardson proves that no such
 algorithm exists.

I see. But what does this have to do with the derivative of |f(x)| that
we are trying to figure out?

As you pointed out, the challenge is that if you include conjugate(x),
then you might be out of luck. But aren't you out of luck already if you
have abs(x) in the expression in the first place? I.e. taking a derivative
is not going to change anything, you are still out of luck.


 How does FriCAS do the zero testing? I.e. if you
 give it

 f(x) = sin(x)^2 + cos(x)^2-1

 how does it decide that it is equal to 0?

 This can be done by the function 'normalize' which first uses
 'realElementary' to rewrite the expression using just 4 fundamental
 real-valued elementary transcendental functions (kernels): log, exp,
 tan, and arctan. E.g.

   sin(x) = 2*tan(x/2)/(tan(x/2)^2+1)
   cos(x) = (1-tan(x/2)^2)/(1+tan(x/2)^2)

 For your example this suffices but if necessary it next rewrites the
 result again using the minimum number of algebraically independent
 kernels.

 There is also a complex-valued version called 'complexElementary'
 which uses only log and exp but may introduce the constant sqrt(-1).

I see, clever.



 Are we talking about functions of just one variable (f(x)) or more
 (f(x, y, z, ...))?

 In general more than one variable.


 Why cannot you just use the probabilistic testing, where you plug in
 various (complex) numbers into f(x) and test that it is equal to zero,
 numerically.


 I suppose that might be pragmatic but I would not call it computer
 algebra in the mathematical sense.

Sure, this might be one of the many methods in a CAS.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Wed, Nov 19, 2014 at 8:19 AM, Bill Page bill.p...@newsynthesis.org wrote:

 On 2014-11-19 9:36 AM, Bill Page bill.p...@newsynthesis.org wrote:
 ...
 Then I noticed that if we have f=z we get

   conjugate(z).diff(z)

 which is 0.  So the 2nd term is 0 and the result is just the first
 Wirtinger derivative.

 Perhaps I am misinterpreting something?


 Oops, my fault.  According to your definition

   conjugate(z).diff(z) = 1

Right, because this diff is the total derivative in the direction
theta, so the first Wirtinger derivative is 0, the second one is 1 and
you get:

0 + 1*e^{-2*i*theta})

and if you implicitly set theta=0, then you get 1.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Wed, Nov 19, 2014 at 9:32 AM, Bill Page bill.p...@newsynthesis.org wrote:
 OK, this looks better!

 (1) - D(abs(x),x)

  _
  x + x
(1)  ---
 2abs(x)
 Type:
 Expression(Integer)
 (2) - D(conjugate(x),y)

(2)  0
 Type:
 Expression(Integer)
 (3) - D(conjugate(x),x)

(3)  1
 Type:
 Expression(Integer)
 (4) - f:=operator 'f

(4)  f
   Type:
 BasicOperator
 (5) - D(abs(f(x)),x)

  , _  _  ,
 f(x)f (x) + f(x)f (x)

(5)  -
   2abs(f(x))
 Type:
 Expression(Integer)
 (6) - D(abs(log(x)),x)

 __
 xlog(x) + x log(x)
(6)  --
 _
   2xxabs(log(x))
 Type:
 Expression(Integer)

That looks good, right? What about arg(z). What are the Wirtinger
derivatives of arg(z)? Do you have other examples of non-analytic
functions?

Would you mind posting your patch to FriCAS somewhere? I would be
interested in how you implemented it.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Wed, Nov 19, 2014 at 9:42 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Wed, Nov 19, 2014 at 9:32 AM, Bill Page bill.p...@newsynthesis.org wrote:
 OK, this looks better!

 (1) - D(abs(x),x)

  _
  x + x
(1)  ---
 2abs(x)
 Type:
 Expression(Integer)
 (2) - D(conjugate(x),y)

(2)  0
 Type:
 Expression(Integer)
 (3) - D(conjugate(x),x)

(3)  1
 Type:
 Expression(Integer)
 (4) - f:=operator 'f

(4)  f
   Type:
 BasicOperator
 (5) - D(abs(f(x)),x)

  , _  _  ,
 f(x)f (x) + f(x)f (x)

(5)  -
   2abs(f(x))
 Type:
 Expression(Integer)
 (6) - D(abs(log(x)),x)

 __
 xlog(x) + x log(x)
(6)  --
 _
   2xxabs(log(x))
 Type:
 Expression(Integer)

 That looks good, right? What about arg(z). What are the Wirtinger
 derivatives of arg(z)? Do you have other examples of non-analytic
 functions?

 Would you mind posting your patch to FriCAS somewhere? I would be
 interested in how you implemented it.

I'll try to compile FriCAS myself and apply your patch, so that I can
play with it. Can you also try:

abs(I*x)

1/abs(x)
1/abs(x)^2
x/abs(x)^3
abs(x)^2

The x/abs(x)^3 is a Coulomb's law in 1D.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Wed, Nov 19, 2014 at 7:36 PM, Bill Page bill.p...@newsynthesis.org wrote:
 On 19 November 2014 21:23, kcrisman kcris...@gmail.com wrote:


 Since this mostly concerns FriCAS I am cross posting to that group.  I will 
 also post the patch there.  For FriCAS list reference the original email 
 thread is here:


 But if you come up with a solution Sage (or Ginac, or whatever) can 
 implement too, please let us know!


 Right now Ondrej's proposed definition is looking pretty good to me
 but I think it needs more extensive testing.  Apparently Ginac with
 Vladimir V. Kisil's patch is able to compute at least some of the
 results I showed with FriCAS.  If someone has used Ginac and is able
 to compile it with the patch, it would be good to have these results
 for comparison.

 Yes, certainly.  We can also continue this thread.

What you posted looks good. But we need to test it for arg(z), re(z),
im(z) and any other non-analytic function that we can find.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 9:28 AM, David Roe roed.m...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 8:05 AM, Bill Page bill.p...@newsynthesis.org wrote:
 On 18 November 2014 09:02, David Roe roed.m...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 5:57 AM, Bill Page bill.p...@newsynthesis.org 
 wrote:

  I think you are overly focused on trying to define a derivative that
  reduces to the conventional derivative of non-analytic functions
  over the reals.

 I've just been casually following this conversation, but I think it's
 important that the derivative of abs(x) be sign(x) not 2*sign(x) or
 1/2*sign(x).


 What makes it important that the derivative of abs(x) be sign(x)?
 An important point here is that there is no one single unique
 derivative of non-analytic functions like abs, but rather than all of
 their derivatives can be expressed in terms of just two.  I am
 seriously interested in reasons for retaining the status quo.

 Because derivative is not just used in the context of functions of a
 complex variable (whether they are analytic or not).  Probably more
 than 90% of Sage users don't know any complex analysis (as frequently
 lamented by rtf).  I will certainly acknowledge that people get things
 wrong with regard to sqrt and log by not knowing about branch cuts.
 But when it comes to the definition of derivative, we need to stay
 consistent with the standard definition of lim_{h - 0} (f(x + h) -
 f(x))/h for functions of a real variable (or functions that many
 people interpret as just functions of a real variable).  Any other
 decision will cause frustration for the vast majority of our users.

Well, I think it doesn't matter if you know complex analysis or not.
The point is rather that there is a real derivative and a complex
derivative. The complex derivative being a generalization of the real
one (http://en.wikipedia.org/wiki/Derivative#Generalizations,
http://en.wikipedia.org/wiki/Generalizations_of_the_derivative#Complex_analysis).
As such, it must reduce to the real derivative as a special case when
all variables are real, otherwise you get inconsistencies.

For example for real numbers, you get:

|x|' = x / |x| = sign(x)

and you can do this numerically. Here is a function that does this for
any angle theta in the complex plane:

def diff(f, z0, theta, eps=1e-8):
h = eps*exp(I*theta)
return (f(z0+h)-f(z0)) / h

For real numbers, you need to set theta=0. This then obviously becomes
the standard definition of a real derivative. So any other definition
than |x|' = sign(x) gives wrong answers. No matter if you know complex
analysis or not.

As far as the derivative of abs(x) in the complex plane for any theta,
the above diff function is just the directional derivative, i.e.
derivative in the direction theta. Based on my previous email, the
(only) correct analytic answer is, using Python notation:

x.conjugate()/(2*abs(x)) + x/(2*abs(x)) * exp(-2*I*theta)

And you can check numerically using the function diff above that
this is indeed the correct answer (just plug in various complex or
real values for x and check that diff and the above formula gives
the same numerical answer for all theta).

Bill, you wrote I think rather that one should strive for the most
general solution
consistent with the mathematics.. Well, the above (i.e.
x.conjugate()/(2*abs(x)) + x/(2*abs(x)) * exp(-2*I*theta)) is the most
general solution consistent with mathematics.

Of these options, only theta=0 gives the real derivative as a special
case, that's what the GiNaC proposal does.

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 11:08 AM, Bill Page bill.p...@newsynthesis.org wrote:
 On 18 November 2014 12:29, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 9:28 AM, David Roe roed.m...@gmail.com wrote:
 ...
 Because derivative is not just used in the context of functions of a
 complex variable (whether they are analytic or not).  Probably more
 than 90% of Sage users don't know any complex analysis (as frequently
 lamented by rtf).  I will certainly acknowledge that people get things
 wrong with regard to sqrt and log by not knowing about branch cuts.
 But when it comes to the definition of derivative, we need to stay
 consistent with the standard definition of lim_{h - 0} (f(x + h) -
 f(x))/h for functions of a real variable (or functions that many
 people interpret as just functions of a real variable).  Any other
 decision will cause frustration for the vast majority of our users.

 Well, I think it doesn't matter if you know complex analysis or not.

 I agree, but apparently for a different reason.

 The point is rather that there is a real derivative and a complex
 derivative. The complex derivative being a generalization of the
 real one (http://en.wikipedia.org/wiki/Derivative#Generalizations,
 http://en.wikipedia.org/wiki/Generalizations_of_the_derivative#Complex_analysis).
 As such, it must reduce to the real derivative as a special case when
 all variables are real, otherwise you get inconsistencies.


 As I said in another email, I think this is highly dependent on one's
 education and experience. Although I admit that it is very common
 (almost ubiquitous) to teach calculus starting from the notion of
 continuity and limits, I my opinion these references on wikipedia are
 especially biased.   To me from the point of view of computer algebra,
 the algebraic properties of derivatives are more important.

 For the sake of continuing the argument, from the point of view of
 algebra why should we consider derivatives of complex functions as a
 generalization of the real one rather than the real derivative as a
 defined in terms of something more general?  In particular notice that
 the so called Wirtinger derivatives also make sense in the case of
 quaternion analysis, so should we be expecting to view quaternion
 calculus also as a generalization' of real derivatives?

I don't know that much about quaternions. Real numbers and real
analysis is essentially a subset of complex analysis. Is that true
that complex analysis is a subset of quaternion analysis? But I think
it's true that quaternion analysis is a generalization of a real
analysis, so I would definitely expect the quaternion derivatives to
match the real ones.


 OK, maybe I am pushing this a little too far.  I admit that the
 argument from the point of view of limits and without any reference to
 conjugate is quite convincing.

 ...
 Bill, you wrote I think rather that one should strive for the most
 general solution
 consistent with the mathematics.. Well, the above (i.e.
 x.conjugate()/(2*abs(x)) + x/(2*abs(x)) * exp(-2*I*theta)) is the
 most general solution consistent with mathematics.

 Of these options, only theta=0 gives the real derivative as a special
 case, that's what the GiNaC proposal does.


 Have you had a chance to consider the issue of the chain-rule yet?

Yes. Very straightforward, as I suggested in my last email. Just start with:

D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}

and then consider the chain rule for Wirtinger derivatives
(http://en.wikipedia.org/wiki/Wirtinger_derivatives#Functions_of_one_complex_variable_2),
I am sure that can be proven quite easily. Then you just calculate
directly:

D f(g) / D z = df(g)/dz + df(g)/d conjugate(z) * e^{-2*i*theta} =

= (df/dg * dg/dz + df/d conjugate(g) * d conjugate(g) / dz) + (df/dg *
dg/d conjugate(z) + df/d conjugate(g) * d conjugate(g) / d
conjugate(z)) * e^{-2*i*theta} =

= df/dg * (dg/dz + dg/d conjugate(z) * e^{-2*i*theta}) + df/d
conjugate(g) * (d conjugate(g)/dz + d conjugate(g)/d conjugate(z) *
e^{-2*i*theta}) =

= df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz

So at the end, the theta dependence got absorbed into Dg/Dz and D
conjugate(g) / Dz, but it assumes that these directional derivatives
are taken with the same angle theta.

You can now use it to do the example from GiNaC:

  cout  abs(log(z)).diff(z)  endl;
  // (before) - D[0](abs)(log(z))*z^(-1)
  // (now) - 
1/2*(z^(-1)*conjugate(log(z))+log(z)*conjugate(z)^(-1))*abs(log(z))^(-1)

I.e. f(g) = |g|, g(z) = log(z) and you get:

D |log(z)| / D z = conjugate(g)/(2*|g|) * D log(z) / Dz + g / (2*|g|)
* D conjugate(log(z)) / Dz =

= conjugate(log(z)) / (2*|log(z)|) * 1/z + log(z) / (2*|log(z)|) *
1/conjugate(z) * e^{-2*i*theta})

= 1/(2*|log(z)|) * (conjugate(log(z)) / z + log(z) / conjugate(z) *
e^{-2*i*theta})

So it exactly agrees, except that there is a theta dependence in the
final answer and GiNaC implicitly chose theta=0. Everything in this
example should

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 12:14 PM, Bill Page bill.p...@newsynthesis.org wrote:
 On 18 November 2014 13:41, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 11:08 AM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 ...
 Have you had a chance to consider the issue of the chain-rule yet?

 Yes. Very straightforward, as I suggested in my last email. Just start with:

 D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}

 and then consider the chain rule for Wirtinger derivatives
 (http://en.wikipedia.org/wiki/Wirtinger_derivatives#Functions_of_one_complex_variable_2),
 I am sure that can be proven quite easily.

 Let me make sure I understand your proposal.  Are you saying that you
 would introduce the symbolic expression

e^{-2*i*theta}

 with theta undefined in the result of all derivatives?  So that
 diff(x) is always the sum of two terms. In particular

   abs(x).diff(x)

 would return the symbolic expression

   conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta}

I think you made a mistake, the correct expression is:

conjugate(x)/(2*abs(x)) + x/(2*abs(x)) * e^{-2*i*theta}


 If you are, then clearly one can recover both Wirtinger derivatives
 from this expression and the rest holds.

For now I just wanted to get the math right in the most general case.
I wasn't even considering what a CAS should do.


 Then you just calculate directly:
 ...
 So it exactly agrees, except that there is a theta dependence in the
 final answer and GiNaC implicitly chose theta=0.
...
 I hope I didn't make some mistake somewhere, but it looks all
 straightforward to me.


 It looks OK to me but I must say, it probably seems rather peculiar
 from the point of view expressed earlier by David Roe.

 How can you explain the presence of the e^theta term to someone
 without experience in complex analysis or at least multi-variable
 calculus?

 I thought rather that what you were proposing was to set theta=0 from
 the start.  If you did that, then I think you still have problems with
 the chain rule.

For a CAS, I was leaning towards using theta=0. But given your
objections, I first needed to figure out the most general case that
covers everything. I think that's now sufficiently clarified.

 Let me add that the kind of solution to this problem that I did
 imagine was to implement two derivatives, for example both

   f.diff(z) = df/dz + df/d conjugate(z)

 and

   f.diff2(z) = df/dz - df/d conjugate(z)

 diff(z) would equal diff2(z) for all analytic functions and diff would
 reduce to the derivative of real non-analytic functions as you desire.

Right, diff() is for theta = 0. diff2() is for theta=pi/2, i.e. taking
the derivative along the imaginary axis.

 Note that for abs we have

   abs(z).diff2(z) = 0

Actually, for abs you have:

abs(z).diff2(z) = (conjugate(z)-z)/(2*abs(z))

 but not in general.  There would be no need to discuss this 2nd
 derivative with less experienced users until they were ready to
 consider more advanced mathematics.

 Clearly we could implement the chain rule given these two derivatives.

So I think that functions can return their own correct derivative, for
example analytic functions just return the unique complex derivative,
for example:

log(z).diff(z) = 1/z

This holds for all cases. Non-analytic functions like abs(f) can return:

abs(f).diff(z) = (conjugate(f)*f.diff(z) +
f*conjugate(f).diff(z)*e^{-2*i*theta}) / (2*abs(f))

I think that's the correct application of the chain rule. We can set
theta=0, so we would just return:

abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / (2*abs(f))

Which for real f (i.e. conjugate(f)=f) simplifies to (as a special case):

abs(f).diff(z) = (f*f.diff(z) + f*f.diff(z)) / (2*abs(f)) = f/abs(f) *
f.diff(z) = sign(f) * f.diff(z)

So it all works.

Unless there is some issue that I don't see, it seems to me we just
need to have one diff(z) function, no need for diff2().

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 1:19 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 12:14 PM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 On 18 November 2014 13:41, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 11:08 AM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 ...
 Have you had a chance to consider the issue of the chain-rule yet?

 Yes. Very straightforward, as I suggested in my last email. Just start with:

 D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}

 and then consider the chain rule for Wirtinger derivatives
 (http://en.wikipedia.org/wiki/Wirtinger_derivatives#Functions_of_one_complex_variable_2),
 I am sure that can be proven quite easily.

 Let me make sure I understand your proposal.  Are you saying that you
 would introduce the symbolic expression

e^{-2*i*theta}

 with theta undefined in the result of all derivatives?  So that
 diff(x) is always the sum of two terms. In particular

   abs(x).diff(x)

 would return the symbolic expression

   conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta}

 I think you made a mistake, the correct expression is:

 conjugate(x)/(2*abs(x)) + x/(2*abs(x)) * e^{-2*i*theta}


 If you are, then clearly one can recover both Wirtinger derivatives
 from this expression and the rest holds.

 For now I just wanted to get the math right in the most general case.
 I wasn't even considering what a CAS should do.


 Then you just calculate directly:
 ...
 So it exactly agrees, except that there is a theta dependence in the
 final answer and GiNaC implicitly chose theta=0.
...
 I hope I didn't make some mistake somewhere, but it looks all
 straightforward to me.


 It looks OK to me but I must say, it probably seems rather peculiar
 from the point of view expressed earlier by David Roe.

 How can you explain the presence of the e^theta term to someone
 without experience in complex analysis or at least multi-variable
 calculus?

 I thought rather that what you were proposing was to set theta=0 from
 the start.  If you did that, then I think you still have problems with
 the chain rule.

 For a CAS, I was leaning towards using theta=0. But given your
 objections, I first needed to figure out the most general case that
 covers everything. I think that's now sufficiently clarified.

 Let me add that the kind of solution to this problem that I did
 imagine was to implement two derivatives, for example both

   f.diff(z) = df/dz + df/d conjugate(z)

 and

   f.diff2(z) = df/dz - df/d conjugate(z)

 diff(z) would equal diff2(z) for all analytic functions and diff would
 reduce to the derivative of real non-analytic functions as you desire.

 Right, diff() is for theta = 0. diff2() is for theta=pi/2, i.e. taking
 the derivative along the imaginary axis.

 Note that for abs we have

   abs(z).diff2(z) = 0

 Actually, for abs you have:

 abs(z).diff2(z) = (conjugate(z)-z)/(2*abs(z))

 but not in general.  There would be no need to discuss this 2nd
 derivative with less experienced users until they were ready to
 consider more advanced mathematics.

 Clearly we could implement the chain rule given these two derivatives.

 So I think that functions can return their own correct derivative, for
 example analytic functions just return the unique complex derivative,
 for example:

 log(z).diff(z) = 1/z

 This holds for all cases. Non-analytic functions like abs(f) can return:

 abs(f).diff(z) = (conjugate(f)*f.diff(z) +
 f*conjugate(f).diff(z)*e^{-2*i*theta}) / (2*abs(f))

Actually, I think I made a mistake. Let's do abs(f).diff(x) again for
the most general case. We use:

D f(g) / D z =

= df/dg * (dg/dz + dg/d conjugate(z) * e^{-2*i*theta}) + df/d
conjugate(g) * (d conjugate(g)/dz + d conjugate(g)/d conjugate(z) *
e^{-2*i*theta}) =

= df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz

Which we derived above. We have f(g) - |g| and g(z) - f(z). So we get:

D |f| / Dz = d|f|/df * Df/Dz + d|f|/d conjugate(f) * D conjugate(f) / Dz =

= (conjugate(f) * Df/Dz + f * D conjugate(f) / Dz) / (2*abs(f))

And then:

Df/Dz = f.diff(z)
D conjugate(f) / Dz = conjugate(f).diff(z)

So I think the formula:

abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / (2*abs(f))

is the most general formula for any theta. The theta dependence is hidden
in conjugate(f).diff(z), since if f is analytic, like f=log(z), the
conjugate(f) is
not analytic, and so the derivative is theta dependent.

The below holds though:


 I think that's the correct application of the chain rule. We can set
 theta=0, so we would just return:

 abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
 (2*abs(f))

 Which for real f (i.e. conjugate(f)=f) simplifies to (as a special case):

 abs(f).diff(z) = (f*f.diff(z) + f*f.diff(z)) / (2*abs(f)) = f/abs(f) *
 f.diff(z) = sign(f) * f.diff(z)

 So it all works.

 Unless there is some issue that I don't see, it seems to me we just
 need to have one diff(z) function, no need

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 2:50 PM, Bill Page bill.p...@newsynthesis.org wrote:
 On 18 November 2014 15:19, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 12:14 PM, Bill Page bill.p...@newsynthesis.org 
 wrote:

   abs(x).diff(x)

 would return the symbolic expression

   conjugate(x)/(2*abs(x)) + conjugate(x)/(2*abs(x))* e^{-2*i*theta}

 I think you made a mistake, the correct expression is:

 conjugate(x)/(2*abs(x)) + x/(2*abs(x)) * e^{-2*i*theta}


 Yes, sorry.

 ...
 I thought rather that what you were proposing was to set theta=0
 from the start.  If you did that, then I think you still have problems
 with the chain rule.

 For a CAS, I was leaning towards using theta=0. But given your
 objections, I first needed to figure out the most general case that
 covers everything. I think that's now sufficiently clarified.


 OK.

 Let me add that the kind of solution to this problem that I did
 imagine was to implement two derivatives, for example both

   f.diff(z) = df/dz + df/d conjugate(z)

 and

   f.diff2(z) = df/dz - df/d conjugate(z)

 diff(z) would equal diff2(z) for all analytic functions and diff would
 reduce to the derivative of real non-analytic functions as you desire.

 Right, diff() is for theta = 0. diff2() is for theta=pi/2, i.e. taking
 the derivative along the imaginary axis.

 Note that for abs we have

   abs(z).diff2(z) = 0

 Actually, for abs you have:

 abs(z).diff2(z) = (conjugate(z)-z)/(2*abs(z))


 Yes again, sorry.  Of course 0 only if conjugate(z)=z.

 but not in general.  There would be no need to discuss this 2nd
 derivative with less experienced users until they were ready to
 consider more advanced mathematics.

 Clearly we could implement the chain rule given these two derivatives.
 ...

 On 18 November 2014 15:46, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 1:19 PM, Ondřej Čertík ondrej.cer...@gmail.com 
 wrote:
 ..

 So I think that functions can return their own correct derivative, for
 example analytic functions just return the unique complex derivative,
 for example:

 log(z).diff(z) = 1/z

 This holds for all cases. Non-analytic functions like abs(f) can return:

 abs(f).diff(z) = (conjugate(f)*f.diff(z) +
 f*conjugate(f).diff(z)*e^{-2*i*theta}) / (2*abs(f))

 Actually, I think I made a mistake. Let's do abs(f).diff(x) again for
 the most general case. We use:

 D f(g) / D z =

 = df/dg * (dg/dz + dg/d conjugate(z) * e^{-2*i*theta}) + df/d
 conjugate(g) * (d conjugate(g)/dz + d conjugate(g)/d conjugate(z) *
 e^{-2*i*theta}) =

 = df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz

 Which we derived above. We have f(g) - |g| and g(z) - f(z). So we get:

 D |f| / Dz = d|f|/df * Df/Dz + d|f|/d conjugate(f) * D conjugate(f) / Dz =

 = (conjugate(f) * Df/Dz + f * D conjugate(f) / Dz) / (2*abs(f))

 And then:

 Df/Dz = f.diff(z)
 D conjugate(f) / Dz = conjugate(f).diff(z)

 So I think the formula:

 abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
 (2*abs(f))

 is the most general formula for any theta. The theta dependence is hidden
 in conjugate(f).diff(z), since if f is analytic, like f=log(z), the
 conjugate(f) is not analytic, and so the derivative is theta dependent.

 The below holds though:


 I think that's the correct application of the chain rule. We can set
 theta=0, so we would just return:

 abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
 (2*abs(f))

 Which for real f (i.e. conjugate(f)=f) simplifies to (as a special case):

 abs(f).diff(z) = (f*f.diff(z) + f*f.diff(z)) / (2*abs(f)) = f/abs(f) *
 f.diff(z) = sign(f) * f.diff(z)

 So it all works.

 Unless there is some issue that I don't see, it seems to me we just
 need to have one diff(z) function, no need for diff2().


 Hmmm... So given only f(z).diff(z) as you have defined it above, how
 do I get Df(z)/D conjugate(z), i.e. the other Wirtinger derivative?
 Or are you claiming that this is not necessary in general in spite of
 the Wirtinger  formula for the chain rule?

In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) /
d conjugate(z). The Df(z) / Dz is the complex derivative taking in
direction theta (where it could be theta=0). Given the chain rule, as
I derived above using chain rules for the Wirtinger derivative:

D f(g) / D z = df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz

I don't see why you would need the isolated Wirtinger derivatives. The
method that implements the derivative of the given function, like
log(z) or abs(z) would simply return the correct formula, as I said
above, e.g.

log(z).diff(z) = 1/z

abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / (2*abs(f))

Both formulas hold for any theta. I guess it depends on how the CAS is
implemented, maybe some CASes have a general machinery for
derivatives. But I am pretty sure you can simply implemented it as I
outlined.

Let me know if you found any issue with this.

Ondrej

-- 
You received this message because

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Tue, Nov 18, 2014 at 6:51 PM, Bill Page bill.p...@newsynthesis.org wrote:
 On 18 November 2014 17:40, Ondřej Čertík ondrej.cer...@gmail.com wrote:

 In my notation, the Wirtinger derivative is d f(z) / d z and d f(z) /
 d conjugate(z). The Df(z) / Dz is the complex derivative taking in
 direction theta (where it could be theta=0). Given the chain rule, as
 I derived above using chain rules for the Wirtinger derivative:

 D f(g) / D z = df/dg Dg/Dz + df/d conjugate(g) D conjugate(g) / Dz

 I don't see why you would need the isolated Wirtinger derivatives.

 You mean that only the function being differentiated needs to the
 Writinger derivatives (as part of the formula that it implements for
 the chain rule)?

Did you mean to write You mean that only the function being
differentiated needs to do the
Writinger derivatives...?

Yes.


 The
 method that implements the derivative of the given function, like
 log(z) or abs(z) would simply return the correct formula, as I said
 above, e.g.

 log(z).diff(z) = 1/z

 abs(f).diff(z) = (conjugate(f)*f.diff(z) + f*conjugate(f).diff(z)) / 
 (2*abs(f))


 If the chain rule must  be implemented by each function then I suppose
 that you also have

   log(f).diff(z) = f.diff(z) / z

 right?

Yes, correct.


 Both formulas hold for any theta.

 The generality provided by theta seems not be be of much interest.

I agree, I think one can implicitly set theta=0 in a CAS. So that's
the option 2) in my email above.


 I guess it depends on how the CAS is implemented, maybe
 some CASes have a general machinery for derivatives. But
 I am pretty sure you can simply implemented it as I outlined.

 Let me know if you found any issue with this.


 Is this how derivatives are implemented in sympy?

It's a little more complicated in sympy, but that's how derivatives
are implemented in csympy (https://github.com/sympy/csympy).

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

Hi Bill,

On Sat, Nov 15, 2014 at 9:18 AM, Bill Page bill.p...@newsynthesis.org wrote:
 On 14 November 2014 14:29, Ondřej Čertík ondrej.cer...@gmail.com wrote:

 On Nov 14, 2014 11:30 AM, Bill Page bill.p...@newsynthesis.org wrote:

 What do you mean by the real derivative?

 The absolute value doesn't have a complex derivative, but it has a real
 derivative, over the real axis.


 It seems to me that the concept of real axis is rather foreign to
 the algebra.  Assuming conjugate is implemented properly, i.e.
 algebraically,  what you are actually saying is just that

   z = conjugate(z)

That's fine.


 ...
 You are not differentiating with respect to x, you are differentiating
 with respect to

   (z+conjugate(z))/2

 Is that how you propose to define the derivatives for non-analytic
 functions? I am a little confused what exactly is your proposal.


 I am sorry for the confusion.  What I am proposing is that the
 Wirtinger derivative(s) be considered the fundamental case (valid for
 complex or even quaternion variables). As you noted previously this is
 fine and doesn't change anything for the case of analytic functions.
 If someone wants the derivative of a non-analytic function over a
 given domain that should be called something else.

I still don't understand exactly your proposal. We've played with a
few ideas above, in particular we have considered at least (below d/dz
is the Wirtinger derivative, d/dx and d/d(iy) are partial derivatives
with respect to x or iy in z=x+i*y) :

1) d/dz
2) d/dz + d/d conjugate(z) = d/dx
3) d/dz - d/d conjugate(z) = d/d(iy)
4) 2 * (d/dz + d/d conjugate(z))
5) 2 * d/dz

Which of these do you propose to use? For analytic functions, only 1)
and 2) reduce to the usual complex derivative. 4) and 5) will be off
by a factor of 2. For example, for a function z^2 we get:

1) 2*z
2) 2*z
3) 2*z
4) 4*z
5) 4*z

Since z^2 is analytic, the correct derivative is 2*z, so 1), 2) and 3)
give the right answer.

For abs(z), we get:

1) conjugate(z) / (2*|z|)
2) Re(z) / |z|
3) -i*Im(z) / |z|
4) 2*Re(z) / |z|
5) conjugate(z) / |z|

When z is real, then the (real) derivative of |z|' = z/|z|. We want
our complex formula to be equal to z/|z| if z is real. Of the above,
only 2) and 5) is equal to z/|z| when z is real. Note that I made a
sign mistake in my previous email regarding 3).


Comparing these two cases, options 1) and 3) are eliminated because
the results for abs(z) do not reduce to the correct real derivative.
Option 4) is eliminated, because it gives wrong results for analytic
functions, as well as it doesn't reduce to the correct real derivative
for abs(z). Option 5) is eliminated because it gives wrong results for
analytic functions.

As such, only option 2) is consistent. For all analytic functions, it
gives the correct complex derivative, and for non-analytic functions,
at least for abs(z) it reduces to the correct real derivative in the
special case when z is real, i.e. z = conjugate(z). Note that you
cannot apply z = conjugate(z) to the definition of 2) to obtain the
(incorrect) result 2*d/dz, you need to treat z and conjugate(z)
separately when differentiating and only at the end apply z =
conjugate(z).

It seems to work for other non-analytic functions, for example for
Re(z) = (z+conjugate(z))/2, we get:

2) 1

for Im(z) = (-z+conjugate(z))*i/2 we get:

2) 0

So that all works as expected. To prove that this works for all
non-analytic functions, we just use the fact that d/dz + d/d
conjugate(z) = d/dx, as we talked about above. So we are just
calculating the partial derivative with respect to x  (we use the
notation z = x+i*y). When z is real, i.e. z = conjugate(z), it
follows that y = 0, and d/dx is just the usual (real) derivative. When
y is non-zero, we still calculate d/dx but using z and conjugate(z).
As shown above, for analytic functions this d/dx derivative is equal
to the complex derivative. For non-analytic functions the complex
derivative doesn't exist, so it's just our definition, but it reduces
to the usual real derivative (which is always equal to d/dx). In one
of my previous emails, I raised a question for non-analytic functions,
why we can't define it in some other way, perhaps d/d(iy), i.e. the
option 3) above. I think the answer is that we can, but it will not
reduce to the real derivative d/dx if z is real, simply because
d/d(iy) is not equal to d/dx, unless the function is analytic, i.e. 3)
works for analytic functions, but fails for abs(z), as shown above (as
well as in my previous email --- note again that I made a sign mistake
there).


 I think one either leaves the derivatives of non analytic functions
 unevaluated,

 No, this is just giving up.  We should be able to do much better than that.

 or defines them in such a way that one recovers the real derivative
 as a special case, as long as there are no inconsistencies.


 Yes exactly, the concept of real derivative is a special case.

Hopefully the above clarifies, that from everything that we have

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

 I still don't understand exactly your proposal. We've played with a
 few ideas above, in particular we have considered at least (below d/dz
 is the Wirtinger derivative, d/dx and d/d(iy) are partial derivatives
 with respect to x or iy in z=x+i*y) :

 1) d/dz
 2) d/dz + d/d conjugate(z) = d/dx
 3) d/dz - d/d conjugate(z) = d/d(iy)
 4) 2 * (d/dz + d/d conjugate(z))
 5) 2 * d/dz

 Which of these do you propose to use? For analytic functions, only 1)
 and 2) reduce to the usual complex derivative. 4) and 5) will be off
 by a factor of 2. For example, for a function z^2 we get:


Correction: For analytic functions, only 1), 2) and 3) reduce to the
usual complex derivative.
(As is shown below on particular examples.)

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

Hi Bill,

Thanks for the clarification. So your point is that 2) is not
sufficient, that we really need two Wirtinger derivatives --- it's
just that one can be expressed using the other and a conjugate, so
perhaps CAS can only return one, but a chain rule needs modification
and probably some other derivatives handling as well. I need to think
about this harder.

Here is a relation that I found today in [1] (see also the references
there), I don't know if you are aware of it:

D f / D z = df/dz + df/d conjugate(z) * e^{-2*i*theta}

Where Df/Dz is the derivative in a complex plane along the direction
theta (the angle between the direction and the x-axis) and df/dz and
df/d conjugate(z) are the two Wirtinger derivatives. This formula
holds for any function. So all the derivatives no matter which
direction lie on a circle of radius df/d conjugate(z) and center
df/dz.

For analytic functions, we have df/d conjugate(z) = 0, and so the
above formula proves that all the derivatives are independent of
direction theta and equal to df/dz.

For non-analytic functions, the above formula gives all the possible
derivatives, and besides df/dz, the derivatives also depend on df/d
conjugate(z) and theta. But that's it. So as you said, the two
Wirtinger derivatives allow us to calculate the derivative along any
direction theta we want.

From my last email, the case 1) corresponds to df/d conjugate(z)=0,
i.e. analytic functions and the result is independent of theta. Case
2) is theta = 0, pi, 2*pi, ..., i.e. taking the derivative along the
x-axis. Case 3) is theta = pi/2, 3*pi/2, 5*pi/2, ..., i.e. taking the
derivative along the y-axis.


A real derivative of a real function g(x) is simply taken along the
x-axis. You can imagine that g(x) is also (arbitrarily) defined in the
whole complex plane and you are taking the Dg/gz derivative above with
theta = 0. The result is the same. So that's why the case 2), i.e.
theta=0, always reproduces the real derivative, because real
derivative is defined as theta=0.

For CAS, one could probably just say that theta=0 in our definition,
and then everything is consistent, and we only have one derivative,
2). The other option is to return both derivatives and make the
derivative Df/Dz of non-analytic function equal to the above formula,
i.e. depending on df/dz, df/d conjugate(z) and theta.

I need to think about the chain rule. I would simply introduce the
theta dependence into all formulas, as that gives all possible
derivatives and gives the exact functional dependence of all
possibilities. And then see whether we need to keep all formulas in
terms of theta, or perhaps if we can set theta = 0 for everything.

Ondrej

[1] Pyle, H. R.,  Barker, B. M. (1946). A Vector Interpretation of
the Derivative Circle. The American Mathematical Monthly, 53(2), 79.
doi:10.2307/2305454

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Nov 14, 2014 8:57 AM, Bill Page bill.p...@newsynthesis.org wrote:

 On 14 November 2014 02:19, Ondřej Čertík ondrej.cer...@gmail.com wrote:
  On Fri, Nov 14, 2014 at 12:14 AM, Ondřej Čertík ondrej.cer...@gmail.com
wrote:
  ...
  Ok, thanks for the confirmation.
 
  There is an issue though --- since |z| is not analytic, the
  derivatives depend on the direction. So along x you get
 
  |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d
conjugate(z) =
  conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z|
 
  but along y you get:
 
  |z|' = \partial |z| / \partial i*y = d |z| / d z - d |z| / d
conjugate(z) =
  conjugate(z) / (2*|z|) - z / (2*|z|) = i*Im(z) / |z|
 
  So I get something completely different.

 It seems to me that we should forget about x and y.  All we really need is

  |z|'  = d |z| / d z = conjugate(z) / (2*|z|)

 and the appropriate algebraic properties of conjugate.

Sure, we can make a CAS return this. But then you get the 1/2 there.


  So which direction should be preferred in the CAS convention and why?
 

 Well, um, you did write: Because I would like to get

   d|x| / d x = x / |x|

   for real x.

 The constant 1/2 is irrelevant.

Well, but how do I recover the real derivative from the complex one if they
differ by a factor of 1/2?

In other words, what is the utility of such a definition then?

I can see the utility of differentiating with respect to x, as at least you
must recover the real derivative results.

Ondrej


 Bill.

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

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Nov 14, 2014 11:30 AM, Bill Page bill.p...@newsynthesis.org wrote:

 On 14 November 2014 13:18, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 
  On Nov 14, 2014 8:57 AM, Bill Page bill.p...@newsynthesis.org wrote:
 
  It seems to me that we should forget about x and y.  All we really
need is
 
   |z|'  = d |z| / d z = conjugate(z) / (2*|z|)
 
  and the appropriate algebraic properties of conjugate.
 
  Sure, we can make a CAS return this. But then you get the 1/2 there.
 

 Yes.

  ...
  The constant 1/2 is irrelevant.
 
  Well, but how do I recover the real derivative from the complex one if
they
  differ by a factor of 1/2?
 

 What do you mean by the real derivative?

The absolute value doesn't have a complex derivative, but it has a real
derivative, over the real axis.

 Perhaps we can just define that as

   d f / d z + d f / d  conjugate(z)

  In other words, what is the utility of such a definition then?
 
  I can see the utility of differentiating with respect to x, as at least
you
  must recover the real derivative results.
 

 You are not differentiating with respect to x, you are differentiating
 with respect to

   (z+conjugate(z))/2

Is that how you propose to define the derivatives for non-analytic
functions? I am a little confused what exactly is your proposal.

I think one either leaves the derivatives of non analytic functions
unevaluated, or defines them in such a way that one recovers the real
derivative as a special case, as long as there are no inconsistencies.

Ondrej


 Bill.

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

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

Yes. Note also here:

http://mathworld.wolfram.com/AbsoluteValue.html

which says that complex derivative of d|z|/dz does not exist, as
Cauchy-Riemann equations do not hold for Abs(z). And:

As a result of the fact that computer algebra programs such as
Mathematica generically deal with complex variables (i.e., the
definition of derivative always means complex derivative), d|z|/dz
correctly returns unevaluated by such software.

So perhaps SymPy and Sage should return Derivative(Abs(x), x). Only
when user specifies that x is real, only then we can differentiate.

Ondrej

On Thu, Nov 13, 2014 at 12:17 AM, Clemens Heuberger
clemens.heuber...@aau.at wrote:

 possibly related to http://trac.sagemath.org/ticket/12588 ?

 Regards, CH

 Am 2014-11-13 um 06:19 schrieb Ondřej Čertík:
 Hi,

 With Sage 6.3, I am getting:

 sage: abs(x).diff(x)
 x/abs(x)
 sage: abs(I*x).diff(x)
 -x/abs(I*x)

 But abs(I*x) == abs(x). So also abs(x).diff(x) and abs(I*x).diff(x)
 must be the same. But in the first case we get x/abs(x), and in the
 second we got -x/abs(x).

 In SymPy, the answer is:

 In [1]: abs(x).diff(x)
 Out[1]:
   d d
 re(x)⋅──(re(x)) + im(x)⋅──(im(x))
   dxdx
 ─
│x│


 In [2]: x = Symbol(x, real=True)

 In [3]: abs(x).diff(x)
 Out[3]: sign(x)

 In [4]: abs(I*x).diff(x)
 Out[4]: sign(x)

 In [26]: var(x)
 Out[26]: x

 Which seems all correct --- in the complex case [1] we get a little
 messy expression, but a correct one. For a real case, we get the
 correct answer.

 In Wolfram Alpha, the answer of abs(I*x).diff(x) is x/abs(x):

 http://www.wolframalpha.com/input/?i=Diff%5BAbs%5Bi*x%5D%2C+x%5D

 Which is only correct for real x, but at least it is correct for
 this special case.

 The Sage result seems wrong for any x.

 Ondrej



 --
 Univ.-Prof. Dr. Clemens HeubergerAlpen-Adria-Universität Klagenfurt
 Institut für Mathematik, Universitätsstraße 65-67, 9020 Klagenfurt, Austria
 Tel: +43 463 2700 3121Fax: +43 463 2700 99 3121
 clemens.heuber...@aau.athttp://wwwu.aau.at/cheuberg

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

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

Hi Bill,

On Thu, Nov 13, 2014 at 10:16 AM, Bill Page bill.p...@newsynthesis.org wrote:
 It has always seemed very inconvenient to me that computer algebra
 programs such as Mathematica choose to define derivative as
 complex-derivative.  I believe a reasonable alternative is what is
 known as a Wirtinger derivative.  Wirtinger derivatives exist for all
 continuous complex-valued functions including non-holonomic functions
 and permit the construction of a differential calculus for functions
 of complex variables that is analogous to the ordinary differential
 calculus for functions of real variables

 http://en.wikipedia.org/wiki/Wirtinger_derivatives

 Wirtinger derivatives come in conjugate pairs but we have

   f(x).diff(conjugate(x)) = conjugate(conjugate(f(x).diff(x))

 so we really only need one derivative given an appropriate conjugate
 function.  The Cauchy-Riemann equations reduce to

   f(x).diff(conjugate(x)) = 0

 I also like that abs is related to the sgn function

  abs(x).diff(x)  = x/abs(x)

 This is consistent with

   abs(x)=sqrt(x*conjugate(x))

 The Wirtinger derivative of abs(x) is 1/2 x/abs(x).  Its total
 Wirtinger derivative is x/abs(x).

 I have implemented conjugate and Wirtinger derivatives in FriCAS

   http://axiom-wiki.newsynthesis.org/SandBoxWirtinger

 Unfortunately I have not yet been able to convince the FriCAS
 developers of the appropriateness of this approach.  I would be happy
 to find someone with whom to discuss this further, pro and con.  The
 discussion on the FriCAS email list consisted mostly of the related
 proper treatment of conjugate without making explicit assumptions
 about variables.

Thanks for your email! I haven't talked to you in a long time.
Literally just today I learned about Wirtinger derivatives. The
wikipedia page is *really* confusing to me. It took me a while to
realize, that Wirtinger derivatives is simply the derivative with
respect to z or conjugate(z). I.e.

z = x + i*y
conjugate(z) = x - i*y

From this it follows:

x = 1/2*(z + conjugate(z))
y = i/2*(-z+conjugate(z))

Then I take any function and write it in terms of z and conjugate(z),
some examples:

|z| = sqrt(z*conjugate(z))
Re z = x = 1/2 * (z + conjugate(z))
z^2 = (x+i*y)^2

And then I simply differentiate with respect to z or conjugate(z).
This is called the Wirtinger derivative. So:

d|z|/dz = d sqrt(z*conjugate(z)) / dz = 1/2*conjugate(z) / |z|

As you said, the function is analytic if it doesn't functionally
depend on conjugate(z), as can be shown easily. So |z| or Re z are not
analytic, while z^2 is. If the function is analytic, then df/d
conjugate(z) = 0, and df/dz is the complex derivative. Right?

So for analytic functions, Wirtinger derivative gives the same answer
as Mathematica. For non-analytic functions, Mathematica leaves it
unevaluated, but Wirtinger derivative gives you something.

How do you calculate the total Wirtinger derivative? How is that defined?

Because I would like to get

d|x| / d x = x / |x|

for real x. And I don't see currently how is this formula connected to
Wirtinger derivatives. Finally, the derivative operator in a CAS could
return Wirtinger derivatives, I think it's a great idea, if somehow we
can recover the usual formula for abs(x) with real x.

What are the cons of this approach?

Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Thu, Nov 13, 2014 at 2:00 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 Hi Bill,

 On Thu, Nov 13, 2014 at 10:16 AM, Bill Page bill.p...@newsynthesis.org 
 wrote:
 It has always seemed very inconvenient to me that computer algebra
 programs such as Mathematica choose to define derivative as
 complex-derivative.  I believe a reasonable alternative is what is
 known as a Wirtinger derivative.  Wirtinger derivatives exist for all
 continuous complex-valued functions including non-holonomic functions
 and permit the construction of a differential calculus for functions
 of complex variables that is analogous to the ordinary differential
 calculus for functions of real variables

 http://en.wikipedia.org/wiki/Wirtinger_derivatives

 Wirtinger derivatives come in conjugate pairs but we have

   f(x).diff(conjugate(x)) = conjugate(conjugate(f(x).diff(x))

 so we really only need one derivative given an appropriate conjugate
 function.  The Cauchy-Riemann equations reduce to

   f(x).diff(conjugate(x)) = 0

 I also like that abs is related to the sgn function

  abs(x).diff(x)  = x/abs(x)

 This is consistent with

   abs(x)=sqrt(x*conjugate(x))

 The Wirtinger derivative of abs(x) is 1/2 x/abs(x).  Its total
 Wirtinger derivative is x/abs(x).

 I have implemented conjugate and Wirtinger derivatives in FriCAS

   http://axiom-wiki.newsynthesis.org/SandBoxWirtinger

 Unfortunately I have not yet been able to convince the FriCAS
 developers of the appropriateness of this approach.  I would be happy
 to find someone with whom to discuss this further, pro and con.  The
 discussion on the FriCAS email list consisted mostly of the related
 proper treatment of conjugate without making explicit assumptions
 about variables.

 Thanks for your email! I haven't talked to you in a long time.
 Literally just today I learned about Wirtinger derivatives. The
 wikipedia page is *really* confusing to me. It took me a while to
 realize, that Wirtinger derivatives is simply the derivative with
 respect to z or conjugate(z). I.e.

 z = x + i*y
 conjugate(z) = x - i*y

 From this it follows:

 x = 1/2*(z + conjugate(z))
 y = i/2*(-z+conjugate(z))

 Then I take any function and write it in terms of z and conjugate(z),
 some examples:

 |z| = sqrt(z*conjugate(z))
 Re z = x = 1/2 * (z + conjugate(z))
 z^2 = (x+i*y)^2

 And then I simply differentiate with respect to z or conjugate(z).
 This is called the Wirtinger derivative. So:

 d|z|/dz = d sqrt(z*conjugate(z)) / dz = 1/2*conjugate(z) / |z|

 As you said, the function is analytic if it doesn't functionally
 depend on conjugate(z), as can be shown easily. So |z| or Re z are not
 analytic, while z^2 is. If the function is analytic, then df/d
 conjugate(z) = 0, and df/dz is the complex derivative. Right?

To elaborate on this point, if the function has a complex derivative
(i.e. it is analytic),
then the complex derivative f'(z) = \partial f /  \partial x. So to
calculate a complex derivative
with respect to z=x+i*y, we just need to differentiate with respect to x.

It can be shown, that the Wirtinger derivatives df/dz is equal to
\partial f /  \partial x for analytic functions,
i.e. when df/d conjugate(z) = 0.

So in a CAS, we can simply define the derivative f'(z) as \partial f /
\partial x for any function, even if it doesn't have a complex
derivative.
For any function we can show that:

\partial f / \partial x = d f / d z + d f / d conjugate(z)

Bill, is this what you call the total Wirtinger derivative?

For example, for |z| we get:

|z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d
conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z|

Using our definition, this holds for any complex z. Then, if z is
real, we get:

|z|' = z / |z|

Which is exactly the usual real derivative. Bill, is this what you had
in mind? That a CAS could return the derivative of abs(z)
as Re(z) / abs(z) ?

Ondrej


 So for analytic functions, Wirtinger derivative gives the same answer
 as Mathematica. For non-analytic functions, Mathematica leaves it
 unevaluated, but Wirtinger derivative gives you something.

 How do you calculate the total Wirtinger derivative? How is that defined?

 Because I would like to get

 d|x| / d x = x / |x|

 for real x. And I don't see currently how is this formula connected to
 Wirtinger derivatives. Finally, the derivative operator in a CAS could
 return Wirtinger derivatives, I think it's a great idea, if somehow we
 can recover the usual formula for abs(x) with real x.

 What are the cons of this approach?

 Ondrej

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Thu, Nov 13, 2014 at 6:56 PM, Bill Page bill.p...@newsynthesis.org wrote:
 Sorry, I hit send before I was quite ready.  To continue ...

 On 13 November 2014 19:24, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Thu, Nov 13, 2014 at 2:00 PM, Ondřej Čertík ondrej.cer...@gmail.com 
 wrote:
 ...
 For example, for |z| we get:

 |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d
 conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z|

 Using our definition, this holds for any complex z. Then, if z
 is real, we get:

 |z|' = z / |z|

 Which is exactly the usual real derivative. Bill, is this what you
 had in mind? That a CAS could return the derivative of abs(z)
 as Re(z) / abs(z) ?


 Yes, exactly.  I think a question might arise whether we should treat
 conjugate or Re as elementary.

Ok, thanks for the confirmation.

There is an issue though --- since |z| is not analytic, the
derivatives depend on the direction. So along x you get


 ...
 What are the cons of this approach?


 First, care needs to be taken to properly extend the chain rule to
 include the conjugate Wirtinger derivative where necessary.

 Second, in principle problems can arise when defining a test for
 constant functions.  For example this is necessary as part of
 rewriting expressions in terms of the smallest number of elementary
 functions (normalize) as a kind of zero test for expressions in
 FriCAS/Axiom. Usually we assume that

   df(x)/dx = 0

 is necessary and sufficient for f to be a constant function.  But
 requiring that the total derivative

   d f / d z + d f / d conjugate(z) = 0

 is not what we mean by constant. In fact it seems to be an open
 question whether Richardson's theorem can be extended to include
 conjugate as an elementary function in such a way that the zero test
 is still computable. This is the last point of discussion on the
 FriCAS email list.

 Bill.

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

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

Re: [sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

On Fri, Nov 14, 2014 at 12:14 AM, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Thu, Nov 13, 2014 at 6:56 PM, Bill Page bill.p...@newsynthesis.org wrote:
 Sorry, I hit send before I was quite ready.  To continue ...

 On 13 November 2014 19:24, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Thu, Nov 13, 2014 at 2:00 PM, Ondřej Čertík ondrej.cer...@gmail.com 
 wrote:
 ...
 For example, for |z| we get:

 |z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d
 conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z|

 Using our definition, this holds for any complex z. Then, if z
 is real, we get:

 |z|' = z / |z|

 Which is exactly the usual real derivative. Bill, is this what you
 had in mind? That a CAS could return the derivative of abs(z)
 as Re(z) / abs(z) ?


 Yes, exactly.  I think a question might arise whether we should treat
 conjugate or Re as elementary.

 Ok, thanks for the confirmation.

 There is an issue though --- since |z| is not analytic, the
 derivatives depend on the direction. So along x you get

Sorry, a bug in gmail sent the message

along x you get:

|z|' = \partial |z| / \partial x = d |z| / d z + d |z| / d
 conjugate(z) = conjugate(z) / (2*|z|) + z / (2*|z|) = Re(z) / |z|

but along y you get:

|z|' = \partial |z| / \partial i*y = d |z| / d z - d |z| / d
 conjugate(z) = conjugate(z) / (2*|z|) - z / (2*|z|) = i*Im(z) / |z|

So I get something completely different. So which direction should be preferred
in the CAS convention and why?

Ondrej



 ...
 What are the cons of this approach?


 First, care needs to be taken to properly extend the chain rule to
 include the conjugate Wirtinger derivative where necessary.

 Second, in principle problems can arise when defining a test for
 constant functions.  For example this is necessary as part of
 rewriting expressions in terms of the smallest number of elementary
 functions (normalize) as a kind of zero test for expressions in
 FriCAS/Axiom. Usually we assume that

   df(x)/dx = 0

 is necessary and sufficient for f to be a constant function.  But
 requiring that the total derivative

   d f / d z + d f / d conjugate(z) = 0

 is not what we mean by constant. In fact it seems to be an open
 question whether Richardson's theorem can be extended to include
 conjugate as an elementary function in such a way that the zero test
 is still computable. This is the last point of discussion on the
 FriCAS email list.

 Bill.

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

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

[sage-devel] Bug in abs(I*x).diff(x)

[Ondřej Čertík]

Hi,

With Sage 6.3, I am getting:

sage: abs(x).diff(x)
x/abs(x)
sage: abs(I*x).diff(x)
-x/abs(I*x)

But abs(I*x) == abs(x). So also abs(x).diff(x) and abs(I*x).diff(x)
must be the same. But in the first case we get x/abs(x), and in the
second we got -x/abs(x).

In SymPy, the answer is:

In [1]: abs(x).diff(x)
Out[1]:
  d d
re(x)⋅──(re(x)) + im(x)⋅──(im(x))
  dxdx
─
   │x│


In [2]: x = Symbol(x, real=True)

In [3]: abs(x).diff(x)
Out[3]: sign(x)

In [4]: abs(I*x).diff(x)
Out[4]: sign(x)

In [26]: var(x)
Out[26]: x

Which seems all correct --- in the complex case [1] we get a little
messy expression, but a correct one. For a real case, we get the
correct answer.

In Wolfram Alpha, the answer of abs(I*x).diff(x) is x/abs(x):

http://www.wolframalpha.com/input/?i=Diff%5BAbs%5Bi*x%5D%2C+x%5D

Which is only correct for real x, but at least it is correct for
this special case.

The Sage result seems wrong for any x.

Ondrej

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

Re: [sage-devel] Re: How to simplify square roots

[Ondřej Čertík]

Thanks Volker for the tip, that does the job. More comments below:

On Sun, Jun 29, 2014 at 11:52 PM, John Cremona john.crem...@gmail.com wrote:
 Be careful though:

 sage: (sqrt(-2)*sqrt(-3)).simplify_radical()
 -sqrt(3)*sqrt(2)

 i.e. you cannot use sqrt(a)*sqrt(b)=sqrt(a*b) everywhere without
 reaching a contradiction.

 sage: bool( (sqrt(-2)*sqrt(-3)) == sqrt(2)*sqrt(3) )
 False

Right, e.g. in sympy:

 sqrt(-2)*sqrt(-3)
-sqrt(6)


Coming to the original example, sympy returns

 sqrt(3)/sqrt(15)
sqrt(5)/5

And Mathematica returns 1/sqrt(5).


Here is a more difficult example, in SymPy:

 2**(S(1)/3) * 6**(S(1)/4)
2**(7/12)*3**(1/4)

Mathematica returns the same thing. Sage, on the other hand, does not
simplify this:

sage: 2**(1/3) * 6**(1/4)
6^(1/4)*2^(1/3)
sage: _.rational_simplify()
6^(1/4)*2^(1/3)


What is interesting though, is that Sage does perform some
factorization automatically, e.g.:

sage: sqrt(12)
2*sqrt(3)

Mathematica and SymPy do the same here.

Here is even better example, in Sage:

sage: sqrt(12)/sqrt(6)
1/3*sqrt(6)*sqrt(3)
sage: _.rational_simplify()
1/3*sqrt(6)*sqrt(3)

SymPy or Mathematica:

 sqrt(12)/sqrt(6)
sqrt(2)

So the Sage rule seems to be --- factorize simple sqrt(N) into the
form a*sqrt(b), do this for all sqrt() in the expression, and then
just convert 1/sqrt(n) - sqrt(n)/n, and return the result, after
canceling common factors.

I think a better rule is to either

a) factor everything, like SymPy or Mathematica
2) do not factor anything, and just leave sqrt(12)/sqrt(6) as is. Then
rational_simplify() should return the result from a).

Ondrej

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

Re: [sage-devel] Re: How to simplify square roots

[Ondřej Čertík]

On Mon, Jun 30, 2014 at 11:23 AM, William Stein wst...@gmail.com wrote:
 On Mon, Jun 30, 2014 at 9:29 AM, Ondřej Čertík ondrej.cer...@gmail.com 
 wrote:
 Thanks Volker for the tip, that does the job. More comments below:

 Another comment.  Evidently Sage uses **Maxima** for
 rational_simplify, hence the integer factorization that is required to
 do this is not-surprisingly insanely stupidly slow, by modern
 standards:

 sage: p = next_prime(10^10); q = next_prime(10^11)
 sage: a = sqrt(p^2*q)/p
 sage: %time a.rational_simplify()
 1/119*sqrt(1383003724001083)
 CPU time: 1.12 s, Wall time: 3.52 s

More importantly, the result is not simplified...

 sage: %time factor(p^2*q)
 119^2 * 1003
 CPU time: 0.00 s, Wall time: 0.03 s

 Don't even try increasing the size of p, q above... or it'll take forever.

Btw, Mathematica always returns sqrt(1003) and it seems to
cancel p no matter how large p and q is (I assume it puts 1/p into
the sqrt() and simplifies the rational).
However, in Mathematica, sqrt(12)  gets simplified to 2*sqrt(3). But
sqrt(p*q) returns as
sqrt(119357). So Mathematica seems to have a cut-off, after
which it won't attempt the factorization.

In SymPy, we have a cut-off as well, but unlike Mathematica, we don't
seem to be able to factorize
it either for larger p, q, e.g.:

In [21]: p = 19

In [22]: q = 31

In [23]: sqrt(p**2*q)/p
sqrt(31)


But:

In [18]: p = 119

In [19]: q = 1003

In [20]: sqrt(p**2*q)/p
sqrt(1383003724001083)/119


 We should maybe consider sometime make our rational_simplify first
 factor or something (I don't know), so it can leverage sage's much
 better integer factorization code.

Btw, in csympy we started using a very fast primesieve library
(http://primesieve.org/).
It's only for generating the primes (and only up to 10^9), but it
might be the fastest library out there.

Ondrej

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

[sage-devel] How to simplify square roots

[Ondřej Čertík]

Hi,

How do I simplify the following:

sage: sqrt(3)/sqrt(15)
1/15*sqrt(15)*sqrt(3)
sage: simplify(_)
1/15*sqrt(15)*sqrt(3)

With sympy one gets:

 sqrt(3)/sqrt(15)
sqrt(5)/5

The reason I am asking is that we are designing a very fast core in
C++ (https://github.com/sympy/csympy) and so far we can't figure out a
fast way to do the full SymPy like simplification. The rule for Sage
(GiNaC?) simplification seems to be: convert expressions of the form
1/sqrt(2), 1/sqrt(15) into 1/2*sqrt(2), 1/15*sqrt(15), then collect
all integers, and leave the square roots as is, i.e. do not attempt
any integer factorization (in or outside of the square root). This we
know how to implement fast I think.

So I would like to know which function you can later use to do the
full simplification.
And also if you run into any issues with the current Sage behavior (I
used Sage Version 6.2.rc2, Release Date: 2014-05-04).

Many thanks for any feedback,
Ondrej

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

Re: [sage-devel] Re: RFC: New Build/Packaging System

[Ondřej Čertík]

Hi Volker,

Thanks for considering hashdist. Few comments:

On Tue, Jun 17, 2014 at 8:33 AM, Volker Braun vbraun.n...@gmail.com wrote:
 I've spent some time looking at hashdist which is probably the closest to
 what we need, but I don't think its the way to go for us right now. First,
 Sage depends on the LD_LIBRARY_PATH hack on too many places. Before that is
 fixed its hard to do anything with a real package management system.

We currently use RPATH, and plan to move to $ORIGIN, so that the build
is relocatable.

https://github.com/hashdist/hashdist/issues/13

But $ORIGIN is not implemented yet. This is another show stopper, as
Sage needs to be relocatable.

 At the
 same time, hashdist isn't ready. Its version 0.2, which is incompatible to
 0.1,

Yes, it is important to get the design right, and sometimes it is not
backwards compatible. That will obviously improve.

 there is no documentation for writing builder plugins / API.

I created an issue for it:

https://github.com/hashdist/hashdist/issues/247

But can you please clarify what you mean by builder plugin?

 And much
 of the source is, let's say, lightly documented with doctests being almost
 completely absent.

https://github.com/hashdist/hashdist/issues/248

 And no parallel build support,

https://github.com/hashdist/hashdist/issues/246

 ... But in the future we
 should definitely reconsider that, when these issues have been addressed on
 both sides.

Thank you for giving us feedback. I have marked all these issues with sage,
so that you can conveniently view them at one place:

https://github.com/hashdist/hashdist/issues?labels=sage

Is there anything else missing?


 What I don't like in hashdist is that the packages don't have a clear
 backing as Python classes in the code, which is related to not being able to
 customize the heck out of it. There is the school of thought that says you
 shouldn't be allowed to do anything that doesn't lead to provably correct
 hash-build maps, and everything must be stateless functional. Thats nice if
 you want a package manager for end users only, but that is IMHO not good
 enough for development purposes. I'd rather have to do an occasional make
 clean than an extra 10k file ops every time I test a change. Fundamentally,
 what does a package define? Its how to get the source code, the version of
 the source code, and how to turn the source into a binary. Right now,
 hashdist packages only have a hook into the third part. Why can't we
 override how hashing works, or where to get the source from? Yes that might
 allow you to break the promise of provably correct builds, but we are all
 adults here. As long as you build stuff in my home directory I ought to be
 able to break anything I want.

So what you are missing is that you want to modify one line in openssl,
and you know that it won't change anything in the other 50+ packages
that depend on it
(e.g. Python, numpy, scipy, ...), so you want to be able to simply
build openssl,
but keep the hash, so that it does not trigger a rebuild of the rest
of the stack?

Or also something else?


 Not only is package == builder Python object a clear API to override all
 aspects of the package build, you then can't help yourself but load them all
 into an IPython session. I found that to be a really nice mechanism to debug
 and explore the whole packaging:


 $ ./build/manager/sage-pkg shell
 Python 2.7.5 (default, Feb 19 2014, 13:47:28)
 Type copyright, credits or license for more information.

 IPython 0.13.2 -- An enhanced Interactive Python.
 ? - Introduction and overview of IPython's features.
 %quickref - Quick reference.
 help  - Python's own help system.
 object?   - Details about 'object', use 'object??' for extra details.
 Loaded packages: atlas, autotools, boehm_gc, boost_cropped, bzip2, cddlib,
 cephes, cliquer, configure, conway_polynomials, cryptominisat, cvxopt,
 cython, database_cremona_ellcurve, database_gap, database_stein_watkins,
 database_stein_watkins_mini, database_symbolic_data, dateutil, docutils,
 dot2tex, ecl, eclib, ecm, elliptic_curves, fflas_ffpack, flint, flintqs,
 freetype, gap, gap_packages, gcc, gd, gdmodule, genus2reduction, gf2x, gfan,
 git, git_trac, givaro, glpk, gmp, graphs, gsl, iconv, iml, ipython, jinja2,
 jmol, lcalc, libfplll, libgap, libm4ri, libm4rie, libogg, libpng, libtheora,
 linbox, lrcalc, matplotlib, maxima, mcqd, mercurial, mpc, mpfi, mpfr, mpir,
 mpmath, ncurses, networkx, ntl, numpy, openssl, palp, pari, pari_galdata,
 pari_seadata_small, patch, pexpect, pillow, pkgconf, pkgconfig, polybori,
 polytopes_db, ppl, pycrypto, pygments, pynac, pyparsing, python, r,
 ratpoints, readline, rpy2, rubiks, sage_c_library, sage_mode, sage_noarch,
 sage_python_library, sagenb, sagetex, scipy, scons, setuptools, singular,
 six, sphinx, sqlalchemy, sqlite, symmetrica, sympow, sympy, tachyon,
 termcap, topcom, tornado, zlib, zn_poly

 In [1]: ppl.config
 Out[1]:
 Configuration:
 - config.builder.check_script = 

Re: [sage-devel] RFC: New Build/Packaging System

[Ondřej Čertík]

Hi Volker,

I was also pointed to this thread. Aron answered pretty much
everything, so just a few comments:

On Mon, Jun 16, 2014 at 11:49 AM, Volker Braun vbraun.n...@gmail.com wrote:
 For the record, Sage build a lot slower to build if you build packages one
 after the other.

 So hashdist packages can sort of change how they are built by inheriting
 (extends:). But can we override / extend:
 * source download (to use the Sage mirror network)

Yes. You just modify the url field to your own mirror. Assuming you
didn't modify the tarball,
you don't need to modify the hash. If you modified the tarball, then
you need to update the hash.

 * the hash computation for the source?

There is hash computation to verify the tarball, e.g.:

sources:
  - url: http://archive.ipython.org/release/2.0.0/ipython-2.0.0.tar.gz
key: tar.gz:j2b4bd4nn7iorbemnd6a5mxzwbkptn2c


But the hash that comes into the build is computed from a json input
script, that contains
this source key, then the script that builds the package, then any
dependencies etc.

 What if I want to install
 files/directories directly from the repository?

Could you clarify this question a bit? I am not sure what exactly you
are asking.

 Is there a way to skip the Nix versioned directories stuff and instead just
 install directly into the destination tree? Because thats what we do now,

So we create a profile from these versioned directories, which you can
view as a destination tree.
They contain hardlinks into versioned directories. You use the
destination tree just like a Sage tree.

 and changing the build system and 50 package build scripts at the same time
 is not really feasible.

We plan to eventually port packages that Sage uses. We've already
ported quite a few relevant packages,
e.g.:

https://github.com/hashdist/hashstack/blob/master/pkgs/linbox.yaml
https://github.com/hashdist/hashstack/blob/master/pkgs/ntl.yaml
https://github.com/hashdist/hashstack/blob/master/pkgs/flint.yaml

and more will come in the future. Essentially anyone can just send a PR:

https://github.com/hashdist/hashstack/pulls

Ondrej

P.S. We now also have a more fancy web page: https://hashdist.github.io/

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

Re: [sage-devel] RFC: New Build/Packaging System

[Ondřej Čertík]

On Mon, Jun 16, 2014 at 12:20 PM, Volker Braun vbraun.n...@gmail.com wrote:
 On Monday, June 16, 2014 7:04:51 PM UTC+1, Ondřej Čertík wrote:

 Yes. You just modify the url field to your own mirror.


 No. I know that I want to download xyz.tar.gz, and I have a list of sage
 mirrors ranked by speed, and I want to download from the fastest one.

I don't think we support this yet. Essentially you would have some
path postfix, but then
you want to change the mirror at one place, and all the packages would
be downloaded
from this mirror?


  What if I want to install
  files/directories directly from the repository?


 Could you clarify this question a bit? I am not sure what exactly you
 are asking.


 I want to install part of Sage (say, under src/c_lib) as a package of the
 build process. How do I do that without creating a tarball? I have a unique
 hash, namely the git tree blob SHA1 for src/c_lib.

Ah, from a git repository? That's easy, you just use the git hash, see e.g.:

https://github.com/hashdist/hashstack/blob/master/pkgs/ginac.yaml

sources:
- url: git://www.ginac.de/ginac.git
  key: git:edfa67d26bac695b5ef9911f3cda3ff50232e35a

And you can use local path as well, e.g.:

sources:
- url: /nh/nest/u/ondrej/repos/ginac
  key: git:edfa67d26bac695b5ef9911f3cda3ff50232e35a


Ondrej

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

Re: [sage-devel] RFC: New Build/Packaging System

[Ondřej Čertík]

On Mon, Jun 16, 2014 at 1:09 PM, Aron Ahmadia a...@ahmadia.net wrote:

 On Mon, Jun 16, 2014 at 3:07 PM, Volker Braun vbraun.n...@gmail.com wrote:

 In particular its not possible to build from the already-existing git
 repo? I don't want to have to specify the version of sage-the-library, I
 just want to build it out of the source tree. The version is the git tree
 sha1 if the tree is clean, and random / file checksum if not clean. At the
 same time there we have at least one package that depends on Sage being able
 to start, so we need to integrate sage in our package management.


 I'm working on a feature similar to what you're asking for this week.  I'm
 programmatically using the functionality in `git stash` to create a commit
 of the current working tree before launching the build.  It's not
 implemented on anything besides napkins yet, though :)

The actual command is git stash create, which will not modify any of
your source files,
i.e. if you have uncommitted changes, but returns a hash of a stash
commit, that can then
be used in hashdist.

Volker, my understanding is that this would be useful for developing a
package, to be able to quickly
run a build, without committing. But for the end user, you always want
to build from some commit.

I.e. if I am developing my own library, I would first put it into
hashdist (with url to github), and then when developing
a new version, I change the url to my local checkout, and I want be
able to quickly check that it installs and works,
so then I would use this feature.

Ondrej

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

Re: [sage-devel] RFC: New Build/Packaging System

[Ondřej Čertík]

On Mon, Jun 16, 2014 at 1:59 PM, Volker Braun vbraun.n...@gmail.com wrote:
 On Monday, June 16, 2014 8:40:34 PM UTC+1, Ondřej Čertík wrote:

 Volker, my understanding is that this would be useful for developing a
 package, to be able to quickly
 run a build, without committing. But for the end user, you always want
 to build from some commit.


 Yes, I agree. But our primary aim here is reduce development turnaround
 time.

Definitely. I just wanted to clarify this. I've wanted this feature
for a long time too, when developing.

Ondrej

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

[sage-devel] Best library for integer factorization (ecmfactor and the B1 parameter)

[Ondřej Čertík]

Hi,

What is the state of the art library for factoring integers?
I was under the impression, that it is the GCM-ECM library
(http://ecm.gforge.inria.fr/).

I've been trying to use ECM and I noticed the following behavior:

sage: from sage.libs.libecm import ecmfactor
sage: N = 121
sage: factor(N)
11^2
sage: ecmfactor(N, 1)
(True, 121)
sage: ecmfactor(N, 100)
(True, 121)
sage: ecmfactor(N, 200)
(True, 121)
sage: ecmfactor(N, 0)
(True, 121)
sage: ecmfactor(N, 0.)
(True, 11)


In other words, it never finds the factor 11, unless you give it B1=0.0

Compared to N=122, where it always finds it:

sage: N = 122
sage: factor(N)
2 * 61
sage: ecmfactor(N, 1)
(True, 2)
sage: ecmfactor(N, 100)
(True, 2)
sage: ecmfactor(N, 200)
(True, 2)


I have a few questions:

* Does this mean that ECM only works sometimes?
* Is there a parameter B1, that always works?

In the README file of the ecm-6.4.4 package, I found:

   digits D  optimal B1   default B2   expected curves
   N(B1,B2,D)
  -power 1 default poly
  20   11e3 1.9e6 74   74 [x^1]
  255e4 1.3e7221  214 [x^2]
  30   25e4 1.3e8453  430 [D(3)]
  351e6 1.0e9984  904 [D(6)]
  403e6 5.7e9   2541 2350 [D(6)]
  45   11e63.5e10   4949 4480 [D(12)]
  50   43e62.4e11   8266 7553 [D(12)]
  55   11e77.8e11  2015817769 [D(30)]
  60   26e73.2e12  4717342017 [D(30)]
  65   85e71.6e13  7766669408 [D(30)]

  Table 1: optimal B1 and expected number of curves to find a
  factor of D digits with GMP-ECM.

The only documentation about ECM that I found in Sage is this:

http://www.sagemath.org/doc/bordeaux_2008/integer_factorization.html
http://www.sagemath.org/doc/reference/libs/sage/libs/libecm.html

But it doesn't answer my questions above.
If the answer is that ECM only works sometimes, but it's not a
reliable way to factor integers, what is the fastest library that
always works?

Many thanks,
Ondrej

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

Re: [sage-devel] Re: Best library for integer factorization (ecmfactor and the B1 parameter)

[Ondřej Čertík]

Hi Volker,

I see. So is my understanding correct, that the proper usage of the
ECM is as follows:

1. Determine if N is prime, using pari(N).ispseudoprime(). The
standard conjecture is that there exist infinitely many
counterexamples, even though no single one is known.

2. If N is not prime, lookup the proper B1 using the table I posted.

3. Keep calling ecmfactor() until it gives you a factor. It must give
you a factor eventually.

?

Ondrej

On Thu, Jan 30, 2014 at 12:04 PM, Volker Braun vbraun.n...@gmail.com wrote:
 Just calling ecmfactor from the innards of the ecm library is just trying
 one elliptic curve (see the docs). This is not going to be really useful by
 itself.

 sage: ecm.factor(121)
 [11, 11]

 Relevant discussion at http://trac.sagemath.org/ticket/15443




 On Thursday, January 30, 2014 6:35:46 PM UTC, Ondřej Čertík wrote:

 Hi,

 What is the state of the art library for factoring integers?
 I was under the impression, that it is the GCM-ECM library
 (http://ecm.gforge.inria.fr/).

 I've been trying to use ECM and I noticed the following behavior:

 sage: from sage.libs.libecm import ecmfactor
 sage: N = 121
 sage: factor(N)
 11^2
 sage: ecmfactor(N, 1)
 (True, 121)
 sage: ecmfactor(N, 100)
 (True, 121)
 sage: ecmfactor(N, 200)
 (True, 121)
 sage: ecmfactor(N, 0)
 (True, 121)
 sage: ecmfactor(N, 0.)
 (True, 11)


 In other words, it never finds the factor 11, unless you give it B1=0.0

 Compared to N=122, where it always finds it:

 sage: N = 122
 sage: factor(N)
 2 * 61
 sage: ecmfactor(N, 1)
 (True, 2)
 sage: ecmfactor(N, 100)
 (True, 2)
 sage: ecmfactor(N, 200)
 (True, 2)


 I have a few questions:

 * Does this mean that ECM only works sometimes?
 * Is there a parameter B1, that always works?

 In the README file of the ecm-6.4.4 package, I found:

digits D  optimal B1   default B2   expected curves
N(B1,B2,D)
   -power 1 default
 poly
   20   11e3 1.9e6 74   74
 [x^1]
   255e4 1.3e7221  214
 [x^2]
   30   25e4 1.3e8453  430
 [D(3)]
   351e6 1.0e9984  904
 [D(6)]
   403e6 5.7e9   2541 2350
 [D(6)]
   45   11e63.5e10   4949 4480
 [D(12)]
   50   43e62.4e11   8266 7553
 [D(12)]
   55   11e77.8e11  2015817769
 [D(30)]
   60   26e73.2e12  4717342017
 [D(30)]
   65   85e71.6e13  7766669408
 [D(30)]

   Table 1: optimal B1 and expected number of curves to find a
   factor of D digits with GMP-ECM.

 The only documentation about ECM that I found in Sage is this:

 http://www.sagemath.org/doc/bordeaux_2008/integer_factorization.html
 http://www.sagemath.org/doc/reference/libs/sage/libs/libecm.html

 But it doesn't answer my questions above.
 If the answer is that ECM only works sometimes, but it's not a
 reliable way to factor integers, what is the fastest library that
 always works?

 Many thanks,
 Ondrej

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

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

Re: [sage-devel] Should the Sage manual mention SageMathCloud?

[Ondřej Čertík]

On Wed, Oct 16, 2013 at 1:07 AM, Robert Bradshaw rober...@gmail.com wrote:
 On Sun, Oct 13, 2013 at 2:26 PM, William Stein wst...@gmail.com wrote:
 On Sun, Oct 13, 2013 at 1:16 PM, Vincent Delecroix
 20100.delecr...@gmail.com wrote:
 thought was that Sage is a math software, open source, with the aim of
 being a viable alternative to Ma*. There was no mention of a cloud
 which is just the incompatible with the open source project (as the
 FSF defines it).

 Why do you think that the existence of a cloud that provides an
 additional way to use Sage is compatible with Sage being an open
 source project?To me that's no different than claiming that the
 existence of websites running on servers running Linux is incompatible
 with Linux being an open source project.

 My very personal opinion is that the cloud is a bad
 way of making Sage popular: it makes the users dependent of a service.

 If good = not dependent  and bad = dependent, then indeed it is
 bad.  I do not define good and bad that way.   I'm more concerned with
 providing valuable services to people, making it easier for people to
 get work done, and providing ways to collaborate.   I want to grow the
 community of users of open source math software, and I'm probably not
 the first person to realize that a website-based approach is a
 powerful tool for addressing some of these goals.

 Up to now, I learned a lot with Sage and I hope that I contributed
 equivalently on teaching with it, going to Sage days, contributing
 with my code, etc. Sage was for me part of the public domain. If the
 cloud really becomes the main way of using Sage it will be for me like
 a dispossession. The cloud implies
  - the obligation of using the cloud to share code
  - no control on the execution of the softwares
  - no direct access to the source code
  - no way to use your own editor

 These are all valid concerns for anybody choosing whether or not to
 use Sage (or anything else) via any computer that isn't their own
 personal computer.  Even if a large number of people were to someday
 use Sage via the cloud, this doesn't mean that everybody does.  You
 can -- and will *always* be able to -- use Sage in any way you want
 (compatible with the GPL). If many more people are using Sage (in
 any way, cloud or not), then the number of contributions to Sage
 itself will increase, the quality of Sage goes up, getting support for
 Sage development gets easier, etc., which will mean that your personal
 cloud-free use of Sage will be improved.   Everybody wins in the Sage
 community wins.   User attention is a zero-sum game (unless there are
 new markets), so somebody has to loose in this scenario--it isn't us
 Sage users -- it's the Ma*'s.

 I actually don't think it's a zero-sum game; I'm hopeful Sage can also
 be useful to people who otherwise wouldn't even use a computer to do
 mathematics, and convenient/helpful enough for people to use computers
 for this kind of work even more. In other words, making the total pie
 bigger. Being a viable alternative to the Ma*s is at least as
 important to those who don't/can't have access to them as to those who
 do.

I view it the same way.


 It's worth pointing out that there is a risk here for cloud-free
 Sage. What you haven't done is clearly outline what part of the cloud
 product will be open and what parts won't be. At the one extreme, all
 the source, configuration, etc. is open and the value-add of the
 sagemath.com is a professionally-administered hosting with lots of
 hardware and support (which, yes, anyone could clone and try to
 compete with, though the original that devotes its profits to the
 improvement of Sage should attract the best/most devoted employees
 and, consequently, offer the best support). At the other end is a very
 closed system where bug-fixes and improvements to core Sage itself are
 withheld from the public version (which could be legal according to
 the GPL, if you're just distributing results, not code). My
 understanding is that the sagemath cloud won't live at either of these
 extremes, but I would consider it sad if peripheral things like the UI
 or better 3d graphics and interacts never made it out to the open
 source project.

 There's also the concern of lock-in. Ideally, a notebook could be
 created on the cloud, downloaded and run in a cloud-free way (say,
 on an airplane w/o internet, or on your department's latest hardware
 dedicated to your research, or over data to sensitive to trust to the
 cloud), then even re-uploaded. Delineating a concrete goal here would
 be good.

Cloud.sage now supports the IPython notebook, which has zero lock-in.
You can run exactly the same notebook locally, without internet access
(assuming of course that you have all the dependencies installed).

Before sage.cloud and ipython notebook a few years ago, even though I
really liked
the Sage notebook, it was only used for Sage, and so the community didn't
grow beyond it. I tried to disentangle it (with 

Re: [sage-devel] numpy 1.7.0 upgrade ticket is ready for review

[Ondřej Čertík]

On Fri, Mar 22, 2013 at 10:24 AM, Francois Bissey
francois.bis...@canterbury.ac.nz wrote:
 After much time spent finding why numpy 1.6.x didn't like sage
 and some nice cooperation with numpy upstream we have an upgrade path
 for numpy. It couldn't have happened before the merging of the new
 doctest framework. Numpy 1.7.0 exposed at least one instance where
 the old one was broken.
 So http://trac.sagemath.org/sage_trac/ticket/11334 is now ready for
 review on top of sage-5.9.beta0 or later.

Please let us know if you run into any problems with numpy 1.7.0.

Ondrej

P.S. I think you should switch to github or bitbucket with Sage for
pull requests, it's so much easier for somebody like me to see what
the ticket #11334 is doing. The way I am doing it is to click on each
patch one by one and try to remember the total changes in my head to
see if it makes sense as a whole.

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sage-devel] Re: Access to SPARC 64

[Ondřej Čertík]

On Fri, Nov 16, 2012 at 12:08 PM, Fernando Perez fperez@gmail.com wrote:
 Hi Ondrej,

 On Thu, Nov 15, 2012 at 8:42 AM, Dima Pasechnik dimp...@gmail.com wrote:
 There are such machines on skynet, e.g. mark.
 -bash-3.00$ uname -a
 SunOS mark 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500
 -bash-3.00$ isainfo -b
 64

 skynet may be a good solution, I figured I'd just also mention the GCC
 compile farm as an option too:

 http://gcc.gnu.org/wiki/CompileFarm

 From their description, numpy qualifies for access and they have a
 very wide array of hardware/OS combinations.  But I've never used it
 myself, so I don't know if in practice it's a good solution or not.

Thanks Fernando and Dima. I have just applied to the compile farm
and also wrote to William.

Ondrej

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

[sage-devel] Access to SPARC 64

[Ondřej Čertík]

Hi,

I am a release manager for the next NumPy release (1.7) and we have
one bug that only shows
on SPARC 64, see below for details.

Is there anyone who would be willing and able to give me an access to
such a machine so that I can debug it?
Jason recommended to ask on the Sage list. I am BCCing the NumPy list.

Any help would be greatly appreciated.

Thanks,
Ondrej

On Thu, Aug 30, 2012 at 8:21 PM, Jason Grout
jason-s...@creativetrax.com wrote:
 On 8/30/12 10:10 PM, Ondřej Čertík wrote:
 Hi,

 Does anyone have a SPARC 64 machine that I could have an access to, so
 that I can try to reproduce and fix the following issue?

 http://projects.scipy.org/numpy/ticket/2076

 That would be greatly appreciated, as it is currently marked as a
 blocker for 1.7.0.


 You might ask on sage-devel.  They were just talking about SPARC
 machines the other day on sage-devel.

 Thanks,

 Jason


 ___
 NumPy-Discussion mailing list
 numpy-discuss...@scipy.org
 http://mail.scipy.org/mailman/listinfo/numpy-discussion

-- 
You received this message because you are subscribed to the Google Groups 
sage-devel group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to 
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.

Re: [sage-devel] GCC package (#12369) needs review

[Ondřej Čertík]

On Tue, Apr 10, 2012 at 3:26 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
 On 2012-04-10 11:46, Ondřej Čertík wrote:
 What is your opinion on this thread:

 https://groups.google.com/d/msg/sage-devel/9CBKLU6LYkU/HNhJBKJ45VMJ
 What do you mean specifically?  It's a long thread, many things are
 discussed...

Ah, maybe the link went to a wrong email. I meant the email by Georg S. Weber
which says:


the approach to include our own GCC 4.5.1 is doomed to fail.


and explains why, to which William replied I think you really know
what you're talking about..

And since you did it and it seems to work, it seems that it is not
doomed to fail. So
that's why I was curious if you have any opinions on this discrepancy.


 In your experience is there
 any problem with simply building gcc from scratch (when needed)?
 That's exactly what's done in the latest beta: sage-5.0.beta13.  There
 are a few issues here and there, but nothing too serious it seems.

Cool.

Ondrej

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] GCC package (#12369) needs review

[Ondřej Čertík]

Hi Jeroen,

On Sun, Mar 11, 2012 at 2:56 PM, Jeroen Demeyer jdeme...@cage.ugent.be wrote:
 I have made a spkg for GCC (GNU compiler collection) version 4.6.3 with
 compilers for C, C++ and Fortran.  We don't always build GCC, by default
 only on systems where this is needed or which have an old GCC version.

 The main motivation for this ticket was to make Sage work on OS X 10.7.
  But I think that having a GCC spkg is good for porting in general.  It
 should also slightly increase Sage run-time performance for people with
 older compilers.  The review of this package should not focus on OS X 10.7.

 To make reviewing this ticket more easy, I have made some testing
 releases, see the ticket #12369 for details.  As far as I know, on every
 system on which sage-5.0.beta7 vanilla works, the testing release with
 GCC also works.

Thanks, this is awesome. I was trying to create a gfortran package
about two years ago, so that I obtain a gfortran binary on a Mac,
but only managed to get it to compile on Linux, not Mac. So
I decided to ship a binary, but this is much better. I see
that you figured out lots of things in the spkg-install.

What is your opinion on this thread:

https://groups.google.com/d/msg/sage-devel/9CBKLU6LYkU/HNhJBKJ45VMJ

which has discouraged me to pursue this path further. I am glad
that you pushed this through. In your experience is there
any problem with simply building gcc from scratch (when needed)?

Ondrej

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: MathICS: A free, light-weight (online) alternative to Mathematica with support for Sage

[Ondřej Čertík]

On Sat, Mar 31, 2012 at 2:01 PM, William Stein wst...@gmail.com wrote:
 On Sat, Mar 31, 2012 at 9:35 PM, leif not.rea...@online.de wrote:
 On 31 Mrz., 22:13, Volker Braun vbraun.n...@gmail.com wrote:
 On Saturday, March 31, 2012 7:11:23 PM UTC+1, kcrisman wrote:

  therefore lack the “structural beauty” of the Mathematica® language.

 Well-placed irony quotation marks!

 :-)

 The core of Mathics is and shall remain independent of Sage, as it
 adds a huge footprint to the installation and Mathics should remain
 rather lightweight. In addition, it should be easier to install
 Mathics on Windows and mobile platforms where Sage is not available.
 That's why the light-weight SymPy Python package is prefered for
 advanced calculations, like integration, that will not be implemented
 in Mathics itself.

 Subject to change [Windows and mobile platforms]... (?)

 This is pretty nice.

 I used it for some basic mathematica-like stuff, and it seemed to work
 fine.  I did try an integral though:

  Integrate[Sin[x]*Cos[x+1],x]

 and I seem to be able to count to 10 before getting the answer, even
 if I retry it several times in the session.  That
 seems surprisingly slow, given:

 sage: time integrate(sin(x)*cos(x+1), x)
 -1/2*x*sin(1) - 1/4*cos(2*x + 1)
 Time: CPU 0.01 s, Wall: 0.01 s
 sage: time integrate(sin(x)*cos(x+1), x, algorithm='sympy')
 -1/2*x*sin(x + 1)*cos(x) + 1/2*x*sin(x)*cos(x + 1) + 1/2*sin(x + 1)*sin(x)
 Time: CPU 0.53 s, Wall: 0.53 s

Indeed, Maxima seems to be really fast on these integrals. Does anyone
know how Maxima does it? Does it use
some special integration algorithm for trigonometric integrals?

Ondrej

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Sage single Cell Server feedback

[Ondřej Čertík]

 * the blue line for interact (the server is computing) is not very
 intuitive for me, it took me a while to realize
 that this is what it means


 Originally we put it there since we can have nested interacts, and the blue
 line helps visually separate the nesting.  The other day I thought that it
 was confusing to see that blue line, so we'll probably remove it and try
 something different to see nested interacts.

 https://github.com/sagemath/sagecell/issues/254

Ah --- so I got it wrong. I thought that the blue line means that the
server is computing.
I didn't realize that it actually never disappears and it is there all the time.




 * sometimes it seems slow, i.e. this script:

 from sympy import var
 var(x)
 print x-x
 print x**2

 takes 5 seconds to evaluate. If you try the same thing here:
 http://live.sympy.org/,
 it is immediate.


 Can you explain the architecture behind live.sympy.org?

I think that currently it just evaluates the expressions in the given
namespace and stores (pickles) the results in a database.

But I have also experimented with a separate GAE account
that runs the engine that only evaluate the expression
and is connected to a GAE account that serves the pages.
I didn't see any big slowdown.


 The slowdown you are experiencing is (I think) because importing anything
 from sympy is sometimes horribly slow.  For example, your first line takes
 my laptop 3 seconds or so on a local copy of sage the first time I tried it.
  Do you know of a way that can be improved?  Do you know of a way we can
 preload this import without messing up the global Sage namespace?

So there must be something wrong with SymPy in Sage. With the
latest sympy git master, we have a nice script for measuring the import time:

$ bin/test_import
Note: the first run (warm up) was not included in the average + std dev
All runs (including warm up):
[2.40106582642, 0.221256017685, 0.2110009193419,
0.2103259563451, 0.2091488838199, 0.2195649147029,
0.210291862488, 0.2112379074101, 0.2108719348911,
0.2103409767149, 0.2111039161681, 0.2101390361791,
0.2114388942719, 0.211920976639, 0.2224760055539,
0.2095551490779, 0.2114191055301, 0.2248861789699,
0.2091879844669, 0.2151539325709, 0.2185208797451,
0.2102448940281, 0.209927082062, 0.2118740081791,
0.2113790512079, 0.2176508903499, 0.21023106575,
0.2108440399169, 0.2192609310149, 0.218972921371,
0.2282600402831, 0.211175918579, 0.2191729545589,
0.2290639877321, 0.2192230224611, 0.211779117584,
0.213361978531, 0.241024017334, 0.2144789695741, 0.219763040543,
0.210104942322, 0.212917089462, 0.2196609973911,
0.2263648509979, 0.215436935425, 0.2111830711359,
0.2220108509061, 0.210973024368, 0.2102708816531,
0.2176859378809, 0.2101359367371]
Number of tests: 50
The speed of import sympy is: 0.215285 +- 0.006493


This is on my slower laptop --- so it is not ideal, but ok. However,
the first run did take a long time. Note that the above
always runs the following script from scratch using python using pexpect:

from timeit import default_timer as clock
from get_sympy import path_hack
path_hack()
t = clock()
import sympy
t = clock()-t
print t

So I assume that the linux kernel caches the files that are read from
the disk. Python cannot cache anything, as it
is always run from scratch.

If you run Sage, import sympy, then close Sage, run Sage again and
import sympy, does it always take ~ 3s?





 * the interact could update immediately when dragging the spinner --
 assuming the round trip
 can be brought to around 1s.


 That would be really nice.  It would be especially nice if we used something
 like long polling or GAE channels or socket.io, where the communication
 didn't require multiple requests hammering the server.




 * I tried many of the examples from here:
 http://wiki.sagemath.org/interact (I know
 I can use the Sage notebook, but I always forget the password and so on,
 this
 cell server is much better for experimenting)


 +1.  These days, I'm opening the cell server much more often than the sage
 notebook for quick one-off calculations.  In fact, usually I use bc to do
 small arithmetic, but I find myself using the cell server more for that
 these days.

For my workflow, the cell server is the right architecture. The way I work
is that many times I just create a script in /tmp/a.py and do some
quick scripting, rather than run ipython, as I really want to
write the whole script, as opposed to just commands. If it is
more permanent script, then I have it in my computation directory
and I just modify it each time a little bit.

I also need to access files on my computer (to plot stuff for example),
so I guess eventually it would be nice to be able to easily
upload a file and access it from the single cell.


Another idea is to allow to save the cell as something like github gist.
So I would just sent you a link and you 

[sage-devel] Sage single Cell Server feedback

[Ondřej Čertík]

Hi,

I just noticed (when testing a link to sagemath.org from my webpage) the
single Cell Server:

http://sagemath.org/eval.html

so I played with it a little bit and I think this is really cool.

Here is some feedback:

* There should be more examples with interact (I would create a topic
interact)

* It is not easy to tell whether the server is computing (I tried
sympy and it freezed, so I thought that
something broke, but it was just calculating for about 5 or 10s). For
interact, there
is a blue line, so I know that it is computing.

* the blue line for interact (the server is computing) is not very
intuitive for me, it took me a while to realize
that this is what it means

* sometimes it seems slow, i.e. this script:

from sympy import var
var(x)
print x-x
print x**2

takes 5 seconds to evaluate. If you try the same thing here:
http://live.sympy.org/,
it is immediate.

* the interact could update immediately when dragging the spinner --
assuming the round trip
can be brought to around 1s.

* I tried many of the examples from here:
http://wiki.sagemath.org/interact (I know
I can use the Sage notebook, but I always forget the password and so on, this
cell server is much better for experimenting)

* sometimes the blue line seems to stay on, try for example
http://wiki.sagemath.org/interact/diffeq#Euler.27s_Method_in_one_variable


What is the current bottleneck in terms of the round trip? Is it
possible to make the interactive examples faster?


Anyway, thanks for doing this. I think this has a huge potential.

Ondrej

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

[sage-devel] Re: [sage-support] Re: public single cell server

[Ondřej Čertík]

On Sun, Jul 31, 2011 at 12:37 AM, Jason Grout
jason-s...@creativetrax.com wrote:
 On 7/29/11 5:11 PM, Jason Grout wrote:

 Hi everyone,

 I'd like to announce a trial beta run of a public single cell server:

 http://sagemath.org:5467/

 The idea is that this is a single cell that can very easily be embedded
 in any webpage. This is the start of a comprehensive Sage web service as
 well, and lays a piece of the ground work for a much more scalable model
 for doing computations in the normal notebook.

 It's ready to be hammered by the larger community at this point. I will
 be mentioning this next week at Mathfest, so please try to break it :).


 I posted a log of all commands that have been run on the singlecell server.

 http://sage.math.washington.edu/home/jason/commands.html

 Of particular note are the commands around 2011-07-31 03:03:07.436000
 (search for that string), where someone is apparently testing the security
 of the setup.  Whoever did it, how did the security and infinite loop tests
 go?

I would be interested in that too. How do you handle such infinite
loops on the server? Do you have some limit on the CPU time allowed
per evaluation?

Ondrej

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Femhub

[Ondřej Čertík]

On Fri, Jul 22, 2011 at 11:37 PM, Eviatar eviatarb...@gmail.com wrote:
 I guess by modular I meant that the different components can be
 installed separately, which is not really the case with Sage (except
 with the extra spkgs). I like the all-in-one approach better anyways
 but, like you said, there is also an advantage in the specific-use
 approach, like Sympy, NumPy, etc.

It's all about the build system (that's why I wrote a new one), the
SPKG packages in Sage are perfectly modular.

Ondrej

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Femhub

[Ondřej Čertík]

Hi Thierry,

On Thu, Jul 21, 2011 at 10:21 PM, Thierry Dumont
tdum...@math.univ-lyon1.fr wrote:
 Hello,

 I juts read that Femhub (http://code.google.com/p/femhub/ and many other
 urls) uses parts of Sage. But is there any project to integrate it in the
 Sage distribution (as optional package, for example) ?

 This would be interesting for teaching...

I did most of the work on femhub, i.e. from the femhub git repository:

$ git shortlog -ns
  275  Ondrej Certik
   84  Sameer Regmi
4  Pavel Solin
3  Brian E. Granger
1  Aayush Poudel
1  Robert Cimrman
1  root

But I am not involved with the project anymore due to irreconcilable
differences with other owners of the project (I have been, among other
things, removed from the github groups and mailinglists against my
will --- but I don't want to discuss this on the public mailinglist,
feel free to send me a private email though). As such, I have started
a new project:

http://qsnake.com/

And I'll be happy to integrate things back to Sage. I didn't announce
the Qsnake project publicly yet, because I am not happy with the web
pages yet, but I am currently busy finishing some work, and I'll get
to it probably at the end of the summer again.

Which exact things are you interested in integrating back? I'll be
happy to discuss it more.

Ondrej

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Re: [sage-devel] Re: Femhub

[Ondřej Čertík]

On Fri, Jul 22, 2011 at 6:19 PM, William Stein wst...@gmail.com wrote:
 On Fri, Jul 22, 2011 at 5:56 PM, Eviatar eviatarb...@gmail.com wrote:
 Just out of curiosity: why are you forking a separate project instead
 of developing Sage?

 I think the main issue is that Sage contains a lot of dependencies and
 code that are not needed for people doing Finite Element Method (say)
 work.  But nonetheless, there are useful ideas in how Sage is
 constructed, which Ondrej's project also benefits from.

Also so that we can quickly release a new version, update a package
and so on. Also, what I did in Qsnake is that I wrote a completely
new build system (in pure Python, as one simple file) and also I have
added a lot of new packages, not in standard Sage.
By doing it separately, I can simply create a version, that just
works. Plus I wanted to use git and github etc., as these tools make
me a lot more productive (subjective reason).

In any case, I have strictly stayed with the SPKG packages, so that
any improvements (let's say after my new packages mature) can be
incorporated in standard Sage, eventually.

So I view it as simply organizing the work, rather than a competing fork.


 As a related example, shortly after I started Sage (in 2005), Ondrej
 started Sympy (in 2006), which does symbolic calculus.   At least for
 a while, much of what Sympy did, one could do more quickly in Sage.
 That said, I just went to the app store recently and downloaded a
 program called PythonMath, which I find handy on occasion: it turns
 out PythonMath is basically Python + Sympy, which is _vastly_ easier
 to port to the iPhone than Sage.

Yes. For the kind of math that I do, in daily research (electronic
structure calculations and other quantum mechanics stuff), sympy
always worked great, and having no other depenencies than Python, it
was exactly what I always needed. For the kind of math that William
does, Sage has always worked much better. Also, sympy is just a
symbolic library (and that's it, so one has to use other libraries for
plotting, numerics, notebook...), while Sage is everything.

And thus the motivation for Qsnake --- to have a program, that
contains everything and just works. I would put Qsnake on the same
level as psage: http://purple.sagemath.org/, if I understand the
motivation of psage correctly, it's aim is also to eventually
integrate the useful packages (once they mature from research to
production) into Sage. Looking here:

http://purple.sagemath.org/goals.html

That's pretty much the same motivation for Qsnake. Except that I need
a different set of packages (and I need Fortran).

Ideally, there would be a huge repository of SPKG packages (just like
the huge repository that Ubuntu has, with almost everything), and one
could quickly install just what one needs. So I am trying to figure
this out too with Qsnake. But it's easier said than done.

Ondrej

-- 
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org