ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007996 | Part 01: TTCN-3 Core Language | Clarification | public | 09-12-2020 18:18 | 15-12-2020 16:20

Reporter | KristÃ³f Szabados |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | 4.13.1 (ongoing) |
Target Version | 4.13.1 (ongoing) | Fixed in Version | 4.13.1 (ongoing) |
Clause Reference(s) | 6.2.15
Source (company - Author) | L.M. Ericsson

Summary | 0007996: Are the keys of a set type unique?

Description

There seems to be an interesting issue with the current description of how map types work: it is not clear if the keys of the map have to be unique or not.
Section 6.2.15.0:
"TTCN-3 supports the specification of map types that map from a set of keys to a set of values in such a way that each value in the set of key is associated with exactly one value in the set of values."
Please note, that there is no requirement for the keys to be unique ... a set of type in TTCN-3 can contain the same value several times.
This is important to clarify as a map with unique keys differs greatly from a map that would allow the same value for multiple keys at the same time.
For example:
- if the keys are unique, index notation used in the right hand side can refers to only a single element (or results in an error), but if the keys are not unique it needs to return a set of values that migth be associated with that key value (in this case a not existing key could return an empty set of instead of resulting in error).
- In the case of left hand side usage, if the keys are unique the behaviour is quite well definied ... but if the keys are not unique, will it change all values mapped to the same key value, or only one of them?
etc...

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7996-1.docx (189,697) 10-12-2020 09:07 http://oldforge.etsi.org/mantis/file_download.php?file_id=3984&type=bug

Issue History
Date Modified | Username | Field | Change
09-12-2020 18:18 | KristÃ³f Szabados | New Issue |
10-12-2020 08:52 | KristÃ³f Szabados | Note Added: 0015835 |
10-12-2020 08:53 | Tomas Urban | Note Added: 0015836 |
10-12-2020 08:53 | Tomas Urban | Assigned To | => KristÃ³f Szabados
10-12-2020 08:53 | Tomas Urban | Status | new => confirmed
10-12-2020 08:58 | KristÃ³f Szabados | Note Added: 0015837 |
10-12-2020 08:59 | KristÃ³f Szabados | Note Added: 0015838 |
10-12-2020 08:59 | KristÃ³f Szabados | Status | confirmed => assigned
10-12-2020 09:00 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
10-12-2020 09:07 | Tomas Urban | File Added: CR7996-1.docx |
10-12-2020 09:12 | Jens Grabowski | Status | assigned => resolved
10-12-2020 09:12 | Jens Grabowski | Resolution | open => fixed
10-12-2020 09:12 | Jens Grabowski | Assigned To | Tomas Urban => Gyorgy Rethy
15-12-2020 16:19 | Gyorgy Rethy | Status | resolved => closed
15-12-2020 16:19 | Gyorgy Rethy | Product Version | => 4.13.1 (ongoing)
15-12-2020 16:19 | Gyorgy Rethy | Fixed in Version | => 4.13.1 (ongoing)
15-12-2020 16:19 | Gyorgy Rethy | Target Version | => 4.13.1 (ongoing)
15-12-2020 16:20 | Gyorgy Rethy | Note Added: 0015858 |

Notes

(0015835)
KristÃ³f Szabados
10-12-2020 08:52

Please note, that we should somehow warn the users, that accessing map elements is a O(n*m) operation.
As there is no hashing function, the indexing itself has to linearly check each element in the map to determine which the key is refering to making it a O(n) operation in worst case (the average might be around O(n/2)).
And as the keys can be complex types too, the checks of the index value against the set of keys might also be a costly operation O(m) where m stands for the elements/fields of the type of the key.

(0015836)
Tomas Urban
10-12-2020 08:53

In my opinion the keys are required to be unique. Although the specification doesn't state it explicitly, there are rules that actually mean that.
1. In 6.2.15.2 (indexed assignment) the rules say that re-assignment occurs if an existing key is used and requires the index expressions (i.e. the keys) to be unique.
2. In 6.2.15.4 (index notation) the rules say that if an existing key is used on the left hand side of an assignment, the value associated with it is overwritten.
Since these are the only two ways of adding values to the map, I think the current rules grant uniqueness of keys. Nevertheless, I made small modifications to the text in order avoid possible misinterpretation.
Please check.

(0015837)
KristÃ³f Szabados
10-12-2020 08:58

Yes in fact 6.2.15.2 restriction a also describes that in index assignment notation, the indexes have to be unique. That, however is still not a property of the map type, but the notation. Please note that while both of your point is valid in the context of us assuming unique keys, if we do not have this assumption they become underspecified (which key and value are they applyed to)

(0015838)
KristÃ³f Szabados
10-12-2020 08:59

Also you mention of having changed something in the text, but there is no new attachment.

(0015858)
Gyorgy Rethy
15-12-2020 16:20

Implemented in draft 4.12.2