Yoo !!
disclaimer
My answer is most likely going to be a bit broad and include stuff you
already know; I am just taking the occasion to write a blurb that
could possibly end up somewhere in the documentation (typically as a
complement of cartesian_product?), if someone finds it
Hi Nathann,
This is one very special case where the Parent/Element relation is
broken. First of all FiniteEnumeratedSet is not the parent of its
elements (it is a facade):
sage: F = FiniteEnumeratedSet([1, Partition([2,1]), Permutation([3,2,1])])
sage: F
{1, [2, 1], [3, 2, 1]}
sage:
On Wednesday, 30 April 2014 16:12:33 UTC+10, Nathann Cohen wrote:
There is also the problem of these __add__ and _add_. From just looking at
the names you have no idea what the difference is, except if you wrote the
code yourself.
Now, in the graph classes we have function like
This is one very special case where the Parent/Element relation is
broken. First of all FiniteEnumeratedSet is not the parent of its
elements (it is a facade):
Well, then I am asking whether it is a good idea / should be allowed.
We already have a tool to store list of elements without
On 04/30/2014 10:38 AM, Andrew wrote:
On Wednesday, 30 April 2014 16:12:33 UTC+10, Nathann Cohen wrote:
There is also the problem of these __add__ and _add_. From just
looking at the names you have no idea what the difference is, except
if you wrote the code yourself.
Now, in
Yo !
The Sage developer's guide contains the following (yes, it is somewhat
hidden):
http://sagemath.org/doc/developer/coding_in_python.html#special-sage-functions
I am sure that opening a ticket on trac to improve the docs is welcomed, for
example adding the links [1] and [2] in that
On Wed, Apr 30, 2014 at 08:12:33AM +0200, Nathann Cohen wrote:
Well, if you find the question justified, of course the answer should be
in the doc.
My point was not about the existence of the answer, but the way I
wrote it :-) Was it helpful?
There is also the problem of these
On Wed, Apr 30, 2014 at 09:23:41AM +0200, Vincent Delecroix wrote:
FiniteEnumeratedSet is aimed to not modify the input it gets. So if
you feed it with Python objects which are not elements it will not
complain and you have to go with that.
Yup. We would want to properly support facade
On Wed, Apr 30, 2014 at 12:22:41PM +0200, Nathann Cohen wrote:
Okay... Then would it make sense to make things like
FiniteEnumeratedSet behave as if they were real parents, for
instance by implementing the __call__ function manually (or let it be
inherited from Facade or whatever it is) so
On Wed, Apr 30, 2014 at 12:19:41PM +0200, Nathann Cohen wrote:
Not my job.
Nor mine in the case of coercion and the _..._ methods :-) Because I
already spent a lot of time on some pieces of the Sage infrastructure
does not mean I (or anybody on sage-combinat-devel) am responsible for
all of
Well, of course one needs to learn the language and its *context* if one
wants to program something.
Yes, but we want to make the language easy to work with, and easy to learn.
_add_coerced_elements_ (if it makes any sense, I do not really know what
its ideal name should be) is clearly more
Nor mine in the case of coercion and the _..._ methods :-) Because I
already spent a lot of time on some pieces of the Sage infrastructure
does not mean I (or anybody on sage-combinat-devel) am responsible for
all of it. Which is why I suggested to report and make your case on
sage-devel.
I
I think that the rule of thumb (if you want to implement a magical
python method __bla__ in Sage, then you should check whether a default
implementation exists, in which case you usually have to implement
_bla_, and the documentation of the default __bla__ gives you more
details what you can
Nathann Cohen wrote:
Well, of course one needs to learn the language and its *context* if one
wants to program something.
Yes, but we want to make the language easy to work with, and easy to
learn. _add_coerced_elements_ (if it makes any sense, I do not really
know what its ideal name
And we shouldn't make (especially *private*) function names too verbose
strikejust for newbies/strike, not just because they'd get more tedious
to type, but also because code would get *harder* to read because of its
length (or width).
1) I have been developping in Python/Sage for the last
Nathann Cohen wrote:
And we shouldn't make (especially *private*) function names too verbose strikejust
for newbies/strike, not just because they'd get more tedious to type, but also
because code would get *harder* to read because of its length (or width).
1) I have been developping in
No offense at all.
Oh, none taken at all ! I just wanted to emphasize that working for a
long time with Python and with Sage did not necessarily help.
I was mainly referring to the __foo__ vs. _foo_ part,
where (I think) once you've read why they're both there, it's not necessary
to restate
Yoo !!
disclaimer
My answer is most likely going to be a bit broad and include stuff you
already know; I am just taking the occasion to write a blurb that
could possibly end up somewhere in the documentation (typically as a
complement of cartesian_product?), if someone finds it
Hi all,
I just noticed that we carefully check that Sage computes something completely
wrong. From sage/structure/element.pyx, line 2052 :
--
When little is implemented about a given ring, then mod may
return simply return `f`. For example, reduction is
On 30 Apr 2014, at 08:28, Charles Bouillaguet charles.bouillag...@gmail.com
wrote:
Hi all,
I just noticed that we carefully check that Sage computes something
completely wrong. From sage/structure/element.pyx, line 2052 :
--
When little is implemented
Hell everybody !
Here is the problem I met today:
sage: F = FiniteEnumeratedSet((a,b,c)); F
{'a', 'b', 'c'}
sage: isinstance(F,Parent)
True
sage: F[0]
'a'
sage: F[0].parent()
---
AttributeError
Hi Nathann,
This is one very special case where the Parent/Element relation is
broken. First of all FiniteEnumeratedSet is not the parent of its
elements (it is a facade):
sage: F = FiniteEnumeratedSet([1, Partition([2,1]), Permutation([3,2,1])])
sage: F
{1, [2, 1], [3, 2, 1]}
sage:
OK, after fixing the self.log patchbot problem in patchbot-2.1.1 I get:
Getting trusted author list...
WARNING: Do not use this copy of sage while the patchbot is running.
'/scratch/sage-6.1.1-x86_64-Linux'/sage -i ccache
git checkout patchbot/base
git checkout -b patchbot/base
git fetch
On Wednesday, 30 April 2014 16:12:33 UTC+10, Nathann Cohen wrote:
There is also the problem of these __add__ and _add_. From just looking at
the names you have no idea what the difference is, except if you wrote the
code yourself.
Now, in the graph classes we have function like
This is one very special case where the Parent/Element relation is
broken. First of all FiniteEnumeratedSet is not the parent of its
elements (it is a facade):
Well, then I am asking whether it is a good idea / should be allowed.
We already have a tool to store list of elements without
How recent is your git?
On Wed, Apr 30, 2014 at 12:31 AM, Ralf Stephan gtrw...@gmail.com wrote:
OK, after fixing the self.log patchbot problem in patchbot-2.1.1 I get:
Getting trusted author list...
WARNING: Do not use this copy of sage while the patchbot is running.
On 29 April 2014 19:23, Martin Albrecht martinralbre...@googlemail.com wrote:
On Monday 28 Apr 2014 14:57:59 François Colas wrote:
Hi Martin,
Here is two examples using multivariate quotients and extension fields
which should be faster than computing CyclotomicField(m) or
Homebrew/Macports/Fink/etc are not supported and likely to conflict with
Sage. What kind of error do you get from make distclean? You can try to
exclude non-system stuff from the PATH to ignore 3rd party software:
export PATH=/usr/bin:/bin:/usr/sbin:/sbin
make distclean
make
On Wednesday,
On Wednesday, April 30, 2014 8:28:24 AM UTC+2, Charles Bouillaguet wrote:
Hi all,
I just noticed that we carefully check that Sage computes something
completely wrong. From sage/structure/element.pyx, line 2052 :
--
When little is implemented about a
On 30 April 2014 09:35, Jean-Pierre Flori jpfl...@gmail.com wrote:
On Wednesday, April 30, 2014 8:28:24 AM UTC+2, Charles Bouillaguet wrote:
Hi all,
I just noticed that we carefully check that Sage computes something
completely wrong. From sage/structure/element.pyx, line 2052 :
What I am trying to do is to use the prime factorisation of m to compute in
another field than Q(zeta_m) (i.e. Q(zeta_m1, zeta_m2, ..., zeta_ml)) or
Q[x]/Phi_m (i.e. Q[x1, ..., xl] / Phi_m1, ..., Phi_ml) because I need m
between 1000 and 1 and actually sage is not able to do this. The idea
On Wednesday, April 30, 2014 11:04:06 AM UTC+2, John Cremona wrote:
On 30 April 2014 09:35, Jean-Pierre Flori jpf...@gmail.com javascript:
wrote:
On Wednesday, April 30, 2014 8:28:24 AM UTC+2, Charles Bouillaguet
wrote:
Hi all,
I just noticed that we carefully check
On 30 April 2014 10:09, François Colas fco...@gmail.com wrote:
What I am trying to do is to use the prime factorisation of m to compute in
another field than Q(zeta_m) (i.e. Q(zeta_m1, zeta_m2, ..., zeta_ml)) or
Q[x]/Phi_m (i.e. Q[x1, ..., xl] / Phi_m1, ..., Phi_ml) because I need m
between
On 30 April 2014 10:13, Jean-Pierre Flori jpfl...@gmail.com wrote:
On Wednesday, April 30, 2014 11:04:06 AM UTC+2, John Cremona wrote:
On 30 April 2014 09:35, Jean-Pierre Flori jpf...@gmail.com wrote:
On Wednesday, April 30, 2014 8:28:24 AM UTC+2, Charles Bouillaguet
wrote:
Hi
John H Palmieri wrote:
On Tuesday, April 29, 2014 6:20:25 PM UTC-7, John H Palmieri wrote:
On Tuesday, April 29, 2014 4:45:35 PM UTC-7, leif wrote:
leif wrote:
Volker Braun wrote:
there is no separate spkg in sage = 6, its is an optional
pkg but lives
On Wed, Apr 30, 2014 at 08:12:33AM +0200, Nathann Cohen wrote:
Well, if you find the question justified, of course the answer should be
in the doc.
My point was not about the existence of the answer, but the way I
wrote it :-) Was it helpful?
There is also the problem of these
On Wed, Apr 30, 2014 at 09:23:41AM +0200, Vincent Delecroix wrote:
FiniteEnumeratedSet is aimed to not modify the input it gets. So if
you feed it with Python objects which are not elements it will not
complain and you have to go with that.
Yup. We would want to properly support facade
My point was not about the existence of the answer, but the way I
wrote it :-) Was it helpful?
Oh. As an answer on sage-devel yes, but you can' t write ling things like
that in the doc. I mean, if you do people probably will not find it when
they have the problem.
This is about the coercion
Yo !
Yup. We would want to properly support facade FiniteEnumeratedSets
over plain Python objects and in particular have:
sage: F = FiniteEnumeratedSet([a,b,c])
sage: F(a)
a
However the coercion system currently does not support facades over
plain Python objects.
On Wed, Apr 30, 2014 at 12:22:41PM +0200, Nathann Cohen wrote:
Okay... Then would it make sense to make things like
FiniteEnumeratedSet behave as if they were real parents, for
instance by implementing the __call__ function manually (or let it be
inherited from Facade or whatever it is) so
Hi Nathann,
[Followup-To: nach gmane.comp.mathematics.sage.combinat.devel gesetzt.]
There is also the problem of these __add__ and _add_. From just looking at
the names you have no idea what the difference is, except if you wrote the
code yourself.
Well, of course one needs to learn the
On Wed, Apr 30, 2014 at 12:19:41PM +0200, Nathann Cohen wrote:
Not my job.
Nor mine in the case of coercion and the _..._ methods :-) Because I
already spent a lot of time on some pieces of the Sage infrastructure
does not mean I (or anybody on sage-combinat-devel) am responsible for
all of
On Wednesday, April 30, 2014 9:50:27 AM UTC+1, Andrew wrote:
singular-3.1.5.p9
Sage-6.2.rc0 uses Singular 3.1.6.p1, you are building an old branch
(possibly older than when we fixed the OSX 10.9 build). Are you sure you
didn't accidentally check out 6.2.beta0? Check git log
--
You
Well, of course one needs to learn the language and its *context* if one
wants to program something.
Yes, but we want to make the language easy to work with, and easy to learn.
_add_coerced_elements_ (if it makes any sense, I do not really know what
its ideal name should be) is clearly more
Hi Guys,
thanks for the support. However, I don't know where I'm supposed to type
'sage -i topcom' ? is this the same as sage: -i topcom, or the command
sage: install_package('TOPCOM') ?
I have the latest version installed, i.e 6.1.1 for mac OS.
When I type sage: install_package('TOPCOM'),
Great, it works!
Thanks a lot for the help.
Best,
Oskar
On Wednesday, April 30, 2014 3:24:34 PM UTC+2, Volker Braun wrote:
Lower case. Open a terminal and run sage -i topcom (or
/Applications/sage/sage -i topcom if it isn't in the search path).
On Wednesday, April 30, 2014 2:12:34
On Wed, Apr 30, 2014 at 9:31 AM, Ralf Stephan gtrw...@gmail.com wrote:
patchbot/patchbot.py, line 295, in check_base
do_or_die(git fetch %s +%s:patchbot/base_upstream %
(self.config['base_repo'], self.config['base_branch']))
Since I couldn't get a git version that worked (reinstalled
On Wednesday, 30 April 2014 20:48:01 UTC+10, Volker Braun wrote:
On Wednesday, April 30, 2014 9:50:27 AM UTC+1, Andrew wrote:
singular-3.1.5.p9
Sage-6.2.rc0 uses Singular 3.1.6.p1, you are building an old branch
(possibly older than when we fixed the OSX 10.9 build). Are you sure you
OK, so the singular version seems to be in
$SAGE_ROOT/build/pkgs/singular/package-version.txt
and it is indeed set to 3.1.5.p9. Updating this by hand to 3.1.6.p1 and
then re-making gave a checksum error on
upstream/singular-3.1.6.p1
Deleting this and then re-making still gives a checksum
To get the latest betas you should be tracking the develop branch (from
trac or github, they are the same).
You can issue something like:
git checkout -b develop trac/develop
to make a local copy of it and directly swith to it.
On Wednesday, April 30, 2014 4:30:44 PM UTC+2, Andrew wrote:
OK,
No offense at all.
Oh, none taken at all ! I just wanted to emphasize that working for a
long time with Python and with Sage did not necessarily help.
I was mainly referring to the __foo__ vs. _foo_ part,
where (I think) once you've read why they're both there, it's not necessary
to restate
Or just do a git pull, since you are on the master branch this will give
you 6.1.1 which afaik also builds on OSX 10.9.
On Wednesday, April 30, 2014 3:38:29 PM UTC+1, Jean-Pierre Flori wrote:
To get the latest betas you should be tracking the develop branch (from
trac or github, they are
It appears git changed its output with some version =1.9.2:
sage -t --long src/sage/dev/sagedev.py
**
File src/sage/dev/sagedev.py, line 897, in
sage.dev.sagedev.SageDev.checkout_branch
Failed example:
On Thursday, 1 May 2014 00:47:20 UTC+10, Volker Braun wrote:
Or just do a git pull, since you are on the master branch this will give
you 6.1.1 which afaik also builds on OSX 10.9.
As detailed above, I have the latest master branch but for some reason it
has the wrong version of singular:
I think you half-built Sage gcc conflicts with Apple gcc. Just rm
-rf /usr/local/src/sage/local and try again.
On Wednesday, April 30, 2014 10:56:11 PM UTC+1, Andrew wrote:
On Thursday, 1 May 2014 00:47:20 UTC+10, Volker Braun wrote:
Or just do a git pull, since you are on the master
Hi,
Pickling of permutation groups is broken, and has been broken for a
while:
sage: G = PermutationGroup([[(1,2,3),(4,5)],[(3,4)]])
sage: G.category()
Category of finite permutation groups
sage: H = loads(dumps(G))
sage: H.category()
Category of sets
Analysis:
On Tuesday, April 29, 2014 3:56:10 PM UTC-4, Volker Braun wrote:
Ok, I changed it to:
$ git trac find b42c581
Commit has been merged in 6.2.beta8. - new
addition
Yes, thanks! That will help a lot down the way.
Though Merged in is still a useful field ;-)
Not that Sage will likely get some of this, but worth pointing out.
http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To
58 matches
Mail list logo
