If the intent is to control the namespace and break up into a number of small
files but retain tab auto completion and view docs then perhaps this is
strategy to consider:
http://www.artima.com/weblogs/viewpost.jsp?thread=254507
--
--
To post to this group, send an email to sage-devel@googleg
On Tue, Jul 10, 2012 at 9:57 AM, Julien Puydt wrote:
> Le 10/07/2012 18:21, Keshav Kini a écrit :
>
>> Have you looked at the files?
>
>
> Yes.
>
>
>> What names would you suggest?
>
>
> There are quite a few ideas :
>
> - matrix_constructions (copy, augment, submatrix, tensor_product, ...) ;
> -
Le 10/07/2012 18:21, Keshav Kini a écrit :
Have you looked at the files?
Yes.
What names would you suggest?
There are quite a few ideas :
- matrix_constructions (copy, augment, submatrix, tensor_product, ...) ;
- matrix_conversions (pari, maxima, singular, ...) ;
- matrix_representations (
On Tue, Jul 10, 2012 at 9:21 AM, Keshav Kini wrote:
> Julien Puydt writes:
>> Le 10/07/2012 09:19, Jeroen Demeyer a écrit :
>>> On 2012-07-10 06:47, William Stein wrote:
Seriously? You guys actually *want* a single 20,000 line Cython file?
Why? The only argument you are giving is tha
Julien Puydt writes:
> Le 10/07/2012 09:19, Jeroen Demeyer a écrit :
>> On 2012-07-10 06:47, William Stein wrote:
>>> Seriously? You guys actually *want* a single 20,000 line Cython file?
>>> Why? The only argument you are giving is that you can't remember
>>> which file something is in, so let
Le 10/07/2012 09:19, Jeroen Demeyer a écrit :
On 2012-07-10 06:47, William Stein wrote:
Seriously? You guys actually *want* a single 20,000 line Cython file?
Why? The only argument you are giving is that you can't remember
which file something is in, so let's just put everything in one
massiv
On 2012-07-10 06:47, William Stein wrote:
> Seriously? You guys actually *want* a single 20,000 line Cython file?
> Why? The only argument you are giving is that you can't remember
> which file something is in, so let's just put everything in one
> massive file. I'm clearly missing something.
William Stein writes:
> On Mon, Jul 9, 2012 at 9:08 PM, Keshav Kini wrote:
>> Robert Bradshaw writes:
>>> I stand by my position that it's a hack to have to break things up due
>>> to technical limitations of compilation/testing. Maybe a necessary
>>> hack, but we've contorted the code due to to
On 7/9/12 11:47 PM, William Stein wrote:
Seriously? You guys actually*want* a single 20,000 line Cython file?
Why? The only argument you are giving is that you can't remember
which file something is in, so let's just put everything in one
massive file. I'm clearly missing something.
I was
On Mon, Jul 9, 2012 at 9:08 PM, Keshav Kini wrote:
> Robert Bradshaw writes:
>
>> On Mon, Jul 9, 2012 at 11:54 AM, William Stein wrote:
>>> On Mon, Jul 9, 2012 at 11:49 AM, Robert Bradshaw
>>> wrote:
On Mon, Jun 18, 2012 at 7:03 PM, Jason Grout
wrote:
> On 6/18/12 8:05 PM, John H
Robert Bradshaw writes:
> On Mon, Jul 9, 2012 at 11:54 AM, William Stein wrote:
>> On Mon, Jul 9, 2012 at 11:49 AM, Robert Bradshaw
>> wrote:
>>> On Mon, Jun 18, 2012 at 7:03 PM, Jason Grout
>>> wrote:
On 6/18/12 8:05 PM, John H Palmieri wrote:
>
> On Monday, June 18, 2012 3:34:15
On Tuesday, 10 July 2012 03:19:52 UTC+8, Robert Bradshaw wrote:
>
> The problem with Graph vs. BipartiteGraph is because the one extends
> from the other. Instead, both should descend from a common base class
> that implements the common functionality. Something like add_edge
> would not belon
On Mon, Jul 9, 2012 at 11:54 AM, William Stein wrote:
> On Mon, Jul 9, 2012 at 11:49 AM, Robert Bradshaw
> wrote:
>> On Mon, Jun 18, 2012 at 7:03 PM, Jason Grout
>> wrote:
>>> On 6/18/12 8:05 PM, John H Palmieri wrote:
On Monday, June 18, 2012 3:34:15 AM UTC-7, Nathann Cohen wrote:
>>>
The problem with Graph vs. BipartiteGraph is because the one extends
from the other. Instead, both should descend from a common base class
that implements the common functionality. Something like add_edge
would not belong in this baseclass, and algorithms that take advantage
of special graph functi
On Mon, Jul 9, 2012 at 11:49 AM, Robert Bradshaw
wrote:
> On Mon, Jun 18, 2012 at 7:03 PM, Jason Grout
> wrote:
>> On 6/18/12 8:05 PM, John H Palmieri wrote:
>>>
>>> On Monday, June 18, 2012 3:34:15 AM UTC-7, Nathann Cohen wrote:
>>>
>>> Helloo everybody !!!
>>>
>>> Our graph file
On Mon, Jun 18, 2012 at 7:03 PM, Jason Grout
wrote:
> On 6/18/12 8:05 PM, John H Palmieri wrote:
>>
>> On Monday, June 18, 2012 3:34:15 AM UTC-7, Nathann Cohen wrote:
>>
>> Helloo everybody !!!
>>
>> Our graph files are getting quite large, and there is in some
>> situations a
On Monday, July 9, 2012 2:59:33 AM UTC+1, Birk Eisermann wrote:
>
> (I have searched and found that there has been discussion on how much
> networkx will be adapted in sage - and it seems that there is some issue
> with the license... right? I also read the sage-devel thread "graph
> theory: ref
Hi Jason,
Good point! Networkx comes quite close. I agree with the distinction
between graphs and algorithms as in networkx. Graphs objects just for
storage of the graph data.
But for algorithms, I have different picture which is closer to how it
is in sage... e.g. no segmentation (hence als
On 7/6/12 10:02 AM, Birk Eisermann wrote:
> Similar, it is for classes. If one class focuses only one
responsibility,
> the functionality of that class is much easier to understand.
Well, the Graph class is not very complicated. It just has one thousand
methods that apply to graphs. But at lea
On 07/06/2012 08:20 PM, Jeroen Demeyer wrote:
On 2012-07-06 14:10, Nathann Cohen wrote:
Then, of course, we would have to change the is_isomorphic function (it
does not take the bipartition into account).
Indeed, if I create a BipartiteGraph object I would expect the
is_isomorphic() function t
Hello Nathann!
On 07/06/2012 08:06 PM, Nathann Cohen wrote:
> I found that G.Bipartition() will do the job.
> Surprisingly (or not) all vertices belong to one class and the other is
> empty. For me, BipartiteGraph(k,l) would be more natural (maybe with the
> convertion that the first partiti
On Friday, July 6, 2012 1:33:23 PM UTC+1, Nathann Cohen wrote:
>
> I agree that you may want to compute automorphisms groups quickly, but it
> quickly gets painful that every edge addition requires a whole copy of the
> graph's structure :-p
>
Graphs just need a way to add multiple edges in a si
>> I also wondered whether you wanted to compute isomorphisms in which the
>> two sets are exchanged
> I think both questions make sense, depending on the problem you're
> working with.
Indeed. That's why I think that such code should be "custom code",
code that you write for yourself and that jus
On 2012-07-06 14:38, Nathann Cohen wrote:
> I also wondered whether you wanted to compute isomorphisms in which the
> two sets are exchanged
I think both questions make sense, depending on the problem you're
working with. Maybe the default should be to consider purely the
partition, BipartiteGraph
> Indeed, if I create a BipartiteGraph object I would expect the
> is_isomorphic() function to check for isomorphism *as bipartite graphs*.
>
> (luckily, for connected graphs, the notions are the same)
if self.is_connected():
return Graph.is_isomorphic(self)
else:
raise ValueError("No idea o
> I forgot to mention one of the main advantages of (logically) immutable
> objects (better late than never): You cannot cache anything if you allow
an
> object representing one mathematical entity to be modified into something
> completely different. Now perhaps you only care about having the worl
On 2012-07-06 14:10, Nathann Cohen wrote:
> Then, of course, we would have to change the is_isomorphic function (it
> does not take the bipartition into account).
Indeed, if I create a BipartiteGraph object I would expect the
is_isomorphic() function to check for isomorphism *as bipartite graphs*.
> A BipartiteGraph object should not just be a graph which happens to be
> bipartite.
O_O
What about giving them a different name then ? If Bipartite graphs are "not
just Bipartite graphs" ? :-p
> The BipartiteGraph object should have additional structure,
> namely the vertex partition. As
Hell Birk !!!
> Why does the graph complement G make a copy the graph itself and then
> changes the edges? I think "G = copy(self)" is the root of problem. The
> graph and its complement are too different: in general, properties like
> bipartitness, connectedness,
> col
On Friday, July 6, 2012 8:41:26 AM UTC+1, Birk Eisermann wrote:
>
> Somehow I agree that many algorithms do not change the graph and
> therefore, the graph classes could be immutable.
>
I forgot to mention one of the main advantages of (logically) immutable
objects (better late than never): You
On 2012-07-06 09:41, Birk Eisermann wrote:
> To me, BipartiteGraph(n) does not make sense. It is a graph without
> edges. Trying to find out to which partition class vertex 0 belongs to
> (G=BipartiteGraph(3); G.) I was struck by this immense list of more
> than 270 functions. I found that G.Bipart
Hello everyone!
Here are my answers to these problems. Feel free to comment!
@ Nathann
1) Some history : the BipartiteGraph class.
>
>
> Try the following :
>> sage: BipartiteGraph(graphs.CompleteBipartiteGraph(3,3)).complement()
>>
>
Why does the graph complement G make a copy the graph itself
On Wednesday, 20 June 2012 00:06:11 UTC+3, Nathann Cohen wrote:
>
> Hellooo everybody !!
>
> As in the best times, I tried 5 times to answer all who answered this
> thread, got angry, erased the message, and began again. But Robert Miller
> has a nice saying when we get to such situations :
Hellooo everybody !!
As in the best times, I tried 5 times to answer all who answered this
thread, got angry, erased the message, and began again. But Robert Miller
has a nice saying when we get to such situations : "shut the fuck up and
show me the code". So that's what I will try to do. Give
On Tuesday, 19 June 2012 03:15:54 UTC+3, Nathann Cohen wrote:
>
> > yes. If implemented right, an overhead is insignificant.
>
> O_o
>
> Are you joking ? O_o
>
no, not at all. If you want to ADD edges, that is.
It's a case when functional programming does rather well, IMHO.
>
> > No, you sho
On Tuesday, June 19, 2012 10:03:34 AM UTC+8, jason wrote:
>
> On 6/18/12 8:05 PM, John H Palmieri wrote:
> > On Monday, June 18, 2012 3:34:15 AM UTC-7, Nathann Cohen wrote:
> >
> > Helloo everybody !!!
> >
> > Our graph files are getting quite large, and there is in some
> >
On 6/18/12 8:05 PM, John H Palmieri wrote:
On Monday, June 18, 2012 3:34:15 AM UTC-7, Nathann Cohen wrote:
Helloo everybody !!!
Our graph files are getting quite large, and there is in some
situations a way to make it shorter : we can define some functions
in modules and
On Monday, June 18, 2012 3:34:15 AM UTC-7, Nathann Cohen wrote:
>
> Helloo everybody !!!
>
> Our graph files are getting quite large, and there is in some situations a
> way to make it shorter : we can define some functions in modules and import
> them in the Graph class afterwards.
>
Th
On Jun 18, 2012 8:15 PM, "Nathann Cohen" wrote:
>
> > yes. If implemented right, an overhead is insignificant.
>
> O_o
>
> Are you joking ? O_o
Python strings are immutable, for instance.
Henry de Valence
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe fro
> yes. If implemented right, an overhead is insignificant.
O_o
Are you joking ? O_o
> No, you should not be able to apply to a generic graph a function which
only
> works for perfect
> graphs. Otherwise it is asking for trouble.
I totally agree, only there is *no* function that only works for o
On Monday, 18 June 2012 16:01:00 UTC+3, Nathann Cohen wrote:
>
> > So you are saying that only the generic Graph should be mutable, thats
> > fine. Just make all derived FooGraph's immutable.
>
> WHAT ? O_o
>
> And what do you do with your graph once that is is immutable ? You
> create a whol
On Monday, June 18, 2012 2:01:00 PM UTC+1, Nathann Cohen wrote:
>
> And what do you do with your graph once that is is immutable ? You
> create a whole copy when you want to add an edge ?
>
Thats how matrices work in Sage, for example.
> And if you have a GenericGraph on which you want to us
> So you are saying that only the generic Graph should be mutable, thats
> fine. Just make all derived FooGraph's immutable.
WHAT ? O_o
And what do you do with your graph once that is is immutable ? You
create a whole copy when you want to add an edge ?
And if you have a GenericGraph on which you
So you are saying that only the generic Graph should be mutable, thats
fine. Just make all derived FooGraph's immutable. The base Graph class can
have as_foo_graph() methods that check the property and return a suitable
specialized class.
On Monday, June 18, 2012 12:15:00 PM UTC+1, Nathann Coh
> Usually the "huge source file" problem is just a symptom of trying to
> stuff everything into one class. You should probably think about whether
you
> can introduce a class hierarchy somewhere, especially if your
is_something()
> property doesn't make sense for the most generic graph. Maybe you w
Usually the "huge source file" problem is just a symptom of trying to stuff
everything into one class. You should probably think about whether you can
introduce a class hierarchy somewhere, especially if your is_something()
property doesn't make sense for the most generic graph. Maybe you want t
46 matches
Mail list logo
