numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story: updated

[Rick W. <rl...@st...>]

On Mon, 26 Jul 2004, Russell E Owen wrote:

> Overall this sounds great.
>
> However, I am still strongly against attribute access.
>
> [...]
>
> In this case there is another mechanism that is more natural, has no
> funny corner cases, and is much more powerful. Its only disadvantage
> is the need for typing for 4 extra characters. Saving 4 characters
> simply not sufficient reason to add this dubious feature.

I am sympathetic with Russell's point of view on this, but I do think
there is more to gain than just typing 4 additional characters.  When
you read code that is using the dictionary version of attributes, you
also are required to read and mentally parse those 4 additional
characters.  There is value to having clean, easily readable code that
goes well beyond saving a little extra typing.  If we didn't care about
that, we'd probably all be using Perl. :-)

Also, I like to use tab-completion during my interactive use of
Python.  I know how to make that work with attributes, even dynamically
created attributes like those for record arrays.  And it is really nice
to be able to type <tab> and have it fill in a name or give a list of
all the available columns.  Doing that with the string/dictionary
approach could be possible, I guess, but it is a lot trickier.

So I do think there are some good reasons for wanting attribute
access.  Whether they are strong enough to counter Russell's sensible
arguments about not cluttering up the interface and documentation, I'm
not sure.  My personal preference would be to get rid of the mapping
between blanks and underscore and to do no mapping of any kind.  Then
if a column has a name that maps to a legal Python variable, you can
access it with an attribute, and if it doesn't then you can't.  That
doesn't sound particular hard to understand or explain to me.
					Rick

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story: updated

[Russell E O. <rowen@u.washington.edu>]

At 8:11 PM +0200 2004-07-26, Francesc Alted wrote:
>...
>Supporting Rarr.field['home address'] and Rarr.field('home address') at the
>same time sounds unnecessary to me. Moreover having a
>Rarr.field('home_address')[32] (for example) looks a bit strange, and I
>think Rarr.field['home_address'][32] would be better. But I repeat, this is
>my personal feeling.
>
>I know that dropping support of __call__() in field will make the change
>backward incompatible, but perhaps now is a good time to define a better
>interface to the RecArray object. Another possibility maybe to raise a
>deprecation warning for such an use for a couple of releases.

I completely agree.

-- Russell

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story: updated

[Francesc A. <fa...@py...>]

A Dilluns 26 Juliol 2004 18:38, Russell E Owen va escriure:
> In this case there is another mechanism that is more natural, has no

Well, I guess that depends on what you understand as "natural". For example,
for me the "natural" way is adding attributes. However, I must recognize
that my point of view could be biased because this can be far more
advantageous in the context of large hierarchies of objects where you should
specify the complete path to go somewhere. This is typical on software to
treat XML documents or any kind of hierarchical data organization system.
For a relatively plain structure like RecArray I can understand that this
can be regarded as unnecessary. But nevertheless, its adoption continue to
sound appealling to me.

Anyway, I'd be happy with any decision (regarding field attribute adoption)
that would be made.

> I hope nobody takes offense. I certainly did not mean to imply that

Not at all. Discussing is a good (the best?) way to learn more :)

-- 
Francesc Alted

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story: updated

[Paul B. <ba...@st...>]

Russell E Owen wrote:
> At 11:43 AM -0400 2004-07-26, Perry Greenfield wrote:
> 
>> I'll try to see if I can address all the comments raised (please let 
>> me know
>> if I missed something).
>> ...(nice proposal elided)...
>> Any comments on these changes to the proposal? Are there those that are
>> opposed to supporting attribute access?
> 
> 
> Overall this sounds great.
> 
> However, I am still strongly against attribute access.
> 
> Attributes are usually meant for names that are intrinsic to the design 
> of an object, not to the user's "configuration" of the object. The name 
> mapping proposal isn't bad (thank you for keeping it simple!), but it 
> still feels like a kludge and it adds unnecessary clutter.
> 
> Your explanation of this limitations was clear, but still, imagine 
> putting that into the manual. It's a lot of "be careful of this" info. 
> That's a red flag to me. Imagine all the folks who don't read carefully. 
> Also imagine those who consider attribute access "the right way to do 
> it" and so want to clean up the limitations. I think you'll see a steady 
> stream of:
> "why can't I see my field..."
> "why can't you solve the collision problems"
> "why can't I use special character thus and so"
> 
> I personally feel that when a feature is hard to document or adds 
> strange limitations then it probably suggests a flawed design.
> 
> In this case there is another mechanism that is more natural, has no 
> funny corner cases, and is much more powerful. Its only disadvantage is 
> the need for typing for 4 extra characters. Saving 4 characters simply 
> not sufficient reason to add this dubious feature.
> 
> Before implementing attribute access I have two suggestions (which can 
> be taken singly or together):
> - Postpone the decision until after the rest of the proposal is 
> implemented. See if folks are happy with the mechanisms that are 
> available. I freely confess to hoping that momentum will then kill the 
> idea.
> - Discuss it on comp.lang.py. I'd like to see it aired more widely 
> before being adopted. So far I've seen just a few voices for it and a 
> few others against it. I realize it's not a democracy -- those who write 
> the code get the final say. I also realize some folks will always want 
> it, but that tension between simplicity and expressiveness is intrinsic 
> to any language. If you add everything anybody wants you get a mess, and 
> I want to avoid this mess while we still can.
> 
> I hope nobody takes offense. I certainly did not mean to imply that 
> those who wish attribute access are inferior in any way. There are 
> features of python I wish it had that will never occur. I honestly can 
> see the appeal of attributes; I was in favor of them myself, early on. 
> It adds an appealing expressiveness that makes some kind of code read 
> more naturally. But I personally feel it has too many limitations and is 
> unnecessary.

That pretty much sums up my opinion. :)

  -- Paul

-- 
Paul Barrett, PhD      Space Telescope Science Institute
Phone: 410-338-4475    ESS/Science Software Branch
FAX:   410-338-4767    Baltimore, MD 21218

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story: updated

[Francesc A. <fa...@py...>]

Hi,

Perry, your last proposal sounds good to me. Just a couple of comments.

A Dilluns 26 Juliol 2004 17:43, Perry Greenfield va escriure:
> 4) To address the suggestions of Russell and Francesc, I'm proposing that
> the current "field" method now become an object (callable to retain backward
> compatibility) that supports:
>    a) indexing by name or number (just like Records)
>    b) name to attribute mapping (with restrictions).
> So that this means 3 ways to do things! As far as attribute access goes, I
> simply do not want to throw arbitrary attributes into the main object
> itself. The use of field is comparatively clean since it has not other
> public attributes. Aside from mapping '_' into spaces, no other illegal
> attribute characters will be mapped. (The identifier/label suggestion by
> Colin Williams has some merit, but on the whole, I think it brings more
> baggage than benefit). The mapping algorithm is such that it tries to map
> the attribute to any field name that has either a ' ' or '_' in the place of
> '_' in the attribute name. While all '_' in the name will take precedence
> over any other match, there will be no guaranteed order for other cases
> (e.g., 'x_y z' vs 'x y_z' vs 'x y z'; though 'x_y_z' would be guaranteed to
> be selected for field.x_y_z if present)

I guess that this mapping algorithm is weak enough to create some problems
with special chars that are not suported. I'd prefer the dictionary/tuple of
pairs mechanism in order to create a user-configured translation. I don't
see the problem that Perry mentioned in an earlier message related with
guarantying the persistence of such an object: we always have pickle, isn't
it? or I'm missing something?

> To summarize
> 
> Rarr.field.home_address
> Rarr.field['home address']
> Rarr.field('home address')

Supporting Rarr.field['home address'] and Rarr.field('home address') at the
same time sounds unnecessary to me. Moreover having a
Rarr.field('home_address')[32] (for example) looks a bit strange, and I
think Rarr.field['home_address'][32] would be better. But I repeat, this is
my personal feeling.

I know that dropping support of __call__() in field will make the change
backward incompatible, but perhaps now is a good time to define a better
interface to the RecArray object. Another possibility maybe to raise a
deprecation warning for such an use for a couple of releases.

Regards,

-- 
Francesc Alted

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story: updated

[Russell E O. <rowen@u.washington.edu>]

At 11:43 AM -0400 2004-07-26, Perry Greenfield wrote:
>I'll try to see if I can address all the comments raised (please let me know
>if I missed something).
>...(nice proposal elided)...
>Any comments on these changes to the proposal? Are there those that are
>opposed to supporting attribute access?

Overall this sounds great.

