<div dir="ltr">I did not really expect a lot of enthusiasm but thought it might be worth a discussion. So let me try.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 6, 2018 at 1:02 PM, Michalis Kamburelis <span dir="ltr"><<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"2018-04-06 17:22 GMT+02:00 Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>>:<br>
> Here is a somewhat radical idea to simplify X3D a bit. Since x3dom is<br>
> javascript it does not really distinguish between SFInt32 and SFFloat, and<br>
> lives pretty well with it. So why not consider completely removing the<br>
> SF/MFInt32 from the spec. in general ?<br>
><br>
> The integer fields are used in not very many nodes: Switch,<br>
> IntegerSequencer, LOD (level_changed) come to mind. A replacement with<br>
> SFFloat would mean adding rounding or truncation to nearest integer in the<br>
> spec. language but probably not more than that.<br>
><br>
> The advantages are that it is an opportunity to make the spec. leaner, and<br>
> help with some node communication issues.<br>
><br>
> The disadvantages are that it would be a backwards incompatible change, and<br>
> may have a minor performance impact.<br>
><br>
<br>
This is a limitation of JavaScript (there are no separate "integer" or<br>
"float" types, just "number"), but all other programming languages<br>
have separate integer / float types. So I would a bit reluctant to do<br>
this...<br>
<br>
Equating "SFFloat == SFInt32" would mean we have less strict typing<br>
when it comes to checking ROUTE connections. All SFFloat fields/events<br>
could be then connected with SFInt32. E.g. in my opinion it is good<br>
that right now you are forced to animate "Switch.whichChoice" with<br>
"IntegerSequencer", and you cannot do it with "ScalarInterpolator".<br>
And it allows X3D specification to avoid making some general rules<br>
whether we round (with round(0.75)=1.0), or truncate (ceil).<br></blockquote><div><br></div><div>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.</div><div>  </div><div>You are right that the loss of some strictness in type checking would be probably the main drawback/impact.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
More importantly, what happens with MFInt32? If it's now MFFloat, then<br>
we get a performance hit when reading a long list of coordinates (like<br>
IndexedFaceSet.coordIndex), because now we have to call round() on<br>
every list item.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Michalis<br>
</blockquote></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div>
</div></div>