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

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Travis O. <oli...@ee...>]

Soeren Sonnenburg wrote:

>I am realizing that this must have been why cvxopt switched away from
>numarray/numeric. There slicing/indexing and '*' work as I would have
>expected:
>  
>
cvxopt uses it's own classes because they did not feel that a general 
purpose array was needed.  They wanted to define a matrix class with 
sparse matrix and dense matrix sub-classes.   In fact, cvxopt's matrix 
classes can not be used as ubiquitously as Numeric/numarray arrays.   
Everything is not a matrix.  In fact, I would like to see more general 
linear algebra routines that allow people to more naturally deal with 
(for example) six-dimensional linear operators mapping from a 
three-dimensional space to a three-dimensional space.  Currently, you 
are forced to perform an artificial row-scanning procedure just to 
interface with matrix libraries.  Scipy can help with this kind of thing.

I do not see cvxopt as a competing array implementation.   At some 
point, hopefully cvxopt will be integrated with scipy.  I am continually 
looking for feasible ways to make scipy more attractive to 
contributors.  Everybody benefits when their is a standard 
infrastructure.   For example, there are sparse matrices in SciPy.  If 
cvxopt has better sparse matrix objects, I would love to use them.  
Hopefully, the array interface will assist on a more abstract scale so 
that memory re-use can occur for at least the dense cvxopt matrices.

>It now seems very difficult for me to end up with a single
>numeric/matrix package that makes it into core python - which is at the
>  
>
>same time very sad.
>  
>

Their are several issues here.  But, yes a Matrix object will always be 
a separate object just as quaternions should be because they represent 
an interpretation to a memory block.  In Numeric/numarray the focus is 
on generic multidimensional arrays.  Therefore numeric operators must be 
element-by element. 

Note that Numeric does have a Matrix object that allows you to use '*' 
to represent matrix multiplication.   It's only problem is that passing 
this object to a function usually returns an array again instead of a 
Matrix. 

-Travis

Re: [Numpy-discussion] convolve

[<rba...@cl...>]

Le Mardi 26 Juillet 2005 10:58, Ren=E9 Bastian a =E9crit :
> Hello,
>
> in the actual form
>
> convolve(a,b)=3D=3Dconvolve(b,a)[::-1]
>
> but following the mathematics,
> one should obtain
>
> convolve(a,b)=3D=3Dconvolve(b,a)
>
> can anyone explain me the reason ?

I think the reasons are the modes other than FULL
and the re-use of "correlate"

Are this good reasons ?

>
> thanks

--=20
Ren=E9 Bastian
http://www.musiques-rb.org/Ecchym/voiture.html

Re: [Numpy-discussion] fft output and input storage

[Warren F. <fo...@sl...>]

>>> print FFT.fft.__doc__
fft(a, n=None, axis=-1)

    Will return the n point discrete Fourier transform of a. n defaults to the
    length of a. If n is larger than a, then a will be zero-padded to make up
    the difference. If n is smaller than a, the first n items in a will be
    used.

    The packing of the result is "standard": If A = fft(a, n), then A[0]
    contains the zero-frequency term, A[1:n/2+1] contains the
    positive-frequency terms, and A[n/2+1:] contains the negative-frequency
    terms, in order of decreasingly negative frequency. So for an 8-point
    transform, the frequencies of the result are [ 0, 1, 2, 3, 4, -3, -2, -1].

    This is most efficient for n a power of two. This also stores a cache of
    working memory for different sizes of fft's, so you could theoretically
    run into memory problems if you call this too many times with too many
    different n's.
>>>

Hmph.  The style guide says I should've put a blank line on the end of
that docstring.  But I don't think there was a style guide then.

w

On Tue, 26 Jul 2005, Daniel Sheltraw wrote:

> Hello all
>
> Would someone please tell me how negative and positive
> frequencies are
> stored in the output of the Numerical Python fft?
>
> Cheers,
> Daniel
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

[Numpy-discussion] fft output and input storage

[Daniel S. <she...@un...>]

Hello all

Would someone please tell me how negative and positive 
frequencies are
stored in the output of the Numerical Python fft?

Cheers,
Daniel

[Numpy-discussion] convolve

[<rba...@cl...>]

Hello,

in the actual form=20

convolve(a,b)=3D=3Dconvolve(b,a)[::-1]

but following the mathematics,
one should obtain

convolve(a,b)=3D=3Dconvolve(b,a)

can anyone explain me the reason ?

thanks
--=20
Ren=E9 Bastian
http://www.musiques-rb.org

Re: [Numpy-discussion] is numerical python only for prototyping ?

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

On Jul 26, 2005, at 12:41 PM, Sebastian Haase wrote:

> Hi,
> This is not sopposed to be an evil question; instead I'm hoping for the
> answer: "No, generally we get >=95% the speed of a pure C/fortran
> implementation" ;-)
> But as I am the strongest Python/numarray advocate in our group I get 
> often
> the answer that Matlab is (of course) also very convenient but 
> generally
> memory handling and overall execution performance is so bad that for 
> final
> implementation one would generally have to reimplement in C.
> We are a bio-physics group at UCSF developping new algorithms for
> deconvolution (often in 3D). Our data sets are regularly bigger than 
> several
> 100MB.  When deciding for numarray I was assuming that the "Hubble 
> Crowd" had
> a similar situation and all the operations are therefore very much 
> optimized
> for this type of data.
> Is 95% a reasonable number to hope for ?  I did wrap my own version of 
> FFTW
> (with "plan-caching"), which should give 100% of the C-speed. But 
> concerns
> arise from expression like "a=b+c*a" (think "convenience"!): If a,b,c 
> are
> each 3D-datastacks creation of temporary data-arrays for 'c*a' AND 
> then also
> for 'b+...' would have to be very costly. (I think this is at least 
> happening
> for Numeric - I don't know about Matlab and numarray)
>

Is it speed or memory usage you are worried about? Where are you 
actually seeing unacceptable performance?

Offhand, I would say the temporaries are not likely to be serious speed 
issues (unless you running out of memory). We did envision at some 
point (we haven't done it yet) of recognizing situations where the 
temporaries could be reused.

As for 95% speed, it's not what required for our work (I think that 
what an acceptable speed ratio is depends on the problem). In many 
cases being within 50% is good enough except for heavily used things 
where it would need to be faster. But yes, we do plan on (and do indeed 
actually use it now) for large data sets where speed is important. We 
generally don't compare the numarray speed to C speed all the time (if 
we were writing C equivalents every time, that would defeat the purpose 
of using Python :-). Perhaps you could give a more specific example 
with some measurements? I don't think I would promise anyone that all 
one's code could be done in Python. Undoubtedly, there are going to be 
some cases where coding in C or similar is going to be needed. I'd just 
argue that Python let's you keep as much as possible in a higher level 
language and a little as necessary in a low level language such as C.