However, I am still strongly against attribute access.

Attributes are usually meant for names that are intrinsic to the 
design of an object, not to the user's "configuration" of the object. 
The name mapping proposal isn't bad (thank you for keeping it 
simple!), but it still feels like a kludge and it adds unnecessary 
clutter.

Your explanation of this limitations was clear, but still, imagine 
putting that into the manual. It's a lot of "be careful of this" 
info. That's a red flag to me. Imagine all the folks who don't read 
carefully. Also imagine those who consider attribute access "the 
right way to do it" and so want to clean up the limitations. I think 
you'll see a steady stream of:
"why can't I see my field..."
"why can't you solve the collision problems"
"why can't I use special character thus and so"

I personally feel that when a feature is hard to document or adds 
strange limitations then it probably suggests a flawed design.

In this case there is another mechanism that is more natural, has no 
funny corner cases, and is much more powerful. Its only disadvantage 
is the need for typing for 4 extra characters. Saving 4 characters 
simply not sufficient reason to add this dubious feature.

Before implementing attribute access I have two suggestions (which 
can be taken singly or together):
- Postpone the decision until after the rest of the proposal is 
implemented. See if folks are happy with the mechanisms that are 
available. I freely confess to hoping that momentum will then kill 
the idea.
- Discuss it on comp.lang.py. I'd like to see it aired more widely 
before being adopted. So far I've seen just a few voices for it and a 
few others against it. I realize it's not a democracy -- those who 
write the code get the final say. I also realize some folks will 
always want it, but that tension between simplicity and 
expressiveness is intrinsic to any language. If you add everything 
anybody wants you get a mess, and I want to avoid this mess while we 
still can.

I hope nobody takes offense. I certainly did not mean to imply that 
those who wish attribute access are inferior in any way. There are 
features of python I wish it had that will never occur. I honestly 
can see the appeal of attributes; I was in favor of them myself, 
early on. It adds an appealing expressiveness that makes some kind of 
code read more naturally. But I personally feel it has too many 
limitations and is unnecessary.

Regards,

-- Russell

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story: updated

[Perry G. <pe...@st...>]

I'll try to see if I can address all the comments raised (please let me know
if I missed something).

1) Russell Owen asked that indexing by field name not be permitted for
record arrays and at least one other agreed. Since it is easier to add
something like this later rather than take it away, I'll go along with that.
So while it will be possible to index a Record by field name, it won't be
for record arrays.

2) Russell asked if it would be possible to specify the types of the fields
using numarray/chararray type objects. Yes, it will. We will adopt Rick
White's 2nd suggestion for handling fields that themselves are arrays, I.e.,

formats = (3,Int16), ((4,5), Float32)

For a 1-d Int16 cell of shape (3,) and a 2-d Float32 cell of shape (4,5)

The first suggestion ("formats = 3*(Int16,), 4*(5*(Float32,),)") will not be
supported. While it is very suggestive, it does allow for inconsistent
nestings that must be checked and rejected (what if someone supplies
(Int16, Int16, Float32) as one of the fields?) which complicates the code.
It doesn't read as well.

3) Russell also suggested nesting record arrays. This sort of capability is
not being ruled out, but there isn't a chance we can devote resources to
this any time soon (can anyone else?)

4) To address the suggestions of Russell and Francesc, I'm proposing that
the current "field" method now become an object (callable to retain backward
compatibility) that supports:
   a) indexing by name or number (just like Records)
   b) name to attribute mapping (with restrictions).
So that this means 3 ways to do things! As far as attribute access goes, I
simply do not want to throw arbitrary attributes into the main object
itself. The use of field is comparatively clean since it has not other
public attributes. Aside from mapping '_' into spaces, no other illegal
attribute characters will be mapped. (The identifier/label suggestion by
Colin Williams has some merit, but on the whole, I think it brings more
baggage than benefit). The mapping algorithm is such that it tries to map
the attribute to any field name that has either a ' ' or '_' in the place of
'_' in the attribute name. While all '_' in the name will take precedence
over any other match, there will be no guaranteed order for other cases
(e.g., 'x_y z' vs 'x y_z' vs 'x y z'; though 'x_y_z' would be guaranteed to
be selected for field.x_y_z if present)

Note that the only real need to support indexing other than consistency is
to support slices. Only slices for numerical indexing will be supported (and
not initially). The callable syntax can support index arrays just as easily.

To summarize

Rarr.field.home_address
Rarr.field['home address']
Rarr.field('home address')

Will all work for a field named "home address"

************************************************

Any comments on these changes to the proposal? Are there those that are
opposed to supporting attribute access?

Thanks, Perry

Re: [Numpy-discussion] Follow-up Numarray header PEP

[<ger...@gr...>]

Hi Todd,

Attached is a new version of numnum (including 'topbot', an alternative
implementation of numnum). The README contains some additional comments
with respect to numarray and Numeric (new comments are preceeded by '+',
old comments by '-').  There were still some other bugs in numnum, too.

On 23 Jul 2004 13:28:47 -0400, Todd Miller wrote
> I finally got to your numnum stuff today... awesome work!  You've got
> lots of good suggestions.  Here are some comments:
> 
> 1. Thanks for catching the early return problem with numarray's
> import_array().  It's not just bad, it's wrong.  It'll be fixed for 1.1.
> 
> 2. That said,  I think expanding the macros in-line in numnum is a
> mistake.  It seems to me that "import_array(); PyErr_Clear();" or
> something like it ought to be enough...  after numarray-1.1 anyway.
>
Indeed, but I am spoiled by C++ and was falling back on gcc -E for
debugging.
> 
> 3. I think there's a problem in numnum.toNP() because of numarray's
> array "behavior" issues.  A test needs to be done to ensure that the
> incoming array is not byteswapped or misaligned;  if it is, the easy 
> fix is to make a numarray copy of the array before copying it to Numeric.
>
Done, but what would be the best function to do this? And the documentation
could insist a little more on the possibility of ill-behaved arrays (see
README). 
>
> 4. Kudos for the LP64 stuff.  numconfig is a thorn in the side of the
> PEP,  so I'll put your techniques into numarray for 1.1. 
>  HAS_FLOAT128 is not currently used,  so it might be time to ditch 
> it.  Anyway, thanks!
>
There is a difference between the PEP header files and internal numarray
usage. I find in my CVS working copy:
[packer@slow numarray]$ grep HAS_FLOAT */*
Src/_ndarraymodule.c:#if HAS_FLOAT128
and
[packer@slow numarray]$ grep HAS_UINT64 */*
Src/buffer.ch:  #if HAS_UINT64
Src/buffer.ch:        #if HAS_UINT64
Src/buffer.ch:        #if HAS_UINT64
Src/buffer.ch:        #if HAS_UINT64
Src/buffer.ch:        #if HAS_UINT64
Src/libnumarraymodule.c:        #if HAS_UINT64
Src/libnumarraymodule.c:        #if HAS_UINT64
Src/libnumarraymodule.c:        #if HAS_UINT64
Src/libnumarraymodule.c:        #if HAS_UINT64
Src/libnumarraymodule.c:        #if HAS_UINT64

but that is not be true for the header files (more important for the PEP)
[packer@slow Include]$ grep HAS_UINT64 */*
[packer@slow Include]$ grep HAS_FLOAT128 */*
numarray/arraybase.h:#if HAS_FLOAT128

> 
> 5. PyArray_Present() and isArray() are superfluous *now*.  I was
> planning to add them to Numeric.
> 
> 6. The LGPL may be a problem for us and is probably an issue if we ever
> try to get numnum into the Python distribution.  It would be better 
> to release numnum under the modified BSD license,  same as numarray.
>
Done, with certain regrets because I believe in (L)GPL.
The minutes of the last board meeting of the PSF tipped the scale
( http://www.python.org/psf/records/board/minutes-2004-06-18.html )

What remains to be done is showing how to add numnum's functionality
to a 3rd party extension by linking numnum's object files to the
extension instead of importing numnum's C-API (numnum should not
become another dependency)

Gerard

