On Thu, 25 Sep 2014, rjf wrote:
I am curious as to what parts of Sage you use. I suspect you are using
it mostly as a front-end to Maxima, In which case -- have you considered
using Maxima directly, esp. wxmaxima?
Installing Sage is quite easy; it took time if you compile it yourself,
but
On 25 September 2014 20:51, kcrisman kcris...@gmail.com wrote:
For Sage, fixing the problem is actually trivial: when the
hypergeometric
function is a polynomial (and at least when the inputs are exact),
don't
call mpmath; just evaluate the polynomial directly and then call .n()
on the
On 2014-09-25, kcrisman kcris...@gmail.com wrote:
For Sage, fixing the problem is actually trivial: when the
hypergeometric
function is a polynomial (and at least when the inputs are exact),
don't
call mpmath; just evaluate the polynomial directly and then call .n()
on the
Hello sage-devel,
The upstream situation with PARI has always been somewhat difficult. The
don't easily accept patches written by people which are not in their
inner circle. That, plus the importance of PARI inside Sage, is probably
also one of the reasons that PARI in Sage has so many
Sage is very lucky indeed that Pari exists and is as good as it is for
many things. Sage is also very lucky that you (Jeroen) exist since
you have been very useful to *both* projects, working hard to improve
both, and on particular reporting -- and fixing -- a lot of upstream
bugs, i.e. bugs in
bump
On Thursday, September 18, 2014 7:30:48 PM UTC+1, Volker Braun wrote:
As we discussed about a month ago, the Sage doctests differ from the
command line output since the displayhook is different. Fix is now at
http://trac.sagemath.org/ticket/16746
Since the change led to a large
On Thu, Sep 25, 2014 at 9:51 PM, kcrisman kcris...@gmail.com wrote:
For Sage, fixing the problem is actually trivial: when the
hypergeometric
function is a polynomial (and at least when the inputs are exact),
don't
call mpmath; just evaluate the polynomial directly and then call .n()
On Thursday, September 25, 2014 2:48:41 PM UTC-5, kcrisman wrote:
And it was quite likely Pascal being learnt on paper.
For what it is worth, my first programming language was C learned on
paper, probably around 1981.
But probably not ideal to go from paper to production in
+1 to adding the patches
If upstream keeps refusing additions like ispseudoprimepower then we could
collect them into a separate shared library that we install separately, but
its not worth the effort right now.
On Friday, September 26, 2014 9:32:59 AM UTC+1, Jeroen Demeyer wrote:
Upstream's
On 2014-09-26 10:52, John Cremona wrote:
I'm sure many
Sage users do not know how much Pari is used for come very important
functionality, such as most number field stuff.
...and a lot of elliptic curves stuff, elementary number theory of
integers, some linear algebra, arbitrary-precision
Hi Jeroen and sage-devel,
The upstream situation with PARI has always been somewhat difficult. The
don't easily accept patches written by people which are not in their
inner circle. That, plus the importance of PARI inside Sage, is probably
also one of the reasons that PARI in Sage has so
On Friday, September 26, 2014 10:46:08 AM UTC+1, Peter Bruin wrote:
To be honest, I tend to agree with this argument. Once you start defining
arithmetic with infinity, you are asking for trouble because there isn't
one set of semantics that is valid in all or even most cases; you are also
Hi Volker,
If upstream keeps refusing additions like ispseudoprimepower then we could
collect them into a separate shared library that we install separately, but
its not worth the effort right now.
I don't think there is a possibility of this happening. To avoid the
impression that it is
On 2014-09-26 11:46, Peter Bruin wrote:
At the moment it is not clear to me that starting to track the
development version is the best decision. It's called development
version for a reason...
1) I think the new functionality that it provides (#16931) is very cool
and a good reason to use it.
After clicking Lastmod-header it got tickets sorted like
1 mins 23 hours 32 mins 8 days
Is this bug in trac in general or some setting at sage trac?
--
Jori Mäntysalo
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this
Op vrijdag 26 september 2014 11:58:44 UTC+2 schreef Volker Braun:
On Friday, September 26, 2014 10:46:08 AM UTC+1, Peter Bruin wrote:
To be honest, I tend to agree with this argument. Once you start
defining arithmetic with infinity, you are asking for trouble because there
isn't one set
On 2014-09-26 11:46, Peter Bruin wrote:
Why write a new function for something
that doesn't seem to be _that_ widely useful, and can easily be
implemented in two lines (ispower() followed by ispseudoprime())?
To expand on this a bit more: I think the number of lines in the
implementation is not
On 2014-09-26 13:18, Peter Bruin wrote:
It is completely sensible for valuation(0)
to result in an error (or a useless infinity return value)
Raising an error and returning a useless infinity value are *very*
different things. The first gives an error immediately such that you
know where the
On 2014-09-26 11:46, Peter Bruin wrote:
Why write a new function for something
that doesn't seem to be _that_ widely useful, and can easily be
implemented in two lines (ispower() followed by ispseudoprime())?
To expand on this a bit more: I think the number of lines in the
For Sage, fixing the problem is actually trivial: when the
hypergeometric
function is a polynomial (and at least when the inputs are exact),
don't
call mpmath; just evaluate the polynomial directly and then call
.n()
on the
result.
Except then Sage would
But probably not ideal to go from paper to production in just a few
weeks along with your other coursework!
They are really cool and don't need much more than paper and pencil, or
in one case small cups that can stack. Worth a peek.
Ok, here's my paper-math tale from the days
After clicking Lastmod-header it got tickets sorted like
1 mins 23 hours 32 mins 8 days
It's not a direct answer to your question, but you might be interested
in http://trac.sagemath.org/report/92
This is nearly useless, though, except for tickets modified since the last
Hi,
I don't know if this is the good place to ask but I did not find any
contact information on the trac page.
When I am trying to open the ticket #15916, via
http://trac.sagemath.org/ticket/15916
I get the following error message:
Oops…
*Trac detected an internal error:*
KeyError:
This is nearly useless, though, except for tickets modified since the last
Sage (official) release. Is there any way to get back to the old system
where the milestone would change *without* changing the ticket - and hence
the ticket last-mod time? It is very misleading to see ticket
On 2014-09-26, kcrisman kcris...@gmail.com wrote:
For Sage, fixing the problem is actually trivial: when the
hypergeometric
function is a polynomial (and at least when the inputs are exact),
don't
call mpmath; just evaluate the polynomial directly and then call
.n()
on
From the noises I hear, in particular on our departamental email, sysadmins
might be tempted to rm -f /bin/bash
from any place they can get their hands on.
It might mean that for building/working with Sage one will need a separate
install of bash.
(or we should switch to another shell...)
Dima
On 26 September 2014 14:59, Dima Pasechnik dimp...@gmail.com wrote:
From the noises I hear, in particular on our departamental email, sysadmins
might be tempted to rm -f /bin/bash
from any place they can get their hands on.
It might mean that for building/working with Sage one will need a
Op vrijdag 26 september 2014 13:40:36 UTC+2 schreef Jeroen Demeyer:
On 2014-09-26 13:18, Peter Bruin wrote:
It is completely sensible for valuation(0)
to result in an error (or a useless infinity return value)
Raising an error and returning a useless infinity value are *very*
different
Op vrijdag 26 september 2014 13:58:06 UTC+2 schreef Travis Scrimshaw:
On 2014-09-26 11:46, Peter Bruin wrote:
Why write a new function for something
that doesn't seem to be _that_ widely useful, and can easily be
implemented in two lines (ispower() followed by ispseudoprime())?
To
On Friday, September 26, 2014 6:55:39 AM UTC-7, Dima Pasechnik wrote:
IMHO it would be great to have this in mpmath rather than a Sage
workaround.
(AFAIK, hypergeometric_U is vulnerable to the very same problem, so this
would mean the workaround would either be needed in several
On Sep 26, 2014, at 7:59 AM, Dima Pasechnik dimp...@gmail.com wrote:
From the noises I hear, in particular on our departamental email, sysadmins
might be tempted to rm -f /bin/bash
from any place they can get their hands on.
It might mean that for building/working with Sage one will need a
On Fri, Sep 26, 2014 at 7:06 AM, John Cremona john.crem...@gmail.com
javascript:; wrote:
On 26 September 2014 14:59, Dima Pasechnik dimp...@gmail.com
javascript:; wrote:
From the noises I hear, in particular on our departamental email,
sysadmins might be tempted to rm -f /bin/bash
from any
On 2014-09-26, Ivan Andrus darthand...@gmail.com wrote:
On Sep 26, 2014, at 7:59 AM, Dima Pasechnik dimp...@gmail.com wrote:
From the noises I hear, in particular on our departamental email, sysadmins
might be tempted to rm -f /bin/bash
from any place they can get their hands on.
It might
On 2014-09-26, William A Stein wst...@uw.edu wrote:
On Fri, Sep 26, 2014 at 7:06 AM, John Cremona john.crem...@gmail.com
javascript:; wrote:
On 26 September 2014 14:59, Dima Pasechnik dimp...@gmail.com
javascript:; wrote:
From the noises I hear, in particular on our departamental email,
On 2014-09-26 16:25, Peter Bruin wrote:
It would be a different
story if there were a significantly faster algorithm than to call
ispower() and ispseudoprime(), but that would first need to be demonstrated.
But why does that even matter? You agreed that the complexity of the
implementation is a
Le 26/09/2014 16:47, Jeroen Demeyer a écrit :
On 2014-09-26 16:25, Peter Bruin wrote:
It would be a different
story if there were a significantly faster algorithm than to call
ispower() and ispseudoprime(), but that would first need to be
demonstrated.
But why does that even matter? You
2. Dima -- do we specifically use bash features in the build scripts of
Sage?
Sage scripts have !/usr/bin/env bash all over the place.
I don't know about 'bashisms' though - one should test on a Debian system,
where bash is not essential, as they have a push to move to dash years
From the noises I hear, in particular on our departamental email,
sysadmins might be tempted to rm -f /bin/bash
from any place they can get their hands on.
It might mean that for building/working with Sage one will need a
separate install of bash.
(or we should switch to
On 2014-09-26 16:42, Julien Puydt wrote:
I don't think it's good to patch upstream and ship it as if it were
upstream.
What do you mean with ship it as if it were upstream? It's not like we
hide the fact that PARI is patched.
It would be better to add functionality to sage-over-pari instead
I just updated the ubuntu systems I administer and the problem went
away. Here is a diagnistic I found online:
jec@lmfdb:~$ x='() { :;}; echo VULNERABLE' bash -c :
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
I have a
On 2014-09-26, Jean-Pierre Flori jpfl...@gmail.com wrote:
2. Dima -- do we specifically use bash features in the build scripts of
Sage?
Sage scripts have !/usr/bin/env bash all over the place.
I don't know about 'bashisms' though - one should test on a Debian system,
where bash is
Hi,
On Fri, Sep 26, 2014 at 02:47:21PM +, Dima Pasechnik wrote:
Sage scripts have !/usr/bin/env bash all over the place.
I don't know about 'bashisms' though - one should test on a Debian system,
where bash is not essential, as they have a push to move to dash years already
on.
(and so
I am working on an optional package for the knot atlas. The idea is to
download the database of knots and links and be able to query it.
I have downloaded a +300MB .rdf file from the knot atlas web page. Juyst
parsing it takes a bit. Which would be the right format to store that
information in
On Fri, Sep 26, 2014 at 8:48 AM, mmarco mma...@unizar.es wrote:
I am working on an optional package for the knot atlas. The idea is to
download the database of knots and links and be able to query it.
I have downloaded a +300MB .rdf file from the knot atlas web page. Juyst
parsing it takes a
On 26 September 2014 16:55, William A Stein wst...@uw.edu wrote:
On Fri, Sep 26, 2014 at 8:48 AM, mmarco mma...@unizar.es wrote:
I am working on an optional package for the knot atlas. The idea is to
download the database of knots and links and be able to query it.
I have downloaded a +300MB
Hi,
Le 26/09/2014 17:04, Jeroen Demeyer a écrit :
On 2014-09-26 16:42, Julien Puydt wrote:
I don't think it's good to patch upstream and ship it as if it were
upstream.
What do you mean with ship it as if it were upstream? It's not like we
hide the fact that PARI is patched.
A good
Hello Travis,
That worked :). Thanks. I have made some edits that you have
suggested not all though, please have a look at them.
On Thu, Sep 25, 2014 at 3:31 AM, Travis Scrimshaw tsc...@ucdavis.edu
wrote:
Hey Amit,
From a quick look at the commit log, I think you've updated Sage,
Yes I do use a lot of integration so Maxima is heavily used. Even if that
was *all* I used.wouldn't it still be best
to use Sage instead of wxMaxima?
I would guess Sage is better supported plus it has all the rest of the
functionality should I ever need it.
Furthermore, I know Python
So i take it would require sqlite as a dependency? or is it already shipped
with sage by default?
--
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
Hi,
Le 26/09/2014 22:18, mmarco a écrit :
So i take it would require sqlite as a dependency? or is it already shipped
with sage by default?
It is shipped (quite recent), and with python bindings (sqlalchemy --
that one a little old).
Snark on #sagemath
--
You received this message because
Hi Julien,
On 2014-09-26, Julien Puydt julien.pu...@laposte.net wrote:
I don't think it's good to patch upstream and ship it as if it were
upstream.
At least in the spkgs I am aware of, Sage does *not* ship a patched
version of upstream. Instead, it ships the unmodified upstream sources
and
It is shipped (quite recent), and with python bindings (sqlalchemy --
that one a little old).
Also sqlalchemy is now an optional spkg IIRC.
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and
Hi,
Le 26/09/2014 22:22, Simon King a écrit :
Hi Julien,
On 2014-09-26, Julien Puydt julien.pu...@laposte.net wrote:
I don't think it's good to patch upstream and ship it as if it were
upstream.
At least in the spkgs I am aware of, Sage does *not* ship a patched
version of upstream.
On Friday, September 26, 2014, Julien Puydt julien.pu...@laposte.net
wrote:
Hi,
Le 26/09/2014 22:18, mmarco a écrit :
So i take it would require sqlite as a dependency? or is it already
shipped
with sage by default?
It is shipped (quite recent),
To clarify - we have included sqlite
On Friday, September 26, 2014 1:40:58 PM UTC-7, Snark wrote:
My point is that it's pretty bad for at least two reasons :
- for a long-term support perspective, that means more work following
upstream ;
- for a public relationship perspective with respect to upstream,
modifying things in
On Friday, September 26, 2014 10:56:11 AM UTC-7, Chris Seberino wrote:
Yes I do use a lot of integration so Maxima is heavily used. Even if that
was *all* I used.wouldn't it still be best
to use Sage instead of wxMaxima?
I suppose if you like the front end, and you don't mind the
56 matches
Mail list logo