Perry

Re: [Numpy-discussion] is numerical python only for prototyping ?

[Peter V. <ve...@em...>]

On 26 Jul 2005, at 18:41, Sebastian Haase wrote:

> Hi,
> This is not sopposed to be an evil question; instead I'm hoping for the
> answer: "No, generally we get >=95% the speed of a pure C/fortran
> implementation" ;-)

you won't, generally. Question is: since you are certainly not going to 
gain an order of a magnitude doing it in C,  do you really care?

> But as I am the strongest Python/numarray advocate in our group I get 
> often
> the answer that Matlab is (of course) also very convenient but 
> generally
> memory handling and overall execution performance is so bad that for 
> final
> implementation one would generally have to reimplement in C.

Well its true that implementations in C will be faster. And memory 
handling in Numeric/numarray can be a pain since the tendency is to 
create and destroy a lot of arrays if you are not careful.

> We are a bio-physics group at UCSF developping new algorithms for
> deconvolution (often in 3D). Our data sets are regularly bigger than 
> several
> 100MB.  When deciding for numarray I was assuming that the "Hubble 
> Crowd" had
> a similar situation and all the operations are therefore very much 
> optimized
> for this type of data.

Funny you mention that example. I did my PhD in exactly the same field 
(considering you are from Sedats lab I guess you are in exactly the 
same field as I was/am, i.e. fluorescence microscopy. What are you guys 
up to these days?) and I developed all my algorithms in C at the time. 
Now, about 7 years later, I returned to the field to re-implement and 
extend some of my old algorithms for use with microscopy data that can 
consist of multiple sets, each several 100MB at least. Now I use python 
with numarray, and I am actualy quite happy with.  I am pushing it by 
using up to 2GB of memory, (per  process, after splitting the problem 
up and distributing it on  a cluster...), but it works. I am sure I 
could squeeze maybe a factor of two or three in terms of speed and 
memory usage by rewriting in C, but that is currently not worth my 
time. So I guess that counts as using numarray as a prototyping 
environment, but the result is also suitable for production use.

> Is 95% a reasonable number to hope for ?  I did wrap my own version of 
> FFTW
> (with "plan-caching"), which should give 100% of the C-speed.

That should help a lot, as the standard FFTs that come with 
Numarray/Numeric suck big time. I do use them, but have to go through 
all kind of tricks to get some decent memory usage in 32bit floating 
point. The FFT array module is in fact very badly written for use with 
large multi-dimensional data sets.

> But concerns
> arise from expression like "a=b+c*a" (think "convenience"!): If a,b,c 
> are
> each 3D-datastacks creation of temporary data-arrays for 'c*a' AND 
> then also
> for 'b+...' would have to be very costly. (I think this is at least 
> happening
> for Numeric - I don't know about Matlab and numarray)

That is indeed a problem, although I think in your case you maybe 
limited by your FFTs anyway, at least in terms of speed. One thing you 
should consider is replacing expressions such as ' c= a + b' with 
add(a, b, c). If you do that cleverly you can avoid quite some memory 
allocations and you 'should' get closer to C. That does not solve 
everything though:

1) Complex expressions still need to be broken up in  sequences of 
operations which is likely slower then iterating once over you array 
and do the expression at each point.
2) Unfortunately not all numarray functions support an output array 
(maybe only the ufuncs?). This can be a big problem, as then temporary 
arrays must be allocated. (It sure was a problem for me.)

You can of course always re-implement the parts that are critical in C 
and wrap them (as you did with FFTW). In fact, I think numarray now 
provides a relatively easy way to write ufuncs which would allow you to 
write a single python function in C for complex expressions.

> Hoping for comments,

Hope this gives some insights. I guess I have had similar experiences, 
there are definitely some limits to the use of numarray/Numeric that 
could be relieved, for instance by having a consistent implementation 
of output arrays. That would allow writing algorithms where you could 
very strictly control the allocation and de-allocation of arrays, which 
would be a big help for working with large arrays.

Cheers, Peter

PS.
I would not mind to hear a bit about your experiences doing the big 
deconvolutions in numarray/Numeric, but that may not be a good topic 
for this list.

> Thanks
> Sebastian Haase
> UCSF, Sedat Lab
>
--
Dr Peter J Verveer
European Molecular Biology Laboratory
Meyerhofstrasse 1
D-69117 Heidelberg
Germany
Tel. +49 6221 387 8245
Fax. +49 6221 397 8306

[Numpy-discussion] is numerical python only for prototyping ?

[Sebastian H. <ha...@ms...>]

Hi,
This is not sopposed to be an evil question; instead I'm hoping for the 
answer: "No, generally we get >=95% the speed of a pure C/fortran 
implementation" ;-)
But as I am the strongest Python/numarray advocate in our group I get often 
the answer that Matlab is (of course) also very convenient but generally 
memory handling and overall execution performance is so bad that for final 
implementation one would generally have to reimplement in C.
We are a bio-physics group at UCSF developping new algorithms for 
deconvolution (often in 3D). Our data sets are regularly bigger than several 
100MB.  When deciding for numarray I was assuming that the "Hubble Crowd" had 
a similar situation and all the operations are therefore very much optimized 
for this type of data.
Is 95% a reasonable number to hope for ?  I did wrap my own version of FFTW 
(with "plan-caching"), which should give 100% of the C-speed. But concerns 
arise from expression like "a=b+c*a" (think "convenience"!): If a,b,c are 
each 3D-datastacks creation of temporary data-arrays for 'c*a' AND then also 
for 'b+...' would have to be very costly. (I think this is at least happening 
for Numeric - I don't know about Matlab and numarray)

Hoping for comments,
Thanks
Sebastian Haase
UCSF, Sedat Lab

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Chris B. <Chr...@no...>]

