this isn’t all documented, but I think it’s time to start coding.
Coding, yes, by all/any means a good thing to do by now.
All I’m asking for is a single “For Example” sentence, to justify to
the reader how an m-block can have 0 external ports. Every time I’ve
read it, I stop and think and wonder; I’m sure I’m not alone.
Are there any advantages to setting up this way versus using a
single m-block per signal- processing concept (source, processing,
sink)? IMHO it would be helpful to have a quick example in the
text, just to be (more) complete. - MLD
I’m not going to spend the time arguing the point. However, it
would be short sighted to preclude something that could be useful and
has zero cost to implement.
There is no argument. I don’t disagree that zero cost options should
be implemented. Maybe it’s too deep of a practical implementation
issue for now - but wondering if there will be costs to keeping
everything internal versus making everything separate external blocks
… or, maybe, if it’s just a semantics, to say something to that
effect, or emphasize what’s already been said regarding the nature of
the m-scheduler and the “m-graph” virtual make-up.
The real documentation for this stuff will be written after it’s coded
Yes, true … frequently the best documentation is that which is
written in hind-sight, not fore-sight. - MLD
On 6/15/06 7:06 PM, “Eric B.” [email protected] wrote:
On Thu, Jun 15, 2006 at 02:37:54PM -0500, Michael D. wrote:
On Thursday, June 15, 2006, at 11:46 AM, Eric B. wrote:
On Thu, Jun 15, 2006 at 08:37:48AM -0400, Michael D. wrote:
My theory on this document is less is more. This is addressed more to
David than to you. The semi-formal spec for the portref lists a min
and max replication count. One could infer that a min of 0 and a
max of 1 would indicate that a port was “optionally connected”.
I agree. This has been a really great discussion and has really helped
to
improve clarity and smooth some wrinkles in the document, but we should
probably bring this phase to a close and start implementing.
How about if I get this last set of comments into the document and then
declare that the final version? I will try to stick to the “less is
more”
philosophy as I am editing.
Thanks!
Dave.
Back after a weekend trip w/o internet access …
On Jun 16, 2006, at 12:28 AM, David Lapsley wrote:
I agree. This has been a really great discussion and has really
helped to
improve clarity and smooth some wrinkles in the document, but we
should
probably bring this phase to a close and start implementing. How
about if
I get this last set of comments into the document and then
declare that the final version?
Sounds good to me. Please check for typos too; there were a few.
I will try to stick to the “less is more”
philosophy as I am editing.
Brevity is a virtue. Too much brevity leads to confusion and
“interpretation loss” … sort of like channel capacity (via Shannon:
one can achieve maximum channel throughput [maximum brevity] with an
arbitrarily low data error rate, but any more brevity and there will
be errors [data loss]). - MLD
On 6/19/06 8:49 AM, “Michael D.” [email protected] wrote:
declare that the final version?
Sounds good to me. Please check for typos too; there were a few.
Great! Will do. I’m still working on it, but will have the “final”
version
out this week.
I will try to stick to the “less is more”
philosophy as I am editing.
Brevity is a virtue. Too much brevity leads to confusion and
“interpretation loss” … sort of like channel capacity (via Shannon:
one can achieve maximum channel throughput [maximum brevity] with an
arbitrarily low data error rate, but any more brevity and there will
be errors [data loss]). - MLD
I like the idea of applying Shannon’s theorem to document editing. Very
nice 
Cheers,
Dave.