+1 from me to include Pynac/GiNaC in Sage,
Martin Albrecht asked about the Windows porting issue: I looked at the
GiNaC code and it is very clean C++. The maintainer is willing to
merge MSVC related patches where needed, i.e. export statements for
the symbols we need. I am not aware of any other
On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] wrote:
BTW, one important warning: ginac and sympycore are missing
assumptions and sympy only has very trivial ones, like positive,
negative, integer, even, odd, etc. This is really important for any
nontrivial things in a CAS
On Mon, Aug 25, 2008 at 11:29 PM, Ondrej Certik [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] wrote:
BTW, one important warning: ginac and sympycore are missing
assumptions and sympy only has very trivial ones, like positive,
negative, integer,
On Tue, Aug 26, 2008 at 8:43 AM, William Stein [EMAIL PROTECTED] wrote:
On Mon, Aug 25, 2008 at 11:29 PM, Ondrej Certik [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] wrote:
BTW, one important warning: ginac and sympycore are missing
assumptions
On Mon, Aug 25, 2008 at 10:58 AM, William Stein [EMAIL PROTECTED] wrote:
As to GPL vs BSD, I am sad that some people will not contribute to a
BSD project and some other people will not use a GPL project. But my
intuition says that the license is not the main reason. If sympy was
as fast as
On Tue, 26 Aug 2008 08:29:33 +0200
Ondrej Certik [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] wrote:
BTW, one important warning: ginac and sympycore are missing
assumptions and sympy only has very trivial ones, like positive,
negative,
On 26/08/2008, at 5:09 PM, Burcin Erocal wrote:
In[]:= Assuming[0x, Assuming[xPi/2 ,ArcCos[Cos[x
Out[]= ArcCos[Cos[x]]
In[]:= Simplify[ArcCos[Cos[x]], Assumptions - 0 x Pi/2]
Out[] = x
==
David J Philp
Postdoctoral Fellow
National Centre for Epidemiology
On Tue, Aug 26, 2008 at 12:09 AM, William Stein [EMAIL PROTECTED] wrote:
I don't know if for this particular project it's a
realistic/valid/interesting solution or not, but how about using LGPL
as a middle solution?
This is not an option because Pynac derives from Ginac and Ginac
is GPL'd:
On Tue, Aug 26, 2008 at 9:09 AM, Burcin Erocal [EMAIL PROTECTED] wrote:
On Tue, 26 Aug 2008 08:29:33 +0200
Ondrej Certik [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] wrote:
BTW, one important warning: ginac and sympycore are missing
On Tue, Aug 26, 2008 at 12:25 AM, Ondrej Certik [EMAIL PROTECTED] wrote:
But did it ever happen to you Fernando that someone would plainly
abuse ipython/numpy/scipy? Clearly ipython is way more popular than
sympy, so if it doesn't happen for numpy/scipy/ipython, I don't think
we have to
An assumption framework is non-trivial as it is basically
computational
real algebraic geometry.
Recenty there was a post about QEPCAD (http://www.cs.usna.edu/~qepcad/
B/QEPCAD.html).
Perhaps this might fit the bill?
Michel
On Aug 26, 8:43 am, William Stein [EMAIL PROTECTED] wrote:
On Mon,
On Tue, 26 Aug 2008 00:40:22 -0700 (PDT)
Michel [EMAIL PROTECTED] wrote:
An assumption framework is non-trivial as it is basically
computational
real algebraic geometry.
Recenty there was a post about QEPCAD (http://www.cs.usna.edu/~qepcad/
B/QEPCAD.html).
Perhaps this might fit the
On Tue, Aug 26, 2008 at 10:16 AM, Burcin Erocal [EMAIL PROTECTED] wrote:
On Tue, 26 Aug 2008 00:40:22 -0700 (PDT)
Michel [EMAIL PROTECTED] wrote:
An assumption framework is non-trivial as it is basically
computational
real algebraic geometry.
Recenty there was a post about QEPCAD
On Tue, Aug 26, 2008 at 1:19 AM, Ondrej Certik [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 10:16 AM, Burcin Erocal [EMAIL PROTECTED] wrote:
On Tue, 26 Aug 2008 00:40:22 -0700 (PDT)
Michel [EMAIL PROTECTED] wrote:
An assumption framework is non-trivial as it is basically
On Aug 26, 1:27 am, William Stein [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 1:19 AM, Ondrej Certik [EMAIL PROTECTED] wrote:
SNIP
qepcad relies on an aging library saclib for the algebraic data
structures. It would be a worthwhile project to implement CAD/port
qepcad so that it
On Tue, 26 Aug 2008 00:42:21 -0700
William Stein [EMAIL PROTECTED] wrote:
Burcin, would LGPL be suitable for you to contribute to sympy, or is
LGPL not protective enough for you?
Since Burcin's whole proposal is to use GiNaC, I suspect that he is only going
to write something if it
On Tue, Aug 26, 2008 at 10:35 AM, Burcin Erocal [EMAIL PROTECTED] wrote:
On Tue, 26 Aug 2008 00:42:21 -0700
William Stein [EMAIL PROTECTED] wrote:
Burcin, would LGPL be suitable for you to contribute to sympy, or is
LGPL not protective enough for you?
Since Burcin's whole proposal is to
On Aug 26, 1:19 am, Ondrej Certik [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 10:16 AM, Burcin Erocal [EMAIL PROTECTED] wrote:
On Tue, 26 Aug 2008 00:40:22 -0700 (PDT)
Michel [EMAIL PROTECTED] wrote:
An assumption framework is non-trivial as it is basically
computational
real
VOTE:
[ ] Yes, include Pynac in Sage
[ ] No, do not (please explain)
[ ] Hmm, I have questions (please ask).
I don't know if my vote counts, but I am of course +1.
Thanks for pioneering the use of Python in C projects, I hope people
will now try much more to reuse C/C++ code.
(e) how
On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote:
Hi,
I propose that pynac be included in Sage.
Pynac is a rewrite of Ginac to seamlessly use native Python objects instead
of CLN -- for inclusion in Sage. Pynac is a C++ library plus extensive
Cython bindings.
I still do not understand why giac is not even mentionned in the
symbolic discussion considering the fact that like ginac, it is a C++
library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas)
has much more advanced calculus functions (either functionnalities
like limits, integration)
On Mon, Aug 25, 2008 at 10:12 AM, parisse
[EMAIL PROTECTED] wrote:
I still do not understand why giac is not even mentionned in the
symbolic discussion considering the fact that like ginac, it is a C++
library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas)
has much more
Hi,
On Mon, 25 Aug 2008 07:12:27 -0700 (PDT)
parisse [EMAIL PROTECTED] wrote:
I still do not understand why giac is not even mentionned in the
symbolic discussion considering the fact that like ginac, it is a C++
library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas)
has much
I've been trying to get an answer for this question for the last few
weeks: Is the plan to extend ginac (write algorithms in C) or to
extend sage (write new algorithms in Sage) using cython/python? This
is very much a design related question, and in the hurry to get GiNaC
through review I feel
On Mon, Aug 25, 2008 at 5:24 PM, Burcin Erocal [EMAIL PROTECTED] wrote:
Hi,
On Mon, 25 Aug 2008 07:12:27 -0700 (PDT)
parisse [EMAIL PROTECTED] wrote:
I still do not understand why giac is not even mentionned in the
symbolic discussion considering the fact that like ginac, it is a C++
I can't speak for anyone else (hence I can't really answer your
question) but I have had problems compiling giac for amd64 hardy heron.
I'm fairly impatient though, and maybe if I tried harder I could have
gotten something to compile. I did spend maybe 30 minutes on it
and gave up.
For a
On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote:
Hi,
I propose that pynac be included in Sage.
VOTE:
[ ] Yes, include Pynac in Sage
[ ] No, do not (please explain)
[ ] Hmm, I have questions (please ask).
I have a question: what will happen to gfurnish's work?
Also noone
has tried to write the Cython wrappers for it,
I hoped Bernard would try it, but I really don't have time for this now.
Ondrej
I don't have the time right now to learn how to write Cython wrappers.
Unfortunately I may end up being obliged (once again) to do it myself
to attract
On Mon, Aug 25, 2008 at 7:12 AM, parisse
[EMAIL PROTECTED] wrote:
I still do not understand why giac is not even mentionned in the
symbolic discussion considering the fact that like ginac, it is a C++
I was able to very quickly get a good understanding of the Ginac
codebase, and make
On Mon, Aug 25, 2008 at 8:54 AM, didier deshommes [EMAIL PROTECTED] wrote:
On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote:
Hi,
I propose that pynac be included in Sage.
VOTE:
[ ] Yes, include Pynac in Sage
[ ] No, do not (please explain)
[ ] Hmm, I have
On Mon, Aug 25, 2008 at 8:35 AM, Gary Furnish [EMAIL PROTECTED] wrote:
I've been trying to get an answer for this question for the last few
weeks: Is the plan to extend ginac (write algorithms in C) or to
extend sage (write new algorithms in Sage) using cython/python?
The plan is definitely
On Mon, Aug 25, 2008 at 2:42 AM, Ondrej Certik [EMAIL PROTECTED] wrote:
VOTE:
[ ] Yes, include Pynac in Sage
[ ] No, do not (please explain)
[ ] Hmm, I have questions (please ask).
I don't know if my vote counts, but I am of course +1.
Your vote counts.
Thanks for pioneering the use
Make it so sympy also runs on top of GiNaC. This will force the creation
of a clear interface specification.
If there is going to be a clear interface spec, then we should go and
make a clear interface spec so that anyone, not just GiNaC can
potentially conform to it. Perhaps this is the
I think porting the limits is quite easy, but unfortunately ginac
series expansion is not sophisticated enough for more complicated
limits (at least last time I tried, it was I think 2 years ago), so
you will have to port the sympy's series expansion as well, or improve
ginac series
On Mon, Aug 25, 2008 at 10:41 PM, Gary Furnish [EMAIL PROTECTED] wrote:
Make it so sympy also runs on top of GiNaC. This will force the creation
of a clear interface specification.
If there is going to be a clear interface spec, then we should go and
make a clear interface spec so that
I definitely want to have a version of pynac outside sage. But keep
in mind again that pynac is GPL'd, and given your mission statement
for sympy, I think it is not an option for you to depend only on something
GPL'd as the only option. As I see it, an important part of the
sympy mission
On Mon, Aug 25, 2008 at 1:41 PM, Gary Furnish [EMAIL PROTECTED] wrote:
Make it so sympy also runs on top of GiNaC. This will force the creation
of a clear interface specification.
If there is going to be a clear interface spec, then we should go and
make a clear interface spec so that
For example pynac uses
sin(x).seires(x, 5)
Actually, more precisely pynac uses:
sin(x).series(x == 3, 5)
to get a taylor expansion about x = 3. I did this
only for consistency with GiNaC, since that is what
GiNaC does.
sympy uses
sin(x).series(x, 0, 5)
and sage uses
BTW, one important warning: ginac and sympycore are missing
assumptions and sympy only has very trivial ones, like positive,
negative, integer, even, odd, etc. This is really important for any
nontrivial things in a CAS and I changes to the core may be needed. I
really want to have
On Aug 25, 2008, at 1:59 AM, William Stein wrote:
Hi,
I propose that pynac be included in Sage.
Pynac is a rewrite of Ginac to seamlessly use native Python objects
instead
of CLN -- for inclusion in Sage. Pynac is a C++ library plus
extensive
Cython bindings. Pynac is about 30K
On Aug 25, 2008, at 8:35 AM, Gary Furnish wrote:
I've been trying to get an answer for this question for the last few
weeks: Is the plan to extend ginac (write algorithms in C) or to
extend sage (write new algorithms in Sage) using cython/python?
I don't think this was addressed in the
41 matches
Mail list logo
