#1866 Caliper inconsistency

[Steve Keen]

I have one data series with monthly info, hence 12 time steps are needed to get yearly change, and others with quarterly data, where 4 time steps are needed. Of course the calipers are not properly aligned.

This is a major issue which might only be resolved by creating the time-based difference operators.

[High Performance Coder]

The GDP dataset finishes in 2003, whereas the CPI dataset has more datapoints. So you would expect that adjusting the Inflation% dataseset's caliper beyond that of the Growth% calipers should set the Growth%'s caliper to the end of its dataset. That is what happens for me using 3.13.0 (which is what is compiled from source code on my laptop). Unfortunately, opening this using the current OpenSUSE build of 3.16.19 crashes. I'll add a ticket for that to look at when I'm back in Sydney. There appears to be a SVG rendering issue, perhaps related to the upgrade to librsvg that happened recently.

[Steve Keen]

No, both data sets go out to 2024; there are just more data points in the CPI file because that is monthly whereas the GDP is quarterly. I did some hack work in Excel to make a single file where all series use the same date format (see CruzData).

[High Performance Coder]

I think I understand what is happening now. The second Ravel computing Growth gets it's time domain from the intersection of GrowthRate^Nom and Inflation, and the latter's time domain is controlled by the caliper on the first ravel. So when moving the caliper on the first ravel outside what the second caliper's truncated range is, the second caliper maxes out. Then after a reset, the axis range on the second Ravel is recalculated, and you can apply the first Ravel's calipers settings to the second one, but it doesn't happen automatically.

Great care will be needed when addressing this situation to avoid a loop where the change in the second caliper range causes the first caliper to be reset.

[Steve Keen]

I think we may have to live with this until we introduce time based
difference operators and the like. But yes, infinite loops must be avoided.
On Wed, Jun 18, 2025 at 9:39 AM High Performance Coder hpcoder@users.sourceforge.net wrote:

I think I understand what is happening now. The second Ravel computing
Growth gets it's time domain from the intersection of GrowthRate^Nom and
Inflation, and the latter's time domain is controlled by the caliper on the
first ravel. So when moving the caliper on the first ravel outside what the
second caliper's truncated range is, the second caliper maxes out. Then
after a reset, the axis range on the second Ravel is recalculated, and you
can apply the first Ravel's calipers settings to the second one, but it
doesn't happen automatically.

Great care will be needed when addressing this situation to avoid a loop
where the change in the second caliper range causes the first caliper to be
reset.

---

[ravel:#692] https://sourceforge.net/p/minsky/ravel/692/ Caliper
inconsistency

Status: open
Milestone: Babbage
Created: Fri Jun 13, 2025 06:13 PM UTC by Steve Keen
Last Updated: Sat Jun 14, 2025 06:12 AM UTC
Owner: High Performance Coder
Attachments:

• CaliperInconsistency20250613.png
  https://sourceforge.net/p/minsky/ravel/692/attachment/CaliperInconsistency20250613.png
  (381.2 kB; image/png)
• CaliperInconsistency20250613.rvl
  https://sourceforge.net/p/minsky/ravel/692/attachment/CaliperInconsistency20250613.rvl
  (1.3 MB; application/octet-stream)

I have one data series with monthly info, hence 12 time steps are needed
to get yearly change, and others with quarterly data, where 4 time steps
are needed. Of course the calipers are not properly aligned.

This is a major issue which might only be resolved by creating the
time-based difference operators.

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/minsky/ravel/692/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[High Performance Coder]

Ticket moved from /p/minsky/ravel/692/

Can't be converted:

• _priority: 4Urgent