Jori Mäntysalo writes:
>
> For graphs we have
>
> from sage.graphs.generators.smallgraphs import *
>
> and
>
> from sage.graphs.generators.platonic_solids import *
>
> and it seems unnecessary but not that harmful to have two set to import.
>
> * * *
>
> So, we could have also something like
>
>
Hello!
I am trying to set font size to 10 and export resulting image in PGF:
# Change font style
from matplotlib import rc
font = {'family':'serif',
'serif':['Computer Modern Unicode'],
'size': 10, }
rc('font', **font)
# Create and save test plot
file_name = '/tmp/foo.pgf'
p =
On Wed, 6 Apr 2016, Johan S. R. Nielsen wrote:
As an example: IMO KleinFourGroup() should be groups.KleinFour() just
like we have graphs.PetersenGraph().
I completely agree. For coding theory, we have also started to put
everything into catalogues codes. and channels., and the
functions and c
On Wednesday, April 6, 2016 at 1:39:33 PM UTC+1, Simon King wrote:
>
> On 2016-04-06, Dima Pasechnik > wrote:
> >> Perhaps it makes sense to just delete SAGE_LOCAL/bin/git, so that my
> >> system-wide git will be picked up?
> >>
> > or make your SAGE_LOCAL/bin/git a symlink to the system git.
> As an example: IMO KleinFourGroup() should be groups.KleinFour() just like
> we have graphs.PetersenGraph().
>
>
There is a lot of old code floating around like that that needs to be
changed to use our current practices (like moving things from the global
namespace to the appropriate catalo
On 2016-04-06, Dima Pasechnik wrote:
>> Perhaps it makes sense to just delete SAGE_LOCAL/bin/git, so that my
>> system-wide git will be picked up?
>>
> or make your SAGE_LOCAL/bin/git a symlink to the system git.
Unfortunately, removing git didn't work. Even removing
SAGE_LOCAL/libexec/git-core
On Wednesday, April 6, 2016 at 1:24:47 PM UTC+1, Simon King wrote:
>
> Hi François,
>
> On 2016-04-06, Francois Bissey >
> wrote:
> > Yes and no. From what I can see it is properly linked. So the linker
> itself requires
> > you to add libssl.
> > LIBS=-lssl ./sage -p git
> > may work.
>
Hi François,
On 2016-04-06, Francois Bissey wrote:
> Yes and no. From what I can see it is properly linked. So the linker itself
> requires
> you to add libssl.
> LIBS=-lssl ./sage -p git
> may work.
Unfortunately it didn't. Difficult.
Perhaps it makes sense to just delete SAGE_LOCAL/bin/git,
> As an example: IMO KleinFourGroup() should be groups.KleinFour() just like
> we have graphs.PetersenGraph().
I completely agree. For coding theory, we have also started to put
everything into catalogues codes. and channels., and the
functions and constructors in global namespace are slowly gett
Yes and no. From what I can see it is properly linked. So the linker itself
requires
you to add libssl.
LIBS=-lssl ./sage -p git
may work.
> On 6/04/2016, at 23:04, Simon King wrote:
>
> ... which would be a problem of Ubuntu, right?
This email may be confidential and subject to legal privil
Hi François,
On 2016-04-06, Francois Bissey wrote:
> libcurl.so doesn’t seem to be properly linked to openssl.
... which would be a problem of Ubuntu, right?
> Output of
> ldd -r /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcurl.so
king@king-C70-B:~/Sage/git/sage$ ldd -r
/usr
On Wed, 6 Apr 2016, Bruno Grenet wrote:
to take into account the fact that 12.is_pri offers no completion
I guess this could be handled as a special case, but then we should also
have 12.is_prime? and 12.is_prime??.
Would this be useful for others as a direct function of Sage? And if so,
s
Hum…
configure:5180: checking for curl_global_init in -lcurl
configure:5205: gcc -o conftest -g -O2 -L/home/king/Sage/git/sage/local/lib
-Wl,-rpath,/home/king/Sage/git/sage/local/lib conftest.c -lcurl >&5
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libcurl.so: undefined
referen
mmarco wrote:
> I have also
> missed something like .squarefree_part() or something like that.
I've had a branch lying around for some time with exactly that; I just
pushed it to trac:
http://trac.sagemath.org/ticket/20368
--
Marc Mezzarobba
--
You received this message because you are subscr
Hi François,
Am Mittwoch, 6. April 2016 09:17:38 UTC+2 schrieb François:
>
> Not that one! The once produced when git is being built in
> SAGE_LOCAL/var/tmp/sage/build/git-2.6.2/src/
>
I did sage -f -s git, so that I could preserve the directory you mention.
The config.log found there is attac
Le 06/04/2016 09:21, Jori Mäntysalo a écrit :
I was asked to look a sketch of paper about unitary divisors.
For definition see https://en.wikipedia.org/wiki/Unitary_divisor .
Sage code can be oneliner:
def unitary_divisors(n):
return [prod([p[0]^p[1] for p in f]) for f in
Set(factor(n)).
I think it makes sense to include it for elements of UFD's. I have also
missed something like .squarefree_part() or something like that.
--
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
On Tuesday, April 5, 2016 at 8:44:45 PM UTC+2, William wrote:
>
> [...] toward standard open source practices.
You mean like in the Linux kernel, which uses a single monolithic git
repository?
Really, modularization is not a useful goal in of itself. And it comes with
its own sets of issues, s
I was asked to look a sketch of paper about unitary divisors.
For definition see https://en.wikipedia.org/wiki/Unitary_divisor . Sage
code can be oneliner:
def unitary_divisors(n):
return [prod([p[0]^p[1] for p in f]) for f in Set(factor(n)).subsets()]
Would this be useful for others as a
Not that one! The once produced when git is being built in
SAGE_LOCAL/var/tmp/sage/build/git-2.6.2/src/
François
> On 6/04/2016, at 18:32, Simon King wrote:
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group an
20 matches
Mail list logo
