numpy-discussion

[Numpy-discussion] why numarray.inputarray?

[Tim H. <tim...@co...>]

I just noticed that the name asarray is considered obsolete and is to be 
replaced with inputarray. Why is that? The name asarray has a pretty 
clear connection with it's behaviour (return it's argument as an array), 
while I can come up with no such connection for inputarray. The best I 
can come up with is that it's often used on the inputs of functions to 
coerce them to arrays, but that seems a pretty tenuous connection. Is 
there a better reason? Am I just being obtuse?

-tim

Re: [Numpy-discussion] why numarray.inputarray?

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

On Mon, 2004-02-09 at 13:55, Tim Hochberg wrote:
> I just noticed that the name asarray is considered obsolete and is to be 
> replaced with inputarray. Why is that? 

I'm not sure what gave you that impression;  asarray() isn't obsolete.

inputarray() was implemented "independently" and then I discovered
afterward that it should have been called asarray().  At the time,  I
was hesitant to rename public functions so I just added the asarray()
alias rather than renaming inputarray().

> The name asarray has a pretty 
> clear connection with it's behaviour (return it's argument as an array), 
> while I can come up with no such connection for inputarray. The best I 
> can come up with is that it's often used on the inputs of functions to 
> coerce them to arrays, but that seems a pretty tenuous connection. Is 
> there a better reason? 

Nope.

> Am I just being obtuse?
> 
> -tim
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] why numarray.inputarray?

[Tim H. <tim...@co...>]

Todd Miller wrote:

>On Mon, 2004-02-09 at 13:55, Tim Hochberg wrote:
>  
>
>>I just noticed that the name asarray is considered obsolete and is to be 
>>replaced with inputarray. Why is that? 
>>    
>>
>
>I'm not sure what gave you that impression;  asarray() isn't obsolete.
>  
>
It was this:

*asarray*( 	seq, type=None, typecode=None)

An alias for inputarray. This is deprecated and only provided for 
compatibility with Numeric.

from http://stsdas.stsci.edu/numarray/Doc/node21.html#l2h-6. Perhaps 
these docs should be tweaked a little not to freak out sensitive people 
like me <0.5 wink>.

Regards,

-tim




>inputarray() was implemented "independently" and then I discovered
>afterward that it should have been called asarray().  At the time,  I
>was hesitant to rename public functions so I just added the asarray()
>alias rather than renaming inputarray().
>
>  
>
>>The name asarray has a pretty 
>>clear connection with it's behaviour (return it's argument as an array), 
>>while I can come up with no such connection for inputarray. The best I 
>>can come up with is that it's often used on the inputs of functions to 
>>coerce them to arrays, but that seems a pretty tenuous connection. Is 
>>there a better reason? 
>>    
>>
>
>Nope.
>
>  
>
>>Am I just being obtuse?
>>
>>-tim
>>
>>
>>
>>-------------------------------------------------------
>>The SF.Net email is sponsored by EclipseCon 2004
>>Premiere Conference on Open Tools Development and Integration
>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>http://www.eclipsecon.org/osdn
>>_______________________________________________
>>Numpy-discussion mailing list
>>Num...@li...
>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>    
>>

Re: [Numpy-discussion] why numarray.inputarray?

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

Tim Hochberg wrote:

>
> I just noticed that the name asarray is considered obsolete and is to 
> be replaced with inputarray. Why is that? The name asarray has a 
> pretty clear connection with it's behaviour (return it's argument as 
> an array), while I can come up with no such connection for inputarray. 
> The best I can come up with is that it's often used on the inputs of 
> functions to coerce them to arrays, but that seems a pretty tenuous 
> connection. Is there a better reason? Am I just being obtuse?
>
> -tim

I agree that the term asarray better describes the functionality. 

One possible use would be to convert an instance of a sub-class of 
NumArray into an instance of the class NumArray.  However, it doesn't do 
that.

It would help if there were a clearer distinction between the functions 
array and inputarray.  The former would appear to cast a wider net and, 
among other things, include files.

I wonder whether there is a need for both array and input array, 
wouldn't it be best to focus on the function with the more general utility?

Colin W.

>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>

