Vladimir Bondarenko wrote:
Hello Nasser,

Thanks for your idea.

Technically, we could do this. Anyways, now we have a small amount of
resource we can dedicate to a concrete system; but we here hope that
the things could look better reasonably soon, hopefully, this year.

As you understand, if we here dedicate something to SAGE, we subtract
this from the above list I quoted.

Not necessarily - you have many options.

1) Release the code under the GPL, letting others adapt it to SAGE.

Of course, if you want to sell your code, which I think you do, this
might not be too attractive.

(As I have said before, my personal belief is your biggest barrier to
commercial exploitation is your unorthodox approach.)

2) Open source the code, but license it under a restrictive license that
expressly forbids usage by commercial users such as Wolfram Research
without payment of a license fee, but allows its free use testing
open-source programs such as SAGE.

Of course WRI could technically ignore your license, but I very much
doubt they would. No WRI manager is going to ask an employee in WRI to
ignore your license.

However, you may be exploited in some ways.

* An employee of WRI could compile your code at home, report bugs at
WRI, not telling the truth how he found them. He would appear a good
employee and gain promotion.

* Normal users would find bugs, report them to WRI, so WRI gain while
others do the work for them.

3) Adapt your code to SAGE (some work on your part), then release a
*binary* package that only works with SAGE and written in such a way it
would not work with the commercial programs Mathematica, Maple, MATLAB etc..

Obviously you could couple this technical restriction with a license
which prevents its adoption by commercial applications.

I've no idea how difficult it might be for someone to write a
SAGE->Mathematica translator, then use your binary code to test
Mathematica by fooling your code.

Again, nobody in WRI is going to officially ask another employee to
write such a translator, but there might be an incentive for some
employees to do this at home.

4) Release a binary package for testing SAGE an use a client/server
approach so that the code needs an internet connection and gets a
license valid for one day only - much the same as FlexLM works. Then if
you thought you were being exploited you could quickly put a stop to it.

PS - you asked me to email you, which I did, but you never replied.

Dave (from the UK).

On Mar 30, 8:57 am, "Nasser Abbasi" <n...@12000.org> wrote:
It would be interesting if your VM machine can add SAGE to the systems it
tests. SAGE is described here:

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

I played with SAGE a little, but I find its interface on windows, having to
use a browser, a bit awkward to say the least. I have not tried it text
based interface.

AFAIK Sage is primarily a browser-based notebook interface to other
packages such as Maxima and SciPy. So it is those other packages that
would benefit from testing and not SAGE itself.

Could you please tell why do you feel that testing SAGE could be really
useful? Useful for whom?

By the way, maybe you know, approximately, how many persons use SAGE?
Occasionally? On a constant basis?

Seehttp://www.sagemath.org/
Browse through the code:http://www.sagemath.org/hg/sage-main?cmd=manifest;manifest=-1;path=/s...

I don't think that the right way to introduce SAGE to a newbie is to
ask him to browse the system's source code ...

SAGE might be a useful program, but the current website is somehow not
convincing (and not informative) enough to persuade me to attempt a
500 MB download of something that will only run on a linux system
running inside an emulator ... Just compare it with e.g. the orders
of magnitude better Yacas website to see what I mean.

I understand that it is essentially a python
program, and thus the python implementation may be a boon or a
disaster, and maybe that is the most prominent factor that can be
identified. (Is there a compacting garbage collector for python?)

If we don't raise questions when people continue to compare CAS on
essentially irrelevant grounds, we are in the position of essentially
allowing others who read this newsgroup from accepting these comments
as valid.

Well, VB managed both to post to an additional distracting newsgroup
(sci.math) and (deliberately?) misinterpret the main question. The
question was whether we could come up with benchmarks that tested the
long-term performance of a CAS (and maybe, whether that mattered or
not). How long it takes to provoke a fatal error by some heuristic
search is a different question.

Thomas Richard actually provided info regarding Maple 11 behavior in
returning memory. It still doesn't answer the more pointed question,
which is... can Maple 11 get into a situation where its memory usage
is so scattered that it runs at "disk speed" even though the actual
data in use is not so voluminous.