Soeren Sonnenburg wrote:
> Hmmhh. I see that this again breaks with R/octave/matlab. One should not
> do so if there is no serious reason. It just makes life harder for every
> potential convert from any of these languages.

If you're looking for a matlab clone, use octave or psilab, or....

Speaking as an ex-matlab user, I much prefer the NumPy approach. The
reason is that I very rarely did linear algebra, and generally used
matlab as a general computational environment. I got very tired of
having to type that "." before all my operators. I also love array
broadcasting, it seems so much cleaner and efficient.

When I moved from Matlab to NumPy, I missed these things:

Integrated plotting: many years later, this is still weak, but at least
for 2-d matplotlib is wonderful.

The large library of math functions: SciPy is moving to fill that gap.

Automatic handling of IEEE special values: numarray now does that pretty
well.

That's what I missed. What I gained was a far more powerful and
expressive language, AND a more powerful and flexible array type. I
don't miss MATLAB at all. In fact, you'll find me on the matplotlib
mailing list, often repeating the refrain: matplotlib is NOT MATLAB nor
should it be!

> It now seems very difficult for me to end up with a single
> numeric/matrix package that makes it into core python - 

That is probably true.

> which is at the same time very sad.

But I'm not sure we should be sad about it. What we all  want is the
package best suited to our own needs to be in the standard library.
However, I'd rather the current situation than having a package poorly
suited to my needs in the standard library. As this thread proves, there
is no one kind of array package that would fit even most people's needs.

However, there is some promise for the future:

1) SciPy base may serve to unify Numeric/numarray

2) Travis has introduced the "array interface"

http://numeric.scipy.org/array_interface.html

this would provide an efficient way for the various array and matrix
packages to exchange data. It does have a hope of making it into the
standard library, though even if it doesn't, if a wide variety of add-on
packages use it, then the same thing is accomplished. If fact, if
packages that don't implement an array type, but might use one (like
PIL, wxPython, etc) accept this interface, then any package that
implements it can be used together with them.

3) What  about PEP 225: Elementwise/Objectwise Operators?
It's listed under:

Deferred, Abandoned, Withdrawn, and Rejected PEPs

Which of those applied here? I had high hope for it one time.

By the way, I had not seen cvxopt before, thanks for the link. Perhaps
it would serve as a better base for a full-featured linear algebra
package than Numeric/numarray. Ideally, it could use the array
interface, for easy exchange of data with other packages.

-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...

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

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

On Jul 26, 2005, at 12:35 AM, Soeren Sonnenburg wrote:

>> Since we deal with big data sets we have adopted 2 (no doubt to the
>> consternation of many).
>
> hmmhh, there is no advantage with big datasets for any of the formats.
>
It is if you have to reorder the data, or use non-optimum iteration  
through the array. The first is definitely slower.

>>> Do you know whether mixing slices and arrays will be supported at  
>>> some
>>> point a[:,[0,1]] ?
>>>
>>> Soeren.
>>
>> No plans at the moment. We figured indexing was complicated enough as
>> it was. I think Travis Oliphant did allow for this in Numeric3 (aka
>> scipy.core); see the link below. But it may not mean what you think it
>> should so you should check that out to see:
>>
>> http://cvs.sourceforge.net/viewcvs.py/numpy/Numeric3/PEP.txt? 
>> view=markup
>
> Hmmhh while we are at it, is there work on a consensus num* ? I've seen
> the PEP for inclusion of numarray, now I see numeric3 and scipy and  
> also
> cvxopt - are people actually converging towards a single num* package ?
>
That's what the goal of Numeric3 is as far as different underlying  
array engines. But if you mean a merging of the array/matrix  
viewpoints, I think you've answered your own question.

Perry

Re[2]: [Numpy-discussion] design issues - octave 'incompatibilities'

[Alan G I. <ai...@am...>]

On Tue, 26 Jul 2005, Soeren Sonnenburg apparently wrote: 
> In my eyes 'array broadcasting' is confusing and should rather be in a 
> function like meshgrid and instead a*b should return 
> matrixmultiply(a,b) ... 

It does, if you work with matrices. Try
import scipy
help(scipy.mat)

Coming from GAUSS I had the same initial reaction.
It did not last long.

hth,
Alan Isaac

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

On Mon, 2005-07-25 at 17:47 -0400, Perry Greenfield wrote:
> I missed this part and was reminded by Travis's message.
> 
> On Jul 23, 2005, at 12:03 PM, Soeren Sonnenburg wrote:
> > -- How can one obtain submatrices from full matrices:
> >
> > numarray gives only elements (which is very, very rarely needed and
> > should IMHO rather be some extra function):
> >
> >>>> i=[0,1]
> >>>> j=[0,2]
> >>>> a[i,j]
> > array([1, 6])
> >
> > vs octave:
> >>> i=[1,2];
> >>> j=[1,3];
> >>> a(i,j)
> > ans =
> >         1        3
> >         4        6
> >
> Maybe for you it is rarely needed, but not for us. The situation is 
> reversed. The latter is rarely used in our case. This is largely a 
> reflection of whether your orientation is matrices or multidimensional 
> arrays. In our case it is quite handy to select out a list of point in 
> an image by giving a list of their respective indices (e.g., stars).

Hmmhh. I see that this again breaks with R/octave/matlab. One should not
do so if there is no serious reason. It just makes life harder for every
potential convert from any of these languages. A funktion take() would
have served this purposed much better... but this is ofcourse all IMHO
and I can see your point: You design it according to your (or your
communities) requirements and different communities different needs... 

