cxbrooks / test

Second test for bugzilla to git
0 stars 0 forks source link

Multiport Composites should infer their width #96

Closed cxbrooks closed 15 years ago

cxbrooks commented 16 years ago

Note: the issue was created automatically with bugzilla2github tool

Original bug ID: BZ#164 From: @cxbrooks Reported version: 7.1.devel CC: bert.rodiers@gmail.com, pt-dev@chess.eecs.berkeley.edu

cxbrooks commented 16 years ago

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3300 "CompositeActor does not support multiport" Discusses a common problem that has appeared before. I added information about this to the Ptolemy II faq, see http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIfaq.htm#multiportComposites

Below is more detailed information:

From: "Christopher Brooks" <cxh@ eecs.berkeley.edu> To: "Edward A. Lee" <eal@ eecs.berkeley.edu> Sent: Friday, November 30, 2007 9:48 AM Subject: Re: [Ptolemy] 1+1 != 2 with transparent composite with multiport

Thanks!

In the perfect world, we would warn the user about dropping the second channel. What's odd is that both Consts fire and the data from the second Const disappears. This is counterintuitive.

_Christopher

This isn't a bug, it's a feature! ;-)

Seriously, what's going on here is that the "width" of the inside relation is set (by default) to 1. In our semantics, when a multiport has width 2 on the outside and width 1 on the inside, the second channel is dropped.

To get this to work, set the width of the relation on the inside to 0, which means "infer the width from the connections".

Arguably, the default width should always be 0, but we would need a proof of soundness. I.e., that the inferred width is always unique. One of my students took a stab at such a proof a few years ago, but didn't get anywhere. Probably worth revisiting...

Edward

At 08:14 AM 11/30/2007, Christopher Brooks wrote:

Jason writes:

Chris, is the way the attached works the intended implementation? I thought the display would read 2.

Hi Jason,

Yep, 1+1 is usually 2, expect for sufficiently large values of 1. :-)

The model you sent appears to illustrate a bug.

I checked in a test version as ptolemy/domains/sdf/test/auto/SDFMultiportComposite.xml

The model is an SDF model that has two Consts connected to a composite actor that has a multiport.

SDF

             |     |
Const -------> Comp.
Const----- -------

The composite is transparent (it has no internal director) Inside the composite, the multiport is connected to the plus port of an AddSubtract. The output of the AddSubtract is connected to a Display:

         ----------   -----------
-------- + Add/Sub --> Display

When I run the test, the Display gets "1". The version I checked in uses a Test actor which expects "2".

This test fails in Ptolemy II 4.0, 5.0 and 6.0.

I vaguely remember seeing a problem like this before.

Adding a SDF director to the composite does not help.

If the multiport is removed and two non-multiports are used, then the test passes.

Any comments? This seems like it should work.

_Christopher

cxbrooks commented 16 years ago

Created attachment 17 Composite within composite multiport problem.

This example, from Jason, has a composite within a composite where the input of each composite is a multiport. The problem is that setting the value of the width to 0 fails:

Error evaluating expression: 0 in .MultiportProblem.CompositeActor.relation.width Because: Cannot use unspecified width on this relation because of its links. in .MultiportProblem.CompositeActor.relation

Attached file: MultiportProblem.xml (application/xml, 7799 bytes) Description: Composite within composite multiport problem.

cxbrooks commented 15 years ago

Created attachment 20 First analysis

Attached file: Width_inference.pdf (application/pdf, 58489 bytes) Description: First analysis

cxbrooks commented 15 years ago

I attached a first analysis (Width_inference.pdf)

cxbrooks commented 15 years ago

The mentioned limitations for width inference have been solved (so now it is possible to have multiple relations for which the width needs to be inferred at the same port). Notice that the value to infer the widths have been changed from 0 to -1.