[sage-devel] Re: [debian] Strange numerical errors in sage's libpari code

[maldun]

Maybe I'm missing something here, but aren't these test also badly stated?

This would be a good example why some tolerance should be included
if one test something with floating points: Every small change in some flop 
somewhere in the
code will lead to a fail.
I personally wouldn't call something "strange numerical error", where some 
floating point operation 
differs from the expected output by a difference below machine epsilon.

If this is the only problem with the different pari version, it would be 
better to restate the
unit test. 

Regards,
Stefan

On Wednesday, February 18, 2015 at 1:53:58 PM UTC+1, Snark wrote:
>
> Hi, 
>
> I'm having strange numerical behaviour with my experimental sage using 
> debian packages, with two failing doctests in the src/sage/libs/pari/ 
> directory (both in gen.pyx) : 
>
> Failed example: 
>  (s*z)^5 
> Expected: 
>  2.00 - 1.08420217248550 E-19*I 
> Got: 
>  2.00 + 0.E-19*I 
>
> Failed example: 
>  e.ellztopoint(1+i) 
> Expected: 
>  [0.E-19 - 1.02152286795670*I, -0.149072813701096 - 
> 0.149072813701096*I] 
> Got: 
>  [0.E-18 - 1.02152286795670*I, -0.149072813701096 - 
> 0.149072813701096*I] 
>
>
> For the first one, the "Got:" is the one expected on a 32-bit box! And 
> from all the tests in the directory where there is a differing 
> 32-bit/64-bit expectation, it's the only failing. 
>
> For the second one... I really don't know... 
>
> Does it look familiar? 
>
> Snark on #sagemath 
>

-- 
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: OpenBLAS beats MK for larger problems

[maldun]

I wouldn't see it that negative, since till now Intel's MKL was considered 
unbeatable in performance on Intel
processors.

On Sunday, February 15, 2015 at 3:47:41 PM UTC+1, Volker Braun wrote:
>
> Blas $X beats $Y on an aging cpu for a relatively unimportant set of 
> operations (specifically, matrix-vector).
>
>
>
>
> On Sunday, February 15, 2015 at 3:37:25 PM UTC+1, maldun wrote:
>>
>> Hi!
>>
>> Maybe this may be interesting for future consideration with respect which 
>> blas implementation to choose:
>>
>> https://github.com/xianyi/OpenBLAS/issues/322
>>
>> It appears that OpenBLAS seems to match more and more MKL performance.
>>
>

-- 
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: OpenBLAS beats MK for larger problems

[maldun]

Sorry I mean MKL, somehow the I lost the L ...

-- 
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] OpenBLAS beats MK for larger problems

[maldun]

Hi!

Maybe this may be interesting for future consideration with respect which 
blas implementation to choose:

https://github.com/xianyi/OpenBLAS/issues/322

It appears that OpenBLAS seems to match more and more MKL performance.

-- 
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: SageMathCloud now open source

[maldun]

Hi!

On Thursday, December 11, 2014 10:47:20 PM UTC+1, William wrote:
>
> On Thu, Dec 11, 2014 at 1:28 PM, maldun > 
> wrote: 
> > That's great to hear! 
> > 
> > Although I don't know If GPL3 is the best choice ... 
>
> I actually didn't have an option regarding GPL or not. 
>
> Not even LGPL or at least GPL2?
 

> > Are there already alternative plans to make funding from SMC, since 
> closed 
> > Source is not an option anymore? 
> > (I think this topic is important, since resources are a major issue) 
>
> I don't know yet, but I still hope  it will be possible to start a 
> company around hosting of SMC, even with SMC being open source.It 
> likely will provide less revenue, and be more difficult to get 
> investment.  However, I'm optimistic that at least _something_ will be 
> possible, which in the longterm will have the intended impact 
> (supporting core Sage development). 
>
> William 
>
> Just some ideas that would come to my mind:


   - The software is open, but hosting doesn't have to be
  - Premium accounts with extras
  - More available processing power for money
  - One idea could be mimiing Github: All worksheets are open, except 
  you pay some bucks/month
  - Goodies (e.g. alternative skins for the interface)
  - Apps for smartphones: The flashcard app Anki does this. Although it 
   is OS they charge money for smartphone interfaces
   - GPL does not forbid adding commercial extra packages, as long they are 
   standalone enough.
   - The classic: Advertisment

- Stefan
 

> > 
> > On Thursday, December 11, 2014 6:47:05 PM UTC+1, William wrote: 
> >> 
> >> Hi, 
> >> 
> >> SageMathCloud is now completely open source.The complete source 
> >> code is here, so if you've ever wondered how something in SMC works, 
> >> you can now find out... 
> >> 
> >> https://github.com/sagemath/cloud 
> >> 
> >> There is also a new developer mailing list: 
> >> 
> >>https://groups.google.com/forum/?fromgroups#!forum/sage-cloud-devel 
> >> 
> >> 
> >> Question: Why is SMC open source? 
> >> 
> >> Answer: Two of the four NSF grants that very substantially supported 
> >> SMC development had explicit open source requirements. 
> >> 
> >> 
> >>  -- William 
> >> 
> >> 
> >> -- 
> >> William Stein 
> >> Professor of Mathematics 
> >> University of Washington 
> >> 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> William Stein 
> Professor of Mathematics 
> University of Washington 
> 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.

[sage-devel] Re: SageMathCloud now open source

[maldun]

That's great to hear!

Although I don't know If GPL3 is the best choice ...

Are there already alternative plans to make funding from SMC, since closed 
Source is not an option anymore?
(I think this topic is important, since resources are a major issue)

On Thursday, December 11, 2014 6:47:05 PM UTC+1, William wrote:
>
> Hi, 
>
> SageMathCloud is now completely open source.The complete source 
> code is here, so if you've ever wondered how something in SMC works, 
> you can now find out... 
>
> https://github.com/sagemath/cloud 
>
> There is also a new developer mailing list: 
>
>https://groups.google.com/forum/?fromgroups#!forum/sage-cloud-devel 
>
>
> Question: Why is SMC open source? 
>
> Answer: Two of the four NSF grants that very substantially supported 
> SMC development had explicit open source requirements. 
>
>
>  -- William 
>
>
> -- 
> William Stein 
> Professor of Mathematics 
> University of Washington 
> 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.

Re: [sage-devel] Re: User Survey

[maldun]

I don't know. 
Is it harder to support a full Sage on a variety of different platforms 
which are needed,
or to make a reduced Sage, where testing of the sub-distribution can be 
fully contained,
in the main framework?

Additionally to that, we have to keep in mind that while sage grows in 
functionality,
more modularity gives better maintainability, which could be necessary 
someday anyway,

And the main question: Does this really concern that much packages? If the 
number
would be countable on one hand, it should really be considerd.

On Tuesday, December 9, 2014 9:42:05 PM UTC+1, William wrote:
>
> On Tue, Dec 9, 2014 at 12:14 PM, maldun > 
> wrote: 
> > Hi! 
> > 
> > Concerning the support problematic for ARM, Windows etc: 
> > 
> > We should ask ourselfs if we need a more minimal Sage distribution, 
> which is 
> > easily portable to 
> > ALL Platforms. The main problem with Sage on many platforms is, that 
> some 
> > packages often fail to build. 
> > Especially C based packages as troublemakers. 
> > 
> > I absolutely don't want to close out these packages! But we should 
> consider 
> > a subset of Sage (let's call it MiniSage) 
> > which is easier portable and more slender, but which contains enough 
> > functionality for the average user. 
> > This gives the developers more time to polish out problems with packages 
> of 
> > the traditional Sage, 
> > while maintaining and improving functionality of the core set on the 
> device 
> > in question. 
> > 
> > That would come to the following new structure: 
> > Minimal Packages (MiniSage)-> Core Packages (traditional Sage) -> 
> optional 
> > Packages ... 
>
> I think everybody would want to have such a thing.  In practice, it is 
> a simply a lot of work (especially for the release manager), and we 
> have very limited resources in that regards, to put it mildly... 
>
> If we had more resources, there are so many things like this that I 
> would want us to do. 
>
> > 
> > -Stefan 
> > 
> > On Tuesday, December 9, 2014 6:25:56 PM UTC+1, William wrote: 
> >> 
> >> On Tue, Dec 9, 2014 at 9:20 AM, mmarco  wrote: 
> >> > Yes we do, but not as completely as x86. For instance the last 
> version 
> >> > that 
> >> > has an arm binary in the download page is 5.13. 
> >> > 
> >> > The Wolfram language, which is something like a strpped version of 
> >> > Mathematica, is included in the raspbian distribution. So, would 
> >> > raspberry 
> >> > pi support fit into the mission statement? 
> >> 
> >> Definitely, yes it does, without any question. 
> >> 
> >>  -- William 
> >> 
> >> > 
> >> > El lunes, 8 de diciembre de 2014 23:10:49 UTC+1, William escribió: 
> >> >> 
> >> >> On Mon, Dec 8, 2014 at 2:05 PM, Jean-Pierre Flori  
>
> >> >> wrote: 
> >> >> > 
> >> >> > 
> >> >> > On Monday, December 8, 2014 9:53:51 PM UTC+1, mmarco wrote: 
> >> >> >> 
> >> >> >> Maybe support for arm architecture would be relevant in that 
> >> >> >> respect. 
> >> >> > 
> >> >> > We do support ARM, don't we? 
> >> >> > 
> >> >> > At least I'm able to compile Sage from scratch on a Raspberry Pi 
> and 
> >> >> > on 
> >> >> > armv7+ as well. 
> >> >> 
> >> >> Awesome!  And yes we do. 
> >> >> 
> >> >> Again, as this thread is titled "User Survey", let's say that the 
> >> >> survey question might be: "Do you *care* about support for Sage on 
> ARM 
> >> >> devices such as Raspberry Pi, etc.?" 
> >> >> 
> >> >> William 
> >> >> 
> >> >> > 
> >> >> > -- 
> >> >> > 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+...@googlegroups.com. 
> >> >> > To post to this group, send email to sage-...@googlegroups.com. 
> >> >> > Visit this group at http://groups.google.com/group/sage-devel. 
> >> >> > For more optio

Re: [sage-devel] Re: User Survey

[maldun]

Hi!

Concerning the support problematic for ARM, Windows etc:

We should ask ourselfs if we need a more minimal Sage distribution, which 
is easily portable to 
ALL Platforms. The main problem with Sage on many platforms is, that some 
packages often fail to build.
Especially C based packages as troublemakers.

I absolutely don't want to close out these packages! But we should consider 
a subset of Sage (let's call it MiniSage) 
which is easier portable and more slender, but which contains enough 
functionality for the average user.
This gives the developers more time to polish out problems with packages of 
the traditional Sage, 
while maintaining and improving functionality of the core set on the device 
in question.

That would come to the following new structure:
Minimal Packages (MiniSage)-> Core Packages (traditional Sage) -> optional 
Packages ...

-Stefan 

On Tuesday, December 9, 2014 6:25:56 PM UTC+1, William wrote:
>
> On Tue, Dec 9, 2014 at 9:20 AM, mmarco > 
> wrote: 
> > Yes we do, but not as completely as x86. For instance the last version 
> that 
> > has an arm binary in the download page is 5.13. 
> > 
> > The Wolfram language, which is something like a strpped version of 
> > Mathematica, is included in the raspbian distribution. So, would 
> raspberry 
> > pi support fit into the mission statement? 
>
> Definitely, yes it does, without any question. 
>
>  -- William 
>
> > 
> > El lunes, 8 de diciembre de 2014 23:10:49 UTC+1, William escribió: 
> >> 
> >> On Mon, Dec 8, 2014 at 2:05 PM, Jean-Pierre Flori  
> >> wrote: 
> >> > 
> >> > 
> >> > On Monday, December 8, 2014 9:53:51 PM UTC+1, mmarco wrote: 
> >> >> 
> >> >> Maybe support for arm architecture would be relevant in that 
> respect. 
> >> > 
> >> > We do support ARM, don't we? 
> >> > 
> >> > At least I'm able to compile Sage from scratch on a Raspberry Pi and 
> on 
> >> > armv7+ as well. 
> >> 
> >> Awesome!  And yes we do. 
> >> 
> >> Again, as this thread is titled "User Survey", let's say that the 
> >> survey question might be: "Do you *care* about support for Sage on ARM 
> >> devices such as Raspberry Pi, etc.?" 
> >> 
> >> William 
> >> 
> >> > 
> >> > -- 
> >> > 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+...@googlegroups.com. 
> >> > To post to this group, send email to sage-...@googlegroups.com. 
> >> > Visit this group at http://groups.google.com/group/sage-devel. 
> >> > For more options, visit https://groups.google.com/d/optout. 
> >> 
> >> 
> >> 
> >> -- 
> >> William Stein 
> >> Professor of Mathematics 
> >> University of Washington 
> >> 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> William Stein 
> Professor of Mathematics 
> University of Washington 
> 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.

Re: [sage-devel] Re: What are we unable to do right now ?

[maldun]

I agree with you that it is not that important as it was some years ago.
Nevertheless be aware that many professional users in engineering
and research can't go online that simply, because of security reasons, and
company policies (I know that from first hand), 
and they are a big market which we should not underestimate.

On Friday, December 5, 2014 9:39:55 PM UTC+1, William wrote:
>
> On Fri, Dec 5, 2014 at 12:19 PM, maldun > 
> wrote: 
> > What we still don't have is a working windows version. This is still a 
> big 
> > blocker for being succesfull. 
>
> I don't want to in any way discourage anybody from working hard on 
> Windows support for Sage.  However, it's getting more difficult to 
> argue that Windows support is a blocker to our mission statement. 
>
> As I've explained elsewhere, I started SageMathCloud because of 
> exactly this problem, and also that I'm thinking about where 
> technology is going to be in a few years rather than where it was. 
> I'm not arguing the SMC is *the* solution, just that web-based 
> approaches are, including Sage cell server, Wakari, etc. 
>
> There's no question that in say 200?, Microsoft Windows support was 
> absolutely critical for widespread adoption of a piece of software in 
> a given market.   Today, and certainly going into the future, this is 
> not so clear.The single most popular applications in the world 
> today are Google.com and Facebook.com [1], which have well over a 
> *billion* active users [2], and neither has a "working windows 
> version".And it appears based on [3] and blogs that much of the 
> math software development work by Wolfram Inc is about making 
> Mathematica available online. 
>
> Online is where the puck is going.  Actually, it is arguably where the 
> puck already is.   (For huge applications, mobile is just a different 
> interface to online.) 
>
>  -- William 
>
> [1] http://www.alexa.com/topsites 
> [2] http://newsroom.fb.com/company-info/ 
> [3] https://www.wolframcloud.com/ 
>
> > 
> > On Friday, December 5, 2014 8:17:44 AM UTC+1, Nathann Cohen wrote: 
> >> 
> >> Helloo everybody ! 
> >> 
> >> I am preparing some Sage talk, and I wanted to say at some point: 
> >> "Honestly we are not that good. We have strong points but we miss many 
> >> things too. It all depends on what the developpers are interested in: 
> we are 
> >> great on some research areas, and under water level on others" 
> >> 
> >> Somehow this question is also related to William's "Sage has failed", 
> as 
> >> we cannot be a replacement for Mathematica/Maple/ unless we cover 
> all 
> >> kinds of mathematics. 
> >> 
> >> In your past experiences (possibly when using Sage to teach in a 
> >> classroom), in which areas do you think we are behind users' 
> expectations ? 
> >> 
> >> If we had such a list, we could even start asking people around "Do you 
> >> work on X ? Cool, we need your help for something big". We could also 
> have a 
> >> list of such domains on our website, and do some (cheap) propaganda 
> like: 
> >> 
> >> "Sage as in 'Free Beer': if you can help us develop Sage's features in 
> the 
> >> areas above, we owe you one. Actually we owe you many. Become a 
> contributor 
> >> and be rewarded with a free beer from every Sage developper you will 
> meet 
> >> around the world" 
> >> 
> >> We have to know what we cannot do. So let's make a list. 
> >> 
> >> Nathann 
> > 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to sage-...@googlegroups.com 
> . 
> > Visit this group at http://groups.google.com/group/sage-devel. 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> William Stein 
> Professor of Mathematics 
> University of Washington 
> 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.

[sage-devel] Re: What are we unable to do right now ?

[maldun]

What we still don't have is a working windows version. This is still a big 
blocker for being succesfull.

On Friday, December 5, 2014 8:17:44 AM UTC+1, Nathann Cohen wrote:
>
> Helloo everybody !
>
> I am preparing some Sage talk, and I wanted to say at some point: 
> "Honestly we are not that good. We have strong points but we miss many 
> things too. It all depends on what the developpers are interested in: we 
> are great on some research areas, and under water level on others"
>
> Somehow this question is also related to William's "Sage has failed", as 
> we cannot be a replacement for Mathematica/Maple/ unless we cover all 
> kinds of mathematics.
>
> In your past experiences (possibly when using Sage to teach in a 
> classroom), in which areas do you think we are behind users' expectations ?
>
> If we had such a list, we could even start asking people around "Do you 
> work on X ? Cool, we need your help for something big". We could also have 
> a list of such domains on our website, and do some (cheap) propaganda like:
>
> "Sage as in 'Free Beer': if you can help us develop Sage's features in the 
> areas above, we owe you one. Actually we owe you many. Become a contributor 
> and be rewarded with a free beer from every Sage developper you will meet 
> around the world"
>
> We have to know what we cannot do. So let's make a list.
>
> Nathann
>

-- 
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] User Survey

[maldun]

Hi!

Since William's statement, that Sage failed as a real alternative to the 4 
MMs there are currently some threads
with thoughts on improving Sage.

But till now I see only discussions among the devlopers. But I think we 
should also ask the users.
The most of us here are scientists. But to make Sage successful we have to 
be more considerate
about a big block of non mathematicians and beginners, which are a big 
portion of potential users.

I don't think that the functionality of Sage is the big problem, in fact 
Sage has a great features for zero cost.
A bigger problem is that Sage is lacking good 'user experience'. This 
starts already with installation.
We still don't have a good Windows version, and you can't install Sage from 
the standard repos of your favorite distribution.
SageMathCloud overcomes some of these problems by providing
an out of the box we interface, but there are still people who want 
something to install on their hard drive.
Especially If they don't want to go online for security reasons, or want to 
use their own hardware.
Additionally it often appears to me that sage lacks of clean design.

So I ask:

Are there any serious attempts to analyze standard user needs more 
systematically?
(And I don't talk about bug reports) I didn't find any except for a survey 
from 2009.

I think it is very important to get at least some clues about

   1. What do most need people for their daily needs
   2. How well does these standard tasks work.

I give an example from my personal experience: Many people have
purely numerical tasks with little symbolics involved (classical in 
engineering)
so they will use much of numpy functionality.
If they use Sage then they often will get annoyed by the preparser not 
handling numpy/scipy well.
I know at least 3 people, which switched to IPython+Sympy because of that 
reason. Not because
Sage isn't worse, but some things don't go along very well.

A keen Sage user now would simply turn the preparser off.  And that would 
be the answer.
This may seem quite trivial to developers which work on far harder topics 
and are good programmers.
Personally I don't have problems tinkering around a bit.

But 'normal' people will

   1. not read the docu, simply want that it works out of the box
   2.  not ask for support
   
Most users simply want to input some formulas and want the problem be 
solved quite elegantly,
The feeling is very important.

So what can we do? We have to ask the users! 

In the information age it shouldn't be such a big deal to make some 
standard surveys on SageMathCloud 
and Sagemath.org. Of course a short one.

Another good start would be make some simple standard tasks as an excercise 
sheet for students which don't know Sage
(e.g. first training session in a math course using sage). Then let the 
students solve them on their own, and finally let them fill
in a form, what they liked and what not, what was difficult, what easy.

I know the most of the developers are scientists, and don't care much about 
good 'marketing'.
But think of Henry Ford: He didn't built the best cars the automotif sector 
t his time, but he gave people
what they needed, and hence was successful.

I hope I made my concerns clear.

Best regards,
Stefan


-- 
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: Mention of Sage in a book review

[maldun]

Nice arcticle!

I totally agree with his comments about Matlab. It was written as 
fast Fortran interface and still has this feeling. Object oriented 
programming is a joke in Matlab. I used Matlab 2009 and measured
1ms(!) time for access to one simple class member. (Comparison:
Pyton needs some µs) I have to laugh if they sell OO programming courses in 
Matlab ...

On Friday, December 5, 2014 11:13:26 AM UTC+1, John Cremona wrote:
>
> In the review http://newsletter.lms.ac.uk/coffee-love-and-matrix-algebra/ 
>  by Robin Whitty of a novel called "Coffee, love and matrix algebra" 
> by Gary Ernest Davis there is a nice mention of Sage;  though clearly 
> not in the book itself which seems to be loaded with product 
> placements for alpha and others. 
>
> John 
>

-- 
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: Maple versus Mathematica

[maldun]

The emphasis lies on 'trying' Concerning image processing and control 
theory matlab is prefered by most with good reason (for reference: I come 
from these areas)
Since numpy/scipy/matplotlib is on board with Sage, it can easily challenge 
Mathematica in these areas, since the scipy packages can compare quite good 
with
Matlab. And I dare say that sage can easily outsmart the symbolic toolbox 
of Matlab.

On another note: Sage comes with Cython (and of course other possibilities) 
which is much smarter than MEX from matlab concerning low level programming 
for fast code.
And I remember well that a colleague of mine switched very fast to 
Numpy/Cython, because he got sick of MEX files.
A comparison between MEX and Cython would also be a good point.

I suppose some direct use cases where Sage is directly compared to the 
other 4Ms and shows why it is better suited, would be important to such a 
comparison.
Some of the formentioned things above are some reasons why at least I 
prefer Sage over Matlab and Mathematica. 
Maybe it would be a good Idea to collect some more concrete examples?

A short list of other strong points besides the one from above


   1.  The price: Of course
   2. Open
   3. Covers broad functionality
   4. Expandable: It is easy to build Sage packages and expand it's 
   functionality.
   5. The Notebook: It is easy to use, and has very nice typesetting 
   (compared to Mathematica it is far better I think; this could also be in a 
   comparison)
   6. Python: One could always argue about the language itself, but in 
   contrast to the others Sage uses a general purpose language. So it easy to 
   combine Sage with other programs (Ever build standalone Programs with the 
   others?)
   7. Most important Python packages for Math ready to go
   8. A nice community
   9. The price!
   10. ...

Has someone more examples why he/she uses Sage instead of one of the 4Ms? 

Maybe a survey along the users would be also good Idea? This could extend 
the list,
and maybe would at least be a start.


On Monday, December 1, 2014 6:27:56 AM UTC+1, Dr. David Kirkby (Kirkby 
Microwave Ltd) wrote:
>
> On 27 Nov 2014 20:51, "maldun" > wrote:
>
> > I personally a comparison of sage with the other Systems is quite hard, 
> since all of the other 4Ms concentrate more or less
> > on particular fields of mathematic (e.g. Matlab focus on numerics, 
> Mathematica more on Calculus etc.)
> > Sage is far from perfect but tries to cover all fields at once.
>
> Although I have never tested it myself,  several sources say Mathematica 
> is the best program for symbolic maths.  
>
> But to me at least Mathematica covers a very wide area of mathematics. 
> Inage processing,  control theory,  number theory, numerics, financial etc. 
> I think it tries to cover pretty much everything.  
>
> I believe any attempt to compare the packages would be very difficult and 
> I doubt it is possible to remove personal bias. 
>
> It is totally objective to say Sage is free, whereas neither Mathematica 
> or MATLAB are. But just about other comparison else is going to be 
> subjective. 
>
> Dave.
>

-- 
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: The "code of conduct" is getting out of hand - please stop for 2 weeks.

[maldun]

+1

As already said in an other thread: I don't understand this high waves of 
emotion, and I don't think it is healthy
for the community

-- 
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: proposed amendment to code of conduct

[maldun]

On Friday, November 28, 2014 11:37:20 PM UTC+1, Simon King wrote:
>
> Hi Maldun, 
>
> On 2014-11-28, maldun > wrote: 
> > So far as I understand, this code/guidline/whatever does not serve as a 
> > law, or is written in stone, 
> > nor does it say: "If you don't behave as stated in the code, you will be 
> > teared feathered and be banned forever!" 
>
> It is the experience of some people participating in the discussion that 
> there is a difference between the official intention of a set of rules, 
> and the spirit in which the rules will eventually be used in reality. 
>
> Dima has provided a link to some communist code of conduct. Its rules seem 
> mainly harmless, but since social rules are never objective, it is always 
> possible to use them against unwanted people. 
>
> And to give you an example that is smaller than Soviet Union: 
> I have seen teachers claiming that the rules they set up just 
> serve to the good of the class (in the current discussion, the word 
> "safety nest" was used), but all what they did was creating a snake pit 
> (and I'd say: deliberately). In one case, four pupils out of a class of 
> 20 pupils left the school within one year. From two of them I know that 
> they left since the teacher's rules could too easily be instrumented by 
> bullies. 
>
> > I don't think it's that big deal, it's like hanging up some nice slogans 
> on 
> > your wall like 'Be nice to others.' 
>
> That's totally opposite to my experience. I respect that the majority of 
> people here wants some kind of code of conduct/guideline/etiquette. But 
> I also know that it can be used as a weapon to nuke a society. So, haste 
> in creating the thing can be fatal. 
>
> Cheers, 
> Simon 
>
> I can follow your concerns but as stated in my other post, there is one 
thing missing to be a law/rule: A consequence.
If you consider teachers or the soviet union, there was also a form of 
authority. The sage community has no leader/excecutive which
executes the laws. So are they really laws? In my opinion they are rather 
statements.


-- 
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: proposed amendment to code of conduct

[maldun]

On Friday, November 28, 2014 11:04:08 PM UTC+1, vdelecroix wrote:
>
> Hi, 
>
> 2014-11-28 15:48 UTC−06:00, maldun >: 
> > Hi all! 
> > 
> > I quite watched this discussion for this so called code of conduct. 
> There 
> > are a lot of 
> > opponents of this idea and I wonder why. 
>
> Please tell me who? As far as I read, nobody proposed to have nothing. 
> We are just discussing what. You are welcome to participate but not to 
> negate the work in progress. 
>
> Erm, even the Wiki states as alternative 'nothing'? So at least one would 
have that in mind.
But thats not precisely what I meant. To be more specific: 'A lot of 
proponents of the code which was initially stated.'
 

> > So far as I understand, this code/guidline/whatever does not serve as a 
> > law, or is written in stone, 
> > nor does it say: "If you don't behave as stated in the code, you will be 
> > teared feathered and be banned forever!" 
>
> That is precisely the issue: its aim is not explicit and it is written as 
> a law. 
>
> I may be wrong, but doesn't a (social) law or rule need some sort of 
consequence
(penalty etc.) and someone who executes it to actually be a law? In the 
current
state it's simply a statement.
 

> > I don't think it's that big deal, it's like hanging up some nice slogans 
> on 
> > your wall like 'Be nice to others.' 
>
> This might not reflect the sentiment of the community. And not 
> everybody have to like "nice slogans". 
>
> Define sentiment of the community? The sentiment of the a) whole 
community, b) the majority
or c) some particular members whcih can be considered as the leaders. 
If you consider a) as your definition then, like in every big community, 
the chances are near zero
that this ever will happen. If you consider b) a vote was already made, and 
I suppose you exclude c) as an option.

