[x3d-public] Sequencer interval definition

Tue Oct 3 06:21:36 PDT 2017

On Oct 2, 2017 2:26 PM, "Andreas Plesch" <andreasplesch at gmail.com> wrote:

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/IntegerSequence
r/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?pa
th=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.

I tested Octaga, BS Contact, view3dscene and InstantPlayer. All fail the
test, eg. the cone stays grey.

Investigating, I changed the test by modifying the keyValues of the
BooleanSequencer to turn on the light when the key (0.2) is part of the
interval 0 to 0.2, or whatever the second interval is:

<BooleanSequencer DEF='OnOffSequencer' key='0 0.2 0.4 1' keyValue='false
true false false' ></BooleanSequencer>

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

This is the only change.

For this test, Octaga, BS Contact and x-ite show a red cone. InstantPlayer
and view3dscene still show a grey cone, indicating perhaps other issues
with the scene (perhaps the routing order).

One explanation is that the players consider the intervals to be closed on
the right, upper limit.

Another explanation may be that the players consider t<0 to be part of the
first interval - 0 to 0.2 - . Then they would consider - 0.2 to 0.4 - the
second interval, thereby turning on the light. This is less likely because
the first interval is clearly specified as (−infinity, t0). This can be
tested as well by routing 0.1 to the sequencer. This should select the
second keyValue turning on the light.

I will try this.

-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/P
>> art01/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/P
>> art01/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
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20171003/88736509/attachment.html>