3 GSoC projects for Sage

[Harald Schilly]

The following is a cross-post from sage-announce and other channels. Apart from these three projects, there are also 5 very exiting ones for Lmonade (project summaries at their GSoC page) and furthermore in the broader "world of Python", also quite many for SymPy and scikit-learn.

Sage is pleased to announce three Google Summer of Code projects for 2013. They focus on speed improvements of symbolic functions, simplifying the distribution and installation procedure on Debian/Linux and ubiquitous accessibility of Sage on the Android platform.

Mathematical Functions Library

Eviatar Bach –  University of British Columbia in Vancouver, Canada

(Mentor: Flavia Stan, Backup: Burcin Erocal)

Sage interfaces with multiple third-party libraries, such as MPFR, GSL, GP/PARI, mpmath, and Maxima, for numerical evaluation of special functions. There are significant discrepancies between these backends in the performance for numerical approximations of the same expression. An initial benchmark reveals, for example, that calculating spherical_bessel_J(1, 5.2) with SciPy is over 100 times faster than with Maxima.

The project has the following goals:

1. develop a benchmark framework to determine which backend should be used by default to evaluate a special function over a specific domain,
2. create symbolic wrappers for all the special functions that can be evaluated numerically by a package included in Sage,
3. create a data structure for generalized hypergeometric functions and extend the symbolic wrappers to obtain representations in terms of generalized hypergeometric functions when possible,
4. implement closure properties for holonomic functions as a next step to improve the symbolic processing of special functions in Sage.

Overall improvement of the Sage Android application

Rasmi Elasmar

(Mentor: Volker Braun, Backup: Harald Schilly)

Although there are already some existing efforts, Sage is still not easily accessible from the Android platform. The Sage Cell client/server infrastructure is an already existing step towards running Sage on a server and communicating back the results. The aim of this proposal is to fix, improve and update the Sage Android application to include new features and functionality, as well as an improved interface for simpler and improved usability. Android's new "Holo" style, sharing of calculations and results, and much more waits to be realized on Android for Sage.

Get Sage ready for Linux distributions

Felix Salfelder – Goethe Universität, Frankfurt, Germany

(Mentor: Tobias Hansen, Julien Puydt, Jeroen Demeyer & John Palmieri )

sage-devel discussion

The aim of this project is to detach the build process of Sage ("the software") from Sage ("the distribution"). The goal is a build system that works within the context of Sage as well as for any GNU/Linux distribution that ships the dependencies for Sage. Distributions that already ship Sage packages or plan to do so are Fedora and Debian. This project is an important step towards making Sage packages in GNU/Linux distributions feasible.


Sage warmly welcomes all three new students and wishes them all the best to learn something new and make an impact in Sage's future developments!

[rjf]

On Tuesday, May 28, 2013 5:46:13 AM UTC-7, Harald Schilly wrote:

The following is a cross-post from sage-announce and other channels. Apart from these three projects, there are also 5 very exiting ones for Lmonade (project summaries at their GSoC page) and furthermore in the broader "world of Python", also quite many for SymPy and scikit-learn.

Sage is pleased to announce three Google Summer of Code projects for 2013. They focus on speed improvements of symbolic functions, simplifying the distribution and installation procedure on Debian/Linux and ubiquitous accessibility of Sage on the Android platform.

Mathematical Functions Library

Eviatar Bach –  University of British Columbia in Vancouver, Canada

(Mentor: Flavia Stan, Backup: Burcin Erocal)

Sage interfaces with multiple third-party libraries, such as MPFR, GSL, GP/PARI, mpmath, and Maxima, for numerical evaluation of special functions. There are significant discrepancies between these backends in the performance for numerical approximations of the same expression. An initial benchmark reveals, for example, that calculating spherical_bessel_J(1, 5.2) with SciPy is over 100 times faster than with Maxima.

The project has the following goals:

1. develop a benchmark framework to determine which backend should be used by default to evaluate a special function over a specific domain,