I am realizing that this must have been why cvxopt switched away from
numarray/numeric. There slicing/indexing and '*' work as I would have
expected:

In [71]: a=matrix([1,2,3,4,5,6,7,8,9],size=(3,3))
In [72]: a
Out[72]: <3x3 matrix, tc='d'>
In [73]: b=matrix([1,2,3,4,5,6,7,8,9],size=(3,3))
In [74]: a*b
Out[74]: <3x3 matrix, tc='d'>
In [75]: print a
   1.0000e+00   4.0000e+00   7.0000e+00
   2.0000e+00   5.0000e+00   8.0000e+00
   3.0000e+00   6.0000e+00   9.0000e+00

In [76]: print b
   1.0000e+00   4.0000e+00   7.0000e+00
   2.0000e+00   5.0000e+00   8.0000e+00
   3.0000e+00   6.0000e+00   9.0000e+00

In [77]: print a*b
   3.0000e+01   6.6000e+01   1.0200e+02
   3.6000e+01   8.1000e+01   1.2600e+02
   4.2000e+01   9.6000e+01   1.5000e+02

In [78]: print a[:,0]
   1.0000e+00
   2.0000e+00
   3.0000e+00

In [79]: print a[0,1]
4.0
In [80]: print a[0,:]
   1.0000e+00   4.0000e+00   7.0000e+00

> True, I do see that others may need the other view, but then the 
> question is which should get the convenience. Since Numeric/numarray 
> are primarily oriented towards multidimensional arrays (e.g., 
> operations are element-by-element rather than matrix) it seemed to make 
> sense to go this way for consistency, but I understand that there is 
> another side to this.

It now seems very difficult for me to end up with a single
numeric/matrix package that makes it into core python - which is at the
same time very sad.

Soeren

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Robert K. <rk...@uc...>]

Soeren Sonnenburg wrote:
> On Mon, 2005-07-25 at 08:59 -0700, Chris Barker wrote:

[snip]

>>such thing as a column vs. a row vector. A vector is a one-dimensional 
>>array: it has no orientation.
> 
> This makes life more difficult if one wants to convert 
> from octave/matlab -> numarray and automated systems close to
> impossible.

<shrug> That wasn't a design goal.

> If vectors had the same properties/functions as matrices one
> would not have such problems, i.e. v^{transpose} * u == dot(v,u) and v*u
> -> error

That would be a big problem for those of us who don't use Numeric just 
for linear algebra. These are general arrays, not matrices and vectors.

[snip]

> In my eyes 'array broadcasting' is confusing and should rather be in a
> function like meshgrid and instead a*b should return
> matrixmultiply(a,b) ...

Spend some time with it. It will probably grow on you. Numeric is not 
Matlab or Octave. It never will be, thank G-d.

[snip]

>>I hope that helps:
> 
> Indeed it does - Thanks!! Unfortunately I am not at all happy now that
> '*' != matrixmultiply (but outerproduct) for vectors/matrices...

Again, Numeric is a package for arrays, not just linear algebra. Please 
spend some more time with Python and Numeric before deciding that they 
must be changed to match your preconceptions.

> I realize that with lists it is ok to grow them via slicing.
> 
> x=[]
> x[0]=1
> IndexError: list assignment index out of range
> x[0:0]=[1]
> x
> [1]
> 
> that seems not to work with numarray ... or ?
> 
> y=array()
> y[0]=1
> TypeError: object does not support item assignment
> y[0:0]=array([1])
> TypeError: object does not support item assignment

Python lists are designed to grow dynamically. Their memory is 
preallocated so that growing them is on average pretty cheap. Numeric 
arrays are not, nor will they be.

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

On Mon, 2005-07-25 at 08:59 -0700, Chris Barker wrote:
> Soeren Sonnenburg wrote:
> > -- why do vectors have no 'orientation', i.e. there are only row but no
> > column vectors (or why do you treat matrices/vectors differently, i.e.
> > have vectors at all as a separate type)
> 
> I think the key to understanding this is that NumPy uses a 
> fundamentally different data type that MATLAB and it's derivatives. 
> MATLAB was originally just what it is called: a "Matrix" laboratory. The 
> basic data type of Matlab is a 2-d matrix. Even a scalar is really a 1X! 
> matrix. Matlab has a few tricks that can make these look like row and 
> column vectors, etc, but they are really always matrices.

Ok, I am realizing that R also distinguishes between vectors and
matrices.

> On the other hand, NumPy arrays are N-dimensional, where N is 
> theoretically unlimited. In practice, I think the max N is defined and 
> compiled in, but you could change it and re-compile if you wanted. In 
> any case, many of us frequently use 3-d and higher arrays, and they can 
> be very useful. When thought  of this way, you can see why there is no 

Well at least this is the same for octave/matlab.

> such thing as a column vs. a row vector. A vector is a one-dimensional 
> array: it has no orientation.

This makes life more difficult if one wants to convert 
from octave/matlab -> numarray and automated systems close to
impossible. If vectors had the same properties/functions as matrices one
would not have such problems, i.e. v^{transpose} * u == dot(v,u) and v*u
-> error

> However, NumPy does support NX1 and 1XN 2-d arrays which can be very handy:
>  >>> import numarray as N
>  >>> a = N.arange(5)
>  >>> a.shape = (1,-1)
>  >>> a
> array([[0, 1, 2, 3, 4]])
>  >>> b = N.arange(5)
>  >>> b.shape = (-1,1)
>  >>> a
> array([0, 1, 2, 3, 4])
>  >>> b
> array([[0],
>         [1],
>         [2],
>         [3],
>         [4]])
> 
> So a is a row vector and b is a column vector. If you multiply them, you 
> get "array broadcasting":
>  >>> a * b
> array([[ 0,  0,  0,  0,  0],
>         [ 0,  1,  2,  3,  4],
>         [ 0,  2,  4,  6,  8],
>         [ 0,  3,  6,  9, 12],
>         [ 0,  4,  8, 12, 16]])
> 
> This eliminates a LOT of extra duplicate arrays that you have to make in 
> Matlab with meshgrid.

In my eyes 'array broadcasting' is confusing and should rather be in a
function like meshgrid and instead a*b should return
matrixmultiply(a,b) ...

> When you index into an array, you reduce its rank (number of dimensions) 
> by 1:
>  >>> a = N.arange(27)
>  >>> a.shape = (3,3,3)
>  >>> a
> array([[[ 0,  1,  2],
>          [ 3,  4,  5],
>          [ 6,  7,  8]],
> 
>         [[ 9, 10, 11],
>          [12, 13, 14],
>          [15, 16, 17]],
> 
>         [[18, 19, 20],
>          [21, 22, 23],
>          [24, 25, 26]]])
>  >>> a.shape
> (3, 3, 3)
>  >>> a[1].shape
> (3, 3)
>  >>> a[1][1].shape
> (3,)
> 
> When you slice, you keep the rank the same:
> 
>  >>> a[1:2].shape
> (1, 3, 3)
> 
> This creates a way to make row and column "vectors" from your 2-d array 
> (matrix)
>  >>> a = N.arange(25)
>  >>> a.shape = (5,5)
>  >>> a
> array([[ 0,  1,  2,  3,  4],
>         [ 5,  6,  7,  8,  9],
>         [10, 11, 12, 13, 14],
>         [15, 16, 17, 18, 19],
>         [20, 21, 22, 23, 24]])
> 
> To make a "row vector" (really a 1XN matrix)
>  >>> a[0:1,:]
> array([[0, 1, 2, 3, 4]])
> 
> 
> To make a "column vector" (really a NX1 matrix)
>  >>> a[:,0:1]
> array([[ 0],
>         [ 5],
>         [10],
>         [15],
>         [20]])
> 
> 
> I hope that helps:

Indeed it does - Thanks!! Unfortunately I am not at all happy now that
'*' != matrixmultiply (but outerproduct) for vectors/matrices...

I realize that with lists it is ok to grow them via slicing.

x=[]
x[0]=1
IndexError: list assignment index out of range
x[0:0]=[1]
x
[1]

that seems not to work with numarray ... or ?

y=array()
y[0]=1
TypeError: object does not support item assignment
y[0:0]=array([1])
TypeError: object does not support item assignment

Soeren.

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

On Mon, 2005-07-25 at 10:10 -0400, Perry Greenfield wrote:
> On Jul 24, 2005, at 2:41 PM, Soeren Sonnenburg wrote:
> 
> >
> > Well but why did you change to the C version then ? Well maybe if it is
> > about optimizing stuff seriously one could work with the transpose
> > anyway...
> >
> 
> To get a really solid answer to "why" you would have to ask those that 
> wrote the original Numeric. (Jim Hugunin and Co.). My guess is was that 
> it was just as much to preserve the following relation
> 
> arr[i,j] = arr[i][j]
> 
> (instead of arr[i,j] = arr[j][i])

Ok, that sounds reasonable.

> But I could be wrong.
> 
> Note that this is a confusing issue to many and often as not there are 
> unstated assumptions that are repeatedly made by many that are *not* 
> shared by everyone. To illustrate, there are at least two different 
> approaches to handling this mismatch and it seems to me that many seem 
> oblivious to the fact that there are two approaches.
> 
> Approach 1: Keep the index convention the same. As a user of Numeric or 
> numarray, you wish M[i,j] to mean the same as it does in 
> Fortran/IDL/matlab... The consequence is that the data are ordered 
> differently between Numeric/numarray and these other languages. This is 
> seen as a data compatibility problem.
> 
> Approach 2: Keep the data invariant and change the indexing convention. 
> What was M[i,j] in Fortran is now M[j,i] in Numeric/numarray. This is 
> not a data compatibility problem, but is now a brain compatibility 
> problem ;-)

well it might not be *that* bad in the end... only it is a tough
decision to break with everything that is there (to put it to extreme:
the world is wrong and but we did it right) and be compatible with C
like array access... If one does so one needs to have very serious
reasons to do so ... that is why I was asking.

> Since we deal with big data sets we have adopted 2 (no doubt to the 
> consternation of many).

hmmhh, there is no advantage with big datasets for any of the formats.

> > Do you know whether mixing slices and arrays will be supported at some
> > point a[:,[0,1]] ?
> >
> > Soeren.
> 
> No plans at the moment. We figured indexing was complicated enough as 
> it was. I think Travis Oliphant did allow for this in Numeric3 (aka 
> scipy.core); see the link below. But it may not mean what you think it 
> should so you should check that out to see:
> 
> http://cvs.sourceforge.net/viewcvs.py/numpy/Numeric3/PEP.txt?view=markup

Hmmhh while we are at it, is there work on a consensus num* ? I've seen
the PEP for inclusion of numarray, now I see numeric3 and scipy and also
cvxopt - are people actually converging towards a single num* package ?

Soeren.

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

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

I missed this part and was reminded by Travis's message.

On Jul 23, 2005, at 12:03 PM, Soeren Sonnenburg wrote:
> -- How can one obtain submatrices from full matrices:
>
> numarray gives only elements (which is very, very rarely needed and
> should IMHO rather be some extra function):
>
>>>> i=[0,1]
>>>> j=[0,2]
>>>> a[i,j]
> array([1, 6])
>
> vs octave:
>>> i=[1,2];
>>> j=[1,3];
>>> a(i,j)
> ans =
>         1        3
>         4        6
>
Maybe for you it is rarely needed, but not for us. The situation is 
reversed. The latter is rarely used in our case. This is largely a 
reflection of whether your orientation is matrices or multidimensional 
arrays. In our case it is quite handy to select out a list of point in 
an image by giving a list of their respective indices (e.g., stars).

True, I do see that others may need the other view, but then the 
question is which should get the convenience. Since Numeric/numarray 
are primarily oriented towards multidimensional arrays (e.g., 
operations are element-by-element rather than matrix) it seemed to make 
sense to go this way for consistency, but I understand that there is 
another side to this.

Perry

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Travis O. <oli...@ee...>]

Soeren Sonnenburg wrote:

>Dear all,
>
>I am new to numarray and as I am trying to use it day-by-day
>I am now wondering about certain numeric/numarray design issues. Please
>forgive me / correct me as I probably misunderstood certain issues.
>
>-- Why did you choose row-major instead of column major format as
>practiced by R/octave/matlab... Doesn't that mean performance problems
>as fortran/blas is optimized if you work with the transposed version ?
>
>-- why do vectors have no 'orientation', i.e. there are only row but no
>column vectors (or why do you treat matrices/vectors differently, i.e.
>have vectors at all as a separate type)
>  
>
I think others have responded to these questions well.

>-- How can one obtain submatrices from full matrices:
>
>numarray gives only elements (which is very, very rarely needed and
>should IMHO rather be some extra function):
>  
>
I thought about this quite a bit because I initially felt as you did 
before beginning work on scipy.base (Numeric3).   I wondered if the 
right choice had been made.  After some thought and discussion, I 
decided this approach was more general and flexible, and agreed with the 
numarray design.  Therefore, this works in scipy.base the same.

Also, scipy.base does allow mixing slices and lists like you want:

import scipy.base

a = scipy.base.array([[1,2,3],[4,5,6],[7,8,9]])
 >>> a[:,[0,1]]
array([[1, 2], [4, 5], [7, 8]], 'l')


>
>-- why don't you allow iterating over the whole matrix via a single
>index ?
>  
>
You can with scipy.base with a.flat[index]    but ravel(a)[index] always 
works too.

The reason is that Numeric uses the concept of reduced-dimensionality 
arrays so that
a[index] for a 2-d array returns a 1-d array not an element of the 2-d 
array. 

It may be different then you are used to but I think it is a better choice.

Best regards,

-Travis Oliphant

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Chris B. <Chr...@no...>]

Soeren Sonnenburg wrote:
> -- why do vectors have no 'orientation', i.e. there are only row but no
> column vectors (or why do you treat matrices/vectors differently, i.e.
> have vectors at all as a separate type)

I think the key to understanding this is that NumPy uses a 
fundamentally different data type that MATLAB ans it's derivatives. 
MATLAB was originally just what it is called: a "Matrix" laboratory. The 
basic data type of Matlab is a 2-d matrix. Even a scalar is really a 1X! 
matrix. Matlab has a few tricks that can make these look like row and 
column vectors, etc, but they are really always matrices.

On the other hand, NumPy arrays are N-dimensional, where N is 
theoretically unlimited. In practice, I think the max N is defined and 
compiled in, but you could change it and re-compile if you wanted. In 
any case, many of us frequently use 3-d and higher arrays, and they can 
be very useful. When thought  of this way, you can see why there is no 
such thing as a column vs. a row vector. A vector is a one-dimensional 
array: it has no orientation.

However, NumPy does support NX1 and 1XN 2-d arrays which can be very handy:
 >>> import numarray as N
 >>> a = N.arange(5)
 >>> a.shape = (1,-1)
 >>> a
array([[0, 1, 2, 3, 4]])
 >>> b = N.arange(5)
 >>> b.shape = (-1,1)
 >>> a
array([0, 1, 2, 3, 4])
 >>> b
array([[0],
        [1],
        [2],
        [3],
        [4]])

So a is a row vector and b is a column vector. If you multiply them, you 
get "array broadcasting":
 >>> a * b
array([[ 0,  0,  0,  0,  0],
        [ 0,  1,  2,  3,  4],
        [ 0,  2,  4,  6,  8],
        [ 0,  3,  6,  9, 12],
        [ 0,  4,  8, 12, 16]])

This eliminates a LOT of extra duplicate arrays that you have to make in 
Matlab with meshgrid.

When you index into an array, you reduce its rank (number of dimensions) 
by 1:
 >>> a = N.arange(27)
 >>> a.shape = (3,3,3)
 >>> a
array([[[ 0,  1,  2],
         [ 3,  4,  5],
         [ 6,  7,  8]],

        [[ 9, 10, 11],
         [12, 13, 14],
         [15, 16, 17]],

        [[18, 19, 20],
         [21, 22, 23],
         [24, 25, 26]]])
 >>> a.shape
(3, 3, 3)
 >>> a[1].shape
(3, 3)
 >>> a[1][1].shape
(3,)

When you slice, you keep the rank the same:

 >>> a[1:2].shape
(1, 3, 3)

This creates a way to make row and column "vectors" from your 2-d array 
(matrix)
 >>> a = N.arange(25)
 >>> a.shape = (5,5)
 >>> a
array([[ 0,  1,  2,  3,  4],
        [ 5,  6,  7,  8,  9],
        [10, 11, 12, 13, 14],
        [15, 16, 17, 18, 19],
        [20, 21, 22, 23, 24]])

To make a "row vector" (really a 1XN matrix)
 >>> a[0:1,:]
array([[0, 1, 2, 3, 4]])


To make a "column vector" (really a NX1 matrix)
 >>> a[:,0:1]
array([[ 0],
        [ 5],
        [10],
        [15],
        [20]])


I hope that helps:
-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...

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

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

On Jul 24, 2005, at 2:41 PM, Soeren Sonnenburg wrote:

>
> Well but why did you change to the C version then ? Well maybe if it is
> about optimizing stuff seriously one could work with the transpose
> anyway...
>

To get a really solid answer to "why" you would have to ask those that 
wrote the original Numeric. (Jim Hugunin and Co.). My guess is was that 
it was just as much to preserve the following relation

arr[i,j] = arr[i][j]

(instead of arr[i,j] = arr[j][i])

But I could be wrong.

Note that this is a confusing issue to many and often as not there are 
unstated assumptions that are repeatedly made by many that are *not* 
shared by everyone. To illustrate, there are at least two different 
approaches to handling this mismatch and it seems to me that many seem 
oblivious to the fact that there are two approaches.

