Dismissing Sage with one sentence

[rjf]

I'm not sure you will all be able to follow this link..

http://ac.els-cdn.com/S0747717111002124/1-s2.0-S0747717111002124-main.pdf?_tid=01d031c0-3aff-11e2-94fb-00000aab0f01&acdnat=1354287949_52b54cfa0d69a9b8bc65bdee9d33d685

but it is to an article in J. of Symbolic Computation

Here is a quote (with context)

CAS authors have attempted to address these user needs in various ways. For example, a CAS may
write input files for another program and invoke it, the other program will then write input to the
CAS in a file and exit, and finally, the CAS will read this input and return a result. This works, but
has fairly serious limitations. A better setup might allow the CAS to interact with other programs
while they run and provide a separate interface to each possible external system. The SAGE system
(Stein et al., 2010) is essentially built around this approach. However, achieving this is a major
programming challenge, and an interface will break as soon as the other system changes its I/O format,
for example.
Furthermore, individual CPU cores have essentially stopped increasing in power, but multicore
systems are becoming more numerous. A typical workstation now has 4 to 8 cores, and this is only the
beginning of the multicore/manycore revolution (Held et al., 2006). Ifwewant to solve larger problems
in future, it is essential for us to exploit multiple processors in a way that gives good parallelism for
minimal programmer/user effort.

....
From

Easy composition of symbolic computation software using
SCSCP: A new Lingua Franca for symbolic computation✩

S. Linton , K. Hammond, A. Konovalov , C. Brown, P.W. Trinder,
H.-W. Loidl , P. Horn, D. Roozemond

Journal of Symbolic Computation 49 (2013) 95–119
.....

Ordinarily it would seem unnecessary to make this comment,
but seeing as how this note appears in Sage-flame, let me
suggest that you read this article before commenting.

If you do not have access to J. Symb. Computing, maybe
that should be remedied.
RJF

[David Joyner]

I have not read this paper.
However, I know Steve Linton, Alexander Konovalov, and Max Horn (who are
all GAP developers) and I am somewhat familiar with SCSCP. I don't agree
with your summary that this paper "dismisses Sage with one sentence",
but that is based solely on my understanding of SCSCP
(http://www.cs.st-andrews.ac.uk/~alexk/scscp/)
and of the authors' opinion of Sage. My vague understanding is that
SCSCP solves a problem that Sage does not. The way use Sage on a daily basis,
off-line command line computations, would not work well with the way
I understand SCSCP. The way I see it, the SCSCP approach is basically
arguing for widespread use of OpenMath.

> --
> You received this message because you are subscribed to the Google Groups
> "sage-flame" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sage-flame/-/VqoFLCOL3OUJ.
> To post to this group, send email to sage-...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-flame+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sage-flame?hl=en.

[rjf]

There's a word or two missing, I think

On Friday, November 30, 2012 11:41:29 AM UTC-8, David Joyner wrote:

 The way [I, David Joyner]  use Sage on a daily basis, [for]

off-line command line computations, would not work well with the way
I understand SCSCP.

They are not arguing that Sage is unusable, but (I think) that the approach does
not scale, or more precisely, it does not track with changes in the clients.
 

The way I see it, the SCSCP approach is basically
arguing for widespread use of OpenMath.

That's my view, too.

It's not a very convincing argument unless you first accept OpenMath as
some kind of widely-accepted standard.

An opposing view might look like this:
Take a computer algebra system Q written in Lisp  (Reduce, Axiom, Fricas, Maxima, Macsyma)
add in N different systems by writing N programs to communicate via Lisp s-expressions
(probably plus asynchronous signals). Use sockets, maybe. or shared memory.
I think that Lisp s-expressions can encode anything you can do in OpenMath, but probably
with 1% of the bandwidth.

Compare this with SCSCP  (or for that matter, Sage).

Invent a new system, call it S.  now to link it to Q and N additional systems one must
write N+1 different programs to communicate with S.  Instead of having partisans of
one system Q immediately on your side, and the other N user communities grumbling
that they are not in the driver's seat,  you have initially zero partisans of Q, and
N+1 user communities grumbling.

I suppose that Sage could argue that it has all those Python fans in its corner, and
that Python is easy to learn, natural, etc. and that those "systems" like Maxima
really benefit from a layer of obscure syntax for a user interface. I don't buy it.

I am not saying that merging facilities that have been programmed independently
is not potentially beneficial.  But making it possible technically is only one aspect.
Doing it so the resulting system exhibits  something that is akin to "good taste"
is much harder.  This is difficult to characterize, and may depend on the audience.
The Linton etal paper argues that robustness follows from using OpenMath and
Sage falls short.

Re taste: Education of high-school students is a different context from (say) partial differential
equation solutions or computational group theory.

RJF

 

[Tom Boothby]

So... Sage is dying because we interact with dinosaur CAS's that use
pipes & files. We're dying because when a yet-to-come CAS appears
that doesn't interact via pipes, files, (c,c++,fortran) libraries,
XMLRPC, etc., will be incompatible with our standard approach.

I must agree. Sage is based on strict adherence to a single approach,
and it has never deviated from that single approach of interacting
with other CAS's. Totally. These authors sure put the final nail in
Sage's coffin, we should all go work on that other modern CAS that's
totally incompatible with the rest of the world and DOES NOT EXIST.

Thanks for sharing that, Dick. We can stop wasting our lives now!

> https://groups.google.com/d/msg/sage-flame/-/zVwgPuwRwXwJ.

[rjf]

On Saturday, December 1, 2012 3:30:35 PM UTC-8, Tom wrote:

... blah blah blah..

  Apologies.  I should have added a sentence ..

 

>> > Ordinarily it would seem unnecessary to make this comment,
>> > but seeing as how this note appears in Sage-flame, let me
>> > suggest that you read this article before commenting.

This means you, Tom.

 

[Tom Boothby]

wat?! Reading? I stand behind my kneejerk reaction to your post
without a read-through! This isn't
sage-think-about-stuff-before-writing, this is sage-flame, you jerk!

> --
> You received this message because you are subscribed to the Google Groups
> "sage-flame" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/sage-flame/-/1kIxHR9xjzEJ.

[rjf]

On Saturday, December 1, 2012 9:47:58 PM UTC-8, Tom wrote:

wat?!  Reading?  I stand behind my kneejerk reaction to your post
without a read-through!  This isn't
sage-think-about-stuff-before-writing, this is sage-flame, you jerk!

 
You never fail to disappoint.

Actually, I suppose a proper response to this is
"I'm rubber, you're glue. Everything you say sticks to you!"

RJF

 

[Tom Boothby]

I might point out, you *did* say "in one sentence". Rather
misleading, I say, if you expect us to read a whole paper. ;)

