Getting attributes from one note for another note not in hierachy

Hi; again thanks for all the responses to past inquiries as I ramp up with Tinderbox.

I’m using Tinderbox in a way that is exciting, at least to me as an engineer. I am using the map display to show a hierarchical system power analysis. It’s a nice way to not have to separately use excel, then a separate manual drawing too.

Problem I have (I’m sure easily solved) is to get an attribute from one note, and use it as part of math in another note that is not in the same hierarchy. I have agents outside the hierarchy that do some math and then (ideally) put those results back in a note inside the system hierarchy. For example, the agent calculates a total $Power in watts from a sum of captured notes; then I want to send that $Power to another block to use.

I realize a link may be able to do this, but I haven’t been able to make links work to transfer numbered attributes (my own naiveness).

Thanks if anyone can help. I’m hoping to put the completed analysis in a tutorial or example of a way to use Tinderbox in visual engineering.

John L

OK, so agent called ‘PowerAgent’ sets it’s $Power to, for example the sum of the $Power values of all its aliases (i.e. its children). Agent’s $Rule:

$Power = sum(children,$Power);

So how to use this resulting $Power value in the note ‘Total Power’? The latter might user a rule like this to match its $Power attribute value to that of the the same attribute in the agent, using an offset reference:

`$Power = $Power(“PowerAgent”);

As long as the title ‘PowerAgent’ is unique within the document, then using just the desired object’s $Name is enough to specify the offset address; otherwise use the entire $Path.

You can actually use an offset on the left side of an action, so the agent’s rule could be re-written as:

$Power = sum(children,$Power); $Power("Total Power") = $Power:

Note there are 2 expressions in the code above - the semi-colon acts as a delimiter. I’ve used the same attribute ($Power) throughout but thats not a requirement:

$Power = sum(children,$ComponentPower); $SomeNumber("Total Power") = $Power:

Ideally, use similar data types. Tinderbox will coerce types if needed (e.g. number to string, etc.) but if doing so run small tests first so you can spot unexpected results. HTH

1 Like

thanks, that’s exactly what I was looking for… how to translate one agent’s attribute to a specific note. Thanks also for a super quick reply. I’ll use it right now.

Hi John,

@mwra’s answer is great, and will cover a lot of use cases.

Another option — one that I use a lot, and the one that you have already intuited — is to explicitly link up the notes and then use link-query operators to query the link set of a note.

For example, in the attached Tinderbox file, there is a note named Sum (method 1), which has a Rule that maintains its value of $MyNumber to always be the sum of the values of $MyNumber for all notes that are linked to it with a “value” link:
$MyNumber=sum(find(linkedTo(that,"value")), $MyNumber);

The note name Sum (method 2) contains a less idiomatic, but perhaps clearer (and I would guess more efficient for documents with many notes) way of doing the same thing:
$MyNumber=0; links.inbound.value.$MyNumber.each(x) { $MyNumber = $MyNumber + x; };

This approach can yield a wonderful functional view of the calculation that is being done. For example:

That’s it. The links show where the information is flowing, and there’s no need to ensure that note names are unique or update actions if we rename notes. Nice and clean.

sum.tbx (56.7 KB)

3 Likes

Very clever @galen – thank you.

The $Rule for “Sum” in the example file has both versions of the rule you described in your posting. Is that intended?

1 Like

Not intentional — thanks, @PaulWalters. I’ve updated the attachment so that it has two sum notes, one for each method.

1 Like

I’m glad @galen posted a link-based solution as it’s equally applicable - I just didn’t want to overload the first answer with detail - and a more visual way to show workings.

If working in a map-based method, if the links get busy, don’t forget you can hide links types: they are still there, just not drawn on screen. IOW, if desired you can have invisible links added just for computational purposes. Link visibility is handled by the Links Inspector and works globally per links type. So, if you made the link type ‘value’ invisible, all ‘value’-type links in the doc would become invisible but other links types would still be drawn. The setting is a toggle so you can, for example, have the link types visible while you set up the links and check your action code then make them invisible once everything is working.

2 Likes

Both @mwra’s and @galen’s methods would be useful for @dominiquerenauld and others looking to make dashboards.

I have a newbie question that I should not have seeing as I’ve been using Tinderbox for so many years now and I expressly please you not to laugh (too much) at it :grin:: in which language is Tinderbox written? I certainly read it somewhere, but I can’t recall where and I didn’t find the answer in the first edition of The Tinderbox Way.

In which computer language is the app itself written? I believe it started being coded in the Metrowerks app (using C++?) and as of v6 was written using XCode (Objective-C?). for a proper description, that’s a question for @eastgate.

Linguistically, (Help, etc.) it is written in American English.

OK. I hesitated over writing computer language, but it was actually the meaning of my question.

Tinderbox is currently written in Objective C++. It started in straight C++, but acquired lots of Objective C in the shift to Tinderbox 6.