Hello everyone,
How to get the first element in a Table ?
My example :
import tables
var a = {1: "one", 2: "two"}.toTable
echo a.keys[0]
The result, for me, should display 1.
Thanks.
Given that a table is not an ordered collection, how is it possible to get any first element?
As an alternative you could implement it as an array of tuples for example:
var a = @[ (1,"one"), (2,"two") ]
and then you could easily retrieve a[0].
A table is unordered. Values are indexed by their keys.
At the moment you can only use OrderedTable and iterate on it and break after the first iteration. PR welcome for more operations.
If you tell us what your data structure will be used for we would be more able to help you
I don't use the Table object properly. I'm going to change my data structure.
Thank you.
Minor correction to @mratsim - if you want to iterate and break after the first then you can use any of the table types, not only OrderedTable. E.g.
import tables
var a = {1: "one", 2: "two"}.toTable
for key, val in a:
echo key
break
You may know that the keys are unique by construction/etc., though, and want to pop them off in whatever "fast order" is convenient. Indeed, the HashSet in sets even provides a pop proc. E.g.,
import sets
var a = ["one", "two"].toHashSet
let x = a.pop
echo x
echo a
if you want to iterate and break after the first then you can use any of the table types
It is just a current implementation detail / coincidence, that your first example returns 1 as the first key. Don't rely on that, please.
Btw, if you (plural) want sorted tables, there is a new player in the town: https://github.com/narimiran/sorta
I've tested it as best as I could, but more eyes on it and some "in the wild" tests would be appreciated. (Also, some internal details need some polishing, but the public API should stay the same)
Of course. I suppose I should have been explicit to mention things are "system/data-structure ordered" not "key ordered". Any iteration has "an" order, though. That weird order just may or may not be what is desired or it might be fine.
In terms of your sorta/B-Tree I would say that (like most fledgling ordered tree implementations) it does not separate "seeking" from "updating" (inserting/deleting). Search trees are often even more useful when augmented. Augmented search trees allow multiple kinds of (useful) order. E.g., B-trees need merely one more number per already large node and a little extra maintenance of that number to support seek-by-rank as well as seek-by-key (thus morphing into an order statistics tree). So, a better design is one organized around a "path handle", e.g., path: seq[tuple[ptr,index]]. Seek-by-X procs can populate said path, updating procs can act upon it, and iterators can start from whatever kind of seek with next/prev updating some path handle. Done right the augmentation can be totally optional, decided at instantiation-time. Layering a more traditional Table-like interfaces on top of that path-oriented internal design is then much easier than trying to implement everything directly.