Whether SAGE should be tested independently of its components is
hardly a question. Why should SAGE not have bugs in addition to the
bugs in the libraries it uses?

On the main question here, as to
whether there are benchmarks that would test efficiency, I assume that
the benchmarks for Maxima (etc) would be relevant to SAGE to the
extent that SAGE is just calling Maxima. To the extent that SAGE has
its own inner loops and memory allocation, it could have its own
problems or successes. I understand that it is essentially a python
program, and thus the python implementation may be a boon or a
disaster,

and maybe that is the most prominent factor that can be
identified. (Is there a compacting garbage collector for python?)

If we don't raise questions when people continue to compare CAS on
essentially irrelevant grounds, we are in the position of essentially
allowing others who read this newsgroup from accepting these comments
as valid.

Michael Abshoff writes



MA> Sage farms out most of those tasks [integration, differentiation,
MA> ODE] to Maxima, which is already tested.

Why sure, I meant precisely this!

Hello Nasser,

Thanks for your idea.

Technically, we could do this. Anyways, now we have a small amount of
resource we can dedicate to a concrete system; but we here hope that
the things could look better reasonably soon, hopefully, this year.

As you understand, if we here dedicate something to SAGE, we subtract
this from the above list I quoted.

It runs on various flavors of Linux and also on OSX. Microsoft
Reseatch is paying for a native Windows port and Solaris is getting
close to running. There are many other worthwhile platforms left after
that in my book.

Well, VB managed both to post to an additional distracting newsgroup
(sci.math) and (deliberately?) misinterpret the main question.  The
question was whether we could come up with benchmarks that tested the
long-term performance of a CAS (and maybe, whether that mattered or
not). How long it takes to provoke a fatal error by some heuristic
search is a different question.

Thomas Richard actually provided info regarding Maple 11 behavior in
returning memory.  It still doesn't answer the more pointed question,
which is... can Maple 11 get into a situation where its memory usage
is so scattered that it runs at "disk speed" even though the actual
data in use is not so voluminous.

Whether SAGE should be tested independently of its components is
hardly a question.  Why should SAGE not have bugs in addition to the
bugs in the libraries it uses?  On the main question here, as to
whether there are benchmarks that would test efficiency, I assume that
the benchmarks for Maxima (etc) would be relevant to SAGE to the
extent that SAGE is just calling Maxima. To the extent that SAGE has
its own inner loops and memory allocation, it could have its own
problems or successes.  I understand that it is essentially a python
program, and thus the python implementation may be a boon or a
disaster, and maybe that is the most prominent factor that can be
identified.  (Is there a compacting garbage collector for python?)

I don't understand NA's comment that SAGE is the first GPL CAS, since
it depends on several other predecessors. Or the comment that large
problems in Maple are interpreted.

If we don't raise questions when people continue to compare CAS on
essentially irrelevant grounds, we are in the position of essentially
allowing others who read this newsgroup from accepting these comments
as valid.

In Maple memory is allocated but not returned to the operating system.

RJF> whether we could come up with benchmarks that tested the
RJF> long-term performance of a CAS (and maybe, whether that
RJF> mattered or not).

A very good question. The long-term performance is something the
customers need. Personally, I hate when after using Maple 11 for
several days, I must reboot as my machine gets tortoise-like.

In contrast, if Mathematica 6 runs for days, and Maple 11 is not run
over this span of time, there is no tangible performance degradation.

On Mar 30, 4:47 pm, caveman <dev.n...@dev.null.com> wrote:
mabshoff wrote:
It runs on various flavors of Linux and also on OSX. Microsoft
Reseatch is paying for a native Windows port and Solaris is getting
close to running. There are many other worthwhile platforms left after
that in my book.

Hi,

What is your problem with Solaris?

It compiles in 32 bit mode with small modifications, but the test
suite doesn't pass yet.

So if you have some
more test machines with say Indiana on Sparc I would be more than
happy to take you up on that offer. Even build and test feedback would
be nice. Since this is getting OT we should take this offlist from now
on or go over to gg:sage-devel.