[x3d-public] Sequencer interval definition

[Andreas Plesch]

Ok, here is a non-interactive test for correct half-closedness of sequencer
intervals:

http://x3dom-sequencer-interval-test.glitch.me/SequencerInterval_test.x3d

In x3dom:

https://x3dom-sequencer-interval-test.glitch.me/

With the updated, correct X3DSequencer implementation for x3dom (
https://github.com/andreasplesch/x3dom/blob/IntegerSequencer/src/nodes/EventUtilities/X3DSequencerNode.js)
the cone is illuminated in red.

With the incorrect, earlier implementation for x3dom (
https://glitch.com/edit/#!/x3dom-sequencer-interval-test?path=X3DSequencerNode.js:106:41)
the cone stays grey.

Testing x-ite it appears that x-ite interpreted intervals to be open on the
left and closed on the right (not the intended interpretation): the cone
stayed grey.

Getting to other browser hopefully later when I have access to Windows.

-Andreas


On Sun, Oct 1, 2017 at 11:33 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Hi Vince,
>
> wolfram is good enough for me. Let me check at least my sequencer x3dom
> code, and perhaps come up with a simple test.
>
> -Andreas
>
>
>
> On Sun, Oct 1, 2017 at 9:42 PM, vmarchetti at kshell.com <
> vmarchetti at kshell.com> wrote:
>
>> For more on the [a,b) denoting an interval a <= x < b, see
>> http://mathworld.wolfram.com/Half-ClosedInterval.html
>>
>> However, I agree that for the practcal problem of clarifying the spec
>> language, we should know how existing browsers have interpreted the
>> currrent language.
>>
>> Vince Marchetti
>>
>> > On Sep 30, 2017, at 11:47 PM, Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Sep 30, 2017 7:49 PM, "vmarchetti at kshell.com" <vmarchetti at kshell.com>
>> wrote:
>> >
>> > > On Sep 4, 2017, at 11:45 AM, Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>> > >
>> > > Resending this without html formatting to ensure proper transmission:
>> > >
>> > > 30.2.4 defines how sequencer values are assigned to key intervals:
>> > >
>> > > http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/utils.html#SequencingEvents
>> > >
>> > > (−infinity, t0), [t0, t1), [t1, t2), ... , [tn-1, +infinity)
>> > >
>> > > are the intervals.
>> > >
>> > > The square bracket [ seems to indicate that the limiting value does
>> not belong to the interval. Is that the case ?
>> >
>> > I'm more used to the square bracket indicating a closed boundary, so
>> that the for the interval denoted [a,b) ; x is in the interval a <= x < b
>> > so a is an element of the interval but b is not. Take the view that
>> neither +infinity nor -infinity is a number; so (-infinity,a) is just
>> shorthand for the set x < a, while [a,+infinity) is x >= a.
>> >
>> > VRML97 seems to be when the bracket for the interval was introduced:
>> >
>> > http://tecfa.unige.ch/guides/vrml/vrml97/spec/part1/concepts.html#4.6.8
>> >
>> > But it is not accompanied by an explanation. For interpolators it may
>> not matter if the limit is included in the interval since the function is
>> continuous.
>> >
>> > For sequencers, the function produces different values depending on
>> from which side an interval limit is approached.
>> >
>> > I guess it is time to look up how various browsers behave at sequencer
>> interval limits.
>> >
>> >
>> >
>> > >
>> > > For example, in the second interval [t0, t1) t0 does not belong to
>> the interval but t1 does.
>> > > I have seen other notations where this interval would be described as
>> ]t0, t1] which I would offer as a suggestion for an improvement.
>> > >
>> > > The next question is about the piecewise function definition:
>> > >
>> > > f(t) = v_n, if t_n <= t < t_(n-1)
>> > >
>> > > Given that the keys t_i are given in a monotonically non-decreasing
>> order, t_n is always larger (or equal to) than t_(n-1). Therefore, a t
>> larger than t_n can never be smaller than t_(n-1). But this is the
>> condition described in the function for value v_n. There is no possible t
>> which can fulfill this condition.
>> > > Presumably this condition was designed as:
>> > >
>> > > f(t) = v_n, if t_n >= t > t_(n-1)
>> > >
>> > > If this is the case I can submit a spec. comment but I very much
>> would appreciate additional eyes on that since it seems like a rather
>> fundamental oversight. Did I overlook something ?
>> > >
>> >
>> > My set of eyes agrees with yours that the formula form in the v 3.3
>> version of section 30.2.4 is incorrect, I would propose a corrected version:
>> >
>> > f(t)    =  v_i, if t_{i-1}   ≤ t < t_{i}  for  1 <= i < n-1
>> >         = v_0, if t < t_0,
>> >         = v_{n−1}, if t ≥ t_{n−1}
>> >
>> >
>> > Looks good to me if [ is meant to include the limit in the interval.
>> >
>> > Andreas
>> >
>> >
>> >
>> >
>> >
>> > > The Interpolator component spec. may provide additional insight:
>> > >
>> > > http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/interp.html#Linearinterpolation
>> > >
>> > > Here the equivalent piecewise function definition is:
>> > >
>> > > f(t) = linterp(t, v_i, v_(i+1)),    if t_i <= t <= t_(i+1),
>> > >
>> > > Note that the interval condition here is between t_i and t_(i+1) and
>> not t_(i-1). So this is correct. But why change for Sequencer to t_(n-1) ?
>> Perhaps there is a reason ?
>> > >
>> > > Also note that i is used rather than n which is also more correct
>> since n is reserved for the fixed, total number of keys, whereas i is the
>> variable index depending on the whatever time t is considered.
>> > >
>> > > -Andreas
>> > >
>> > > --
>> > > Andreas Plesch
>> > > Waltham, MA 02453
>> > > _______________________________________________
>> > > x3d-public mailing list
>> > > x3d-public at web3d.org
>> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>> >
>> >
>>
>>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>



-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171002/b2470a6d/attachment.html>