Changing the pattern concept

[ddiefenthaler]

While implementing the pattern visualizer I stumbled across the fact that it would be useful to know how many tiles one unit holds. This works for the calling unit, as there is the function local_size(). But there is know way to call this function for different units.

A workaround for this is to use local_extents(unit u). By multiplying those extents up this yields the searched size for normal patterns. This workaround is also used by @rkowalewski in PR #467 (diff). But unfortunately this breaks for some patterns, i.e. the ShiftTilePattern.

My suggestion is to add a function local_size(unit u) to the pattern concept. In the same go I would also add the function local_extents() without a parameter which would result in the local extents for the active units. This is already destined for the function global. For the fact that this is not implemented for all patterns see issue #508 .

The title of this issue is left vague on purpose, as if more changes for the concept arise they should be done in one go.

For the current pattern concept see this section from the code documentation: Pattern Concept

Proposed changes:

• add size local_size(unit u)
• add size[d] local_extents()

[devreal]

Is there an update here? Can you provide a PR that adds the missing members?

[ddiefenthaler]

Sorry for my inactivity lately, I just updated the link to the pattern concept as it is unfortunately not a permalink.

Adding the functions to the concept would be easy, but I won't do this without feedback. Once the concept is settled the implementation can start. This should also be mostly straightforward.

I think there were performance concerns for computing those values for any remote unit. This shouldn't be a problem as those functions aren't required for production algorithms. Otherwise it should be possible to cache such values. They are probably also needed for the (mostly not implemented) index-conversions.

I can look into the implementation details once I get positive feedback, but in the case my proposed changes are rejected I would like to reduce pointless work. There is also issue #508 to track and check the implementation status.

I'm hopefully going to be more active again in the next months.