Re: Py 2.5 on Language Shootout
Isaac Gouy wrote: > [EMAIL PROTECTED] wrote: > > Alioth is a great site for selecting the language in which to implement > > primitives. Usually it's C. > > And for selecting a language for which you might need to implement > primitives in C :-) Well if you like C so much, just do it in C. ":-)" > > > > > Two of the alioth benchmarks, Partial-sums and Spectral-norm, could be > > done using Numarray, or would be done with Numarray if most of the > > program was in Python and there was a need to implement a similar > > numerical procedure. The speed would be up near the compiled language > > benchmarks. However the specific wording of these benchmarks prohibits > > this approach. Spectral-norm must pretend the dataset is infinite, and > > Partial-sums has to be implemented in a simple dumb loop. > > And we wouldn't use a naïve recursive algorithm to find fibonnaci > numbers ... unless we were interested in recursion for its own sake. > > Maybe the author of spectral-norm was interested in function calls. > Maybe the author of partial-sums was interested in simple dumb loops > and simple dumb Math. I am not disputing this. I think you take my point though. > > > > Looking over the benchmarks, one gains the impression that Python is a > > slow language. > > What does that even mean - a slow language? > The alioth benchmarks provide a set of numbers by which languages may be compared. > > > My first serious Python programming exercise involved converting a 900 > > line Bash Shell program to a 500 line Python program, with a speedup > > factor of 17. Using Python allowed an OO structure and advanced > > containers, meaning the program was more maintainable and portable, > > which were the main aims of the exercise. The speedup was a surprising > > and welcome side benefit. I think it was mosly because the Python > > byte-code interpreter is probably an order of magnitude faster than > > Bash's direct interpretation, and because in Python system calls to > > recurse directories and create symbolic links were not forked to > > separate processes. In fact I would guess that the overall speed of the > > Python program would be little less than a C program, given that most > > of the time would be spent in system calls. > > /I would guess/ I don't have the time, or interest, to recode it in C to find out. In reality the choice would be C++ because of OO and STL. Perhaps traversing and linking a tree containing about 1000 files would not take a full second. I might be wrong. All i know is, its a lot faster than Bash. > > > Its almost possible to make a large Python program arbitrarily fast by > > profiling it and implementing slow bits as primitives. Size is probably > > of greater concern. > > We could read that simply as - /it's not possible/ to make a large > Python program arbitrarily fast. Is that what you meant? No. I meant that if my Python program is too big in terms of its execution memory requirements, then that would be a difficult issue to deal with. Rather than optimizing execution hotspots, I might have to use another language. Cheers, P.S. Alioth is a great site. -- http://mail.python.org/mailman/listinfo/python-list
Re: Py 2.5 on Language Shootout
Alioth is a great site for selecting the language in which to implement primitives. Usually it's C. Two of the alioth benchmarks, Partial-sums and Spectral-norm, could be done using Numarray, or would be done with Numarray if most of the program was in Python and there was a need to implement a similar numerical procedure. The speed would be up near the compiled language benchmarks. However the specific wording of these benchmarks prohibits this approach. Spectral-norm must pretend the dataset is infinite, and Partial-sums has to be implemented in a simple dumb loop. Looking over the benchmarks, one gains the impression that Python is a slow language. My first serious Python programming exercise involved converting a 900 line Bash Shell program to a 500 line Python program, with a speedup factor of 17. Using Python allowed an OO structure and advanced containers, meaning the program was more maintainable and portable, which were the main aims of the exercise. The speedup was a surprising and welcome side benefit. I think it was mosly because the Python byte-code interpreter is probably an order of magnitude faster than Bash's direct interpretation, and because in Python system calls to recurse directories and create symbolic links were not forked to separate processes. In fact I would guess that the overall speed of the Python program would be little less than a C program, given that most of the time would be spent in system calls. Its almost possible to make a large Python program arbitrarily fast by profiling it and implementing slow bits as primitives. Size is probably of greater concern. -- http://mail.python.org/mailman/listinfo/python-list
Re: mutable numeric type
Way to go. Try doing this. x = MutableNumeric(42) y = x x += 42 print y -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding an instance to a data tree
And of course the solution occurs to me about 30 minutes after posting, to have the add method return an instance which then invokes setup. self.add(name, child_type, other_info).setup(child-setup-parameters) -- http://mail.python.org/mailman/listinfo/python-list
Adding an instance to a data tree
Hi,
I have a data tree. A node in the tree "assembles" itself when called
upon to do so by the level-of-detail algorithm.
It creates and adds its children to itself using a base class method
called "add". However in the pseudo-constructor called "setup", the
child node needs to be already linked into the tree in order to obtain
configuration information. So the "add" method creates the child,
optionally positions it within the parents frame of reference, then
invokes the child's setup method which has variable length arguments.
Here is an example of code in an assemble method.
self.add("Reservoir",(Reservoir, r, r +
self.inner_tank_thickness))
self.add("End_tank", (End_tank, r,
self.outer_tank_radius),
0.5*self.payload_length +
0.5*self.outer_tank_thickness)
self.add("Inner_end_tank", (End_tank, r,
self.outer_tank_radius),
-0.5*self.payload_length
-0.5*self.outer_tank_thickness)
self.add("Zero_G_port", Zero_G_port,
0.5*self.payload_length
-0.5*self.zg_length)
self.add("Hangar-floor", Hangar)
self.add("herc", Hercules_shuttle,
(0.5*self.payload_length - 25,
R3d(180.0,V3d(0,1,0
self.add("herc1",Hercules_shuttle,
(V3d(0,-12.5,0.5*self.payload_length - 25), R3d(180.0,V3d(0,1,0
The add method takes the parameters "name", child-information, and
optional location-information.
The child information is either a class, or a tuple whose first member
is a class. The remaining members of the tuple are parameters to the
class setup method.
The problem is this: Sometimes the setup method parameters are quite
numerous, leading to problems when the order is misjudged. If invoked
directly, then naming parameters minimises the problems with missed
parameters. However the indirect creation via the "add" method means
the parameters are passed in a tuple, so the parameters cannot be
named.
How can I "pre-construct" the children with parent id and optional
location information, and also implement the advantages of named
function parameters?
Looking for all suggestions.
--
http://mail.python.org/mailman/listinfo/python-list
Re: handling many default values
Alan Isaac wrote: > > At Friday 10/11/2006 14:11, Alan G Isaac wrote: > > >class Params: > > > def __init__(self,**kwargs): > > > #set lots of default values > > > ... > > > #set the deviations from defaults > > > self.__dict__.update(kwargs) > > > > > >Is this a reasonable approach overall? > > >(Including the last line.) > > > "Gabriel Genellina" wrote in message > news:[EMAIL PROTECTED] > > I'm not sure what you want to do exactly, but a class attribute acts > > as a default instance attribute. > > Yes. I am sorry my question was not clearer. > There are *many* parameters, > and the list can change, > so I want to avoid listing them all in the Param class's __init__ function, > using the strategy above. > > Q1: Is this approach reasonable? > (This is a newbie question about unforseen hazards.) > Q2: Is it horrible design to isolate the parameters in a separate class? > (Comment: currently several classes may rely on (parts of) the same > parameter set.) > > Thanks, > Alan Isaac Hi, I kind of had a similar problem when I was developing a 3d OO engine. I had many bigger things composed of lots of little things, and a lot of code was spent initializing the little things in constructors. So I just passed a reference of the bigger thing to the little thing in its constructor, thus saving a lot of parameter passing and variable setup and copying. In the following example, big is passed to little's constructor, instead of all of big's variables. ie. class big: def __init__(self): self.v1 = ... self.v2 = ... self.objects = [] def assemble(self): self.objects.append(little(self, 1)) self.objects.append(little(self,2)) class little: def __init__(self, big, n): self.big = big # Now little has access to v1, v2 by self.big.v1 etc self.n = n # This makes it different def a_function(self): do_something(self.big.v1, self.big.v2) -- http://mail.python.org/mailman/listinfo/python-list
