On 3/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Well, philosophically, I could see where a lot of CS types might have > > a problem with mutable numbers, complex or otherwise. > > Are you a CS type? If so, speak directly. >
I flirt with the idea, but feel more drawn to American Literature. Hoping for some honorary degree from UC Santa Cruz maybe, or Berkeley even. > If not, why do you feel compelled to speak on their behalf. > I'm volunteering this information. I read a lot of CS type stuff and know that Guido finds mutable strings an abomination in Ruby. Mutability must be tastefully applied. Doing it to a primitive number type should at least be on the table for discussion, even in polite company. > As an OOP devotee I am surpirsed you find this as much of an issue as you > seem to. > I've written polyhedron, vector and modulo integer types, and generally come to wanting to return a new object as the result of any operation, even rotations in the case of polyhedra. I'll use reassignment to save namespace, but I prefer mypoly = mypoly('X', 90) over mypoly('X',90) and a side-effect. > My complex number is an old fashioned object. For my purposes - destroying > it and > recreating another every time a value changes is wasteful, (and cruel ;)) > "Old fashioned object" isn't clear enough. It's as easy to return a new object as not. Neither approach is intrinsically "old fashioned". Look at strings. 'kirby'.uppercase() returns the string 'KIRBY'. If I want to keep the result, I need to assign it a reference. That's how primitive numbers behave too. -2 .__invert__() returns 3, doesn't alter -2 in any way. > Instead of having my geometric objects of the complex plane *be* complex > numbes, > there is certainly the solution of having a complex number as an attribute of > these objects It'd see that as a separate issue. Even if you demote the identity to an attribute, you're still not compelled to implement that much mutability. > and then I can take more your approach, and at the speed of C, since I would > then > be using the built-in for arithmettic operations. > > There remained something unsatisfying to me about that approach. > > Until something blows up about my current approach, I am quite happy with it. > That's what I was asking. Do you feel compelled or are you more just freely experimenting with an approach that gives you pleasure. I think you've answered my question. I'm only giving substance to my adjective "quirky". It's OK to be quirky and have fun, in my book anyway. > And if and when something does blow up, I will know what it is and will have > developed some *real* expertise on the problem of mutable complex numbers, > beyond > the fear of distrubing the sleep of some abstract CS type. And will report > back in. > Fair enough. Just be aware of the many skeptics in your audience, who'll think you're off on some wild goose chase in search of a superior paradigm. > At the moment I don't expect that to happen - but my mind is open - as it has > been from > the beginning - to the possbility that I have made a wrong turn here. > > Art It all depends on your goals. If your goal is a working PyGeo with code your well understand, then the mutable complex number may be no hindrance at all. If your goal is to get your source code studied in CS departments, as exemplary of how to go about coding such a VPython app, that'd be a different challenge. Probably why I'm drawn to American Literature is I think that's where my own brand of quirkiness will find more acceptance. I *do* want to have my fun and need a fair amount of freedom to do so. Likewise in the Python community, I'd hope fun experiments like yours get a lot of latitude to just develop as they develop. You'll solicit feedback, sure, but there's nobody here pretending to be your boss in any way. Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig