[x3d-public] Sequencer interval definition

Tue Oct 3 09:51:54 PDT 2017

continued ...
On Tue, Oct 3, 2017 at 9:21 AM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> 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.
>
>
http://x3dom-sequencer-interval-test.glitch.me/SequencerInterval_test_inFirst.x3d

is a test if the first (v0) or second keyValue (v1) is selected if the key
falls into the interval [t0, t1)

Octaga, InstantPlayer and x-ite all select v0 , unfortunately. I will also
test BSContact but expect it to also select v0.

I believe this is inconsistent with Vince's proposal for a corrected
function as the proposal reserves v0 for the interval t<t0 .

This behaviour is not inconsistent with the current spec. because the
current spec. provides a function definition which must be incorrect and is
therefore open to interpretation.

For the sake of practical backward compatibility, therefore Vince's
function definition may be altered to:

f(t)   =  v_i, if t_{i} ≤ t < t_{i+1}  for  0 <= i < n-1
        = v_0, if t < t_0,
        = v_{n−1}, if t ≥ t_{n−1}

It would be still possible to define a reserved value for the interval t<t0
by repeating the first key: key="0 0 1"

How does that look ?

-Andreas

> -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
>>> >
>>> >
>>>
>>>
>>
>

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