Having read all of the replies, I like the suggestion to add simple readable documentation to the data structures' module docs the best.
Adding new documentation metadata seems to me not worth it. Besides the already mentioned problems, I would like to mention that complexity-documentation is not *that* structured: - Besides Big-O, there is Big-Omega and Little-o, which are also very useful and relatively common in literature. Do we also need to add new metadata names for those? - Time-complexity and Space-complexity are by no means the only complexities that are being measured for data structures. Do we also need to add new metadata names for e.g. communication complexity, - What about amortized complexities? - In regards to *what* is the complexity measured? (i.e. "what is `n` in O(2n+3)"?) And that, combined with the fact that I think it is important to also accommodate people who are new to this mathematical way of writing algorithmic complexities, makes me conclude that it is a bad idea to create a rigid structured way for it, and that adding some humanly-readable unstructured documentation for common operations on commonly-used datastructures would be the way to go. These unstructured documentation snippets might be accompanied by their formal complexity notations, but should not only consist of these. ~Qqwy/Marten On Thursday, July 18, 2019 at 6:36:04 PM UTC+2, Mário Guimarães wrote: > > Hi, > > I find this can be useful in selecting the collections and their > manipulating functions to be used in our code. > > The case is that in an immutable language it may not be evident what is > the O(...) of the insert, read, update, delete and sort, in our collections. > > For example, what is the complexity of sorting an immutable enumerable via > `Enum.sort`? I really do not know. > > This could be documented with a table at the start of the documentation > for the collection. > > This effort could be decomposed in as many issues as the number of > collections to document. > > Experienced people may know many of these Big-O details, but for > newcommers to Elixir (and Erlang) it could be very helpful. > > Thanks > Mário > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/9bacd647-8731-4b19-9f86-38e6b0f87bb3%40googlegroups.com.
