Talk:Tree from nesting levels: Difference between revisions

Line 111:
::::: But as you say – where the inconsistency of the type becomes a problem, a note in the preamble and a variant representation will be enough [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 20:21, 4 February 2021 (UTC)
:::: Considering the first level as a forest with the current wording seems fine. You do have a good point about the [] case being inconsistent though. Following the pattern <pre>[3] => [[[3]]], [2] => [[2]], [1] => [1], [] => ???</pre> then it seems like [] should map to 'nothing' instead of []. Also for the sum type in the python above, why is it between Int and None? Isn't the choice between Int and Tree? [[User:Garbanzo|Garbanzo]] ([[User talk:Garbanzo|talk]]) 03:40, 7 February 2021 (UTC)
::::: Yes, the value represented by `[]` is ambiguous in the output notation shown in the task – we don't have a way of knowing whether it's a single value node or an empty list of potentially multiple children.
::::: The sum type representing value nodes has a None/Nothing option for the cases where no level integer has been supplied, but we do know that there must be an intermediate node. If there is a level 1 and a level 3, then there must be a level in between, descending from 1 and a parent to 3.
::::: An alternative – where there the input contains a 1 and a 3 but no 2, for example,
::::: would be to supply a 2, making the implicit parent nodes explicit.
::::: The simplification of the node value type might be appealing, but the cost is
::::: that the (input sequence -> output tree) rewrite would then cease to be reversible –
::::: once we have added integers that were not explicitly supplied, we have discarded
::::: information, for any return trip, about which levels were implicit, and should
::::: be discarded for the integer list representation, and which were explicit,
::::: and should be kept. [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 06:27, 7 February 2021 (UTC)
 
==Source==
9,655

edits