Approach 1: Keep the index convention the same. As a user of Numeric or 
numarray, you wish M[i,j] to mean the same as it does in 
Fortran/IDL/matlab... The consequence is that the data are ordered 
differently between Numeric/numarray and these other languages. This is 
seen as a data compatibility problem.

Approach 2: Keep the data invariant and change the indexing convention. 
What was M[i,j] in Fortran is now M[j,i] in Numeric/numarray. This is 
not a data compatibility problem, but is now a brain compatibility 
problem ;-)

Since we deal with big data sets we have adopted 2 (no doubt to the 
consternation of many).

This ought to be in a FAQ, it comes up enough to be :-)

>
> Do you know whether mixing slices and arrays will be supported at some
> point a[:,[0,1]] ?
>
> Soeren.

No plans at the moment. We figured indexing was complicated enough as 
it was. I think Travis Oliphant did allow for this in Numeric3 (aka 
scipy.core); see the link below. But it may not mean what you think it 
should so you should check that out to see:

http://cvs.sourceforge.net/viewcvs.py/numpy/Numeric3/PEP.txt?view=markup

Perry Greenfield

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Robert K. <rk...@uc...>]

Soeren Sonnenburg wrote:
> On Sat, 2005-07-23 at 12:06 -0700, Robert Kern wrote:
> 
>>Soeren Sonnenburg wrote:
>>
>>>Dear all,
>>>
>>>I am new to numarray and as I am trying to use it day-by-day
>>>I am now wondering about certain numeric/numarray design issues. Please
>>>forgive me / correct me as I probably misunderstood certain issues.
>>>
>>>-- Why did you choose row-major instead of column major format as
>>>practiced by R/octave/matlab... Doesn't that mean performance problems
>>>as fortran/blas is optimized if you work with the transposed version ?
>>
>>Not everyone is interfacing with optimized FORTRAN code. Those who are 
>>are usually using ATLAS as their BLAS, and ATLAS has row-major versions 
>>of the BLAS subroutines. Row-major is C's convention and 
>>numarray/Numeric largely follow that. There are of course some 
>>performance issues when interfacing with FORTRAN code that expects 
>>column-major, but there would be other performance problems if 
>>numarray/Numeric were column-major and interfacing with row-major code.
> 
> Well but why did you change to the C version then ? Well maybe if it is
> about optimizing stuff seriously one could work with the transpose
> anyway...

Because numarray and Python are written in C. It's also consistent with 
lists-of-lists.

In [8]: L = [[0, 1],[2,3]]

In [9]: A = array(L)

In [10]: L[1][0]
Out[10]: 2

In [11]: A[1][0]
Out[11]: 2

In [12]: A[1,0]
Out[12]: 2

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

On Sat, 2005-07-23 at 12:06 -0700, Robert Kern wrote:
> Soeren Sonnenburg wrote:
> > Dear all,
> > 
> > I am new to numarray and as I am trying to use it day-by-day
> > I am now wondering about certain numeric/numarray design issues. Please
> > forgive me / correct me as I probably misunderstood certain issues.
> > 
> > -- Why did you choose row-major instead of column major format as
> > practiced by R/octave/matlab... Doesn't that mean performance problems
> > as fortran/blas is optimized if you work with the transposed version ?
> 
> Not everyone is interfacing with optimized FORTRAN code. Those who are 
> are usually using ATLAS as their BLAS, and ATLAS has row-major versions 
> of the BLAS subroutines. Row-major is C's convention and 
> numarray/Numeric largely follow that. There are of course some 
> performance issues when interfacing with FORTRAN code that expects 
> column-major, but there would be other performance problems if 
> numarray/Numeric were column-major and interfacing with row-major code.

Well but why did you change to the C version then ? Well maybe if it is
about optimizing stuff seriously one could work with the transpose
anyway...

> Often, though, a "row" vector can also be used in place of a "column" 
> vector. Although sometimes not:

You are right, thanks!

> > Are there more elegant ways to do this ? Which issues are likely to be
> > fixed in the future ?
> 
> None. They're not broken, just different from what you are used to.

Thanks a lot for your very helpful mail!

Do you know whether mixing slices and arrays will be supported at some
point a[:,[0,1]] ?

Soeren.

Re: [Numpy-discussion] design issues - octave 'incompatibilities'

[Robert K. <rk...@uc...>]

Soeren Sonnenburg wrote:
> Dear all,
> 
> I am new to numarray and as I am trying to use it day-by-day
> I am now wondering about certain numeric/numarray design issues. Please
> forgive me / correct me as I probably misunderstood certain issues.
> 
> -- Why did you choose row-major instead of column major format as
> practiced by R/octave/matlab... Doesn't that mean performance problems
> as fortran/blas is optimized if you work with the transposed version ?

Not everyone is interfacing with optimized FORTRAN code. Those who are 
are usually using ATLAS as their BLAS, and ATLAS has row-major versions 
of the BLAS subroutines. Row-major is C's convention and 
numarray/Numeric largely follow that. There are of course some 
performance issues when interfacing with FORTRAN code that expects 
column-major, but there would be other performance problems if 
numarray/Numeric were column-major and interfacing with row-major code.

> -- why do vectors have no 'orientation', i.e. there are only row but no
> column vectors (or why do you treat matrices/vectors differently, i.e.
> have vectors at all as a separate type)

You can certainly make column vectors.

In [1]: a = arange(5)

In [2]: a
Out[2]: NumPy array, format: long
[0 1 2 3 4]

In [3]: a.shape = (5,1)

In [4]: a
Out[4]: NumPy array, format: long
[[0]
  [1]
  [2]
  [3]
  [4]]

Often, though, a "row" vector can also be used in place of a "column" 
vector. Although sometimes not:

> -- How can one obtain submatrices from full matrices:

In [6]: import numarray

In [7]: a = numarray.arange(1, 10)

In [8]: a.shape = (3,3)

In [9]: a
Out[9]:
array([[1, 2, 3],
        [4, 5, 6],
        [7, 8, 9]])

