![](https://secure.gravatar.com/avatar/7dd64dbe40f809b9f8276bde56c872fd.jpg?s=120&d=mm&r=g)
Just started to play with Numeric3, looks as a significant usability improvement but.... Same functions/classes are named differently in numarray and Numeric3, for instance typecodes. I thing that agreeing on the same names for identical functions/classes would make the users life easier for either porting or alternating back ends. I believe that it may help unifying the two projects. Nadav.
![](https://secure.gravatar.com/avatar/4d021a1d1319f36ad861ebef0eb5ba44.jpg?s=120&d=mm&r=g)
Nadav Horesh wrote:
This is true for only a few cases. Mostly the names are compatible, but some of the naming conventions needed changing... For example: We have used type for the name of the data type in a numeric array. But, this can be confusing because type refers to the kind of Python object and all arrays are the same kind of python object. In addition, it is natural to use the type= keyword in array constructors, but this then blocks the use of that builtin for the function it is used with. Of course typecode was previously chosen by Numeric, but now the types are not codes (they are really type objects). Thus, I have been calling type (dtype) in the new scipy.base. The alternative is to keep the name type (eliminate the use of typecode, and rename python's type function to pytype within scipy). It could easily be changed if that is a real problem. Because of the signficantly different usage of types in the new system, it is helpful to have a different name (dtype). But, I could be persuaded to use the word type and rename Python's type to pytype. -Travis
![](https://secure.gravatar.com/avatar/7dd64dbe40f809b9f8276bde56c872fd.jpg?s=120&d=mm&r=g)
I am not picky about which name to use. It is would be the same for me if Jay Miller would add a support for dtype keyword, and switch Int32 for int32 (or vice versa). In this case you both agree that types should be classes (although Numeric3 types == type is better) and not strings. Once there is an agreement on the functions, methods and keyword (for instance should arange function have a shape keyword), the exact names choice should be an easy issue to overcome. Nadav. Travis Oliphant wrote:
![](https://secure.gravatar.com/avatar/b24e93182e89a519546baa7bafe054ed.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
These changes make sense (1) replacing type by dtype (dType?) and (2) replacing typecode by dType instances. It would be good if, as suggested by Nadav, the first change could be made to numarray.
This, I suggest, would be a step back. Is there any plan to make Win32 binary version available for testing? Past efforts to compile have failed. Colin W,
![](https://secure.gravatar.com/avatar/b24e93182e89a519546baa7bafe054ed.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
[error] - this should have read: These changes make sense (1) replacing type by dtype (dType?) and (2) replacing typecode by dType an instance of a Numeric types class. It would be good if, as suggested by Nadav, the first change could be made to numarray. He indicates that the naming of the new Numeric types classes is different from that used by numarray. Is it necessary to change this?
This, I suggest, would be a step back. Is there any plan to make Win32 binary version available for testing? Past efforts to compile have failed. Colin W, ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
![](https://secure.gravatar.com/avatar/4d021a1d1319f36ad861ebef0eb5ba44.jpg?s=120&d=mm&r=g)
Nadav Horesh wrote:
This is true for only a few cases. Mostly the names are compatible, but some of the naming conventions needed changing... For example: We have used type for the name of the data type in a numeric array. But, this can be confusing because type refers to the kind of Python object and all arrays are the same kind of python object. In addition, it is natural to use the type= keyword in array constructors, but this then blocks the use of that builtin for the function it is used with. Of course typecode was previously chosen by Numeric, but now the types are not codes (they are really type objects). Thus, I have been calling type (dtype) in the new scipy.base. The alternative is to keep the name type (eliminate the use of typecode, and rename python's type function to pytype within scipy). It could easily be changed if that is a real problem. Because of the signficantly different usage of types in the new system, it is helpful to have a different name (dtype). But, I could be persuaded to use the word type and rename Python's type to pytype. -Travis
![](https://secure.gravatar.com/avatar/7dd64dbe40f809b9f8276bde56c872fd.jpg?s=120&d=mm&r=g)
I am not picky about which name to use. It is would be the same for me if Jay Miller would add a support for dtype keyword, and switch Int32 for int32 (or vice versa). In this case you both agree that types should be classes (although Numeric3 types == type is better) and not strings. Once there is an agreement on the functions, methods and keyword (for instance should arange function have a shape keyword), the exact names choice should be an easy issue to overcome. Nadav. Travis Oliphant wrote:
![](https://secure.gravatar.com/avatar/b24e93182e89a519546baa7bafe054ed.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
These changes make sense (1) replacing type by dtype (dType?) and (2) replacing typecode by dType instances. It would be good if, as suggested by Nadav, the first change could be made to numarray.
This, I suggest, would be a step back. Is there any plan to make Win32 binary version available for testing? Past efforts to compile have failed. Colin W,
![](https://secure.gravatar.com/avatar/b24e93182e89a519546baa7bafe054ed.jpg?s=120&d=mm&r=g)
Travis Oliphant wrote:
[error] - this should have read: These changes make sense (1) replacing type by dtype (dType?) and (2) replacing typecode by dType an instance of a Numeric types class. It would be good if, as suggested by Nadav, the first change could be made to numarray. He indicates that the naming of the new Numeric types classes is different from that used by numarray. Is it necessary to change this?
This, I suggest, would be a step back. Is there any plan to make Win32 binary version available for testing? Past efforts to compile have failed. Colin W, ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
participants (3)
-
Colin J. Williams
-
Nadav Horesh
-
Travis Oliphant