> 
> 7. Your API struct was very clean.  Eventually I'll regenerate numarray
> like that.
> 
> 8. I logged your comments and bug reports on Source Forge and eventually
> they'll get fixed.
> 
> A to Z the numnum/pep code is beautiful.  Next stop, header PEP update.
> 
> Regards,
> Todd
>
> 
> On Sun, 2004-07-18 at 17:24, ger...@gr... wrote: 
> > Hi Todd,
> > 
> > This is a follow-up on the 'header pep' discussion.
> > 
> > The attachment numnum-0.1.tar.gz contains the sources for the
> > extension modules pep and numnum.  At least on my systems, both
> > modules behave as described in the 'numarray header PEP' when the
> > extension modules implementing the C-API are not present (a situation
> > not foreseen by the macros import_array() of Numeric and especially
> > numarray).  IMO, my solution is 'bona fide', but requires further
> > testing.
> > 
> > The pep module shows how to handle the colliding C-APIs of the Numeric
> > and numarray extension modules and how to implement automagical
> > conversion between Numeric and numarray arrays.
> > 
> > For a technical reason explained in the README, the hard work of doing
> > the conversion between Numeric and numarray arrays has been delegated
> > to the numnum module.  The numnum module is useful when one needs to
> > convert from one array type to the other to use an extension module
> > which only exists for the other type (eg. combining numarray's image
> > processing extensions with pygame's Numeric interface):
> > 
> > Python 2.3+ (#1, Jan  7 2004, 09:17:35)
> > [GCC 3.3.1 (SuSE Linux)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import numnum; import Numeric as np; import numarray as na
> > >>> np1 = np.array([[1, 2], [3, 4]]); na1 = numnum.toNA(np1)
> > >>> na2 = na.array([[1, 2, 3], [4, 5, 6]]); np2 = numnum.toNP(na2)
> > >>> print type(np1); np1; type(np2); np2
> > <type 'array'>
> > array([[1, 2],
> >        [3, 4]])
> > <type 'array'>
> > array([[1, 2, 3],
> >        [4, 5, 6]],'i')
> > >>> print type(na1); na1; type(na2); na2
> > <class 'numarray.numarraycore.NumArray'>
> > array([[1, 2],
> >        [3, 4]])
> > <class 'numarray.numarraycore.NumArray'>
> > array([[1, 2, 3],
> >        [4, 5, 6]])
> > >>>
> > 
> > The pep module shows how to implement array processing functions which
> > use the Numeric, numarray or Sequence C-API:
> > 
> > static PyObject *
> > wysiwyg(PyObject *dummy, PyObject *args)
> > {
> >     PyObject *seq1, *seq2;
> >     PyObject *result;
> > 
> >     if (!PyArg_ParseTuple(args, "OO", &seq1, &seq2))
> >         return NULL;
> > 
> >     switch(API) {
> >     case NumericAPI:
> >     {
> >         PyObject *np1 = NN_API->toNP(seq1);
> >         PyObject *np2 = NN_API->toNP(seq2);
> >         result = np_wysiwyg(np1, np2);
> >         Py_XDECREF(np1);
> >         Py_XDECREF(np2);
> >         break;
> >     }
> >     case NumarrayAPI:
> >     {
> >         PyObject *na1 = NN_API->toNA(seq1);
> >         PyObject *na2 = NN_API->toNA(seq2);
> >         result = na_wysiwyg(na1, na2);
> >         Py_XDECREF(na1);
> >         Py_XDECREF(na2);
> >         break;
> >     }
> >     case SequenceAPI:
> >         result = seq_wysiwyg(seq1, seq2);
> >         break;
> >     default:
> >         PyErr_SetString(PyExc_RuntimeError, "Should never happen");
> >         return 0;
> >     }
> > 
> >     return result;
> > }
> > 
> > See the README for an example session using the pep module showing that
> > it is possible pass a mix of Numeric and numarray arrays to pep.wysiwyg().
> > 
> > Notes:
> > 
> > - it is straightforward to adapt pep and numnum so that the conversion
> >   functions are linked into pep instead of imported.
> > 
> > - numnum is still 'proof of concept'.  I am thinking about methods to
> >   make those techniques safer if the numarray (and Numeric?) header
> >   files make it never into the Python headers (or make it safer to
> >   use those techniques with Python < 2.4).  In particular it would
> >   be helpful if the numerical C-APIs export an API version number,
> >   similar to the versioning scheme of shared libraries -- see the
> >   libtool->versioning info pages. 
> > 
> > I am considering three possibilities to release a more polished
> > version of numnum (3rd party extension writers may prefer to link
> > rather than import numnum's functionality):
> > 
> > 1. release it from PyQwt's project page
> > 2. register an independent numnum project at SourceForge
> > 3. hand numnum over to the Numerical Python project (frees me from
> >    worrying about API changes).
> > 
> > 
> > Regards -- Gerard Vermeulen
> 
> --


--
Open WebMail Project (http://openwebmail.org)

[Numpy-discussion] Permutation in Numpy

[Hee-Seng K. <ky...@ea...>]

#perm.py
def perm(k):
     # Compute the list of all permutations of k
     if len(k) <= 1:
         return [k]
     r = []
     for i in range(len(k)):
         s =  k[:i] + k[i+1:]
         p = perm(s)
         for x in p:
             r.append(k[i:i+1] + x)
     return r

Does anyone know if there is a built-in function in Numpy (or Numarray) 
that does the above task faster (computes the list of all permutations 
of a list, k)?  Or is there a way to make the above function run faster 
using Numpy?

I'm asking because I need to create a very large list which contains 
all permutations of range(12), in which case there would be 12! 
permutations.  I created a file test.py:

#!/usr/bin/env python
from perm import perm
print perm(range(12))

And ran the program:

$ ./test.py >> list.txt

The program ran for about 90 minutes and was still running on my 
machine (667 MHz PowerPC G4, 512 MB SDRAM) until I quit the process as 
I was getting nervous (and impatient).

I would highly appreciate anyone's suggestions.

Many thanks,
Kye

[Numpy-discussion] Hot Stock Newsflash, ARMM expecting Mass|ve M0nday Ga1ns R753KT98

[<rii...@ya...>]

E.fficiency Technologies, Inc.'s New Centrif.ugal Chiller Efficiency and Management Tool Can He.lp S.ave Industry Bi.llions in Energy C.osts 

ARMM lau.nch n.ew s.ervice (EffHVAC)

D.ont miss this g.reat inves.tment issue! ARMM is another ho.t public tr.aded comp.any that is set to so.ar on Monday, July 26th..


BIG PR camp.aign sta.rting on 26th of July for ARMM - S.t0ck will e.xpl0de - Just read the news 

---------------------
P.rice on Friday: 10Cents
In our o.pinion N.ext 3 days p.otential p.rice: 35Cents
In our o.pinion N.ext 10 days p.otential p.rice: 45Cents
---------------------

G.et on B.oard with ARMM and e.njoy some i.ncredible p.rofits in the n.ext 3-10 days_!_!

ALL T.ECHNICAL I.NDICATORS SAY - B.U.Y ARMM @ up to 35cents!

Significant short term t.rading p.rofits in ARMM are being p.redicted, great n.ews a.lready issued by the c.ompany and big PR c.ampaign on the way in the n.ext few days.
 

C.OMPANY P.ROFILE
-------------->
American Resource Management, Inc., through its w.holly-owned s.ubsidiary, E.fficiency T.echnologies, Inc. ("EffTec") is a Tulsa, Oklahoma based c.ompany d.edicated to developing energy efficiency m.onitoring programs for c.ommercial/i.ndustrial HVAC systems principally made up of c.entrifugal chillers and boilers.  Centrifugal chillers are the single largest energy-using components in most facilities and can typically consume more than 50% of the total electrical usage.  Centrifugal chillers running inefficiently result in substantially higher e.nergy c.osts, decreased equipment reliability and shortened l.ifespan.


EffTec has developed a p.owerful, easy-to-use, online d.iagnostic s.ervice called EffHVAC that gives f.acilities the a.bility to document, m.onitor, e.valuate and m.anage c.entrifugal c.hiller system p.erformance.  EffHVAC c.reated detailed reports that contain a w.ealth of i.nformation that can be used to improve operations and save t.housands of d.ollars in u.tility c.osts.
 

EffTec offers c.omprehensive and f.lexible HVAC consulting and training.  Our t.eam consists of industry-recognized e.xperts in HVAC system design, efficiency, preventive and proactive maintenance, repair, chemistry, computer programming and m.arketing.  Combine EffHVAC with our consulting services and start d.eveloping a w.orld-class HVAC program to improve your b.ottom line.  

   




Inform.ation within this email contains "f.orward look.ing state.ments" within the meaning of Sect.ion 27A of the Sec.urities Ac.t of 1933 and Sect.ion 21B of the Securit.ies Exc.hange Ac.t of 1934. Any stat.ements that express or involve discu.ssions with resp.ect to pre.dictions, goa.ls, expec.tations, be.liefs, pl.ans, proje.ctions, object.ives, assu.mptions or fut.ure eve.nts or perform.ance are not stat.ements of histo.rical fact and may be "forw.ard loo.king stat.ements."  For.ward looking state.ments are based on expect.ations, estim.ates and project.ions at the time the statem.ents are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those prese.ntly anticipated. Forward look.ing statements in this action may be identified through the use of words su.ch as: "pro.jects", "for.esee", "expects", "est.imates," "be.lieves," "underst.ands" "wil.l," "part of: "anticip.ates," or that by stat.ements indi.cating certain actions "may,"
"cou.ld," or "might" occur. All information provided within this em.ail pertai.ning to inv.esting, st.ocks, securi.ties must be under.stood as informa.tion provided and not investm.ent advice. Eme.rging Equity Al.ert advi.ses all re.aders and subscrib.ers to seek advice from a registered profe.ssional secu.rities represent.ative before dec.iding to trade in sto.cks featured within this ema.il. None of the mate.rial within this rep.ort shall be constr.ued as any kind of invest.ment advi.ce. Please have in mind that the interpr.etation of the witer of this newsl.etter about the news published by the company does not represent the com.pany official sta.tement and in fact may differ from the real meaning of what the news rele.ase meant to say. Please read the news release by your.self and judge by yourself about the detai.ls in it.  In compli.ance with Sec.tion 17(b), we discl.ose the hol.ding of ARMM s.hares prior to the publi.cation of this report. Be aware of an inher.ent co.nflict of interest res.ulting from such holdi.ngs due to our intent to pro.fit from the liqui.dation of these shares. Sh.ares may be s.old at any time, even after posi.tive state.ments have been made regard.ing the above company. Since we own sh.ares, there is an inher.ent conf.lict of inte.rest in our statem.ents and opin.ions. Readers of this publi.cation are cauti.oned not to place und.ue relia.nce on forw.ard-looki.ng statements, which are based on certain assump.tions and expectati.ons invo.lving various risks and uncert.ainties, that could cause results to differ materi..ally from those set forth in the forw.ard- looking state.ments. Please be advi.sed that noth.ing within this em.ail shall cons.titute a solic.itation or an offer to buy or sell any s.ecurity menti.oned her.ein. This news.letter is neither a regi.stered inves.tment ad.visor nor affil.iated with any brok.er or dealer. All statements made are our e.xpress o.pinion only and should be treated as such. We may own, buy and sell any securi.ties menti.oned at any time. This r.eport includes forw.ard-looki.ng stat.ements within the meaning of The Pri.vate Securi.ties Litig.ation Ref.orm Ac.t of 1995. These state.ments may include terms as "expe.ct", "bel.ieve", "ma.y", "wi.ll", "mo.ve","und.ervalued" and "inte.nd" or simil.ar terms. This news.letter was paid 11500 dollars from th.ird p.arty to se.nd this report. PL.EASE DO YOUR OWN D.UE DI.LIGENCE B.EFORE INVES.TING IN ANY PRO.FILED COMP.ANY. You may lo.se mon.ey from inve.sting in Pen.ny St.ocks.


A_RM_M - our NEW st<o>ck pick - GREAT N.EWS V650OE49
>A.RMM - our NEW s_t_0_c_k p1ck = GREAT N_E_WS V3501136  
NnnEW St_ock Pick - Hug.e Mon-day - /ArMm\   m468MV68
NewW Stoc-k Pick + Hug.e Mon-day - ArMm = Earn_1ngs 1497cJ72  
Mas_sive G.a1ns - F0r-casted For Mond#y g984iJ69 
Monday F0rcaSST is A>R.M.M - Read & Earnn  Z8697B79
In-Creased Earn-ings Report - AR-MM - For Monday Morning l547BH81 
EX PLO SIVE Gain-s - ALERT for MONDAY T288xC38 
NewsWire - Double your Monday Earn>ings!   q664qv16
A,L,E,R,T - A>R>M>M- This st0ck is h0t - They announced great news  l993L941
A>R<M>M is about to EXPL0DE - A c t n_o_w Z484TE26 
<A/R/M/M> - Ma-jor TradeeE Al_ert! !e330vH15
1O to 2O cent in=crease monday. Ma_jor ALer.t. c8620c55 
New P1ck Bownd to Dou_ble & Tri_ple. A.R/M.M.. I942qD93 
B1gGa1ns For-M0nday = (2X)Double Your Pr0fits!y747s506 
UpCOMING Mondays Hot/test St O CK {2x} PROF!TS L572lS00
Get Ins1ders SEcrEt_s - A|R|M|M Sets to Expl0de U812Jb41 
Ab0ut To Expl0de - <AR.MM>  y142qK13   
Hot Stock Newsflash, ARMM expecting Mass|ve M0nday Ga1ns 7074WE36 
M0nday Ga1ns, *ARMM*, St0ck NewsW1re g504mo93  
{3x} Ur m0nDay Pr0FITS - A\R\M\M w433T229
Break.ing New.s for ARM.M -  American Resource Management, Inc.


E.fficiency Technologies, Inc.'s New Centrif.ugal Chiller Efficiency and Management Tool Can He.lp S.ave Industry Bi.llions in Energy C.osts 

ARMM lau.nch n.ew s.ervice (EffHVAC)

D.ont miss this g.reat inves.tment issue! ARMM is another ho.t public tr.aded comp.any that is set to so.ar on Monday, July 26th..


BIG PR camp.aign sta.rting on 26th of July for ARMM - S.t0ck will e.xpl0de - Just read the news 

---------------------
P.rice on Friday: 10Cents
In our o.pinion N.ext 3 days p.otential p.rice: 35Cents
In our o.pinion N.ext 10 days p.otential p.rice: 45Cents
---------------------

G.et on B.oard with ARMM and e.njoy some i.ncredible p.rofits in the n.ext 3-10 days_!_!

ALL T.ECHNICAL I.NDICATORS SAY - B.U.Y ARMM @ up to 35cents!

Significant short term t.rading p.rofits in ARMM are being p.redicted, great n.ews a.lready issued by the c.ompany and big PR c.ampaign on the way in the n.ext few days.
 

C.OMPANY P.ROFILE
-------------->
American Resource Management, Inc., through its w.holly-owned s.ubsidiary, E.fficiency T.echnologies, Inc. ("EffTec") is a Tulsa, Oklahoma based c.ompany d.edicated to developing energy efficiency m.onitoring programs for c.ommercial/i.ndustrial HVAC systems principally made up of c.entrifugal chillers and boilers.  Centrifugal chillers are the single largest energy-using components in most facilities and can typically consume more than 50% of the total electrical usage.  Centrifugal chillers running inefficiently result in substantially higher e.nergy c.osts, decreased equipment reliability and shortened l.ifespan.


EffTec has developed a p.owerful, easy-to-use, online d.iagnostic s.ervice called EffHVAC that gives f.acilities the a.bility to document, m.onitor, e.valuate and m.anage c.entrifugal c.hiller system p.erformance.  EffHVAC c.reated detailed reports that contain a w.ealth of i.nformation that can be used to improve operations and save t.housands of d.ollars in u.tility c.osts.
 

EffTec offers c.omprehensive and f.lexible HVAC consulting and training.  Our t.eam consists of industry-recognized e.xperts in HVAC system design, efficiency, preventive and proactive maintenance, repair, chemistry, computer programming and m.arketing.  Combine EffHVAC with our consulting services and start d.eveloping a w.orld-class HVAC program to improve your b.ottom line.  

   




Inform.ation within this email contains "f.orward look.ing state.ments" within the meaning of Sect.ion 27A of the Sec.urities Ac.t of 1933 and Sect.ion 21B of the Securit.ies Exc.hange Ac.t of 1934. Any stat.ements that express or involve discu.ssions with resp.ect to pre.dictions, goa.ls, expec.tations, be.liefs, pl.ans, proje.ctions, object.ives, assu.mptions or fut.ure eve.nts or perform.ance are not stat.ements of histo.rical fact and may be "forw.ard loo.king stat.ements."  For.ward looking state.ments are based on expect.ations, estim.ates and project.ions at the time the statem.ents are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those prese.ntly anticipated. Forward look.ing statements in this action may be identified through the use of words su.ch as: "pro.jects", "for.esee", "expects", "est.imates," "be.lieves," "underst.ands" "wil.l," "part of: "anticip.ates," or that by stat.ements indi.cating certain actions "may,"
"cou.ld," or "might" occur. All information provided within this em.ail pertai.ning to inv.esting, st.ocks, securi.ties must be under.stood as informa.tion provided and not investm.ent advice. Eme.rging Equity Al.ert advi.ses all re.aders and subscrib.ers to seek advice from a registered profe.ssional secu.rities represent.ative before dec.iding to trade in sto.cks featured within this ema.il. None of the mate.rial within this rep.ort shall be constr.ued as any kind of invest.ment advi.ce. Please have in mind that the interpr.etation of the witer of this newsl.etter about the news published by the company does not represent the com.pany official sta.tement and in fact may differ from the real meaning of what the news rele.ase meant to say. Please read the news release by your.self and judge by yourself about the detai.ls in it.  In compli.ance with Sec.tion 17(b), we discl.ose the hol.ding of ARMM s.hares prior to the publi.cation of this report. Be aware of an inher.ent co.nflict of interest res.ulting from such holdi.ngs due to our intent to pro.fit from the liqui.dation of these shares. Sh.ares may be s.old at any time, even after posi.tive state.ments have been made regard.ing the above company. Since we own sh.ares, there is an inher.ent conf.lict of inte.rest in our statem.ents and opin.ions. Readers of this publi.cation are cauti.oned not to place und.ue relia.nce on forw.ard-looki.ng statements, which are based on certain assump.tions and expectati.ons invo.lving various risks and uncert.ainties, that could cause results to differ materi..ally from those set forth in the forw.ard- looking state.ments. Please be advi.sed that noth.ing within this em.ail shall cons.titute a solic.itation or an offer to buy or sell any s.ecurity menti.oned her.ein. This news.letter is neither a regi.stered inves.tment ad.visor nor affil.iated with any brok.er or dealer. All statements made are our e.xpress o.pinion only and should be treated as such. We may own, buy and sell any securi.ties menti.oned at any time. This r.eport includes forw.ard-looki.ng stat.ements within the meaning of The Pri.vate Securi.ties Litig.ation Ref.orm Ac.t of 1995. These state.ments may include terms as "expe.ct", "bel.ieve", "ma.y", "wi.ll", "mo.ve","und.ervalued" and "inte.nd" or simil.ar terms. This news.letter was paid 11500 dollars from th.ird p.arty to se.nd this report. PL.EASE DO YOUR OWN D.UE DI.LIGENCE B.EFORE INVES.TING IN ANY PRO.FILED COMP.ANY. You may lo.se mon.ey from inve.sting in Pen.ny St.ocks.


barycentric deform conservator cacophony critter addison armament complain difluoride boris discriminatory boron abo deoxyribose boorish compote belfast carolingian court albania accentuate belshazzar bridesmaid breakwater brandish average bolshevism coppery 

Re: [Numpy-discussion] A bit long, but would appreciate anyone's help, if time permits!

[Colin J. W. <cj...@sy...>]

Hee-Seng Kye wrote:

> Hi.  Like my previous post, my question is not directly related to Numpy, 

True, but numarray can be of help.

> but I couldn't help posting it since many people here deal with 
> numbers.  I have a question that requires a bit of explanation.  I 
> would highly appreciate it if anyone could read this and offer any 
> suggestions, whenever time permits.
>
> I'm trying to write a program that 1) gives all possible rotations of 
> an ordered list, 2) chooses the ordering that has the smallest 
> difference from first to last element of the rotation, and 3) 
> continues to compare the difference from first to second-to-last 
> element, and so on, if there was a tie in step 2.
>
> The following is the output of a function I wrote.  The first 6 lines 
> are all possible rotations of [0,1,3,6,7,10], and this takes care of 
> step 1 mentioned above.  The last line provides the differences (mod 
> 12).  If the last line were denoted as r, r[0] lists the differences 
> from first to last element of each rotation (p0 through p5), r[1] the 
> differences from first to second-to-last element, and so on.
>
> >>> from normal import normal
> >>> normal([0,1,3,6,7,10])
> [0, 1, 3, 6, 7, 10]    #p0
> [1, 3, 6, 7, 10, 0]    #p1
> [3, 6, 7, 10, 0, 1]    #p2
> [6, 7, 10, 0, 1, 3]    #p3
> [7, 10, 0, 1, 3, 6]    #p4
> [10, 0, 1, 3, 6, 7]    #p5
>
> [[10, 11, 10, 9, 11, 9], [7, 9, 9, 7, 8, 8], [6, 6, 7, 6, 6, 5], [3, 
> 5, 4, 4, 5, 3], [1, 2, 3, 1, 3, 2]]     #r
>
> Here is my question.  I'm having trouble realizing step 2 (and 3, if 
> necessary).  In the above case, the smallest number in r[0] is 9, 
> which is present in both r[0][3] and r[0][5].  This means that p3 and 
> p5 and only p3 and p5 need to be further compared.  r[1][3] is 7, and 
> r[1][5] is 8, so the comparison ends here, and the final result I'm 
> looking for is p3, [6,7,10,0,1,3] (the final 'n' value for 'pn' 
> corresponds to the final 'y' value for 'r[x][y]').
>
> How would I find the smallest values of a list r[0], take only those 
> values (r[0][3] and r[0][5]) for further comparison (r[1][3] and 
> r[1][5]), and finally print a p3?
>
> Thanks again for reading this.  If there is anything unclear, please 
> let me know.
>
> Best,
> Kye
>
> My code begins here: 

[snip]
The following reproduces your result, but I'm not sure that it does what 
you want to do.

Best wishes.

Colin W.

# Kye.py
#normal.py
def normal(s):
    s.sort()
    r = []
    q = []
    v = []

    for x in range(0, len(s)):
        k = s[x:]+s[0:x]
        r.append(k)

    for y in range(0, len(s)):
        print r[y], '\t'
        d = []
        for yy in range(len(s)-1, 0, -1):
            w = (r[y][yy]-r[y][0])%12
            d.append(w)
        q.append(d)

    for z in range(0, len(s)-1):
        d = []
        for zz in range(0, len(s)):
            w = q[zz][z]
            d.append(w)
        v.append(d)
    print '\n', v

def findMinima(i, lst):
  global diff
  print 'lst:', lst, 'i:', i
  res= []
  dataRow= diff[i].take(lst)
  fnd= dataRow.argmin()
  val= val0= dataRow[fnd]
  while val == val0:
    fndRes= lst[fnd]                  # This will become the result iff 
no dupicate found
    res.append(fnd)
    dataRow[fnd]= 100
    fnd= dataRow.argmin()
    val0= dataRow[fnd]
  if len(res) == 1:
    return fndRes
  else:
    ret= findMinima(i-1, res) 
    return ret

def normal1(s):
  import numarray.numarraycore as _num
  import numarray.numerictypes as _nt
  global diff
  s= _num.array(s)
  s.sort()
  rl= len(s)
  r= _num.zeros(shape= (rl, rl), type= _nt.Int)
  for i in range(rl):
    r[i, 0:rl-i]= s[i:]
    if i:
      r[i, rl-i:]= s[0:i]
  subtr= r[0].repeat(5, 1).resize(6, 5)
  subtr.transpose()
  neg= r[1:] < subtr
  diff= r[1:]-subtr + 12 * neg
 
  return 'The selectect rotation is:', r[findMinima(diff._shape[0]-1, 
range(diff._shape[1]))]

if __name__ == '__main__':
  print normal1([0,1,3,6,7,10])


>
> #normal.py
> def normal(s):
>     s.sort()
>     r = []
>     q = []
>     v = []
>
>     for x in range(0, len(s)):
>         k = s[x:]+s[0:x]
>         r.append(k)
>
>     for y in range(0, len(s)):
>         print r[y], '\t'
>         d = []
>         for yy in range(len(s)-1, 0, -1):
>             w = (r[y][yy]-r[y][0])%12
>             d.append(w)
>         q.append(d)
>
>     for z in range(0, len(s)-1):
>         d = []
>         for zz in range(0, len(s)):
>             w = q[zz][z]
>             d.append(w)
>         v.append(d)
>     print '\n', v
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

[Numpy-discussion] ANN: SciPy04 -- Last day for abstracts and early registration!

[eric j. <er...@en...>]

Hey Group,

Just a reminder that this is the last day to submit abstracts for 
SciPy04.  It is also the last day for early registration.

More information is here:

http://www.scipy.org/wikis/scipy04

About the Conference and Keynote Speaker
---------------------------------------------
The 1st annual *SciPy Conference* will be held this year at Caltech, 
September 2-3, 2004.  As some of you may know, we've experienced great 
participation in two SciPy "Workshops" (with ~70 attendees in both 2002 
and 2003) and this year we're graduating to a "conference."  With the 
prestige of a conference comes the responsibility of a keynote address.  
This year, Jim Hugunin has answered the call and will be speaking to 
kickoff the meeting on Thursday September 2nd.  Jim is the creator of 
Numeric Python, Jython, and co-designer of AspectJ. Jim is currently 
working on IronPython--a fast implementation of Python for .NET and Mono.

Presenters
-----------
We still have room for a few more standard talks, and there is plenty of 
room for lightning talks. Because of this, we are extending the abstract 
deadline until July 23rd.  Please send your abstract to 
abs...@sc....  Travis Oliphant is organizing the presentations 
this year. (Thanks!)  Once accepted, papers and/or presentation slides 
are acceptable and are due by August 20, 2004.

Registration
-------------
Early registration ($100.00) has been extended to July 23rd.  Follow the 
links off of the main conference site:

http://www.scipy.org/wikis/scipy04

After July 23rd, registration will be $150.00.  Registration includes 
breakfast and lunch Thursday & Friday and a very nice dinner Thursday 
night.  Please register as soon as possible as it will help us in 
planning for food, room sizes, etc.

Sprints
--------
As of now, we really haven't had much of a call for coding sprints for 
the 3 days prior to SciPy 04.  Below is the original announcement about 
sprints.  If you would like to suggest a topic and see if others are 
interested, please send a message to the list.  Otherwise, we'll forgo 
the sprints session this year.

   We're also planning three days of informal "Coding Sprints" prior to
   the conference -- August 30 to September 1, 2004.  Conference
   registration is not required to participate in the sprints.  Please
   email the list, however, if you plan to attend.  Topics for these
   sprints will be determined via the mailing lists as well, so please
   submit any suggestions for topics to the scipy-user list:

   list signup: http://www.scipy.org/mailinglists/
   list address: sci...@sc...


thanks,
eric

Re: [Numpy-discussion] Follow-up Numarray header PEP

[Todd M. <jm...@st...>]

Hi Gerard,

I finally got to your numnum stuff today... awesome work!  You've got
lots of good suggestions.  Here are some comments:

1. Thanks for catching the early return problem with numarray's
import_array().  It's not just bad, it's wrong.  It'll be fixed for 1.1.

2. That said,  I think expanding the macros in-line in numnum is a
mistake.  It seems to me that "import_array(); PyErr_Clear();" or
something like it ought to be enough...  after numarray-1.1 anyway.  

3. I think there's a problem in numnum.toNP() because of numarray's
array "behavior" issues.  A test needs to be done to ensure that the
incoming array is not byteswapped or misaligned;  if it is, the easy fix
is to make a numarray copy of the array before copying it to Numeric.

4. Kudos for the LP64 stuff.  numconfig is a thorn in the side of the
PEP,  so I'll put your techniques into numarray for 1.1.  HAS_FLOAT128
is not currently used,  so it might be time to ditch it.  Anyway,
thanks!

5. PyArray_Present() and isArray() are superfluous *now*.  I was
planning to add them to Numeric. 

6. The LGPL may be a problem for us and is probably an issue if we ever
try to get numnum into the Python distribution.  It would be better to
release numnum under the modified BSD license,  same as numarray.

7. Your API struct was very clean.  Eventually I'll regenerate numarray
like that.

8. I logged your comments and bug reports on Source Forge and eventually
they'll get fixed.

A to Z the numnum/pep code is beautiful.  Next stop, header PEP update.

Regards,
Todd

On Sun, 2004-07-18 at 17:24, ger...@gr... wrote: 
> Hi Todd,
> 
> This is a follow-up on the 'header pep' discussion.
> 
> The attachment numnum-0.1.tar.gz contains the sources for the
> extension modules pep and numnum.  At least on my systems, both
> modules behave as described in the 'numarray header PEP' when the
> extension modules implementing the C-API are not present (a situation
> not foreseen by the macros import_array() of Numeric and especially
> numarray).  IMO, my solution is 'bona fide', but requires further
> testing.
> 
> The pep module shows how to handle the colliding C-APIs of the Numeric
> and numarray extension modules and how to implement automagical
> conversion between Numeric and numarray arrays.
> 
> For a technical reason explained in the README, the hard work of doing
> the conversion between Numeric and numarray arrays has been delegated
> to the numnum module.  The numnum module is useful when one needs to
> convert from one array type to the other to use an extension module
> which only exists for the other type (eg. combining numarray's image
> processing extensions with pygame's Numeric interface):
> 
> Python 2.3+ (#1, Jan  7 2004, 09:17:35)
> [GCC 3.3.1 (SuSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numnum; import Numeric as np; import numarray as na
> >>> np1 = np.array([[1, 2], [3, 4]]); na1 = numnum.toNA(np1)
> >>> na2 = na.array([[1, 2, 3], [4, 5, 6]]); np2 = numnum.toNP(na2)
> >>> print type(np1); np1; type(np2); np2
> <type 'array'>
> array([[1, 2],
>        [3, 4]])
> <type 'array'>
> array([[1, 2, 3],
>        [4, 5, 6]],'i')
> >>> print type(na1); na1; type(na2); na2
> <class 'numarray.numarraycore.NumArray'>
> array([[1, 2],
>        [3, 4]])
> <class 'numarray.numarraycore.NumArray'>
> array([[1, 2, 3],
>        [4, 5, 6]])
> >>>
> 
> The pep module shows how to implement array processing functions which
> use the Numeric, numarray or Sequence C-API:
> 
> static PyObject *
> wysiwyg(PyObject *dummy, PyObject *args)
> {
>     PyObject *seq1, *seq2;
>     PyObject *result;
> 
>     if (!PyArg_ParseTuple(args, "OO", &seq1, &seq2))
>         return NULL;
> 
>     switch(API) {
>     case NumericAPI:
>     {
>         PyObject *np1 = NN_API->toNP(seq1);
>         PyObject *np2 = NN_API->toNP(seq2);
>         result = np_wysiwyg(np1, np2);
>         Py_XDECREF(np1);
>         Py_XDECREF(np2);
>         break;
>     }
>     case NumarrayAPI:
>     {
>         PyObject *na1 = NN_API->toNA(seq1);
>         PyObject *na2 = NN_API->toNA(seq2);
>         result = na_wysiwyg(na1, na2);
>         Py_XDECREF(na1);
>         Py_XDECREF(na2);
>         break;
>     }
>     case SequenceAPI:
>         result = seq_wysiwyg(seq1, seq2);
>         break;
>     default:
>         PyErr_SetString(PyExc_RuntimeError, "Should never happen");
>         return 0;
>     }
> 
>     return result;
> }
> 
> See the README for an example session using the pep module showing that
> it is possible pass a mix of Numeric and numarray arrays to pep.wysiwyg().
> 
> Notes:
> 
> - it is straightforward to adapt pep and numnum so that the conversion
>   functions are linked into pep instead of imported.
> 
> - numnum is still 'proof of concept'.  I am thinking about methods to
>   make those techniques safer if the numarray (and Numeric?) header
>   files make it never into the Python headers (or make it safer to
>   use those techniques with Python < 2.4).  In particular it would
>   be helpful if the numerical C-APIs export an API version number,
>   similar to the versioning scheme of shared libraries -- see the
>   libtool->versioning info pages. 
> 
> I am considering three possibilities to release a more polished
> version of numnum (3rd party extension writers may prefer to link
> rather than import numnum's functionality):
> 
> 1. release it from PyQwt's project page
> 2. register an independent numnum project at SourceForge
> 3. hand numnum over to the Numerical Python project (frees me from
>    worrying about API changes).
> 
> 
> Regards -- Gerard Vermeulen



-- 

[Numpy-discussion] re: Unpickling python 2.2 userArray objs in python 2.3

[<sa...@hy...>]

I have further information on my problem of unpickling an object that 
is based on Numeric.UserArray class.

I can recreate the endless getattr loop with the following code, 
which is a small subsection of my class:

data = Numeric.ones(31,savespace=1)
ua = UserArray(data)
blob = cPickle.dumps(ua)
obj = cPickle.loads(blob)      <-- fails here

If you pickle the data obj, everything works.  This code works in 
Python2.2.

Is this a bug?  Is it fixable?

sue

[Numpy-discussion] A bit long, but would appreciate anyone's help, if time permits!

[Hee-Seng K. <ky...@ea...>]

Hi.  Like my previous post, my question is not directly related to 
Numpy, but I couldn't help posting it since many people here deal with 
numbers.  I have a question that requires a bit of explanation.  I 
would highly appreciate it if anyone could read this and offer any 
suggestions, whenever time permits.

I'm trying to write a program that 1) gives all possible rotations of 
an ordered list, 2) chooses the ordering that has the smallest 
difference from first to last element of the rotation, and 3) continues 
to compare the difference from first to second-to-last element, and so 
on, if there was a tie in step 2.

The following is the output of a function I wrote.  The first 6 lines 
are all possible rotations of [0,1,3,6,7,10], and this takes care of 
step 1 mentioned above.  The last line provides the differences (mod 
12).  If the last line were denoted as r, r[0] lists the differences 
from first to last element of each rotation (p0 through p5), r[1] the 
differences from first to second-to-last element, and so on.

 >>> from normal import normal
 >>> normal([0,1,3,6,7,10])
[0, 1, 3, 6, 7, 10]	#p0
[1, 3, 6, 7, 10, 0]	#p1
[3, 6, 7, 10, 0, 1]	#p2
[6, 7, 10, 0, 1, 3]	#p3
[7, 10, 0, 1, 3, 6]	#p4
[10, 0, 1, 3, 6, 7]	#p5

[[10, 11, 10, 9, 11, 9], [7, 9, 9, 7, 8, 8], [6, 6, 7, 6, 6, 5], [3, 5, 
4, 4, 5, 3], [1, 2, 3, 1, 3, 2]]     #r

Here is my question.  I'm having trouble realizing step 2 (and 3, if 
necessary).  In the above case, the smallest number in r[0] is 9, which 
is present in both r[0][3] and r[0][5].  This means that p3 and p5 and 
only p3 and p5 need to be further compared.  r[1][3] is 7, and r[1][5] 
is 8, so the comparison ends here, and the final result I'm looking for 
is p3, [6,7,10,0,1,3] (the final 'n' value for 'pn' corresponds to the 
final 'y' value for 'r[x][y]').

How would I find the smallest values of a list r[0], take only those 
values (r[0][3] and r[0][5]) for further comparison (r[1][3] and 
r[1][5]), and finally print a p3?

Thanks again for reading this.  If there is anything unclear, please 
let me know.

Best,
Kye

My code begins here:
#normal.py
def normal(s):
	s.sort()
	r = []
	q = []
	v = []

	for x in range(0, len(s)):
		k = s[x:]+s[0:x]
		r.append(k)

	for y in range(0, len(s)):
		print r[y], '\t'
		d = []
		for yy in range(len(s)-1, 0, -1):
			w = (r[y][yy]-r[y][0])%12
			d.append(w)
		q.append(d)

	for z in range(0, len(s)-1):
		d = []
		for zz in range(0, len(s)):
			w = q[zz][z]
			d.append(w)
		v.append(d)
	print '\n', v

[Numpy-discussion] Unpickling python 2.2 UserArray objs in python 2.3

[<sa...@hy...>]

I have a large bunch of objects that subclass UserArray from Numeric 
22.  These objects were created and pickled in binary mode in 
Python2.2 and stored in a mysql database on Red hat 8.  

Using Python2.2, I can easily retrieve and unpickle the objects.

I have just upgraded the system to Fedora Core 2 which supplies 
Python 2.3.3.  After much hassle, I have been able to compile Numeric 
1.0 (ver 23) and have tried to unpickle these objects.  Now, I get a 
failure in the loads call.  

The code is:
<retrieve blob from mysql>
import cPickle
obj = cPickle.loads(str(blob))

When this is called, the python interpreter (via IDLE) goes into a 
loop in the UserArray __getattr__ function.(line 198):
return getattr(self.array,attr)

>> File "/usr/lib/python2.3/site-packages/Numeric/UserArray.py" line 
198, in __getattr__
>>    return getattr(self.array,attr)

No other error is reported, just a stack full of these lines.

It seems that at this point, UserArray doesn't know that it has an 
'array' attr.

This worked just fine in Python2.2.

Has something changed in Python2.3 cPickle functions or in how 
Numeric 23 handles pickle/unpickle that would make my Python2.2 blobs 
unusable in Python 2.3?  Is there a solution for this, other than 
remaking my blobs (not an option - there are literally millions of 
them), or must I figure out how to access python2.2 for this code?

So far as I can tell, the string I get back is exactly the same for 
both versions.

Any help you can give me would be appreciated.  Thanks

sue giller

Re: [Numpy-discussion] Is there a better way to do this?

[Hee-Seng K. <ky...@ea...>]

Thanks a lot everyone for suggestions.  On my slow machine (667 MHz), 
inefficient programs run even slower, and when I expand the program to 
calculate 9-digit numbers, there is almost a 2-minute difference!

Thanks again.

Best,

Kye

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story

[Colin J. W. <cj...@sy...>]

Francesc Alted wrote:

>Hi,
>
>I agree that numarray team's overhaul of RecArray access modes is very good
>and I agree most of it.
>
>A Dimarts 20 Juliol 2004 19:14, Russell E Owen va escriure:
>  
>
>>I think recarray[field name] is too easily confused with 
>>recarray[index] and is unnecessary.
>>    
>>
>
>Yeah, maybe you are right.
>
>  
>
>>I suggest one of two solutions:
>>- Do nothing. Make users use field(field name or index)
>>or
>>- Allow access to the fields via an indexable entity. Simplest for 
>>the user would be to use "field" itself:
>>   recArr.field[1]
>>   recArr.field["abc"]
>>(i.e. field becomes an object that can be called or can be accessed 
>>via __getitem__)
>>    
>>
>
>I prefer the second one. Although I know that you don't like the __getattr__
>method, the field object can be used to host one. The main advantage I see
>having such a __getattr__ method is that I'm very used to press TAB twice in
>the python console with its completion capabilities activated. It would be a
>very nice way of interactively discovering the fields of a RecArray object.
>I don't know whether this feature is used a lot or not out there, but for me
>is just great.  I understand, however, that having to include a map to
>suport non-vbalid python names for field names can be quite inconvenient.
>
>Regards,
>  
>
Perry's issue 3.

Perhaps there is a need to separate the name or identifier of a column 
in a RecArray or a field in a Record from its label.  The labels, for 
display purposes, would default to the column names.  The column names 
would default, as at present, to the Cn form.

I like the use of attributes for the column names, it avoids the problem 
Russell Owen mentioned above.
Suppose we have a simple RecArray with the fields "name" and "age", it's 
much simpler to write rec.name or rec.age that rec["name"] or rec["age"].

The problems with the use of attributes, which must be Python names, are 
(1) they cannot have accented or special characters eg é, ç, @, & * 
etc.  and (2) there is a danger of conflict with existing properties or 
attributes.  My guess is that the special characters would be required 
primarily for display purposes.  Thus, the label could meet that need.

The danger of conflict could be addressed by raising an exception.  
There remains a possible problem where identifiers are passed on from 
some other system, perhaps a database. 

Thus, the primary identifier of a row in a RecArray would be an integer 
index and that of a column or field would be a standard Python 
identifer.  Although, at times, it would be useful to be able to index 
the individual fields (or columns) as part of the usual indexing 
scheme.  Thus rec[2, 3, 4] could identify a record and rec[2, 3, 4].age 
or rec[2, 3, 4, 5] could identify the sixth field in that record.

The use of attributes raises the possibility that one could have nested 
records.  For example, suppose one has an address record:

addressRecord
   streetNumber
   streetName
   postalCode
   ...

There could then be a personal record:
personRecord
   ...
   officeAddress
   homeAddress
   ...

One could address a component as rec.homeAddress.postalCode.

Finally, there was mention, earlier in the discussion, of facilitating 
the indexing of a RecArray.  I hope that some way will be found to do this.

Colin W.

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story

[Francesc A. <fa...@py...>]

Hi,

I agree that numarray team's overhaul of RecArray access modes is very good
and I agree most of it.

A Dimarts 20 Juliol 2004 19:14, Russell E Owen va escriure:
> I think recarray[field name] is too easily confused with 
> recarray[index] and is unnecessary.

Yeah, maybe you are right.

> I suggest one of two solutions:
> - Do nothing. Make users use field(field name or index)
> or
> - Allow access to the fields via an indexable entity. Simplest for 
> the user would be to use "field" itself:
>    recArr.field[1]
>    recArr.field["abc"]
> (i.e. field becomes an object that can be called or can be accessed 
> via __getitem__)

I prefer the second one. Although I know that you don't like the __getattr__
method, the field object can be used to host one. The main advantage I see
having such a __getattr__ method is that I'm very used to press TAB twice in
the python console with its completion capabilities activated. It would be a
very nice way of interactively discovering the fields of a RecArray object.
I don't know whether this feature is used a lot or not out there, but for me
is just great.  I understand, however, that having to include a map to
suport non-vbalid python names for field names can be quite inconvenient.

Regards,

-- 
Francesc Alted

Re: [Numpy-discussion] Is there a better way to do this?

[Rick W. <rl...@st...>]

On Wed, 21 Jul 2004, Hee-Seng Kye wrote:

> I'm trying to write a program that computes six-digit numbers, in which
> the left digit is always smaller than its following digit (i.e., it's
> always ascending).

Here's another version that is a little faster still:

def f3():
  c = 1
  for p0 in range(0, 7):
    for p1 in range(p0+1, 8):
      for p2 in range(p1+1, 9):
        for p3 in range(p2+1, 10):
          for p4 in range(p3+1, 11):
            for p5 in range(p4+1, 12):
              print repr(c).rjust(3), "\t",
              print "%X %X %X %X %X %X" % (p0, p1, p2, p3, p4, p5)
              c += 1
  print "...Done"

This is plenty fast even for 9-digit numbers.  In fact it gets
a little faster for larger numbers of digits.

This problem is completely equivalent to the problem of finding
all combinations of 6 numbers chosen from the digits 0..11.
If you sort the digits of each combination in ascending order,
you get your numbers.  So if you search for something like
"Python permutations combinations" you can find other algorithms
that work.  Here's a recursive version:

def f4(n, digits=range(12)):
    if n==0:
        return [[]]
    rv = []
    for i in range(len(digits)):
        for cc in f4(n-1,digits[i+1:]):
            rv.append([digits[i]]+cc)
    return rv

That returns a list of all the number sets having n digits.
It's slower than the loop version but is more general.  There
are fast C versions of this sort of thing out there, I think.
				Rick White

Re: [Numpy-discussion] Is there a better way to do this?

[Jeffery D. C. <jco...@ea...>]

Hee-Seng Kye wrote:

> My question is not directly related to NumPy, but since many people 
> here deal with numbers, I was wondering if I could get some help; it 
> would be even better if there is a NumPy (or Numarray) function that 
> takes care of what I want!
>
> I'm trying to write a program that computes six-digit numbers, in 
> which the left digit is always smaller than its following digit (i.e., 
> it's always ascending).  The best I could do was to have many embedded 
> 'for' statement:
>
> c = 1
> for p0 in range(0, 7):
>   for p1 in range(1, 12):
>     for p2 in range(2, 12):
>       for p3 in range(3, 12):
>         for p4 in range(4, 12):
>           for p5 in range(5, 12):
>             if p0 < p1 < p2 < p3 < p4 < p5:
>               print repr(c).rjust(3), "\t",
>               print "%X %X %X %X %X %X" % (p0, p1, p2, p3, p4, p5)
>               c += 1
> print "...Done"
>
> This works, except that it's very slow.  I need to get it up to 
> nine-digit numbers, in which case it's significantly slow.  I was 
> wondering if there is a more efficient way to do this.
>
> I would highly appreciate it if anyone could help.

This appears to give the same results and is significantly faster.

def vers1():
    c = 1
    for p0 in range(0, 7):
        for p1 in range(p0+1, 12):
            for p2 in range(p1+1, 12):
                for p3 in range(p2+1, 12):
                    for p4 in range(p3+1, 12):
                        for p5 in range(p4+1, 12):
                            print repr(c).rjust(3), "\t",
                            print "%X %X %X %X %X %X" % (p0, p1, p2, p3, 
p4, p5)
                            c += 1
    print "...Done"


>
> Many thanks.
>
> -Kye
>
--
Jeff

[Numpy-discussion] Is there a better way to do this?

[Hee-Seng K. <ky...@ea...>]

My question is not directly related to NumPy, but since many people 
here deal with numbers, I was wondering if I could get some help; it 
would be even better if there is a NumPy (or Numarray) function that 
takes care of what I want!

I'm trying to write a program that computes six-digit numbers, in which 
the left digit is always smaller than its following digit (i.e., it's 
always ascending).  The best I could do was to have many embedded 'for' 
statement:

c = 1
for p0 in range(0, 7):
   for p1 in range(1, 12):
     for p2 in range(2, 12):
       for p3 in range(3, 12):
         for p4 in range(4, 12):
           for p5 in range(5, 12):
             if p0 < p1 < p2 < p3 < p4 < p5:
               print repr(c).rjust(3), "\t",
               print "%X %X %X %X %X %X" % (p0, p1, p2, p3, p4, p5)
               c += 1
print "...Done"

This works, except that it's very slow.  I need to get it up to 
nine-digit numbers, in which case it's significantly slow.  I was 
wondering if there is a more efficient way to do this.

I would highly appreciate it if anyone could help.

Many thanks.

-Kye

Re: [Numpy-discussion] formats in record array

[Rick W. <rl...@st...>]

On Wed, 21 Jul 2004, Jin-chung Hsu wrote:

> > From: Russell E Owen <rowen@u.washington.edu>
> > Subject: Re: [Numpy-discussion] Proposed record array behavior: the rest
> > of the story
> >
> > Will it be possible, when creating a new records array, to specify
> > types of a record array as a list of normal numarray types? Currently
> > one has to specify the types as a "formats" string, which is
> > nonstandard.
>
> In theory it is easy to do that except you can't specify cell arrays, i.e.
> how do you specify the equivalent of:
>
> formats=['3Int16', '(4,5)Float32']
>
> with the numarray type instances?
>
> JC Hsu

Well, how about one (or both) of these:

formats = 3*(Int16,), 4*(5*(Float32,),)

formats = (3,Int16), ((4,5), Float32)

[Numpy-discussion] formats in record array

[Jin-chung H. <hs...@st...>]

> From: Russell E Owen <rowen@u.washington.edu>
> Subject: Re: [Numpy-discussion] Proposed record array behavior: the rest
> of the story


> Will it be possible, when creating a new records array, to specify 
> types of a record array as a list of normal numarray types? Currently 
> one has to specify the types as a "formats" string, which is 
> nonstandard.

In theory it is easy to do that except you can't specify cell arrays, i.e.
how do you specify the equivalent of:

formats=['3Int16', '(4,5)Float32']

with the numarray type instances?

JC Hsu

Re: [Numpy-discussion] Proposed record array behavior: the rest of the story

[Russell E O. <rowen@u.washington.edu>]

At 12:04 PM -0400 2004-07-20, Perry Greenfield wrote:
>...(a detailed summary of proposed changes to numarray record arrays)

+1 on all of it with one exception noted below. This sounds like a 
first-rate overhaul and is much appreciated.

Will it be possible, when creating a new records array, to specify 
types of a record array as a list of normal numarray types? Currently 
one has to specify the types as a "formats" string, which is 
nonstandard.

I'm unhappy about one proposal:
>...
>Record array behavior changes:
>...
>5) Field name indexing for record arrays. It will be possible to index
>record arrays with a field name, i.e., if the index is a string, then what
>will be returned is a numarray/chararray for that column. (Note that it
>won't be possible to index record arrays by field number for obvious
>reasons).
>
>I.e. Currently
>
>>>>  col = recArr.field('doc')
>
>Can also be
>
>>>>  col = recArr['abc']
>
>But the current
>
>>>>  col = recArr.field(1)
>
>Cannot become
>
>>>>  col = recArr[1]

I think recarray[field name] is too easily confused with 
recarray[index] and is unnecessary.

I suggest one of two solutions:
- Do nothing. Make users use field(field name or index)
or
- Allow access to the fields via an indexable entity. Simplest for 
the user would be to use "field" itself:
   recArr.field[1]
   recArr.field["abc"]
(i.e. field becomes an object that can be called or can be accessed 
via __getitem__)

This could easily support index arrays (a topic you brought up and 
that sound appealing to me):
   recArr.field[index array]
and it might even be practical to support:
   recArr.field[sequence of field indices and/or names]
e.g.
   recArr.field[(ind 1, field name 2, ind 3...)]

You asked about other issues. One that comes to mind is record arrays 
of record arrays. Should they be allowed? My gut reaction is yes if 
it's not too hard. Folks always seem to find a use for generality if 
it's offered. On the other hand, if it's hard, it's not worth the 
effort. If they are allowed, users are going to want some efficient 
way to get to a particular field (i.e. in one call even if the field 
is several recArrays deep). That could get messy.

Thanks for a great posting. The improvements to record arrays sound first-rate.

-- Russell