This sounds like a really bad idea for 2 reasons.
 1. none of the backends are stationary.  If someone comes up with a spherical_bessel evaluator that is 100X faster
yet again than SciPy, but is in Maxima, you are losing.
2. To determine over an arbitrary span of floats which program is most accurate and fastest requires a fairly
sophisticated set of tests.  For example even a function like sine can be delicate to evaluate, say at a high integer
multiple of pi.  And how do the functions respond at singularities?  Just generating random arguments is
not sensible. 
Oh, for some programs you may need to figure out what to do with unbounded inputs (integers, bigfloats).

2. create symbolic wrappers for all the special functions that can be evaluated numerically by a package included in Sage,

 

Um, I'm not sure what is required here, but maybe just bookkeeping??

2. create a data structure for generalized hypergeometric functions and extend the symbolic wrappers to obtain representations in terms of generalized hypergeometric functions when possible,

huh?  Wouldn't it always be possible to express generalized hypergeometric functions as generalized hypergeometric functions?
If you mean to simplify them, whose algorithm are you going to use?  Or did you not know about such things?
 

1. 
   
2. implement closure properties for holonomic functions as a next step to improve the symbolic processing of special functions in Sage.

 

.

Overall improvement of the Sage Android application

Rasmi Elasmar

(Mentor: Volker Braun, Backup: Harald Schilly)

Although there are already some existing efforts, Sage is still not easily accessible from the Android platform. The Sage Cell client/server infrastructure is an already existing step towards running Sage on a server and communicating back the results. The aim of this proposal is to fix, improve and update the Sage Android application to include new features and functionality, as well as an improved interface for simpler and improved usability. Android's new "Holo" style, sharing of calculations and results, and much more waits to be realized on Android for Sage.

This project, and the one below, suggest that people are going to continue to ignore the elephant not
in the Operating System Room,  namely  native Windows XP, Vista, 7, 8 ...

[Jeroen Demeyer]

On 05/30/2013 12:08 AM, rjf wrote:
> This project, and the one below, suggest that people are going to
> continue to ignore the elephant not
> in the Operating System Room, namely native Windows XP, Vista, 7, 8 ...

Windows support is very far from being ignored. In fact, there exists a
usable version of Sage using Cygwin. It doesn't work 100% and there are
some DLL rebasing issues, but it mostly works.

[Felix Salfelder]

depends on what "native" means. for debian i'd suspect native is
"without the distribution". on redmond i think rjf is pointing to at
least "without cygwin" (which looks far more difficult).

but why not stick to cygwin and package sage for cygwin? just think of
cygwin as a gnu-like distribution and read the fine print of the
debian-sage project ("the one below")...

regards
felix

[Harald Schilly]

On Thu, May 30, 2013 at 12:08 AM, rjf <fat...@gmail.com> wrote:
> This sounds like a really bad idea …

> Um, I'm not sure what is required here, but maybe just bookkeeping??

> huh?
> … ignore the elephant not in the Operating System Room,

The term "GSoC" stands for the "Google Summer of Code" programme. Do
you even know what it is? How it works and what happened so far? I
suggest you to first investigate its purpose and inherent goals.

[rjf]

Regarding GSoC, goals include

5. Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)

from
http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs#goals

I think that making free / open source  code work on Windows is in this category.
While it is hard to count how many people are using free software by looking
at (say) sourceforge statistics --- some people get secondary distributions --
for packages of Maxima, the vast majority of direct downloads, at least, are for
Windows.   I suppose every person who downloads Sage also downloads
Maxima, and those are not counted by sourceforge (or am I mistaken??)

Sage architects seem to believe it epitomizes a high level of software
engineering. Yet it cannot be run natively on the (still) most highly
available platform.

 I think that for a student it would be a very thorough
exposure to real-world scenarios.  I think it would be quite painful
since, I suspect,  Sage has no suitable mentor.

[Harald Schilly]

On Thu, May 30, 2013 at 6:07 PM, rjf <fat...@gmail.com> wrote:
> Regarding GSoC

