On Jan 19, 2008 5:48 PM, kcrisman <[EMAIL PROTECTED]> wrote:
>
>
>
> > 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.
His example constructs just the generators. The two are basically equivalent.
>
> 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.
Ummh, I think that's what the "mathematica demonstrations" idea is all
about. We need to implement something similar in Sage, so people can
play around with graphs, etc., by manipulating buttons, sliders, and
very simple forms.
> 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.
Actually, the behavior of Sage for show(v), where v is a list of graphics
objects, is pretty stupid. This is pretty dumb:
sage: show([plot(sin,(0,1)), circle((0,0),1)])
<html><div class="math">\begin{array}{l}[\text{Graphics object
consisting of 1 graphics primitive},\\
\text{Graphics object consisting of 1 graphics primitive}],\\
\end{array}</div></html>
It would be better to observe that each element of this list is a
graphics object
and in that case make a graphics arrow (or something!) out of it.
I would support adding that feature if you think it would be useful.
By the way,
sage: implicit_multiplication(True)
sage: 2x + 3cos(x)
3*cos(x) + 2*x
now works in sage-2.10. You might be interested, since you were one of the
people to request it.
>
> >
> > 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!
Wow you have an extremely interesting point there. The "99% of people" who
just want something that is insanely easy to use are in point of fact willing
to sacrifice speed (and features) in exchange for getting something done very
quickly without any frustration. This is something we should always keep
in mind, but not take it too far (like Maple does).
> 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
-~----------~----~----~----~------~----~------~--~---
