Ventana software support forum

I'm experiencing odd outputs in my model when looking at the fractional part of a number.

One calculation being performed is 50 (SUM from two constants imported from excel) multiplied by 0.6 (constant, direct input), and the output is 30 in the table in vensim but when looking at it in excel export I have 30.00000190734860 . Then, when this is multiplied by 0.1 (constant imported from excel) it is 3.00000023841857.

In another part of the model 0.899999976158142 (calculated variable) multiplied by 10 (constant imported from excel) is giving an output of 9 (both in vensim and excel export).

I attach an excerpt from the model which includes the first error I refer to and the data input file.

Is there some Vensim explanation for this that I am missing?

I am using version 5.7a (Double Precision)

I think what you're seeing is probably precision effects from the floating point representation. A lot of fractions - including .1, .3, etc. - don't exactly map to binary.

In 5.7dp (which is truly ancient) this is exacerbated by the fact that computation is double precision, but storage in the vdf is single precision. Some of the data input from Excel might also have been single precision. This means that there's some additional truncation loss from the underlying double precision calculations.

I'll take a look at the model and see if there's any further insight.

Great, thanks Tom.

We have also since found that if we import the data without subscripts that the error doesn't seem to occur. Is subscripted data imported differently?

No, subscripted data is not handled differently.

Any imported numbers will only be accurate to 8 significant figures as they are all stored at that accuracy. So you might be better off using the single precision version of Vensim.

I have the same issue on Vensim DSS 9.3.5. I want to compare the impact of different strategies with the baseline values. I exported the simulated values into xlsx and imported them again as data values, but it slightly changed the imported values. Then, I exported the new results for both original and the baseline values. The original one remained the same, but the data values were changed.

After spending a lot of time (I am more familiar with the first method for importing data), I realized if I read the excel file through the GET XLS DATA function, the error is reduced to e-14, which is desirable compared to the larger error I get with the Import Dataset method.

If you can email us the datasets and instructions on how to recreate this, we can take a look.

Could you please test it with the structure I posted here? A test excel file and a test Vensim model would work. I used 313.33060002299600 as data input. Please let me know if it does not work, so I will send the exact files I have used to make this example.

If you zip up the relevant files and post here or email, it would likely yield a better (or at least faster) result.

Right. I have attached the zip to this post and already posted instructions to replicate the issue.

Thanks - we'll take a look. My guess is that it's a numerical precision truncation somewhere. But it's probably impossible to fully reconcile - Excel's numerical storage is presumably a decimal format, while Vensim is using doubles. As I recall, the IEEE standards even permit variation in the low bits beyond the standard size, which may arise in different hardware.

Does this have any policy relevance in your model? If the results are qualitatively sensitive to these differences, it's either an interesting situation, or an unreasonably sensitive formulation.

Yes, it can be a sensitive formulation (unfortunately, I am unsure if I can share the model, as it is part of a larger project). I wanted to use a shortcut to calculate the percentage change from the baseline. That is how I realized the imported baseline dataset (captured from exporting the simulation output) differs from the simulated baseline (the graph). The error is extremely low when you read the data using GET XLS DATA (the red parts in the image show the data export/import process. They are not model variables).