Re: [Edu-sig] Properties use case
In a message of Tue, 21 Mar 2006 13:58:52 CST, "Michael Tobis" writes:
While PyPy is a most admirable endeavor, I can't imagine that it can resolve this problem. I'll be most pleased to discover that I am wrong, so please correct me.
Is scientific programming a target usage of PyPy?
Yes.
In particular, how could large arrays of numbers of homogeneous type be handled outside the Numeric-type libraries in such a way that efficient computation is possible and also provide a guarantee the memory mapping of the data to allow interoperation with compiled languages?
This one is better discussed on pypy-dev@codespeak.net where you will get better answers from people who are actually implementing this stuff :-)
Surely a reimplementation of BLAS, Atlas, Lapack, etc is not part of PyPy's mission. So how is the success of PyPy going to have great relevance to Numeric/numarray/numpy users?
We don't -- at least right now -- want to replace these cases where you use numeric because you really need a lot of linear algebra. (Though the goal is to make it easy for researchers to drop in algorithms that can speed up their code, so who knows what people will do with it, eventually). But a lot of people are using numeric simply for speed and more memory packing. These people will find it easier to write their programs in PyPy, just as some of them now find it easier to write their programs in straightforward python and then use Psyco. I could be wrong, but I don't think it is the linear algebra that Arthur wants, or needs. He wants 'bloody fast arrays'. And I think he will like tens of thousands of threads, too, though if these just means tens of thousands of chances to modify only part of your complex number, when you wanted an atomic action guaranteed to modify both parts as one, then he may hate it before he likes it. :-)
mt
Laura
-----Original Message----- From: Laura Creighton [mailto:lac@strakt.com]
We don't -- at least right now -- want to replace these cases where you use numeric because you really need a lot of linear algebra.
Actually, the way I see it, there will be a significant benefit even when using a library like Numeric for linear algebra When profiling I was surprised at the time being spent on the calculation of determinants for my small matrices. Looking at the Numeric code I understood the issue better. It needs to do a decent amount of processing just to form the right question for lapack, i.e. it needs to analyze and understand the array it is processing before it can call the lapack routine. Which is why I begin to think that within the framework of an application where I know beforehand, e.g. the size and shape of the array for which I need a determinant, I would be losing less than I would have guessed by just up and calculating it in Python. Either way PyPY will be a win for this kind of processing. Art
-----Original Message----- From: Laura Creighton [mailto:lac@strakt.com]
And I think he will like tens of thousands of threads, too, though if these just means tens of thousands of chances to modify only part of your complex number, when you wanted an atomic action guaranteed to modify both parts as one, then he may hate it before he likes it. :-)
Sorry - I suspect everyone else is quite done with this, but I'm still bothered by mixed signals. I would like to be able to present PyGeo as good, sensible code. Not Museum Quality, to be sure. But good and responsible. There is an implication in what you are saying that I am still off the mark. Perhaps I am. But its not fair, in my mind, to throw that at me knowing that it still has not gotten through to me (and Zelle ?) in what way I am off the mark. For the life of me I don't see the problem. My class has 2 __slots__ - .real and .imag. It does with them the kind of things that classes do. How is this class different and less thread safe than an infinite number of other classes that do with attributes the kinds of things that classes do with attributes? I have unintentionally stimulated a CS nerve, apparently. But would still love to get to the bottom of issue. Or get an official CS - proper use case aside - bill of health. Art
Arthur wrote:
-----Original Message----- From: Laura Creighton [mailto:lac@strakt.com]
And I think he will like tens of thousands of threads, too, though if these just means tens of thousands of chances to modify only part of your complex number, when you wanted an atomic action guaranteed to modify both parts as one, then he may hate it before he likes it. :-)
Sorry - I suspect everyone else is quite done with this, but I'm still bothered by mixed signals.
I would like to be able to present PyGeo as good, sensible code. Not Museum Quality, to be sure. But good and responsible.
There is an implication in what you are saying that I am still off the mark. Perhaps I am. But its not fair, in my mind, to throw that at me knowing that it still has not gotten through to me (and Zelle ?) in what way I am off the mark.
For the life of me I don't see the problem. My class has 2 __slots__ - .real and .imag. It does with them the kind of things that classes do.
How is this class different and less thread safe than an infinite number of other classes that do with attributes the kinds of things that classes do with attributes?
This is a complex matter and I'll try to give a very short (hence a little categoric) answer. First of all, IMO Laura was referring to several thousands of lightweight thread such as those found in the Oz/Mozart language (http://www.mozart-oz.org). And that is because we have had a PyPy/Oz sprint two weeks ago where we made plans and prototypes for the integration of some ideas of Mozart into PyPy (mostly logic variables, "search", and constraint programming, micro-threads were already on the go). In that language stateful datatypes such as mutable objects are an exception. By default the variable store is a single assignment store. That means when you create a variable (e.g. with this statement X=_ ) it is uninitialized (called unbound). Then when you assign it you cannot rebind it to an other value: X=4 works but if you do X=5 later you get a sort of exception (failure). In a sense = does not do assignment but true mathematical equality (called unification). So you can do 4=X as well as 1+X = 5. The language supports very lightweight threads (having a million of those is no problem), when they try to "use" the value of a variable , they block if the variable is unbound. So you can launch inter-dependant threads accessing values computed by each others without wondering about the synchronization. That is called dataflow concurrency. In a sense, your mutable complex object is opposite to that approach where (almost) all variables never ever change their value.
I have unintentionally stimulated a CS nerve, apparently. But would still love to get to the bottom of issue.
HTH :-)
Or get an official CS - proper use case aside - bill of health.
I would refer you to the CTM book: http://www2.info.ucl.ac.be/people/PVR/book.html You will find there lots of interresting ideas about computer language semantics. Best, -- Grégoire Dooms
participants (3)
-
Arthur -
Grégoire Dooms -
Laura Creighton