The primary focus of the programme is on the students and their
participation, not the actual project. The point I wanted to make is,
that the participating organizations do not advertise jobs – instead
it's the other way around and students advertise themselves with their
project proposals.

Therefore it is first of all entirely pointless if you propose
something different, because you should have addressed that to all
students who submitted projects and not Sage – and second of all you
do not know all the other submitted proposals (which will not be
disclosed).

Harald

[Volker Braun]

First of all, its the Google summer of code and not the Microsoft summer of code ;-)

On Thursday, May 30, 2013 5:07:22 PM UTC+1, rjf wrote:

While it is hard to count how many people are using free software by looking
at (say) sourceforge statistics --- some people get secondary distributions --
for packages of Maxima, the vast majority of direct downloads, at least, are for
Windows.

That is because everyone but Microsoft has solved the problem of package management. Every linux distribution lets you install maxima with a one-liner, cryptographic chain of trust to the packager included. Maxima for windows still requires you to download an executable file from the internet with a web browser. Your download statistics is for users without package management.

 

Sage architects seem to believe it epitomizes a high level of software
engineering. Yet it cannot be run natively on the (still) most highly
available platform.

Or as I call it, the most quickly declining platform. You would do a disservice to students to teach them today about platforms that will clearly be obsolete by the time they will enter the workforce.

[Burcin Erocal]

I am going to respond to the comments below, since they come from a
senior member of the symbolic computation community. I would have
appreciated them a lot more if they were better informed, at least by
reading the original project proposal also posted on this list [1], and
intended as constructive criticism instead of just trolling.

[1] https://groups.google.com/forum/#!topic/sage-devel/00_Is5q_0IY

On Wed, 29 May 2013 15:08:02 -0700 (PDT)
rjf <fat...@gmail.com> wrote:

> On Tuesday, May 28, 2013 5:46:13 AM UTC-7, Harald Schilly wrote:
> >
> > Mathematical Functions Library

> > Eviatar Bach <http://www.phas.ubc.ca/%7Eeviatarb/> – University of

> > British Columbia in Vancouver, Canada
> > (Mentor: Flavia Stan, Backup: Burcin Erocal)
> >
> > Sage interfaces with multiple third-party libraries, such as MPFR,
> > GSL, GP/PARI, mpmath, and Maxima, for numerical evaluation of
> > special functions. There are significant discrepancies between
> > these backends in the performance for numerical approximations of
> > the same expression. An initial benchmark reveals, for example,
> > that calculating spherical_bessel_J(1, 5.2) with SciPy is over 100
> > times faster than with Maxima.
> > The project has the following goals:
> >

> > 1. develop a benchmark framework to determine which backend

> > should be used by default to evaluate a special function over a
> > specific domain,
> > This sounds like a really bad idea for 2 reasons.
> 1. none of the backends are stationary. If someone comes up with a
> spherical_bessel evaluator that is 100X faster
> yet again than SciPy, but is in Maxima, you are losing.

The point of the benchmark framework is to be able to repeat the
measurements when the backends change, on different platforms, etc.

See explanation of item 2 from [1].

> 2. To determine over an arbitrary span of floats which program is
> most accurate and fastest requires a fairly
> sophisticated set of tests. For example even a function like sine
> can be delicate to evaluate, say at a high integer
> multiple of pi. And how do the functions respond at singularities?
> Just generating random arguments is
> not sensible.

Again, see explanation of item 2 from [1].

> Oh, for some programs you may need to figure out what to do with
> unbounded inputs (integers, bigfloats).

How is this related? We already have interfaces to the packages
mentioned above to handle conversion issues.

> > 1.
> > 2. create symbolic wrappers for all the special functions that

> > can be evaluated numerically by a package included in Sage,
> >
> >
> Um, I'm not sure what is required here, but maybe just bookkeeping??

Yes, these are simple wrappers in Sage. Somebody needs to write them.

