You can subscribe to this list here.
2000 |
Jan
(8) |
Feb
(49) |
Mar
(48) |
Apr
(28) |
May
(37) |
Jun
(28) |
Jul
(16) |
Aug
(16) |
Sep
(44) |
Oct
(61) |
Nov
(31) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(56) |
Feb
(54) |
Mar
(41) |
Apr
(71) |
May
(48) |
Jun
(32) |
Jul
(53) |
Aug
(91) |
Sep
(56) |
Oct
(33) |
Nov
(81) |
Dec
(54) |
2002 |
Jan
(72) |
Feb
(37) |
Mar
(126) |
Apr
(62) |
May
(34) |
Jun
(124) |
Jul
(36) |
Aug
(34) |
Sep
(60) |
Oct
(37) |
Nov
(23) |
Dec
(104) |
2003 |
Jan
(110) |
Feb
(73) |
Mar
(42) |
Apr
(8) |
May
(76) |
Jun
(14) |
Jul
(52) |
Aug
(26) |
Sep
(108) |
Oct
(82) |
Nov
(89) |
Dec
(94) |
2004 |
Jan
(117) |
Feb
(86) |
Mar
(75) |
Apr
(55) |
May
(75) |
Jun
(160) |
Jul
(152) |
Aug
(86) |
Sep
(75) |
Oct
(134) |
Nov
(62) |
Dec
(60) |
2005 |
Jan
(187) |
Feb
(318) |
Mar
(296) |
Apr
(205) |
May
(84) |
Jun
(63) |
Jul
(122) |
Aug
(59) |
Sep
(66) |
Oct
(148) |
Nov
(120) |
Dec
(70) |
2006 |
Jan
(460) |
Feb
(683) |
Mar
(589) |
Apr
(559) |
May
(445) |
Jun
(712) |
Jul
(815) |
Aug
(663) |
Sep
(559) |
Oct
(930) |
Nov
(373) |
Dec
|
From: Magnus L. H. <ma...@he...> - 2002-12-28 22:34:53
|
I know PyObject arrays aren't supported in numarray yet -- but how about making the functions more polymorphic? Yes, they work on other sequence types such as lists -- but there seems to be quite a bit of type checking going on. I suppose that is necessary for performance reasons, but how about some polymorphic behaviour in the cases where an unknown type is encountered? It would be nice, for example, if sum() worked on general iterators and generators, and if argsort() worked on, e.g., lists of strings... This would make it easier to integrate the purely numeric stuff with other parts of Python programs... It may be that I'm going beyond the scope of numarray here, but this sort of agnostic signature-based polymorphism is very Pythonic. -- Magnus Lie Hetland http://hetland.org |
From: Magnus L. H. <ma...@he...> - 2002-12-28 22:28:52
|
Perry Greenfield <pe...@st...>: > > > There needs to be a function or method that returns the number of > > elements in an array. > > > > def Elements(array): > > """Number of elements in an array. > > > > This version is slow. > > """ > > return numarray.multiply.reduce(array.shape) len(ravel(array)) may be a faster in some cases, it seems. (Or ravel(array).shape[0], for that matter). BTW: Using the name "array" here seems just as bad as the use of "type" in numarray... Just a thought :] [snip] > > The following function is useful for downsizing arrays. I suggest that > > it should be a ufunc method. This is how I have used reduceat in Numeric. > > > > def blockreduce(array, blocksizes, ufunc): > > """Apply ufunc.reduce to blocks in an array.""" [snip] > We certainly have frequent need for a binning function (i.e., > the equivalent of a blockreduce for add). Do others see this > as a generally useful extension for all binary ufuncs? Not sure if I fully understand this -- but in my work on sequences and time series, I certainly need to do stuff like sums and averages over fixed-sized blocks of one-dimensional arrays... (Discretization.) But there are easier ways of doing that, I suppose (with reshape or indices, for example). -- Magnus Lie Hetland http://hetland.org |
From: Perry G. <pe...@st...> - 2002-12-28 22:28:31
|
Hmmm, I see what you mean. Looks like we have something to fix. Thanks for pointing this out. Perry > -----Original Message----- > From: num...@li... > [mailto:num...@li...]On Behalf Of Magnus > Lie Hetland > Sent: Saturday, December 28, 2002 4:29 PM > To: Numpy-discussion > Subject: [Numpy-discussion] from RandomArray2 import *? > > > I just tried a starred import from RandomArray2, but it seems that it > didn't work properly -- e.g. the uniform function wasn't imported. And > I can't see any __all__ attribute; what's going on? > > -- > Magnus Lie Hetland > http://hetland.org > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > |
From: Perry G. <pe...@st...> - 2002-12-28 21:53:20
|
Edward Jones writes: > > Should the variable "type" be used in numarray? It is an important > function in Python. > We pondered this for a while. Yes, it conflicts with the built in function (and so that function is aliased within the numarray code to a different name). Do you see this causing problems for you? Normally there is no conflict in using it as a keyword name for function or method arguments, but if you can show practical cases where it is a problem, we may reconsider. It seemed to us that type was the best name for the keyword, particularly since we were discouraging people from thinging of typecodes. > --------------------------------------- > > There needs to be a function or method that returns the number of > elements in an array. > > def Elements(array): > """Number of elements in an array. > > This version is slow. > """ > return numarray.multiply.reduce(array.shape) > > --------------------------------------- > I don't disagree. It would be nice to have a consensus for what the function name (and perhaps an array attribute?) should be. I believe IDL uses nelements (which I find more suggestive than elements), but perhaps others have better names. > I write code using both PIL and numarray. PIL uses strings for modes and > numarray uses (optionally) strings as typecodes. This causes problems. > One fix is to emit a DeprecationWarning when string typecodes are used. > Two functions are needed: StringTypeWarningOn and StringTypeWarningOff. > The default should be to ignore this warning. > I'm not sure I understand. Can you give me an example of problem code or usage? It sounds like you are trying to test the types of PIL and numarray objects in a generic sense. But I'd understand better if you could show an example. > > The following function is useful for downsizing arrays. I suggest that > it should be a ufunc method. This is how I have used reduceat in Numeric. > > def blockreduce(array, blocksizes, ufunc): > """Apply ufunc.reduce to blocks in an array.""" > dims = len(array.shape) > if type(blocksizes) is IntType: > blocksizes = dims * [blocksizes] > if len(blocksizes) != dims: > raise TypeError, 'blocksizes must be same length as shape' > for i in range(dims): > if array.shape[i] % blocksizes[i] != 0: > raise ValueError, 'blocksizes must exactly divide ' \ > 'the corresponding array dimension' > for i in range(dims): > array = array.copy() > newshape = (array.shape[0] / blocksizes[i], blocksizes[i]) + \ > array.shape[1:] > array.shape = newshape > array = ufunc.reduce(array, 1) > dims = len(array.shape) > # (0,1,2,3) --> (1,2,3,0) > perm = tuple(range(1, dims)) + (0,) > array = numarray.transpose(array, perm) > return array > We certainly have frequent need for a binning function (i.e., the equivalent of a blockreduce for add). Do others see this as a generally useful extension for all binary ufuncs? (As a side comment, the requirement that the dimensions be evenly divisible is often a pain; one question is to ask whether this must be a requirement or not, or whether there is a way to disable this requirement, i.e., permit the last block to be smaller than usual?) Thanks, Perry Greenfield |
From: Magnus L. H. <ma...@he...> - 2002-12-28 21:29:43
|
I just tried a starred import from RandomArray2, but it seems that it didn't work properly -- e.g. the uniform function wasn't imported. And I can't see any __all__ attribute; what's going on? -- Magnus Lie Hetland http://hetland.org |
From: Perry G. <pe...@st...> - 2002-12-28 19:02:22
|
> In fact, I'm thinking of adopting numarray for my pytables project, but I > don't like the fact that data is not natively aligned inside > recarrays, i.e. > there is not a gap between the different fields even if datatypes doesn't > match the "native" architecture alignement. IMO this can affect > very much to > the read/write efficency when one wants to work with data rows or > columns of > recarrays objects. > > Are there any plans to support this "natural" alignment in > addition of the non- > alignment schema present right now?. > Are you asking for an option to create record arrays with aligned fields (in the sense that the addresses of all values are consistent with their type)? Or are you arguing that non-aligned columns must be prohibited? The former is certainly possible (not not very difficult to implement; basically it requires that record sizes must be a multiple of the largest numerical type, and that padding is placed within records to ensure that all fields have offsets that are a multiple of their size). We cannot accept the latter since we need to access data that are stored in such a non-aligned manner in data files. > Francesc Alted Thanks, Perry Greenfield |
From: Edward C. J. <edc...@er...> - 2002-12-28 17:51:26
|
Should the variable "type" be used in numarray? It is an important function in Python. --------------------------------------- There needs to be a function or method that returns the number of elements in an array. def Elements(array): """Number of elements in an array. This version is slow. """ return numarray.multiply.reduce(array.shape) --------------------------------------- I write code using both PIL and numarray. PIL uses strings for modes and numarray uses (optionally) strings as typecodes. This causes problems. One fix is to emit a DeprecationWarning when string typecodes are used. Two functions are needed: StringTypeWarningOn and StringTypeWarningOff. The default should be to ignore this warning. In my code I use the following workarounds: def SameType(x, y): """Are the two input the same object of NumericType?""" if isinstance(x, NumericType) and isinstance(y, NumericType) \ and x == y: return True return False def IsTypeInList(typecode, seq): """Is a NumericType object in a list of NumericType objects?""" if not isinstance(typecode, NumericType): return False for item in seq: if isinstance(item, NumericType) and typecode == item: return True return False --------------------------------------- The following function is useful for downsizing arrays. I suggest that it should be a ufunc method. This is how I have used reduceat in Numeric. def blockreduce(array, blocksizes, ufunc): """Apply ufunc.reduce to blocks in an array.""" dims = len(array.shape) if type(blocksizes) is IntType: blocksizes = dims * [blocksizes] if len(blocksizes) != dims: raise TypeError, 'blocksizes must be same length as shape' for i in range(dims): if array.shape[i] % blocksizes[i] != 0: raise ValueError, 'blocksizes must exactly divide ' \ 'the corresponding array dimension' for i in range(dims): array = array.copy() newshape = (array.shape[0] / blocksizes[i], blocksizes[i]) + \ array.shape[1:] array.shape = newshape array = ufunc.reduce(array, 1) dims = len(array.shape) # (0,1,2,3) --> (1,2,3,0) perm = tuple(range(1, dims)) + (0,) array = numarray.transpose(array, perm) return array |
From: Magnus L. H. <ma...@he...> - 2002-12-28 16:13:02
|
Francesc Alted <fa...@op...>: [snip] > You may want to have a look at PyTables (http://pytables.sourceforge.net). > It's designed to be used in scenarios similar to that you are exposing. [snip] Sounds interesting. I'll look into it. -- Magnus Lie Hetland http://hetland.org |
From: Francesc A. <fa...@op...> - 2002-12-28 15:10:17
|
Mensaje citado por: Perry Greenfield <pe...@st...>: > Our RecordArrays were intended to map > to data files closely, but other variants are certainly possible. In fact, I'm thinking of adopting numarray for my pytables project, but I don't like the fact that data is not natively aligned inside recarrays, i.e. there is not a gap between the different fields even if datatypes doesn't match the "native" architecture alignement. IMO this can affect very much to the read/write efficency when one wants to work with data rows or columns of recarrays objects. Are there any plans to support this "natural" alignment in addition of the non- alignment schema present right now?. Francesc Alted |
From: Francesc A. <fa...@op...> - 2002-12-28 14:41:06
|
Mensaje citado por: Magnus Lie Hetland <ma...@he...>: > I'm working on some two-dimensional tables of data, where some data > are numerical, while other aren't. I'd like to use numarray's > numerical capabilities with the numerical parts (columns) while > keeping the data in each row together. (I'm sure this generalizes to > more dimensions, and to sub-arrays in general, not just rows.) You may want to have a look at PyTables (http://pytables.sourceforge.net). It's designed to be used in scenarios similar to that you are exposing. It supports Numeric objects and although columns in tables are not automatically converted to Numeric o numarray objects, you can build them on the flight easily using its powerful selection capabilities. It uses HDF5 (http://hdf.ncsa.uiuc.edu/HDF5/) format to save its data, so you can read PyTables files in a variety of languages and platforms. Cheers, Francesc Alted |
From: Perry G. <pe...@st...> - 2002-12-28 01:22:32
|
Magnus Lie Hetland writes: > Tim Churches <tc...@op...>: > [snip] > > Just like this: > > > > >>> import Numeric > > >>> a = Numeric.array(['a','b','c'],typecode=Numeric.PyObject) > > >>> a > > array([a , b , c ],'O') > > >>> > > As you may have noticed from my previous descriptions, I'm using > numarray, not Numeric. I've used this in Numeric before -- I just > can't find the equivalent functionality in numarray :) > At the moment, PyObject arrays are not supported (mainly because it hasn't been a priority for our needs yet. But if all one needs is such an array to hold PyObjects and nothing more (for example, we envisioned more sophisticated uses such as apply object methods to the array and returning arrays of the results) than associative purposes (and being able to set and get array values), it should be quite easy to add this capability. In fact one could subclass NDArray and just define the _get and _setitem methods (I forget the exact names) and probably customize the __init__ and have the functionality that you need. I can take a look at it next week (or if you feel bold, look at NDArray yourself). As with Numeric, speed is sacrificed when using such arrays. The presumption is that one is using Numeric or numarray on such things mainly for the convenience of the array manipulations, not the kind of efficiency that bulk numerical operations provide. Combining that with RecordArrays may be a bit trickier in the sense that RecordArrays presume that records use the same buffer for all data. If one doesn't mind storing PyObject pointers in that data array, it probably is also fairly simple to extend it (but I frankly haven't thought this through so I may be wrong about how easy it is). Doing this may require some thought about how to pickle such arrays. Of course, one may have a set of arrays as Tim suggests which also acts like a record array where there is no single data buffer. Our RecordArrays were intended to map to data files closely, but other variants are certainly possible. Perry Greenfield |
From: Magnus L. H. <ma...@he...> - 2002-12-28 00:06:44
|
Tim Churches <tc...@op...>: [snip] > Just like this: > > >>> import Numeric > >>> a = Numeric.array(['a','b','c'],typecode=Numeric.PyObject) > >>> a > array([a , b , c ],'O') > >>> As you may have noticed from my previous descriptions, I'm using numarray, not Numeric. I've used this in Numeric before -- I just can't find the equivalent functionality in numarray :) [snip] > I really like MetaKit's column-based storage, Me too. > but it just doesn't scale > well (on the author's admission, and verified empirically) Yes, you're right. > - beyond a > few 10**5 records, it bogs down terribly, whereas memory-mapped NumPy > plus BsdDb3 recno databse for strings scales well to many tens of > millions of records (or more, but thats as far as I have tested). Impressive! Now this *does* sound interesting... The project I originally posted about only has a few hundred records, so I'm only considering numarray for expressiveness/readability there -- performance is not an issue. But using bsddb and numarray (or Numeric) together like this seems useful in many applications. > Tim C -- Magnus Lie Hetland http://hetland.org |
From: Tim C. <tc...@op...> - 2002-12-27 23:49:28
|
On Fri, 2002-12-27 at 12:55, Magnus Lie Hetland wrote: > Tim Churches <tc...@op...>: > [snip] > > Have a look at the discussion on RecordArrays in this overview of > > Numarray: http://stsdas.stsci.edu/numarray/DesignOverview.html > > Sounds interesting. > > > However, in the meantime, as you note, its not too hard to write a class > > which emulates R/S-Plus data frames. Just store each column in its own > > Numeric array of the appropriate type > > Yeah -- it's just that I'd like to keep a set of columns collected as > a two-dimensional array, to allow horizontal summing and the like. > (Not much more complicated, but an extra issue to address.) > > > (which might be the PyObject > > types, which can hold any Python object type), > > Hm. Yes. I can't seem to find these anymore. I seem to recall using > type='o' or something in Numeric, but I can't find the right type > objects now... (Guess I'm just reading the docs and dir(numeric) > poorly...) It would be nice if array(['foo']) just worked. Oh, well. Just like this: >>> import Numeric >>> a = Numeric.array(['a','b','c'],typecode=Numeric.PyObject) >>> a array([a , b , c ],'O') >>> > > > By memory-mapping disc-based > > versions of the Numeric arrays, and using the BsdDb3 record number > > database format for the string columns, you can even make a disc-based > > "record array" which can be larger than available RAM+swap. > > Sounds quite useful, although quite similar to MetaKit. (I suppose I > could use some functions from numarray on columns in MetaKit... But > that might just be too weird -- and it would still just be a > collection of columns :]) I really like MetaKit's column-based storage, but it just doesn't scale well (on the author's admission, and verified empirically) - beyond a few 10**5 records, it bogs down terribly, whereas memory-mapped NumPy plus BsdDb3 recno databse for strings scales well to many tens of millions of records (or more, but thats as far as I have tested). Tim C |
From: Magnus L. H. <ma...@he...> - 2002-12-27 22:56:06
|
Tim Churches <tc...@op...>: [snip] > Have a look at the discussion on RecordArrays in this overview of > Numarray: http://stsdas.stsci.edu/numarray/DesignOverview.html Sounds interesting. > However, in the meantime, as you note, its not too hard to write a class > which emulates R/S-Plus data frames. Just store each column in its own > Numeric array of the appropriate type Yeah -- it's just that I'd like to keep a set of columns collected as a two-dimensional array, to allow horizontal summing and the like. (Not much more complicated, but an extra issue to address.) > (which might be the PyObject > types, which can hold any Python object type), Hm. Yes. I can't seem to find these anymore. I seem to recall using type='o' or something in Numeric, but I can't find the right type objects now... (Guess I'm just reading the docs and dir(numeric) poorly...) It would be nice if array(['foo']) just worked. Oh, well. [snip] > Happy to > collaborate on furthering this idea. That would be great (even though I don't really have any time to use for this -- it's just a really tiny part of a small project I'm working on :) > By memory-mapping disc-based > versions of the Numeric arrays, and using the BsdDb3 record number > database format for the string columns, you can even make a disc-based > "record array" which can be larger than available RAM+swap. Sounds quite useful, although quite similar to MetaKit. (I suppose I could use some functions from numarray on columns in MetaKit... But that might just be too weird -- and it would still just be a collection of columns :]) [snip] Thanks for your input. -- Magnus Lie Hetland http://hetland.org |
From: Tim C. <tc...@op...> - 2002-12-27 22:12:30
|
On Fri, 2002-12-27 at 11:29, Magnus Lie Hetland wrote: > I'm working on some two-dimensional tables of data, where some data > are numerical, while other aren't. I'd like to use numarray's > numerical capabilities with the numerical parts (columns) while > keeping the data in each row together. (I'm sure this generalizes to > more dimensions, and to sub-arrays in general, not just rows.) > > It's not a hard problem, really, but the obvious solution--to keep > the other rows in separate arrays/lists and just juggle things > around--seems a bit clunky. I was just wondering if anyone had other > ideas (would it be practical to include all the data in a single array > somehow--I seem to recall that Numeric could have arbitrary object > arrays, but I'm not sure whether numarray supports this?) or perhaps > some hints on how to organize code around this? I wrote a small class > that wraps things up and works a bit lik R/S-plus's data frames; is > there some other more standard code out there for this sort of thing? > (It's a problem that crops up often in data processing of various > kinds...) Have a look at the discussion on RecordArrays in this overview of Numarray: http://stsdas.stsci.edu/numarray/DesignOverview.html However, in the meantime, as you note, its not too hard to write a class which emulates R/S-Plus data frames. Just store each column in its own Numeric array of the appropriate type (which might be the PyObject types, which can hold any Python object type), and have the wrapper class implement __getitem__ etc to collect the relevant "rows" from each column and return them as a complete row as a dict or a sequence. Not that fast, but not slow either. You can implement a generator to allow cursor-like traversal of the all the rows if you like. Happy to collaborate on furthering this idea. By memory-mapping disc-based versions of the Numeric arrays, and using the BsdDb3 record number database format for the string columns, you can even make a disc-based "record array" which can be larger than available RAM+swap. I hope to release code written under contract by Dave Cole (see http://www.object-craft.com.au ) which illustrates this idea in the next month or so (but I've been saying that to myself for a year or more...). Tim C |
From: Magnus L. H. <ma...@he...> - 2002-12-27 21:29:59
|
I'm working on some two-dimensional tables of data, where some data are numerical, while other aren't. I'd like to use numarray's numerical capabilities with the numerical parts (columns) while keeping the data in each row together. (I'm sure this generalizes to more dimensions, and to sub-arrays in general, not just rows.) It's not a hard problem, really, but the obvious solution--to keep the other rows in separate arrays/lists and just juggle things around--seems a bit clunky. I was just wondering if anyone had other ideas (would it be practical to include all the data in a single array somehow--I seem to recall that Numeric could have arbitrary object arrays, but I'm not sure whether numarray supports this?) or perhaps some hints on how to organize code around this? I wrote a small class that wraps things up and works a bit lik R/S-plus's data frames; is there some other more standard code out there for this sort of thing? (It's a problem that crops up often in data processing of various kinds...) Thanks, Magnus -- Magnus Lie Hetland http://hetland.org |
From: Edward C. J. <edc...@er...> - 2002-12-23 02:33:48
|
The operators "<<" and ">>" seem to be undocumented. Is there a reason for this? Ed Jones |
From: Cong <vo....@is...> - 2002-12-22 08:51:40
|
Cong> I've just upgraded from Numeric-21.0 to Numeric-22.0 Cong> ( python-2.2.2 ) and found a bug. Do anyone use LinearAlgebra too ? Cong> Cong> Now, I downed it to Numeric 21.0 . This version works very well. I found that now this version doesnot work too. So I delete Numeric 21.0 complettely then install Numeric 22.0 again. After that the error message changed to: $ python Python 2.2.2 (#1, Dec 22 2002, 17:44:21) [GCC 3.2.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import LinearAlgebra Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/Numeric/LinearAlgebra.py", line 10, in ? import MLab File "/usr/lib/python2.2/site-packages/Numeric/MLab.py", line 20, in ? import RandomArray File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 30, in ? seed() File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 26, in seed x = int(t/base) OverflowError: float too large to conver I can not figure out what is happenning. Temporarily, I import LinearAlgebra this way: try: import LinearAlgebra except: import LinearAlgebra And this worked, for Numeric 22.0 on python 2.2.2 as well as for Numeric 21.0 on python 2.2.2 . // Cong Cong> Cong> Cong Cong> Cong> $ python Cong> Python 2.2.2 (#1, Dec 14 2002, 05:45:37) Cong> [GCC 3.2.1] on linux2 Cong> Type "help", "copyright", "credits" or "license" for more information. Cong> >>> import LinearAlgebra Cong> Traceback (most recent call last): Cong> File "<stdin>", line 1, in ? Cong> File "/usr/lib/python2.2/site-packages/Numeric/LinearAlgebra.py", line 10, in ? Cong> import MLab Cong> File "/usr/lib/python2.2/site-packages/Numeric/MLab.py", line 20, in ? Cong> import RandomArray Cong> File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 30, in ? Cong> seed() Cong> File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 24, in seed Cong> ndigits = int(math.log10(t)) Cong> OverflowError: float too large to convert Cong> |
From: Cong <vo....@is...> - 2002-12-22 08:33:55
|
I've just upgraded from Numeric-21.0 to Numeric-22.0 ( python-2.2.2 ) and found a bug. Do anyone use LinearAlgebra too ? Now, I downed it to Numeric 21.0 . This version works very well. Cong $ python Python 2.2.2 (#1, Dec 14 2002, 05:45:37) [GCC 3.2.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import LinearAlgebra Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/site-packages/Numeric/LinearAlgebra.py", line 10, in ? import MLab File "/usr/lib/python2.2/site-packages/Numeric/MLab.py", line 20, in ? import RandomArray File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 30, in ? seed() File "/usr/lib/python2.2/site-packages/Numeric/RandomArray.py", line 24, in seed ndigits = int(math.log10(t)) OverflowError: float too large to convert |
From: Chris B. <Chr...@no...> - 2002-12-20 19:40:18
|
Hi all, I just stumbled upon this paper by William Kahan, a Professor at Berkeley that is well known for his work on the first Intel math co-processor, and the development of IEE 754 (plus a lot of other stuff). I took a course with him at Berkeley, and the man is brilliant. So brilliant that is is very hard to follow him, as a student, if you are not so sharp. I'm not, and I just squeeked by and missed a great deal of what he tried to teach. I did gain a good appreciation of the complexity of floating point arithmetic, however. Here is the paper as a PDF: http://www.cs.berkeley.edu/%7ewkahan/MgtkMath.pdf There's a lot of other good stuff on his web page at: http://www.cs.berkeley.edu/%7ewkahan/ THe paper is entitled "Marketing versus Mathematics". In particular, take a look at the section on Quattro Pro on Page 13, for a nice discussion of binary arithmetic displayed as decimal, which is an often brought up subject in the Python newsgroups. He discusses how you'd really have to display more than the 15 digits that Quattro displayed, to avoid confusion. """ But no such cure can be liberated from little annoyances: 0.8 entered would display as 0.80000000000000004 to 17 sig. dec.; """ At the Python prompt: >>> 0.8 0.80000000000000004 More evidence that the current Python way is "best", if confusing to newbies. This would be another good paper to point people towards that ask about floating point on the newsgroups. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Todd M. <jm...@st...> - 2002-12-19 14:36:30
|
Sebastian Haase wrote: >Hi all, >I downloaded numarray 0.4 about 5 minutes after I got the announce but >my naive 'python2.2 ./setup.py build' gives this > > numarray-0.4 doesn't currently support a two step build process because code generation, which is required, doesn't occur unless the install command is present. Unfortunately, code generation *always* occurs when the install command is present, which defeats the purpose of a seperate build. This problem has been fixed in CVS by making code generation the result of an explicit setup.py switch (--gencode) which makes it possible to generate code during a build command. One work-around is the following: 1. First generate code (as a non-priviledged user) using "python setup.py install". Control-C as soon as the code starts to build. 2. Do "python setup.py build" 3. Edit setup.py, commenting out the 2 calls to os.system() in the function prepare(). This prevents codegeneration during the "real" install. 4. Do "python setup.py install" as root, noting that no new code is generated, and everything is already built. Todd >haase@baboon:~/numarray-0.4: python2.2 ./setup.py build >running build >running build_py >not copying Lib/ndarray.py (output up-to-date) >not copying Lib/numtest.py (output up-to-date) >not copying Lib/codegenerator.py (output up-to-date) >not copying Lib/ufunc.py (output up-to-date) >not copying Lib/testdata.py (output up-to-date) >not copying Lib/numarray.py (output up-to-date) >not copying Lib/ieeespecial.py (output up-to-date) >not copying Lib/recarray.py (output up-to-date) >not copying Lib/template.py (output up-to-date) >not copying Lib/arrayprint.py (output up-to-date) >not copying Lib/typeconv.py (output up-to-date) >not copying Lib/numinclude.py (output up-to-date) >not copying Lib/numarrayext.py (output up-to-date) >not copying Lib/_ufunc.py (output up-to-date) >not copying Lib/chararray.py (output up-to-date) >not copying Lib/numtestall.py (output up-to-date) >not copying Lib/numerictypes.py (output up-to-date) >not copying Lib/memmap.py (output up-to-date) >running build_ext >building '_conv' extension >error: file 'Src/_convmodule.c' does not exist > >What am I missing? I'm running Linux (debian woody) on i386. > >Thanks, >Sebastian > >------------------------------------------------------- >This SF.net email is sponsored by: Microsoft Visual Studio.NET >comprehensive development tool, built to increase your >productivity. Try a free online hosted session at: >http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en >_______________________________________________ >Numpy-discussion mailing list >Num...@li... >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > |
From: Todd M. <jm...@st...> - 2002-12-19 13:53:42
|
Sebastian Haase wrote: >Hi! >Somehow I have a problem with numarray. Please take a look at this: > Hi Sebastian, I've don't recall seeing anything like this, nor can I reproduce it now. If you've been following numarray for a while now, I can say that it is important to remove the old version of numarray before installing the new version. I recommend deleting your current installation and reinstalling numarray. compress() is a ufunc, much like add() or put(). It is defined in ndarray.py, right after the import of the modules ufunc and _ufunc. _ufunc in particular is a problematic module, because it has followed the atypical development path of moving from C-code to Python code. Because of this, and the fact that a .so or .dll overrides a .py, older installations interfere with newer ones. The atypical path was required because the original _ufuncmodule.c was so large that it could not be compiled on some systems; as a result, I split _ufuncmodule.c into pieces by data type and now use _ufunc.py to glue the pieces together. Good luck! Please let me know if reinstalling doesn't clear up the problem. Todd > > >>>>import numarray as na >>>>na.array([0, 0]) >>>> >>>> >array([0, 0]) > > >>>>na.array([0.0, 0.0]) >>>> >>>> >Traceback (most recent call last): > File "<input>", line 1, in ? > File "C:\Python22\Lib\site-packages\numarray\numarray.py", line 581, in >__repr__ > MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ', ', 1) > File "C:\Python22\Lib\site-packages\numarray\arrayprint.py", line 163, in >array2string > separator, array_output) > File "C:\Python22\Lib\site-packages\numarray\arrayprint.py", line 125, in >_array2string > format, item_length = _floatFormat(data, precision, suppress_small) > File "C:\Python22\Lib\site-packages\numarray\arrayprint.py", line 246, in >_floatFormat > non_zero = numarray.abs(numarray.compress(numarray.not_equal(data, 0), >data)) >AttributeError: 'module' object has no attribute 'compress' > >The same workes fine with Numeric. But I would prefer numarray because I'm >writing C++-extensions and I need "unsigned shorts". > >What is this error about? > >Thanks, >Sebastian > > > > >------------------------------------------------------- >This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! >Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, >MP3 Players, XBox Games, Flying Saucers, WebCams, Smart Putty. >T H I N K G E E K . C O M http://www.thinkgeek.com/sf/ >_______________________________________________ >Numpy-discussion mailing list >Num...@li... >https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > |
From: Sebastian H. <ha...@ms...> - 2002-12-19 01:22:13
|
Hi! Somehow I have a problem with numarray. Please take a look at this: >>>import numarray as na >>>na.array([0, 0]) array([0, 0]) >>>na.array([0.0, 0.0]) Traceback (most recent call last): File "<input>", line 1, in ? File "C:\Python22\Lib\site-packages\numarray\numarray.py", line 581, in __repr__ MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ', ', 1) File "C:\Python22\Lib\site-packages\numarray\arrayprint.py", line 163, in array2string separator, array_output) File "C:\Python22\Lib\site-packages\numarray\arrayprint.py", line 125, in _array2string format, item_length = _floatFormat(data, precision, suppress_small) File "C:\Python22\Lib\site-packages\numarray\arrayprint.py", line 246, in _floatFormat non_zero = numarray.abs(numarray.compress(numarray.not_equal(data, 0), data)) AttributeError: 'module' object has no attribute 'compress' The same workes fine with Numeric. But I would prefer numarray because I'm writing C++-extensions and I need "unsigned shorts". What is this error about? Thanks, Sebastian |
From: Edward C. J. <edc...@er...> - 2002-12-18 22:26:32
|
In "numerictypes.py' it says "This module is designed so 'from numerictypes import *' is safe." When I "import numerictypes", and run dir(), I get: ['Any', 'AnyType', 'Bool', 'BooleanType', 'Byte', 'Complex', 'Complex32', 'Complex64', 'ComplexType', 'Double', 'Float', 'Float32', 'Float64', 'FloatingType', 'Int', 'Int16', 'Int32', 'Int64', 'Int8', 'IntegralType', 'Long', 'MAX_ALIGN', 'NumericType', 'Short', 'SignedIntegralType', 'SignedType', 'UInt16', 'UInt32', 'UInt64', 'UInt8', 'UnsignedIntegralType', 'UnsignedType', '__builtins__', '__doc__', '__name__', 'genericCoercions', 'genericPromotionExclusions', 'genericTypeRank', 'inttype1', 'inttype2', 'kind', 'mapto', 'maptype1', 'maptype2', 'nt1', 'nt2', 'ntypesize1', 'ntypesize2', 'numinclude', 'outtype', 'pythonTypeMap', 'pythonTypeRank', 'rank1', 'rank2', 'scalarTypeMap', 'signedtype1', 'signedtype2', 'typeDict', 'typecode', 'typecodes'] A bunch of leading "_" are needed. ---------------- My code is: #! /usr/bin/env python from numerictypes import UInt8 print UInt8 == "ABC" The message is: Traceback (most recent call last): File "./silly02.py", line 5, in ? print UInt8 == "ABC" File "/usr/lib/python2.2/site-packages/numarray/numerictypes.py", line 101, in __cmp__ other = typeDict[other] KeyError: ABC I would expect that the only object == to UInt8 be itself. Maybe add a function comparetypecodes(x, y) which returns True iff x and y are either NumericType's or strings which represent the same type. |
From: Todd M. <jm...@st...> - 2002-12-18 15:03:55
|
Edward C. Jones wrote: > The optional shape argument to fromstring is not documented. Noted. > > ----------------- > > I suggest a documentation section on NumericTypes. "Int8.bytes" and > need documenting. Noted. > > ---------------- > > Table of Automatic Coercions (found by experiment) > > B I8 U8 I16 U16 I32 U32 I64 U64 F32 F64 C32 C64 > ------------------------------------------------------------------ > B | *I8 I8 U8 I16 U16 I32 U32 I64 U64 F32 F64 C32 C64 > I8 | I8 *I16 I16 U16 I32 U32 I64 U64 F32 F64 C32 C64 > U8 | U8 I16 U16 I32 U32 I64 U64 F32 F64 C32 C64 > I16 | I16 *I32 I32 U32 I64 U64 F32 F64 C32 C64 > U16 | U16 I32 U32 I64 U64 F32 F64 C32 C64 > I32 | I32 *I64 I64 U64 F32 F64 C32 C64 > U32 | U32 I64 U64 F32 F64 C32 C64 > I64 | I64 *I64 ?F32 F64 C32 C64 > U64 | U64 ?F32 F64 C32 C64 > F32 | F32 F64 C32 C64 > F64 | F64 ?C32 C64 > C32 | C32 C64 > C64 | C64 Nice table! > > The names are listed in the order used in "numerictypes.py". The "*" > cases are exceptions treated there. Are the "?" conversions correct? See No. The Complex32/Float64 conversion has already been fixed in CVS. The Int64/Float32 coercion will be changed from Float32 to Float64. > "genericPromotionExclusions" in "numerictypes.py". Thanks for the excellent feedback! Todd |