I personally think that it is more important to not contradict the 
sentiment of the community, but thats just my opinion.
 

> > And I really like such codes because it states that the community wants 
> > that it's members are nice to each others. 
>
> Now, you consider that it is not only a slogan ;-) My main concern 
> with your sentence is that you make a distinction between "the 
> community" and "the members". What is this difference? 
>
> Vincent 
>

I just wanted to say that it appears to me, that communities who remember 
their members from time to time to be nice to each other
tend to actually do this. But yes this is simply a personal experience, and 
has no deeper foundation.

If you want to nitpick: It's like the difference between a set and its 
elements. And since members are individuals, and actually humans,
they can be nice to each other. A community is not a human being, but a set 
of members who work on/with some software/whatever.

Maybe my comments seem a little bit sarcastic, but I personally think the 
emotions concerning this matter are quite high, on something which
does not really seem to have such a deep impact on the project. Maybe I am 
wrong, but from my experience this will lead to the following:
A lot of time and energy is wasted on something not that big, although 
maybe bigger problems would need more attention and finally come to

   - a solution everyone is equally unhappy or
   - It will be discussed forever till everyone is tired, and in the end 
   nothing happens.

Sorry for being so sarcastic but I have quite some experience on such 
matters (and it always happens just read newspapers ...). 
Also I'm currently reading some books about innovations and novelities and 
it is quite shocking how precisely the theory apply in this current 
situation ...

-- 
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: proposed amendment to code of conduct

[maldun]

Hi all!

I quite watched this discussion for this so called code of conduct. There 
are a lot of
opponents of this idea and I wonder why.

So far as I understand, this code/guidline/whatever does not serve as a 
law, or is written in stone,
nor does it say: "If you don't behave as stated in the code, you will be 
teared feathered and be banned forever!"

I don't think it's that big deal, it's like hanging up some nice slogans on 
your wall like 'Be nice to others.'

And I really like such codes because it states that the community wants 
that it's members are nice to each others.
And we all know that there are communities which are the complete oposite 
of nice to their users/each other.
So no harm, just like the 'other code' in 
https://groups.google.com/forum/#!topic/sage-flame/ST-8uPshOR4

-- 
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: Maple versus Mathematica

[maldun]

One of the most important differences between Sage and Mathematica, is that 
no one of the developers has such a big ego than Stephen Wolfram. It even 
got it's own music theme: https://mollyrocket.com/11235

And we all know that Python will never decipher the universe like the 
Wolfram language will *cough**cough*

Back to Topic:

I like that idea very much. But I think instead of simply comparing Sage 
with one of the other 4M's
we should focus on emphasizing that Sage covers a lot of the functionality 
for no cost.

I personally a comparison of sage with the other Systems is quite hard, 
since all of the other 4Ms concentrate more or less
on particular fields of mathematic (e.g. Matlab focus on numerics, 
Mathematica more on Calculus etc.)
Sage is far from perfect but tries to cover all fields at once.

This is what I love about this project: With the complete power of all 
Python libraries, one can do calculus, algebra and numerics
equally strong in one box, without transfering forth and back between 
commercial codes, which try to be incompatible as possible.
This can be quite frustrating if you work on topics where Calculus, 
Symbolics and Numerics heavily mix (e.g. Continuum mechanics;
>From the symbolic expression to the variational formulation, to the finite 
element matrix)

On Tuesday, November 18, 2014 10:35:21 PM UTC+1, William wrote:
>
> See this interesting document: 
>
>
> http://www.maplesoft.com/products/maple/compare/HowMapleComparestoMathematica.pdf
>  
>
> It would be valuable to our users (and potential users) if we had a 
> similar document which explains and *argues* for why we believe our 
> approach to mathematical software is better than the ones taken by 
> Mathematica, Magma, Maple, and Matlab. 
>
> Some samples from their document: "About 95% of Maple's functionality 
> is written in the  Maple programming language, and every Maple user 
> can freely inspect the source code for any of these predefined Maple 
> library routines. [...] In Mathematica, the source code for all the 
> predefined library routines written in the Mathematica  programming 
> language is hidden from the user." (*) 
>
> When arguing for Maple's language over the Mathematica language, they 
> say "Functional programs are often opaque; most people,  even 
> experienced programmers, find functional-style  programs to be 
> significantly harder to write, read, and  debug." 
>
> (*) We had a specific situation a few years ago where an academic 
> wrote a package in maple, and a student at UW wanted to write a 
> similar open source package in Python.  We specifically asked 
> Maplesoft if the student could look at the source code of Maple, which 
> is "open" in the sense they list above, then be inspired by it in 
> writing his own Python code.   They came back and clearly said "no 
> way; absolutely not!" 
>
>
> -- 
> William Stein 
> Professor of Mathematics 
> University of Washington 
> 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.

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

[maldun]

The only clean solution for this behaviour would be a warning e.g: 
"Warning: This Identity holds only almost everywhere!"
But I don't know if it's worth the effort ...

-- 
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: Bug in abs(I*x).diff(x)

[maldun]

>
>
> This is in some sense good, since  we don't have to care about the 
> derivative at zero, 
> but in an other sense it is not so good, since the subdifferential ∂abs(0) 
> = [0,1] is a bounded and with this definition one could come to the false 
> conclusion that abs(x)
> has a pole, althoug by taking limits one can easily see that it should be 
> bounded at zero.
>
>
>
>
Sorry I meant  ∂abs(0) = [-1,1] ...

And another thing to add: I think the only clean solution could be a 
warning like: "Warning: This is not a derivative in the classical sense!"
But I don't know if this is really worth the effort ... 

-- 
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: Bug in abs(I*x).diff(x)

[maldun]

We had a similar problem with the complex derivative of logarithms in 
combination with the complex conjugate, where I also the
use of Wirtinger Operators would solve the problem: 
https://groups.google.com/forum/?hl=en#!topic/sage-support/bEMPMEYeZKU

Having them in Sage would be a great achievement!

Although this has some sense in complex analysis one should be careful with 
'deriving' the absolute value, since
it results in the weak derivative ( 
http://en.wikipedia.org/wiki/Weak_derivative) , which is in a broader sense 
the derivative in the distribution sense. 
Thus we have infinite possible derivatives

With this expression it is indirectly forbidden to asign a specific value 
to the unspecified value at zero:

sage: f = abs(x).diff(x)
sage: f(x=0)
---
ValueErrorTraceback (most recent call last)
 in ()
> 1 f(x=Integer(0))

/home/maldun/sage/sage-6.3/local/lib/python2.7/site-packages/sage/symbolic/expression.so
 
in sage.symbolic.expression.Expression.__call__ 
(build/cythonized/sage/symbolic/expression.cpp:21933)()

/home/maldun/sage/sage-6.3/local/lib/python2.7/site-packages/sage/symbolic/ring.so
 
in sage.symbolic.ring.SymbolicRing._call_element_ 
(build/cythonized/sage/symbolic/ring.cpp:8493)()

/home/maldun/sage/sage-6.3/local/lib/python2.7/site-packages/sage/symbolic/expression.so
 
in sage.symbolic.expression.Expression.substitute 
(build/cythonized/sage/symbolic/expression.cpp:21183)()

ValueError: power::eval(): division by zero



This is in some sense good, since  we don't have to care about the 
derivative at zero, 
but in an other sense it is not so good, since the subdifferential ∂abs(0) 
= [0,1] is a bounded and with this definition one could come to the false 
conclusion that abs(x)
has a pole, althoug by taking limits one can easily see that it should be 
bounded at zero.

For symbolic purposes, of course one could live on with this.

-- 
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] Legendre_Q and the Branch of the logarithm

[maldun]

Hi!

On trac http://trac.sagemath.org/ticket/16813 Ralf Stephan and I come to 
the question which representation of legendre_Q and gen_legendre_Q is 
better suited,
since it is not unique due to the complex logarithm.
We have several choices to represent the logorithm appering in the formula 
of legendre_Q


   1. log((1+z)/(1-z))
   2. log(1+z) - log(1-z)
   3. conjugate(log((1+z)/(1-z))
   
It seems Maxima uses the first one, Wolfram the second one (indeed it has 
it's benefits). The third is possible but unhandy since you can't proper 
differentiate complex conjugation (except if you use Wirtinger operators of 
course, but not with the standard differential operator)

The problem is now that version one and two are simply solutions on 2 
different branches of the logarithm, therefore both correct but which one 
two choose. We think that V2 is better, but we have to make sure that it 
does not interfere with other code.
The testing of sage is currently going on, but I wanted to ask on the 
mailing list if there are other reasons too, to stick on representation 
number 1.

 

-- 
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] reddit'ers at it again discussing sage...

[maldun]

>
> Well, I think you didn't understand me or I don't understand you. 
> There is already numpy, scipy and matplotlib in Sage and there is no 
> obstruction whatsoever to use it. One has to turn off the preparser, 
> otherwise you might see really odd errors. 
>
>
> Oversaw that comment ...
No it's not only the preparser. Many of the Special functions still don't 
support direct input of numpy arrays, and there are more points.
Not too long ago list_plot wasn't able to use numpy array one had to use 
.to_list() 

-- 
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] reddit'ers at it again discussing sage...

[maldun]

I know that, but it frightens me. I have no idea how to enter those 
characters ... 
Without knowing anything, I bluntly assume that Sage will have a 
Python-2-only policy for variable names. 

-- H 


Nothing simpler than that:
https://code.google.com/p/ibus/wiki/LaTeX
based on Ibus: https://code.google.com/p/ibus/

 I have a normal US Keyboard Layout

With Ibus you can simply type every UTF-8 Character with ease like: ∞, Σ, 
∫ｆ(α)ｄα using the well known latex commands =D
今晩は皆さん



-- 
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] reddit'ers at it again discussing sage...

[maldun]

On Wednesday, August 27, 2014 7:00:51 PM UTC+2, Harald Schilly wrote:
>
>
>
> On Wednesday, August 27, 2014 4:16:46 PM UTC+2, bluescarni wrote:
>>
>> My impression is that the Scipy-Numpy-Sympy ecosystem is a better fit 
>> than Sage, at least for numerical purposes. 
>>
>
> Mine too, and despite Sage lacking with updates there is nobody holding 
> you back from working with just that stack in Sage and access additional 
> features on demand. We should make sure that installing additional packages 
> via pip does work (hence, we have to update numpy/scipy and so on from time 
> to time to get pandas&co working) but besides that this is fine.
>
> There are only two major issues:
> * compatibility: e.g. the .numpy() of a sage matrix gives you something 
> for numpy. one has to know that.
> * out-of-the-box: The Sage preparser breaks an awful lot of things if you 
> do not know that it is transforming your input. Personally, I was never 
> very fond of it but I fully understand why it is there. 
>
> Me dreaming: All of the above could be solved by yet another additional 
> sage spkg, which does not only add many of the numerical python libs, but 
> also changes some of the internals (like, disabling the preparser). The 
> actual question would be if that triggers any interest. I don't think so...
>
> --H
>
>
+1

Lacking numpy support is really one of the big flaws of Sage since 
Numpy,Scipy et al form a marvelous Matlab replacement.
And I hope truly that we get to Python 3 some time. Since Python has full 
UTF8 support writing 
if α < γ*ε:
 return σ

 is not a dream anymore

Nevertheless the Sage notebook is really good to work in combination with 
Scipy since you can make a quite good presentation of your results 

-- 
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 practical/useful would a native windows subset be?

[maldun]

There a reports on Trac that sage 5.9 worked fine on windows 7 64-Bit. 
http://trac.sagemath.org/wiki/CygwinPort
So it is no science-fiction to say that sage on Cygwin is possible.
Indeed it will not come without some trouble and hard work.

On Monday, August 25, 2014 1:48:41 PM UTC+2, Dr. David Kirkby (Kirkby 
Microwave Ltd) wrote:
>
>
> On 25 Aug 2014 12:44, "Jeroen Demeyer"  > wrote:
>
> > I think Sage-on-Cygwin is fay more realistic than a pure native (even 
> stripped down) version of Sage. I you care about Windows, concentrate your 
> efforts on the Cygwin port.
>
> Why has so much time been spent on it, without success?
>
> William wrote in 2007 Sage would probably never be built on Cygwin
>
> http://markmail.org/message/fapx25o3kqipdeg2
>
> Then in 2010 described how he got it to build
>
> https://groups.google.com/forum/m/#!topic/sage-windows/ygK1kJm9p9w
>
> and while I can't find the post,  I think William later expressed some 
> doubt whether it would ever work properly. 
>
> I am on my mobile phone now,  so not too easy to browse the web, but I 
> pretty sure that the Cygwin port was due to be finished before the Solaris 
> port. 
>
> Maybe there's a case for a fresh start with more modest aims and a cleaner 
> interface. 
>
> Dave
>

-- 
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: William Stein says "Sage has overall failed"

[maldun]

And I forgot: It is defenitely better than the 5th M, namely MatCAD! 

