Hi,
Not because of Composition but because of sum
sage: import __builtin__
sage: __builtin__.sum(Composition([1,2,3]))
6
Vincent
2014-05-19 16:26 UTC+02:00, Nathann Cohen nathann.co...@gmail.com:
Hello everybody !
Today I come with this :
sage: sum(Composition([1,2,3]))
...
TypeError:
Hello everybody !
Today I come with this :
sage: sum(Composition([1,2,3]))
...
TypeError: sum() takes exactly 1 argument (0 given)
Some code of mine which uses Composition expected to see 3+2+1=6 there, but
all I got was an exception.
Looks like you are not allowed to change the meaning of
On Mon, May 19, 2014 at 04:29:44PM +0200, Vincent Delecroix wrote:
Not because of Composition but because of sum
sage: import __builtin__
sage: __builtin__.sum(Composition([1,2,3]))
6
That being said, since Composition seems to be the single
combinatorial object having a sum method, we
Hi Nicolas,
On 2014-05-19, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote:
That being said, since Composition seems to be the single
combinatorial object having a sum method, we could think of renaming
it to something more appropriate that would not conflict with Sage's
sum syntax and
Hi,
See also http://trac.sagemath.org/ticket/15163 .
Best regards,
Darij
On Mon, May 19, 2014 at 12:01 PM, Simon King simon.k...@uni-jena.de wrote:
Hi Nicolas,
On 2014-05-19, Nicolas M. Thiery nicolas.thi...@u-psud.fr wrote:
That being said, since Composition seems to be the single
On Mon, May 19, 2014 at 04:01:52PM +, Simon King wrote:
Multiplication? I always think of words as elements of a free group, of
course multiplicatively written. Hence, concatenation of words w1,...,wn
would be prod([w1,w2,...,wn]).
Indeed.
`+` works too for concatenation of words, which
I'm not sure what all of the fuss is about: in papers is it common practise
to acknowledge funding sources. Indeed this is often required. If a
substantial piece of code is one of the funding outcomes shouldn't this be
acknowledged?
For me Sage is a collaborative software, not the
Hello,
can you please tell me if it's expected that setup.py installs C headers of
numpy
into the python tree associated with the current running python instead
of something under $SAGE_LOCAL/, e.g. include?
If yes then this leads to failure to include numpy C headers when compiling
in unsafe
On Monday, May 19, 2014 2:51:23 AM UTC+1, Andrew wrote:
I would have thought that the correct way to do this would be by adding
a brief sentence to the
AUTHORS: block
and the top of the file.
IMHO that is just the programming equivalent to spray-painting your name on
transformer boxes.
How does one extract record components from GAP records obtained from
libGAP?
E.g.
sage: libgap.InvariantQuadraticForm(libgap.GeneralOrthogonalGroup(1,4,9))
rec( matrix := [ [ 0*Z(3), Z(3)^0, 0*Z(3), 0*Z(3) ], [ 0*Z(3), 0*Z(3),
0*Z(3), 0*Z(3) ], [ 0*Z(3), 0*Z(3), Z(3)^0, 0*Z(3) ], [ 0*Z(3),
On 2014-05-19, Nathann Cohen nathann.co...@gmail.com wrote:
I'm not sure what all of the fuss is about: in papers is it common practise
to acknowledge funding sources. Indeed this is often required. If a
substantial piece of code is one of the funding outcomes shouldn't this be
Libgap records behave like Python dicts:
sage: Q =
libgap.InvariantQuadraticForm(libgap.GeneralOrthogonalGroup(1,4,9)); Q
rec( matrix := [ [ 0*Z(3), Z(3)^0, 0*Z(3), 0*Z(3) ], [ 0*Z(3), 0*Z(3),
0*Z(3), 0*Z(3) ], [ 0*Z(3), 0*Z(3), Z(3)^0, 0*Z(3) ], [ 0*Z(3), 0*Z(3),
0*Z(3), Z(3)^0 ] ] )
sage:
well, rules are rules. If certain Ritchy Bastrad would donate 10M$ to
Sage project, under the condition it be renamed Ritchy Bastard
Sage, then, you know...
Not many people here enjoy next to zero obligations liftime funding,
like CNRS offers you, Nathann :)
Ahahahah.
Well, refusing to get
On 2014-05-19, Volker Braun vbraun.n...@gmail.com wrote:
Libgap records behave like Python dicts:
great, thanks!
I should RTFM more often...
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group and stop receiving emails
Since my review request for the urgent bugfix for this:
sage: RLF(0) oo
False
has been hijacked by an open-ended discussion about and whether grants
ought to be acknowledged in the source tree, I'd like to break out that
discussion into a separate thread.
Questions:
* Should sources
Hi,
this is the expected behaviour. At compilation time you should have extra
CPPFLAGS
pointing to the right folder. Can you provide detail of the failed compilation?
Francois
On 19/05/2014, at 20:36, Ralf Stephan gtrw...@gmail.com wrote:
Hello,
can you please tell me if it's expected that
It's the first compile that includes numpy headers, i.e. the header
numpy/ndarrayobject.h. The output is
gcc -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC
-I/tmp/tmpr
P11xO-sage-git-temp-15178/local/lib/python/site-packages/numpy/core/include
-I/
Volker Braun wrote:
On Monday, May 19, 2014 2:51:23 AM UTC+1, Andrew wrote:
I would have thought that the correct way to do this would be by
adding a brief sentence to the
AUTHORS: block
and the top of the file.
IMHO that is just the programming equivalent to spray-painting
Grant ack must happen, but on the sagemath.org website (only) as we've been
doing it for years now. I think that model works well. If anybody wants
to add something, email me or Harald.
On May 19, 2014 4:20 AM, leif not.rea...@online.de wrote:
Volker Braun wrote:
On Monday, May 19, 2014
On May 19, 2014 2:52 AM, Volker Braun vbraun.n...@gmail.com wrote:
Since my review request for the urgent bugfix for this:
sage: RLF(0) oo
False
has been hijacked by an open-ended discussion about and whether grants
ought to be acknowledged in the source tree, I'd like to break out
I definitely am against the acknowledgements in the source code. It could
be necessary to have some way of acknowledgement (at the end, we would like
the community to consider that writing code for sage is not a minor task
compared to publishing papers), but that should be somewhere else. I
On Monday, May 19, 2014 12:22:01 PM UTC+2, François wrote:
This is quite ugly. I notice an unhealthy mix. You’ll notice:
-I/tmp/tmprP11xO-sage-git-temp-15178/local/lib/python/site-packages/numpy/core/include
which should enable you to find the header, but were does
Maybe this question is clearer: in an install that is started from
directory A/sage by cloning into B and 'make', do you expect the python
SPKG to be installed into A/B and which instance of python should then
run 'setup.py' when installing numpy?
--
You received this message because you are
What about doing tail `grep -i 'error\|fail' logfile` after a crash
automatically?
On Sunday, May 18, 2014 5:34:04 PM UTC+2, leif wrote:
It may happen that you get (just)
The following package(s) may have failed to build:
The build directory may contain configuration files and other
Not sure if I understand, but git clone /path/to/A B would create B as a
completely independent source tree.
On Monday, May 19, 2014 3:05:35 PM UTC+1, Ralf Stephan wrote:
Maybe this question is clearer: in an install that is started from
directory A/sage by cloning into B and 'make', do you
On Mon, May 19, 2014 at 4:25 PM, Volker Braun vbraun.n...@gmail.com wrote:
Not sure if I understand, but git clone /path/to/A B would create B as a
completely independent source tree.
...which installs back python and its packages into A. And for me as python
newb this
doesn't look right.
I *think* what happens is that 'make' gets called as subprocess from
patchbot (the A python),
and the call inside spkg-install (of B spkgs) somehow gets it wrong and
installs the packages
into A. logs can be found at
https://github.com/robertwb/sage-patchbot/issues/35
On Mon, May 19, 2014 at
That makes more sense, if you call from within A's sage-env the makefile of
B then you'll have a bunch of environment variables set pointing to A.
On Monday, May 19, 2014 3:40:01 PM UTC+1, Ralf Stephan wrote:
I *think* what happens is that 'make' gets called as subprocess from
patchbot (the
Is there a way to get the original env *before A/sage clobbers it? Maybe
it's backupped
somewhere? Would that help?
On Mon, May 19, 2014 at 4:42 PM, Volker Braun vbraun.n...@gmail.com wrote:
That makes more sense, if you call from within A's sage-env the makefile
of B then you'll have a bunch
Please review:
http://trac.sagemath.org/ticket/16377
On Mon, May 19, 2014 at 5:05 PM, Ralf Stephan gtrw...@gmail.com wrote:
Is there a way to get the original env *before A/sage clobbers it? Maybe
it's backupped
somewhere? Would that help?
On Mon, May 19, 2014 at 4:42 PM, Volker Braun
Ralf Stephan wrote:
What about doing tail `grep -i 'error\|fail' logfile` after a crash
automatically?
? Well, that's what we currently do (on a per-package logfile basis),
and this meanwhile works for almost all packages (apparently even ATLAS
;-) ), but AFAICS currently e.g. not for
Ralf Stephan wrote:
Is there a way to get the original env *before A/sage clobbers it? Maybe
it's backupped
somewhere? Would that help?
man exec() / execve() ? ;-)
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to
man exec() / execve() ? ;-)
That's C but when we get to python's os.environ its already too late.
--
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
On Sat, May 17, 2014 at 2:27 PM, leif not.rea...@online.de wrote:
R. Andrew Ohana wrote:
Well it is a bit different than other changes, since nothing actually
changes in the ticket itself (which would prompt a notification). Rather
the plugin is just a special render for the branch field, so
34 matches
Mail list logo
