>
> If I understand your complaint correctly, the problem is that
> re-compiling after switching branches is too expensive.
>
You *NEVER* need to recompile everything when switching branches. There is
a trick : you should never checkout a branch but instead pull it (merge it)
with your curren
> 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
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 probl
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 pro
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 Scri
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
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
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
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
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 having
On Thu, May 29, 2014 at 10:29 AM, Travis Scrimshaw 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
> have develope
On Thu, May 29, 2014 at 10:37 AM, William Stein wrote:
> On Thu, May 29, 2014 at 10:01 AM, kcrisman 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!)
On Thu, May 29, 2014 at 2:22 PM, leif wrote:
> kcrisman wrote:
>>
>>
>> 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, forcing co
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
re
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 Pro
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 understoo
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 us
"""
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
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
kcrisman wrote:
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, forcing constant
recompilation for even the most trivial changes. [...]
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 thi
> On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen
> > 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.
>
> Ahahahahahahah. Well, only
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 accep
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 mess
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
complete
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 car
+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 wrote:
> > I might be too
On 29 May 2014 21:02, Nathann Cohen 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 within Sage".
J
> 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
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 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 to
> keep in mind that loud people are not alwa
On 29 May 2014 20:50, Volker Braun 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, the docs
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 rece
On 2014-05-29, John Cremona wrote:
> On 29 May 2014 20:22, Simon King wrote:
>> Hi Volker,
>>
>> On 2014-05-29, Volker Braun wrote:
>>> code: How can I easily find that discussion?
>>>
>>> Pretty easy, I would say: "git trac find ".
>>
>> Wow! That is in fact very useful. Didn't know about
On 29 May 2014 20:22, Simon King wrote:
> Hi Volker,
>
> On 2014-05-29, Volker Braun wrote:
>> code: How can I easily find that discussion?
>>>
>>
>> Pretty easy, I would say: "git trac find ".
>
> Wow! That is in fact very useful. Didn't know about this. So far, I was
> mainly using the dev scri
Hi Volker,
On 2014-05-29, Volker Braun wrote:
> code: How can I easily find that discussion?
>>
>
> Pretty easy, I would say: "git trac find ".
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 think.
Cheers,
Simon
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
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 lat
Hi Volker,
On 2014-05-29, Volker Braun 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 information in
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 aro
On Thu, May 29, 2014 at 10:49 AM, Volker Braun 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 all
> requi
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 fr
On Thu, May 29, 2014 at 10:01 AM, kcrisman 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 no problem with th
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
sc
On Thu, May 29, 2014 at 2:41 AM, Simon King wrote:
> Hi William,
>
> On 2014-05-28, William Stein 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?
>
>
> 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 1:58 AM, Eric Gourgoulhon
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 the Python way of d
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
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
On Thu, May 29, 2014 at 8:49 AM, kcrisman 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. (Or sympy, or
On Thu, May 29, 2014 at 7:54 AM, kcrisman 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
> project necess
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 thi
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 (vir
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 t
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 m
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 2014-05-29, Volker Braun 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
I still get *two*
On 2014-05-29, Volker Braun 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 gets killed.
OSX shoul
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 an
On 29 May 2014 09:40, Nicolas M. Thiery 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
>> Modules(ZZ)---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 > 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 J
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 invoki
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
> 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 stati
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 a
Hi William,
On 2014-05-28, William Stein 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 is a proper
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
competit
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 enh
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
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
> Commuta
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
u/vdelecroix/experimental-
72 matches
Mail list logo