-- 
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: William Stein says "Sage has overall failed"

[maldun]

Sage has definietly not failed! I use it as alternative to Matlab and 
Mathematica for years now, and what the true strength of Sage is not, that 
it is better than one of the 4M's, but is doing a equivalently good job in 
all those areas, which each of this programs is speciallized in!

The one thing I have personally to criticize about sage is that the 
scientific computing/numeric community is quite weak here. Of course thanks 
to scipy that part is very well covered, and the scipy ecosystem is part of 
sage, but it still has the feeling of 'beeing on board' instead of beeing 
fully integrated.
 

On Thursday, August 21, 2014 12:17:43 PM UTC+2, Harald Schilly wrote:
>
> Surprisingly, sometimes Reddit contains actual discussions: 
>
>
> http://www.reddit.com/r/math/comments/2e3qla/william_stein_says_sage_has_overall_failed/
>  
>
> -- H 
>

-- 
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: SageMathCloud / closed source / GPL / Spirit of Sage??

[maldun]

I don't think it's a bad idea to make something partly commercial. 

>From the moral point of view I may cite Richard Stallmann ( 
http://www.gnu.org/philosophy/selling.html ):

> Many people believe that the spirit of the GNU Project is that you should 
> not charge money for distributing copies of software, or that you should 
> charge as little as possible—just enough to cover the cost. This is a 
> misunderstanding.
>
> Actually, we encourage people who redistribute free software 
>  to charge as much as they 
> wish or can. If this seems surprising to you, please read on.
>

 Making money of opensource is not a bad thing. One can sell service, 
support and simple methods to work everything out of the box and maybe some 
nice extras.
The people who don't need this fancy stuff and are able to type 'make' in 
their shell can still download the source and get everything working on 
their own.

That's the way many commercial Open Source projects like Red Hat 
Enterprice, Android, or even Numpy work.

What should be avoided is of course making parts of the 'core' sage closed 
source. This should only maybe affect maybe some webapp stuff. (Why not 
sell a nice app on Google play?)
Sage is made from volunteer work, and taking money for service is fine, as 
long active developers who spend their freetime in making sage better
still have the right to get their software free of charge, and don't have 
drawbacks in using it.
 

On Friday, August 15, 2014 10:42:14 AM UTC+2, Dr. David Kirkby (Kirkby 
Microwave Ltd) wrote:
>
> As I understand it, the SageMathCloud is closed source. Yet it is 
> making extensive use of open-source code. Maybe the closed source bits 
> don't link to the open-source bits, though I find it a bit hard to 
> believe. If it did not link, it would not that be against the GPL? Or 
> I guess if the code is not distibuted, but only kept on a server, it 
> probably gets around the GPL. 
>
> If not against the GPL, this certainly seems to be going against the 
> *spirit* of the Sage project. It looks as though the intention is to 
> charge for access to a web service which makes use of open-source code 
> developed by many - myself included. 
>
> One might argue it is the same with any web service making use of 
> Apache for example, although I still think a closed-source 
> SageMathCloud is pushing the limits of what some (myself included), 
> find morally acceptable. 
>
> The only comment on the Wikipedia talk page 
>
> http://en.wikipedia.org/wiki/Talk:SageMathCloud 
>
> says "Unfortunately, some part of it is becoming closed source. And, 
> they will charge for the many of the services..." I don't know who 
> wrote that, but it was not me. 
>
> Maybe it is legal. I don't think it is morally right. 
>
> Dave 
>

-- 
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: How practical/useful would a native windows subset be?

[maldun]

Hi!

Python XY ( https://code.google.com/p/pythonxy/ )and WinPython 
(http://winpython.sourceforge.net/) do this for years now and are working 
properly. Maybe one can use this as a start since many of the needed 
prequisites are there.

but why not concentrate on a working cygwin port, and bundle everything to 
a working standalone executable? This would avoiding rewriting and 
spliiting the code in several parts which would also need to be maintained 
seperately.

On Monday, August 25, 2014 10:15:41 AM UTC+2, Dr. David Kirkby (Kirkby 
Microwave Ltd) wrote:
>
> It seems Sage really could do with a native windows port. I am wondering 
> how practical it would be to make a version which is a subset of Sage, with 
> something like Qt which runs on Windows,  Linux,  OSX and Solaris and has 
> the look and feel of those platforms. 
>
> It could make a Google Summer of Code project. 
>
> If a small subset could be implemented,  the chances are reasonable that 
> others might port more bits. If it could do more than a scientific 
> calculator,  that would probably be enough to get people using it.  Call it 
> "Mini Sage" or something similar to indicate it is not the full version. 
>
> I believe that there are some are some bits of Sage that uses fork and has 
> have no Windows equivalent, so those bits could be left out. Perhaps at a 
> later date a complete rewrite of such bits could form other GSOC projects. 
>
> The download size of such a subset would be smaller than the full version 
> and MUCH smaller that a virtual machine image, as one doesn't need to 
> include a complete operating system too.
>
> Wolfram Research did at one point offer a subset of Mathematica, which i 
> think was called Calc Centre, but I think it was a bit of a flop, so I 
> don't think that they sell it any more. That might be an argument for not 
> doing a partial native port. 
>
> If a partial port was done, avoiding the need for a browser, one could use 
> its own parser and provide a more confident interface.  Although many are 
> critical of Mathematica's interface,  it is more consistent than that of 
> Sage.
>
> Dave
>

-- 
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: User friendly output for divergant integrals/sum

[maldun]

+1

One could also go further and raise a PlusInfinitiyException or a 
MinusInfinityException and handle them correctly.

On Monday, January 6, 2014 5:39:56 PM UTC+1, Gregory Bard wrote:
>
> Perhaps we could get the best of both worlds?
>
> We could throw a "divergent integral/sum exception" (that can be two 
> exceptions or one, depending
> on how you look at what an integral really is...)
>
> This way, the calculus student would see the words "divergent integral" 
> and know what it means.
>
> However, the high performance programmer can catch the exception and do... 
> something... with it.
>
> Thoughts?
> ---Greg
>
> On Saturday, January 4, 2014 12:12:58 AM UTC-6, Vibhav Pant wrote:
>>
>> Sage currently handles divergant integrals/sums by raising a ValueError, 
>> wouldn't it be nice if a more user friendly output (like infinity or 
>> printing "divergant integral") could be used instead of raising an 
>> exception?
>
>

-- 
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: SymbolicPolynomial class

[maldun]

Well I guess doing symbolic computation in a clean fashion is never easy 
... 

I'm not unfimiliar with the notion of Picard-Vessiot extensions, but I will 
have a second look into it. Thanks for the input.

On Friday, December 20, 2013 8:19:33 PM UTC+1, Nils Bruin wrote:
>
> On Friday, December 20, 2013 2:58:51 AM UTC-10, maldun wrote:
>>
>> Another more careful approach would be to start at the field of rational 
>> functions and extend it step by step with algebraic and transcendental 
>> functions, till we reach a field which is maximal under the available 
>> symbolic expressions.
>>
> I hope you realize that you're going through the same steps as the 
> mathematicians who have been involved in developing axiom, macsyma, maple, 
> mathematica etc. before they settled for the mess that we have now? It may 
> well be possible to come up with a better way of dealing with things, but 
> you'll probably need a fundamentally new computational/representational 
> insight to get it.  And you'll probably not get something that is more 
> appealing to beginners than the apparent simplicity of the pen-and-paper 
> approach that SR takes to representing its elements (at least not at first).
>
> If you're interested in taking an algebraic approach to the functions that 
> arise from ordinary linear differential equations (and that includes a lot 
> of the functions relevant for calculus) you should read up on 
> Picard-Vessiot extensions.
>

-- 
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: SymbolicPolynomial class

[maldun]

Another more careful approach would be to start at the field of rational 
functions and extend it step by step with algebraic and transcendental 
functions, till we reach a field which is maximal under the available 
symbolic expressions.

On Friday, December 20, 2013 9:26:22 AM UTC+1, maldun wrote:
>
> On Thursday, December 19, 2013 7:47:19 PM UTC+1, Nils Bruin wrote:
>
>> On Wednesday, December 18, 2013 11:04:22 PM UTC-10, maldun wrote:
>>>
>>> What I mean is that we should only allow expressions of meromorphic 
>>> functions in the symbolic field, i.e. we would only allow variables, 
>>> trigonometric functions and so on.
>>> SR should be then a superset where everything else should also be 
>>> allowed.
>>>
>>  
>> I think you'll find that category is a little too small to even just do 
>> first year calculus: even log(z) isn't meromorphic (at z=0).
>>
>
> Good argument. Is it possible to reasonable relax the condition. E.g. 
> meromorphic almost everywhere in CC?
> Alternatively extend the field of meromorphic functions to the 
> differential field (M,d/dz) (see 
> http://en.wikipedia.org/wiki/Differential_algebra#Differential_field)
> Such a field can be extended by it's logarithms (so log(z) would be 
> contained) and all elementary functions also would be contained. 
> Additionally it's very useful
> for symbolic differentiation and integration.
>
>
>>
> On Thursday, December 19, 2013 8:05:15 PM UTC+1, vdelecroix wrote:
>>
>> And meromorphic functions are not stable under composition... 
>>
>
> Is this really relevant for symbolic calculus? At least the composition is 
> closed.
>

-- 
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: SymbolicPolynomial class

[maldun]

On Thursday, December 19, 2013 7:47:19 PM UTC+1, Nils Bruin wrote:

> On Wednesday, December 18, 2013 11:04:22 PM UTC-10, maldun wrote:
>>
>> What I mean is that we should only allow expressions of meromorphic 
>> functions in the symbolic field, i.e. we would only allow variables, 
>> trigonometric functions and so on.
>> SR should be then a superset where everything else should also be allowed.
>>
>  
> I think you'll find that category is a little too small to even just do 
> first year calculus: even log(z) isn't meromorphic (at z=0).
>

Good argument. Is it possible to reasonable relax the condition. E.g. 
meromorphic almost everywhere in CC?
Alternatively extend the field of meromorphic functions to the differential 
field (M,d/dz) 
(see http://en.wikipedia.org/wiki/Differential_algebra#Differential_field)
Such a field can be extended by it's logarithms (so log(z) would be 
contained) and all elementary functions also would be contained. 
Additionally it's very useful
for symbolic differentiation and integration.


>
On Thursday, December 19, 2013 8:05:15 PM UTC+1, vdelecroix wrote:
>
> And meromorphic functions are not stable under composition... 
>

Is this really relevant for symbolic calculus? At least the composition is 
closed.

-- 
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: SymbolicPolynomial class

[maldun]

Sorry my Mistake, but if you look into the text you quoted, I already 
corrected it:  
...
> ... The ring of analytic 
> functions is an Integral domain. 
...
Continous is of course not sufficient.

On Thursday, December 19, 2013 10:12:15 AM UTC+1, John Cremona wrote:
>
> On 19 December 2013 09:04, maldun > wrote: 
> > The fact, that SR is not a field is interesting, the Kronecker delta 
> example 
> > on the ticket shows it quite well. But the problem originates from the 
> fact, 
> > that the Kronecker delta is not a continuous function. The ring of 
> analytic 
> > functions is an Integral domain. 
>
> No it is not.  The product of max(0,x) and max(0,-x) is 0. 
>
> John 
>
> > 
> > Question: Should we define a subset of SR which is a field (at least in 
> > theory) to make some things cleaner? A quite practical approach 
> > would be the field of meromorphic functions, which covers the most daily 
> > problems in symbolic computation. (It would be also quite interesting in 
> > view of defining differential algebras) 
> > 
> > What I mean is that we should only allow expressions of meromorphic 
> > functions in the symbolic field, i.e. we would only allow variables, 
> > trigonometric functions and so on. 
> > SR should be then a superset where everything else should also be 
> allowed. 
> > 
> > On Wednesday, December 18, 2013 8:18:56 PM UTC+1, Nils Bruin wrote: 
> >> 
> >> On Wednesday, December 18, 2013 9:58:15 AM UTC-8, vdelecroix wrote: 
> >>> 
> >>> Users of polynomials should worry about the coefficient ring. What do 
> >>> someone should expect of 
> >>> 
> >>> sage: (6*x^2 - 12).factor() 
> >>> 
> >>> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic 
> >>> polynomial there is no way to make it coherent... 
> >> 
> >> It's worse: SR isn't even an exact ring (and it has zero divisors; 
> >> seehttp://trac.sagemath.org/ticket/11126#comment:2) , so a lot of 
> polynomial 
> >> arithmetic you'd normally expect to work, doesn't in general. 
> >> 
> >> So yes we can define polynomial rings with coefficients in SR: 
> >> 
> >> sage: SR['x'] 
> >> Univariate Polynomial Ring in x over Symbolic Ring 
> >> sage: (1+sin(2))*x-2.3 
> >> (sin(2) + 1)*x - 2.30 
> >> 
> >> but any nontrivial computation in it will be problematic (I take this 
> as 
> >> definition of nontrivial here). 
> >> 
> >>> 
> >>> And I guess a long term goal of Sage would be to make it disappear. 
> >> 
> >> 
> >> It IS good for some things: integration strategies and some symbolic 
> >> differential equation solving methods do benefit from the loose 
> approach 
> >> that SR takes with mathematical expressions. 
> >> I think a more attainable goal is to allow the user to avoid SR in as 
> many 
> >> cases as possible. 
> > 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to 
> > sage-...@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] Re: SymbolicPolynomial class

[maldun]

Sorry my Mistake, but if you look into the text you quoted, I already it:  
...
> that the Kronecker delta is not a continuous function. The ring of 
analytic 
> functions is an Integral domain. 
...
Continous is of course not sufficient.

On Thursday, December 19, 2013 10:12:15 AM UTC+1, John Cremona wrote:
>
> On 19 December 2013 09:04, maldun > wrote: 
> > The fact, that SR is not a field is interesting, the Kronecker delta 
> example 
> > on the ticket shows it quite well. But the problem originates from the 
> fact, 
> > that the Kronecker delta is not a continuous function. The ring of 
> analytic 
> > functions is an Integral domain. 
>
> No it is not.  The product of max(0,x) and max(0,-x) is 0. 
>
> John 
>
> > 
> > Question: Should we define a subset of SR which is a field (at least in 
> > theory) to make some things cleaner? A quite practical approach 
> > would be the field of meromorphic functions, which covers the most daily 
> > problems in symbolic computation. (It would be also quite interesting in 
> > view of defining differential algebras) 
> > 
> > What I mean is that we should only allow expressions of meromorphic 
> > functions in the symbolic field, i.e. we would only allow variables, 
> > trigonometric functions and so on. 
> > SR should be then a superset where everything else should also be 
> allowed. 
> > 
> > On Wednesday, December 18, 2013 8:18:56 PM UTC+1, Nils Bruin wrote: 
> >> 
> >> On Wednesday, December 18, 2013 9:58:15 AM UTC-8, vdelecroix wrote: 
> >>> 
> >>> Users of polynomials should worry about the coefficient ring. What do 
> >>> someone should expect of 
> >>> 
> >>> sage: (6*x^2 - 12).factor() 
> >>> 
> >>> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic 
> >>> polynomial there is no way to make it coherent... 
> >> 
> >> It's worse: SR isn't even an exact ring (and it has zero divisors; 
> >> seehttp://trac.sagemath.org/ticket/11126#comment:2) , so a lot of 
> polynomial 
> >> arithmetic you'd normally expect to work, doesn't in general. 
> >> 
> >> So yes we can define polynomial rings with coefficients in SR: 
> >> 
> >> sage: SR['x'] 
> >> Univariate Polynomial Ring in x over Symbolic Ring 
> >> sage: (1+sin(2))*x-2.3 
> >> (sin(2) + 1)*x - 2.30 
> >> 
> >> but any nontrivial computation in it will be problematic (I take this 
> as 
> >> definition of nontrivial here). 
> >> 
> >>> 
> >>> And I guess a long term goal of Sage would be to make it disappear. 
> >> 
> >> 
> >> It IS good for some things: integration strategies and some symbolic 
> >> differential equation solving methods do benefit from the loose 
> approach 
> >> that SR takes with mathematical expressions. 
> >> I think a more attainable goal is to allow the user to avoid SR in as 
> many 
> >> cases as possible. 
> > 
> > -- 
> > 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+...@googlegroups.com . 
> > To post to this group, send email to 
> > sage-...@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] Re: SymbolicPolynomial class

[maldun]

The fact, that SR is not a field is interesting, the Kronecker delta 
example on the ticket shows it quite well. But the problem originates from 
the fact,
that the Kronecker delta is not a continuous function. The ring of analytic 
functions is an Integral domain.
Question: Should we define a subset of SR which is a field (at least in 
theory) to make some things cleaner? A quite practical approach
would be the field of meromorphic functions, which covers the most daily 
problems in symbolic computation. (It would be also quite interesting in 
view of defining differential algebras) 

What I mean is that we should only allow expressions of meromorphic 
functions in the symbolic field, i.e. we would only allow variables, 
trigonometric functions and so on.
SR should be then a superset where everything else should also be allowed.

On Wednesday, December 18, 2013 8:18:56 PM UTC+1, Nils Bruin wrote:
>
> On Wednesday, December 18, 2013 9:58:15 AM UTC-8, vdelecroix wrote:
>>
>> Users of polynomials should worry about the coefficient ring. What do 
>> someone should expect of 
>>
>> sage: (6*x^2 - 12).factor() 
>>
>> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic 
>> polynomial there is no way to make it coherent... 
>>
> It's worse: SR isn't even an exact ring (and it has zero divisors; 
> seehttp://trac.sagemath.org/ticket/11126#comment:2) , so a lot of 
> polynomial arithmetic you'd normally expect to work, doesn't in general.
>
> So yes we can define polynomial rings with coefficients in SR:
>
> sage: SR['x']
> Univariate Polynomial Ring in x over Symbolic Ring
> sage: (1+sin(2))*x-2.3
> (sin(2) + 1)*x - 2.30
>
> but any nontrivial computation in it will be problematic (I take this as 
> definition of nontrivial here).
>  
>
>> And I guess a long term goal of Sage would be to make it disappear. 
>>
>
> It IS good for some things: integration strategies and some symbolic 
> differential equation solving methods do benefit from the loose approach 
> that SR takes with mathematical expressions.
> I think a more attainable goal is to allow the user to avoid SR in as many 
> cases as possible.
>

-- 
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: SymbolicPolynomial class

[maldun]

This isn't exactly a question of mathematical correctness, but of usability.
Think of users who aren't mathematicians, but engineers or from physics.
Most of them even don't know the difference between a polynomial from ZZ or 
RR.

So the goal should be a good default behavior which covers 70-90% of all 
standard use cases.
A way would be to let the class look for the smallest ring where all 
coefficients are in (e.g.  (6*x^2 - 12) should be identified as element of 
ZZ[x])
and then apply factorisation over that ring. (compare with other CAS like 
Mathematica or Maple or look what Wolfram Alpha gives as answer)

Of course one could argue that this should eventually be done by the 
preparser. But a specific class could help providing clean conversion 
methods.
E.g. one could do: 
f = x^2 - 1.
f.set_ring(RR) 

On Wednesday, December 18, 2013 6:58:15 PM UTC+1, vdelecroix wrote:
>
> Users of polynomials should worry about the coefficient ring. What do 
> someone should expect of 
>
> sage: (6*x^2 - 12).factor() 
>
> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic 
> polynomial there is no way to make it coherent... 
>
> Moreover, I feel very uncomfortable having an extra layer with 
> symbolic polynomial. Most of the time, the symbolic ring should just 
> be avoided. And I guess a long term goal of Sage would be to make it 
> disappear. 
>
> Vincent 
>
> 2013/12/18, maldun >: 
> > Why reinvent the wheel? A symbolic polynomal class should be capable of 
> a 
> > type checking of the coefficients and transform the polynomial 
> internally 
> > into the correct setting and then call the correct algorithms and 
> methods. 
> > 
> > The main purpose of such a class is that the user can work intuitively 
> with 
> > 
> > polynomials, without worrying about the right rings and types. The main 
> > challenge for that is to design an intelligent default behavior, which 
> is 
> > satisfying for the most use cases. 
> > If the usage of the class is  inconvenient for some use cases, one could 
> go 
> > 
> > back to the classical polynomial rings. 
> > The other benefit is the possibility to extend the class for symbolic 
> > usage. 
> > 
> > On Wednesday, December 18, 2013 12:04:28 PM UTC+1, Simon King wrote: 
> >> 
> >> Hi again, 
> >> 
> >> On 2013-12-18, maldun > wrote: 
> >> > 1) I think that applying Polynomial division by commands like 
> >> > 
> >> > sage: f(x)=3Dx^3+5*x^2-3*x+1 
> >> > sage: g(x)=3Dx+1 
> >> > sage: f.maxima_methods().divide(g) 
> >> > [x^2 + 4*x - 7, 8] 
> >> > 
> >> > are not very intuitive. 
> >> 
> >> These aren't polynomials but symbolic expressions. If you want 
> >> polynomial division, use polynomials: 
> >> 
> >>   sage: P. = QQ[] 
> >>   sage: f = x^3+5*x^2-3*x+1 
> >>   sage: g = x+1 
> >>   sage: f.quo_rem(g) 
> >>   (x^2 + 4*x - 7, 8) 
> >>   sage: f//g 
> >>   x^2 + 4*x - 7 
> >>   sage: f%g 
> >>   8 
> >>   sage: f == (f//g)*g + f%g 
> >>   True 
> >> 
> >> > 2) As mentioned direct call of algorithms (e.g. compute gcd, 
> Gr=F6bner 
> >> basi= 
> >> > s etc.) 
> >> 
> >> ... which exists in Sage. Just use polynomials and not symbolic 
> >> expressions. 
> >> 
> >> 
> >> > 3) More symbolic manipulation possibilities for specific for symbolic 
> >> polyn= 
> >> > omials. 
> >> 
> >> Right, that's in the "symbolic expression world". 
> >> 
> >> > 4) faster and numerical more stable evaluation methods 
> >> 
> >> Is there a reason to not implement this on the level of the *existing* 
> >> polynomials with coefficients in RR or CC? 
> >> 
> >> Up to now I don't see a compelling reason for introducing yet another 
> >> class of polynomials. One should use the right tool for the job. In 
> >> the job examples you gave, it seems to me that symbolic expressions 
> >> are not the right tool, but there *are* easily accessible suitable 
> >> tools in Sage. 
> >> 
> >> - for 1) you will probably be able to use existing polynomial classes, 
> >>   which will be a lot faster than calling maxima---unless you have 
> >>   quite exotic coefficients, but in this case the notion of division 
> >>   with remainder might not even make sense. 
> >> 
> >> - for 2) you certainly do not want to re-invent th

