Delta Inaccuracy
System dynamics program with additional features for economics
Brought to you by:
hpcoder,
profstevekeen
Menu
▾
▴
4 Attachments
#435 Delta Inaccuracy
The program doesn't crash, but it returns numbers that are wrong, as a side-by-side comparison with Excel makes obvious--especially in the first row where the delta numbers should obviously by 0.01, 0.05 and 0.07, rather than the 0.0099, 0.0476 and 0.0654 returned by Ravel.
This hasn't turned up in my email feed yet; posting this to see if that makes it update.
The way that you're calculating relative difference is different. In Minsky, Δx = x_i-x_{i-1}, which is the normal way difference equations are written. In the Excel spreadsheet you're using (x_{i+1}-x_i)/x_i), which is like a forward difference.
To replicate the Excel formula, you need to set the argument to -1, which calculates Δx=x_i-x_{i+1}. But since that formula is now the reversed difference, so you will need to insert a '-' operator (using the second input port) to change the sign of the result.
Actually, the manual entry could be a bit clearer on this topic.
Dang! Yes that makes sense, but it’s an easy mistake to make—a conceptual
one.
Maybe there could be a default entry in the different field of -1 ? Or a
text hint “Negative differences for change over previous value”?
Also, this raises an idea about how to handle time. Where the difference is
across a time dimension (it could be across a People dimension, for
example, income differences across a corporation sorted by seniority), the
form could include a “Unit” field. Left blank it would be just one time
step, whatever the frequency of the data was. Filled in it could be “Day”,
“Month”, “Quarter”, etc.
The default argument is 1, in line with all the operation widgets.
To get terminology right, I refer to https://en.wikipedia.org/wiki/Finite_difference. Minsky currently implements backward difference.
It is arguable whether forwards or backwards difference is correct, but once established, it needs to be documented clearly.
We do have an opportunity to switch which definition we use here - possibly you are the only one to use the difference operation, but we'd need to canvas our user base to be sure.
I took a look at some well-known packages to see what they do: Excel has no such operator, because it is easy to simulate using "drag'n'fill" of a formula. Matlab and numpy both technically implement forward difference, however there would be no distinction between forward and backward difference in their case. If it weren't for Minsky's unique x-vector feature (which allows elementwise division by the input vector), there wouldn't be any difference in Minsky either.
Re your comment about the operation argument being x-vector aware - I always thought we had a ticket describing that as a feature request. I couldn't find it , however, so I'll create a new one. I think it would be best to make this a separate operation, perhaps with symbol Δₓ to distinguish it from the regular difference operation.
I would recommend switching to -1 as a default for this operator. I expect
Tom is using it as well, and Ty-- in fact I'll cc them here to confirm--but
the standard thing in financial analysis, economics, etc., is to see the
difference between this date and the one before it, rather than this date
and the one after it.
Tom and Ty, do you use the \Delta (difference) operator in Ravel, and if
so, do you normally look at change with respect the previous date or the
next date?
That's an interesting idea about delta x: perhaps we should then rename
this one delta t?
I'm not sure about it though--a single operator with internal flexibility
has appeal too.
Good morning,
When I use differences, it is mostly the date before. When using TSP (=Times Series Processor, a software popular once for time series econometrics) one of the appealing features was it's ease to take lags over (previous) times. It was possible to use lag to the future, but it feels awkward.
Russell sent the previous conversation. I will look at the data in that post this evening.
Best,Tom
I would recommend switching to -1 as a default for this operator. I expect Tom is using it as well, and Ty-- in fact I'll cc them here to confirm--but the standard thing in financial analysis, economics, etc., is to see the difference between this date and the one before it, rather than this date and the one after it.
Tom and Ty, do you use the \Delta (difference) operator in Ravel, and if so, do you normally look at change with respect the previous date or the next date?
That's an interesting idea about delta x: perhaps we should then rename this one delta t?
I'm not sure about it though--a single operator with internal flexibility has appeal too.
Whoops! With the -1 argument, Delta returns negative numbers. Not what is intended!
On Thu, Nov 30, 2023 at 07:31:15AM -0000, Steve Keen wrote:
That is why you need to negate the result (mentioned above) by feeding it into the '-' port of the subtract operation.
--
Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders hpcoder@hpcoders.com.au
http://www.hpcoders.com.au
I encountered this issue last year, because of my 5 years on Minsky I quickly figured out to adjust the argument, that said, sort of being an advanced user this would serve as an issue for the beginner/intermediate user. I was going to create a ticket for, but didn't want to bother Russ with a low level problem.
I agree with Russ for consistency reasons the arguments should default at 1. Overall in my math experience its rather subjective if it should be backward of forward looking.
This highlights the need for a complete re write of the help menu, (Something I think I will take the lead on) to shorten the learning curve to the beginner and intermediate users. Visual examples etc beyond the current highly advance explanations, that only mathy peeps understand.
I also like the idea of a new ravel/minsky file have pop ups for each element placed on the canvas, that would have check boxes that would say "don't show this help window again" and "don't show ANY help windows again" This would be file attribute, so every time you saved the file and came back again they would not pop up ever again as they would become very aggravating beyond their use value.
A simple way to resolve this at present would be to have a "negate output" checkbox on the Delta operator. That results in a cleaner canvas too--one less operator for what is a very common situation in finance, economics, business analysis etc.
Since I expect our target market will be Excel users (rather than Pivot Table users), they would expect the operator to function this way (change over previous value) and making this a (user-editable) default setting would also help.
To resolve this issue, I'm adding another operation "differencePlus" that uses the forward difference x_{i+Δ}-x_i. That way we retain backward compatibility with models that use the existing convention.