ratio of two variables results in a matrix
System dynamics program with additional features for economics
Brought to you by:
hpcoder,
profstevekeen
screenshot
data
You're doing a bit wrong, but this is one aspect of Ravel we're still
debating. Currently Ravel only aligns the time axes of two Ravels if they
have the same name. I changed your Ravels into Edit mode (do you know you
can do that?) and the second one had a date for its name (something like
1956-01-01). I used the Dimensions command under the Edit menu to rename it
to Date, and the division worked fine, as you can see.
I think Ravel should align date axes whatever their names, but Russ makes
the point that what about when a Ravel has multiple date axes--for example,
a product sales database could record date of the order and date of its
fulfillment. However, the majority of databases will have just one date
axis, and in that case I think the program should align them automatically.
Your thoughts?
Hi Steve,
(Not sure you realise but we saw each other in Antwerp earlier this week.)
I double checked this morning and noticed that the two date variables had different names. I thought I had checked before but apparently not well enough.
I changed in the CSV files and recalculated and the result was correct.
For what it's worth: In SQL you get to define a primary (usually unique) key per table. That could be the solution here. If there is only one column with date/time that will be the primary key. If there are two or more as Russ points out, it will depend on the user to determine which one is the primary key.
Is there any way I can change the status of this ticket to closed, so Russell won't loose any time looking at this? (Or for other tickets that are resolved with the new versions, to indicate that we have verified that it now works properly?)
Last edit: TomScat 2023-01-28
Of course I did, Tom! It was a real pleasure both to meet you, and to find
you were a serious user of Ravel--and triply so when I saw you'd posted
this bug report.
I think we should leave this one open. Your suggestion of defining a
particular date dimension as the key one for a variable is a very good
idea. Let's see what Russ's reaction to it is.
PS Ravel needs a unique key, and it creates it out of a unique combination
of dimension values. There are fine tuning capabilities in the import
routine as well: duplicate data can be aggregated on import for example.
This would be useful to a company analyzing sales data on a say monthly,
when it had transactions data on all sales. Then Ravel would sum all the
transactions in a month on import.
Your idea is for a primary date dimension, which I think makes sense. But
again, let's see what Russ reckons.
I don't believe we can presume to know what's in the mind of the user - but need to make it as easy as possible to allow the user to manipulate the data. So any such transformation (such as aligning date/time columns) needs to be optional and reversible. I don't think it is an easy task to achieve that, but by no means impossible. Whether it is worth providing this feature is another matter - it may be more confusing than helpful.
I'm glad though that renaming the axis to force the alignment did work as intended. As you might be aware, it was quite recent work that enabled that functionality.
As for primary key - that is more a property of a database, than a Ravel hypercube. Looking up items by primary key is way more efficient than a non-indexed key, because the former is O(log n), and the latter O(n). Within Ravel's tensor manipulations, some things are O(log n), and some O(n), but generally its down to the structure of the data, not whether a primary key is used.
Leaving this in awaiting user column, but at present I'm not sure there's anything to be done.
I think you can close this.
I made a mistake when entering the data.