Re: [sage-devel] Re: SymbolicPolynomial class

[maldun]

This isn't exactly a question of mathematical correctness, but of usability.
Think of users who aren't mathematicians, but engineers or from physics.
Most of them even don't know the difference between a polynomial from ZZ or 
RR.

So the goal should be a good default behavior which covers 70-90% of all 
standard use cases.
A way would be to let the class look for the smallest ring where all 
coefficients are in (e.g.  (6*x^2 - 12) should be identified as element of 
ZZ[x])
and then apply factorisation over that ring. (compare with other CAS like 
Mathematica or Maple)

Of course one could argue that this should eventually be done by the 
preparser. But a specific class could help providing clean conversion 
methods.

On Wednesday, December 18, 2013 6:58:15 PM UTC+1, vdelecroix wrote:
>
> Users of polynomials should worry about the coefficient ring. What do 
> someone should expect of 
>
> sage: (6*x^2 - 12).factor() 
>
> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic 
> polynomial there is no way to make it coherent... 
>
> Moreover, I feel very uncomfortable having an extra layer with 
> symbolic polynomial. Most of the time, the symbolic ring should just 
> be avoided. And I guess a long term goal of Sage would be to make it 
> disappear. 
>
> Vincent 
>
> 2013/12/18, maldun >: 
> > Why reinvent the wheel? A symbolic polynomal class should be capable of 
> a 
> > type checking of the coefficients and transform the polynomial 
> internally 
> > into the correct setting and then call the correct algorithms and 
> methods. 
> > 
> > The main purpose of such a class is that the user can work intuitively 
> with 
> > 
> > polynomials, without worrying about the right rings and types. The main 
> > challenge for that is to design an intelligent default behavior, which 
> is 
> > satisfying for the most use cases. 
> > If the usage of the class is  inconvenient for some use cases, one could 
> go 
> > 
> > back to the classical polynomial rings. 
> > The other benefit is the possibility to extend the class for symbolic 
> > usage. 
> > 
> > On Wednesday, December 18, 2013 12:04:28 PM UTC+1, Simon King wrote: 
> >> 
> >> Hi again, 
> >> 
> >> On 2013-12-18, maldun > wrote: 
> >> > 1) I think that applying Polynomial division by commands like 
> >> > 
> >> > sage: f(x)=3Dx^3+5*x^2-3*x+1 
> >> > sage: g(x)=3Dx+1 
> >> > sage: f.maxima_methods().divide(g) 
> >> > [x^2 + 4*x - 7, 8] 
> >> > 
> >> > are not very intuitive. 
> >> 
> >> These aren't polynomials but symbolic expressions. If you want 
> >> polynomial division, use polynomials: 
> >> 
> >>   sage: P. = QQ[] 
> >>   sage: f = x^3+5*x^2-3*x+1 
> >>   sage: g = x+1 
> >>   sage: f.quo_rem(g) 
> >>   (x^2 + 4*x - 7, 8) 
> >>   sage: f//g 
> >>   x^2 + 4*x - 7 
> >>   sage: f%g 
> >>   8 
> >>   sage: f == (f//g)*g + f%g 
> >>   True 
> >> 
> >> > 2) As mentioned direct call of algorithms (e.g. compute gcd, 
> Gr=F6bner 
> >> basi= 
> >> > s etc.) 
> >> 
> >> ... which exists in Sage. Just use polynomials and not symbolic 
> >> expressions. 
> >> 
> >> 
> >> > 3) More symbolic manipulation possibilities for specific for symbolic 
> >> polyn= 
> >> > omials. 
> >> 
> >> Right, that's in the "symbolic expression world". 
> >> 
> >> > 4) faster and numerical more stable evaluation methods 
> >> 
> >> Is there a reason to not implement this on the level of the *existing* 
> >> polynomials with coefficients in RR or CC? 
> >> 
> >> Up to now I don't see a compelling reason for introducing yet another 
> >> class of polynomials. One should use the right tool for the job. In 
> >> the job examples you gave, it seems to me that symbolic expressions 
> >> are not the right tool, but there *are* easily accessible suitable 
> >> tools in Sage. 
> >> 
> >> - for 1) you will probably be able to use existing polynomial classes, 
> >>   which will be a lot faster than calling maxima---unless you have 
> >>   quite exotic coefficients, but in this case the notion of division 
> >>   with remainder might not even make sense. 
> >> 
> >> - for 2) you certainly do not want to re-invent the wheel. Sage uses 
> >>   (mainly) Singular to do Gröbner computations when working w

Re: [sage-devel] Re: SymbolicPolynomial class

[maldun]

The fact, that SR is not a field is interesting, the Kronecker delta 
example on the ticket shows it quite well. But the problem originates from 
the fact,
that the Kronecker delta is not a continuous function. The ring of 
continuous functions is an Integral domain.
Question: Should we define a subset of SR which is a field (at least in 
theory) to make some things cleaner? A quite practical approach
would be the field of meromorphic functions, which covers the most daily 
problems in symbolic computation. (It would be also quite interesting in 
view of defining differential algebras) 

What I mean is that we should only allow expressions of meromorphic 
functions in the symbolic field, i.e. we would only allow variables, 
trigonometric functions and so on.
SR should be then a superset where everything else should also be allowed.

On Wednesday, December 18, 2013 8:18:56 PM UTC+1, Nils Bruin wrote:
>
> On Wednesday, December 18, 2013 9:58:15 AM UTC-8, vdelecroix wrote:
>>
>> Users of polynomials should worry about the coefficient ring. What do 
>> someone should expect of 
>>
>> sage: (6*x^2 - 12).factor() 
>>
>> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic 
>> polynomial there is no way to make it coherent... 
>>
> It's worse: SR isn't even an exact ring (and it has zero divisors; 
> seehttp://trac.sagemath.org/ticket/11126#comment:2) , so a lot of 
> polynomial arithmetic you'd normally expect to work, doesn't in general.
>
> So yes we can define polynomial rings with coefficients in SR:
>
> sage: SR['x']
> Univariate Polynomial Ring in x over Symbolic Ring
> sage: (1+sin(2))*x-2.3
> (sin(2) + 1)*x - 2.30
>
> but any nontrivial computation in it will be problematic (I take this as 
> definition of nontrivial here).
>  
>
>> And I guess a long term goal of Sage would be to make it disappear. 
>>
>
> It IS good for some things: integration strategies and some symbolic 
> differential equation solving methods do benefit from the loose approach 
> that SR takes with mathematical expressions.
> I think a more attainable goal is to allow the user to avoid SR in as many 
> cases as possible.
>

-- 
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: SymbolicPolynomial class

[maldun]

The fact, that SR is not a field is interesting, the Kronecker delta 
example on the ticket shows it quite well. But the problem originates from 
the fact,
that the Kronecker delta is not a continuous function. The ring of 
continuous functions is an Integral domain.
Question: Should we define a subset of SR which is a field (at least in 
theory) to make some things cleaner? A quite practical approach
would be the field of meromorphic functions, which covers the most daily 
problems in symbolic computation. (It would be also quite interesting in 
view of defining differential algebras) 

On Wednesday, December 18, 2013 8:18:56 PM UTC+1, Nils Bruin wrote:
>
> On Wednesday, December 18, 2013 9:58:15 AM UTC-8, vdelecroix wrote:
>>
>> Users of polynomials should worry about the coefficient ring. What do 
>> someone should expect of 
>>
>> sage: (6*x^2 - 12).factor() 
>>
>> The answers are different in ZZ[x], QQ[x] and RR[x]. For a symbolic 
>> polynomial there is no way to make it coherent... 
>>
> It's worse: SR isn't even an exact ring (and it has zero divisors; 
> seehttp://trac.sagemath.org/ticket/11126#comment:2) , so a lot of 
> polynomial arithmetic you'd normally expect to work, doesn't in general.
>
> So yes we can define polynomial rings with coefficients in SR:
>
> sage: SR['x']
> Univariate Polynomial Ring in x over Symbolic Ring
> sage: (1+sin(2))*x-2.3
> (sin(2) + 1)*x - 2.30
>
> but any nontrivial computation in it will be problematic (I take this as 
> definition of nontrivial here).
>  
>
>> And I guess a long term goal of Sage would be to make it disappear. 
>>
>
> It IS good for some things: integration strategies and some symbolic 
> differential equation solving methods do benefit from the loose approach 
> that SR takes with mathematical expressions.
> I think a more attainable goal is to allow the user to avoid SR in as many 
> cases as possible.
>

-- 
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.

[sage-devel] Re: SageManifolds v0.3

[maldun]

Good Job!

But I have to agree with Volker, using strings is not a good idea.
Why not using functions as input instead?

e.g. in your example from the tutorial:

X. = M.chart('x y z', 'xyz')

I would use something like
var('x y z')
charti = x*y*z

X = M.chart(vars = [x,y,z], map = charti)


On Sunday, November 24, 2013 10:32:45 PM UTC+1, Eric Gourgoulhon wrote:
>
> Hi,
>
> We have just posted a new version (0.3) of SageManifolds at 
> http://sagemanifolds.obspm.fr
> SageManifolds is an attempt to include differential geometry and tensor 
> calculus in Sage (cf. the initial 
> post, 
> the v0.2 post 
>  
> and trac 
> 14865).
>  
> It is still in some preliminary stage but following the comments made on 
> this list and during meetings of Paris Sage group (thanks to all!), we have 
> worked towards a better integration into Sage. In particular:
>
>- Parent / Element scheme is now used for Manifold / Point
>- The instantiation of most objects is now performed via factory 
>methods, so that there is no need to have the class name in the global 
>namespace and tab completion can be used to guess the method to employ. 
>- The coordinates associated with a chart are no longer put by default 
>in the global namespace; to do so, one has to use the preparser tool 
> during the chart instantiation. 
>
> For example, the sphere S^2, along with the two charts associated with 
> stereographic projections from two poles, is set up as follows:
>
> sage: M = Manifold(2, 'S^2') # 2 = dimension of the manifold
> sage: U = M.open_domain('U') # the complement of the North pole
> sage: stereoN. = U.chart('x y', 'stereoN') # (x,y) = stereographic 
> coord. from the North pole
> sage: V = M.open_domain('V') # the complement of the South pole
> sage: stereoS. = V.chart('u v', 'stereoS') # (u,v) = stereographic 
> coord. from the South pole
> sage: phi = stereoN.transition_map(stereoS, (x/(x^2+y^2), y/(x^2+y^2)), \
> :  intersection_name='W', \
> :   chart1_name='stereoN_W', restrictions1=[x^2+y^2!=0
> ], \
> :   chart2_name='stereoS_W', restrictions2=[u^2+v^2!=0
> ])
> sage: phi(x,y)
> (x/(x^2 + y^2), y/(x^2 + y^2))
> sage: M.domains['W'] is U.intersection(V)
> True
> sage: M.atlas
> {'stereoN': chart 'stereoN' (U, (x, y)),
>  'stereoN_W': chart 'stereoN_W' (W, (x, y)),
>  'stereoS': chart 'stereoS' (V, (u, v)),
>  'stereoS_W': chart 'stereoS_W' (W, (u, v))}
> sage: M.frames
> {'stereoN_W_b': coordinate basis 'stereoN_W_b' (d/dx,d/dy),
>  'stereoN_b': coordinate basis 'stereoN_b' (d/dx,d/dy),
>  'stereoS_W_b': coordinate basis 'stereoS_W_b' (d/du,d/dv),
>  'stereoS_b': coordinate basis 'stereoS_b' (d/du,d/dv)}
>
>
> The sphere example is detailed on 
> http://sagemanifolds.obspm.fr/examples.html (embedding into R^3, induced 
> metric, curvature, spherical coordinates).
>
> Many things remain to be done. People interested in contributing are 
> welcome! We have set up a git repository (
> https://gitroc.obspm.fr/gitweb/SageManifolds.git) for this (see the 
> instructions here), as well as a mailing list.
>
> Eric Gourgoulhon & Michal Bejger.
>
>

-- 
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.

[sage-devel] Re: SymbolicPolynomial class

[maldun]

Why reinvent the wheel? A symbolic polynomal class should be capable of a 
type checking of the coefficients and transform the polynomial internally 
into the correct setting and then call the correct algorithms and methods.

The main purpose of such a class is that the user can work intuitively with 
polynomials, without worrying about the right rings and types. The main 
challenge for that is to design an intelligent default behavior, which is 
satisfying for the most use cases.
If the usage of the class is  inconvenient for some use cases, one could go 
back to the classical polynomial rings.
The other benefit is the possibility to extend the class for symbolic usage.


On Wednesday, December 18, 2013 12:04:28 PM UTC+1, Simon King wrote:
>
> Hi again, 
>
> On 2013-12-18, maldun > wrote: 
> > 1) I think that applying Polynomial division by commands like 
> > 
> > sage: f(x)=3Dx^3+5*x^2-3*x+1 
> > sage: g(x)=3Dx+1 
> > sage: f.maxima_methods().divide(g) 
> > [x^2 + 4*x - 7, 8] 
> > 
> > are not very intuitive. 
>
> These aren't polynomials but symbolic expressions. If you want 
> polynomial division, use polynomials: 
>
>   sage: P. = QQ[] 
>   sage: f = x^3+5*x^2-3*x+1 
>   sage: g = x+1 
>   sage: f.quo_rem(g) 
>   (x^2 + 4*x - 7, 8) 
>   sage: f//g 
>   x^2 + 4*x - 7 
>   sage: f%g 
>   8 
>   sage: f == (f//g)*g + f%g 
>   True 
>
> > 2) As mentioned direct call of algorithms (e.g. compute gcd, Gr=F6bner 
> basi= 
> > s etc.) 
>
> ... which exists in Sage. Just use polynomials and not symbolic 
> expressions. 
>
>
> > 3) More symbolic manipulation possibilities for specific for symbolic 
> polyn= 
> > omials. 
>
> Right, that's in the "symbolic expression world". 
>
> > 4) faster and numerical more stable evaluation methods 
>
> Is there a reason to not implement this on the level of the *existing* 
> polynomials with coefficients in RR or CC? 
>
> Up to now I don't see a compelling reason for introducing yet another 
> class of polynomials. One should use the right tool for the job. In 
> the job examples you gave, it seems to me that symbolic expressions 
> are not the right tool, but there *are* easily accessible suitable 
> tools in Sage. 
>
> - for 1) you will probably be able to use existing polynomial classes, 
>   which will be a lot faster than calling maxima---unless you have 
>   quite exotic coefficients, but in this case the notion of division 
>   with remainder might not even make sense. 
>
> - for 2) you certainly do not want to re-invent the wheel. Sage uses 
>   (mainly) Singular to do Gröbner computations when working with 
>   coefficients in finite fields and QQ, and I think ZZ and function fields 
>   as well. If you want to beat Singular with an implementation that is 
>   based on symbolic expressions, you should be prepared for some years 
>   of work. Again, if you have exotic coefficient domains that Singular 
>   can't deal with, then a new implementation might make more sense. In 
>   this case: There is a toy implementation of the Buchberger algorithm 
>   and I think also of F5 algorithm somewhere in Sage, which should work 
>   with exotic coefficients and which you may try to improve. 
>
> - for 3), this makes sense. The question is if this requires a whole new 
>   fully fledged polynomial class. 
>
> - for 4), it seems to me that this should be done in 
>   sage.rings.polynomial.polynomial_real_mpfr_dense.PolynomialRealDense 
>   respectively in 
>   
> sage.rings.polynomial.polynomial_element_generic.Polynomial_generic_dense_field
>  
>
>
> Best regards, 
> Simon 
>
>
>

-- 
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.

[sage-devel] Re: SymbolicPolynomial class

[maldun]

And another thing: A more unified interface for polynomials.

Currently we have, as you mentioned, three ways to define polynomials. It 
would enable us to design a class which provides a good default behavior 
for the average user.

-- 
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.

[sage-devel] Re: Remaining Mercurial patches

[maldun]

On Tuesday, December 17, 2013 3:01:47 PM UTC+1, Volker Braun wrote:
>
> On Tuesday, December 17, 2013 12:34:31 PM UTC, maldun wrote:
>>
>> And I have another question: why github?
>>
>
> We only use github to mirror our own repo to save bandwidth. All 
> development is done with our own git server.
>
>
>  
>
Ok this makes sense. Thanks for the answer! 

-- 
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.

[sage-devel] Re: SymbolicPolynomial class

[maldun]

1) I think that applying Polynomial division by commands like

sage: f(x)=x^3+5*x^2-3*x+1
sage: g(x)=x+1
sage: f.maxima_methods().divide(g)
[x^2 + 4*x - 7, 8]

are not very intuitive. This should be done by specific methods/operators for 
polynomials, and this can only be done by a specific class for polynomials.

2) As mentioned direct call of algorithms (e.g. compute gcd, Gröbner basis etc.)

3) More symbolic manipulation possibilities for specific for symbolic 
polynomials.

4) faster and numerical more stable evaluation methods 


On Tuesday, December 17, 2013 5:23:20 PM UTC+1, Simon King wrote:
>
> Hi, 
>
> On 2013-12-17, maldun > wrote: 
> > On ticket http://trac.sagemath.org/ticket/9706 for the orthogonal 
> > Polynomials Jeroen Demeyer came up with the the idea of a 
> > SymbolicPolynomial class. I think that's a great idea, because, if well 
> > designed, such a class has much potential to give very much comfort to 
> the 
> > handling of sage. Because many algorithms that deal with Polynomials 
> have 
> > to be called from external programs and libraries. 
>
> I don't see the point here. 
>
> On the sage-support list, one quite often sees questions that boil down to 
> the misunderstanding that a symbolic polynomial 
>   sage: var('x') 
>   x 
>   sage: x^2+1 
>   x^2 + 1 
>   sage: type(x^2+1) 
>
>
> and a symbolic polynomial function 
>   sage: f(x) = x^2+1 
>   sage: f 
>   x |--> x^2 + 1 
>   sage: type(f) 
>
>
> and an element of a polynomial ring 
>   sage: P. = GF(5)[] 
>   sage: x^2+1 
>   x^2 + 1 
>   sage: type(x^2+1) 
>'sage.rings.polynomial.polynomial_zmod_flint.Polynomial_zmod_flint'> 
>
> have the same range of applications. Very often, the posters on 
> sage-support were using symbolic expressions but should rather be using 
> polynomials, for efficiency. 
>
> So, what exactly would be the purpose of a SymbolicPolynomial class? And 
> why do you think that the existence of such a class could give much 
> comfort to the handling of sage (even when you restrict this statements 
> to users such as myself, who use multivariate polynomials on a daily 
> basis, 
> in the sense of computing Gröbner bases and test for membership in 
> polynomial 
> ideals)? 
>
> Best regards, 
> Simon 
>
>
>

-- 
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.

[sage-devel] Re: Remaining Mercurial patches

[maldun]

or better for the client: hg-git (http://hg-git.github.io/)

On Tuesday, December 17, 2013 1:26:23 PM UTC+1, maldun wrote:
>
> Why not use git-hg? https://github.com/cosmin/git-hg
>
> On Monday, December 16, 2013 11:51:27 AM UTC+1, Volker Braun wrote:
>>
>> I would recommend people change their mercurial patches to git branches, 
>> even only if to get their feet wet with git and the "sage -dev" scripts. 
>> But I will merge mercurial tickets, too.
>>
>> For now it is still possible to use mercurial & sage-5.13 to develop, but 
>> as time passes this will become less feasible.
>>
>>
>>
>> On Monday, December 16, 2013 9:56:11 AM UTC, Jeroen Demeyer wrote:
>>>
>>> There are various tickets having positive_review which have Mercurial 
>>> patches. Will these need to be changed to a git branch before they can 
>>> be merged or will the release manager take care of this? 
>>>
>>> What about Mercurial patches which are currently 
>>> needs_work/needs_review? Can these be finished in Mercurial-world or is 
>>> that a bad idea? 
>>>
>>> Jeroen. 
>>>
>>

-- 
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.

[sage-devel] Re: Remaining Mercurial patches

[maldun]

And I have another question: why github? afaik bitbucket would allow to use 
both git and mercurial. So it is possible for users to submit a mercurial 
patch on a git repo and vice versa. I think this would avoid a lot of 
compability issues.
I peronally prefer git, but I guess there are a lot of people who prefer 
mercurial for some reasons, and sage was built on mercurial from the 
beginning.

On Monday, December 16, 2013 11:51:27 AM UTC+1, Volker Braun wrote:
>
> I would recommend people change their mercurial patches to git branches, 
> even only if to get their feet wet with git and the "sage -dev" scripts. 
> But I will merge mercurial tickets, too.
>
> For now it is still possible to use mercurial & sage-5.13 to develop, but 
> as time passes this will become less feasible.
>
>
>
> On Monday, December 16, 2013 9:56:11 AM UTC, Jeroen Demeyer wrote:
>>
>> There are various tickets having positive_review which have Mercurial 
>> patches. Will these need to be changed to a git branch before they can 
>> be merged or will the release manager take care of this? 
>>
>> What about Mercurial patches which are currently 
>> needs_work/needs_review? Can these be finished in Mercurial-world or is 
>> that a bad idea? 
>>
>> Jeroen. 
>>
>

-- 
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.

[sage-devel] Re: Remaining Mercurial patches

[maldun]

Why not use git-hg? https://github.com/cosmin/git-hg

On Monday, December 16, 2013 11:51:27 AM UTC+1, Volker Braun wrote:
>
> I would recommend people change their mercurial patches to git branches, 
> even only if to get their feet wet with git and the "sage -dev" scripts. 
> But I will merge mercurial tickets, too.
>
> For now it is still possible to use mercurial & sage-5.13 to develop, but 
> as time passes this will become less feasible.
>
>
>
> On Monday, December 16, 2013 9:56:11 AM UTC, Jeroen Demeyer wrote:
>>
>> There are various tickets having positive_review which have Mercurial 
>> patches. Will these need to be changed to a git branch before they can 
>> be merged or will the release manager take care of this? 
>>
>> What about Mercurial patches which are currently 
>> needs_work/needs_review? Can these be finished in Mercurial-world or is 
>> that a bad idea? 
>>
>> Jeroen. 
>>
>

-- 
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.

[sage-devel] SymbolicPolynomial class

[maldun]

Hi all!

On ticket http://trac.sagemath.org/ticket/9706 for the orthogonal 
Polynomials Jeroen Demeyer came up with the the idea of a 
SymbolicPolynomial class. I think that's a great idea, because, if well 
designed, such a class has much potential to give very much comfort to the 
handling of sage. Because many algorithms that deal with Polynomials have 
to be called from external programs and libraries.

I already have two things which should be added to such a class:

The // operator should enforce polynomial division and return the result, 
while the % operator should return the remainder of the division.
E.g:

(x^2 - 2)//(x+1) returns x-1 and (x^2 - 2) % (x+1) returns -1

+ we could add features for polynomial algebra

More input welcome 

-- 
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.

[sage-devel] New Orthogonal Polynomials - The second try

[maldun]

Hi!

after some years and finishing my Phd, I finally found some time and the 
need to implement a new version of orthogonal polynomials.
Over the time I have many valuable lessons learned, and I now want to make 
the whole development trough.

I posted a new patch on http://trac.sagemath.org/ticket/9706 and ask for 
review.
but this time I don't want to add all polys at once, but only add the 
chebyshev polys first, and when this patch works and has positive review I 
add the next classes.
I hope this way it is less frustrating, for me and the reviewer, because it 
is a whole bunch of code, and its tiring to test and look through about 
2000 lines of code.

Hope this approach is ok for you, but I think it is better the get new 
polys every few version, instead of getting no new classes.

cheers maldun 


-- 
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.

[sage-devel] Re: Where should Fourier sum stop?

[maldun]

It is not only more pythonic if you cut the series at N-1 it is also
natural
if you are used to work with spectral methods and ffts, because a
trig. poly. with deg
N-1 has N coefficients, since the constant term has degree 0.

greez
Maldun

On Jun 18, 2:25 am, Andrey Novoseltsev  wrote:
> Hello,
>
> There is a discrepancy between the documentation and behaviour of
> partial sums of Fourier series:http://trac.sagemath.org/sage_trac/ticket/8603
>
> If the cut-off parameter is N, then the documentation says that N-th
> term will be included, but it is not.
>
> To fix it, one should either adjust the documentation, which is easy
> and does not break any code, or change the behaviour, which leads to
> exceptions in doctests and can break similar user code. What should we
> do? Including N seems a bit more natural, but stopping at N-1 is more
> Pythonic, i.e. like range(N).
>
> Thank you,
> Andrey

-- 
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: toying with various upgrades (numpy,ecl,maxima,gfan,mpfi)

[maldun]

If you want I could make the numpy update again. Since most necessary
patches of the Bugs we found in #9808 should be merged in 1.5.1 this
should be rather easy.

regards,
Stefan

On Jan 27, 2:45 pm, kcrisman  wrote:
> On Jan 27, 5:30 am, François Bissey 
> wrote:
>
> > Hi all,
>
> > so it's that time again where I look at how "easy" it would be to update
> > various pieces of sage to the latest upstream. The tests were performed
> > on a linux machine running in 64 bit (amd64) based on 4.6.2.alpha2.
>
> > Harmless and easy to correct.
>
> > ecl-11.1.1/maxima-5.23.2
> > Lots of numerical noise and a bit of formatting. Mostly due to ecl as
> > downgrading maxima to 5.22.1 but keeping ecl-11.1.1 doesn't change the 
> > results
> > of the tests. 6 files are affected in total.
>
> If you open tickets for these, cc: me and I might be able to use that
> PPC 10.4 machine to help test again.  Note that 
> athttp://www.math.utexas.edu/pipermail/maxima/2011/023868.htmlwe have
> the following, which I never saw Juanjo respond to directly.  It'd be
> helpful to see what's up with this currently before upgrading.
>
> On 1/20/11 11:14 AM, Oliver Kullmann wrote:> Hello,
>
> > Maxima 5.21.1 as well as 5.23.2, built with Ecl 11.1.1,
> > has a completely corrupted next_prime function, e.g.
> > next_prime(113) = 121 = 11^2
> > (determining all "primes" within {1,...,1000} yields 231
> > "primes", while there are 168).
>
> > Don't know whether this is an Ecl or a Maxima (or a joint) problem.
> > Would be good to find out.
>
> Now that everyone has verified that other lisps don't show this, how
> about fixing it?
>
> A peek at next-prime-det in src/ifactor.lisp has this bit of code:
>
>   (loop while 1 do
>        (dolist (p *small-primes*)
>      (if (= (mmod n p) 0) (return))
>      (if (>= (* p p) n) (return-from next-prime-det n)))
>        (incf n (nth (mmod n 210) deltaprimes)))
>
> For whatever reason, ecl doesn't execute the loop.  It should because
> "1" is equivalent to true.  When I change the 1 to T, ecl returns 127
> as
> the next prime.
>
> Of course, since this is an infinite loop, we could just get rid of
> the
> "while 1 do" part and just use plain loop.
>
> Sounds like a bug in ecl to me.
>
> Ray

-- 
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: Anybody using weave?

[maldun]

Would be good to know!

I updated the corresponding documentation in numerical sage:
http://trac.sagemath.org/sage_trac/ticket/10689

these examples should work now. You could simply test waeve with the
repaired examples ^^

(sorry for possible double posting ^^")

greez,
maldun

On Jan 25, 3:22 pm, Jeroen Demeyer  wrote:
> On 2011-01-25 14:46, maldun wrote:
>
> > Question: Isn't a version of weave included in scipy, or would
> > deleting the weave in Sage,
> > also cripple the weave in Scipy? (I personally don't think so)
>
> I will check what happens when one simply removes the weave spkg from
> Sage: seehttp://trac.sagemath.org/sage_trac/ticket/10688

-- 
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: weave doesn't work

[maldun]

Update: I allowed myself to update the docu: 
http://trac.sagemath.org/sage_trac/ticket/10689
would need review.

greez maldun

On Jan 25, 3:16 pm, maldun  wrote:
> As mentioned in the other post, it's included in scipy and can be
> imported via
>
> from scipy import weave
>
> so I think this package is simply outdated.
>
> greez,
> maldun
>
> On Jan 22, 3:48 pm, Jeroen Demeyer  wrote:
>
> > There is some documentation about using Weave, but it doesn't work.
> > Anybody knows about weave and has an idea what's going on here?
>
> > sage: import weave
> > ---
> > ImportError                               Traceback (most recent call last)
>
> > /home/jdemeyer/sage/sage-4.6/ in ()
>
> > /home/jdemeyer/sage/sage-4.6/local/lib/python2.6/site-packages/weave/__init__.py
> > in ()
> >      18 except:
> >      19     pass
> >      20
> > ---> 21 from numpy.testing import ScipyTest
> >      22 test = ScipyTest().test
>
> > ImportError: cannot import name ScipyTest

-- 
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: weave doesn't work

[maldun]

As mentioned in the other post, it's included in scipy and can be
imported via

from scipy import weave

so I think this package is simply outdated.

greez,
maldun

On Jan 22, 3:48 pm, Jeroen Demeyer  wrote:
> There is some documentation about using Weave, but it doesn't work.
> Anybody knows about weave and has an idea what's going on here?
>
> sage: import weave
> ---
> ImportError                               Traceback (most recent call last)
>
> /home/jdemeyer/sage/sage-4.6/ in ()
>
> /home/jdemeyer/sage/sage-4.6/local/lib/python2.6/site-packages/weave/__init__.py
> in ()
>      18 except:
>      19     pass
>      20
> ---> 21 from numpy.testing import ScipyTest
>      22 test = ScipyTest().test
>
> ImportError: cannot import name ScipyTest

-- 
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: Anybody using weave?

[maldun]

Update: In my normal Python I have Scipy but not Weave installed, and
importing worked.
So normally deleting weave shouldn't cause troubles because it's
included in scipy.
Perhaps the import statements have to be changed.
(But we should test it in sage too, just to be sure)

On Jan 25, 2:46 pm, maldun  wrote:
> Question: Isn't a version of weave included in scipy, or would
> deleting the weave in Sage,
> also cripple the weave in Scipy? (I personally don't think so)
>
> I only import weave from scipy via from scipy import weave
> so if removing weave doesn't do any harm to the weave in scipy, I have
> no problems with that.
>
> On Jan 23, 3:31 pm, Jeroen Demeyer  wrote:
>
> > If not, we can remove it from Sage?...
> > It looks to be broken anyway.

-- 
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: Anybody using weave?

[maldun]

Question: Isn't a version of weave included in scipy, or would
deleting the weave in Sage,
also cripple the weave in Scipy? (I personally don't think so)

I only import weave from scipy via from scipy import weave
so if removing weave doesn't do any harm to the weave in scipy, I have
no problems with that.


On Jan 23, 3:31 pm, Jeroen Demeyer  wrote:
> If not, we can remove it from Sage?...
> It looks to be broken anyway.

-- 
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: not specifying vars for derivative of single-var functions?

[maldun]

Also +1 for keeping.

Many people which are more familiar with Matlab expect this behavior
in Sage too.
(I recently introduced Sage to some people)
Of course it's safer to specify the variable, but if I need to I can
do it. I think
this should always be a users choice and never the choice of the
designers.
I never understand the argumentation that someone somewhere somehow
could create troubles. That's
the reason why I hate Java...

regards,
-Stefan

On Jan 25, 7:36 am, Robert Bradshaw 
wrote:
> On Mon, Jan 24, 2011 at 10:13 PM, Dan Drake  wrote:
> > What's the current thinking regarding derivative() and functions of a
> > single variable? Right now, you don't need to specify a variable if the
> > function only depends on one variable, so the following works:
>
> >    sage: f(x) = x^3 + 1
> >    sage: derivative(f)
> >    x |--> 3*x^2
> >    sage: f.derivative()
> >    x |--> 3*x^2
>
> > ...but I've heard that some people would like to change that, so that in
> > all cases it would be necessary to specify the variable. What's the
> > status of that?
>
> > This came up on ticket #10678, and is related to an article we're
> > working on. The article will be around for a while (we hope!), so if the
> > derivative() function is going to change, we want to know about it.
>
> I say +1 to keeping this behavior.
>
> - Robert

-- 
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: Advice for "Lazy" Symbolic Evaluation

[maldun]

The problem is, that there is no "simple" way to do it with
BuiltinFunction. The documentation of this class is currently in the
SAGE_ROOT/devel/sage/symbolic/function.pxd itself.
You can there see the Function base class from which BuiltinFunction
is derived, there is also the __call__ method defined. There you will
also find many helpful docstrings how these classes work. This was
also the way how I started ^^
In fact the only thing you do is overload the right methods. _eval_
for the evaluation, _evalf_ for the .n() method, _derivative_ for
derivative of the function and so on.

Normally if you derive BuiltinFunction (for user defined function you
normally use symbolic function) you don't overload __call__. Only
__eval__ should be overloaded (this is also mentioned in the
functions.pxd). You would have to overload __call__ in your new class
to handle the vectors (but lose the handling of other data types, but
it could be a fast solution), or modify the current __call__ method in
the Function class to work with that (there you find the coercion
methods). I don't think it's complicated, you simply would have to add
a statement that checks if one of the arguments is a vector and hand
it over to the right method. But it would require some work, and is
the reason why I said you would get credits for doing that =)

You will find examples on the trac ticket I posted (here the latest
version: 
http://trac.sagemath.org/sage_trac/attachment/ticket/9706/orthogonal_polys.9.py
). look for example at the OrthogonalPolynomials class (which is the
base class) and the Chebyshev_T class: You define class functions and
give it to the __eval__ (or define eval differently for each
subclass)). Also you see how to define derivatives and so on.

But as mentioned above: to understand BuiltinFunction, you should
understand how the base class is working (at least the basics).

regards,
maldun


On 18 Jan., 22:24, Chris Swierczewski  wrote:
> > Coercion is currently still a little problem, and I think you would
> > earn some credits here if add this ability to the call method in
> > BuiltinFunction. Have you ever looked into that class? Perhaps it
> > helps you understanding the problem.
>
> So I've been looking at some of the trigonometric functions in 
> sage/functions/trig.pyx but I'm having trouble understanding what's going on. 
> There's not much going on in terms of documentation and __call__ isn't even 
> being overloaded in those examples. (See arccos or something similar.)
>
> Have you encountered any slight more elaborate examples?
>
> > If you need a quick solution, simply writing a small python class
> > would do the trick. (similar as in the current ortho_polys version)
>
> I considered this at first but I wanted to see if there's a preexisting Sage 
> construct that could help me out. BuiltinFunction seems like a step in the 
> right direction if I can only find examples of its use. There's not a lot of 
> helpful documentation out there. I'm gonna have to make a blog post about it 
> once I figure it out. :)
>
> --
> Chris

-- 
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: Advice for "Lazy" Symbolic Evaluation

[maldun]

If you want to wrap builtin function you could derive the
BuiltinFunction class and simply overload the eval and call methods.
(ok simply perhaps understates the problem, because the _call_ method
in BuiltinFunction is quite complex).
Coercion is currently still a little problem, and I think you would
earn some credits here if add this ability to the call method in
BuiltinFunction. Have you ever looked into that class? Perhaps it
helps you understanding the problem.

I'm still writing on the orthogonal polynomials, and I have similar
problems, but with other data types. You could look on the code I
posted on trac if it helps you:
http://trac.sagemath.org/sage_trac/ticket/9706

If you need a quick solution, simply writing a small python class
would do the trick. (similar as in the current ortho_polys version)

regards,
maldun

On 18 Jan., 17:13, Chris Swierczewski  wrote:
> > Try map instead: map(theta,[x,x^2,x^3]), because map applies the
> > function
> > to every list element.
>
> Thanks for the suggestion but theta is, in fact, a vector-valued function. It 
> acts on the elements of the input list / vector in a non-linear and 
> non-trivial way. So I'm looking for ways to craete a function (perhaps 
> wrapping BuiltinFunction) that can recognize and evaluate vectors over SR.
>
> The issue is that theta currently can only evaluate numerical input. (Over 
> ComplexField.) There's a lot of numerical approximation going on so simply 
> feeding it symbolic types isn't going to work. Hence, the need for some sort 
> of wrapper around this numerical theta that will deal with symbolic input 
> appropriately.
>
> --
> Chris

-- 
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: Advice for "Lazy" Symbolic Evaluation

[maldun]

Perhaps some things that could also useful for you:
most symbolic functions can handle numpy arrays,

if you don't want to write map all the time perhaps you can do this:

def theta_lazy(expression):
  try:
return map(theta,expression)
  except TypeError:
return theta(expression)

regards,
maldun

On Jan 18, 1:14 pm, maldun  wrote:
> Of course theta can't handle lists.
> Try map instead: map(theta,[x,x^2,x^3]), because map applies the
> function
> to every list element.
>
> Hope this helps =)
> maldun
>
> On Jan 14, 12:22 pm, Chris Swierczewski  wrote:
>
> > Does anyone know of an example where a class __call__ method takes lists as
> > input? (With possible symbolic entries, of course.) I'm attempting to follow
> > the structure of Function_sec (and similar functions) but when I try
>
> > sage: var('x')
> > sage: theta([x,x^2,x^3])
>
> > I get the following error:
>
> > Traceback (click to the left of this block for traceback)
> > ...
> > TypeError: descriptor '__call__' requires a
> > 'sage.symbolic.function.Function' object but received a 'list'
>
> > So for some reason my function isn't handling the symbolic input. Could 
> > somebody give some further guidance? Maybe a toy function that accepts 
> > vector input?
>
> > Thanks,
>
> > Chris

