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
> >> com
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 w
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 i
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:
> >> qepcad relies on an aging library saclib for the algebraic data
> >> structures. It would be a worthwhile project to implement CAD/port
> >> qepcad s
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 ba
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
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
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 M
> On Tue, Aug 26, 2008 at 9:15 AM, David Philp <[EMAIL PROTECTED]> wrote:
>>
>>
>> On 26/08/2008, at 5:09 PM, Burcin Erocal wrote:
>>> In[]:= Assuming[0>> Out[]= ArcCos[Cos[x]]
>>
>> In[]:= Simplify[ArcCos[Cos[x]], Assumptions -> 0 < x < Pi/2]
>> Out[] = x
>
> Exactly, you pass the assumptions as
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
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 sympycor
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
>
On 26/08/2008, at 5:09 PM, Burcin Erocal wrote:
> In[]:= Assuming[0 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 and Population Health
Building 6
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,
On Tue, Aug 26, 2008 at 12:06 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
>
> 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. Bu
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
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 mis
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,
>>> nega
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 thing
+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 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 ema
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 a
> 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 assum
> 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
>
> s
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 sp
>> 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
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 s
>> 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
"
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 be
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 pionee
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 defini
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)
>>
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 fund
> 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 attra
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
> 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.
>
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
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 th
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
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 a
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) a
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 bindi
> 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)
43 matches
Mail list logo
