On Thu, Aug 21, 2014 at 9:45 PM, Bill Hart <goodwillh...@googlemail.com> wrote:
> Julia can already call Python functions (and I don't mean in some
> theoretical, technical sense, I mean very practically via an interface
> designed explicitly for such). So it's not necessary to "move" Sage from
> Python to Julia. Other Scientific Python projects haven't done this.
>
> There are other reasons why this is not necessary, because of other
> technical advances that will become available in the coming few years (they
> are working in labs right now).
>
> Instead, the Sage project should do two things in my opinion:
>
> 1) Make Julia part of the Sage ecosystem (it's already had a huge investment
> from the scientific and statistical communities, so this is a no-brainer if
> you want to embrace that community)
>
> 2) Invest in the technologies that are making Julia successful (jit,
> dependent typing, metaprogramming, type checking and inference, etc.)
>
> Whether 2 involves rewriting some functionality in Julia, or simply finding
> ways of adding such functionality to Python is really neither here nor
> there.
>
> What Sage can't do is just stagnate and ignore progress. If it does, it will
> be brushed aside as if it wasn't even there, as has happened over and over
> again in the history of computer algebra! And it's happening to Sage. A few
> years ago, people at conferences were excitedly demonstrating stuff in Sage.
> This year, they've moved back to Magma.
To fill out this point a little, in my experience (recently, and in
the past), such people choose to use Magma instead of Sage because
Magma is capable of doing X, where X is something important they need
for their work. In some cases, Magma does X slowly, with frequent
crashes, etc.. But it does X nonetheless; whereas, programming Sage
to do X from scratch would take the right expert about 2 years. This
illustrates how Sage is failing to be a viable alternative to Magma.
If Magma does X, and Sage doesn't, and people care about X, then Sage
is not a viable alternative.
Unfortunately, I don't think see "Sage switching to Julia", or Sage
having better support for "(jit, dependent typing, metaprogramming,
type checking and inference, etc.)" in itself would be enough of a
reason for people to have the option to choose Sage over Magma.
Such advantages don't address the **real difficulty** in implementing
a first version of X that works, since implementing X fundamentally
takes reading and understanding papers, working out the right
algorithms, etc. -- it's almost entirely a human expert and design
problem. At least that's my experience watching/making this happen
many times over the last decade. Please keep in mind that much of
your (Bill Hart's) implementation work has been looking at
implementations of various algorithms and coming up with a new
approach that is better in certain ways -- that's certainly very
important and useful, but it is a different problem than doing the
first general implementation of code for computing with some class of
mathematical objects. It's like the difference between building the
first ever car and inventing a better wheel.
Here are two concrete examples of X's where I've seen this exact
situation in the last few months, and for which there is no open
source implementation in any language, despite a demand for one over
the last 10 years:
- (a) quaternion algebras over number fields (topic of Sage Days
61 next week -- https://sites.google.com/site/sagedays61/)
- (b) functional fields, mainly Florian Hess's Riemann-Roch spaces
algorithm; this supports basic algebraic geometry constructions, which
Magma has and Sage doesn't.
There are dozens of other similar examples. They are hard to get
funded with grants, because in all cases the proposal basically says:
"replicate something that's already been done... years ago". Also,
the type of funding one wants is for a person to work full time on the
problem for 1-2 years. A grant proposal that says "We plan to do Y,
and [lots about Y], but we need X [a little about X]," has a chance to
get funded (depending on Y). However, there are many X's (like a and
b above) where I certainly can't make a compelling case for any Y
except "make sage a viable alternative".
If we actually had "real money" to support open source math software
development, I'm certain there could be useful open source
implementations of (a) and (b) above within 2 years. I can think of
specific people who would love to carry out these core implementation
problems, but instead will be teaching a lot of Calculus instead, and
probably not enjoying it.
Anyway, a lack of funding is a big obstruction to creating a viable
open source free alternative to the Ma's for all.
-- 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+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.
