[sage-devel] Re: cython memory leak when one's forget to cdef the for loop variable

[Sébastien Labbé]

Does this also explain the leak?

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: cython memory leak when one's forget to cdef the for loop variable

[Volker Braun]

PS: Write your code in a file and compile it with "cython -a myfile.pyx", 
that generates a html file with explanations.




On Thursday, October 20, 2016 at 1:11:14 AM UTC+2, Volker Braun wrote:
>
> Thats the expected behavoir. Without type annotation, cython just does the 
> same as Python (create a list of 10**8 elements and iterate over). With 
> type annotation it is a C-level for loop.
>
>
> On Thursday, October 20, 2016 at 12:33:47 AM UTC+2, Sébastien Labbé wrote:
>>
>> Dear sage-devel,
>>
>> Writing cython code, I was having a problem with memory leaks, and I 
>> managed to simplify the problem to a simple for loop computing a sum.
>>
>> If the loop variable a is cdef, everything is fine:
>>
>> sage: %%cython
>> : def test_with_cdef_a(int N):
>> : cdef long S = 0
>> : cdef int a
>> : for a in range(1, N):
>> : sig_check() # Check for Keyboard interupt
>> : S += a
>> : return S
>> :
>> sage: %time test_with_cdef_a(10**8)  # fast, takes no memory, great
>> CPU times: user 103 ms, sys: 2.64 ms, total: 105 ms
>> Wall time: 106 ms
>> 49995000
>>
>> As expected, if I forget the "cdef int a" line, it takes longer. But most 
>> surprisingly, it uses a *lot* of memory during the computation (40%) and 
>> not all of the memory is freed after he computation (30%).
>>
>> sage: %%cython
>> : def test_no_cdef_a(int N):
>> : cdef long S = 0
>> : for a in range(1, N):
>> : sig_check() # Check for Keyboard interupt
>> : S += a
>> : return S
>> :
>> sage: %time test_no_cdef_a(10**8)# this takes a lot of memory 
>> (40%)  + memory leaks (30% of the memory after computation)
>> CPU times: user 8.36 s, sys: 787 ms, total: 9.14 s
>> Wall time: 9.24 s
>> 49995000
>> sage: %time test_no_cdef_a(10**9)# this takes a lot of memory 
>> (all of it, starts swaping)
>>
>> I am using:
>>
>> $ sage -cython -V 
>> Cython version 0.24.1
>> $ sage -version   
>> SageMath version 7.4.beta6, Release Date: 2016-09-24
>>
>> Are you able to reproduce?
>>
>> Sébastien
>>
>>
>>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: cython memory leak when one's forget to cdef the for loop variable

[Volker Braun]

Thats the expected behavoir. Without type annotation, cython just does the 
same as Python (create a list of 10**8 elements and iterate over). With 
type annotation it is a C-level for loop.


On Thursday, October 20, 2016 at 12:33:47 AM UTC+2, Sébastien Labbé wrote:
>
> Dear sage-devel,
>
> Writing cython code, I was having a problem with memory leaks, and I 
> managed to simplify the problem to a simple for loop computing a sum.
>
> If the loop variable a is cdef, everything is fine:
>
> sage: %%cython
> : def test_with_cdef_a(int N):
> : cdef long S = 0
> : cdef int a
> : for a in range(1, N):
> : sig_check() # Check for Keyboard interupt
> : S += a
> : return S
> :
> sage: %time test_with_cdef_a(10**8)  # fast, takes no memory, great
> CPU times: user 103 ms, sys: 2.64 ms, total: 105 ms
> Wall time: 106 ms
> 49995000
>
> As expected, if I forget the "cdef int a" line, it takes longer. But most 
> surprisingly, it uses a *lot* of memory during the computation (40%) and 
> not all of the memory is freed after he computation (30%).
>
> sage: %%cython
> : def test_no_cdef_a(int N):
> : cdef long S = 0
> : for a in range(1, N):
> : sig_check() # Check for Keyboard interupt
> : S += a
> : return S
> :
> sage: %time test_no_cdef_a(10**8)# this takes a lot of memory 
> (40%)  + memory leaks (30% of the memory after computation)
> CPU times: user 8.36 s, sys: 787 ms, total: 9.14 s
> Wall time: 9.24 s
> 49995000
> sage: %time test_no_cdef_a(10**9)# this takes a lot of memory (all 
> of it, starts swaping)
>
> I am using:
>
> $ sage -cython -V 
> Cython version 0.24.1
> $ sage -version   
> SageMath version 7.4.beta6, Release Date: 2016-09-24
>
> Are you able to reproduce?
>
> Sébastien
>
>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] cython memory leak when one's forget to cdef the for loop variable