-- 
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: Advice for "Lazy" Symbolic Evaluation

[maldun]

Of course theta can't handle lists.
Try map instead: map(theta,[x,x^2,x^3]), because map applies the
function
to every list element.

Hope this helps =)
maldun

On Jan 14, 12:22 pm, Chris Swierczewski  wrote:
> Does anyone know of an example where a class __call__ method takes lists as
> input? (With possible symbolic entries, of course.) I'm attempting to follow
> the structure of Function_sec (and similar functions) but when I try
>
> sage: var('x')
> sage: theta([x,x^2,x^3])
>
> I get the following error:
>
> Traceback (click to the left of this block for traceback)
> ...
> TypeError: descriptor '__call__' requires a
> 'sage.symbolic.function.Function' object but received a 'list'
>
> So for some reason my function isn't handling the symbolic input. Could 
> somebody give some further guidance? Maybe a toy function that accepts vector 
> input?
>
> Thanks,
>
> Chris

-- 
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: Error when installing wxPython

[maldun]

I had the same errors, simply update the source
The version is 2.8.7 current is 2.8.11

You find a new spkg on 
http://computational-sage.googlecode.com/files/wxPython-2.8.11.0.spkg

On 17 Jan., 20:11, Sancho  wrote:
> I'll try to apply this fix:http://trac.wxwidgets.org/ticket/10883
>
> On Jan 16, 1:16 am, Sancho  wrote:
>
> > Sage Version 4.6, Release Date: 2010-10-30
> > openSUSE 11.3 (x86_64)
> > g++ (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]
>
> > On Dec 8 2010, 8:55 pm, Dima Pasechnik  wrote:
>
> > > please report Sage version, OS version, compiler version...
>
> > > On Dec 9, 2:48 am,Sancho wrote:
>
> > > > I run: sage -i wxPython-2.8.7.1
>
> > > > I get the following error.
>
> > > > /cs/public/lib/pkg/sage/sage-local/spkg/build/wxPython-2.8.7.1/
> > > > wxPython-src-2.8.7.1/bld/bk-deps g++ -c -o monodll_gsockgtk.o -I.pch/
> > > > wxprec_monodll -D__WXGTK__     -I../src/tiff -I../src/jpeg -I../src/
> > > > png -I../src/zlib  -I../src/regex  -DwxUSE_BASE=1 -DWXMAKINGDLL -fPIC -
> > > > DPIC -DWX_PRECOMP -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -
> > > > I/cs/public/lib/pkg/sage/sage-local/spkg/build/wxPython-2.8.7.1/
> > > > wxPython-src-2.8.7.1/bld/lib/wx/include/gtk2-unicode-debug-2.8 -I../
> > > > include -pthread -I/tmp/sage-4.6/local/include/freetype2 -I/tmp/
> > > > sage-4.6/local/include -I/tmp/sage-4.6/local/include/libpng12 -I/usr/
> > > > include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/
> > > > usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/
> > > > usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -pthread -DORBIT2=1
> > > > -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib64/
> > > > glib-2.0/include -I/usr/include/libxml2 -I/usr/include/gconf/2 -I/usr/
> > > > include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/
> > > > include -pthread -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-
> > > > aliasing -pthread -I/tmp/sage-4.6/local/include/freetype2 -I/tmp/
> > > > sage-4.6/local/include -I/tmp/sage-4.6/local/include/libpng12 -I/usr/
> > > > include/libgnomeprintui-2.2 -I/usr/include/libgnomeprint-2.2 -I/usr/
> > > > include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/
> > > > glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -I/usr/
> > > > include/pango-1.0 -I/usr/include/gail-1.0 -I/usr/include/gtk-2.0 -I/
> > > > usr/include/atk-1.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/cairo -
> > > > I/usr/include/pixman-1 ../src/gtk/gsockgtk.cpp
> > > > In file included from ../src/gtk/gsockgtk.cpp:21:0:
> > > > ../include/wx/gsocket.h:40:7: error: using typedef-name ‘GSocket’
> > > > after ‘class’
> > > > /usr/include/glib-2.0/gio/giotypes.h:127:47: error: ‘GSocket’ has a
> > > > previous declaration here
> > > > In file included from ../include/wx/gsocket.h:179:0,
> > > >                  from ../src/gtk/gsockgtk.cpp:21:
> > > > ../include/wx/unix/gsockunx.h:40:7: error: using typedef-name
> > > > ‘GSocket’ after ‘class’
> > > > /usr/include/glib-2.0/gio/giotypes.h:127:47: error: ‘GSocket’ has a
> > > > previous declaration here
> > > > ../src/gtk/gsockgtk.cpp: In function ‘void _GSocket_GDK_Input(void*,
> > > > gint, GdkInputCondition)’:
> > > > ../src/gtk/gsockgtk.cpp:34:13: error: ‘struct GSocket’ has no member
> > > > named ‘Detected_Read’
> > > > ../src/gtk/gsockgtk.cpp:36:13: error: ‘struct GSocket’ has no member
> > > > named ‘Detected_Write’
> > > > ../src/gtk/gsockgtk.cpp: In member function ‘virtual bool
> > > > GSocketGUIFunctionsTableConcrete::Init_Socket(GSocket*)’:
> > > > ../src/gtk/gsockgtk.cpp:56:11: error: ‘struct GSocket’ has no member
> > > > named ‘m_gui_dependent’
> > > > ../src/gtk/gsockgtk.cpp:57:27: error: ‘struct GSocket’ has no member
> > > > named ‘m_gui_dependent’
> > > > ../src/gtk/gsockgtk.cpp: In member function ‘virtual void
> > > > GSocketGUIFunctionsTableConcrete::Destroy_Socket(GSocket*)’:
> > > > ../src/gtk/gsockgtk.cpp:67:16: error: ‘struct GSocket’ has no member
> > > > named ‘m_gui_dependent’
> > > > ../src/gtk/gsockgtk.cpp: In member function ‘virtual void
> > > > GSocketGUIFunctionsTableConcrete::Install_Callback(GSocket*,
> > > > GSocketEvent)’:
> > > > ../src/gtk/gsockgtk.cpp:72:33: error: ‘struct GSocket’ has no member
> > > > named ‘m_gui_dependent’
> > > > ../src/gtk/gsockgtk.cpp:75:15: error: ‘struct GSocket’ has no member
> > > > named ‘m_fd’
> > > > ../src/gtk/gsockgtk.cpp:83:42: error: ‘struct GSocket’ has no member
> > > > named ‘m_server’
> > > > ../src/gtk/gsockgtk.cpp:90:35: error: ‘struct GSocket’ has no member
> > > > named ‘m_fd’
> > > > ../src/gtk/gsockgtk.cpp: In member function ‘virtual void
> > > > GSocketGUIFunctionsTableConcrete::Uninstall_Callback(GSocket*,
> > > > GSocketEvent)’:
> > > > ../src/gtk/gsockgtk.cpp:98:33: error: ‘struct GSocket’ has no member
> > > > named ‘m_gui_dependent’
> > > > ../src/gtk/gsockgtk.cpp:108:42: error: ‘struct GSocket’ has no member
> > > > named ‘m_server

[sage-devel] Tickets #8537, #8538 and #10566 for outdated spkgs openmpi, mpi4py and it's docu would need some review

[maldun]

Hi all!

I needed them for a seminar project, so I updated the openmpi (see
http://trac.sagemath.org/sage_trac/ticket/8537) mpi4py (see
http://trac.sagemath.org/sage_trac/ticket/8538) packages and the
mpi4py docu (see http://trac.sagemath.org/sage_trac/ticket/10566).

The packages worked on ubuntu 10.04 on 2 different machines.

Can someone have a look on these especially on the openmpi spkg
install. It was necesseary to delete other versions of openmpi before
install, or else one has funny problems with differently compiled
datatypes... so I added a lot of remove statements in the spkg-
install, but I'm quite sure
there is a better way. has somenone an Idea?

greez maldun

-- 
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] Updated MPI

[maldun]

Hi all!

I needed them for a seminar project, so I updated the openmpi (see
http://trac.sagemath.org/sage_trac/ticket/8537) mpi4py (see
http://trac.sagemath.org/sage_trac/ticket/8538) packages and the
mpi4py docu (see http://trac.sagemath.org/sage_trac/ticket/10566).

The packages worked on ubuntu 10.04 on 2 different machines.

Can someone have a look on these especially on the openmpi spkg
install. It was necesseary to delete other versions of openmpi before
install, or else one has funny problems with differently compiled
datatypes... so I added a lot of remove statements, but I'm quite sure
there is a better way. has somenone an Idea?

greez maldun

-- 
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] Easymacs

[maldun]

Hi!

Maybe some of will find this tool also useful:
http://www.dur.ac.uk/p.j.heslin/Software/Emacs/Easymacs/index.php

I personally love the emacs, but I never liked the positioning of the
shortcuts... and since the emacs is afaik the only editor which
supports sage, this could also very useful for beginners too, who
search a good alternative to the notebook. (or generally for students
who begin programming, but find the emacs confusing)

greez maldun

-- 
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: bug wranglers

[maldun]

Hi, Burcin!

I think this is a great Idea!
I'm short on time in the next months, but
If I'm free again, could help with this.

greez,
Stefan

On 16 Okt., 14:21, Burcin Erocal  wrote:
> Hi,
>
> Motivated by the call for the bug days, here is an idea to manage the
> rapidly increasing number of "new" tickets on trac.
>
> Many of the bugs on trac are
>
>  - duplicates,
>
>  - already fixed, which can be closed after adding a doctest or
>
>  - has not been seen by a developer who can fix it since keeping up
>    with all the new tickets on trac is very time consuming, and
>    possibly the problem was filed in the wrong category.
>
> We might be able to overcome this with a "bug-wrangler" team, people
> who volunteer to
>
>  - look at newly submitted tickets, notify the related developers, ask
>    for examples and test cases if the report doesn't provide them,
>    etc.
>
>  - every once in a while, go through the open tickets and see if
>    they were fixed in a recent release
>    (perhaps this won't be such a problem once the duplicates are
>    filtered properly)
>
> I know some people already spend time doing some of this, but it's
> impossible to fight with more than 2000 open tickets without an
> organized effort.
>
> Most linux distributions already use a similar approach. The issues are
> first assigned to the bug-wrangler team, where the email address points
> to a mailing list. Then someone takes the new ticket, and follows up
> until the right developer gives feedback.
>
> This would also be an easy way to consolidate duplicate tickets, even
> if they are filed in different components. The members of the
> bug-wrangler mailing list will be able to see the initial report for
> every ticket, so they might recall a similar problem reported a few
> days ago.
>
> Another advantage is that the members of this team don't need to be
> developers, or even know how to code. It is enough to be able to listen
> to user requests and use trac.
>
> This could also be a good starting point for people who want to get
> into Sage development, since it provides an opportunity to look through
> the library and become familiar with the internal structure of Sage.
>
> Comments?
>
> Cheers,
> Burcin

-- 
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] The new ortho polys would need review/feedback (Ticket #9706)

[maldun]

Hi!

Burcin asked me to make a new version of ortho polys some time ago,
and since Ticket #9808 for upgrading numpy and scipy finally got a
positive review, I can now finish this task.

Please feel free to look at the new version. The new version is a lot
faster as the old implementation with maxima, and the new ortho polys
can now be handled as symbolic objects.
Numerical evaluation is either done with mpmath, or with scipy when
the input is a numpy array.

But it is a whole lot of code (it grew from 650 lines to 2300 lines of
code!)

-- 
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: Strange doctest behavior after adding new ortho polys as Builtin functions

[maldun]

Ok I found a workarround:

I enlarged the ranges in the for loop for the search of the functions.
The change apparently made the search range for the function foo
wider.
All doctests pass now

Open question why does this work if I type it in by hand...

On 14 Okt., 21:57, maldun  wrote:
> Hi all!
>
> I found some time to work on ticket #9706 again. I'm currently working
> the doctest failures out. After applying the patch (or ortho_poly
> versions 8 or 9)  the following doctest fail:
>
>     * sage -t -long "devel/sage/sage/symbolic/random_tests.py"
>     * sage -t -long "devel/sage/sage/symbolic/pynac.pyx"
>
> I worked the first one out. This is clear, that when you add new
> symbolic objects the random expressions change.
>
> But the second is giving me headaches for some time now... I give an
> example because I think the others have the same problem:
>
> File "/home/maldun/sage/sage-4.5.2/devel/sage/sage/symbolic/
> pynac.pyx", line 386:
>     sage: get_sfunction_from_serial(i) == foo
> Expected:
>     True
> Got:
>     False
>
> apparently if I change the doctest to see which output you get I got
> this:
> sage -t -long "devel/sage/sage/symbolic/pynac.pyx"
> **
> File "/home/maldun/sage/sage-4.6.alpha3/devel/sage/sage/symbolic/
> pynac.pyx", line 387:
>     sage: get_sfunction_from_serial(i) #== foo
> Expected:
>     True
> Got:
>     foo
>
> wtf??? I get foo, but "get_sfunction_from_serial(i) == foo" returns
> false? What is this?
> And something went wrong, the following lines of the doctest fail
> also:
>
> File "/home/maldun/sage/sage-4.6.alpha3/devel/sage/sage/symbolic/
> pynac.pyx", line 389:
>     sage: py_latex_function_pystring(i, (x,y^z))
> Expected:
>     'my args are: x, y^z'
> Got:
>     '\\mathrm{bar}\\left(x, y^{z}\\right)'
>
> And really strange is: If I type the whole doctest in by hand
> everything works!
>
> Please has someone an Idea?
>
> -maldun

-- 
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] Strange doctest behavior after adding new ortho polys as Builtin functions

[maldun]

Hi all!

I found some time to work on ticket #9706 again. I'm currently working
the doctest failures out. After applying the patch (or ortho_poly
versions 8 or 9)  the following doctest fail:

* sage -t -long "devel/sage/sage/symbolic/random_tests.py"
* sage -t -long "devel/sage/sage/symbolic/pynac.pyx"

I worked the first one out. This is clear, that when you add new
symbolic objects the random expressions change.

But the second is giving me headaches for some time now... I give an
example because I think the others have the same problem:

File "/home/maldun/sage/sage-4.5.2/devel/sage/sage/symbolic/
pynac.pyx", line 386:
sage: get_sfunction_from_serial(i) == foo
Expected:
True
Got:
False

apparently if I change the doctest to see which output you get I got
this:
sage -t -long "devel/sage/sage/symbolic/pynac.pyx"
******
File "/home/maldun/sage/sage-4.6.alpha3/devel/sage/sage/symbolic/
pynac.pyx", line 387:
sage: get_sfunction_from_serial(i) #== foo
Expected:
True
Got:
foo

wtf??? I get foo, but "get_sfunction_from_serial(i) == foo" returns
false? What is this?
And something went wrong, the following lines of the doctest fail
also:

File "/home/maldun/sage/sage-4.6.alpha3/devel/sage/sage/symbolic/
pynac.pyx", line 389:
sage: py_latex_function_pystring(i, (x,y^z))
Expected:
'my args are: x, y^z'
Got:
'\\mathrm{bar}\\left(x, y^{z}\\right)'

And really strange is: If I type the whole doctest in by hand
everything works!

Please has someone an Idea?

-maldun

-- 
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: Complex numerical integration

[maldun]

So it happened again... I had such a discussion some time ago in one
other thread are are several other problems with numerical integration
which occour.

The thing is, that sage holds a lot of tool to perform numerical
integration to get a good answer (pari, mpmath, scipy etc.) but
sometimes it would be nice to get something more user friendly.

I'm planning to do some work on this, at least improving more control
of the choice of numerical integration methods for the user.
But it won't happening in the next time because I have a lot of work
to do, and I have to finish some other things, like a new version of
orthogonal polynomials before.

Another goal would be doing something similar to Mathematica's
NIntegrate, but his would take some years and should only considered
as long time goal for sage.

-maldun

On Oct 14, 6:01 am, Oscar Gerardo Lazo Arjona
 wrote:
> Hello people!
>
> I've been trying to solve this integral:
>
> sage: integrate(sqrt(sec(x)-1),x,pi/2,pi)
> integrate(sqrt(sec(x) - 1), x, 1/2*pi, pi)
>
> Since sage failed to produce a symbolic result, I tried with
> numerical_integral
>
> sage: numerical_integral(sqrt(sec(x)-1),pi/2,pi)
> (nan, nan)
>
> But that failed also... So I tried with mathematica:
>
> sage: mathematica_console()
>          Mathematica 7.0 for Linux x86 (32-bit)
> Copyright 1988-2008 Wolfram Research, Inc.
>
> In[1]:= Integrate[Sqrt[Sec[x]-1],{x,Pi/2,Pi}]
>
> Out[1]= I Pi
>
> So mathematica says it's a pure imaginary number, which I know to be true.
>
> I know that symbolic integration is quite complicated to develop, but
> numerical integration should be fairly easy to extend to complex
> numbers. Am I missing something? Why does numerical_integral return NaN?
> Perhaps i'ts not because of the complex result, in which case how could
> I solve the integral without recurring to mathematica?
>
> thanks!
>
> Oscar.

-- 
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: Bug with Latex in sage

[maldun]

Thanks for the hints but actually I'm doing this anyway since my sage
holds a lot of experimental stuff which I use for my work. So I have
always an clean intallation of Sage ready if something goes wrong =)

But using git is a nice Idea to manage this, I had thought about that
earlier.

-maldun

