Just to clarify, i wasn't thinking on sage sending a query to findstat, but
performing the search locally (i.e. having findstat software included in
Sage).
I don't know how findstat is implemented, so i don't know how wise that
aproach would be. Does findstat relly on a big database that is
Thanks for the thoughtful replies. It's a fine line between being critical
of the idea and dismissive of the students. Please everyone limit
yourselves to criticizing the idea, as students might come to this thread
later.
I don't think one should dismiss the students. Look at the Mathworks
Does findstat relly on a big database that is enhanced with the new queries?
Or does it compute every query from scratch?
I start with answering here since this the crucial point.
We want to use Sage in FindStat only in the background, a user
interacting with FindStat (by searching for
On Thu, May 29, 2014 at 11:42:40AM +0200, Nicolas M. Thiery wrote:
Here is the description of http://trac.sagemath.org/ticket/16410,
which potentially needs review:
--
From the discussions of (TODO: add refs to the
Yoo !!
Nathann, Christian, Viviane, ... do you mind briefly stating on the
ticket whether this sounds like a reasonable step forward?
Well... I don't have much to add there I think... Besides, for
political reasons, you will understand that I cannot review this
ticket :-P
For me what
BUT: this would result in code in Sage that is not useful purely
within Sage. And there are people, loud people, that say there should
not be such code in Sage.
I can hear your frustration ... In similar situations, it helped me to
keep in mind that loud people are not always
I might be too, I am not quite sure!
Paul
Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye
On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen
I might be too, I am not quite sure!
If so, I would be ashamed to steal the spotlights. The place is yours.
Nathann
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To unsubscribe from this group and stop receiving emails from it, send
On 29 May 2014 21:02, Nathann Cohen nathann.co...@gmail.com wrote:
BUT: this would result in code in Sage that is not useful purely
within Sage. And there are people, loud people, that say there should
not be such code in Sage.
I do not know what is code in Sage that is not useful purely
+1 for subtlety!
Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye
On Thu, May 29, 2014 at 10:15 PM, Nathann Cohen
On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen nathann.co...@gmail.com
I can hear your frustration ... In similar situations, it helped me to
keep in mind that loud people are not always representative. Of course
the difficulty is to fetch the opinion from the others.
To add on to what Viviane just said, the problem is also in using
vocabulary and words such as our side (a constant in Nathann's prose) or
I don't even know what I think anymore. With the turn that events take, I
think I don't even need to think anymore. I think that I will think what
you think I
E.g. when a
borderline feature is meaningful in the context of Sage, is useful
for a sister project, but does not yet have a direct use case
within Sage ...
Correct me if I am wrong, off the top of my head:
Assuming the findstat people start adding information about which maps
are
Yo !
I don't even know what I think anymore. With the turn that events take, I
think I don't even need to think anymore. I think that I will think what
you
think I think, it is much easier for me.
which is a very open minded attitude
and a jest, as I am sure you understood. I was
Hi Travis,
I agree with you and I think it was already suggested by Simon that
the maps should not be built on startup. On the other hand, the maps
that we want to register might not all come from a method.
I created ticket #16408 and drafted a working implementation in
Hi Simon,
On Wed, May 28, 2014 at 03:36:09PM +, Simon King wrote:
Are you sure that this is a problem? In order to construct ZZ, we need
CommutativeAdditiveGroups()---which is already there. Now, someone does
Modules(ZZ)---and of course we can make it so that it returns
Thanks for these clear explanations.
The case of IPython tab mechanism for getting documentation is very
convincing!
Coming from the C++ world, I was used to have the attributes private, but
was not sure about the Python way of dealing with this (having read
different opinions about it). I did
Just to clarify, i wasn't thinking on sage sending a query to findstat, but
performing the search locally (i.e. having findstat software included in
Sage).
I don't know how findstat is implemented, so i don't know how wise that
aproach would be. Does findstat relly on a big database that is
Thanks for the thoughtful replies. It's a fine line between being critical
of the idea and dismissive of the students. Please everyone limit
yourselves to criticizing the idea, as students might come to this thread
later.
I don't think one should dismiss the students. Look at the Mathworks
Hi William,
On 2014-05-28, William Stein wst...@gmail.com wrote:
With properties, guess what happens? Suppose f.something is a
property that's an immutable number, e.g., the determinant of a
matrix.
sage: a = matrix(...)
sage: a.det?
docstring about integer!
That's not true, if det
On Thu, May 29, 2014 at 10:14:20AM +0200, Vincent Delecroix wrote:
I agree with you and I think it was already suggested by Simon that
the maps should not be built on startup. On the other hand, the maps
that we want to register might not all come from a method.
I created ticket #16408 and
Does findstat relly on a big database that is enhanced with the new queries?
Or does it compute every query from scratch?
I start with answering here since this the crucial point.
We want to use Sage in FindStat only in the background, a user
interacting with FindStat (by searching for
If its really because you are running out of memory then the OOM killer
will send a SIGTERM, do you see that in strace?
The doc builder respects the usual SAGE_NUM_THREADS environment variable.
On Wednesday, May 28, 2014 11:27:41 PM UTC+1, Dima Pasechnik wrote:
On 2014-05-28, Dima Pasechnik
On Thursday, May 29, 2014 12:03:54 AM UTC+1, William wrote:
Another issue is that frequently in math we have algorithms/options to
functions, e.g.,
sage: a.det(algorithm=padic)
And even if there is no argument I would prefer a.det() over a.det to make
it clear that this is invoking a
OK, great, thanks for clarifying!
Am Mittwoch, 28. Mai 2014 20:53:36 UTC+2 schrieb Simon King:
Hi Martin,
On 2014-05-28, 'Martin R' via sage-combinat-devel
sage-comb...@googlegroups.com javascript: wrote:
E.g., it should know domain and codomain, and it should know
what category it
E.g., it should know domain and codomain, and it should know
what category it belongs to. I think it makes sense to let a morphism
know whether it is injective or surjective. However, additional
information that is certainly interesting to researchers (e.g.: Was first
defined by John
On 29 May 2014 09:40, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote:
Hi Simon,
On Wed, May 28, 2014 at 03:36:09PM +, Simon King wrote:
Are you sure that this is a problem? In order to construct ZZ, we need
CommutativeAdditiveGroups()---which is already there. Now, someone does
Hi,
On Thu, May 29, 2014 at 12:29:45PM +0200, Christian Stump wrote:
We want to use Sage in FindStat only in the background, a user
interacting with FindStat (by searching for statistics, or by
contributing statistics) should not see what's happening in the
background.
As a developper and
On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote:
If its really because you are running out of memory then the OOM killer
will send a SIGTERM, do you see that in strace?
I have this on OSX, which I guess doesn't have an OOM killer;
anyway, no, the processes just hang, and no,
nothing
On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote:
If its really because you are running out of memory then the OOM killer
will send a SIGTERM, do you see that in strace?
The doc builder respects the usual SAGE_NUM_THREADS environment variable.
Really? With
$ SAGE_NUM_THREADS=1 make
On Thursday, May 29, 2014 1:09:51 AM UTC+2, William wrote:
* Wolfram Inc. ...
Mathematica available for free on Raspberry Pi
http://www.wolfram.com/raspberry-pi/
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this
On Thu, May 29, 2014 at 12:29:45PM +0200, Christian Stump wrote:
BUT: this would result in code in Sage that is not useful purely
within Sage. And there are people, loud people, that say there should
not be such code in Sage.
I can hear your frustration ... In similar situations, it helped me
On Thu, May 29, 2014 at 11:42:40AM +0200, Nicolas M. Thiery wrote:
Here is the description of http://trac.sagemath.org/ticket/16410,
which potentially needs review:
--
From the discussions of (TODO: add refs to the
Paul-Olivier,
Thank you for your very thoughtful comments in several different threads.
Naturally there is no one response to all of them - indeed, it touches on
things that researchers of open-source development and motivation (not the
developers themselves) have been filling reams of
Hi! Thanks again for your thoughtful comments. I see two different issues
arising in this thread.
1) Your desire to have a MOOC teaching Python programming around some
mathematics, which might end up contributing to Sage. (Or sympy, or numpy,
or Gambit, or ...) That sounds awesome.
I
On Thu, May 29, 2014 at 7:54 AM, kcrisman kcris...@gmail.com wrote:
That said, I think you are referring to software contributions themselves,
and here we come upon something William already stumbled on when he started
psage (though I haven't checked in on that project in a while). A maturing
On Thu, May 29, 2014 at 8:49 AM, kcrisman kcris...@gmail.com wrote:
Hi! Thanks again for your thoughtful comments. I see two different issues
arising in this thread.
1) Your desire to have a MOOC teaching Python programming around some
mathematics, which might end up contributing to Sage.
Yoo !!
Nathann, Christian, Viviane, ... do you mind briefly stating on the
ticket whether this sounds like a reasonable step forward?
Well... I don't have much to add there I think... Besides, for
political reasons, you will understand that I cannot review this
ticket :-P
For me what
Please excuse the following rant. As usual, it is ill-informed, and if
some of the points are due to ignorance, I have no problem with that being
pointed out. But from reading the lists, I'm not the only one experiencing
difficulty with this sort of thing. At the very least I think it shows
On Thu, May 29, 2014 at 1:58 AM, Eric Gourgoulhon
egourgoul...@gmail.com wrote:
Thanks for these clear explanations.
The case of IPython tab mechanism for getting documentation is very
convincing!
Coming from the C++ world, I was used to have the attributes private, but
was not sure about
Update: My conclusion from psage is that it's very important to have
easy ways to share in-development code. Using trac (e.g., git
branches) is also fine for that. Psage is pointless (or more like the
famous combinat queue back then). I didn't stumble upon anything
with psage.
On Thu, May 29, 2014 at 2:41 AM, Simon King simon.k...@uni-jena.de wrote:
Hi William,
On 2014-05-28, William Stein wst...@gmail.com wrote:
With properties, guess what happens? Suppose f.something is a
property that's an immutable number, e.g., the determinant of a
matrix.
sage: a =
I never really have had a problem with the new workflow (in fact, I
actually prefer it to the old one). However I had a good command of git
coming into this and read the git the hard way. So my 2 cents would be to
have developers spend time learning git properly instead of using the dev
On Thu, May 29, 2014 at 10:01 AM, kcrisman kcris...@gmail.com wrote:
Please excuse the following rant. As usual, it is ill-informed, and if some
I appreciate it, and I'm glad we're having this discussion. (It's a
rant, but it isn't a flame. Yeah!)
of the points are due to ignorance, I have
On Thursday, May 29, 2014 6:01:24 PM UTC+1, kcrisman wrote:
As another example, in attempting to review one patch which relies upon
the new Maxima update
The git branch contains the entire code, so automatically has all
requirements. You don't need to know where the maxima update comes from
On Thu, May 29, 2014 at 10:49 AM, Volker Braun vbraun.n...@gmail.com wrote:
On Thursday, May 29, 2014 6:01:24 PM UTC+1, kcrisman wrote:
As another example, in attempting to review one patch which relies upon
the new Maxima update
The git branch contains the entire code, so automatically has
On Thursday, May 29, 2014 7:00:52 PM UTC+1, William wrote:
The argument that mailing patches doesn't work at that scale isn't
convincing, since Linux kernel development is much bigger than Sage
development, and they mail patches around
That is not really true. They do mail patches around,
Hi Volker,
On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote:
: where that is, one cannot learn easily from git log, since
$ git log | grep maxima | less
$ git log | grep Maxima | less
The git log is not a plain text file, its a directed acyclic graph. There
is much more useful
On Thursday, May 29, 2014 7:26:35 PM UTC+1, Simon King wrote:
Before switching to git, we had the policy (enforced by commit hooks, if
I recall correctly) that the commit message mentions the ticket number.
No, that was Jeroen manually (ok, with a script) telling you
days/weeks/months later
Thanks for the advice.
I've just finished the changes, setting all attribute names to single
underscore (2280 substitutions, thank you sed !).
Best wishes,
Eric.
Le jeudi 29 mai 2014 19:07:04 UTC+2, William a écrit :
Please try to use a single underscore, e.g., self._tensor, instead of
Hi Volker,
On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote:
code: How can I easily find that discussion?
Pretty easy, I would say: git trac find sha1.
Wow! That is in fact very useful. Didn't know about this. So far, I was
mainly using the dev scripts, and git trac only once, I
On 29 May 2014 20:22, Simon King simon.k...@uni-jena.de wrote:
Hi Volker,
On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote:
code: How can I easily find that discussion?
Pretty easy, I would say: git trac find sha1.
Wow! That is in fact very useful. Didn't know about this. So far, I
On 2014-05-29, John Cremona john.crem...@gmail.com wrote:
On 29 May 2014 20:22, Simon King simon.k...@uni-jena.de wrote:
Hi Volker,
On 2014-05-29, Volker Braun vbraun.n...@gmail.com wrote:
code: How can I easily find that discussion?
Pretty easy, I would say: git trac find sha1.
Wow!
On Thursday, May 29, 2014 8:29:04 PM UTC+1, John Cremona wrote:
Can someone point me to instructions for how to install (and use) git
trac?
The developer guide on a sufficiently recent (6.2+) Sage version.
On a related note, the docs on the web page are still from 6.1.1
--
You received
On 29 May 2014 20:50, Volker Braun vbraun.n...@gmail.com wrote:
On Thursday, May 29, 2014 8:29:04 PM UTC+1, John Cremona wrote:
Can someone point me to instructions for how to install (and use) git
trac?
The developer guide on a sufficiently recent (6.2+) Sage version.
On a related note,
BUT: this would result in code in Sage that is not useful purely
within Sage. And there are people, loud people, that say there should
not be such code in Sage.
I can hear your frustration ... In similar situations, it helped me to
keep in mind that loud people are not always
I might be too, I am not quite sure!
Paul
Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye
On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen
I might be too, I am not quite sure!
If so, I would be ashamed to steal the spotlights. The place is yours.
Nathann
--
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
On 29 May 2014 21:02, Nathann Cohen nathann.co...@gmail.com wrote:
BUT: this would result in code in Sage that is not useful purely
within Sage. And there are people, loud people, that say there should
not be such code in Sage.
I do not know what is code in Sage that is not useful purely
+1 for subtlety!
Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye
On Thu, May 29, 2014 at 10:15 PM, Nathann Cohen
Volker Braun wrote:
The doc builder respects the usual SAGE_NUM_THREADS environment variable.
Well, nevertheless, AFAIK it uses Python's multiprocessing even with
SAGE_NUM_THREADS=1, just like 'sage -b' does.
I've been considering the latter a bug for years, but others apparently
didn't
I actually do think it would be a really good thing to have a statfinder
within sage, and somehow merge findstat code with sage code. It would
benefit both sage and findstat users. At the end, both FindStat and Sage
have the same aim: using computers to help us doing research. I understand
On Thursday, May 29, 2014 9:45:52 PM UTC+1, leif wrote:
Well, nevertheless, AFAIK it uses Python's multiprocessing even with
SAGE_NUM_THREADS=1, just like 'sage -b' does.
Whats wrong with that? You want an extra untested codepath to handle that
special value?
--
You received this message
Robert Bradshaw wrote:
[...] now that we're on git a pull request is 99% of what a ticket is
I'm happy that this (still) is *not* the case (for most tickets at least).
(specifically, an annotated point to a particular git branch/commit
that needs review) and we should seriously consider
On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen nathann.co...@gmail.com
I can hear your frustration ... In similar situations, it helped me to
keep in mind that loud people are not always representative. Of course
the difficulty is to fetch the opinion from the others.
To add on to what Viviane just said, the problem is also in using
vocabulary and words such as our side (a constant in Nathann's prose) or
I don't even know what I think anymore. With the turn that events take, I
think I don't even need to think anymore. I think that I will think what
you think I
On Wed, May 28, 2014 at 04:03:11PM -0700, William Stein wrote:
When properties were added to Python, and Sage got them, I was not
convinced and didn't want to switch all the code to them. Why?
...
Thanks William for this synthetic answer on that matter. We should
definitely add this to the
E.g. when a
borderline feature is meaningful in the context of Sage, is useful
for a sister project, but does not yet have a direct use case
within Sage ...
Correct me if I am wrong, off the top of my head:
Assuming the findstat people start adding information about which maps
are
On Wed, May 28, 2014 at 09:57:43AM +, Simon King wrote:
Personally, I would not hesitate to use these existing base classes
(sage.rings.ring.Ring for example) for things that are guaranteed to be
rings. Of course, if the actual algebraic structure depends on
parameters, then one must use a
Yo !
I don't even know what I think anymore. With the turn that events take, I
think I don't even need to think anymore. I think that I will think what
you
think I think, it is much easier for me.
which is a very open minded attitude
and a jest, as I am sure you understood. I was
There is definitely frustration on both sides. My offer for you to come
and talk in Zurich is serious, it's easier to talk in person. We could even
invite you to a seminar to talk about mathematics. Then we go chill out
somewhere and we talk about sage.
Paul
Paul-Olivier Dehaye
SNF Assistant
Volker Braun wrote:
On Thursday, May 29, 2014 9:45:52 PM UTC+1, leif wrote:
Well, nevertheless, AFAIK it uses Python's multiprocessing even with
SAGE_NUM_THREADS=1, just like 'sage -b' does.
Whats wrong with that?
As Dima pointed out, it doesn't only (needlessly) require specific
On Thu, May 29, 2014 at 2:22 PM, leif not.rea...@online.de wrote:
kcrisman wrote:
rant
Git workflow.
The goal was to reduce work for some developers and make things more
modular, but in fact what happens is that people are basing their
branches on all kinds of different starting points,
On Thu, May 29, 2014 at 10:37 AM, William Stein wst...@gmail.com wrote:
On Thu, May 29, 2014 at 10:01 AM, kcrisman kcris...@gmail.com wrote:
Please excuse the following rant. As usual, it is ill-informed, and if some
I appreciate it, and I'm glad we're having this discussion. (It's a
rant,
On Thu, May 29, 2014 at 10:29 AM, Travis Scrimshaw tsc...@ucdavis.edu wrote:
I never really have had a problem with the new workflow (in fact, I
actually prefer it to the old one). However I had a good command of git
coming into this and read the git the hard way. So my 2 cents would be to
I am having great trouble getting sage to build on FreeBSD version 10
and above. I was finally able to fix the problem by switching out the
python-2.7.5 source code that comes with sage with python-2.7.6 source
code. Amazingly this fixed a lot of the problems.
So, is there any interest in
Well, I am thankful that my rant led to some pretty substantive discussion.
Here let me summarize some thoughts.
A) +1 to having something where a github-like editing thing works. I've
used this at least once with matplotlib. My beef with github is orthogonal
to the web interface piece. If
Hey Stephen,
This is http://trac.sagemath.org/ticket/16260 which is waiting for
review.
Best,
Travis
On Thursday, May 29, 2014 6:43:44 PM UTC-7, Stephen Montgomery-Smith wrote:
I am having great trouble getting sage to build on FreeBSD version 10
and above. I was finally able to fix
Beat me to it. I completely missed that Jean-Pierre had added his new cygwin
patch. Review should be trivial.
Francois
On Thu, 29 May 2014 18:51:15 Travis Scrimshaw wrote:
Hey Stephen,
This is http://trac.sagemath.org/ticket/16260 which is waiting for
review.
Best,
Travis
On
There is definitely frustration on both sides. My offer for you to come
and talk in Zurich is serious, it's easier to talk in person. We could even
invite you to a seminar to talk about mathematics. Then we go chill out
somewhere and we talk about sage.
An excellent idea for all such
1. This is great. Thank you. I hope it gets included in sage-6.3.
2. I erroneously said that I had to remove package-version.txt. But it
was actually the uuid patch I had to remove. But I see from the trac
ticket that you guys are already on top of this.
On 05/29/2014 08:51 PM, Travis
In my opinion,the packages of matlab are more important than matlab itself.
So I wonder if there is any packages of sage,like an implement of some
simulation models.
And if I want to write some packages of sage,waht format should I use,
*.sage or *.py?
BTW:If there some cool cases that solve
In my opinion,the packages of matlab are more important than matlab itself.
So I wonder if there is any packages of sage,like an implement of some
simulation models.
And if I want to write some packages of sage,waht format should I use,
*.sage or *.py?
BTW:If there some cool cases that solve
But there is a real technical disagreement here too.
There is no such thing. One of Paul-Olivier's last posts was about how he
thought we agreed 100% together and wanted me to say it. It is part of our
couple therapy.
https://groups.google.com/d/msg/sage-combinat-devel/QRUXmy6UZVo/hfPQfkVzT8MJ
84 matches
Mail list logo