[Sébastien Labbé]

Dear sage-devel,

Writing cython code, I was having a problem with memory leaks, and I 
managed to simplify the problem to a simple for loop computing a sum.

If the loop variable a is cdef, everything is fine:

sage: %%cython
: def test_with_cdef_a(int N):
: cdef long S = 0
: cdef int a
: for a in range(1, N):
: sig_check() # Check for Keyboard interupt
: S += a
: return S
:
sage: %time test_with_cdef_a(10**8)  # fast, takes no memory, great
CPU times: user 103 ms, sys: 2.64 ms, total: 105 ms
Wall time: 106 ms
49995000

As expected, if I forget the "cdef int a" line, it takes longer. But most 
surprisingly, it uses a *lot* of memory during the computation (40%) and 
not all of the memory is freed after he computation (30%).

sage: %%cython
: def test_no_cdef_a(int N):
: cdef long S = 0
: for a in range(1, N):
: sig_check() # Check for Keyboard interupt
: S += a
: return S
:
sage: %time test_no_cdef_a(10**8)# this takes a lot of memory 
(40%)  + memory leaks (30% of the memory after computation)
CPU times: user 8.36 s, sys: 787 ms, total: 9.14 s
Wall time: 9.24 s
49995000
sage: %time test_no_cdef_a(10**9)# this takes a lot of memory (all 
of it, starts swaping)

I am using:

$ sage -cython -V 
Cython version 0.24.1
$ sage -version   
SageMath version 7.4.beta6, Release Date: 2016-09-24

Are you able to reproduce?

Sébastien


-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: doc.sagemath.org gone from google

[Paul Masson]

In case no one else has noticed, doc.sagemath.org is now showing up in 
Google searches, including the link that initiated this thread.

Google taketh away, and Google giveth back.