> > 1.
> > 2. create a data structure for generalized hypergeometric

> > functions and extend the symbolic wrappers to obtain
> > representations in terms of generalized hypergeometric functions
> > when possible,
> > huh? Wouldn't it always be possible to express generalized
> > hypergeometric
> functions as generalized hypergeometric functions?

For example, we want the software to convert bessel_j(2,x) to
1/8*x^2*hypergeometric_pfq(0, 1, 3, -1/4*x^2).

> If you mean to simplify them, whose algorithm are you going to use?
> Or did you not know about such things?

The goal is to provide a basis to implement algorithms used in DDMF [2].

[2] http://ddmf.msr-inria.inria.fr/


> > 1.
> > 2. implement closure properties for holonomic functions as a

> > next step to improve the symbolic processing of special functions
> > in Sage.

Cheers,
Burcin

[rjf]

On Thursday, May 30, 2013 9:23:32 AM UTC-7, Harald Schilly wrote:

...

 

Therefore it is first of all entirely pointless if you propose
something different, because you should have addressed that to all
students who submitted projects and not Sage – and second of all you
do not know all the other submitted proposals (which will not be
disclosed).

Harald

since I did not offer my services as a mentor, I didn't check over the submissions.
I think that people who think they may be mentors should be responsible for
checking over the (pre- ) proposals.
 

[rjf]

On Thursday, May 30, 2013 9:31:45 AM UTC-7, Volker Braun wrote:

First of all, its the Google summer of code and not the Microsoft summer of code ;-)

On Thursday, May 30, 2013 5:07:22 PM UTC+1, rjf wrote:

While it is hard to count how many people are using free software by looking
at (say) sourceforge statistics --- some people get secondary distributions --
for packages of Maxima, the vast majority of direct downloads, at least, are for
Windows.

That is because everyone but Microsoft has solved the problem of package management.

Yes, I agree that secondary distributions for linux means they are undercounted.
I do not know if Windows is truly in decline.

However, the latest Windows release of Maxima shows 1,545,527  direct downloads.

Every linux distribution lets you install maxima with a one-liner, cryptographic chain of trust to the packager included. Maxima for windows still requires you to download an executable file from the internet with a web browser. Your download statistics is for users without package management.

 

Sage architects seem to believe it epitomizes a high level of software
engineering. Yet it cannot be run natively on the (still) most highly
available platform.

Or as I call it, the most quickly declining platform. You would do a disservice to students to teach them today about platforms that will clearly be obsolete by the time they will enter the workforce.

I think you badly underestimate the value of a skilled Microsoft Windows expert now and over the
next decade or more.  I don't care for the Windows development environment, I am hardly
an expert on it though.  I have had students working for me who became skilled in using
it and found it (eventually) to be quite productive.  As I said previously, I think the lack of
a mentor in this area may disqualify GSoC Sage projects in this subject.
 

[rjf]

On Thursday, May 30, 2013 10:23:27 AM UTC-7, Burcin Erocal wrote:

I am going to respond to the comments below, since they come from a
senior member of the symbolic computation community. I would have
appreciated them a lot more if they were better informed, at least by
reading the original project proposal also posted on this list [1], and
intended as constructive criticism instead of just trolling.

Sorry if it seems like trolling, but I was hoping to nudge people in the
direction of doing something useful.  I went back and read the posting
from the link below.

[1] https://groups.google.com/forum/#!topic/sage-devel/00_Is5q_0IY

<snip>

 

The point of the benchmark framework is to be able to repeat the
measurements when the backends change, on different platforms, etc.

See explanation of item 2 from [1].

Yes, but having just read the proposal, I get the feeling that upon repeating
the measurements, there would be a need to re hand-code links.  This
would in any case be pretty delicate.  For example some implementations
are fast  or accurate in one part of the domain but slow  or inaccurate in others.
People building upon (say) Bessel_J  may be unhappy when you change.
 

