[x3d-public] remove SF/MFInt32 ?

[John Carlson]

I think type conversion should be implicit, or with a warning.   Would this
satisfy the requirement?

John

On Fri, Apr 6, 2018, 1:42 PM Andreas Plesch <andreasplesch at gmail.com> wrote:

> 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
> _______________________________________________
> 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/20180406/a02d5367/attachment-0001.html>