Re: Semantics

[Tony Bartoletti <azb@xxxxxxxx>]

At 06:09 PM 10/22/99 -0400, you wrote:
>>>>>> "Tony" == Tony Bartoletti <azb@llnl.gov> writes:
>
> Tony> At 04:46 PM 10/22/99 -0400, Michael Duren wrote:
>
> Mike> Denis,
>  
> Mike> In looking at the TSP specification, I have one observation.
>  
> Mike> In section 2.1 of the document, it is stated that the serial
> Mike> number shall be "a monotonically incrementing integer for each
> Mike> newly generated time stamp token".  However, in section 2.4.2
> Mike> when the meaning and the usage of the serial number is
> Mike> discussed, it is referred to as "a strictly monotonically
> Mike> increasing integer."
>  
> Mike> My understanding is that "monotonically increasing" values can
> Mike> be equal (i.e. the time value is monotonically increasing) and
> Mike> "strictly increasing" values cannot have equal values.  I am
> Mike> not sure what "strictly monotonically increasing" implies.
> Mike> Seems to me that the serial number should be referred to as
> Mike> "strictly increasing" or "unique and monotonically increasing"
> Mike> in both places.
>  
> Mike> Any comments?
>  
> Mike> Mike Duren
>
> Tony> "Strictly" speaking, you are correct.
>
> Tony> The sequence <2,5,7,7,7,9> is monotonically increasing because
> Tony> it never decreases.
>
> Tony> Uniqueness (1-to-1 mapping) requires a "strictly increasing"
> Tony> (or decreasing) seq.
>
>That doesn't match the terminology I'm familiar with.
>
>2,5,7,7,7... is "monotonically non-decreasing" but it is not
>"monotonically increasing".

I believe the term "monotonic sequence" is intended to imply that
the sign (+/-) of the differences never changes.  It is either
always "+" or always "-", which allows "+0" or "-0".  Since this
leads to 4 possibilities, some schools take "strictly" as a
refinement of monotonic, and I suppose some instead take "increasing"
as a refinement of "non-decreasing".

Come to think of it, with "increasing, decreasing, non-increasing,
and non-decreasing" understood, the term "monotonic" becomes redundant. 

I agree, as you state below, that we should avoid terms that
may be misinterpreted, and try to use "plain english" where possible.

>But given that there appear to be differing interpretations of the
>terminology, it would be best not to use these ambiguous technical
>terms but rather describe in plain english what the required property
>is (i.e., "each value must be > than its predecessor" or "each value
>must be >= its predecessor" depending on which is wanted).
>
>	paul
>
>

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: azb@llnl.gov                                   LLLLLLLL