Re: [Numpy-discussion] why numarray.inputarray?

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

On Tue, 2004-02-10 at 09:31, Colin J. Williams wrote:
> Tim Hochberg wrote:
> 
> >
> > I just noticed that the name asarray is considered obsolete and is to 
> > be replaced with inputarray. Why is that? The name asarray has a 
> > pretty clear connection with it's behaviour (return it's argument as 
> > an array), while I can come up with no such connection for inputarray. 
> > The best I can come up with is that it's often used on the inputs of 
> > functions to coerce them to arrays, but that seems a pretty tenuous 
> > connection. Is there a better reason? Am I just being obtuse?
> >
> > -tim
> 
> I agree that the term asarray better describes the functionality. 
> 
> One possible use would be to convert an instance of a sub-class of 
> NumArray into an instance of the class NumArray.  However, it doesn't do 
> that.
> 
> It would help if there were a clearer distinction between the functions 
> array and inputarray.  The former would appear to cast a wider net and, 
> among other things, include files.

This is a mess, I have to agree.  The most important distinction is that
array() makes a copy of an array by default, while
inputarray()/asarray() does not.

> I wonder whether there is a need for both array and input array, 
> wouldn't it be best to focus on the function with the more general utility?
Based on your input, and Tim Hochberg's earlier comments,  I think we
should:

1. Clean up the array function by ditching the buffer/sequence keyword
deprecation code.  buffer has been deprecated long enough.

2. Redefine asarray() as calling array() with copy=1.  Tim's right. 
It's a better name than inputarray() and we want it for backward
compatibility anyway.

3. Redefine inputarray() as a non-recommended synonym for asarray(). 
I'd say deprecate it,  but that's a PITA for anyone already using it.

4. Change the manual to document asarray() as primary and document
inputarray() as a non-recommended synonym.

Comments?

Todd

> 
> Colin W.
> 
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Numpy-discussion mailing list
> > Num...@li...
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] why numarray.inputarray?

[Tim H. <tim...@co...>]

Todd Miller wrote:

[SNIP]

>Based on your [Colin Williams] input, and Tim Hochberg's earlier comments,  I think we
>should:
>
>1. Clean up the array function by ditching the buffer/sequence keyword
>deprecation code.  buffer has been deprecated long enough.
>
>2. Redefine asarray() as calling array() with copy=1.  Tim's right. 
>It's a better name than inputarray() and we want it for backward
>compatibility anyway.
>
>3. Redefine inputarray() as a non-recommended synonym for asarray(). 
>I'd say deprecate it,  but that's a PITA for anyone already using it.
>
>4. Change the manual to document asarray() as primary and document
>inputarray() as a non-recommended synonym.
>
>Comments?
>
>  
>
Sounds good to me. I've never used the buffer/sequence stuff, so I'm not 
really qualified to opine on that.

-tim

Re: [Numpy-discussion] why numarray.inputarray?

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

Todd Miller wrote:

>On Tue, 2004-02-10 at 09:31, Colin J. Williams wrote:
>  
>
>>Tim Hochberg wrote:
>>
>>    
>>
>>>I just noticed that the name asarray is considered obsolete and is to 
>>>be replaced with inputarray. Why is that? The name asarray has a 
>>>pretty clear connection with it's behaviour (return it's argument as 
>>>an array), while I can come up with no such connection for inputarray. 
>>>The best I can come up with is that it's often used on the inputs of 
>>>functions to coerce them to arrays, but that seems a pretty tenuous 
>>>connection. Is there a better reason? Am I just being obtuse?
>>>
>>>-tim
>>>      
>>>
>>I agree that the term asarray better describes the functionality. 
>>
>>One possible use would be to convert an instance of a sub-class of 
>>NumArray into an instance of the class NumArray.  However, it doesn't do 
>>that.
>>
>>It would help if there were a clearer distinction between the functions 
>>array and inputarray.  The former would appear to cast a wider net and, 
>>among other things, include files.
>>    
>>
>
>This is a mess, I have to agree.  The most important distinction is that
>array() makes a copy of an array by default, while
>inputarray()/asarray() does not.
>
>  
>
>>I wonder whether there is a need for both array and input array, 
>>wouldn't it be best to focus on the function with the more general utility?
>>    
>>
>Based on your input, and Tim Hochberg's earlier comments,  I think we
>should:
>
>1. Clean up the array function by ditching the buffer/sequence keyword
>deprecation code.  buffer has been deprecated long enough.
>
Good!  Although it means some changes in my not fully tested code.  I 
believe that sequence can also be a buffer, as long as type and shape 
are also provided.  I haven't yet tried this.

