Menu
▾
▴
numpy-discussion — Discussion list for all users of Numerical Python
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: Fernando P. <Fer...@co...> - 2006-01-05 17:57:16
|
Joe Harrington wrote: > Francesc Altet on scipy-dev: > > >>Now that numpy is dead and we all want a long life to numpy, what >>about moving discussions in this list into the venerable: > > >>"numpy-discussion <num...@li...>" > > > We're one community (or want to be). Could we just have one mailing > list per type of discussion (dev and user)? All the cross-posting and > cross-monitoring is tedious. I don't care whether we keep scipy-* or > numpy-* lists, but is there a functional reason to have four lists? > Consider that soon we may have *-doc, *-newbie, *-announce, and others > as well, if this takes off like we all hope. If the developers want > separate lists because some are only working on one of the two > packages, I can see that argument (in the future if not now). I don't > see a need for two user lists, unless perhaps sorted by high and low > traffic. > > I propose we either drop the numpy-* lists (if subscribers there > agree), or leave them for ongoing discussion of the legacy packages, > and discourage discussion of the new numpy/scipy there. > > Ok, flame me. Uh, no. I'm actually with you on this one: I just don't think we are a large enough group to warrant the existence of separate numpy- and scipy- lists, especially when the overlap in topics is so high. Every scipy user is, by necessity, a numpy user as well. I think that, IF in the future: 1. the traffic on the scipy- lists becomes enormous, AND 2. a significant portion of that traffic is for users of numpy as a pure array library with no scientific concerns (if it really becomes a popular 'data exchange' system for Python-and-C libraries), THEN we can consider resuscitating the numpy lists. For now, I vote on leaving them dormant, and moving all numeric(abandoned), numarray(maintenance-transition) and numpy/scipy (new development) discussion to the scipy-* lists. I don't think the occasional post about Numeric or numarray is a major concern (at least it doesn't bother me). It is an issue also of friendliness to newbies: I'd like to tell newcomers "for information and discussion, just join scipy-user and matplotlib-user, and you should be set on all numerics and plotting in python". Telling them to subscribe to, or monitor via gmane, 8 different lists is annoying. Cheers, f |
|
From: Sebastian H. <ha...@ms...> - 2006-01-05 17:28:35
|
Thanks Todd, I like this a lot. Maybe it could be mentioned in the documention - I don't have any good suggestions on where, I just noticed that 'dtype' is not in the index. I assume the following assignment to 'dtype' is not that important !? >>> na.__version__ '1.5.1' >>> a = na.arange(10,dtype=na.float32) >>> a.dtype Float32 >>> a.dtype = na.int32 Traceback (most recent call last): File "<input>", line 1, in ? AttributeError: can't set attribute Also: when / why was it decided that dtypes (float32, int32, ...) should be lowercase !? Aren't all python types usually uppercase ... Thanks for all your work. Sebastian Haase On Thursday 05 January 2006 03:10, Todd Miller wrote: > Sebastian Haase wrote: > >Hi, > >In an effort to follow the scipy_core development I just got the latest > > CVS version of numarray. > >I was mainly interested in changing my code (and the tutorial that I > > write) slowly but surely to use 'dtype' instead of 'type'. > > > >So I get this: > >>>>na.__version__ > > > >'1.5.1' > > > >>>>a = na.arange(10,dtype=na.float32) # great ! > >>>>a.dtypechar > > > >'f' > > > >>>>a.type() > > > >Float32 > > > >>>>a.dtype > > > >Traceback (most recent call last): > > File "<input>", line 1, in ? > >AttributeError: 'NumArray' object has no attribute 'dtype' > > > >Is there a reason for not having the 'dtype' attribute !? I *really* never > >liked the need for parenthesis when using 'a.type()' ... > > > >Thanks, > >Sebastian Haase > > I added .dtype returning the numarray numerical type object > corresponding to the array. > > Todd |
|
From: Joe H. <jh...@oo...> - 2006-01-05 16:26:00
|
Francesc Altet on scipy-dev: > Now that numpy is dead and we all want a long life to numpy, what > about moving discussions in this list into the venerable: > "numpy-discussion <num...@li...>" We're one community (or want to be). Could we just have one mailing list per type of discussion (dev and user)? All the cross-posting and cross-monitoring is tedious. I don't care whether we keep scipy-* or numpy-* lists, but is there a functional reason to have four lists? Consider that soon we may have *-doc, *-newbie, *-announce, and others as well, if this takes off like we all hope. If the developers want separate lists because some are only working on one of the two packages, I can see that argument (in the future if not now). I don't see a need for two user lists, unless perhaps sorted by high and low traffic. I propose we either drop the numpy-* lists (if subscribers there agree), or leave them for ongoing discussion of the legacy packages, and discourage discussion of the new numpy/scipy there. Ok, flame me. --jh-- |
|
From: Todd M. <jm...@st...> - 2006-01-05 11:10:26
|
Sebastian Haase wrote: >Hi, >In an effort to follow the scipy_core development I just got the latest CVS >version of numarray. >I was mainly interested in changing my code (and the tutorial that I write) >slowly but surely to use 'dtype' instead of 'type'. >So I get this: > > >>>>na.__version__ >>>> >>>> >'1.5.1' > > >>>>a = na.arange(10,dtype=na.float32) # great ! >>>>a.dtypechar >>>> >>>> >'f' > > >>>>a.type() >>>> >>>> >Float32 > > >>>>a.dtype >>>> >>>> >Traceback (most recent call last): > File "<input>", line 1, in ? >AttributeError: 'NumArray' object has no attribute 'dtype' > >Is there a reason for not having the 'dtype' attribute !? I *really* never >liked the need for parenthesis when using 'a.type()' ... > >Thanks, >Sebastian Haase > > I added .dtype returning the numarray numerical type object corresponding to the array. Todd |
|
From: Sebastian H. <ha...@ms...> - 2006-01-05 01:21:20
|
Hi, In an effort to follow the scipy_core development I just got the latest CVS version of numarray. I was mainly interested in changing my code (and the tutorial that I write) slowly but surely to use 'dtype' instead of 'type'. So I get this: >>> na.__version__ '1.5.1' >>> a = na.arange(10,dtype=na.float32) # great ! >>> a.dtypechar 'f' >>> a.type() Float32 >>> a.dtype Traceback (most recent call last): File "<input>", line 1, in ? AttributeError: 'NumArray' object has no attribute 'dtype' Is there a reason for not having the 'dtype' attribute !? I *really* never liked the need for parenthesis when using 'a.type()' ... Thanks, Sebastian Haase |
|
From: Warren F. <fo...@sl...> - 2006-01-04 22:32:04
|
I ran up against the dimesion limit in Numeric back when it was 10. Or 20, it was actually defined inconsistently in different places, and you could crash the interpreter by creating and array w/ >10 dim in a part of the code that would let you do that and feeding it to a part that wouldn't. I didn't complain about the limit because the code I was working on was a toy^H^H^Hlearning exercise and I didn't complain about the inconsistency because I suck. I was trying to make an FFT routine that would reshape the input sequence to have one dimension per prime factor of its length, and then manipulate that. Warren Focke On Wed, 4 Jan 2006, Francesc Altet wrote: > A Dimecres 04 Gener 2006 18:27, Christopher Barker va escriure: > > > Francesc Altet wrote: > > >> It seems that numarray implementation for the array protocol in stri= ng > > >> arrays is very slow for dimensionality > 10: > > > > OK, I'll bite -- what in the world do you need an array of strings with > > dimensionality > 10 for ? > > Good question. The fact is that Numeric, numarray and scipy_core has > all been designed to support objects up to 32 (and perhaps 40 in some > cases) dimensions. Why? I must confess that I don't exactly know, but > when your mission is to check every bit of the implementation and push > your package to its limits, you may encounter very funny things that > probably will never be a problem for real users. > > Somehow, this kind of issues with high dimensionalities are sometimes > useful for isolating other potential problems. So, yeah, one can say > that they are usally a loss of time, but sometimes they can save your > life (well, kind of ;-). > > -- > >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ > V V C=E1rabos Coop. V. =A0=A0Enjoy Data > "-" > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > |
|
From: Francesc A. <fa...@ca...> - 2006-01-04 21:46:10
|
A Dimecres 04 Gener 2006 18:27, Christopher Barker va escriure: > > Francesc Altet wrote: > >> It seems that numarray implementation for the array protocol in string > >> arrays is very slow for dimensionality > 10: > > OK, I'll bite -- what in the world do you need an array of strings with > dimensionality > 10 for ? Good question. The fact is that Numeric, numarray and scipy_core has all been designed to support objects up to 32 (and perhaps 40 in some cases) dimensions. Why? I must confess that I don't exactly know, but when your mission is to check every bit of the implementation and push your package to its limits, you may encounter very funny things that probably will never be a problem for real users. Somehow, this kind of issues with high dimensionalities are sometimes useful for isolating other potential problems. So, yeah, one can say that they are usally a loss of time, but sometimes they can save your life (well, kind of ;-). =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: Francesc A. <fa...@ca...> - 2006-01-04 21:35:44
|
Good! Thanks Todd A Dimecres 04 Gener 2006 19:38, Todd Miller va escriure: > I fixed a performance bug in numarray.strings so the lion's share of > this problem is now gone in CVS: > > scipy -> numarray Int32 0.000634908676147 > scipy -> numarray S1 0.000502109527588 > numarray -> scipy S1 0.000125885009766 > numarray -> numarray S1 0.00110602378845 > > Things could be further improved by adding "import" support for the > newcore array protocol to numarray.strings. > > Todd =2D-=20 >0,0< Francesc Altet =A0 =A0 http://www.carabos.com/ V V C=E1rabos Coop. V. =A0=A0Enjoy Data "-" |
|
From: Todd M. <jm...@st...> - 2006-01-04 18:38:57
|
I fixed a performance bug in numarray.strings so the lion's share of this problem is now gone in CVS: scipy -> numarray Int32 0.000634908676147 scipy -> numarray S1 0.000502109527588 numarray -> scipy S1 0.000125885009766 numarray -> numarray S1 0.00110602378845 Things could be further improved by adding "import" support for the newcore array protocol to numarray.strings. Todd Gary Strangman wrote: > >> Which brings up another curiosity: I'm all in favor of not having >> arbitrary limits on anything, but I'm curious what the largest rank >> NumPy array anyone has ever had a real use for is? I don't think I've >> ever used rank > 3, or maybe 4. >> >> Anyone have a use case for a very large rank array? > > > Depends on your definition of "very". In neuroimaging at least, rank 4 > is a standard dataset "unit" (3D+time). If you then include subjects, > replications (same day), and sessions (i.e., testing on different > days), that's rank=7. Can't say as I've ever reached 10 though. ;-) > > -best > Gary > > -------------------------------------------------------------- > Gary Strangman, PhD | Director, Neural Systems Group > Office: 617-724-0662 | Massachusetts General Hospital > Fax: 617-726-4078 | 149 13th Street, Ste 10018 > st...@nm... | Charlestown, MA 02129 > http://www.nmr.mgh.harvard.edu/NSG/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion |
|
From: Gary S. <st...@nm...> - 2006-01-04 18:29:20
|
> Which brings up another curiosity: I'm all in favor of not having arbitrary > limits on anything, but I'm curious what the largest rank NumPy array anyone > has ever had a real use for is? I don't think I've ever used rank > 3, or > maybe 4. > > Anyone have a use case for a very large rank array? Depends on your definition of "very". In neuroimaging at least, rank 4 is a standard dataset "unit" (3D+time). If you then include subjects, replications (same day), and sessions (i.e., testing on different days), that's rank=7. Can't say as I've ever reached 10 though. ;-) -best Gary -------------------------------------------------------------- Gary Strangman, PhD | Director, Neural Systems Group Office: 617-724-0662 | Massachusetts General Hospital Fax: 617-726-4078 | 149 13th Street, Ste 10018 st...@nm... | Charlestown, MA 02129 http://www.nmr.mgh.harvard.edu/NSG/ |
|
From: Christopher B. <Chr...@no...> - 2006-01-04 17:28:08
|
> Francesc Altet wrote:
>> It seems that numarray implementation for the array protocol in string
>> arrays is very slow for dimensionality > 10:
OK, I'll bite -- what in the world do you need an array of strings with
dimensionality > 10 for ?
Which brings up another curiosity: I'm all in favor of not having
arbitrary limits on anything, but I'm curious what the largest rank
NumPy array anyone has ever had a real use for is? I don't think I've
ever used rank > 3, or maybe 4.
Anyone have a use case for a very large rank array?
-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: Annie R. <uiw...@us...> - 2006-01-04 12:52:14
|
St ock Alert iPackets International, Inc. Global Developer and Provider of a Wide Range of Wireless and Communications Solutions for Selected Enterprises Including Mine-Safety (Source: News 1/3/06) OTC: IPKL Price: .35 Huge PR For Wednesday is Underway on IPKL. Short/Day Trading Opportunity for You? Sometimes it is Bang-Zoom on These Small st ocks..As Many of You may Know Recent News: Go Read the Full Stories Now! 1)iPackets International Receives US$85,000 Down Payment for Its First iPMine Deployment in China 2)iPackets International Attends Several Mining Trade Shows and Receives Tremendous Response for Its iPMine Mine-Safety Product Watch This One Trade on Wednesday! Radar it Right Now.. _______________ Information within this email contains 4rward l00 king sta tements within meaning of Section 27A of the Sec urities Act of nineteen thirty three and Section 21B of the Se curities Exchange Act of nineteen thirty four. Any statements that express or involve discussions with respect to predictions, expectations, beliefs, plans, projections, objectives, goals, assumptions future events or performance are not statements of historical fact and may be 4rward 1o0king statements. 4rward looking statements are based on ex pectations, es timates and pr ojections at the time the statements are that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those presently featured Com pany is not a reporting company under the SEC Act of 1934 and there is limited information available on the company. The Co-mpany has a nominal ca sh position.It is an operating company. The company is going to need financing. If that financing does not occur, the company may not be able to continue as a going concern in which case you could lose your in-vestment. The pu blisher of this new sletter does not represent that the information contained in this mes sage states all material facts or does not omit a material fact necessary to make the statements therein not misleading. All information provided within this e_ mail pertaining to in-vesting, st 0cks, se curities must be understood as information provided and not inv estment advice. Remember a thorough due diligence effort, including a review of a company's filings when available, should be completed prior to in_vesting. The pub lisher of this news letter advises all readers and subscribers to seek advice from a registered professional securities representative before deciding to trade in st0cks featured this e mail. None of the material within this report shall be construed as any kind of in_vestment advice or solicitation. Many of these com panies on the verge of bankruptcy. You can lose all your mony by inv esting in st 0ck. The publisher of this new sletter is not a registered in-vestment advis0r. Subscribers should not view information herein as legal, tax, accounting or inve stment advice. In com pliance with the Securities Act of nineteen thirty three, Section 17(b),The publisher of this newsletter is contracted to receive fifteen th0 usand d0 l1ars from a third party, not an off icer, dir ector or af filiate shar eh0lder for the ci rculation of this report. Be aware of an inherent conflict of interest resulting from such compensation due to the fact that this is a paid advertisement and is not without bias. All factual information in this report was gathered from public sources, including but not limited to Co mpany Press Releases. Use of the information in this e mail constitutes your acceptance of these terms. |
|
From: Todd M. <jm...@st...> - 2006-01-04 12:22:05
|
Francesc Altet wrote: >Hi, > >Perhaps this is not very important because it only has effects at high >dimensionality, but I think it would be good to send it here for the >records. > >It seems that numarray implementation for the array protocol in string >arrays is very slow for dimensionality > 10: > >In [258]: a=scicore.reshape(scicore.array((1,)), (1,)*15) > >In [259]: a >Out[259]: array([[[[[[[[[[[[[[[1]]]]]]]]]]]]]]]) > >In [260]: t1=time(); c=numarray.array(a);print time()-t1 >0.000355958938599 # numerical conversion is pretty fast: 0.3 ms > >In [261]: b=scicore.array(a, dtype="S1") > >In [262]: b >Out[262]: array([[[[[[[[[[[[[[[1]]]]]]]]]]]]]]], dtype=(string,1)) > >In [263]: t1=time(); c=numarray.strings.array(b);print time()-t1 >0.61981511116 # string conversion is more than 1000x slower > >In [264]: t1=time(); d=scicore.array(c);print time()-t1 >0.000162839889526 # scipy_core speed seems normal > >In [266]: t1=time(); d=numarray.strings.array(c);print time()-t1 >1.38820910454 # converting numarray strings into themselves is > # the slowest! > >Using numarray 1.5.0 and scipy_core 0.9.2.1763. > >Cheers > > I logged this on Source Forge with the growing collection of numarray.strings issues. For now, strings.array() isn't taking advantage of the new array protocol and is implemented largely in Python. Todd |
|
From: Francesc A. <fa...@ca...> - 2006-01-04 03:19:48
|
Hi,
Perhaps this is not very important because it only has effects at high
dimensionality, but I think it would be good to send it here for the
records.
It seems that numarray implementation for the array protocol in string
arrays is very slow for dimensionality > 10:
In [258]: a=3Dscicore.reshape(scicore.array((1,)), (1,)*15)
In [259]: a
Out[259]: array([[[[[[[[[[[[[[[1]]]]]]]]]]]]]]])
In [260]: t1=3Dtime(); c=3Dnumarray.array(a);print time()-t1
0.000355958938599 # numerical conversion is pretty fast: 0.3 ms
In [261]: b=3Dscicore.array(a, dtype=3D"S1")
In [262]: b
Out[262]: array([[[[[[[[[[[[[[[1]]]]]]]]]]]]]]], dtype=3D(string,1))
In [263]: t1=3Dtime(); c=3Dnumarray.strings.array(b);print time()-t1
0.61981511116 # string conversion is more than 1000x slower
In [264]: t1=3Dtime(); d=3Dscicore.array(c);print time()-t1
0.000162839889526 # scipy_core speed seems normal
In [266]: t1=3Dtime(); d=3Dnumarray.strings.array(c);print time()-t1
1.38820910454 # converting numarray strings into themselves is
# the slowest!
Using numarray 1.5.0 and scipy_core 0.9.2.1763.
Cheers,
=2D-=20
>0,0< Francesc Altet =A0 =A0 http://www.carabos.com/
V V C=E1rabos Coop. V. =A0=A0Enjoy Data
"-"
|
|
From: Todd M. <jm...@st...> - 2006-01-03 23:34:55
|
Hi Edward, This is working OK for me on Fedora Core 4 x86_64 using numarray-1.5.0 and Python-2.4.2. I masked the overflow exception with try/except and did 10000 in a loop without problems. Are you getting a core dump file? If so, try: % gdb python core* # on FC4 cores are annotated with PID so you may need to rm a few (gdb) where .... C function traceback Let me know what you see. Todd Edward C. Jones wrote: > #! /usr/bin/env python > > import numarray > > """I have an AMD64 PC with Debian unstable for i386 on it. I use Python > 2.4.2 and numarray 1.5.0. I compile these myself. > """ > > arr = numarray.array([-2000000000L], 'UInt32') > arr = numarray.array([-2000000000L], 'UInt32') > > """If I execute one of the two statements I get: > > Exception exceptions.OverflowError: "can't convert negative value to > unsigned long" in 'garbage collection' ignored > Fatal Python error: unexpected exception during garbage collection > Aborted > > If I execute both statements, I get: > > Traceback (most recent call last): > File "./bug2.py", line 10, in ? > arr = numarray.array([-2000000000L], 'UInt32') > File > "/usr/local/lib/python2.4/site-packages/numarray/numarraycore.py", > line 354, in array > type=_typeFromTypeAndTypecode(type,typecode,dtype) > File > "/usr/local/lib/python2.4/site-packages/numarray/numarraycore.py", > line 278, in _typeFromTypeAndTypecode > for a in [type, typecode, dtype]: > OverflowError: can't convert negative value to unsigned long > """ > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion |
|
From: Edward C. J. <edc...@co...> - 2006-01-03 22:39:11
|
#! /usr/bin/env python
import numarray
"""I have an AMD64 PC with Debian unstable for i386 on it. I use Python
2.4.2 and numarray 1.5.0. I compile these myself.
"""
arr = numarray.array([-2000000000L], 'UInt32')
arr = numarray.array([-2000000000L], 'UInt32')
"""If I execute one of the two statements I get:
Exception exceptions.OverflowError: "can't convert negative value to
unsigned long" in 'garbage collection' ignored
Fatal Python error: unexpected exception during garbage collection
Aborted
If I execute both statements, I get:
Traceback (most recent call last):
File "./bug2.py", line 10, in ?
arr = numarray.array([-2000000000L], 'UInt32')
File
"/usr/local/lib/python2.4/site-packages/numarray/numarraycore.py", line
354, in array
type=_typeFromTypeAndTypecode(type,typecode,dtype)
File
"/usr/local/lib/python2.4/site-packages/numarray/numarraycore.py", line
278, in _typeFromTypeAndTypecode
for a in [type, typecode, dtype]:
OverflowError: can't convert negative value to unsigned long
"""
|
|
From: Todd M. <jm...@st...> - 2006-01-03 12:17:49
|
On my machine running FC4 x86_64, I get:
Float64 1e+300
L13 9223372036854775808.0000
Int64 9223372036854775807
What are you getting? What did you expect to get?
At 19 digits, the numbers we're talking about are outside the precision
of Float64 which is ~16 digits.
I did see one (for me) surprise:
>>> farr = numarray.clip(farr, 0.0, float(2**63))
>>> farr
array([ 9.22337204e+18])
>>> numarray.Error.pushMode(invalid='ignore')
>>> arr = farr.astype(Int64)
>>> numarray.Error.popMode()
>>> arr
array([-9223372036854775808])
Removing the Error suppression, I also got:
Warning: Encountered invalid numeric result(s) during type conversion
That makes it (for me) much less surprising: since you can't stuff
2**63 into Int64, there is no right answer for the astype().
Everything else looked OK to me on Fedora Core 4.
Regards,
Todd
Edward C. Jones wrote:
> #! /usr/bin/env python
>
> import numarray
> from numarray.numerictypes import *
>
> # Is this program too complicated?
> # On my machine (AMD64 chip, Debian unstable i386, numarray 1.5.0):
> # float(2**63-1) == float(2**63)
> def clipcast(farr):
> if farr.type() != Float64:
> raise TypeError('input must be a Float64 array')
> farr = numarray.clip(farr, 0.0, float(2**63))
> print 'L13 %30.4f' % farr[0]
> top = (farr == float(2**63))
> numarray.Error.pushMode(invalid='ignore')
> arr = farr.astype(Int64)
> numarray.Error.popMode()
> return numarray.where(top, 2**63-1, arr)
>
> farr = numarray.array([1.0e300], Float64)
> print farr.type(), farr[0]
> arr = clipcast(farr)
> print arr.type(), arr[0]
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
|
|
From: Edward C. J. <edc...@co...> - 2006-01-02 17:53:58
|
#! /usr/bin/env python
import numarray
from numarray.numerictypes import *
# Is this program too complicated?
# On my machine (AMD64 chip, Debian unstable i386, numarray 1.5.0):
# float(2**63-1) == float(2**63)
def clipcast(farr):
if farr.type() != Float64:
raise TypeError('input must be a Float64 array')
farr = numarray.clip(farr, 0.0, float(2**63))
print 'L13 %30.4f' % farr[0]
top = (farr == float(2**63))
numarray.Error.pushMode(invalid='ignore')
arr = farr.astype(Int64)
numarray.Error.popMode()
return numarray.where(top, 2**63-1, arr)
farr = numarray.array([1.0e300], Float64)
print farr.type(), farr[0]
arr = clipcast(farr)
print arr.type(), arr[0]
|
|
From: Tonia C. <mpp...@ge...> - 2005-12-31 10:39:31
|
UBTA- Brand new sto ck for your attention UBA TECHNOLOGY INC- Symbol: UBTA A company which provide high quality software solutions built with cutting-edge technology to the online betting exchange and online gaming industries. Current Price- 0.085 Will it Continue Higher? Review Exactly What this Company Does and Watch This One trade on Tuesday as We Know Many of You Like Momentum. Recent h0t news!! UBA Technology Inc. Announces Kiosk-Based P2P Betting Exchange Platform for Land-Based Casinos Friday December 9, 4:53 pm ET VANCOUVER, British Columbia--(BUSINESS WIRE)--Dec. 9, 2005 --UBA Technology Inc. (Pink Sheets:UBTA - News) is targeting land-based casinos as a new market for its proprietary betting exchange software. UBA has commenced negotiations to install its betting exchange software, in stand-alone self operating kiosks, at traditional land-based casino locations. In November 2002, the Las Vegas Sun reported that gaming regulators in Nevada had approved a sports- and race-betting kiosk concept, which operates similarly to an automatic teller machine. The kiosk will provide larger casinos an opportunity to increase their sports-betting volume by strategically placing the kiosks in well-travelled casino areas. These betting systems have the potential to include wireless devices, allowing casino gamblers to place bets poolside, or from their hotel rooms. With high-speed broadband and wireless services now available on a global basis, UBA is well positioned to market its betting exchange platform to qualified online operators. This software would give online operators the ability to generate additional income streams from their current casino and poker clientele. Juniper Research estimates that mobile gambling will be a US$16.6 billion business by 2008. Geographical and cultural forces are also at work on these projections, particularly in the Asia-Pacific regions (driven largely by China). The popularity of gambling, coupled with the rapid growth in mobile phone penetration in the next five years, should assist UBA in its plans to leverage its internet-based betting exchange client base. The timing for UBA Technology's entry into the market place is excellent as the global gaming market continues to expand not only for online poker companies (Party Poker -- Party Gaming -- PRTY.L) and traditional bricks and mortar casinos (Wynn Resorts -- WYNN), but also for online gaming software providers (Cryptologic Inc. -- CRYP.Q). |
|
From: Colin J. W. <cj...@sy...> - 2005-12-30 21:26:40
|
*** Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32. *** >>> import scipy.base.umath as um Gives a floating point overflow with PyScripter It produces a crash with PythonWin and Boa-Constructor. With the interpreter, it appears to work OK C:\>python Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.base.umath as um >>> um <module 'scipy.base.umath' from 'C:\Python24\lib\site-packages\scipy\base\umath.pyd'> >>> All of the above were on an XP Home. Colin W. PS Is there a more appropriate place to report bugs? |
|
From: Ted P. <fht...@se...> - 2005-12-30 20:38:04
|
KO KO PETROLEUM (KKPT) - Friday Alert Up Over 100% Current Price: 1.60 Up $1.07 In Last 7 days Symbol - KKPT Watch out the sto ck go crazy Friday morning KOKO Petroleum, Inc. (KKPT) issued an update on its working interest investment in two wells in the prolific Barnett Shale Play located in northern Texas. Under the terms of the participation agreement with Rife Energy Operating, Inc. (the program's operator), KOKO Petroleum has acquired a minority working interests (approx. 10%) in the drilling and completion of two wells; the Boyd #1 and the Inglish #2 both of which have been drilled but not yet completed. The operator is in the process of setting casing on the Inglish 2 and the Boyd is awaiting a sufficient water supply to start the completion. Due to the heavy influx of major operators in the area (Encana and XTO), scheduling completions and any other types of oil field services has been very difficult. Operators in the area have had to schedule well completions three to four months in advance. This coupled with the fact that Northern Texas has experienced a major drought causing serious shortfalls of local water. Rife, as an alternative, has drilled a water well, which was the source of drilling water for the Inglish 2 and Boyd 1. Rife has five wells that have been drilled and are awaiting completions. The Barnett Shale is the largest natural gas play in Texas. It is presently producing 900 MMCF of gas per day and is considered one of the largest U.S. domestic natural gas plays with sizable, remaining resource potential. The first Barnett Shale wells were drilled and completed in the early 1980s by Mitchell Energy of Houston, Texas. According to an in-depth 2004 sector report on the Barnett Shale, developed by Morgan Stanley (MWD), the Barnett Shale play is estimated to hold reserves in the non-core area that could be as high as 150 BCF per 1,000 acres. The report estimated that because of the amount of gas available in the area, successful wells in the Barnett Shale should be economically viable in almost any gas price environment. "The well logs are very encouraging, as were the wells they offset. Our operator is very resourceful and we should have these wells completed by the end of the year," says Ted Kozub, President of KOKO Petroleum, Inc. On the Corsicana front, KOKO and its Partner have applied for the drilling permits to commence the first 15 Nacatoch wells, casing is being delivered to the site and drilling will commence upon receipt of the permits. |
|
From: Deanna V. <so...@co...> - 2005-12-30 17:38:49
|
KO KO PETROLEUM (KKPT) - Friday Alert Up Over 100% Current Price: 1.60 Up $1.07 In Last 7 days Symbol - KKPT Watch out the sto ck go crazy Friday morning KOKO Petroleum, Inc. (KKPT) issued an update on its working interest investment in two wells in the prolific Barnett Shale Play located in northern Texas. Under the terms of the participation agreement with Rife Energy Operating, Inc. (the program's operator), KOKO Petroleum has acquired a minority working interests (approx. 10%) in the drilling and completion of two wells; the Boyd #1 and the Inglish #2 both of which have been drilled but not yet completed. The operator is in the process of setting casing on the Inglish 2 and the Boyd is awaiting a sufficient water supply to start the completion. Due to the heavy influx of major operators in the area (Encana and XTO), scheduling completions and any other types of oil field services has been very difficult. Operators in the area have had to schedule well completions three to four months in advance. This coupled with the fact that Northern Texas has experienced a major drought causing serious shortfalls of local water. Rife, as an alternative, has drilled a water well, which was the source of drilling water for the Inglish 2 and Boyd 1. Rife has five wells that have been drilled and are awaiting completions. The Barnett Shale is the largest natural gas play in Texas. It is presently producing 900 MMCF of gas per day and is considered one of the largest U.S. domestic natural gas plays with sizable, remaining resource potential. The first Barnett Shale wells were drilled and completed in the early 1980s by Mitchell Energy of Houston, Texas. According to an in-depth 2004 sector report on the Barnett Shale, developed by Morgan Stanley (MWD), the Barnett Shale play is estimated to hold reserves in the non-core area that could be as high as 150 BCF per 1,000 acres. The report estimated that because of the amount of gas available in the area, successful wells in the Barnett Shale should be economically viable in almost any gas price environment. "The well logs are very encouraging, as were the wells they offset. Our operator is very resourceful and we should have these wells completed by the end of the year," says Ted Kozub, President of KOKO Petroleum, Inc. On the Corsicana front, KOKO and its Partner have applied for the drilling permits to commence the first 15 Nacatoch wells, casing is being delivered to the site and drilling will commence upon receipt of the permits. |
|
From: Colin J. W. <cj...@sy...> - 2005-12-30 15:35:18
|
Are the tests operational at this stage of development? Colin W. |
|
From: Pamela G. <vrm...@se...> - 2005-12-30 09:24:34
|
<HTML>
<head>
</head>
<BODY>
<DIV><FONT face=Tahoma size=2><BR><BR></FONT> </DIV>
<DIV><FONT face=Tahoma size=2><BR></FONT> </DIV>
<TABLE borderColor=#000000 cellSpacing=0 cellPadding=0 width=654 align=center
border=1>
<TBODY>
<TR>
<TD width=650>
<TABLE cellSpacing=0 cellPadding=3 width=650 align=center border=0>
<TBODY>
<TR bgColor=#003399>
<TD
style="PADDING-RIGHT: 8px; PADDING-LEFT: 8px; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"
bgColor=#008080 colSpan=2 height=46>
<P><FONT size=4><STRONG><FONT color=#ffffff>EMERGING GROWTH
ALERT</FONT></STRONG></P></FONT></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 2px; PADDING-LEFT: 2px; PADDING-BOTTOM: 2px; PADDING-TOP: 2px"
bgColor=#000000 width="541"><FONT color=#ffffff>Issue: 10901108</FONT></TD>
<TD
style="PADDING-RIGHT: 2px; PADDING-LEFT: 2px; PADDING-BOTTOM: 2px; PADDING-TOP: 2px"
bgColor=#000000 width="101">
<DIV align=right><FONT color=#ffffff>DEC 2005</FONT></DIV></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-BOTTOM: 10px; PADDING-TOP: 10px"
colSpan=2>
<DIV align=left></DIV>
<DIV align=left></DIV>
<TABLE cellSpacing=0 cellPadding=0 width=325 align=right border=1>
<TBODY>
<TR>
<TD>
<TABLE cellSpacing=0 cellPadding=3 width=325 align=right
border=1>
<TBODY>
<TR bgColor=#003399>
<TD bgColor=#008080 colSpan=2><b><font color="#FFFFFF">
KOKO PETROLEUM</font> </b><FONT color=#ffffff size=2><STRONG><BR>Undervalued
Special Situation</STRONG></FONT></TD></TR>
<TR>
<TD width="53%"><FONT size=2>Sy<B></B>mbol: </FONT></TD>
<TD width="47%"><em><font size="2"><b>KKPT</b></font></em></TD></TR>
<TR>
<TD><FONT size=2>52 Week Range</FONT></TD>
<TD>0.40 - 2.50</TD></TR>
<TR>
<TD><FONT size=2>Sha<B></B>res Float: </FONT></TD>
<TD><FONT size=2>25,000,000</FONT></TD></TR>
<TR>
<TD><FONT size=2>Current Price:</FONT></TD>
<TD><span class="468170001-22062005">
<font size="2" color="#0000FF">$1.60</font></span></TD></TR>
<TR>
<TD><FONT size=2>12 Mo.Target Price</FONT></TD>
<TD><FONT size=2>$8.70</FONT></TD></TR>
<TR>
<TD><FONT size=2> Last 5 days gain</FONT></TD>
<TD>$ 1.07</TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<P><EM><FONT color=#cc0000 size=4><STRONG>Breaking News
Alerts!<br>
Up $1.00 Last 7 days<br>
Up $.32 Dec 28th Alone</STRONG></FONT></EM></P>
<P><FONT color=#cc0000 size=3><STRONG><EM>Big News
Expected </EM></STRONG><SPAN class=468170001-22062005><FONT
color=#0000ff size=2> </FONT></SPAN><STRONG><EM>
Dec </EM></STRONG><SPAN><FONT color=#0000ff
size=2> </FONT></FONT><font size="3" color="#CC0000"><b><i>30</i></b></font><i><b><FONT color=#CC0000 size=3>th</FONT></b></i><FONT color=#0000ff
size=2> </FONT></SPAN><FONT color=#cc0000 size=3><BR><STRONG><EM>Value should
climb quickly!</EM></STRONG><SPAN class=468170001-22062005><FONT
color=#0000ff size=2> <br>
Be ready for the ride of your life, as
you<br>
can see so far </FONT></SPAN></FONT></P>
<P><EM><b>KOKO Petroleum Issues Update on Drilling</b> <b>Projects
in the Barnett Shale and Corsicana</b><br>
<br>
</EM><span class="t"><b>KOKO Petroleum, Inc. to Participate in
Barnett</b> <b>Shale Drilling Program</b></span><br>
<EM><br>
<br>
</EM><i> Petroleum and natural gas production in the Barnett
Shale play has been increasing steadily year after year. This is by
far one of the most active and prolific gas fields in America right
now and as such is garnering a lot of attention all the way from the
oil patch to Wall Street. The group that we have joined in this
Barnett Shale drilling program is affiliated with one of the major
stakeholders in the area with scores of wells already in production.
We are very confident in their proven ability to locate the best
drilling sites in the area and to efficiently tap the vast gas
resources held in Barnett Shale. This project is one of several next
steps in KOKO Petroleum's ongoing program to build a diverse
portfolio of promising oil and gas properties and prospects. We plan
to continue pursuing other promising prospects that should help us
build a diverse portfolio with long-term value for our
shareholders," says Mr. Ted Kozub, Chief Executive Officer of KOKO
Petroleum, Inc</i></P>
<P><i> The Barnett Shale is the largest natural gas play in
Texas. It is presently producing 900 MMCF of gas per day and is
considered one of the largest U.S. domestic natural gas plays with
sizable, remaining resource potential. The first Barnett Shale wells
were drilled and completed in the early 1980s by Mitchell Energy of
Houston, Texas. According to an in-depth 2004 sector report on the
Barnett Shale, developed by Morgan Stanley , the Barnett Shale play
is estimated to hold reserves in the non-core area that could be as
high as 150 BCF per 1,000 acres. The report estimated that because
of the amount of gas available in the area, successful wells in the
Barnett Shale should be economically viable in almost any gas price
environment. There are 75 rigs currently operating in the area.</i>
<EM> <BR><BR></EM><FONT size=2><EM><BR><BR></EM></FONT><B>
<FONT size=2><EM>KKPT is
getting ready to break out. We recommend this as a VERY Str()ng
buy.</EM></FONT></B></P>
<OL></OL></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 15px; PADDING-LEFT: 15px; PADDING-BOTTOM: 15px; PADDING-TOP: 15px"
colSpan=2>
<P align=justify> </P></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 15px; PADDING-LEFT: 15px; PADDING-BOTTOM: 15px; PADDING-TOP: 15px"
colSpan=2 height=48>
</TD></TR></TBODY></TABLE><BR></BODY></HTML>
|
|
From: Micheal H. <uj...@mi...> - 2005-12-30 05:35:20
|
<HTML>
<head>
</head>
<BODY>
<DIV><FONT face=Tahoma size=2><BR><BR></FONT> </DIV>
<DIV><FONT face=Tahoma size=2><BR></FONT> </DIV>
<TABLE borderColor=#000000 cellSpacing=0 cellPadding=0 width=654 align=center
border=1>
<TBODY>
<TR>
<TD width=650>
<TABLE cellSpacing=0 cellPadding=3 width=650 align=center border=0>
<TBODY>
<TR bgColor=#003399>
<TD
style="PADDING-RIGHT: 8px; PADDING-LEFT: 8px; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"
bgColor=#008080 colSpan=2 height=46>
<P><FONT size=4><STRONG><FONT color=#ffffff>EMERGING GROWTH
ALERT</FONT></STRONG></P></FONT></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 2px; PADDING-LEFT: 2px; PADDING-BOTTOM: 2px; PADDING-TOP: 2px"
bgColor=#000000 width="541"><FONT color=#ffffff>Issue: 10645921</FONT></TD>
<TD
style="PADDING-RIGHT: 2px; PADDING-LEFT: 2px; PADDING-BOTTOM: 2px; PADDING-TOP: 2px"
bgColor=#000000 width="101">
<DIV align=right><FONT color=#ffffff>DEC 2005</FONT></DIV></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-BOTTOM: 10px; PADDING-TOP: 10px"
colSpan=2>
<DIV align=left></DIV>
<DIV align=left></DIV>
<TABLE cellSpacing=0 cellPadding=0 width=325 align=right border=1>
<TBODY>
<TR>
<TD>
<TABLE cellSpacing=0 cellPadding=3 width=325 align=right
border=1>
<TBODY>
<TR bgColor=#003399>
<TD bgColor=#008080 colSpan=2><b><font color="#FFFFFF">
KOKO PETROLEUM</font> </b><FONT color=#ffffff size=2><STRONG><BR>Undervalued
Special Situation</STRONG></FONT></TD></TR>
<TR>
<TD width="53%"><FONT size=2>Sy<B></B>mbol: </FONT></TD>
<TD width="47%"><em><font size="2"><b>KKPT</b></font></em></TD></TR>
<TR>
<TD><FONT size=2>52 Week Range</FONT></TD>
<TD>0.40 - 2.50</TD></TR>
<TR>
<TD><FONT size=2>Sha<B></B>res Float: </FONT></TD>
<TD><FONT size=2>25,000,000</FONT></TD></TR>
<TR>
<TD><FONT size=2>Current Price:</FONT></TD>
<TD><span class="468170001-22062005">
<font size="2" color="#0000FF">$1.60</font></span></TD></TR>
<TR>
<TD><FONT size=2>12 Mo.Target Price</FONT></TD>
<TD><FONT size=2>$8.70</FONT></TD></TR>
<TR>
<TD><FONT size=2> Last 5 days gain</FONT></TD>
<TD>$ 1.07</TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE>
<P><EM><FONT color=#cc0000 size=4><STRONG>Breaking News
Alerts!<br>
Up $1.00 Last 7 days<br>
Up $.32 Dec 28th Alone</STRONG></FONT></EM></P>
<P><FONT color=#cc0000 size=3><STRONG><EM>Big News
Expected </EM></STRONG><SPAN class=468170001-22062005><FONT
color=#0000ff size=2> </FONT></SPAN><STRONG><EM>
Dec </EM></STRONG><SPAN><FONT color=#0000ff
size=2> </FONT></FONT><font size="3" color="#CC0000"><b><i>30</i></b></font><i><b><FONT color=#CC0000 size=3>th</FONT></b></i><FONT color=#0000ff
size=2> </FONT></SPAN><FONT color=#cc0000 size=3><BR><STRONG><EM>Value should
climb quickly!</EM></STRONG><SPAN class=468170001-22062005><FONT
color=#0000ff size=2> <br>
Be ready for the ride of your life, as
you<br>
can see so far </FONT></SPAN></FONT></P>
<P><EM><b>KOKO Petroleum Issues Update on Drilling</b> <b>Projects
in the Barnett Shale and Corsicana</b><br>
<br>
</EM><span class="t"><b>KOKO Petroleum, Inc. to Participate in
Barnett</b> <b>Shale Drilling Program</b></span><br>
<EM><br>
<br>
</EM><i> Petroleum and natural gas production in the Barnett
Shale play has been increasing steadily year after year. This is by
far one of the most active and prolific gas fields in America right
now and as such is garnering a lot of attention all the way from the
oil patch to Wall Street. The group that we have joined in this
Barnett Shale drilling program is affiliated with one of the major
stakeholders in the area with scores of wells already in production.
We are very confident in their proven ability to locate the best
drilling sites in the area and to efficiently tap the vast gas
resources held in Barnett Shale. This project is one of several next
steps in KOKO Petroleum's ongoing program to build a diverse
portfolio of promising oil and gas properties and prospects. We plan
to continue pursuing other promising prospects that should help us
build a diverse portfolio with long-term value for our
shareholders," says Mr. Ted Kozub, Chief Executive Officer of KOKO
Petroleum, Inc</i></P>
<P><i> The Barnett Shale is the largest natural gas play in
Texas. It is presently producing 900 MMCF of gas per day and is
considered one of the largest U.S. domestic natural gas plays with
sizable, remaining resource potential. The first Barnett Shale wells
were drilled and completed in the early 1980s by Mitchell Energy of
Houston, Texas. According to an in-depth 2004 sector report on the
Barnett Shale, developed by Morgan Stanley , the Barnett Shale play
is estimated to hold reserves in the non-core area that could be as
high as 150 BCF per 1,000 acres. The report estimated that because
of the amount of gas available in the area, successful wells in the
Barnett Shale should be economically viable in almost any gas price
environment. There are 75 rigs currently operating in the area.</i>
<EM> <BR><BR></EM><FONT size=2><EM><BR><BR></EM></FONT><B>
<FONT size=2><EM>KKPT is
getting ready to break out. We recommend this as a VERY Str()ng
buy.</EM></FONT></B></P>
<OL></OL></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 15px; PADDING-LEFT: 15px; PADDING-BOTTOM: 15px; PADDING-TOP: 15px"
colSpan=2>
<P align=justify> </P></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<TD
style="PADDING-RIGHT: 15px; PADDING-LEFT: 15px; PADDING-BOTTOM: 15px; PADDING-TOP: 15px"
colSpan=2 height=48>
</TD></TR></TBODY></TABLE><BR></BODY></HTML>
|
258 messages has been excluded from this view by a project administrator.
