Variable types and truncation

Support
1

Chris,

I noticed that in MWorks 0.4.5, it is now rounding if the variable was declared an integer (e.g. 0.3 is rounded to 0). Not that I disagree with this behavior, but I don’t remember this happening in older versions.

Is this a new change to the integer class? Does this mean we should do a better job keeping track of whether variables were integer or float?

Thanks,

Elias

2

Hey Elias,

Yes, that’s new behavior. Previous versions of MWorks interpreted all variable default values as floats, regardless of declared type. That made it impossible to declare variables of type “string”, which is why I made the change.

Dave has questioned whether truncation is really the correct behavior, so it’s possible that we’ll revisit this change in the future. For now, though, you should be careful to declare your variables with appropriate types.

Chris

3

I vote that we promote that warning to a full, experiment-stopping error as soon as possible. Too many ways this can quietly ruin someone’s day, and erode trust in the upgrade process.

Dave

Sent from my iPhone

4

I vote that we promote that warning to a full, experiment-stopping error as soon as possible.

That’s fine with me. Should it be a “normal” error (merror invocation) or a parse error (raised exception)? The latter seems more robust, in that it would prevent the experiment from loading, but I worry that it could lead to breakage when ComponentRegistry::getNumber is called while an experiment is running.

Chris

5

Should it be a “normal” error (merror invocation) or a parse error (raised exception)?

It looks like ComponentRegistry::getNumber is only called at parse time, so I went with a parse error. The change will be in tonight’s nightly build.

Chris