On Sunday, August 7, 2016 at 8:25:56 AM UTC-7, William wrote:
>
> I'm googling for links to the sage reference manual, e.g., 
>
>
> https://www.google.com/search?q=sage+Elements+of+Quotients+of+Univariate+Polynomial+Rings=1C5CHFA_enUS691US691=sage+Elements+of+Quotients+of+Univariate+Polynomial+Rings=chrome..69i57j69i64.1153j0j7=chrome=UTF-8
>  
>
> and they now **all** go to combinat.sagemath.org.I had expected to 
> find links such as 
>
>   
> http://doc.sagemath.org/html/en/reference/polynomial_rings/sage/rings/polynomial/polynomial_quotient_ring_element.html
>  
>
> but nope. 
>
> -- 
> William (http://wstein.org) 
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL 1v0.1.0

[François Bissey]

On 19/10/16 23:57, Victor Shoup wrote:

Sure. Will do.


For people not on libsingular-devel, Hannes' answer:
==
The problem is a fast/convinient conversion between long integers in
factory of type CanonicalForm (which is in principle a mpz_t number)
and long integers in NTL of type ZZ (which is, if I understood it
correctly, analogue to the internal of a mpz_t).
(There are routines to access the mpz_t representation of a CanonicalForm in
factory and to construct a CanonicalForm from a mpz_t)

The current implementation uses a string representation in basis
16 (NTL->factory) resp. 10 (factory->NTL),
which is neither nice nor fast, but was easy to implement and works:

mpn_get_str converts the NTL-ZZ-number to a string
and mpz_init_set_str creates then the GMP-mpz_t-number (and then the
CanonicalForm number)

The reverse uses a string with basis 10: mpz_get_str from factory to
string and conv from string to NTL ZZ
=

Francois

--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Is Brown's construction available in the graph component of sagemath?

[Dima Pasechnik]

On Wednesday, October 19, 2016 at 7:05:23 AM UTC+1, ywr nn wrote:
>
> hi, Dima!
>
> In my context, for every power of primes q, Brown's construction gives a 
> graph with order q^2+q+1, maximum degree q+1, diameter 2.
> The graph is not a regular one. The degree sequence of the graph is 
> [(q+1)^(q^2), q^(q+1)].
> This Brown's construction gives known largest lower bounds for the 
> degree-diameter problem for the case of diameter 2.
>
> Is not this construction called "Brown's construction" in graph theory?
>

Well, as I said, it was also discovered simultaneously and independently by 
Erdós and Rényi (see 
e.g. 
http://www.combinatorics.org/ojs/index.php/eljc/article/download/v22i2p21/pdf
for a short discussion on this)

Does this sound right to you?
Dima



> yawara
>
> On Mon, Oct 10, 2016 at 8:52 PM, Dima Pasechnik  > wrote:
>
>>
>>
>> On Sunday, October 9, 2016 at 9:10:50 PM UTC, ni732...@gmail.com wrote:
>>>
>>> Brown's construction is the function which takes a finite field to a 
>>> graph with diameter 2.
>>> http://www.emis.ams.org/journals/EJC/Surveys/ds14.pdf
>>>
>>> Is it available in the graph component of sagemath?
>>>
>>
>> I won't be surprised if it could be constructed as a subgraph of one of 
>> many strongly regular graphs
>> known to Sage, but there is no direct way to build such a graph in Sage, 
>> IMHO.
>>
>> The description of the adjacency in the link you provide is a bit too 
>> brief to see what exactly it does, 
>> but I think these graphs are also known as  Erdős–Rényi graphs, from 
>> P. Erdós, A. Rényi, V.T. Sós
>> On a problem of graph theory
>> Studia Sci. Math. Hungar., 1 (1966), pp. 215–235
>>
>> Brown's paper was published in the same year: W.G. Brown
>> On graphs that do not contain a Thomsen graph
>> Canad. Math. Bull., 9 (1966), pp. 281–285
>>
>> We published a paper where these graphs were considered, and I implemented
>> a construction of them in GAP, but not in Sage :-)
>> https://www.cs.ox.ac.uk/publications/publication7266-abstract.html
>>
>> Please feel free to cc me on the Sage ticket with an implementation, I'd 
>> be glad to review it.
>>
>> Dima
>>  
>>
>>> If not, I plan to implement it for sagemath.
>>>
>>> yawara
>>>
>> -- 
>> 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 sage-devel+...@googlegroups.com .
>> To post to this group, send email to sage-...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Embedding graphs on the projective plane

[Dima Pasechnik]

On Tuesday, October 18, 2016 at 6:59:09 PM UTC+1, Joshua Fallon wrote:
>
> Hi all, Sage rookie here. I've been working on writing functions to test 
> whether a graph can be embedded on the projective plane, as in Myrvold and 
> Roth's paper (
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.45.1102=rep1=pdf).
>  
> I'm still working out some bugs, and working on transitioning from Sage 
> functions to adding methods to the graphs class, but I think this could be 
> a useful tool for Sage to have. My first step is a decomposition of 
> two-connected graphs into three-blocks (cycles, cocycles, and 3-connected 
> graphs) as described by Tutte and Cunningham and Edmonds (or call it 
> SPQR-trees, if you like). I have this method in my local Sage source code 
> and I think it's worthwhile to have in its own right alongside 
> blocks_and_cuts_tree. I'd like to use this smaller method to make a first 
> small foray into actual contribution to Sage.
>
> Is it worth requesting a trac account now for the decomposition, or should 
> I hold off until the whole embeddability tester is running in my local 
> source code (assuming there's interest in that function itself)?
>

would be great to have, sure, go ahead. 

>
> Best,
> Joshua Fallon
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

[Ximin Luo]

Thanks a lot!

'Martin R. Albrecht' via sage-devel:
> Hi all,
> 
> this is now  https://trac.sagemath.org/ticket/21728
> 
> Cheers,
> Martin
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

[Ximin Luo]

Jeroen Demeyer:
> On 2016-10-18 17:52, Ximin Luo wrote:
>> (2) In the long run, one can think about splitting out sage.rings.integers 
>> (and related things) into a small library "sage-types" or something like 
>> that. Then sagelib and fpylll can depend on this, and there would be no 
>> circular dependency, even when Debian or other distros try to build it.
> 
> I do not understand how that would help you. I am proposing a solution
> 
> (A) Split the Sage package in 2 packages (Sage-the-library + 
> Sage-the-distribution)
> 
> and you have various reasons why this doesn't work. Instead you propose
> 
> (B) Split the Sage package in 2 packages (sage.rings.integers (and related 
> things) + the rest)
> 
> To me, (A) and (B) look very similar. Why would (B) work while (A) does not? 
> In other words, why are the problems that you mention for (A) not applicable 
> to (B)?
> 

It's a fair observation but there are important differences.

In (A), the majority of the code exists in the dependency (sagelib). However 
the tests for this huge body of code, exist in the dependant. This causes the 
huge write-run-fix loop. And this is not really what a dependency system is 
"supposed" to be used for, we don't have similar situations like this anywhere 
else.

In (B), the sage-types library is supposed to be a minimal library with a 
stable API that doesn't change too often. The write-run-fix loop is greater, 
but it doesn't get invoked nearly as often. This would automatically be true 
just because the code base is smaller, but you could also put some extra effort 
into making it very very stable.

Furthermore, this pattern is very common. If we have a huge project and it 
develops a utility that is useful to other smaller projects, it often gets 
split out. For example we have the NSPR library from Mozilla which Firefox 
depends on, GObject from GNOME, etc.

Smaller projects that want to play with Sage integers, might not want to depend 
on *all* of sagelib - it slows down testing. Possibly some of these people 
would have sage installed already - but some of them might not want to do this, 
or not want to install a whole development version of sage.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] NTL 1v0.1.0