>
>2. Redefine asarray() as calling array() with copy=1.  Tim's right. 
>It's a better name than inputarray() and we want it for backward
>compatibility anyway.
>
Good!  Although it would be good to make provision for this to convert a 
sub-class instance into an instance of  NumArray,  something like:
            if instance(sequence, NumArray):
               if sequence.__class__ !=  NumArray.__class__:
                   sequence.__class__ = NumArray.__class__
                    copy= True

>
>3. Redefine inputarray() as a non-recommended synonym for asarray(). 
>I'd say deprecate it,  but that's a PITA for anyone already using it.
>  
>
It wouldn't be that much of a pain if the deprecation were in the 
documentation only and put into the code after say a year.

>4. Change the manual to document asarray() as primary and document
>inputarray() as a non-recommended synonym.
>
Yes.  Incidentally, what is the current status of the documentation?  
The last time I looked, it was for version 0.7.

Colin W.

>
>Comments?
>
>Todd
>
>  
>
>>Colin W.
>>
>>    
>>
>>>
>>>-------------------------------------------------------
>>>The SF.Net email is sponsored by EclipseCon 2004
>>>Premiere Conference on Open Tools Development and Integration
>>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>>http://www.eclipsecon.org/osdn
>>>_______________________________________________
>>>Numpy-discussion mailing list
>>>Num...@li...
>>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>The SF.Net email is sponsored by EclipseCon 2004
>>Premiere Conference on Open Tools Development and Integration
>>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>>http://www.eclipsecon.org/osdn
>>_______________________________________________
>>Numpy-discussion mailing list
>>Num...@li...
>>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>>    
>>

Re: [Numpy-discussion] why numarray.inputarray?

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

On Tue, 2004-02-10 at 16:17, Colin J. Williams wrote:
> Todd Miller wrote:
> 
> >On Tue, 2004-02-10 at 09:31, Colin J. Williams wrote:
> >  
> >
> >>Tim Hochberg wrote:
> >>
> >>    
> >>
> >>>I just noticed that the name asarray is considered obsolete and is to 
> >>>be replaced with inputarray. Why is that? The name asarray has a 
> >>>pretty clear connection with it's behaviour (return it's argument as 
> >>>an array), while I can come up with no such connection for inputarray. 
> >>>The best I can come up with is that it's often used on the inputs of 
> >>>functions to coerce them to arrays, but that seems a pretty tenuous 
> >>>connection. Is there a better reason? Am I just being obtuse?
> >>>
> >>>-tim
> >>>      
> >>>
> >>I agree that the term asarray better describes the functionality. 
> >>
> >>One possible use would be to convert an instance of a sub-class of 
> >>NumArray into an instance of the class NumArray.  However, it doesn't do 
> >>that.
> >>
> >>It would help if there were a clearer distinction between the functions 
> >>array and inputarray.  The former would appear to cast a wider net and, 
> >>among other things, include files.
> >>    
> >>
> >
> >This is a mess, I have to agree.  The most important distinction is that
> >array() makes a copy of an array by default, while
> >inputarray()/asarray() does not.
> >
> >  
> >
> >>I wonder whether there is a need for both array and input array, 
> >>wouldn't it be best to focus on the function with the more general utility?
> >>    
> >>
> >Based on your input, and Tim Hochberg's earlier comments,  I think we
> >should:
> >
> >1. Clean up the array function by ditching the buffer/sequence keyword
> >deprecation code.  buffer has been deprecated long enough.
> >
> Good!  Although it means some changes in my not fully tested code.  I 
> believe that sequence can also be a buffer, as long as type and shape 
> are also provided.  I haven't yet tried this.
> 
> >
> >2. Redefine asarray() as calling array() with copy=1.  Tim's right. 
> >It's a better name than inputarray() and we want it for backward
> >compatibility anyway.
> >
> Good!  Although it would be good to make provision for this to convert a 
> sub-class instance into an instance of  NumArray,  something like:
>             if instance(sequence, NumArray):
>                if sequence.__class__ !=  NumArray.__class__:
>                    sequence.__class__ = NumArray.__class__
>                     copy= True

