I don't know whether this is theoretical, philosophical, or in any way relevant to what we are *supposed* to be discussing here - but to break what I consider to be an uncomfortable silence I thought I'd throw it out into the excess bandwidth, nonetheless: I do in fact use properties in various places in my code, and but not generally in ways I find compelling or truly functional - maybe some nuance of "interface" that I could easily live without. I seem , however, to have come across my first more compelling use case. I went with the creation of a mutable complex number type, which I then inherit from and use down the line. But when I send instances of classes derived from this custom type to use as elements of a Numeric Userarray, there is no way that I have found to be able to tell Numeric that if it treats these instances as if they were built-in complex numbers, things should work out OK. Numeric seems to insist on creating arrays of Python instances, and then insists it does not know how to do math with Python instances. So properties come in handy essentially to do casting - from the custom Complex type to the built-in complex type on the way into the UserArray, and in reverse on the way out - i.e, set and get. This only additionally meant customizing the Numeric UserArray to derive from object (it doesn't come that way) , before I go further with it, so that properties "take". I am sure I am taking at least a bit of a performance hit by going this route. Does anyone see something simple I may be missing here to get to where I am trying to get, without the hit? Art
I am sure I am taking at least a bit of a performance hit by going this route. Does anyone see something simple I may be missing here to get to where I am trying to get, without the hit?
Art
Sounds like the kind of question that should go with example code, but maybe that's just me. Kirby
kirby urner wrote:
I am sure I am taking at least a bit of a performance hit by going this route. Does anyone see something simple I may be missing here to get to where I am trying to get, without the hit?
Art
Sounds like the kind of question that should go with example code, but maybe that's just me.
What it seems to be is mostly a question of a limitation in my understanding of what means type(xxx). I want to create a class that impersonates a built-in type - in my case <type 'complex'>. And in fact am working from pypy code that not only impersonates <type 'complex'>, but within the pypy implementation, *is* <type 'complex'>. How does pypy get there? My motive is simply to con Numeric into a willingness to treat my implementation of the complex number type - the mutable one - on the same basis that it treats the built-in immutable one. Is there a mechanism to con Numeric here? Art
Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Is there a mechanism to con Numeric here?
Art
I'm interested in your question and therefore presumably in the answer. However, I'm not running Numeric these days, for the simple reason that it's not currently a part of my Python curriculum. We create a matrix object, maybe a quaternion object, in order to rotate our polyhedron objects (assemblages of face-defining tuples, each element a vertex in a dictionary of vectors -- e.g. the 26 A-Z of the concentric hierarchy): http://www.4dsolutions.net/ocn/oop7.html (see graphic top right). So I don't need linear algebra from Numeric at this time, nor any of its other resources. Not saying I won't in future. Numpy is cool stuff. Kirby
kirby urner wrote:
Is there a mechanism to con Numeric here?
Art
I'm interested in your question and therefore presumably in the answer. However, I'm not running Numeric these days, for the simple reason that it's not currently a part of my Python curriculum.
Appreciate your interest. I think it is an interesting question in that it in some sense represents a clash between "technical" typing and duck typing. My mutable complex number quacks (almost) exactly like the immutable one, and usually in Python that might be enough to have it accepted as being of the same type. Numeric seems to be catching me on a technicality. Technology seems to full of the damn things ;) The array object of Numeric is actually the C multiarray object. And Numeric is perhaps thinking more in C than in Python in using a technical rather than functional definition of type. Unfortunately it seems to be a bit too daunting to me to attempt to follow the trail into the C code to try to track down the error that's generated when I (innocently ;) try to cast an array of the mutable complex numbers to the Numeric complex array type. Neither have I tried yet to see if the more recent numarray and numpy libraries behave any differently here.
We create a matrix object, maybe a quaternion object, in order to rotate our polyhedron objects (assemblages of face-defining tuples, each element a vertex in a dictionary of vectors -- e.g. the 26 A-Z of the concentric hierarchy):
http://www.4dsolutions.net/ocn/oop7.html (see graphic top right).
So I don't need linear algebra from Numeric at this time, nor any of its other resources. Not saying I won't in future. Numpy is cool stuff.
I actually think your way is best to achieve ultimate transparency for pedagogical purposes, even at the sacrifice of performance. I am more and more thinking that a good deal of Numeric is overkill for my purposes as well - sacrificing transparency for what is probably not tremendous performance benefits when I am dealing only in 2x2, 3x3 and 4x4 arrays. Since Numeric is designed as a general use library, it needs to spend some time determining what it is looking at when, for example, doing linear algebra - what shape are the arrays it is looking at, what type, etc. In the controlled environment that I am working in in PyGeo I know what I am sending along, so I think I can gain some of the time back that I would be loosing in going from C to Python simply because I can design things in a way where little is general, everything is specific - we know what we are getting because we are sending it. Have been experimenting with all this, as it happens. Art
Kirby
Arthur wrote:
I actually think your way is best to achieve ultimate transparency for pedagogical purposes, even at the sacrifice of performance. I am more and more thinking that a good deal of Numeric is overkill for my purposes as well - sacrificing transparency for what is probably not tremendous performance benefits when I am dealing only in 2x2, 3x3 and 4x4 arrays. Since Numeric is designed as a general use library, it needs to spend some time determining what it is looking at when, for example, doing linear algebra - what shape are the arrays it is looking at, what type, etc. In the controlled environment that I am working in in PyGeo I know what I am sending along, so I think I can gain some of the time back that I would be loosing in going from C to Python simply because I can design things in a way where little is general, everything is specific - we know what we are getting because we are sending it. Have been experimenting with all this, as it happens.
Art
Just thought I'd throw out the tool I am using for my "experiments". Python Performance Validator - an (expensive) commercial product to be found at http://www.softwareverify.com/ Working with a free fully functional 30 day trial version, seeing what I can learn about my code with it before it expires, and then will probably be left to other tools, as I can't justify its cost for my purposes. But at least I can give them a plug. I have found profiling, formal debugging, etc. somewhat complicated by the fact that I am working with a graphical and dynamic application. Not that that's so unusual a situation to face, but some of the issues that arise seem to me to come under the category of Profiling 103, and I never got through 101. This tool has helped me get my bearings. Art What it solves for me is the problem of separating performance issues, e.g. start-u
Kirby
----- Original Message ----- From: kirby urner <kirby.urner@gmail.com> Date: Thursday, March 16, 2006 5:04 pm Subject: Re: [Edu-sig] Properties use case
The idea of a "mutable complex number" gives me the creeps. Did you say you'd seen this successfully tried somewhere?
Don't lose any sleep over it. Yes. PyGeo. Art
The idea of a "mutable complex number" gives me the creeps. Did you say you'd seen this successfully tried somewhere?
Don't lose any sleep over it.
Yes.
PyGeo.
Art
Sorry you felt forced into doing something quirky for whatever reason. Or maybe it's just for the fun of it, experimenting with new ideas. Lots of good comes from experimentation, trial and error. I'm not being critical, just leery i.e. is this a sandbox I could play in? A lot of people ask the same questions about mine, with quirky sand-castles aplenty (I love sand). Kirby
----- Original Message ----- From: kirby urner <kirby.urner@gmail.com>
The idea of a "mutable complex number" gives me the creeps. Did you say you'd seen this successfully tried somewhere?
Don't lose any sleep over it.
Yes.
PyGeo.
Art
Sorry you felt forced into doing something quirky for whatever reason. Or maybe it's just for the fun of it, experimenting with new ideas.
Just looking for the most elegant solution to my problem- nothing quirky intended. Except that I am consciously here, as elsewhere, sacrificing some measure of performance in the interest of my own sense of elegance. I guess one could argue that scarificing performance for an application where performance *is* an issue cannot be elegant. Depends what one is after, I guess. Are there people out there with a more developed sense of elegance in programming than I have been able to develop? No question. But it ain't like I am inheriting from float to redefine =, or anything ;) Or throwing properties aropund willy nilly. Art
Lots of good comes from experimentation, trial and error.
I'm not being critical, just leery i.e. is this a sandbox I could play in?
A lot of people ask the same questions about mine, with quirky sand-castles aplenty (I love sand).
Kirby
Just looking for the most elegant solution to my problem- nothing quirky intended.
Well, philosophically, I could see where a lot of CS types might have a problem with mutable numbers, complex or otherwise. Usually, some complex number s would be operated on by a function g, to return new complex number g(s). This idea that g(s) might return null or something, while meanwhile s itself has changed, is usually not considered so elegant. Even s = g(s) i.e. reassignment of s to a new value, is better than g(s) producing a side-effect, i.e. a change to s itself -- where s.g() would be another way to say it. You'll hear the word "quirky" applied to this latter pattern. Usually means: "hard to debug" (reassignments are easier to catch than implicit changes in memory). Kirby
----- Original Message ----- From: kirby urner <kirby.urner@gmail.com> Date: Thursday, March 16, 2006 9:38 pm Subject: Re: [Edu-sig] Properties use case
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. If not, why do you feel compelled to speak on their behalf. As an OOP devotee I am surpirsed you find this as much of an issue as you seem to. 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 ;)) 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 - 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. 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. 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
----- Original Message ----- From: ajsiegel@optonline.net Date: Friday, March 17, 2006 10:05 am ----- Original Message ----- From: ajsiegel@optonline.net
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 - 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.
Eureka - potentially. Michaels' comments about using a Numeric array as my mutable number, together with my own efforts to justify my current architecture from your doubts... All my geometric objects of the complex plane, points, lines and circles have an associated 2X2 Hermitian matrix as an attrbute. This is what allows me - for example - to do transformations on an abritrary set of objects. They all can quack out a Hermitian matrix, and therefore can be treated as one "type" for the purposes of certain processes. A level of abstraction up from where I am right now -- perhaps the better architecture is to have all my complex objects *be* (derived from) this 2x2 matrix. This - although not the motive - would probably allow me to in fact put my mutable complex number to sleep. And help others' sleep ;). This might have to be psuedo-inheritance via an UserArray mechanism - until it becomes clearer to me if there is in the newer array libraries a way to do true inheritance Something that feels right about this at the moment. Will report back in. Art
On 3/17/06, ajsiegel@optonline.net <ajsiegel@optonline.net> 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
----- Original Message ----- From: kirby urner <kirby.urner@gmail.com> Date: Friday, March 17, 2006 1:17 pm Subject: Re: [Edu-sig] Properties use case
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.
As it happens I have an *actual* degree in Literature from a school in that neighborhood - San Francisco State. Not an academically honered department, but certainly an interesting one - folks who hung with Andre Beton and the Surrealists in Paris in their heyday, etc. But for us to argue over things we actually know something about would be so much less entertaining ;).
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.
I feel neither compelled, or that I am experimenting. I am trying to solve problems, though some of those problems have an aesthetic component as well as a functional component. I can't think outside the box, having no good idea where the box is to begin with. Art
Arthur:
Are you a CS type? If so, speak directly.
I'm a CS type (BS in CS, MS in CSEE). Kirby's right, it's generally considered "better" to return a new primitive type rather than mutate it in place. Many programming languages impose "striction functionality" which means you have no (or nearly no) mutable state at all, just returning new values. This can avoid many, many types of problems in programming, but isn't as friendly in some cases. For "better" in the first sentence above you can insert any of: faster, more stable, less error-prone, and frequently more readable. Arthur:
If not, why do you feel compelled to speak on their behalf.
Kirby:
I'm volunteering this information.
And therein I think we have the nub of the frequent Arthur/Kirby semi-argument. My impression is that Kirby often offers suggestions and information, and Arthur interprets this as telling him what to do and pushes back. No idea what to do about this, just pointing it out. Arthur:
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 ;))
Wasteful how? By implementing your own complex type and ignoring the built-in one you are wasting memory, speed, and (arguably) your time. The bytes that are thrown away when an existing complex object is reclaimed are treated humanely and given a decent recycling to emerge as new objects. Where is the waste? Kirby:
That's how primitive numbers behave too. -2 .__invert__() returns 3, doesn't alter -2 in any way.
I hadn't noticed the __invert__ method before so I tested this: -2.__invert__() gave a SyntaxError (-2).__invert__() gave 1 (2).__invert__() gave -3 Just to be pedantic about it. %-)
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.
That about sums it up. You can make up you're own types to your hearts content: mutable ints and floats if you want. It can be a good learning experience, as long as you're not trying to to pass it off as a best practice. --Dethe
----- Original Message ----- From: Dethe Elza <delza@livingcode.org> Date: Friday, March 17, 2006 6:08 pm Subject: Re: [Edu-sig] Properties use case
Arthur:
Are you a CS type? If so, speak directly.
I'm a CS type (BS in CS, MS in CSEE). Kirby's right, it's generally considered "better" to return a new primitive type rather than mutate it in place.
What defines a "primitive type". My understanding is that in many languages there is no complex primitive type. Perhaps it is a bit less primitive, and that the thinking about, say, floats does not apply, one-to-one, about thinking about complex numbers.
And therein I think we have the nub of the frequent Arthur/Kirby semi-argument. My impression is that Kirby often offers suggestions and information, and Arthur interprets this as telling him what to do and pushes back. No idea what to do about this, just pointing it out.
How about the rub of the Dethe/Arthur dynamics. You think I am being a wise guy, when I think I am being an iniquisitive student - I think. Art
What defines a "primitive type". My understanding is that in many languages there is no complex primitive type.
Each language defines its own primitive types, some have no primitive types (or hide them better), some are more primitive than others. In Python, complex numbers have an implementation which is coded in C and quite fast compared to anything achievable in pure Python.
Perhaps it is a bit less primitive, and that the thinking about, say, floats does not apply, one-to-one, about thinking about complex numbers.
In the sense that they are not based on hardware-implemented types that's true. In the sense that they are "special" in Python (i.e., faster and more efficient than user-created types), then they are still primitives.
How about the rub of the Dethe/Arthur dynamics. You think I am being a wise guy, when I think I am being an iniquisitive student - I think.
I understand that you're an inquisitive student, but the style you respond in is often more aggressive than inquisitive, as far as I've been able to observe. Nothing wrong with challenging the status quo, or whatever, but it does tend to squelch participation on the list at times, especially from members who are less thick-skinned (or patient) than Kirby. Just saying. --Dethe
----- Original Message ----- From: Dethe Elza <delza@livingcode.org>
What defines a "primitive type". My understanding is that in many languages there is no complex primitive type.
Each language defines its own primitive types, some have no primitive types (or hide them better), some are more primitive than others. In Python, complex numbers have an implementation which is coded in C and quite fast compared to anything achievable in pure Python.
Obviously once I become convinced that the mutable complex numbers happens to work for my purposes, there is nothing preventing me from implementing as an extension in C. Would that put the issue to bed? What - pedagogically - do you imagine you are communicating to me by telling me that *this* is generally considered better than *that*. Nakedly - pretty much nothing. And it would be easier to converse, no doubt,l if we all felt we were listening to each other. You always seem to be listening with half an ear. I said in the course of the discussion - maybe 3 times - that I understood that I was giving up performance, and that I could understand an objection on that basis, but for where I am going - knowing for example that a C extension is always doable - that I wasn't going to let that be short-term decisive. You come back to me explaining to be that I am giving up performance. Yeah. I know.
I understand that you're an inquisitive student, but the style you respond in is often more aggressive than inquisitive, as far as I've been able to observe. Nothing wrong with challenging the status quo, or whatever, but it does tend to squelch participation on the list at times, especially from members who are less thick-skinned (or patient) than Kirby.
Kirby understands. I am from New York ;) You seemed married to Arthur as the desruptive bad guy. I don't buy it, but don't expect to change your mind either. Art
Obviously once I become convinced that the mutable complex numbers happens to work for my purposes, there is nothing preventing me from implementing as an extension in C.
Of course.
Would that put the issue to bed?
No particular issue. Kirby said something, you challenged it, I'm putting in my CAD$0.02. You can reimplement python in python if you want (and you wouldn't be the first).
What - pedagogically - do you imagine you are communicating to me by telling me that *this* is generally considered better than *that*. Nakedly - pretty much nothing.
Thought I said that--faster, less memory, more readable, y'know, because you asked.
And it would be easier to converse, no doubt,l if we all felt we were listening to each other.
Oh, I mostly listen. Sometimes I stop listening when the thread goes on too long without going anywhere. On rare occasions I jump in. Coming to regret doing that, going back to lurk mode now.
You always seem to be listening with half an ear.
Hmm. I wonder which half?
I said in the course of the discussion - maybe 3 times - that I understood that I was giving up performance, and that I could understand an objection on that basis, but for where I am going - knowing for example that a C extension is always doable - that I wasn't going to let that be short-term decisive.
Yes, I know, I read that. I'm not questioning that you know this. You asked what problems from a CS viewpoint there would be. I told you. You don't like it, don't ask.
You come back to me explaining to be that I am giving up performance.
Which you knew, but you asked. Performance is a nebulous word by itself. I tried to clarify--adding mutable objects is unlikely to save *either* memory *or* speed. Your mileagle may vary, of course.
Kirby understands. I am from New York ;)
Yeah, I'm from Tennessee, but I don't speak from there. And I don't use it to justify being confrontational.
You seemed married to Arthur as the desruptive bad guy.
Nope, perfectly willing to be shown otherwise. On the other hand, folks have dropped off the list, or threatened to, in part because of your attacks on other posters. Just because I'm de-lurking to point this out doensn't mean I'm the only one who feels this way (although maybe the only one still around, dunno).
I don't buy it, but don't expect to change your mind either.
Damn. I wish you would. I'd really like to have my mind changed on this. I truly would.
Art
--Dethe
----- Original Message ----- From: Dethe Elza <delza@livingcode.org>
Yes, I know, I read that. I'm not questioning that you know this. You asked what problems from a CS viewpoint there would be. I told you. You don't like it, don't ask.
Its not that I'm a bad guy. Must be that I'm just stupid. I still don't understand what I have been told from a CS standpoint. Beyond that one Computer Scientist doesn't particularly like me. But I knew that already, as well. Art
The last thing I want is to start up this thread again, but I have not been paying attention to edu-sig for awhile and when I came back I found some things I need to address.
Yes, I know, I read that. I'm not questioning that you know this. You asked what problems from a CS viewpoint there would be. I told you. You don't like it, don't ask.
Its not that I'm a bad guy.
I know that, and have never called you one. I tried to address a specific issue, i.e.: Arthur to Kirby: Are you a CS type? If so, speak directly. If not, why do you feel compelled to speak on their behalf. Sorry if I'm mis-reading that, but it looks to me like "shut up," which I find offensive, even if Kirby doesn't. Perhaps it bothered me more because of this other recent posting: Arthur to Vern: Are you an appointed or self-appointed redactor of all that is Turtle in the world of Python? Which again, appears to be more of an attack than any attempt to move the conversation forward. Maybe that is just me?
Must be that I'm just stupid.
You and I and the rest of the list know you are not stupid, so why self-deprecate?
I still don't understand what I have been told from a CS standpoint.
Well, I was trying to give a short answer, but others have since chimed in with more detailed explanations far better than mine, so I will leave this alone.
Beyond that one Computer Scientist doesn't particularly like me.
I assume you mean me, but rest assured that I do like you. If I didn't, I would not have bothered.
But I knew that already, as well.
That's too bad, and I feel like my communications have failed rather completely if you believe that.
Art
So, Art, I apologize for my poor communications with you. Obviously what I've had to say did not come across the way I intended it, and I'm sorry for that. I don't bear you any ill will, and I certainly don't care one way or the other how you implement complex numbers in your apps. It was also a mistake on my part to try to address both a communication issue on your part that I had trouble with at the same time as addressing the question you had about your code--I should have separated those issues (or just not gone there at all). I certainly did not intend to come across as condescending or rude to you. I hope we can move on now (and not awaken the mutable-complex permathread). --Dethe
----- Original Message ----- From: Dethe Elza <delza@livingcode.org>
Arthur to Kirby: Are you a CS type? If so, speak directly.
If not, why do you feel compelled to speak on their behalf.
Sorry if I'm mis-reading that, but it looks to me like "shut up," which I find offensive, even if Kirby doesn't. >
I wasn't asking Kirby to shut up, nor do I think he took it that way. What I was asking him to do was to talk in a voice that was unambigiously his own. Its complicated enough to talk with Kirby, without a sub-text of having a conversation with other people who aren't Kirby, through Kirby - or that at least is what I was trying to say.
Perhaps it bothered me more because of this other recent posting:
Arthur to Vern: Are you an appointed or self-appointed redactor of all that is Turtle in the world of Python?
Which again, appears to be more of an attack than any attempt to move the conversation forward. Maybe that is just me?
Its not just you. Its me. I was inappropriate, owned up to having been inappropriate, and apologized. That's all I could think to do. Happens to me every decade or so ;).
So, Art, I apologize for my poor communications with you. Obviously what I've had to say did not come across the way I intended it, and I'm sorry for that. I don't bear you any ill will, and I certainly don't care one way or the other how you implement complex numbers in your apps. It was also a mistake on my part to try to address both a communication issue on your part that I had trouble with at the same time as addressing the question you had about your code--I should have separated those issues (or just not gone there at all). I certainly did not intend to come across as condescending or rude to you.
I appreciate your communication here very much. Thnks, Art
I appreciate your communication here very much.
Thnks,
Art
Good work, both of you. I look forward to archived v-lists (video lists). I don't know how they'd work exactly, but the bandwidth would be a lot higher. People who're already on the same page could get by with edu-sig type communications probably. But if the going got rough, we'd switch to a v-list and try to sort it out in a more personal and personable way -- but still archived in such a way others could lurk in on, like here. Actually, I'm just describing television, aren't I (except the archiving feature is still immature, unless you're lucky enough to have easy access). We should all get on TV somehow, not necessarily in real time -- like I've got a Google Video up, doing some of my schtick as a Fuller Schooler: http://video.google.com/videosearch?q=polyhedra Career diplomats distrust cyberspace with good reason. They know there's no substitute for in-person direct contact sometimes. But that's my point: it's not either/or. And increasingly, cyberspace is addressing its bandwidth deficiencies. Computers and TV are increasingly becoming two aspects of the same animal. For the record: I've met Arthur in person a couple of times, both times enjoyable. He referred to omelets -- this was in up town Manhatten, and I have a relevant blog entry from that same time: http://mybizmo.blogspot.com/2005/05/tree-house.html I've not met Dethe nor most of the others active on this list. I'd love to of course. Jeff Elkner I've met at Pycon, though we've not had any in-depth discussions (plus Jeff hasn't posted in I don't know how long). Jason Cunliffe has gone off to France I understand (he and I met in New York City as well, some years ago). I've seen Laura in action at OSCON and EuroPython, but any direct discussion has been mostly by elist and email. I'm not saying we should all keep careful track of all this who's met who stuff. I just wanted to acknowledge that it changes/influences the chemistry of on-line edu-sig communications to some degree. Limited bandwidth is a reality. Passionate thinkers are sometimes the most vulnerable to this "feature" (of limited bandwidth). They really deserve more air time (TV time), just so we (the audience) might get a clearer picture of who we're dealing with and what actually is going on. How many threads on edu-sig might simply end overnight, were we to have an edu-sig conference? How many new ones, perhaps more fruitful ones, might get started? Hard to say. We may get to find out. Kirby
On 3/17/06, Dethe Elza <delza@livingcode.org> wrote:
Nope, perfectly willing to be shown otherwise. On the other hand, folks have dropped off the list, or threatened to, in part because of your attacks on other posters.
My interest in justice has overwhelmed my interest in discretion. I have followed the present discussion closely and think the above does not match my experience. Being new here, I have no idea of prior history. This is the first significant thread I have followed on this list. With that caveat I feel compelled to say that in the context of the current discussion I saw Arthur ask questions in a straightforward way, and get very little help and lots of wildly off-topic nitpicking digression laced with argument from authority and a snarky attitude. I saw nothing of him attacking any other poster, and think he has been relatively patient given the tone of the responses. In the not unlikely event that I stop paying any mind to this list as a consequence of the present discussion, I feel compelled from a sense of fairness to say that it will *not* be because of anything I have seen in Arthur's behavior. mt
ajsiegel@optonline.net wrote:
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 - 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.
The thing that typically blows up is when you are (for example) computing with a complex number that is changed halfway through the computation by another thread (say a mouse drag). The square root winds up being neither the square root of the original number nor of the new changed number. Further, it becomes dicey to try to prove that your square root function will always terminate (a step size from one that is guaranteed to settle might be a disaster at the new-improved value. So, that's why CS people like immutable primitive types. -- Scott David Daniels Scott.Daniels@Acm.Org
Thank you for a refreshingly terse and substantive comment! Let's have more of those! mt On 3/17/06, Scott David Daniels <Scott.Daniels@acm.org> wrote:
ajsiegel@optonline.net wrote:
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 - 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.
The thing that typically blows up is when you are (for example) computing with a complex number that is changed halfway through the computation by another thread (say a mouse drag). The square root winds up being neither the square root of the original number nor of the new changed number. Further, it becomes dicey to try to prove that your square root function will always terminate (a step size from one that is guaranteed to settle might be a disaster at the new-improved value.
So, that's why CS people like immutable primitive types.
-- Scott David Daniels Scott.Daniels@Acm.Org
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Scott David Daniels
So, that's why CS people like immutable primitive types.
I believe you. But if we trace back the thread we will see that the bottom line question that I was struggling with at the beginning was precisely the question of what *makes* a primitive type such. Obviously something much deeper than the fact that it is coded in C. But let's leave it alone though, because at the moment, among other things - for the practical purposes for which I raised the issue (and as a Naïve Programmer, that is my focus) - it seems to be moot. Ten posts back or so I had tried to communicate that through Kirby's prodding and Michael's suggestive remarks, I had begun to see an approach that I had not before considered that might solve the issue I consider myself to be facing in a manner that was more satisfactory - not only to the CS world - but to myself. This was *after* I complemented Kirby on the transparency of his approach and suggested that I was trying to emulate such an approach more thoroughly. But - and this is what particularly confused me - before he declared the idea of a mutable complex number - I think the technical term was - "creepy". Let's just go to sleep. Art
Arthur wrote:
... But if we trace back the thread we will see that the bottom line question that I was struggling with at the beginning was precisely the question of what *makes* a primitive type such. Obviously something much deeper than the fact that it is coded in C.
Well, if it hadn't been buried in a hail of words, it would have been more obvious to the readers as well as the writer. I'll try to talk from the point of view of a language designer. Typically, a computer language is developed to solve some kind of problem (or family of problems). The primitives must be enough to express, succinctly, problems in that space and parts of solutions to those problems. You'd be surprised at the variety of things people want to express. It used to be commonly accepted that "little languages" was the way to attack this problem. A new problem space meant building a "little language" to express its problems and solutions. However, it turns out that these "little languages" have this "feeping creaturism" problem; the users often want "just a bit more" added until the language (which was once nice and small and tidy) seems to be all bolts and knobs and corners where unanticipated extensions got thrown on to solve "just one problem." Also, the number of people capable of building, supporting, and extending a language is not huge in comparison to the number of problem spaces. Experience in building languages has shown us that the more "distinct" things in the language, the harder it is to learn, use, and remember. Here I am not talking about the complexity of the compiler/interpreter/language translation system, but the amount of "stuff" a _user_ of the language needs to know about the language. The fewer things a user has to track mentally, the "simpler" the language. So, here is a tension: we want a simple language that can express succinctly problems and (effective) solutions to problems. The simpler the language, the more quickly you can become expert in the language, and move on to the problems you really want to solve. The more expressive the language, the simpler your programs in your field of discourse. We do know that program complexity grows _significantly_ worse than linearly with the size of a program, so we want the programs the user writes to be small to help him out. Often adding more to the language shrinks the users code, so there is a balancing act here. Here are some criteria for primitives. We want as few primitives as possible. We should add primitives for anything almost every user will need. In addition to those, we may add some primitives for those things that the user cannot build himself nearly as efficiently (or perhaps is very likely to get wrong). We probably need primitives for every "manifest constant" in a program (the 5 in "i *= 5"). Almost always, programs need a way to perform I/O (Knuth, in one class defined a computer program as something that took zero or more inputs and produced one or more outputs, on the grounds a rock implements anything that produces zero outputs). But programs that simply produce output, but consume no input are rare; ab initio chemists may write some of these. Usually the programs are to be operated by people other than those who wrote the programs, so they must consume input in some form. Input, output, and calculation all need to be expressed. Even if you have no intention of doing text processing, input and output almost force you to have a text type. Most calculation will want to do arithmetic (there are languages w/o arithmetic primitives). There must be a way to build data structures (combine our primitives), since the design and use of data structures is core CS (and the key to not having to build everything into the language). We need to be able to define functions (a way to decompose problems), and how functions and their results are combined is, finally, the probable answer to the mutability question. If every time you call a function it might mutate its arguments, safe practice is to copy any arguments to the function. Early FORTRAN said a procedure could change its arguments, and the change would be reflected in the calling program. So, after: pi = 3.1415297 somesub(pi, 3) the value of pi might be changed. Even worse, the program might change the value of 3 (the constant used in the compiled chunk of code for 3). The FORTRAN solution was to tell the programmer "don't do that." We now solve these problems either by using "pass-by-value" semantics (the subroutine gets a copy of its argument), or by passing immutable objects. So, it makes sense that manifest constants must be immutable in a language like Python that does call-by-sharing. Also you avoid another nasty problems called "aliasing". If you have a function like: def same_range(a, b): while a < b: a *= 2 while a >= b: a /= 2 return a Calling "same_range(lumberjacks, lumberjacks)" will make the second loop infinite because both a and b are aliases for the same object. That's no problem for immutables (one version is as good as another), but can cause surprisingly hard-to-find bugs. Note aliases are _much_ harder to detect than simply this case, and the results can be nasty. Some people have proposed that program have no side-effects to solve this, but others among us consider that absurd: a program models reality, and reality is mutable. There is no way to write to a printer and then abandon that calculation and move to another where the printer has not yet been written upon. So I've gone on at absurd length here to explain why immutable primitives are preferred. The reasons are subtle, and come from shared experience on building languages. This is why some of us study computer science; we are interested in such questions. It is frustrating sometimes to be asked a simple-to-ask question that seems combined with a "nasty CS elitists" attitude. There _is_ a body of work in CS, what it talks about is not trivial, and it builds on itself in a way that makes it hard to answer some questions succinctly. Some of the questions feel a lot like, "why so many planar surfaces in architecture;" to answer them requires work, not simply in the saying, but in looking back for the whys. Often the first answer "it makes my skin crawl" is the real answer; some rule has become so internalized you don't know why you feel it. It doesn't necessarily mean Kirby was saying you had done an incredibly stupid thing; it might simply mean that something about that as design felt dangerous to him in some way. --Scott David Daniels Scott.Daniels@Acm.Org
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Scott David Daniels Sent: Saturday, March 18, 2006 1:03 PM To: edu-sig@python.org Subject: Re: [Edu-sig] Properties use case
Arthur wrote:
Some of the questions feel a lot like, "why so many planar surfaces in architecture;" to answer them requires work, not simply in the saying, but in looking back for the whys. Often the first answer "it makes my skin crawl" is the real answer; some rule has become so internalized you don't know why you feel it. It doesn't necessarily mean Kirby was saying you had done an incredibly stupid thing; it might simply mean that something about that as design felt dangerous to him in some way.
From where I sit it looks that one might choose to express a 3 element vector as a tuple or one might choose to express is as a list, or even more
Can we allow this to be about the communication between teacher and student, and me be the student recognizing that the teacher has the knowledge he seeks, but frustrated... Because it is probably exactly my inability to phrase the question properly - I'm just a student - that leads to the problem. But if I was able to ask the question exactly properly, I probably wouldn't need to ask it - I would probably already have the answer. So I am recognizing that *I* am the source of the problem, in this sense. But that doesn't make the problem go away. Or allow us the say that the process is working. Intuitively, there is something qualitatively different - float as primitive, complex number as primitive. Simply a wrong intuition? Nothing lying beneath it? likely a mutable array. And while suspecting that one can get into religious arguments about the matter, in practice smart people can be found doing either or both. I don't understand, really, the distinction between a vector expressed as a list and a vector expressed as a tuple, from the concept of a complex number in mutable form, and one in immutable form. If you feel like trying to help... Art
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Arthur Sent: Saturday, March 18, 2006 1:39 PM To: 'Scott David Daniels'; edu-sig@python.org
I don't understand, really, the distinction between a vector expressed as a list and a vector expressed as a tuple, from the concept of a complex number in mutable form, and one in immutable form.
If you feel like trying to help...
Put another way, if I take the PyPy implementation of the complex primitive, and comment out the 2 property lines that restrict the write to real and imag - and instead of calling it a primitive I call it a class. And I use the class as such - where have I gone wrong? Art
Arthur wrote:
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Arthur Sent: Saturday, March 18, 2006 1:39 PM To: 'Scott David Daniels'; edu-sig@python.org
I don't understand, really, the distinction between a vector expressed as a list and a vector expressed as a tuple, from the concept of a complex number in mutable form, and one in immutable form.
If you feel like trying to help...
Put another way, if I take the PyPy implementation of the complex primitive, and comment out the 2 property lines that restrict the write to real and imag - and instead of calling it a primitive I call it a class. And I use the class as such - where have I gone wrong?
Art
OK, so as I said in my over-long thing, immutable types have an exciting property that you can't really tell aliases from copies. This makes Python's call method behave a lot like "call-by-value" -- a good thing, since call-by-value is easy to analyze (both for machines and humans). With mutables, you have the question of "caller-saves" or "callee-saves" in function calls. Caller-saves makes a copy to do the call with, and callee-saves makes a copy on function entry (at least for those args for which there will be mutation). Typically, a lot of effort (either by the compiler or the programmer) is expended to keep all of this copying to a minimum. With immutables, you needn't do any of the bookkeeping. It is not that you have gone terribly wrong; it is that you have opened the lid on a large class of avoidable problems. If you look at Java's strings (as I remember -- it has been forever since I studied Java at all), you will find they are mutable. You also find that Java code copies strings a _lot_, just to be safe against lower- level mutation. Your primitive complex (the mutable one) also could not be used as a dictionary key except by identity, which would not allow rapid access. --Scott David Daniels Scott.Daniels@Acm.Org
Scott David Daniels wrote:
copying to a minimum. With immutables, you needn't do any of the bookkeeping. It is not that you have gone terribly wrong; it is that you have opened the lid on a large class of avoidable problems. If you look at Java's strings (as I remember -- it has been forever since I studied Java at all), you will find they are mutable. You also find that Java code copies strings a _lot_, just to be safe against lower- level mutation.
Incidentally, Java's strings are immutable, too. Quote from "Head First Java" (p. 589): "For security purposes, and for the sake of conserving memory ... Strings in Java are immutable." Christian
Christian Mascher wrote:
Scott David Daniels wrote:
copying to a minimum. With immutables, you needn't do any of the bookkeeping. It is not that you have gone terribly wrong; it is that you have opened the lid on a large class of avoidable problems. If you look at Java's strings (as I remember -- it has been forever since I studied Java at all), you will find they are mutable. You also find that Java code copies strings a _lot_, just to be safe against lower- level mutation.
Incidentally, Java's strings are immutable, too. Quote from "Head First Java" (p. 589):
"For security purposes, and for the sake of conserving memory ... Strings in Java are immutable."
Sorry about the mis-information, it has been too many years since I looked at Java. Perhaps I was remembering Pascal or Ada. --Scott David Daniels Scott.Daniels@Acm.Org
Some of the questions feel a lot like, "why so many planar surfaces in architecture;" to answer them requires work, not simply in the saying, but in looking back for the whys. Often the first answer "it makes my skin crawl" is the real answer; some rule has become so internalized you don't know why you feel it. It doesn't necessarily mean Kirby was saying you had done an incredibly stupid thing; it might simply mean that something about that as design felt dangerous to him in some way.
--Scott David Daniels Scott.Daniels@Acm.Org
Yeah, good, thanks Scott. Arthur is a really smart guy -- knows enough to get himself in real trouble. My high school year book quote: "If a little knowledge is a dangerous thing, show the me man who knows so much as to be out of danger." I forget who said that. The point being (of course) that's we may never know enough. Kirby
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of kirby urner Sent: Sunday, March 19, 2006 10:58 AM
Arthur is a really smart guy -- knows enough to get himself in real trouble.
And generally have. Just a little more cautious, with age, about the kind of trouble ;) Art
Hello Scott, In C++ we have a saying for value types, such as complex numbers: "Do as the ints do". The complex class in C++ is also immutable. I have never seen a need for mutable numeric, scalar quantities since I began scientific programming 30 years ago. Just a perspective. Friday, March 17, 2006, 5:23:08 PM, you wrote: SDD> ajsiegel@optonline.net wrote:
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 - 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.
SDD> The thing that typically blows up is when you are (for example) SDD> computing with a complex number that is changed halfway through SDD> the computation by another thread (say a mouse drag). The square SDD> root winds up being neither the square root of the original number SDD> nor of the new changed number. Further, it becomes dicey to SDD> try to prove that your square root function will always terminate SDD> (a step size from one that is guaranteed to settle might be a SDD> disaster at the new-improved value. SDD> So, that's why CS people like immutable primitive types. SDD> -- Scott David Daniels SDD> Scott.Daniels@Acm.Org SDD> _______________________________________________ SDD> Edu-sig mailing list SDD> Edu-sig@python.org SDD> http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck
A Numeric array is mutable; it refers to allocated memory. So any subpart of it is mutable. So I suggest you use a 1-element complex numeric array as your mutable complex type.
import Numeric as N a = N.ones((20,20),N.Complex) b = N.ravel(a[1:2,1:2]) b array([ 1.+0.j]) id(b) 2741696 b += 1 + 1j b array([ 2.+1.j]) id(b) 2741696
Admittedly the str() of this object is ugly, and because Numeric isn't inheritance-friendly this is hard to work around elegantly. If this is a problem it might provide the occasion to upgrade to a newer numerical package. Still, why do you care about mutability of your complex number instances once they are outside Numeric? That seems unusual. mt
Michael Tobis wrote:
A Numeric array is mutable; it refers to allocated memory. So any subpart of it is mutable. So I suggest you use a 1-element complex numeric array as your mutable complex type.
import Numeric as N a = N.ones((20,20),N.Complex) b = N.ravel(a[1:2,1:2]) b
array([ 1.+0.j])
id(b)
2741696
b += 1 + 1j b
array([ 2.+1.j])
id(b)
2741696
Admittedly the str() of this object is ugly, and because Numeric isn't inheritance-friendly this is hard to work around elegantly. If this is a problem it might provide the occasion to upgrade to a newer numerical package.
Yeah, I should be moving along to understand what the newer numerical packages do differently. One of the reasons I haven't is because I have had the impression that differences are more at the level of implementation detail, rather than user-facing, and there is no fundamental difference in these kinds of functional issues. but that has only been an impression, and you seem to be implying otherwise.
Still, why do you care about mutability of your complex number instances once they are outside Numeric? That seems unusual.
Well outside of Numeric they represent dynamic, graphical geometric objects, whose identity needs to stay intact as they run through their paces. Art
participants (8)
-
ajsiegel＠optonline.net -
Arthur
-
Christian Mascher -
Chuck Allison -
Dethe Elza -
kirby urner -
Michael Tobis -
Scott David Daniels