[Victor Shoup]

Sure. Will do.

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

[Francois Bissey]

Very much appreciated Martin! Since this ticket doesn’t touch 
sagelib Gentoo, Debian and other distributions will be able to
use fpylll-0.23 directly in sage-7.4. I’ll issue a revision of
the sage-7.4 ebuild tomorrow and review the ticket if no one
has done it by then.

François

> On 19/10/2016, at 23:02, 'Martin R. Albrecht' via sage-devel 
>  wrote:
> 
> Hi all,
> 
> this is now  https://trac.sagemath.org/ticket/21728
> 
> Cheers,
> Martin
> 
> Martin R. Albrecht writes:
>> Hi there,
>> 
>> Ximin Luo writes:
>>> We can do "pre-install tests" with Sage 7.3, by doing a "dummy
>>> install" using Sage's Makefiles, running the tests here, then
>>> installing them to the "real location". (This requires some patching,
>>> but we have achieved this already and it works.) However with Sage 7.4
>>> this is not possible, due to the fpylll situation. Packages in Debian
>>> (and most other buildsystems) are built and tested as distinct units,
>>> we can't build A, install A, build B, install B, then test A.
>> 
>> I see the problem here.
>> 
>>> So, a much better alternative of resolving the fpylll issue would be
>>> to not have fpylll build-depend on Sage.
>> 
>>> (1) I can see that it's possible to build fpylll without Sage, it will
>>> just have a different API. Could we patch Sage-the-library to use
>>> fpylll-without-Sage, then have Sage itself convert the non-Sage
>>> integers into Sage integers?
>> 
>> […]
>> 
>>> So, what are the problems with (1)? If there are no problems, could we
>>> patch this *before* Sage 7.4 is released? I would be happy to write
>>> the patch myself, but guidance on where to start would also be much
>>> appreciated.
>> 
>> It’d be easy to make that work as far as tests are concerned, we’d lose
>> convenience, though: none of the fpylll functions taking integer
>> arguments would work out of the box.
>> 
>> Alternatively, we could do the conversion on the Python level instead of
>> C/C++/Cython. This way, it could be resolved at runtime. There’d be some
>> overhead, but the Integer conversion functions aren’t really used all
>> that much.
>> 
>> I’ll give that a try.
>> 
>> Cheers,
>> Martin
> 
> 
> -- 
> 
> _pgp: https://keybase.io/martinralbrecht
> _www: https://martinralbrecht.wordpress.com
> _jab: martinralbre...@jabber.ccc.de
> _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
> 
> -- 
> 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 sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

['Martin R. Albrecht' via sage-devel]

Hi all,

this is now  https://trac.sagemath.org/ticket/21728

Cheers,
Martin