I'd like to hear more opinions on this.  

> >
> >3. Redefine inputarray() as a non-recommended synonym for asarray(). 
> >I'd say deprecate it,  but that's a PITA for anyone already using it.
> >  
> >
> It wouldn't be that much of a pain if the deprecation were in the 
> documentation only and put into the code after say a year.

Consider it done and get back to me in a year.

> 
> >4. Change the manual to document asarray() as primary and document
> >inputarray() as a non-recommended synonym.
> >
> Yes.  Incidentally, what is the current status of the documentation?  
> The last time I looked, it was for version 0.7.
> 

JC Hsu did a lot of work revising the manual.  I just posted the new
version on Source Forge as part of the 0.8 file release.

Todd
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] why numarray.inputarray?

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

> Todd Miller wrote:
>
> [SNIP]
>
> >Based on your [Colin Williams] input, and Tim Hochberg's earlier
comments,  I think we
> >should:
> >
> >1. Clean up the array function by ditching the buffer/sequence keyword
> >deprecation code.  buffer has been deprecated long enough.
> >
> >2. Redefine asarray() as calling array() with copy=1.  Tim's right.
> >It's a better name than inputarray() and we want it for backward
> >compatibility anyway.
> >
> >3. Redefine inputarray() as a non-recommended synonym for asarray().
> >I'd say deprecate it,  but that's a PITA for anyone already using it.
> >
> >4. Change the manual to document asarray() as primary and document
> >inputarray() as a non-recommended synonym.
> >
> >Comments?
> >
> >
> >
> Sounds good to me. I've never used the buffer/sequence stuff, so I'm not
> really qualified to opine on that.
>
Hi,
I'm using memory mapped array and it sounds quite natural to say
'buffer=memmapSoAndSo'
Are you actually saying that 'sequence' is a synonym for that and the
preferred keyword ?

- Sebastian Haase
UCSF

Re: [Numpy-discussion] why numarray.inputarray?

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

On Tue, 2004-02-10 at 16:20, Sebastian Haase wrote:
> Hi,
> I'm using memory mapped array and it sounds quite natural to say
> 'buffer=memmapSoAndSo'
> Are you actually saying that 'sequence' is a synonym for that and the
> preferred keyword ?

Yes.  The decision was made last year to support the sequence keyword
for the numarray.array() rather than buffer.  buffer has been deprecated
for almost a year so I think it's time to clean up the code.  I
personally like buffer better as well,  but I can't stand the code
clutter any longer... it should be one or the other not both.

Regards,
Todd

> - Sebastian Haase
> UCSF
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>

Re: [Numpy-discussion] why numarray.inputarray?

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

> > 2. Redefine asarray() as calling array() with copy=1.  Tim's right.  
> > It's a better name than inputarray() and we want it for backward 
> > compatibility anyway. 
 
In that case a copy is always made, right? You only want a copy when a 
conversion is done, otherwise a reference should be returned. That is the 
current behaviour with 0.8 and so does Numeric, if I recall well. 
 
Peter 
 

Re: [Numpy-discussion] why numarray.inputarray?

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

On Tue, 2004-02-10 at 17:03, ve...@em... wrote:
> > > 2. Redefine asarray() as calling array() with copy=1.  Tim's right.  
> > > It's a better name than inputarray() and we want it for backward 
> > > compatibility anyway. 
>  
> In that case a copy is always made, right? You only want a copy when a 
> conversion is done, otherwise a reference should be returned. That is the 
> current behaviour with 0.8 and so does Numeric, if I recall well. 

I misspoke here.  It's correct in CVS.

Thanks,
Todd

>  
> Peter 
>  
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- 
Todd Miller <jm...@st...>