In [10]: i = [0,1]

In [11]: j = [[0],[2]]

In [12]: a[i,j]
Out[12]:
array([[1, 4],
        [3, 6]])

> -- why don't you allow iterating over the whole matrix via a single
> index ?

ravel()

> Are there more elegant ways to do this ? Which issues are likely to be
> fixed in the future ?

None. They're not broken, just different from what you are used to.

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

[Numpy-discussion] C API function to get the shape of an array ?

[Soeren S. <pyt...@nn...>]

Hi,

I just want to use NA_get1_Int64 etc but I couldn't find a way to
'cleanly' find out about the size of an array, i.e. I always have to
access raw fields in the PyArrayObject structure like:

PyArrayObject* a;

if (a->nd == 2)
{
  if (a->dimensions[0] == m &&
      b->dimensions[1] == n)
...


Is this the intended way ? I hope not...

Best,
Soeren

[Numpy-discussion] design issues - octave 'incompatibilities'

[Soeren S. <pyt...@nn...>]

Dear all,

I am new to numarray and as I am trying to use it day-by-day
I am now wondering about certain numeric/numarray design issues. Please
forgive me / correct me as I probably misunderstood certain issues.

-- Why did you choose row-major instead of column major format as
practiced by R/octave/matlab... Doesn't that mean performance problems
as fortran/blas is optimized if you work with the transposed version ?

-- why do vectors have no 'orientation', i.e. there are only row but no
column vectors (or why do you treat matrices/vectors differently, i.e.
have vectors at all as a separate type)

numarray:
a=array([[1,2,3],[4,5,6],[7,8,9]])
>>> a[0,:]
array([1, 2, 3])
>>> a[:,0]
array([1, 4, 7])

vs. octave:

a=[1,2,3;4,5,6;7,8,9];
>> a(1,:)
ans =
        1        2        3
>> a(:,1)
ans =
        1
        4
        7

-- How can one obtain submatrices from full matrices:

numarray gives only elements (which is very, very rarely needed and
should IMHO rather be some extra function):

>>> i=[0,1]
>>> j=[0,2]
>>> a[i,j]
array([1, 6])

vs octave:
>> i=[1,2];
>> j=[1,3];
>> a(i,j)
ans =
        1        3
        4        6

all one can do in numarray currently is as awkward as this:

>>> a.take(i,0).take(j,1)
array([[1, 3],
       [4, 6]])

also mixing slice and variable does not work a[:,i] - hmmhh seems that
is a major issue for me...

-- why don't you allow iterating over the whole matrix via a single
index ?

i.e.

a[3]
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IndexError: Index out of range

vs octave
>> a(4)
ans = 2

Are there more elegant ways to do this ? Which issues are likely to be
fixed in the future ?

Best regards,
Soeren

[Numpy-discussion] Building Numeric+numarray with atals on Fedora Core 4

[Chris B. <Chr...@no...>]

It looks like I'm managing to maintain this thread all by myself!

I thought I'd  post this final note, so that anyone searching the 
archives can see my solution. It's a bit ugly, but it seems to work.

First the summary:

I'm trying to build both Numeric and numarray on a new installation of 
Linux Fedora Core 4 on a Pentium M laptop.

Fedora helpfully provides a full lapack and blas rpms, but they don't 
appear to be at all optimized. In fact, when I used them, it was slower 
than the built-in lapack-lite.

I haven't been able to find a complete atlas+lapack distribution for 
Fedora core 4 (or anything like it), so this is what I did:

Got the atlas binaries from the atlas site:

https://sourceforge.net/projects/math-atlas/

I downloaded:
atlas3.6.0_Linux_P4SSE2.tar.gz

NOTE: these are pretty old...should I be using the 3.7.10 unstable 
version instead?

I then merged these with the Fedora lapack (should be in 
/usr/lib/liblapack.a) by following the directions in the atlas README:

"""******** GETTING A FULL LAPACK LIB **************************
ATLAS does not provide a full lapack library.  However, there is a 
simple way
to get ATLAS to provide its faster LAPACK routines to a full LAPACK library.
ATLAS's internal routines are distinct from LAPACK's, so it is safe to 
compile
ATLAS's LAPACK routines directly into a netlib-style LAPACK library.
First, obtain the LAPACK src from netlib and build the LAPACK library as
normal.  Then, in this directory (where you should have a liblapack.a),
issue the following commands:
   mkdir tmp
   cd tmp
   ar x ../liblapack.a
   cp <your LAPACK path & lib> ../liblapack.a
   ar r ../liblapack.a *.o
   cd ..
   rm -rf tmp

Just linking in ATLAS's liblapack.a first will not get you the best LAPACK
performance, mainly because LAPACK's untuned ILAENV will be used instead
of ATLAS's tuned one.
"""

I installed them in:

/usr/local/lib/atlas
and
/usr/local/include/atlas

Then I set up the numarray and Numeric build process to use them. For 
numarray, I edited cfg_packages.py, and put in:

USE_LAPACK = True

near the top, and edited on of the blocks to read:

	print "Adding paths for lapack/blas"
         lapack_dirs = ['/usr/local/lib/atlas']
         lapack_libs = ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c', 
'gfortran']
	lapack_include_dirs += ['/usr/local/include/atlas/']

NOTE: the gfortran lib is something I hadn't seen before, but I needed 
it to resolve missing symbols. I'm guess that the fedora lapack used 
gfortran.

then a setup.py build, setup.py install, and it seems to work, and is 
about twice as fast as lapack-lite on my simple test case. In the past, 
I got about a 7 times speed-up with the atlas that I got from Gentoo. 
I'm a bit disappointed, but it's OK, and I'm not really doing anything 
where it matters much.

For Numeric, I edited customize.py:

#  Using ATLAS blas in /usr/local
if 1:
     use_system_lapack = 1
     lapack_library_dirs = ['/usr/local/lib/atlas']
     lapack_libraries = ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c', 
'gfortran']

And that did it.

-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...