[Numpy-discussion] Response to PEP suggestions

[Robert Kern]

konrad.hinsen at laposte.net wrote:
> On 20.02.2005, at 00:55, Robert Kern wrote:

>> understanding your proposition correctly, it also creates another  
>> problem: rank-n arrays would then pass this check, although they  
>> shouldn't.
> 
> 
> No. My proposal is to have new Python scalar types, which are distinct  
> from the array type(s). The new scalar types would use rank-0 arrays as  
> their internal representation, but that would be an implementation  
> detail not visible to users.

*Ahh!* Enlightenment dawns. That makes a *hell* of a lot more sense than 
what I thought you were proposing. Thank you for bearing with my babbling.

I withdraw my objections.

I do have one comment, though. I still prefer the idea that arrays, 
including rank-0 arrays, be containers. So I would suggest that there 
only be a handful of new rank-0 types, int-like, float-like, 
complex-like, object, and maybe a couple more. The differences between 
the type objects would be solely for inheritance reasons. Different 
precisions would be handled like they are for rank-n arrays.

>> I expect so, too. However, when considering additions to the standard  
>> library, python-dev has to assume otherwise. If it's going to be so  
>> limited in application, then something so large shouldn't be in the  
>> standard library.
> 
> 
> I am not so sure about this. There is some very domain-specific stuff  
> in the standard library.

I think my point was that a number hierarchy is something that *ought* 
to have much wider applicability. If the implementation *doesn't*, then 
it shouldn't be in the standard library. That's why I prefer the 
arrangement I described above. It isn't a real number hierarchy and 
doesn't purport to be one. It's just an implementation detail[1] to make 
multiarrays place nicer with the rest of the Python universe.

>> I think it would be great to have a more thorough number hierarchy in  
>> the standard library. So would some others. See PEPs 228 and 242.  
>> However, I think that the issue is orthogonal getting an multiarray  
>> object into the standard library. I'm not convinced that it actually  
>> solves the problems with
> 
> 
> The common point is just the community that is interested in this.  
> However, there might be a wider interest in a re-working of the number  
> hierarchy. There have been additions to the number hierarchy that don't  
> come from the numerics community, such as the decimal number type. I  
> think that a more open number hierarchy, into which modules could add  
> their own types, could make it into the core if it doesn't cause any  
> compatibility problems. In fact, this may be easier to argue for than  
> having array methods on all scalar types.

Agreed. I think, though, that what Travis proposes in "PEP Updated" is 
going to be easiest of all to swallow.

[1] Isn't it amazing how many design problems go away by claiming that 
"it's just an implementation detail?"  :-)

-- 
Robert Kern
rkern at ucsd.edu

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