[x3d-public] remove SF/MFInt32 ?

[Andreas Plesch]

I did not really expect a lot of enthusiasm but thought it might be worth a
discussion. So let me try.

On Fri, Apr 6, 2018 at 1:02 PM, Michalis Kamburelis <
michalis.kambi at gmail.com> wrote:

> "2018-04-06 17:22 GMT+02:00 Andreas Plesch <andreasplesch at gmail.com>:
> > Here is a somewhat radical idea to simplify X3D a bit. Since x3dom is
> > javascript it does not really distinguish between SFInt32 and SFFloat,
> and
> > lives pretty well with it. So why not consider completely removing the
> > SF/MFInt32 from the spec. in general ?
> >
> > The integer fields are used in not very many nodes: Switch,
> > IntegerSequencer, LOD (level_changed) come to mind. A replacement with
> > SFFloat would mean adding rounding or truncation to nearest integer in
> the
> > spec. language but probably not more than that.
> >
> > The advantages are that it is an opportunity to make the spec. leaner,
> and
> > help with some node communication issues.
> >
> > The disadvantages are that it would be a backwards incompatible change,
> and
> > may have a minor performance impact.
> >
>
> This is a limitation of JavaScript (there are no separate "integer" or
> "float" types, just "number"), but all other programming languages
> have separate integer / float types. So I would a bit reluctant to do
> this...
>
> Equating "SFFloat == SFInt32" would mean we have less strict typing
> when it comes to checking ROUTE connections. All SFFloat fields/events
> could be then connected with SFInt32. E.g. in my opinion it is good
> that right now you are forced to animate "Switch.whichChoice" with
> "IntegerSequencer", and you cannot do it with "ScalarInterpolator".
> And it allows X3D specification to avoid making some general rules
> whether we round (with round(0.75)=1.0), or truncate (ceil).
>

I am not sure if X3D should be considered a programming language although
it is probably Turing complete. Its declarative nature and its abstracted
foundation serve to strike a balance between ease of use and full
programmability. So I think there may be room for simplification.

You are right that the loss of some strictness in type checking would be
probably the main drawback/impact.

The rule on how to convert to an index would be just a decision.
Alternatively, indices could still be required to be round numbers.
Otherwise, the value would be undefined. The strict type checking is a
doubly edged sword. It encourages more precision on the input and therefore
presumably more correctness but then requires more nodes and fields to
enable that precision. For example, I would like to route a level_changed
SFInt32 value to a SFFloat key field of a BooleanSequencer. Now I need a
type converter and since there is not one, I have to have a type converter
script just to satisfy type correctness.


> More importantly, what happens with MFInt32? If it's now MFFloat, then
> we get a performance hit when reading a long list of coordinates (like
> IndexedFaceSet.coordIndex), because now we have to call round() on
> every list item.
>

I believe this would be a one time operation during loading which would be
barely noticeable on a modern system, even for large IFSs. The parsing of
the string to a number in the first place likely takes much longer.


> Regards,
> Michalis
>

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