I think we can still retain primitive typed dense implementations underneath the generic interfaces. The API operations all accept boxed values but there is no reason the dense implementation cannot additionally support primitive versions thereof. Users would just need to cast when using them.
Jeff -----Original Message----- From: Ted Dunning [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 11:57 AM To: [email protected] Subject: Re: Matrix Design Questions If you are thinking of doing large matrix computations, it is a major loss to store these elements as objects. Get/set really, really need to work against primitive types to avoid boxing. The difference is about 5x for Double vs double. This 5x can be avoided in total memory footprint, but not in garbage production. I think that an equivalent generic rectanular container for objects is important, but it is also critically important to have a reasonably efficient matrix package. Is there a middle ground that can avoid the massive hit that boxing imposes? On 2/28/08 11:45 AM, "Karl Wettin" <[EMAIL PROTECTED]> wrote: > Jeff Eastman skrev: >> 1. While I find the notation awkward and tedious, I think making the >> Matrix interfaces use generics is the best solution for supporting a >> family of efficient implementations: from Boolean through Integer to >> Double. I note that boxed types would need to replace the primitives but >> also that the sparse implementations already use them so the main impact >> would be on the dense implementations. I'm an old Smalltalk guy, and the >> idea of everything being an object just does not bother me. > > Good. I want all values to be Objects and have the data definition model > tell me how to treat them. It makes very little sense to me to use hard > typed stuff at this level. But that is just me. > > > karl