> 2. To determine over an arbitrary span of floats which program is
> most accurate and fastest requires a fairly
> sophisticated set of tests.  For example even a function like sine
> can be delicate to evaluate, say at a high integer
> multiple of pi.  And how do the functions respond at singularities?
> Just generating random arguments is
> not sensible.  

Again, see explanation of item 2 from [1].

 

I repeat. Generating random arguments is not sensible.  (Incidentally,
you will still need to be able to generate the correct answers for these
functions. This seems to have been overlooked.
 What do you do if your benchmark test shows slightly
different answers from the systems?)
 My point is that this is poorly formulated as a question, and the proposed answer is also
poorly thought out.

> Oh, for some programs you may need to figure out what to do with
> unbounded inputs (integers, bigfloats).

How is this related? We already have interfaces to the packages
mentioned above to handle conversion issues.

Some routines in some systems will handle arguments that are unacceptably
large for routines in some other systems.
 

> >    1.
> >    2. create symbolic wrappers for all the special functions that
> > can be evaluated numerically by a package included in Sage,
> >    
> >  
> Um, I'm not sure what is required here, but maybe just bookkeeping??

Yes, these are simple wrappers in Sage. Somebody needs to write them.

> >    1.
> >    2. create a data structure for generalized hypergeometric
> > functions and extend the symbolic wrappers to obtain
> > representations in terms of generalized hypergeometric functions
> > when possible,
> > huh?  Wouldn't it always be possible to express generalized
> > hypergeometric
> functions as generalized hypergeometric functions?

For example, we want the software to convert bessel_j(2,x) to
1/8*x^2*hypergeometric_pfq(0, 1, 3, -1/4*x^2).

> If you mean to simplify them, whose algorithm are you going to use?
> Or did you not know about such things?

The goal is to provide a basis to implement algorithms used in DDMF [2].

[2] http://ddmf.msr-inria.inria.fr/

I'm not sure that this is sensible either.  If you wanted to implement Gfun  (the
other reference to the proposal) that might make more sense.

The winner is to be able to convert 1/8*x^2*H_pfq(...)  to Bessel_J(). 
Rewriting everything as hypergeometric functions is not hard and not
interesting.  See however work on Meijer G functions for integration.
This is however something that could probably be done in Maxima/Lisp,
if it is not already there.  And I think that some of it is in specfun /hypgeo.

RJF

[Harald Schilly]

On Thu, May 30, 2013 at 9:05 PM, rjf <fat...@gmail.com> wrote:
> As I said previously, I think the lack of
> a mentor in this area may disqualify GSoC Sage projects in this subject.

I cannot follow you.

Let's consider the following case: There are about 100 project
proposals submitted. Several ones of them are about Android, none of
them is about Windows – all the others concern different areas. Now,
please explain me:
1. How a mentor "in the area of Windows" should have an impact in
having a project about Windows in that case?
2. Why are all projects regarding areas other than "Windows"
automatically disqualified?

H

[Volker Braun]

On Thursday, May 30, 2013 8:05:17 PM UTC+1, rjf wrote:

I think you badly underestimate the value of a skilled Microsoft Windows expert now and over the

next decade or more.

Well there will certainly be demand, somebody has to help the lucy ones escape their vendor lock-in and provide continued maintenance for the truly screwed. So presumably the value of a Windows admin will stay at about the current state. That is, about 10k/year less than a Unix admin. That's still not bad, but hardly what I would recommend to my students.

[rjf]

On Thursday, May 30, 2013 12:26:10 PM UTC-7, Harald Schilly wrote:

On Thu, May 30, 2013 at 9:05 PM, rjf <fat...@gmail.com> wrote:
> As I said previously, I think the lack of
> a mentor in this area may disqualify GSoC Sage projects in this subject.

I cannot follow you.

Let's consider the following case: There are about 100 project
proposals submitted. Several ones of them are about Android, none of
them is about Windows – all the others concern different areas. Now,
please explain me:
1. How a mentor "in the area of Windows" should have an impact in
having a project about Windows in that case?