> --
> You received this message because you are subscribed to the Google Groups
> "sage-flame" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/sage-flame/-/5iyqkgBfhKEJ.

[rjf]

Tom, the one sentence in the referenced paper was

"However, achieving this is a major
programming challenge, and an interface will break as soon as the other system changes its I/O format,
for example."

The rest of the quote was to supply some context.

As for expecting you to read a whole paper, I said
"Let me suggest that you read this article before commenting."

The reason for this suggestion is that a Sage proponent might
wish to defend the position that these people should just have
adopted Sage, rather than building a whole new system.




Deficient in reading comprehension.
Deficient in understanding irony.
Deficient in conventional discourse as being
 able to state and defend a position.

Has anyone at Sage Central read this article? Or interacted
with these researchers at any point on this topic?

RJF

[Dima Pasechnik]

On Monday, 3 December 2012 01:15:34 UTC+8, rjf wrote:

Tom, the one sentence in the referenced paper was

"However, achieving this is a major
programming challenge, and an interface will break as soon as the other system changes its I/O format,
for example."

The rest of the quote was to supply some context.

As for expecting you to read a whole paper, I said
"Let me suggest that you read this article before commenting."

The reason for this suggestion is that a Sage proponent might
wish to defend the position that these people should just have
adopted Sage, rather than building a whole new system.




Deficient in reading comprehension.

those in glass houses... :-)

[you might have noticed a deleted message in this thread, it was an rjf's repost of a message I sent to him, which contained details I did not want to make public, and explicitly said so in the message - yet it was reposted without much reading :-)]

 

Deficient in understanding irony.
Deficient in conventional discourse as being
 able to state and defend a position.

Has anyone at Sage Central read this article? Or interacted
with these researchers at any point on this topic?

I investigated usability of SCSCP at some  point several years ago, and didn't find it useful for purposes of 

connecting GAP with numerical software, something that  I need for my research.

Actually, OpenMath, the protocol used by SCSCP, is something what numerics people never heard of, it seems.

They even use the abbreviation SDP for something rather different...

Besides, converting 1000x1000 floating point matrices into XML to send them over - that's not one wants to do a lot,

isn't it?

Then, the article (a version of a paper in ISSAAC 2010) in question dates back to 2009. 

Perhaps one can do user base statistics for Sage vs SCSCP for the past year...

Apparently this "major programming challenge" Sage faced, according to this article, 

has not been that severe.

Certainly, it could just have been that ruthless Sage marketing machine...

Dima