On Oct 14, 4:08 am, Mitesh Patel  wrote:
> On 10/12/2010 10:31 AM, kcrisman wrote:
>
> > On Oct 12, 11:29 am, maldun  wrote:
> >> Thanks for the quick response! I will update my sage on this computer
> >> then =)
>
> > You might want to wait until the "official" release of Sage 4.6, which
> > should be imminent, rather than doing sage -upgrade, which is
> > supposedly for "experts" but does have the ability to destroy your
> > Sage if you aren't careful.
>
> One "expert" way to manage destruction is to do
>
> tar xf sage-x.y.z.tar
> cd sage-x.y.z
> make
> cd ..
> cp -a sage-x.y.z sage-x.y.z-copy   # On Mac and Linux.  What is -a on
> Solaris?
> cd sage-x.y.z-copy
> ./sage -upgrade http://...         # Or sage -i, sage -f, etc.
>
> say.  It's helps to keep the original sage-x.y.z in place, to avoid
> breaking paths in
>
> sage-x.y.z-copy/local/lib/pkgconfig/*
>
> which still refer to sage-x.y.z (see #9210 for a fix awaiting review
> [1]).  If an irreversible operation goes bad, you can
>
> cd ..
> rm -rf sage-x.y.z-copy
> cp -a sage-x.y.z sage-x.y.z-copy
>
> and try again, etc.
>
> However, it may still be best to wait until we've resolved #9896 [2] to
> upgrade from before 4.6 into the 4.6 cycle.
>
> Another way is to put all content under SAGE_ROOT in a git repository
> and, when it's necessary, to reset the working directory to an earlier
> commit.
>
> [1]http://trac.sagemath.org/sage_trac/ticket/9210
> [2]http://trac.sagemath.org/sage_trac/ticket/9896

-- 
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: Presentation for Matlab-o-phil people

[maldun]

PS: If you are especially interested in PDE's you should also look at
the FEMhub Project, which is a Sage fork, and deals with finite
elements: http://femhub.org/
The Femhub packages can be also installed in sage without much
trouble. I tested it out recently, no problem at all.

>The MATLAB symbolic toolbox does not seem well integrated into MATLAB, so 
>that's
>an advantage Sage has. Also the symbolic toolbox costs more than MATLAB.

The Matlab symbolic toolbox is based on mupad, which is crap in my
opinion...
That was one of the reason I switched to Sage, another reason is Sage
is based on Python, and has therefore the benefit, that it is based on
a real programming language, which knows more than one data type.

Just my 2 cents.

-maldun

-- 
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: Presentation for Matlab-o-phil people

[maldun]

Hi,

I can't help you with that now, but I'm currently working on such
things, but it refers more to optimization, and will need some time,
because I have a lot of other work to do.

But www.scipy.org holds a lot info about comparisons with Matlab and
Python in general, and since scipy and numpy are the most similar
parts of sage to matlab, I think it's worth to focus on these Here
some links:
Key differences between numpy and Matlab:
http://www.scipy.org/NumPy_for_Matlab_Users

See for example this benchmark tests:
http://www.scipy.org/PerformancePython

Fast numerical computations with Cython:
http://conference.scipy.org/proceedings/SciPy2009/paper_2/full_text.pdf

Hope that helps a little bit.

-maldun

On Oct 14, 10:17 am, Alexander Dreyer
 wrote:
> Hi,
> are there  Sage Worksheets around for explaining the advantages of
> Sage to people, which usually use Matlab for scientific projects and
> industrial feasibility studies. It's usually about ODE and related
> stuff.
>
> My Best,
>   Alexander

-- 
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: Bug with Latex in sage

[maldun]

Thanks for the quick response! I will update my sage on this computer
then =)

On Oct 12, 5:20 pm, Burcin Erocal  wrote:
> On Tue, 12 Oct 2010 08:05:40 -0700 (PDT)
>
> maldun  wrote:
> > Hi all!
>
> > I had the following problem with the latex() function in sage:
>
> > sage: f(x) = (sin(sqrt(x))-sqrt(x))/x^(3/2)
> > sage: f(x)
> > -(sqrt(x) - sin(sqrt(x)))/x^(3/2)
> > sage: latex(f(x))
> > \frac{-\sqrt{x} - \sin\left(\sqrt{x}\right)}{x^{\frac{3}{2}}}
>
> > As you can see, he writes the minus sign before the \sqrt{x} instead
> > before the \frac{...} where it belongs.
> > Perhaps the parser has the wrong priorities
>
> This is fixed with the latest pynac update #9901. I get the following:
>
> sage: sage: f(x) = (sin(sqrt(x))-sqrt(x))/x^(3/2)
> sage: sage: f(x)
> -(sqrt(x) - sin(sqrt(x)))/x^(3/2)
> sage: sage: latex(f(x))
> -\frac{\sqrt{x} - \sin\left(\sqrt{x}\right)}{x^{\frac{3}{2}}}
>
> Cheers,
> Burcin

-- 
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] Bug with Latex in sage

[maldun]

Hi all!

I had the following problem with the latex() function in sage:

sage: f(x) = (sin(sqrt(x))-sqrt(x))/x^(3/2)
sage: f(x)
-(sqrt(x) - sin(sqrt(x)))/x^(3/2)
sage: latex(f(x))
\frac{-\sqrt{x} - \sin\left(\sqrt{x}\right)}{x^{\frac{3}{2}}}

As you can see, he writes the minus sign before the \sqrt{x} instead
before the \frac{...} where it belongs.
Perhaps the parser has the wrong priorities

--maldun

-- 
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 crashes on calculating roots of a polynom

[maldun]

You're right... I really should go to bed now =)
Well then it works also for ubuntu ^^

-maldun

On 10 Okt., 23:07, Mike Hansen  wrote:
> On Sun, Oct 10, 2010 at 2:05 PM, maldun  wrote:
> > Thanks to your patch the segfault is now gone, but apperently a new
> > problem arises:
>
> That is what is supposed to happen.  There's no way to convert (x-a)
> to a polynomial over the reals since "-a" cannot be converted to a
> real number.
>
> --Mike

-- 
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 crashes on calculating roots of a polynom

[maldun]

On 10 Okt., 20:47, Mike Hansen  wrote:
> On Sun, Oct 10, 2010 at 11:15 AM, maldun  wrote:
> > sage: sage: a = var('a')
> > sage: sage: R.  = a.parent()[]
> > sage: sage: (x - a).change_ring(RR) # boom!
>
> I've posted a patch athttp://trac.sagemath.org/sage_trac/ticket/10100
> which fixes this.
>
> --Mike

Thanks to your patch the segfault is now gone, but apperently a new
problem arises:

sage: a = var('a')
sage:
sage: R.  = a.parent()[]
sage: (x - a).change_ring(RR) # boom!
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (844, 0))

---
TypeError     Traceback (most recent call
last)

/home/maldun/sage/sage-4.5.3/ in ()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
rings/polynomial/polynomial_element.so in
sage.rings.polynomial.polynomial_element.Polynomial.change_ring (sage/
rings/polynomial/polynomial_element.c:16456)()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
structure/parent.so in sage.structure.parent.Parent.__call__ (sage/
structure/parent.c:6407)()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
structure/coerce_maps.so in
sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/
structure/coerce_maps.c:3108)()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
structure/coerce_maps.so in
sage.structure.coerce_maps.DefaultConvertMap_unique._call_ (sage/
structure/coerce_maps.c:3010)()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
rings/polynomial/polynomial_ring.pyc in _element_constructor_(self, x,
check, is_gen, construct, **kwds)
311 x = x.Polrev()
312
--> 313 return C(self, x, check, is_gen, construct=construct,
**kwds)
    314
315 def is_integral_domain(self, proof = True):

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
rings/polynomial/polynomial_real_mpfr_dense.so in
sage.rings.polynomial.polynomial_real_mpfr_dense.PolynomialRealDense.__init__
(sage/rings/polynomial/polynomial_real_mpfr_dense.c:3620)()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
structure/parent.so in sage.structure.parent.Parent.__call__ (sage/
structure/parent.c:6407)()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
structure/coerce_maps.so in
sage.structure.coerce_maps.NamedConvertMap._call_ (sage/structure/
coerce_maps.c:4053)()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
symbolic/expression.so in sage.symbolic.expression.Expression._mpfr_
(sage/symbolic/expression.cpp:4733)()

/home/maldun/sage/sage-4.5.3/local/lib/python2.6/site-packages/sage/
symbolic/expression.so in
sage.symbolic.expression.Expression._eval_self (sage/symbolic/
expression.cpp:4545)()

TypeError: Cannot evaluate symbolic expression to a numeric value.

@Dave
Thanks for the info! I was quite puzzled about this error message, and
google didn't gave any hints.

-- 
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 crashes on calculating roots of a polynom

[maldun]

Ok I know your problem. I use ubuntu 10.04 myself.
 I built my own valgrind with source from svn to get it running.

Since we have the quite the same system I tried it out myself, and
voila...

valgrind gives no valuable information, except that it's a segfault:

sage: sage: a = var('a')
sage: sage: R.  = a.parent()[]
sage: sage: (x - a).change_ring(RR) # boom!


Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).


More interesting is this from sage -gdb

/home/maldun/sage/sage-4.5.3/local/bin/python[0x4006d9]
=== Memory map: 
0040-00401000 r-xp  08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
0060-00601000 r--p  08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
00601000-00602000 rw-p 1000 08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
00602000-0453e000 rw-p  00:00
0  [heap]
7fffc400-7fffc4021000 rw-p  00:00 0
7fffc4021000-7fffc800 ---p  00:00 0
7fffc951c000-7fffc9526000 r-xp  08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9526000-7fffc9725000 ---p a000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9725000-7fffc9726000 r--p 9000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9726000-7fffc9729000 rw-p a000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9729000-7fffc972f000 r-xp  08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc972f000-7fffc992e000 ---p 6000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc992e000-7fffc992f000 r--p 5000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc992f000-7fffc993 rw-p 6000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc993-7fffc993c000 r-xp  08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc993c000-7fffc9b3b000 ---p c000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc9b3b000-7fffc9b3c000 r--p b000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc9b3c000-7fffc9b3f000 rw-p c000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
Program received signal SIGABRT, Aborted.
0x76e2ba75 in *__GI_raise (sig=) at ../
nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c

gdb up gives:

#1  0x76e2f5c0 in *__GI_abort () at abort.c:92
92  abort.c: No such file or directory.
in abort.c
(gdb) up
#2  0x76e654fb in __libc_message (do_abort=, fmt=) at ../sysdeps/unix/sysv/linux/
libc_fatal.c:189
189 ../sysdeps/unix/sysv/linux/libc_fatal.c: No such file or
directory.
in ../sysdeps/unix/sysv/linux/libc_fatal.c
(gdb) up
#3  0x76e6f5b6 in malloc_printerr (action=3,
str=0x76f3fab3 "free(): invalid pointer", ptr=) at malloc.c:6264
6264malloc.c: No such file or directory.
in malloc.c
(gdb) up
#4  0x76e75e53 in *__GI___libc_free (mem=) at malloc.c:3738
3738in malloc.c
(gdb) up
#5  0x7fffea770c05 in mpfr_clear () from /home/maldun/sage/
sage-4.5.2/local/lib/libmpfr.so.1
(gdb) up
#6  0x7fffe33868a7 in
__pyx_pf_4sage_5rings_10polynomial_26polynomial_real_mpfr_dense_19PolynomialRealDense___dealloc__
(o=0x43e9808) at sage/rings/polynomial/polynomial_real_mpfr_dense.c:
3706
3706  mpfr_clearstruct
__pyx_obj_4sage_5rings_10polynomial_26polynomial_real_mpfr_dense_PolynomialRealDense
*)__pyx_v_self)->_coeffs[__pyx_v_i]));
(gdb) up
#7
__pyx_tp_dealloc_4sage_5rings_10polynomial_26polynomial_real_mpfr_dense_PolynomialRealDense
(o=0x43e9808) at sage/rings/polynomial/p

[sage-devel] Re: sage crashes on calculating roots of a polynom

[maldun]

Ok I know your problem. I use ubuntu 10.04 myself.
 I built my own valgrind with source from svn to get it running.

Since we have the quite the same system I tried it out myself, and
voila...

valgrind gives no valuable information, except that it's a segfault:

sage: sage: a = var('a')
sage: sage: R.  = a.parent()[]
sage: sage: (x - a).change_ring(RR) # boom!


Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).


More interesting is this from sage -gdb

/home/maldun/sage/sage-4.5.3/local/bin/python[0x4006d9]
=== Memory map: 
0040-00401000 r-xp  08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
0060-00601000 r--p  08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
00601000-00602000 rw-p 1000 08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
00602000-0453e000 rw-p  00:00
0  [heap]
7fffc400-7fffc4021000 rw-p  00:00 0
7fffc4021000-7fffc800 ---p  00:00 0
7fffc951c000-7fffc9526000 r-xp  08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9526000-7fffc9725000 ---p a000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9725000-7fffc9726000 r--p 9000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9726000-7fffc9729000 rw-p a000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9729000-7fffc972f000 r-xp  08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc972f000-7fffc992e000 ---p 6000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc992e000-7fffc992f000 r--p 5000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc992f000-7fffc993 rw-p 6000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc993-7fffc993c000 r-xp  08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc993c000-7fffc9b3b000 ---p c000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc9b3b000-7fffc9b3c000 r--p b000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc9b3c000-7fffc9b3f000 rw-p c000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
Program received signal SIGABRT, Aborted.
0x76e2ba75 in *__GI_raise (sig=) at ../
nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c

I hope this helps somehow

On 7 Okt., 20:07, Johannes  wrote:
> im sorry, but I cant install valgrind because it does not compile with
> my glibc version.
> Ubuntu 10.4 is comming with glib 2.10 and valgrind builds just with
> glibc 2.2 up to 2.7
>
> greatz
>
> Am 07.10.2010 19:38, schrieb maldun:
>
> > I would suggest to run sage with valgrind to get more information out
> > of your error messages.
>
> > On 7 Okt., 17:31, Johannes  wrote:
>
> >> Hi list,
> >> i got my sage crashed once again:
>
> >> sage: a,b,c= var('a,b,c')
> >> sage: mprime = matrix([[01,b+1,2],[a+1,2,1],[2,1,c+1]])
> >> sage: cp = mprime.charpoly()
> >> sage: cp.real_roots()
> >> *** glibc detected *** python: free(): invalid pointer: 0x00541bfc ***
> >> === Backtrace: =
> >> /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xc57591]
> >> /lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xc58de8]
> >> /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xc5becd]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/memory.so(+0x121d)[0x16c21d]
> >> /opt/sage-4.5.1/local/lib/libmpfr.so.1(mpfr_clear+0x58)[0x8e3778]
> >> /opt/sage-4.5.1/local/lib/py

[sage-devel] Re: sage crashes on calculating roots of a polynom

[maldun]

Ok I know your problem. I use ubuntu 10.04 myself.
 I built my own valgrind with source from svn to get it running.

Since we have the quite the same system I tried it out myself, and
voila...

valgrind gives no valuable information, except that it's a segfault:

sage: sage: a = var('a')
sage: sage: R.  = a.parent()[]
sage: sage: (x - a).change_ring(RR) # boom!



Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).


More interesting is this from sage -gdb

/home/maldun/sage/sage-4.5.3/local/bin/python[0x4006d9]
=== Memory map: 
0040-00401000 r-xp  08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
0060-00601000 r--p  08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
00601000-00602000 rw-p 1000 08:07
46679134   /home/maldun/sage/sage-4.5.3/local/
bin/python
00602000-0453e000 rw-p  00:00
0  [heap]
7fffc400-7fffc4021000 rw-p  00:00 0
7fffc4021000-7fffc800 ---p  00:00 0
7fffc951c000-7fffc9526000 r-xp  08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9526000-7fffc9725000 ---p a000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9725000-7fffc9726000 r--p 9000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9726000-7fffc9729000 rw-p a000 08:07
8130829    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/ext/interactive_constructors_c.so
7fffc9729000-7fffc972f000 r-xp  08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc972f000-7fffc992e000 ---p 6000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc992e000-7fffc992f000 r--p 5000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc992f000-7fffc993 rw-p 6000 08:07
47056756   /home/maldun/sage/sage-4.5.3/local/lib/
python2.6/lib-dynload/_multiprocessing.so
7fffc993-7fffc993c000 r-xp  08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc993c000-7fffc9b3b000 ---p c000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc9b3b000-7fffc9b3c000 r--p b000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
7fffc9b3c000-7fffc9b3f000 rw-p c000 08:07
8131979    /home/maldun/sage/sage-4.5.3/devel/sage-
numpy-1.5/build/sage/finance/fractal.so
Program received signal SIGABRT, Aborted.
0x76e2ba75 in *__GI_raise (sig=) at ../
nptl/sysdeps/unix/sysv/linux/raise.c:64
64  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c


The last line says there is no raise.c, and actually after searching
there is no raise.c on the whole file system.

I hope this helps somehow


On 7 Okt., 20:07, Johannes  wrote:
> im sorry, but I cant install valgrind because it does not compile with
> my glibc version.
> Ubuntu 10.4 is comming with glib 2.10 and valgrind builds just with
> glibc 2.2 up to 2.7
>
> greatz
>
> Am 07.10.2010 19:38, schrieb maldun:
>
> > I would suggest to run sage with valgrind to get more information out
> > of your error messages.
>
> > On 7 Okt., 17:31, Johannes  wrote:
>
> >> Hi list,
> >> i got my sage crashed once again:
>
> >> sage: a,b,c= var('a,b,c')
> >> sage: mprime = matrix([[01,b+1,2],[a+1,2,1],[2,1,c+1]])
> >> sage: cp = mprime.charpoly()
> >> sage: cp.real_roots()
> >> *** glibc detected *** python: free(): invalid pointer: 0x00541bfc ***
> >> === Backtrace: =
> >> /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xc57591]
> >> /lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xc58de8]
> >> /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xc5becd]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/memory.so(+0x121d)[0x16c21d]
> >&

[sage-devel] Re: sage crashes on calculating roots of a polynom

[maldun]

Ok then they didn't upgrade the valgrind package in the meantime.

I'm using Ubuntu myself and had the same problem, but I build my own
package with the latest source from svn. It worked for me
I can send it to you if you want, and you test it out.

maldun

On 7 Okt., 20:07, Johannes  wrote:
> im sorry, but I cant install valgrind because it does not compile with
> my glibc version.
> Ubuntu 10.4 is comming with glib 2.10 and valgrind builds just with
> glibc 2.2 up to 2.7
>
> greatz
>
> Am 07.10.2010 19:38, schrieb maldun:
>
> > I would suggest to run sage with valgrind to get more information out
> > of your error messages.
>
> > On 7 Okt., 17:31, Johannes  wrote:
>
> >> Hi list,
> >> i got my sage crashed once again:
>
> >> sage: a,b,c= var('a,b,c')
> >> sage: mprime = matrix([[01,b+1,2],[a+1,2,1],[2,1,c+1]])
> >> sage: cp = mprime.charpoly()
> >> sage: cp.real_roots()
> >> *** glibc detected *** python: free(): invalid pointer: 0x00541bfc ***
> >> === Backtrace: =
> >> /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xc57591]
> >> /lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xc58de8]
> >> /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xc5becd]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/memory.so(+0x121d)[0x16c21d]
> >> /opt/sage-4.5.1/local/lib/libmpfr.so.1(mpfr_clear+0x58)[0x8e3778]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_real_mpfr_dense.so(+0x5dd5)[0x68fcdd5]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(+0x86c43)[0x724c43]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3535)[0x76a2f5]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(+0x57ed7)[0x6f5ed7]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(+0x3bfb4)[0x6d9fb4]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/structure/coerce_maps.so(+0xffb2)[0xb4ffb2]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/structure/parent.so(+0x1f4df)[0x5214df]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyCFunction_Call+0x128)[0x70bc48]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(+0x90cad)[0x72ecad]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_element.so(+0x7511)[0x1327511]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyCFunction_Call+0xa5)[0x70bbc5]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_element.so(+0xb33d3)[0x13d33d3]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyCFunction_Call+0x128)[0x70bc48]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x54)[0x765f84]
> >> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_element.so(+0x39aea)[0x1359aea]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x482e)[0x76b5ee]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCode+0x63)[0x76d0c3]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50c9)[0x76be89]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x4370)[0x76b130]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x4370)[0x76b130]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x59e1)[0x76c7a1]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x4370)[0x76b130]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> >> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(

[sage-devel] Re: sage crashes on calculating roots of a polynom

[maldun]

I would suggest to run sage with valgrind to get more information out
of your error messages.

On 7 Okt., 17:31, Johannes  wrote:
> Hi list,
> i got my sage crashed once again:
>
> sage: a,b,c= var('a,b,c')
> sage: mprime = matrix([[01,b+1,2],[a+1,2,1],[2,1,c+1]])
> sage: cp = mprime.charpoly()
> sage: cp.real_roots()
> *** glibc detected *** python: free(): invalid pointer: 0x00541bfc ***
> === Backtrace: =
> /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0xc57591]
> /lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0xc58de8]
> /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0xc5becd]
> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/memory.so(+0x121d)[0x16c21d]
> /opt/sage-4.5.1/local/lib/libmpfr.so.1(mpfr_clear+0x58)[0x8e3778]
> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_real_mpfr_dense.so(+0x5dd5)[0x68fcdd5]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(+0x86c43)[0x724c43]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x3535)[0x76a2f5]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(+0x57ed7)[0x6f5ed7]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(+0x3bfb4)[0x6d9fb4]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/structure/coerce_maps.so(+0xffb2)[0xb4ffb2]
> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/structure/parent.so(+0x1f4df)[0x5214df]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyCFunction_Call+0x128)[0x70bc48]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(+0x90cad)[0x72ecad]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_element.so(+0x7511)[0x1327511]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyCFunction_Call+0xa5)[0x70bbc5]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_element.so(+0xb33d3)[0x13d33d3]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyCFunction_Call+0x128)[0x70bc48]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyObject_Call+0x5c)[0x6c873c]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x54)[0x765f84]
> /opt/sage-4.5.1/local/lib/python2.6/site-packages/sage/rings/polynomial/polynomial_element.so(+0x39aea)[0x1359aea]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x482e)[0x76b5ee]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCode+0x63)[0x76d0c3]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x50c9)[0x76be89]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x4370)[0x76b130]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x4370)[0x76b130]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x59e1)[0x76c7a1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x4370)[0x76b130]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x4370)[0x76b130]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalFrameEx+0x4370)[0x76b130]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCodeEx+0x7d1)[0x76cfa1]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyEval_EvalCode+0x63)[0x76d0c3]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyRun_FileExFlags+0xb1)[0x78cf91]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyRun_SimpleFileExFlags+0xdc)[0x78d1cc]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(PyRun_AnyFileExFlags+0x7a)[0x78d5fa]
> /opt/sage-4.5.1/local/lib/libpython2.6.so.1.0(Py_Main+0xc7d)[0x799c4d]
> python(main+0x27)[0x8048657]
> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xc02bd6]
> python[0x8048591]
> === Memory map: 
> 0011-00117000 r-xp  08:05 164238
> /opt/sage-4.5.1/local/lib/python2.6/lib-dynload/itertools.so
> 00117000-00118000 r--p 6000 08:05 164238
> /opt/sage-4.5.1/local/lib/python2.6/lib-dynload/itertools.so
> 00118000-0011b000 rw-p 7000 08:05 164238
> /opt/sage-4.5.1/local/lib/python2.6/lib-dynload/itertools.so
> 0011b000-0011f000 r-xp  08:

[sage-devel] Re: German translation of the tutorial / Übersetzung des Tutorials in Deutsch

[maldun]

When I find some time this weekend, I can do some proofreading.

Hope you get along with austrian german as well ;-)

greez,
maldun

On Oct 5, 12:10 am, Philipp Schneider 
wrote:
>  Dear Sage community,
>
> Michael Mardaus and I are happy to announce that we have finished
> translating the complete Sage tutorial to German.
>
> Now we need the help of as many German speaking users as possible to
> proofread our translation.
> If you happen to belong to this group and have some minutes to speak, we
> would be happy if you could send us corrections or improved formulations.
>
> you can find the current version of the translation in html format 
> at:http://wwwcip.informatik.uni-erlangen.de/~snphschn/sage/doc/output/ht...
>
> or in pdf format 
> at:http://wwwcip.informatik.uni-erlangen.de/~snphschn/sage/doc/output/pd...
>
> You can either send me the corrections per email, or you can post them
> to sage trac at:http://trac.sagemath.org/sage_trac/ticket/9725
>
> Thank you,
> Philipp Schneider
>
> 
>
> Liebe Sage-Community,
>
> Michael Mardaus und ich sind gl cklich dar ber, dass wir verk nden
> k nnen, dass wir das komplette Sage-Tutorial in Deutsch bersetzt haben.
>
> Nun ben tigen wir die Hilfe beim Korrekturlesen unserer bersetzung von
> m glichst vielen deutschsprachigen Sage-Nutzern .
> Falls Sie sich angesprochen f hlen und etwas Zeit haben, w rden wir uns
> freuen, wenn Sie uns auf Fehler aufmerksam machen, oder verbesserte
> Formulierungen schicken w rden.
>
> Sie k nnen die aktuelle Version der bersetzung hier im html-Format 
> finden:http://wwwcip.informatik.uni-erlangen.de/~snphschn/sage/doc/output/ht...
>
> oder im pdf-Format 
> unter:http://wwwcip.informatik.uni-erlangen.de/~snphschn/sage/doc/output/pd...
>
> Sie k nnen mir die Verbesserungen entweder per Email schicken, oder Sie
> k nnen diese auf Sage-trac 
> unter:http://trac.sagemath.org/sage_trac/ticket/9725
> eingeben.
>
> Vielen Dank,
> Philipp Schneider

-- 
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: German translation of the tutorial / Übersetzung des Tutorials in Deutsch

[maldun]

When I find some time this weekend I will make a little bit
proofreading.

greez,
maldun

On Oct 5, 12:10 am, Philipp Schneider 
wrote:
>  Dear Sage community,
>
> Michael Mardaus and I are happy to announce that we have finished
> translating the complete Sage tutorial to German.
>
> Now we need the help of as many German speaking users as possible to
> proofread our translation.
> If you happen to belong to this group and have some minutes to speak, we
> would be happy if you could send us corrections or improved formulations.
>
> you can find the current version of the translation in html format 
> at:http://wwwcip.informatik.uni-erlangen.de/~snphschn/sage/doc/output/ht...
>
> or in pdf format 
> at:http://wwwcip.informatik.uni-erlangen.de/~snphschn/sage/doc/output/pd...
>
> You can either send me the corrections per email, or you can post them
> to sage trac at:http://trac.sagemath.org/sage_trac/ticket/9725
>
> Thank you,
> Philipp Schneider
>
> 
>
> Liebe Sage-Community,
>
> Michael Mardaus und ich sind gl cklich dar ber, dass wir verk nden
> k nnen, dass wir das komplette Sage-Tutorial in Deutsch bersetzt haben.
>
> Nun ben tigen wir die Hilfe beim Korrekturlesen unserer bersetzung von
> m glichst vielen deutschsprachigen Sage-Nutzern .
> Falls Sie sich angesprochen f hlen und etwas Zeit haben, w rden wir uns
> freuen, wenn Sie uns auf Fehler aufmerksam machen, oder verbesserte
> Formulierungen schicken w rden.
>
> Sie k nnen die aktuelle Version der bersetzung hier im html-Format 
> finden:http://wwwcip.informatik.uni-erlangen.de/~snphschn/sage/doc/output/ht...
>
> oder im pdf-Format 
> unter:http://wwwcip.informatik.uni-erlangen.de/~snphschn/sage/doc/output/pd...
>
> Sie k nnen mir die Verbesserungen entweder per Email schicken, oder Sie
> k nnen diese auf Sage-trac 
> unter:http://trac.sagemath.org/sage_trac/ticket/9725
> eingeben.
>
> Vielen Dank,
> Philipp Schneider

-- 
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: Ticket #9808 for newer numpy and scipy packages would need a final decision

[maldun]

On 30 Sep., 14:58, Jason Grout  wrote:
> On 9/30/10 6:25 AM, maldun wrote:
>
> > There is another thing that I want to mention another thing:
>
> > Leif mentioned that it would be important that after installing of
> > numpy rebuilding of sage should happen with -b, and not with -ba
> > like I suggested. I can understand his thoughts because actually it is
> > a good thing when sage builds the only the .pyx files which are
> > concerned.
>
> There have been times in the past when an spkg update required sage -ba.
>   I'm not commenting on whether that is good or not, just saying that
> there is precedent for saying that an spkg update requires sage -ba.  I
> personally don't find it offensive to require sage -ba for an underlying
> library.
>
> Thanks,
>
> Jason

Thanks, then keeping -ba would be more a matter of taste then a
necessity.

Update: I solved the issues with numpy-1.5.0. And since fbissey
reported,
that numpy-1.4.1.p0 still does not build on linux ppc, we should move
to 1.5.0 then.
I wrote a summary of the applied changes, and made diffs of the spkg-
install files.
Question: should I put this in a new ticket, or should I post this in
the old?

-- 
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: Ticket #9808 for newer numpy and scipy packages would need a final decision

[maldun]

There is another thing that I want to mention another thing:

Leif mentioned that it would be important that after installing of
numpy rebuilding of sage should happen with -b, and not with -ba
like I suggested. I can understand his thoughts because actually it is
a good thing when sage builds the only the .pyx files which are
concerned.

But -b doesn't do this out of the box you have to trick sage, because
there happenend no changes to the .pyx files at all, and so the .c
files don't get recompiled.
One way to this is -ba which is of course more time consuming, but
after upgrading from numpy-1.3.x to a higher version this gets
obsolete anyway because all newer numpy versions have the same size of
"flatiter". And if you build a fresh sage this wouldn't happen anyway.

An other method would be touching the numpy.pxd in cython, which
actually work, but this somehow interferes with the principle that one
package shouldn't touch the other, and numpy isn't dependend on cython
so we would artificially create one.
And then we could make the changed numpy headers dependend on the
concerned modules, which would be a better solution, but then we have
to add ALL headers to the dependend lists because, if we upgrade to
newer numpy versions, there are different or even no header changes
(what is also a problem).
One thing what we can do here would be put a "patched" header into the
patches path which only contains a small change like an additional
comment to trick sage  with the timestamps and make the modules only
dependend on that header, so that we only have to add one header to
the entries.
But these solutions don't really make me happy because they have more
the taste of a bad hack then a clean solution.

Has anyone a better Idea for a clean solution?

Of course I will apply any change that are demanded by reviewers, but
I'm actually not happy with that change, for the reasons I mentioned.
I hope one can understand my concerns.

-- 
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: Ticket #9808 for newer numpy and scipy packages would need a final decision

[maldun]

Could you alse give the 1.4.1.p0 a spin? it contains the patch for
linux ppc. (download link a few posts above) Perhaps the whole thing
will get obsolete
with 1.5.0 but I'm curious if that would work also, because I'm not
sure if I get 1.5.0 ready in time.

greez
maldun

On Sep 30, 10:05 am, François Bissey  wrote:
> > On Sep 29, 9:01 am, Marshall Hampton  wrote:
> > > It looks like it might be a while before this is fixed by numpy:
>
> > >http://projects.scipy.org/numpy/ticket/1403
>
> > > Given the importance of numpy to Sage, I think it might make sense to
> > > drop support for PPC linux.  On the positive side:
>
> > > 1) There are considerable improvements to numpy and scipy in the
> > > latest version that some of our developers and users are interested in
> > > (not to mention bugfixes).
>
> > > 2) We need the latest scipy & numpy to be able to upgrade the python
> > > version in Sage.  I don't think it makes sense to freeze our version
> > > of python.  Also there are many interesting improvements to python in
> > > the 2.7 series, which will be the last 2.x version.
>
> > > The downsides of dropping support for a platform are obvious, but I
> > > really wonder how many people are running Sage on linux PPC.
>
> > Though let's be clear that the downside is there.  For instance, there
> > is also the socio impact - one of the (supposed) advantages of open
> > source is that it can run on a wider spectrum of hardware, esp. lower
> > end and older ones.  It would be nice for Sage to do this as much as
> > possible.
>
> > I think the real problem is that we never knew whether Linux PPC was
> > supported or not!  The notion of 'official support' has evolved
> > considerably over the last year, thanks largely to the efforts of Dave
> > K. - mostly in good ways, I'd say.
>
> I will put my feet in it. I never really cared if it was officially supported 
> I
> have the hardware I have the OS. I had a crack at it, it worked. mabshoff told
> me at the time that it was supported but that was then.
>
> I will test patch for numpy-1.5.x if they become available. I know that numpy
> 1.5 works because the package from the system works so it should work in sage.
>
> I also believe in trying in testing in lesser known platforms, I just happen
> to have one at hand, Dave has several.
>
> Francois

-- 
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: Ticket #9808 for newer numpy and scipy packages would need a final decision

[maldun]

>
> Maldun, do you think that would be possible?  I'd be willing to retest
> it on the OS X PPC box to make sure that didn't break anything - no,
> Dima, I still don't have the Linux up on that yet :(
>
> - kcrisman

I packed it: 
http://code.google.com/p/spkg-upload/downloads/detail?name=numpy-1.4.1.p0.spkg

Give me feedback if it builds on your machine, it works for me.
I will run the long doctests during the night.

greez,
maldun

-- 
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: Ticket #9808 for newer numpy and scipy packages would need a final decision

[maldun]

Yeah that's true, and I wouldn't make the final decision on that, but
it would be great if it could be tested
anyway, I think this may make porting to 1.5.1 easier when it finally
will be released,

On 29 Sep., 18:49, kcrisman  wrote:
> On Sep 29, 11:46 am, maldun  wrote:
>
> > > Maldun, do you think that would be possible?  I'd be willing to retest
> > > it on the OS X PPC box to make sure that didn't break anything - no,
> > > Dima, I still don't have the Linux up on that yet :(
>
> > > - kcrisman
>
> > Sure why not! I give it a shot and post a patched version on trac as
> > soon as possible.
>
> > I've already working on 1.5.0 too, and I think I know already what has
> > to be fixed.
> > If I provide the package of 1.5.0 and a patch for the doctests would
> > you test, that too?
> > Peraps we could jump directly to 1.5.0. then!
>
> But I thought the reason for doing 1.4.x was because it was more
> stable?
>
> - kcrisman

-- 
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: Ticket #9808 for newer numpy and scipy packages would need a final decision

[maldun]

>
> Maldun, do you think that would be possible?  I'd be willing to retest
> it on the OS X PPC box to make sure that didn't break anything - no,
> Dima, I still don't have the Linux up on that yet :(
>
> - kcrisman

Sure why not! I give it a shot and post a patched version on trac as
soon as possible.

I've already working on 1.5.0 too, and I think I know already what has
to be fixed.
If I provide the package of 1.5.0 and a patch for the doctests would
you test, that too?
Peraps we could jump directly to 1.5.0. then!

greez,
maldun

-- 
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: Ticket #9808 for newer numpy and scipy packages would need a final decision

[maldun]

On Sep 29, 3:55 pm, Volker Braun  wrote:
> I thought this is fixed due to Debian people pestering numpy dev's :-)
> But I'm not sure if the patch is already included in the newest
> release.
>
> http://mail.scipy.org/pipermail/numpy-svn/2010-July/004318.html
>
> Volker

As far as I know this will happen in 1.5.1, but this will take some
time...

-- 
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: Very suitable for rapid prototyping

[maldun]

This is the reason why I think Sage and Python in general are so
useful.
I'm doing a lot of experimental code recently, and it is very easy to
get them
up and running in Python/Sage programs.

And since the whole system is so flexible in communicating with other
languages,
sorting out the critical parts and make them more efficient is easily
possible.
This saves a lot of time! Normally you have to prototype in language A
because
it's simple to get the code running, where you not know at the
beginning if it even works, and don't want to waste time on this.
Then port it to language B, which is more efficient.
With Python it's easy to prototype and then just exchange the parts
which kills the efficiency.

On 29 Sep., 00:42, Carl Witty  wrote:
> I am proud to report that Sage has been "officially" recognized as
> "very suitable for rapid prototyping".  Also, Sage is "a fine tool for
> many applications".
>
> This recognition is because I won the lightning round (for the "rapid
> prototyping" recognition) and got second place in the main contest
> (for the "fine tool" recognition) in the 2010 ICFP Programming Contest
> (http://icfpcontest.org/2010/) using Sage (the recognition is part of
> the prize).  (Normally the recognition would be for a programming
> language, but the organizers let me claim Sage rather than Python as
> the programming language I used.)
>
> From Sage, I used:
>
> * matrices over multivariate integer polynomials
> * the Polyhedron class, to find vertices of a polyhedron given its
> definition as linear inequalities
> * ZZ's arbitrary-base support, to convert integers to and from base-3 strings
>
> The prize ceremony was videotaped, but I don't know if the video will
> be available.  (If so, it would be part of the segment "Report on the
> Thirteenth ICFP Programming Contest".)
>
> Carl

-- 
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: Very suitable for rapid prototyping

[maldun]

This is the reason why I think Sage and Python in general are so
useful.
I'm doing a lot of experimental code recently, and it is very easy to
get them
up and running in Python/Sage programs.

And since the whole system is so flexible in communicating with other
languages,
sorting out the critical parts and make them more efficient is easily
possible.
This saves a lot of time! Normally you have to prototype in language A
because
it's simple to get the code running, where you not know at the
beginning if it even works, and don't want to waste time on this.
Then port it to language B, which is more efficient.
With Python it's easy to prototype and then just exchange the parts
which kills the efficiency.

On 29 Sep., 00:42, Carl Witty  wrote:
> I am proud to report that Sage has been "officially" recognized as
> "very suitable for rapid prototyping".  Also, Sage is "a fine tool for
> many applications".
>
> This recognition is because I won the lightning round (for the "rapid
> prototyping" recognition) and got second place in the main contest
> (for the "fine tool" recognition) in the 2010 ICFP Programming Contest
> (http://icfpcontest.org/2010/) using Sage (the recognition is part of
> the prize).  (Normally the recognition would be for a programming
> language, but the organizers let me claim Sage rather than Python as
> the programming language I used.)
>
> From Sage, I used:
>
> * matrices over multivariate integer polynomials
> * the Polyhedron class, to find vertices of a polyhedron given its
> definition as linear inequalities
> * ZZ's arbitrary-base support, to convert integers to and from base-3 strings
>
> The prize ceremony was videotaped, but I don't know if the video will
> be available.  (If so, it would be part of the segment "Report on the
> Thirteenth ICFP Programming Contest".)
>
> Carl

-- 
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: Latest numpy+scipy packages

[maldun]

Ok latest update: numpy-1.4.1 and scipy-0.8 should now be ready! (see
ticket #9808; http://trac.sagemath.org/sage_trac/ticket/9808 )

Many many thanks to fbissey for the help with the spkg-install script,
and kcrisman for additional testing!

I have now a question: Should we merge it into sage-4.6. now or not?
numpy-1.4.1 is stable and quite well tested, it only fails on the ppc-
linux, which is not on the supported list
in the README.txt file of sage.

Short installation:
install the package normally and da sage -ba after install to get rid
of the warnings.
A patch for the failing doctests is in the attachment of the ticket.


-- 
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: changing SAGE_LOCAL/SAGE_ROOT to SPKG_LOCAL/SPKG_ROOT

[maldun]

This is just my opinion, but isn't the name SPKG (SAGE package)
already quite specialised?

On Sep 27, 11:13 pm, Ondrej Certik  wrote:
> Hi,
>
> in Femhub (http://femhub.org) I wrote a new buildsystem from scratch
> using Python, so far it's a simple Python script:
>
> http://github.com/hpfem/femhub/blob/master/spkg/base/femhub-run
>
> and it is (so far) fully compatible with Sage in the sense that any
> Sage package (should) install in Femhub and any Femhub package should
> install in Sage. (The goals of the Python based buildsystem is to
> support dependencies, as well as make it easier to improve it and make
> changes to it.)
>
> Very common question that gets asked on our group meetings (probably 4
> or 5 times already) is why we use SAGE_ROOT and SAGE_LOCAL in all our
> packages, and not something more project neutral, like
> SPKG_ROOT/SPKG_LOCAL. My answer to that is always: well, we want to
> stay compatible with Sage. Just like Ubuntu also uses the "debian"
> directory in every single Ubuntu package.
>
> Nevertheless, what is the opinion in the Sage community to the
> following proposal:
>
> 1) support SPKG_ROOT and SPKG_LOCAL in the Sage buildsystem (and would
> be equivalent to SAGE_LOCAL, SAGE_ROOT)
>
> 2) deprecate SAGE_ROOT/LOCAL, but keep it in the buildsystem, so that
> old packages still build
>
> I am myself +0 to that, it would fix some problems, it would create
> some new ones. But I would like to know what people think about this.
>
> 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: Improvement of numerical integration routines

[maldun]

Ok first I would thank everyone for their thoughts. I think the best
is to do a design document, or at least start a ticket where we come
to a common agreement how to handle the input because there are
several possiblities to do that. And it is important that we are more
or less happy about the solution.
I'm a little bit short on time in the next weeks, but I hope to get
back into it soon =)

@rjf Of course from a mathematical point of view you are correct, but
from a more pragmatic point of view you have to consider that about
80%-90% of the input satisfy these assumptions. So one can prevent
about 80%-90% of the mistakes. For the others it is important to give
the user a good control about the choice of the method.
It remembers me somehow of the arguments people used against
seatbelts, because there are SOME cases where the seatbelt could kill
you even when it saves your life in 80% of the cases...

>For example, you could solve World Hunger if you assume
>(a) there is enough free food for everyone and (b) there is
>enough free transportation to distribute it.

Ever watched "We feed the world"? Just curious :)

-- 
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] The PyCUDA package for sage

[maldun]

Hi!

I packed a PyCUDA package. The last efforts for this seem to go back 2
years ago.
Everything can be found under http://trac.sagemath.org/sage_trac/ticket/10010

It works for me but needs testing (I have ubuntu 10.04 latest nvidia
devel drivers, and CUDA 3.2)

as mentioned in the other thread PyOpenCL would also be available:
http://trac.sagemath.org/sage_trac/ticket/10009

Everything works for me, I hope it's useful for others too!

greez,
maldun

-- 
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: pyope...@sage

[maldun]

Since nobody answered I figured it out myself how it works.

Opened a ticket on this. see http://trac.sagemath.org/sage_trac/ticket/10009
. This would need testing, it is only tested on ubuntu 10.04
with latest NVIDIA developer drivers, and CUDA toolkit.
I use a geforce 9500 GT.

greez,
maldun

-- 
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