If a student were to propose to make a native port of Sage to
Windows, such a project would require a mentor.  If there is no
mentor, such a project would be rejected.
 

2. Why are all projects regarding areas other than "Windows"
automatically disqualified?

I did not disqualify all other areas. I don't see how you are reading
my note to think that.  There are plenty of appropriate areas and
there are probably projects suitable for an energetic and clever
but possibly inexperienced student.
 

RJF

[rjf]

Interesting perspective. Where did you get the $10k/year difference?
You seem to think that Microsoft will just disappear.  It would be a shame for the
funding of the Microsoft-INRIA research program.

There are, I think, some parts of the Windows ecosystem that are
far superior to that on Linux, though I suppose one can, for $$ upgrade
Linux.    Two that I have encountered  (at least as of a few years ago --
handwriting recognition  and speech recognition) .

[Volker Braun]

On Friday, May 31, 2013 7:39:02 AM UTC+1, rjf wrote:

Interesting perspective. Where did you get the $10k/year difference?

http://www.indeed.com/salary?q1=Unix+System+Administrator&q2=windows+System+Administrator

 

You seem to think that Microsoft will just disappear.

They won't disappear, just like IBM didn't disappear after they lost their near-monopoly. They will have to learn how to play nice with other vendor's systems and begin offering solutions that are best for their customers, though.

[Harald Schilly]

Thank's for the above clarification.

On Thursday, May 30, 2013 12:08:02 AM UTC+2, rjf wrote:

continue to ignore the elephant not

in the Operating System Room,  namely  native Windows XP, Vista, 7, 8 ... 

It looks like the elephant is changing:

Here is a link to a brand new study by KPC&B released 2 days ago. Slide number 109 shows the global market shares of personal operating systems. Especially, the changes of Windows/Intel vs. Android/iOS and also the overall worldwide personal usage of mobile phones (1.5B subscribed smartphone users vs. 5B mobile phone subscribers in 2012) indicate for me, that it is not a bad idea to spend some time on this.

http://www.slideshare.net/kleinerperkins/kpcb-internet-trends-2013

Harald

[kcrisman]

On Friday, May 31, 2013 6:55:01 AM UTC-4, Harald Schilly wrote:

Thank's for the above clarification.

On Thursday, May 30, 2013 12:08:02 AM UTC+2, rjf wrote:

continue to ignore the elephant not

in the Operating System Room,  namely  native Windows XP, Vista, 7, 8 ... 

Maybe the Windows discussion could move to sage-flame...  as a practical matter, given Sage's mission statement, having as good a solution on Windows as possible certainly would help with respect to proprietary alternatives.   (And low-end situations, where people are very likely to have an older Windows OS and not have the $ or hardware to upgrade immediately.)   I think the mentor thing is a red herring, though; the number of projects proposed on Windows probably would roughly match the number of mentors (at least by proportion), because you wouldn't likely get interested in Sage development in the first place unless you were on Linux or Mac.

[mmarco]

I know that this is not exactly about the windows port situation, but
still, it is closely related to the sage-on-windows issue:

On the project ideas suggestions that were proposed by sage, there was
one dedicated to writing a GUI to handle the sage installation in
windows. No student decided to propose such a project.

On the other hand, there are people working on a cygwin port. I
haven't tested it, but they claim to have obtained something usable.
So it is not true at all that the windows port has been abandoned.
What it is true, on the other hand, is that the prefered way to run
sage on windows is through the virtualbox appliance. This is maybe a
suboptimal solution, but it's a solution that works. So the statement
that we are ignoring the windows is far from being true.

[rjf]

On Friday, May 31, 2013 3:21:06 AM UTC-7, Volker Braun wrote:

On Friday, May 31, 2013 7:39:02 AM UTC+1, rjf wrote:

Interesting perspective. Where did you get the $10k/year difference?

http://www.indeed.com/salary?q1=Unix+System+Administrator&q2=windows+System+Administrator

 

