[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Latest Draft of ISO/IEC 15909 for comment





On Sat, 18 Nov 2000, Jonathan wrote:

> As yet, I have not had comment on the draft from
> Tad Murata (USA), Jean Berube (Canada), Nisse Huisberg (Finland) or any 
> one from France or Italy.

Sorry, I've been terribly busy. We do not have any serious comments, but a
few small details I could mention (many from Kimmo Varpaaniemi):

1.

I'm personally not very happy with the definition of the multisets. It is
the usual one, yes, but it is not very good. Already in 1987 G.P. Monro
(Zeitschrift f. math. Logik und Grundlagen d. Math. 33) pointed out the
problem, i.e. B: A -> N and C: D -> N are different even if they have the
same elements because D may have an element not in A and this element is
mapped to zero. If the multiset is {a,a,b} then C: {a,b} -> N: a mapsto 2
and b mapsto 1 is different from D: {a,b,c} -> N: a mapsto 2, b mapsto 1
and c mapsto 0.

The solution (acording to Monro) is to see a multiset as a partition of a
"normal" set or as a surjective mapping M: I -> S where I is an index set. 

We really see a multiset as an equivalence class where all non-zero
mappings are the same. I have a discussion about these problems in my
thesis.

2.

Together with Kimmo we wondered why the multiset must have a *non-empty*
basis set. Any special reason ? Also the place set must be non-empty. A
net with a non-empty place set is not very useful, but are there any
mathematical problems ?

3. 

Is there a definition of "capacity" ?

4. 

It seems that you have chosen the pair: "net" <-> "net graph" instead of
"(net) system" <-> "net" for a net with resp. without initial marking.
Well, no problems.

5.

Kimmo who has been working with unfoldings wondered if it is a good idea
to restrict P/T nets to finite ones. It is not stated explicitly, but the
only net graph defined has a finite set of places and a finite
set of transitions. 

6. 

There is a small problem with the fonts on page 27 where (sigma) and s are
of different size. A LaTeX problem maybe ?


7.

The operator *Dot (should be bullet+Dot) is difficult. It would not hurt
to use another bullet in the signature than in the algebra. Or perhaps
another font. I have been working for many years with many-sorted algebras
and I had difficulties with the notations. 

I am working with category theory and the algebra is just the Hom-functor
on the algebraic theory generated by the signature. It is mapping the
sorts to the morphism sets with the sort as target, i.e. Dot = {*} (in the
algebra)  and I do not see why a new sort name "dot" should be introduced?
If the algebra is not initial then the sort is just mapped to the
Hom-functor for (a certain object, i.e. sort string) w instead of the
empty sort string (which gives us the initial algebra). The sort string w
defines the sorts (and number) of the variables in the algebra. And the
morphism set from w to the sort gives us all the terms of that sort.

It is all in my thesis. I used some time to figure it out although you can
find the basic work in the ADJ papers. 

8.

Kimmo was not very happy with the notation 2`1c (p. 34) because he thinks
it is not very readable. I know it is used in Design/CPN but it was
perhaps introduced for syntactical reasons (implementation related) and
not for readability. Why not use 2*1c or something ?

` is dangerous because it is so close to ' and ´ (and very small).



These comments are from reading through the draft. It is of course a
different thing when we really start working with the standard, but at
this point it seems quite nice to me. I am especially pleased that you
have got the many-sorted approach into the standard. I would personally
like to have operators also to target *strings* - not only to one-sorted
targets, but I realise that it may be too difficult and perhaps a bit out
of scope. My reason is that a Petri net transition is equivalent to an
operator with many-sorted target as well as many-sorted source.

OK, that was our comments.

Nisse

__________________________________________________
Nisse Husberg, D.Sc.(Tech.), Prof.
Computer Science Theory Laboratory
Technical University Helsinki
FIN-02150 Esbo
Finland
Tel: +358- 9-451 3254 (job),
     +358-19-614 056 (home),
     +358-40-769 0402 (mobile)
Email: Nisse.Husberg@hut.fi