Martin R. Albrecht writes:
> Hi there,
>
> Ximin Luo writes:
>> We can do "pre-install tests" with Sage 7.3, by doing a "dummy
>> install" using Sage's Makefiles, running the tests here, then
>> installing them to the "real location". (This requires some patching,
>> but we have achieved this already and it works.) However with Sage 7.4
>> this is not possible, due to the fpylll situation. Packages in Debian
>> (and most other buildsystems) are built and tested as distinct units,
>> we can't build A, install A, build B, install B, then test A.
>
> I see the problem here.
>
>> So, a much better alternative of resolving the fpylll issue would be
>> to not have fpylll build-depend on Sage.
>
>> (1) I can see that it's possible to build fpylll without Sage, it will
>> just have a different API. Could we patch Sage-the-library to use
>> fpylll-without-Sage, then have Sage itself convert the non-Sage
>> integers into Sage integers?
>
> […]
>
>> So, what are the problems with (1)? If there are no problems, could we
>> patch this *before* Sage 7.4 is released? I would be happy to write
>> the patch myself, but guidance on where to start would also be much
>> appreciated.
>
> It’d be easy to make that work as far as tests are concerned, we’d lose
> convenience, though: none of the fpylll functions taking integer
> arguments would work out of the box.
>
> Alternatively, we could do the conversion on the Python level instead of
> C/C++/Cython. This way, it could be resolved at runtime. There’d be some
> overhead, but the Integer conversion functions aren’t really used all
> that much.
>
> I’ll give that a try.
>
> Cheers,
> Martin


-- 

_pgp: https://keybase.io/martinralbrecht
_www: https://martinralbrecht.wordpress.com
_jab: martinralbre...@jabber.ccc.de
_otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

[Jeroen Demeyer]

On 2016-10-18 17:52, Ximin Luo wrote:

(2) In the long run, one can think about splitting out sage.rings.integers (and related 
things) into a small library "sage-types" or something like that. Then sagelib 
and fpylll can depend on this, and there would be no circular dependency, even when 
Debian or other distros try to build it.


I do not understand how that would help you. I am proposing a solution

(A) Split the Sage package in 2 packages (Sage-the-library + 
Sage-the-distribution)


and you have various reasons why this doesn't work. Instead you propose

(B) Split the Sage package in 2 packages (sage.rings.integers (and 
related things) + the rest)


To me, (A) and (B) look very similar. Why would (B) work while (A) does 
not? In other words, why are the problems that you mention for (A) not 
applicable to (B)?


--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Is Brown's construction available in the graph component of sagemath?

[ywr nn]

hi, Dima!

In my context, for every power of primes q, Brown's construction gives a
graph with order q^2+q+1, maximum degree q+1, diameter 2.
The graph is not a regular one. The degree sequence of the graph is
[(q+1)^(q^2), q^(q+1)].
This Brown's construction gives known largest lower bounds for the
degree-diameter problem for the case of diameter 2.

Is not this construction called "Brown's construction" in graph theory?

yawara

On Mon, Oct 10, 2016 at 8:52 PM, Dima Pasechnik  wrote:

>
>
> On Sunday, October 9, 2016 at 9:10:50 PM UTC, ni732...@gmail.com wrote:
>>
>> Brown's construction is the function which takes a finite field to a
>> graph with diameter 2.
>> http://www.emis.ams.org/journals/EJC/Surveys/ds14.pdf
>>
>> Is it available in the graph component of sagemath?
>>
>
> I won't be surprised if it could be constructed as a subgraph of one of
> many strongly regular graphs
> known to Sage, but there is no direct way to build such a graph in Sage,
> IMHO.
>
> The description of the adjacency in the link you provide is a bit too
> brief to see what exactly it does,
> but I think these graphs are also known as  Erdős–Rényi graphs, from
> P. Erdós, A. Rényi, V.T. Sós
> On a problem of graph theory
> Studia Sci. Math. Hungar., 1 (1966), pp. 215–235
>
> Brown's paper was published in the same year: W.G. Brown
> On graphs that do not contain a Thomsen graph
> Canad. Math. Bull., 9 (1966), pp. 281–285
>
> We published a paper where these graphs were considered, and I implemented
> a construction of them in GAP, but not in Sage :-)
> https://www.cs.ox.ac.uk/publications/publication7266-abstract.html
>
> Please feel free to cc me on the Sage ticket with an implementation, I'd
> be glad to review it.
>
> Dima
>
>
>> If not, I plan to implement it for sagemath.
>>
>> yawara
>>
> --
> 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 sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.