[ibis-interconn] FW: Sparse/Duplicate Entries

From: "Walter Katz" <wkatz@xxxxxxxxxx>
To: "IBIS-Interconnect" <ibis-interconn@xxxxxxxxxxxxx>
Date: Wed, 15 Jul 2009 14:32:27 -0400
All,

 

I agree with Brad, that model developer assigned labels to transfer
functions is preferable. I will accept general agreement of assigning matrix
elements as a list associated with a labeled transfer function.

 

Walter

 

-----Original Message-----
From: Brad Brim [mailto:bradb@xxxxxxxxxxx] 
Sent: Wednesday, July 15, 2009 2:22 PM
To: 'Mirmak, Michael'
Cc: 'Walter Katz'; 'Dmitriev-Zdorov, Vladimir'; radek_biernacki@xxxxxxxxxxx;
'Bob Ross'
Subject: RE: [ibis-interconn] Sparse/Duplicate Entries

 

seems as if my e-mail address is screened by freelists.org so I will send
directly to those I recall attending today's meeting

 

 

hello all,

 

Vladimir proposed

  [keyword]

    <ID_1> : (a,b) (c,d) (e,f) (g,h)

    <ID_2> : (i,j) (k,l)

 

Radek proposed

  [keyword]

    (a,b) (i,j)

  [keyword]

    (a,b) : (c,d) (e,f)

  [keyword]

    (i,j) : (k,l)

  [keyword]

    (a,b) : (g,h)

 

We could have a hybrid of these two, where we remove the IDs from Vladimir's
proposal and add the ':' character from Radek's proposal

  [keyword]

    (a,b) : (c,d) (e,f) (g,h)

    (i,j) : (k,l)

 

Or alternately, if we simply simply allow blank IDs in Vladimir's proposal

  [keyword]

    : (a,b) (c,d) (e,f) (g,h) : (i,j) (k,l)

 

Radek's proposal does not separate sparsity and redundancy. If it did, it
would read more like

  [keyword]

    (a,b) (c,d) (e,f) (g,h) (i,j) (k,l)

  [keyword]

    (a,b) : (c,d) (e,f) (g,h)

    (i,j) : (k,l)

 

Comments and Observations:

  (1)  I would very much prefer if all redundancy mappings for a unique
transfer function are required to be in one location, though they could be
in any order. One may perceive Radek's proposal as more free-form for the
model developer but with generality comes complexity. It will be a bit more
difficult to parse but much more difficult for human readability.

  (2)  If the <IDs> are not just integers, but can be any arbitrary text
(except for certain characters, especially ':' in the above examples), then
the desire would be met to have a label. I value human readability less than
most, but I still prefer Vladimir's proposal above all others. If you want
an ID-free list, then use Vladimir's proposal as I showed above with ':'
separators.

  (3) I prefer we we do not separate sparsity and redundancy, because
listing the entire sparse matrix structure seems wasteful of space and
potentially more effort an on-the-fly model developer.

  (4)  If we assume the the vast majority of applications will be sparsity
with NO redundancy, then Radek's proposal is ever-so-slightly more efficient
because even the blank IDs (i.e. the ':' separators) are not required.
However, this separator is a small price to pay for having labels available.

 

best regards,

 -Brad

 

Brad Brim

bradb@xxxxxxxxxxx

 


  _____  


From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, July 15, 2009 9:07 AM
To: IBIS-Interconnect
Subject: [ibis-interconn] Sparse/Duplicate Entries
Importance: High

Bard,

 

To answer you last question. All of the connector and package models that we
deal with are both very sparse, and have many common "Things". 

 

Walter

 

Walter Katz

Chief Scientist

Signal Integrity Software, Inc.

wkatz@xxxxxxxxxx

303.449-2308
[ibis-interconn] FW: Sparse/Duplicate Entries

Other related posts:
