> The graphs(...) construction is naturally an iterator, so instead of
> constructing a list, just iterate through them, saving the ones you
> need. Try this:
> sage: def check_size(g):
> ....: return g.size() == 6
> ....:
> sage: L = []
> sage: for g in graphs(7):
> ....: if check_size(g):
> ....: L.append(g)
> ....:
>
Is there a difference in action between this and Jason's list
comprehension construct below?
sage: [g for g in graphs(3) if g.size()==3]
[Graph on 3 vertices]
That is, does his example construct just the generator and then append
them to the list like yours, or does it construct the list first?
Either yes or no will help my Python understanding.
But what I am really getting at is what David Joyner calls making Sage
"insanely easy" to use. I had also considered defining extra
functions to do this, but this just adds another layer of overhead;
the 'filter' construction (and Jason's idea) are both at least ways to
do it in a compact way, so there is the least needed change when
checking something new.
However, the idea is not just for me to have something that works, to
show students, which I have done in some other classes (and had a lot
of fun learning to program and parse Python on the way!), but to
create something which the students, *particularly* the ones with no
programming experience, can change themselves with as little pain as
possible. Even with my own limited programming experience, I am
constantly baffled by how scary algorithmic thinking is to students
who create distractingly and annoyingly fancy Powerpoint presentations
with aplomb - but you teach who you have. Probably 20 years ago it
would have been the opposite - any computer-literate students would
have been down with BASIC but mystified by a double-click.
> > Even the syntax of the graphs_list.show_graphs(list) is pretty thorny
> > and certainly nonintuitive compared to the rest of Sage graphics,
>
> Can you give an example of what you're talking about? Given any
> arbitrary
> list of Sage objects, the only obvious choice I can think of is the
> GraphicsArray object, which usually wants a list of lists anyway. The
> whole
> reason we wrote the graphs_list set of functions was to make it easier
> to
> get nice plots of lists of graphs. It would be much easier for us to
> make
> you happy regarding this point if you could give us an example of
> other
> sage objects that act so nicely.
Oh, I just meant as opposed to something like just typing show(list).
Again, my standard concern is "insanely easy", and hence as consistent
as possible. But I hadn't thought of the fact that these are of lists
of graphics objects, since this is a different case than when one uses
show(P+Q) or something, so I apologize for misinterpreting this; I
believe you that there probably isn't a better way to do it! I'm
sorry for it, and definitely didn't intend to be irksome.
>
> Finally, regarding efficiency, there are absolutely no guarantees. The
> canonical labeling of graphs is somewhat competitive, but it still has
> a ways to go to catch up, and it is currently going through a major
> overhaul by yours truly. As far as generating graphs goes, you should
> not expect it to be fast at all. All that is implemented right now is
> in Python, all the property checks are in Python, and no optimizations
> of any kind have been done. What needs to happen first is optimization
> of the canonical labeling function.
That is what I expected, but hopefully won't be too big a problem -
the *nice* part about 'customers' needing insane ease is that they
usually don't need insane speed! The tree generator alone (linear or
not) will be extremely helpful. Thanks as always!
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sage-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
