Identifiers - makingthematrix/gailibrary GitHub Wiki

Everywhere in the pseudocode I use strings as identifiers. It would work in real code if I wanted GAI to be used only in Rust. GAI could work on string references which are quick to compare. But as soon as the user starts to register new identifiers dynamically, be it through external API (C, Lua, ...), or even in Rust, but through operations on string objects (because why not), GAI will be forced to compare strings by content. So I think it will make much more sense to have identifiers as integers and an Identifiers class to register them. At registration, the new id will be associated with a string constant. Each method using identifiers will eventually have a complementary method (a macro?) using the string equivalent of the id, so it will be possible to use strings for better readability first, and then to replace them with integers in the production mode.

let HEALTH = GAI.ids.reg_value("health")
npc.get_d("health")// works only in debug
npc.get(HEALTH)    // both in debug and production

Also, this way it’s easier to keep identifiers unique. FunctionId and ValueId have to be interchangeable anyway (because lazy vals and variables are created with ids equal to ids of functions which computed them), but even if GraphIds are not interchangeable with them, it’s better to keep them unique and prevent confusion.

It’s easy to see that there will be a lot of operations on sets of identifiers during GAI calculations. As far as I know Rust supports a small collections library with only the most basic operations on sets possible. For example, adding two sets result in a collection of references to the values, not copies of values. That’s good if I wanted to manipulate bigger data structures, but in this case it just forces me to perform additional operations to obtain a new set of ids. Eventually I decided to write my own implementation of a set of integers - USet. I used another project rust-experiments to compare it to the default HashSet and to the version from the im crate. USet came on top, leaving im::HashSet far behind, and being 3x faster even from the default HashSet. I'll use it for now, and later decide if I want to go back to the default implementation.

I’m thinking about either finding a better suited crate or implementing one myself, trading universality for simplicity and speed. The number of all ids in GAI will probably never be bigger than a few thousands, so a set and a map could be implemented as vectors. In the case of a set itwould a vector of booleans (if the id is there, the corresponding entry in the vector is true); in the case of a map - a vector of references to values.

Graphs <- | -> GAI main classes