Bug: Very precise time settings for model

[Travis]

I don't remember this before, but it seems you can't have integer values for a model's INITIAL TIME or FINAL TIME. Or, at least, the formatters for the Model Settings window don't let you.

I've tried removing the extraneous zeros but they always come back. Several models, not just one.

Vensim 10.1, macOS Ventura (not Sonoma)

Screenshot attached.

[attachment=0]Screenshot 2023-10-31 at 12.42.47 PM.png[/attachment]

[Administrator]

These are all represented internally as double precision, that's why they are like this in the GUI.

[Travis]

Huh, I don't remember this level of precision in previous version of Vensim (e.g., v8). I would suggest limiting this since it isn't helpful for the user and is particularly weird when time is years, like this:

[attachment=0]Screenshot 2023-10-31 at 3.29.56 PM.png[/attachment]

Seems like it should be formatted at integers unless the user enters a decimal.

[Administrator]

Huh, I don't remember this level of precision in previous version of Vensim (e.g., v8). I would suggest limiting this since it isn't helpful for the user and is particularly weird when time is years, like this:

What if you have half a year? It's not unusual to have a half year.

I really don't see the issue here. They are represented internally as double precision, so why not make that absolutely clear in the GUI?

[tomfid]

I think we can have our cake and eat it too here.

[Travis]

I understand the admin's point of view, but I'll try to represent a new user's perspective. Vensim is a very complex and daunting tool. Decimals create a cognitive load (for anyone) and scare students (and sometimes modelers). If Vensim can help a user by only displaying complexity and precision when needed, then that helps reduce the cognitive load on the user.

This Settings window is minor, but since it is a screen that a beginning modeler uses, it is something to review carefully.

And, as maybe implied by "have cake and eat too", the underlying code can accept a double, but the UI formatter could only show it when the user needs that level of precision. A half year can be shown with only one decimal, not six.

Thanks for considering.

[tomfid]

I think the task here is actually a little bigger. Since .vdfx went to double precision, there's been a mismatch between the engine/output numerical precision and text precision. For example, you can read in a constant from a .cin file as a float or a double, but a constant in an equation gets truncated to a float, even if you enter more digits. This is troublesome if the constant is meant to be sqrt(pi) or something. Similarly, export and tables don't give you full precision (unless you specify a c-style formatter).

Beneath all this is the fundamental problem of not all decimals having an exact binary representation in single or double precision. However, there are some libraries that do give reversible conversions, so decimal you typed -> double -> decimal doesn't change, except in some perverse cases. I think this also gives you a min-length decimal in most cases. This is what we need to implement.

However ... it's tricky, because the interpretation of some floats could change, which could change model behavior. One could argue that a model that's sensitive to the last digit of a float is not so robust, but that's not always true. So this will need a lot of testing before unleashing it on the world.

[Travis]

This makes sense. Thanks for the explanation. If I can be helpful in thinking through the UI/UX, let me know.