Mailman 3 November 2006 - Edu-sig

pygeo, vpyython stats
by Arthur Nov. 11, 2006

Nov. 11, 2006

FWIW - Just to get some bearings I just looked at some sourceforge download statistics for pygeo and for vpython. PyGeo VPython Nov 2006 31 24 Oct 2006 113 144 Sep 2006 112 160 Aug 2006 90 193 Jul 2006 114 132 Jun 2006 133 575 May 2006 120 72 Apr 2006 119 43 Mar 2006 118 62 Feb 2006 110 66 Jan 2006 136 53 Both numbers are meager by many standards, but I am not disappointed in PyGeo's, in that I have purposefully refrained from promoting it an iota for over 3 years, other then discussion of it here, and only here. My thinking is that I will only promote it when it is complete, in the sense of suitable for a general audience, e.g.well-documented, and having its own editing environment as part of the distribution. And that will be when that will be. Since I don't consider there to be any competition for it - it's kind of its own thing - I don't feel under any enormous pressure. But having trouble making sense of the statistics above, since PyGeo requires vpython and the PyGeo site points folks to the vpython download site. In many months there are more downloads of PyGeo than Vpython, which either means that folks are downloading PyGeo without understanding the dependencies, and giving up, or that PyGeo is being downloaded as an add-on to existing Vpython installations. Or that the statistics are unreliable for some other reason that is not apparent. Assuming the statistics are meaningful , it does seem fair to conclude that PyGeo is a very major factor in generating interest in Vpython, to the extent such interest exists. Where I go with that info, not sure. Art

2 3

forking vpython????
by Arthur Nov. 7, 2006

Nov. 7, 2006

For the record: I have made my peace with Bruce Sherwood, the physics professor who administers the the vpython project. Anyone listening in on visual-python list can see that our recent interactions are quite cordial- as are the private interaction we have recently had. He and Ruth Chabay are hard at work meeting a deadline for a second addition of "Matters and Interaction" http://www4.ncsu.edu/~rwchabay/mi/ which is seems to me is an innovative introductory physics textbook, and an innovative use of Python, via VPython, in education. That being said: The possibility that I will approach my contributions to vpython as a fork, rather "joining" the project seems strong. a) I am frustrated with the pace of feedback to my efforts to contribute, and in fact there is no one currently committed to the project very qualified to evaluate those efforts. b) I am upfront about my lack of C++ expertise, and shy from the responsibility of making contributions in an environment where the program is being used in a growing number of college curricula and where there is not the expertise to vet those contributions, however: - PyGeo exercises vpython extensively, and has developed a fairly extensive set of tests (of a kind). I am satisfied to consider my vpython-fork code as production quality to the extent those tests are passed. OTOH, those test are not designed explicitly to test vpython, and I can understand a decision that they are inadequate for this purpose. c) In going through the vpython code I am finding a lot of undocumented features, and a lot of easy extensions. There are, for example, a number of functions on vectors and vector methods that are already written and used internally. There are written and used internally because they are of the kind that are useful in 3d mathematics. The boost.python framework is there, allowing them to be exposed to Python trivially - one line of code. The availability of these functions and methods would add performance to PyGeo. Not sure I want to have to debate the point with anyone as to why they have not been exposed, and whether they should be. Would like to be in a "just do it" position. There are whole other structures - vector_arrays and scalar_arrays - that have been exposed to Python, but, are incomplete and therefore totally undocumented. Completing and extending them, I am feeling now, is within my capabilities. I would like to get on with it outside of committee type discussion. d) VPython_main is free to access my forked versions and make their own decisions on which changes I have made to incorporate, and which not. I think I prefer not to be in that direct loop or advocating for this change or that - as to VPython_main. Wonder if anyone here has any thoughts on this. Art

1 0

Truth values and comparisons
by Arthur Nov. 6, 2006

Nov. 6, 2006

Looking for a little education on edu-sig. On one hand I am feeling like a big boy, having announced today on the vpython list that I think I have adequately accomplished the necessary fixes to the vpython C++ code to accomplish compatibility with the newly released numpy 1.0, and in a way that I think in the end (it was a round-about process for me) is straightforward and unlikely to introduce bugs into the existing stable codebase. OTOH, I am learning there is some very basic Python I do not understand. Now having a vpython that runs against numpy, I am learning about some of the changes in the numpy Python API versus that of Numeric and numarray. One basic incompatibility is in that the older libraries did something to give a result in comparing 2 arrays that numpy backs away from - complaining about ambiguity. For example, in the vpython faces_heightfield.py demo there is a line: >>>normal[i] = vertex_map[tp] and norm( vertex_map[ tp ] ) which ran fine under Numeric and numarray, and now fails with a message: """ The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() """ For the purposes of the exercise assume that both "vertex_map[tp]" and "norm( vertex_map[ tp ]" each return one dimensional, 3 element numpy arrays. Not exactly true, but I think the result would be the same if it were. In the original code, what is the "and" doing, and in what way might the "any" or "all" built-ins be used to get the result intended by it? Art

5 10

Vpython 4.0
by Arthur Nov. 5, 2006

Nov. 5, 2006

Making a long story as short as I can: Taking on the project of getting vpython to numpy compatibility (think I got there) brought me for the first time to a serious look at vpython 4.0 beta, which I had been avoiding, knowing it was buggy. Bugs, aside - turns out it is a major step forward, implementing transparency, texturing, advanced lighting, among other cool features - including some undocumented features that are intended to make vpython accessible to other GUI toolkits (from what I gather). Anybody interested might run the texture_and_lighting.py demo to get a feel for some of the new capabilities. Very cool. The only deal killing bug seems to be the one related to mouse.getclick() crashes, on Windows. So I thought I'd have a look, getting quickly way over my C++ head, finding that a mouse click event involved code that included shared pointers, signals and slots, threads,and the direct manipulation of the Python GIL. Way over my C++ head. I tried to follow the code and on a gander decided to see what would happen if I cut out the direct Python gil manipulation, having some clue/instinct that there was some conflict between that and what the boost::shared_ptr library was doing in managing object life cycles. And with that one change (simple changing a call from "py_pop" to "pop" to short-circuit going into the gil code), the demo that was consistently crashing, the diople.py demo, now seems stable Which of course seems too good to be true, because presumably Jonathan Brandmeyer, the CS student author of this, had some specific reasons to be messing with the Python gil, and I don't know what I may be breaking, on what platforms, by my fix, if it is in fact a fix at all. Or else I'm a genius, or lucky, or something. Anybody willing to jump in here, to any extent, to have a look see? Art

2 3