Why does it produce strange number?

[yut]

Attached file is a part of a larger model.
"real dev cost" and "target cost" are the same in the parameter setting.
Therefore, "a", which is "target real ratio" minus one, should keep zero.
However, it has very small positive number.
In this model, it's OK.
However, in the bigger model, this small positive number accumulate and cause trouble.
Why is not "a" zero?
How can I sort it?
(I want "a" to be zero!.)

[Administrator]

I think this is a case of floating point errors (https://www.google.com/search?client=fi ... int+errors).

Can you share the larger model? It might be a different reason for the accumulation.

[yut]

The bigger model is here.
It stops by the floating point overflow error OR runtime error.
I cannot say why two errors occur in different run.
When floating point overflow error occurs, Vensim display the message below.
INFO:
INFO: ERROR: Floating point error computing : change in sales
INFO: ERROR: Check causes and uses of change in sales for division by zero or overflow
INFO:
ERROR: Floating point error computing - change in sales - at time = 36.250000.
INFO: Trying to save the results anyway

[yut]

Thanks, admin.

But, I think both (small and big) models should be in equilibrium at least in the setting of current parameters.

[Administrator]

"Sales" in your model is measured in "$/Month". That's a rate, but you are accumulating the "change in sales" and not resetting "Sales" at all. Is this your intention? I think maybe that this is the cause of the problem, "sales" keeps accumulating, but the units of "$/Month" suggest it should not.

I'm struggling to understand the logic in your structure,

[yut]

Hi Admin,

Thank you for your reply.

In the model, "sales" is not a rate.
This is the sales level for a one-month period.
As you know, units do not distinguish between levels and rates.

Of course, if we have a stock of "inventory" and its outflow of "sales," "sales" should be a rate.
However, in the context of uploaded model, sales is a "consequence" of development investment (in the model, development cost).

Moreover, the calculation result is not related to the unit name.
If all variable names are "a," "b," or "c," I believe you would understand why I have a question about calculation result.

[tomfid]

The proximate cause of the FP error is that the real cost ratio becomes large, which causes sales to grow at an astronomical rate.

The conceptualization of sales as a stock is conceptually questionable here. Consider, for example, what happens if you fix the real cost ratio at 1.1: sales would grow forever at 10%/month. That's impossible in the long run, and it's not a normal price elasticity effect, which would normally be something like sales=cost^elasticity (no integration).

I'm not sure what the concept of cost is here, but it seems inverted. I would expect higher cost -> higher price -> lower sales.

I would consider some thought experiments in extreme conditions. For example, what happens if you raise price to a very high level instantaneously? Should sales fall to near 0 immediately, or gradually decline?

[yut]

Thanks, Tom.

I agree with you about the cause of floating point error.
But, it is not my main question.
My question is in the bottom of this message.
But let me explain a little first.

Maybe, the word "cost" is not appropriate.
It should be "investment."

I think it is not ridiculous to set sales as a level.
Some of B2B business have clear relationship between quality or implemented functions and price.
But, it might be expressed as "sales ability" or "sales representatives" instead of "sales."

It is completely right that there should be some growth limit.
But in this step, I am write down a model completely based on my client's explanation (or argument).
Then I will show them that the simulation result is something wrong and start to explore their mental model together.

However, before going ahead, we found that the variable "target real ratio" should keep 1 (and of course, a should keep 0) in smaller model (untitled.mdl) but the simulation result didn't.
This made the client disappointed and concerned about the software calculations.
Therefore, I would like to know the reason that the very simple calculation (0.2/0.2) does not provide correct answer 1 in the smaller model.