Hi Robert,
I am about to get started on some stuff for the random number generators but
thought I would run it by you first. I envisage the following:
uniform short_doubles -- doubles generated from a single 32 bit random
number (advantage: speed)
uniform double, short_doubles on the interval (0,1) -- don't touch
singularities in functions like log (this is my preferred default)
fast_normal -- ziggurat method using single 32 bit random numbers
(advantage: speed)
fast_exponential -- ziggurat method using single 32 bit random numbers
(advantage: speed)
MWC8222 random number generator (advantage: speed on some machines,
different from mtrand)
Except for the last, none conflict with current routines and can be added
without a branch. I expect adding MWC8222 might need more extensive work and
I will branch for that. So the questions are of utility and naming. I see
some utility for myself, otherwise I wouldn't be considering doing the work.
OTOH, I already have (C++) routines that I use for these things, so a larger
question might be if anyone else sees a use for these. I like speed, but it
is not always that important in everyday apps.
I see that Pyrex is used for the interface, so I suppose that is one more
tool to become familiar with ;)
Chuck
Travis has introduced the function diagflat for creating diagonal arrays. It
flattens whatever array is supplied and returns its values as the diagonal
of a 2-D array or matrix. As the function is currently undocumented I
thought now might be a good time to discuss other possible choices for the
name. Here is a quick list that comes to mind
diagflat (current name)
asdiagonal
todiagonal
asdiag
todiag
...
Chuck
I will be out of the office starting 09/04/2006 and will not return until
09/25/2006.
I will respond to your message when I return. For urgent matters please
contact Ton van de Peut: T.vdpeut(a)mapperlithography.com
I think I see a bug in lib.user_array.container class. The __eq__
method is
def __eq__(self,other): return self._rc(equal(self.array,other))
the expression equal(self.array,other) will return an ndarray of
bools, which is then converted, by way of self._rc(), to whatever the
derived class is. In my case, this does not make sense, because an
array of bools is not a valid argument to the constructor (actually,
the data buffer is accepted, but the results are not reliable). What
I want, and it seem most people would want in this situation, is just
the array of bools; i.e. don't apply the self._rc() method.
Assuming there is agreement that this is the desirable behavior, the
same would be true for __lt__, __le__, etc.
I will probably override this behavior by defining my own __eq__,
etc., in my derived class, just for safety.
** Bill Spotz **
** Sandia National Laboratories Voice: (505)845-0170 **
** P.O. Box 5800 Fax: (505)284-5451 **
** Albuquerque, NM 87185-0370 Email: wfspotz(a)sandia.gov **
Hi
All yo e ur PHA o RRMAC s Y d f irec g tly from the m t anufa a cture j
r,
Your ch v an b ce to eco i nomiz v e wit o h us
http://omgandesunkerion.com
r
z
y
floor was smooth and hard, as were the walls when I brushed my fingers
What about her? Steengo asked.
be a crackup in the old kaserne tonight!
