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

Re: [Numpy-discussion] Boolean array formatting poll

[Pearu P. <pe...@ce...>]

Considering the number of `-1`s, how about

>>> a=numarray.arange(6, type=numarray.Bool); a[::2] = 0; a
 array([F, T, F, T, F, T], type=Bool)

which is short and readable.

Pearu

[Numpy-discussion] Why stripping spaces in strings?

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

Hi,

A user of pytables recently asked me why it truncates the trailing spaces on
strings. I have to explain him that the information is there, but the
strings module of the numarray package deliberately strips off the trailing
spaces when printing:

>>> from numarray import strings
>>> a=strings.array("hello world  ")
>>> print a
['hello world']
>>> print "<%s>" % a
<['hello world']>
>>> len(a[0])
11

however:

>>> print "<%s>" % a._data
<hello world  >
>>> a._byteView()
array([[104, 101, 108, 108, 111,  32, 119, 111, 114, 108, 100,  32,  32]], 
type=UInt8)
>>> a._itemsize
13

In the beginning I thought that this was a nice feature, but when people is
using numarray.strings objects as containers (for example for Pickled
objects), that can be rather confusing, and I would prefer to see all the
trailing blanks.

But as I am not completely sure, I just would like to discuss the pro's and
con's of the current printing apprach.

Cheers,

-- 
Francesc Alted

Re: [Numpy-discussion] Boolean array formatting poll

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

+ 1, because of consistency

-- 
Francesc Alted

Re: [Numpy-discussion] Boolean array formatting poll

[Gerard V. <gve...@gr...>]

-1, because of readability

Gerard

On 09 Sep 2003 16:15:36 -0400
Todd Miller <jm...@st...> wrote:

> Now that Python has a bool type, I have received a patch for numarray's
> arrayprint module which alters the formatting of Boolean arrays from:
> 
> >>>> a=numarray.arange(6, type=numarray.Bool); a[::2] = 0; a
> array([0, 1, 0, 1, 0, 1], type=Bool)
> 
> to:
> 
> >>>> a=numarray.arange(6, type=numarray.Bool); a[::2] = 0; a
> array([False, True, False, True, False, True], type=Bool)
> 
> Which format do you prefer?   Please vote for or against changing the
> format:  +1 (for)  or -1 (against).
> 
> -- 
> Todd Miller 			jm...@st...
> STSCI / ESS / SSB
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 

Re: [Numpy-discussion] Boolean array formatting poll

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

Vote +1
Todd Miller wrote:

>Now that Python has a bool type, I have received a patch for numarray's
>arrayprint module which alters the formatting of Boolean arrays from:
>
>  
>
>>>>>a=numarray.arange(6, type=numarray.Bool); a[::2] = 0; a
>>>>>          
>>>>>
>array([0, 1, 0, 1, 0, 1], type=Bool)
>
>to:
>
>  
>
>>>>>a=numarray.arange(6, type=numarray.Bool); a[::2] = 0; a
>>>>>          
>>>>>
>array([False, True, False, True, False, True], type=Bool)
>
>Which format do you prefer?   Please vote for or against changing the
>format:  +1 (for)  or -1 (against).
>
>  
>

Re: [Numpy-discussion] Boolean array formatting poll

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

Todd Miller wrote:

> >>>> a=numarray.arange(6, type=numarray.Bool); a[::2] = 0; a
> array([False, True, False, True, False, True], type=Bool)
> 
> Which format do you prefer?   Please vote for or against changing the
> format:  +1 (for)  or -1 (against).

-1

It just makes it harder to read, particularly for a large array

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[Numpy-discussion] Boolean array formatting poll

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

Now that Python has a bool type, I have received a patch for numarray's
arrayprint module which alters the formatting of Boolean arrays from:

>>>> a=numarray.arange(6, type=numarray.Bool); a[::2] = 0; a
array([0, 1, 0, 1, 0, 1], type=Bool)

to:

>>>> a=numarray.arange(6, type=numarray.Bool); a[::2] = 0; a
array([False, True, False, True, False, True], type=Bool)

Which format do you prefer?   Please vote for or against changing the
format:  +1 (for)  or -1 (against).

-- 
Todd Miller 			jm...@st...
STSCI / ESS / SSB

Re: [Numpy-discussion] NA_ReturnOutput question

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

On Mon, 2003-09-08 at 11:34, Peter Verveer wrote:
> The documentation states that NA_ReturnOutput(numarray, shadow) should be used 
> with the value returned by NA_OptionalOutputArray() for the shadow parameter. 

The purpose of NA_OptionalOutputArray() and NA_ReturnOutput() is to
support an optional output parameter and return value with a couple
specific behaviors:

1. If no output array is specified to the function (it is left defaulted
to None), then the function makes up an output array by cloning it
(shape and type) from some 'master' array.  The output array is returned
as the result of the function.

2. If an output array is specified, then it may still need to be
"shadowed" to correctly match the type, byteswap, and alignment
requirements specified for the function.  When a shadow output is
created,  it is used in all of the real calculations and then copied
back onto the original array and deallocated at function exit.  The
function returns None.

> Is it also possible to use a shadow array allocated otherwise, e.g. by 
> NA_NewArray()?

I don't think so.  It is however possible to return an array allocated
by NA_NewArray() as-is.  

> 
> Cheers, Peter
> 
> -- 
> Dr. Peter J. Verveer
> Cell Biology and Cell Biophysics Programme
> EMBL
> Meyerhofstrasse 1
> D-69117 Heidelberg
> Germany
> Tel. : +49 6221 387245
> Fax  : +49 6221 387242
> Email: Pet...@em...
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			jm...@st...
STSCI / ESS / SSB

[Numpy-discussion] NA_ReturnOutput question

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

The documentation states that NA_ReturnOutput(numarray, shadow) should be used 
with the value returned by NA_OptionalOutputArray() for the shadow parameter. 
Is it also possible to use a shadow array allocated otherwise, e.g. by 
NA_NewArray()?

Cheers, Peter

-- 
Dr. Peter J. Verveer
Cell Biology and Cell Biophysics Programme
EMBL
Meyerhofstrasse 1
D-69117 Heidelberg
Germany
Tel. : +49 6221 387245
Fax  : +49 6221 387242
Email: Pet...@em...

Re: [Numpy-discussion] Attempting to sub-class NumArray

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

Todd Miller wrote:

>On Sat, 2003-09-06 at 11:25, Colin J. Williams wrote:
>  
>
>>Todd Miller wrote:
>>
>>    
>>
>>>I think the problem you are having is caused by the assumption that
>>>instance initialization is equivalent to an unordered assignment of all
>>>instance attributes.  That's not true because the private attributes are
>>>interrelated;  assigning "shape" affects "_shape" and "_strides",
>>>_itemsize must be known before _strides can be computed from shape, and
>>>so on. 
>>>
>>>      
>>>
>>It would be helpful if you could let us know what assignment ordering 
>>would be appropriate, or, if there were information about the 
>>interactions, perhaps we could work these things out for ourselves.
>>    
>>
>
>In truth,  I don't think the order is the issue, so let's drop that. 
>All I can say is that somehow special.__init__() is creating
>inconsistent _shape and _strides.  I also noticed it creating and
>assigning bound methods, which you probably don't want to do.
>
Yes, I had spotted that and limited the updating to the variables.  This 
seemed to work, but your suggestion below is the neater way to go.

>>As we've discussed before, there is little information available on 
>>private objects and their roles.  Even to have the source code of some 
>>of the C code might be useful.  I wasn't able to spot the relevant C 
>>code among the CVS directories.
>>    
>>
>
>The source code is all there.
>
>Look in Include/numarray/numarray.h, Src/_ndarraymodule.c, and
>Src/_numarraymodule.c, and maybe Src/libnumarraymodule.c.
>
Thanks, I'll poke around there.

>
>  
>
>>However, the assumption would appear to apply to the crude 
>>initialization of 'special'.  The problem which is being reported seems 
>>to be connected with the function setshape in generic.py.  This is far 
>>from the unordered assignment, although I recognize that ther might be 
>>some connection.
>>    
>>
>
>I'm not sure where and how, but I think the problem is in your dir()
>loop.   So, instead, try this:
>
>self.__setstate__(arr.__getstate__())
>
This seems to be a better approach than mine.

>
>That ensures that you're only copying the data attributes and appears to
>work.
>
Thanks, over that hurdle and on to the next

Colin W.

>
>Todd
>
>  
>
>>Colin W.
>>
>>    
>>
>>>On Fri, 2003-09-05 at 20:32, Colin J. Williams wrote:
>>> 
>>>
>>>      
>>>
>>>>Todd,
>>>>
>>>>Thanks again for your prompt response.
>>>>Todd Miller wrote:
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hi Colin,
>>>>>
>>>>>I haven't looked at this in detail,  but special.__init__() is making me
>>>>>queasy.  
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>We don't call __init__ directly, but only when we construct the
>>>>instance, a,  of the class special.
>>>>   
>>>>
>>>>        
>>>>
>>>>>Why doesn't it call NumArray.__init__()?
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Because we have data to install in the newly created a.  We go off to
>>>>the factory function, numarray.array, to create the array, which we
>>>>then specialize.
>>>>
>>>>I don't see how NumArray.__init__ would help.  This cumbersome
>>>>procedure seems to work OK in most respects, but fails to display
>>>>properly.
>>>>
>>>>I don't follow the code sufficiently well to be sure, but my hunch is
>>>>that the problem lies with setShape.  It fails to update _strides.
>>>>
>>>>Colin W.
>>>>   
>>>>
>>>>        
>>>>
>>>>>Todd
>>>>>
>>>>>On Fri, 2003-09-05 at 15:03, Colin J. Williams wrote:
>>>>> 
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>When ravel() is used on an instance of NumArray, the _strides attribute 
>>>>>>is recalculated correctly.
>>>>>>When ravel() is used on an instance of special, a sub-class of NumArray, 
>>>>>>the _strides attribute keeps its old value.  This appears to cause the 
>>>>>>display problem which is reported.
>>>>>>
>>>>>>The essentials of the code used are below.
>>>>>>
>>>>>>To investigate this problem, two print statements were added to the 
>>>>>>method setshape in generic.py:
>>>>>>
>>>>>>           if newnelements == nelements:
>>>>>>               self._shape = tuple(shape)
>>>>>>               print 'In setShape self._shape:', self._shape
>>>>>>               self._strides = self._stridesFromShape()
>>>>>>               print 'In setShape self._strides:', self._strides
>>>>>>           else:
>>>>>>               raise ValueError("New shape is not consistent with the
>>>>>>   old shape")
>>>>>>
>>>>>>It seems that only the first of these print statements is executed with 
>>>>>>special, but both are executed with NumArray.  In the second case, the 
>>>>>>output is not in the expected sequence.
>>>>>>
>>>>>>I would appreciate any suggestion as to a workaround.
>>>>>>
>>>>>>Colin W,
>>>>>>
>>>>>>Grief when attempting to sub-class NumArray
>>>>>>
>>>>>>Code used:
>>>>>>
>>>>>># Try to sub-class
>>>>>>class special(N.NumArray):
>>>>>> def __init__(self, data= None, shape= None, eType= None):
>>>>>>##                         eType= _nt.Any or AnyType not acceptable %%
>>>>>>   arr= N.array(sequence= data, shape= shape, type= eType)
>>>>>>   for attr in dir(arr):
>>>>>>##      This is a longwinded way of setting up special
>>>>>>##      There must be a better way                     %%
>>>>>>##      Perhaps we should use generic._view
>>>>>>##      It's not documented                 TRY IT LATER
>>>>>>##      There is no need to transfer methods!
>>>>>>     if attr[0] == '_' and attr[1] != '_':
>>>>>>       print attr
>>>>>>       exec 'self.' + attr + '= ' 'arr.' + attr
>>>>>>       exec 'print self.' + attr
>>>>>>   pass
>>>>>>
>>>>>>a= special(data= [1, 2, 3, 4], shape= (2, 2))
>>>>>>a= N.array([1, 2, 3, 4], shape= (2, 2))
>>>>>>print 'In ts a._strides:', a._strides
>>>>>>b= _gen.ravel(a)
>>>>>>print 'In ts b._strides:', b._strides       #  <<< Unchanged with 
>>>>>>special, OK with NumArray
>>>>>>print 'b:', b
>>>>>>
>>>>>>
>>>>>>
>>>>>>USING THE SUBCLASS special
>>>>>>            
>>>>>>
>>>>>>>C:\Progra~1\Python23\pythonw -u ts.py
>>>>>>>              
>>>>>>>
>>>>>>In ts a._strides: (8, 4)
>>>>>>In setShape self._shape: (4,)
>>>>>>In ts b._strides: (8, 4)
>>>>>>b: In setShape self._shape: (4,)
>>>>>>Traceback (most recent call last):
>>>>>> File "ts.py", line 37, in ?
>>>>>>   print 'b:', b
>>>>>> File 
>>>>>>"C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 
>>>>>>618, in __str__
>>>>>>   MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ' ', "")
>>>>>> File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
>>>>>>line 176, in array2string
>>>>>>   separator, prefix)
>>>>>> File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
>>>>>>line 138, in _array2string
>>>>>>   max_str_len = max(len(str(max_reduce(data))),
>>>>>>libnumarray.error: maximum_Int32_reduce: access beyond buffer. offset=27 
>>>>>>buffersize=16
>>>>>>            
>>>>>>
>>>>>>>Exit code: 1
>>>>>>>              
>>>>>>>
>>>>>>__________________________________________________________
>>>>>>
>>>>>># USING NumArray
>>>>>>
>>>>>>In setShape self._shape: (2, 2)
>>>>>>In ts a._strides: (8, 4)
>>>>>>In setShape self._shape: (4,)
>>>>>>In ts b._strides: (4,)
>>>>>>b: In setShape self._shape: (4,)
>>>>>>[1 2 3 4]
>>>>>>            
>>>>>>
>>>>>>>Exit code: 0
>>>>>>>              
>>>>>>>
>>>>>>
>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>This sf.net email is sponsored by:ThinkGeek
>>>>>>Welcome to geek heaven.
>>>>>>http://thinkgeek.com/sf
>>>>>>_______________________________________________
>>>>>>Numpy-discussion mailing list
>>>>>>Num...@li...
>>>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>>>>>   
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>

Re: [Numpy-discussion] Attempting to sub-class NumArray

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

On Sat, 2003-09-06 at 11:25, Colin J. Williams wrote:
> Todd Miller wrote:
> 
> >I think the problem you are having is caused by the assumption that
> >instance initialization is equivalent to an unordered assignment of all
> >instance attributes.  That's not true because the private attributes are
> >interrelated;  assigning "shape" affects "_shape" and "_strides",
> >_itemsize must be known before _strides can be computed from shape, and
> >so on. 
> >
> It would be helpful if you could let us know what assignment ordering 
> would be appropriate, or, if there were information about the 
> interactions, perhaps we could work these things out for ourselves.

In truth,  I don't think the order is the issue, so let's drop that. 
All I can say is that somehow special.__init__() is creating
inconsistent _shape and _strides.  I also noticed it creating and
assigning bound methods, which you probably don't want to do.

> As we've discussed before, there is little information available on 
> private objects and their roles.  Even to have the source code of some 
> of the C code might be useful.  I wasn't able to spot the relevant C 
> code among the CVS directories.

The source code is all there.

Look in Include/numarray/numarray.h, Src/_ndarraymodule.c, and
Src/_numarraymodule.c, and maybe Src/libnumarraymodule.c.

> However, the assumption would appear to apply to the crude 
> initialization of 'special'.  The problem which is being reported seems 
> to be connected with the function setshape in generic.py.  This is far 
> from the unordered assignment, although I recognize that ther might be 
> some connection.

I'm not sure where and how, but I think the problem is in your dir()
loop.   So, instead, try this:

self.__setstate__(arr.__getstate__())

That ensures that you're only copying the data attributes and appears to
work.

Todd

> Colin W.
> 
> >
> >On Fri, 2003-09-05 at 20:32, Colin J. Williams wrote:
> >  
> >
> >>Todd,
> >>
> >>Thanks again for your prompt response.
> >>Todd Miller wrote:
> >>    
> >>
> >>>Hi Colin,
> >>>
> >>>I haven't looked at this in detail,  but special.__init__() is making me
> >>>queasy.  
> >>>      
> >>>
> >>We don't call __init__ directly, but only when we construct the
> >>instance, a,  of the class special.
> >>    
> >>
> >>>Why doesn't it call NumArray.__init__()?
> >>>      
> >>>
> >>Because we have data to install in the newly created a.  We go off to
> >>the factory function, numarray.array, to create the array, which we
> >>then specialize.
> >>
> >>I don't see how NumArray.__init__ would help.  This cumbersome
> >>procedure seems to work OK in most respects, but fails to display
> >>properly.
> >>
> >>I don't follow the code sufficiently well to be sure, but my hunch is
> >>that the problem lies with setShape.  It fails to update _strides.
> >>
> >>Colin W.
> >>    
> >>
> >>>Todd
> >>>
> >>>On Fri, 2003-09-05 at 15:03, Colin J. Williams wrote:
> >>>  
> >>>      
> >>>
> >>>>When ravel() is used on an instance of NumArray, the _strides attribute 
> >>>>is recalculated correctly.
> >>>>When ravel() is used on an instance of special, a sub-class of NumArray, 
> >>>>the _strides attribute keeps its old value.  This appears to cause the 
> >>>>display problem which is reported.
> >>>>
> >>>>The essentials of the code used are below.
> >>>>
> >>>>To investigate this problem, two print statements were added to the 
> >>>>method setshape in generic.py:
> >>>>
> >>>>            if newnelements == nelements:
> >>>>                self._shape = tuple(shape)
> >>>>                print 'In setShape self._shape:', self._shape
> >>>>                self._strides = self._stridesFromShape()
> >>>>                print 'In setShape self._strides:', self._strides
> >>>>            else:
> >>>>                raise ValueError("New shape is not consistent with the
> >>>>    old shape")
> >>>>
> >>>>It seems that only the first of these print statements is executed with 
> >>>>special, but both are executed with NumArray.  In the second case, the 
> >>>>output is not in the expected sequence.
> >>>>
> >>>>I would appreciate any suggestion as to a workaround.
> >>>>
> >>>>Colin W,
> >>>>
> >>>>Grief when attempting to sub-class NumArray
> >>>>
> >>>>Code used:
> >>>>
> >>>># Try to sub-class
> >>>>class special(N.NumArray):
> >>>>  def __init__(self, data= None, shape= None, eType= None):
> >>>>##                         eType= _nt.Any or AnyType not acceptable %%
> >>>>    arr= N.array(sequence= data, shape= shape, type= eType)
> >>>>    for attr in dir(arr):
> >>>>##      This is a longwinded way of setting up special
> >>>>##      There must be a better way                     %%
> >>>>##      Perhaps we should use generic._view
> >>>>##      It's not documented                 TRY IT LATER
> >>>>##      There is no need to transfer methods!
> >>>>      if attr[0] == '_' and attr[1] != '_':
> >>>>        print attr
> >>>>        exec 'self.' + attr + '= ' 'arr.' + attr
> >>>>        exec 'print self.' + attr
> >>>>    pass
> >>>>
> >>>>a= special(data= [1, 2, 3, 4], shape= (2, 2))
> >>>>a= N.array([1, 2, 3, 4], shape= (2, 2))
> >>>>print 'In ts a._strides:', a._strides
> >>>>b= _gen.ravel(a)
> >>>>print 'In ts b._strides:', b._strides       #  <<< Unchanged with 
> >>>>special, OK with NumArray
> >>>>print 'b:', b
> >>>>
> >>>>
> >>>>
> >>>>USING THE SUBCLASS special
> >>>> >C:\Progra~1\Python23\pythonw -u ts.py
> >>>>In ts a._strides: (8, 4)
> >>>>In setShape self._shape: (4,)
> >>>>In ts b._strides: (8, 4)
> >>>>b: In setShape self._shape: (4,)
> >>>>Traceback (most recent call last):
> >>>>  File "ts.py", line 37, in ?
> >>>>    print 'b:', b
> >>>>  File 
> >>>>"C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 
> >>>>618, in __str__
> >>>>    MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ' ', "")
> >>>>  File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
> >>>>line 176, in array2string
> >>>>    separator, prefix)
> >>>>  File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
> >>>>line 138, in _array2string
> >>>>    max_str_len = max(len(str(max_reduce(data))),
> >>>>libnumarray.error: maximum_Int32_reduce: access beyond buffer. offset=27 
> >>>>buffersize=16
> >>>> >Exit code: 1
> >>>>__________________________________________________________
> >>>>
> >>>># USING NumArray
> >>>>
> >>>>In setShape self._shape: (2, 2)
> >>>>In ts a._strides: (8, 4)
> >>>>In setShape self._shape: (4,)
> >>>>In ts b._strides: (4,)
> >>>>b: In setShape self._shape: (4,)
> >>>>[1 2 3 4]
> >>>> >Exit code: 0
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>-------------------------------------------------------
> >>>>This sf.net email is sponsored by:ThinkGeek
> >>>>Welcome to geek heaven.
> >>>>http://thinkgeek.com/sf
> >>>>_______________________________________________
> >>>>Numpy-discussion mailing list
> >>>>Num...@li...
> >>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >>>>    
> >>>>        
> >>>>
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] Matrix square root

[Andrew N. <aln...@st...>]

Bernard Frankpitt <fra...@er...> writes:

[snip... finding matrix square root through eigenvalue decomposition.]

> The only problem with this approach is that you have to find all the
> eigenvalues and eigenvectors to get the spectral decomposition.  For
> large, poorly conditioned matrices this can be a source of significant
> errors, and a lot of work. An alternative, and often faster and more
> accurate approach is to use a series expansion for the square
> root. Evaluating the series expansion only requires multiplication.

This technique sounds like it's definitely worth checking out.

Thankyou for the tip.

Andrew.

Re: [Numpy-discussion] Attempting to sub-class NumArray

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

Todd Miller wrote:

>I think the problem you are having is caused by the assumption that
>instance initialization is equivalent to an unordered assignment of all
>instance attributes.  That's not true because the private attributes are
>interrelated;  assigning "shape" affects "_shape" and "_strides",
>_itemsize must be known before _strides can be computed from shape, and
>so on. 
>
It would be helpful if you could let us know what assignment ordering 
would be appropriate, or, if there were information about the 
interactions, perhaps we could work these things out for ourselves.

As we've discussed before, there is little information available on 
private objects and their roles.  Even to have the source code of some 
of the C code might be useful.  I wasn't able to spot the relevant C 
code among the CVS directories.

However, the assumption would appear to apply to the crude 
initialization of 'special'.  The problem which is being reported seems 
to be connected with the function setshape in generic.py.  This is far 
from the unordered assignment, although I recognize that ther might be 
some connection.

Colin W.

>
>On Fri, 2003-09-05 at 20:32, Colin J. Williams wrote:
>  
>
>>Todd,
>>
>>Thanks again for your prompt response.
>>Todd Miller wrote:
>>    
>>
>>>Hi Colin,
>>>
>>>I haven't looked at this in detail,  but special.__init__() is making me
>>>queasy.  
>>>      
>>>
>>We don't call __init__ directly, but only when we construct the
>>instance, a,  of the class special.
>>    
>>
>>>Why doesn't it call NumArray.__init__()?
>>>      
>>>
>>Because we have data to install in the newly created a.  We go off to
>>the factory function, numarray.array, to create the array, which we
>>then specialize.
>>
>>I don't see how NumArray.__init__ would help.  This cumbersome
>>procedure seems to work OK in most respects, but fails to display
>>properly.
>>
>>I don't follow the code sufficiently well to be sure, but my hunch is
>>that the problem lies with setShape.  It fails to update _strides.
>>
>>Colin W.
>>    
>>
>>>Todd
>>>
>>>On Fri, 2003-09-05 at 15:03, Colin J. Williams wrote:
>>>  
>>>      
>>>
>>>>When ravel() is used on an instance of NumArray, the _strides attribute 
>>>>is recalculated correctly.
>>>>When ravel() is used on an instance of special, a sub-class of NumArray, 
>>>>the _strides attribute keeps its old value.  This appears to cause the 
>>>>display problem which is reported.
>>>>
>>>>The essentials of the code used are below.
>>>>
>>>>To investigate this problem, two print statements were added to the 
>>>>method setshape in generic.py:
>>>>
>>>>            if newnelements == nelements:
>>>>                self._shape = tuple(shape)
>>>>                print 'In setShape self._shape:', self._shape
>>>>                self._strides = self._stridesFromShape()
>>>>                print 'In setShape self._strides:', self._strides
>>>>            else:
>>>>                raise ValueError("New shape is not consistent with the
>>>>    old shape")
>>>>
>>>>It seems that only the first of these print statements is executed with 
>>>>special, but both are executed with NumArray.  In the second case, the 
>>>>output is not in the expected sequence.
>>>>
>>>>I would appreciate any suggestion as to a workaround.
>>>>
>>>>Colin W,
>>>>
>>>>Grief when attempting to sub-class NumArray
>>>>
>>>>Code used:
>>>>
>>>># Try to sub-class
>>>>class special(N.NumArray):
>>>>  def __init__(self, data= None, shape= None, eType= None):
>>>>##                         eType= _nt.Any or AnyType not acceptable %%
>>>>    arr= N.array(sequence= data, shape= shape, type= eType)
>>>>    for attr in dir(arr):
>>>>##      This is a longwinded way of setting up special
>>>>##      There must be a better way                     %%
>>>>##      Perhaps we should use generic._view
>>>>##      It's not documented                 TRY IT LATER
>>>>##      There is no need to transfer methods!
>>>>      if attr[0] == '_' and attr[1] != '_':
>>>>        print attr
>>>>        exec 'self.' + attr + '= ' 'arr.' + attr
>>>>        exec 'print self.' + attr
>>>>    pass
>>>>
>>>>a= special(data= [1, 2, 3, 4], shape= (2, 2))
>>>>a= N.array([1, 2, 3, 4], shape= (2, 2))
>>>>print 'In ts a._strides:', a._strides
>>>>b= _gen.ravel(a)
>>>>print 'In ts b._strides:', b._strides       #  <<< Unchanged with 
>>>>special, OK with NumArray
>>>>print 'b:', b
>>>>
>>>>
>>>>
>>>>USING THE SUBCLASS special
>>>> >C:\Progra~1\Python23\pythonw -u ts.py
>>>>In ts a._strides: (8, 4)
>>>>In setShape self._shape: (4,)
>>>>In ts b._strides: (8, 4)
>>>>b: In setShape self._shape: (4,)
>>>>Traceback (most recent call last):
>>>>  File "ts.py", line 37, in ?
>>>>    print 'b:', b
>>>>  File 
>>>>"C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 
>>>>618, in __str__
>>>>    MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ' ', "")
>>>>  File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
>>>>line 176, in array2string
>>>>    separator, prefix)
>>>>  File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
>>>>line 138, in _array2string
>>>>    max_str_len = max(len(str(max_reduce(data))),
>>>>libnumarray.error: maximum_Int32_reduce: access beyond buffer. offset=27 
>>>>buffersize=16
>>>> >Exit code: 1
>>>>__________________________________________________________
>>>>
>>>># USING NumArray
>>>>
>>>>In setShape self._shape: (2, 2)
>>>>In ts a._strides: (8, 4)
>>>>In setShape self._shape: (4,)
>>>>In ts b._strides: (4,)
>>>>b: In setShape self._shape: (4,)
>>>>[1 2 3 4]
>>>> >Exit code: 0
>>>>
>>>>
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This sf.net email is sponsored by:ThinkGeek
>>>>Welcome to geek heaven.
>>>>http://thinkgeek.com/sf
>>>>_______________________________________________
>>>>Numpy-discussion mailing list
>>>>Num...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>>>    
>>>>        
>>>>

Re: [Numpy-discussion] Matrix square root

[Bernard F. <fra...@er...>]

Andrew Nesbit wrote:

>Konrad Hinsen <hi...@cn...> writes:
>
>>On Thursday 04 September 2003 16:42, Andrew Nesbit wrote:
>>    
>>
>>>I need a function equivalent to Matlab's sqrtm, i.e., a square root
>>>for matrices
>>>
>[snip]
>
>>I'd use an eigenvalue decomposition, then take the square root of the 
>>eigenvalues, and then apply the diagonlization matrix in reverse. If you 
>>convert to eigenvalues to complex before taking the square root, this will 
>>work for non-positive-definite matrices, yielding a complex result
>>
>
>Thankyou for the advice.  This gives me a good starting point.
>
>Andrew.
>
>  
>
The only problem with this approach is that you have to find all the 
eigenvalues and eigenvectors to get the spectral decomposition.  For 
large, poorly conditioned matrices this can be a source of significant 
errors, and a lot of work. An alternative, and often faster and more 
accurate approach is to use a series expansion for the square root. 
Evaluating the series expansion only requires multiplication.

Bernie

Re: [Numpy-discussion] Attempting to sub-class NumArray

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

Hi Colin,

I haven't looked at this in detail,  but special.__init__() is making me
queasy.  Why doesn't it call NumArray.__init__()?

Todd

On Fri, 2003-09-05 at 15:03, Colin J. Williams wrote:
> When ravel() is used on an instance of NumArray, the _strides attribute 
> is recalculated correctly.
> When ravel() is used on an instance of special, a sub-class of NumArray, 
> the _strides attribute keeps its old value.  This appears to cause the 
> display problem which is reported.
> 
> The essentials of the code used are below.
> 
> To investigate this problem, two print statements were added to the 
> method setshape in generic.py:
> 
>             if newnelements == nelements:
>                 self._shape = tuple(shape)
>                 print 'In setShape self._shape:', self._shape
>                 self._strides = self._stridesFromShape()
>                 print 'In setShape self._strides:', self._strides
>             else:
>                 raise ValueError("New shape is not consistent with the
>     old shape")
> 
> It seems that only the first of these print statements is executed with 
> special, but both are executed with NumArray.  In the second case, the 
> output is not in the expected sequence.
> 
> I would appreciate any suggestion as to a workaround.
> 
> Colin W,
> 
> Grief when attempting to sub-class NumArray
> 
> Code used:
> 
> # Try to sub-class
> class special(N.NumArray):
>   def __init__(self, data= None, shape= None, eType= None):
> ##                         eType= _nt.Any or AnyType not acceptable %%
>     arr= N.array(sequence= data, shape= shape, type= eType)
>     for attr in dir(arr):
> ##      This is a longwinded way of setting up special
> ##      There must be a better way                     %%
> ##      Perhaps we should use generic._view
> ##      It's not documented                 TRY IT LATER
> ##      There is no need to transfer methods!
>       if attr[0] == '_' and attr[1] != '_':
>         print attr
>         exec 'self.' + attr + '= ' 'arr.' + attr
>         exec 'print self.' + attr
>     pass
> 
> a= special(data= [1, 2, 3, 4], shape= (2, 2))
> a= N.array([1, 2, 3, 4], shape= (2, 2))
> print 'In ts a._strides:', a._strides
> b= _gen.ravel(a)
> print 'In ts b._strides:', b._strides       #  <<< Unchanged with 
> special, OK with NumArray
> print 'b:', b
> 
> 
> 
> USING THE SUBCLASS special
>  >C:\Progra~1\Python23\pythonw -u ts.py
> In ts a._strides: (8, 4)
> In setShape self._shape: (4,)
> In ts b._strides: (8, 4)
> b: In setShape self._shape: (4,)
> Traceback (most recent call last):
>   File "ts.py", line 37, in ?
>     print 'b:', b
>   File 
> "C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 
> 618, in __str__
>     MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ' ', "")
>   File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
> line 176, in array2string
>     separator, prefix)
>   File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
> line 138, in _array2string
>     max_str_len = max(len(str(max_reduce(data))),
> libnumarray.error: maximum_Int32_reduce: access beyond buffer. offset=27 
> buffersize=16
>  >Exit code: 1
> __________________________________________________________
> 
> # USING NumArray
> 
> In setShape self._shape: (2, 2)
> In ts a._strides: (8, 4)
> In setShape self._shape: (4,)
> In ts b._strides: (4,)
> b: In setShape self._shape: (4,)
> [1 2 3 4]
>  >Exit code: 0
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller 			jm...@st...
STSCI / ESS / SSB

[Numpy-discussion] Attempting to sub-class NumArray

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

When ravel() is used on an instance of NumArray, the _strides attribute 
is recalculated correctly.
When ravel() is used on an instance of special, a sub-class of NumArray, 
the _strides attribute keeps its old value.  This appears to cause the 
display problem which is reported.

The essentials of the code used are below.

To investigate this problem, two print statements were added to the 
method setshape in generic.py:

            if newnelements == nelements:
                self._shape = tuple(shape)
                print 'In setShape self._shape:', self._shape
                self._strides = self._stridesFromShape()
                print 'In setShape self._strides:', self._strides
            else:
                raise ValueError("New shape is not consistent with the
    old shape")

It seems that only the first of these print statements is executed with 
special, but both are executed with NumArray.  In the second case, the 
output is not in the expected sequence.

I would appreciate any suggestion as to a workaround.

Colin W,

Grief when attempting to sub-class NumArray

Code used:

# Try to sub-class
class special(N.NumArray):
  def __init__(self, data= None, shape= None, eType= None):
##                         eType= _nt.Any or AnyType not acceptable %%
    arr= N.array(sequence= data, shape= shape, type= eType)
    for attr in dir(arr):
##      This is a longwinded way of setting up special
##      There must be a better way                     %%
##      Perhaps we should use generic._view
##      It's not documented                 TRY IT LATER
##      There is no need to transfer methods!
      if attr[0] == '_' and attr[1] != '_':
        print attr
        exec 'self.' + attr + '= ' 'arr.' + attr
        exec 'print self.' + attr
    pass

a= special(data= [1, 2, 3, 4], shape= (2, 2))
a= N.array([1, 2, 3, 4], shape= (2, 2))
print 'In ts a._strides:', a._strides
b= _gen.ravel(a)
print 'In ts b._strides:', b._strides       #  <<< Unchanged with 
special, OK with NumArray
print 'b:', b



USING THE SUBCLASS special
 >C:\Progra~1\Python23\pythonw -u ts.py
In ts a._strides: (8, 4)
In setShape self._shape: (4,)
In ts b._strides: (8, 4)
b: In setShape self._shape: (4,)
Traceback (most recent call last):
  File "ts.py", line 37, in ?
    print 'b:', b
  File 
"C:\PROGRA~1\Python23\lib\site-packages\numarray\numarraycore.py", line 
618, in __str__
    MAX_LINE_WIDTH, PRECISION, SUPPRESS_SMALL, ' ', "")
  File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
line 176, in array2string
    separator, prefix)
  File "C:\PROGRA~1\Python23\lib\site-packages\numarray\arrayprint.py", 
line 138, in _array2string
    max_str_len = max(len(str(max_reduce(data))),
libnumarray.error: maximum_Int32_reduce: access beyond buffer. offset=27 
buffersize=16
 >Exit code: 1
__________________________________________________________

# USING NumArray

In setShape self._shape: (2, 2)
In ts a._strides: (8, 4)
In setShape self._shape: (4,)
In ts b._strides: (4,)
b: In setShape self._shape: (4,)
[1 2 3 4]
 >Exit code: 0

[Numpy-discussion] bug?

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

possible bug? 
 
>>> a = array([[[1, 1], [0, 1]]]) 
>>> print logical_or.reduce(a, 0) 
[[1 0] 
 [1 1]] 
 
should be: 
 
>>> print a[0, ...] 
[[1 1] 
 [0 1]] 
 
Cheers, Peter 
-- 
Dr. Peter J. Verveer 
Cell Biology and Cell Biophysics Programme 
EMBL 
Meyerhofstrasse 1 
D-69117 Heidelberg 
Germany 
Tel. : +49 6221 387245 
Fax  : +49 6221 387242 
 

Re: [Numpy-discussion] Matrix square root

[Andrew N. <aln...@st...>]

Konrad Hinsen <hi...@cn...> writes:

> On Thursday 04 September 2003 16:42, Andrew Nesbit wrote:
>> I need a function equivalent to Matlab's sqrtm, i.e., a square root
>> for matrices.

[snip]

> I'd use an eigenvalue decomposition, then take the square root of the 
> eigenvalues, and then apply the diagonlization matrix in reverse. If you 
> convert to eigenvalues to complex before taking the square root, this will 
> work for non-positive-definite matrices, yielding a complex result.

Thankyou for the advice.  This gives me a good starting point.

Andrew.

Re: [Numpy-discussion] Matrix square root

[Konrad H. <hi...@cn...>]

On Thursday 04 September 2003 16:42, Andrew Nesbit wrote:
> I need a function equivalent to Matlab's sqrtm, i.e., a square root
> for matrices.
>
> I constructed the following definition:
>
> def sqrtm(M):
>     (U,S,VT) =3D LinearAlgebra.singular_value_decomposition(M)
>     D =3D MLab.diag(sqrt(S))
>     return matrixmultiply(matrixmultiply(U,D),VT)
>
> but this technique only works for Hermitian, positive definite
> matrices.  The matrices I operate on don't necessarily satisfy that
> condition.

I'd use an eigenvalue decomposition, then take the square root of the=20
eigenvalues, and then apply the diagonlization matrix in reverse. If you=20
convert to eigenvalues to complex before taking the square root, this wil=
l=20
work for non-positive-definite matrices, yielding a complex result.

Konrad.
--=20
-------------------------------------------------------------------------=
------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------=
------

[Numpy-discussion] Matrix square root

[Andrew N. <aln...@st...>]

I need a function equivalent to Matlab's sqrtm, i.e., a square root
for matrices.

I constructed the following definition:

def sqrtm(M):
    (U,S,VT) = LinearAlgebra.singular_value_decomposition(M)
    D = MLab.diag(sqrt(S))
    return matrixmultiply(matrixmultiply(U,D),VT)

but this technique only works for Hermitian, positive definite
matrices.  The matrices I operate on don't necessarily satisfy that
condition.

Does anybody know of a more general technique, preferably with an
accompanying Python implementation?

Thanks.

Andrew.

Re: [Numpy-discussion] Re: sum and mean methods behaviour

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

On Thursday 04 September 2003 15:33, Perry Greenfield wrote:
> > So, if this is a general problem, why should only the reduce method be
> > enhanced to avoid this? If you implement this, should this
> > capability not be
> > supported more broadly than only by reduce(), for instance by universal
> > functons such as 'add'? Would it not be unexpected for users that only
> > reduce() provides such added functionality?
>
> Certainly true (and much more likely a problem for integer multiplication
> than addition). On the other hand, it is more likely to be only an
> occasional problem for binary operations. With reductions, the risk is
> severe that overflows will happen. For example, for addition it is
> the difference between a+a for the normal operation and len(a)*a for
> the reduction. Arguably reductions on Int8 and Int16 arrays are likely
> to run into a problem than not.

That true, but this argument really only holds for the integer types. For 
32-bit floating point or complex types it will usually not be necessary to 
convert to 64-bit to prevent overflow. In that case it may often not be 
desirable to change the array type. I am not saying that the convert option 
would not useful for the case of floats, but it is maybe an argument to keep 
the default behaviour, at least for Float32 and Complex32 types.

Generally I do agree that there is no need to change the ufuncs, I did not 
want to suggest that this actually be implemented...

> > However, as Paul Dubois pointed out earlier, the original design
> > philosphy of
> > Numeric/numarray was to let the user deal with such problems
> > himself and keep
> > the package small and fast. This seems actually a sound decision,
> > so would it
> > not be better to avoid complicating numarray with these type of
> > changes and
> > also leave reduce as it is?
>
> No, I'm inclined to change reductions because of the high potential
> for problems, particularly with ints. I don't think ufunc type handling
> needs to change though. Todd believes that changing reduction behavior
> would not be difficult (though we will try to finish other work first
> before doing that). Changing reduction behavior is probably the easiest way
> of implementing the improved sum and mean functions. The only thing we need
> to determine is what the default behavior is (Todd proposes
> the defaults remain the same, I'm not so sure.)

This would solve my problem with mean() and sum(). I think these should 
certainly return the result in the optimal precision. These may then not be 
the most optimal in terms of speed, but certainly 'good enough'. I would  
like to second Todds preference to keep the default behaviour of reductions 
to be the same as it is now. For reductions, I mostly want the result to be 
in the same type, because I chose that type in the first place for storage 
reasons.

Cheers, Peter

RE: [Numpy-discussion] Re: sum and mean methods behaviour

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

Peter Verveer writes

> Hi all,
>
> I was thinking a bit more about the changes to reduce() that Todd
> proposed,
> and have some questions:
>
> The problem that the output may not be able to hold the result of
> an operation
> is not unique to the reduce() method. For instance adding two
> arrays of type
> UInt can also give you the wrong answer:
>
> >>> array(255, UInt8) + array(255, UInt8)
> 254
>
> So, if this is a general problem, why should only the reduce method be
> enhanced to avoid this? If you implement this, should this
> capability not be
> supported more broadly than only by reduce(), for instance by universal
> functons such as 'add'? Would it not be unexpected for users that only
> reduce() provides such added functionality?
>
Certainly true (and much more likely a problem for integer multiplication
than addition). On the other hand, it is more likely to be only an
occasional problem for binary operations. With reductions, the risk is
severe that overflows will happen. For example, for addition it is
the difference between a+a for the normal operation and len(a)*a for
the reduction. Arguably reductions on Int8 and Int16 arrays are likely
to run into a problem than not.

> However, as Paul Dubois pointed out earlier, the original design
> philosphy of
> Numeric/numarray was to let the user deal with such problems
> himself and keep
> the package small and fast. This seems actually a sound decision,
> so would it
> not be better to avoid complicating numarray with these type of
> changes and
> also leave reduce as it is?
>
No, I'm inclined to change reductions because of the high potential
for problems, particularly with ints. I don't think ufunc type handling
needs to change though. Todd believes that changing reduction behavior
would not be difficult (though we will try to finish other work first before
doing that). Changing reduction behavior is probably the easiest way
of implementing the improved sum and mean functions. The only thing we
need to determine is what the default behavior is (Todd proposes
the defaults remain the same, I'm not so sure.)

> Personally I don't have a need for the proposed changes to the reduce
> function. My original complaint that started the whole discussion
> was that
> the mean() and sum() array methods did not give the correct
> result in some
> cases. I still think they should return a correct double precision value,
> even if the universal functions may not. That could be achieved
> by a separate
> implementation that does not use the universal functions. I would
> be prepared
> to provide that implementation either to replace the mean and sum
> methods, or
> as a separate add-on.
>
>

Re: [Numpy-discussion] Extracting column vectors from matrix.

[Andrew N. <aln...@st...>]

Konrad Hinsen <hi...@cn...> writes:

> 1) A[:, col:col+1]
>
> or perhaps
>
> 2) A[:, col][:, NewAxis]

Yep, those are the sort of tricks I was looking for.  Thankyou.

Andrew.

[Numpy-discussion] Re: sum and mean methods behaviour

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

Peter Verveer writes:
> Todd Miller writes:
> > 1. Add a type parameter to sum which defaults to widest type.
> >
> > 2. Add a type parameter to reductions (and fix output type handling).
> > Default is same-type as it is now.  No major changes to C-code.
> >
> > 3. Add a WidestType(array) function:
> >
> >         Bool                        --> Bool
> >         Int8,Int16,Int32,Int64      --> Int64
> >         UInt8, UInt16,UInt32,UInt64 --> UInt64 (Int64 on win32)
> >         Float32, Float64            --> Float64
> >         Complex32, Complex64        --> Complex64
>
> This sounds like a good solution.
>
> > The only thing this really leaves out, is a higher performance
> > implementation of sum/mean which Peter referred to a few times.
>
> Is this really the case? It depends on how you plan to implement
> the output
> conversion. If you will do this by allocating a temporary
> converted copy of
> the complete input before the calculations then this potentially
> requires a
> lot of temporary storage. But it is certainly possible to come up with an
> implementation that avoids this. Have you given this some thought?
>
The way numarray ufuncs currently work is that for larger arrays,
the conversion of types is only done in blocks. No temporary copy is
made of the whole input array. So the temporary storage issue is not
a problem.

Re: [Numpy-discussion] Extracting column vectors from matrix.

[Konrad H. <hi...@cn...>]

On Thursday 04 September 2003 11:58, Andrew Nesbit wrote:
> Say that I have a rank-2 array (matrix) of shape (m,n).  Call it A.
>
> When extracting column vectors from A, I often want to keep the result
> as a rank-2 column vector (for subsequent matrix multiplications,
> etc), so I usually end up writing something ugly like this:
>
> column_vector =3D reshape(A[:,col],(m,1))
>
> I've got a function to wrap this, but is there a builtin (or cleaner)
> way to do this sort of operation?

1) A[:, col:col+1]

or perhaps

2) A[:, col][:, NewAxis]

Konrad.
--=20
-------------------------------------------------------------------------=
------
Konrad Hinsen                            | E-Mail: hi...@cn...
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------=
------