This is an interesting resource.  Here's some more data from the same source.

Unix Systems Administrator    $88,000.
Windows Systems Administrator $77,000.
Lisp Programmer               $95,000.
Python Programmer             $89,000

[rjf]

On Friday, May 31, 2013 5:25:39 AM UTC-7, kcrisman wrote:

   I think the mentor thing is a red herring, though; the number of projects proposed on Windows probably would roughly match the number of mentors (at least by proportion), because you wouldn't likely get interested in Sage development in the first place unless you were on Linux or Mac.

My assumption was that the number of mentors willing and capable of supervising a Windows port
was, most likely, zero.  It's the kind of expertise that is  probably not so common among mathematicians.
So I agree that the number might match, proportionally.

My point was that Google goals were consistent with a possible (student-proposed)
project of porting Sage to native Windows framework. 

[rjf]

On Saturday, June 1, 2013 6:16:59 AM UTC-7, mmarco wrote:

On the other hand, there are people working on a cygwin port. I

haven't tested it, ... Why is it suboptimal?  (one guess: you can't

have a one-click windows installer?)

I thought this had been done some time ago -- a cygwn solution.
It also seemed to me that there was an undercurrent of activity
to get a native windows version.  I'm not sure why this was viewed
as valuable -- certainly there are some neat things on Windows
that are not on Linux, but just as certainly Sage can't depend on
them... people would be upset if Sage on
windows had better features and could not be back-ported to Linux.

Anyway,  maybe we will all meet "in the cloud".

[leif]

Demanding William's Lisp port of Sage even more.

(Although I have to admit I haven't checked whether there are figures
for Cython programmers as well.)


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Harald Schilly]

On Saturday, June 1, 2013 4:51:39 PM UTC+2, rjf wrote:

Lisp Programmer               $95,000.

I raise you the VAX Mainframe: $100,000

http://www.indeed.com/salary?q1=vax+mainframe

Welcome to the cloud!

Could we stop this pointless "discussion" please?

[leif]

Modulo the time frame.

[mmarco]

>I haven't tested it, ... Why is it suboptimal?

I used the word "suboptimal" to reffer to the virtualbox based
solution, not to the cygwin one.

If by "native" you mean "without cygwin"... i am afraid that that we
would be very far away from that. Not only from the sage side (at the
end of the day, most of the code writen by sage devs is portable
python/cython), but from the thirthd party pieces: Singular is not
natively ported to windows (runs under cygwin), GAP for windows uses
cygwin too, Pari/gp also runs under cygwin (and has limitations
compared to the linux version)...

So the native windows port of sage is really unlikely to happen in the
mid term. Considering that, Sage releases official versions that work
under windows (via virtualbox), and also a cygwin port is being worked
on (although it is true that, with the virtual machine available, this
has become a secondary effort).

And since you mention the one-click installer... that was pretty much
what the GUI project that we suggested was about. As i said, no
student showed interest in working on that. As i said, the statement
that the sage project is turning its back on windows system is far
from being true.

[Eviatar]

On Thursday, 30 May 2013 12:21:25 UTC-7, rjf wrote:

I repeat. Generating random arguments is not sensible.  (Incidentally,
you will still need to be able to generate the correct answers for these
functions. This seems to have been overlooked.
 What do you do if your benchmark test shows slightly
different answers from the systems?)
 My point is that this is poorly formulated as a question, and the proposed answer is also
poorly thought out.

Hello,

Do you have any suggestions on how to benchmark the different backends other than pick random arguments from specified domains? I'm open to any suggestions. In any case, the benchmark framework is going to be a relatively minor part of the project.

Eviatar

[William Stein]

One tidbit to add to this discussion (which has gone on way too long),
is that in my experience often compute intensive functions in Sage are
faster on Windows when run on a VM than when run under Cygwin or
natively. There are many reasons for this, including LInux's
excellent memory management, special optimizations people writing code
make for the Linux version of some code, but don't make anywhere else,
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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



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