Empirical
|
Create an ActionDefaults class that can take fewer args than expected and fill in rest.
Allow for named arguments to facilite intepreted functions.
Setup easier mechanism to control the order in which actions are triggered.
Signals should have default parameters so not all need be supplied when triggered.
Add tests in array::front and array::back to ensure not empty.
Add tests for get.
Should we save a copy of the original genome? (or create a new "memory" member)
We should clean up how we handle scope; the root scope is zero, so the arg-based scopes are 1-16 (or however many). Right now we increment the value in various places and should be more consistent.
How should Avida-GP organisms take an action? Options include sending ALL outputs and picking the maximum field; sending a single output and using its value; having specialized commands...
We should clean up how we handle scope; the root scope is zero, so the arg-based scopes are 1-16 (or however many). Right now we increment the value in various places and should be more consistent.
Implement append(), resize()...
Implement techniques to push bits (we have pop)
Implement techniques to insert of remove bits from middle.
Allow a minimum and maximum combo size, not just a fixed combo size. If no sizes are specifed, all sizes should be explored (all possible combinations).
Create a ComboGenerator template to take a container and generate all combinations
Create a combos function that will build a ComboGenerator for the container type passed in.
Events can be further sub-divided and built up (similar to DataNode objects) so that we save only the information that we're planning to use. This may be slightly faster (given how frequently some of these like mouse move might be used), but likely to be more compelx.
An alternative speed-up might be to save the current event somewhere in emp_i on the Javascript side, and then just request the information that we might need. This approach should be easier to implement, but since everything would be copied anyway in such as case, it might not actually be a speedup.
Convert to a template that acts as a glorified vector, simplifying random selection?
Should operator[] index by element count or by weight?
Add a JSWrap that takes an object and method and does the bind automatically.
Build a non-enscripten version; it should still be callable from the C++ side, but mostly to be able to test programs without Emscripten.
We need to standardize how we handle macros that covert inputs to comma-separated results vs those that merge them together. One option is to have comma-separated the default and then have an EMP_REMOVE_COMMAS (or somesuch)
EMP_TYPES_TO_ARGS (not yet listed above) is poorly named. Maybe EMP_DECLARE_ARGS?
It would be useful to have EMP_WRAP_WITH_ID which passes in the position ID as the second argument. This would allow us to, for example, streamline EMP_TYPES_TO_ARGS.
A more generic EMP_WRAP macro that is specified on the fly. For example: EMP_WRAP(W,2,4,A,B,a,b,c,d,e,f,g,h,i,j,k,l) would assume six args in each wrap, A, B, and the rest broken into groups of four. I.e.: W(A,B,a,b,c,d), W(A,B,e,f,g,h), W(A,B,i,j,k,l)
Add Hash for boards to be able to cachce moves.
Setup OPTIONAL caching of expensive board measures.
Add Hash for boards to be able to cachce moves.
Setup OPTIONAL caching of expensive board measures.
Patterns should include functions that are called when that point of rule is triggered.
Make sure to warn if a symbol has no patterns associated with it.
Make sure to warn if a symbol has no path to terminals.
Make sure to warn if a symbol is never use in another pattern (and is not a start state)
Should we change Parser to a template that takes in the type for the lexer?
Should we save a copy of the original genome? (or create a new "memory" member)
We should clean up how we handle scope; the root scope is zero, so the arg-based scopes are 1-16 (or however many). Right now we increment the value in various places and should be more consistent.
How should Avida-GP organisms take an action? Options include sending ALL outputs and picking the maximum field; sending a single output and using its value; having specialized commands...
Track information about emp::vector and emp::array objects to make sure we don't point directly into them? (A resize() could make such pointers invalid!) Or better, warn it vector memory could have moved.
Get working with threads
Need to implement ^ and $ (beginning and end of line)
Need to implement {n}, {n,} and {n,m} (exactly n, at least n, and n-m copies, respecitvely)
Build custom load/store function for more STL objects (especially containers)
To deal with pointers we should recurse, but keep map to new pointer locations.
Setup a more robust method for dealing with arbitrary strings so we don't have to worry about collisions in streams (JSon format??)
Setup a (compressed) binary save formmat in DataPods in addition to JSon.
Setup promised synergistic interactions with config and tuple_struct to auto store and load without any additional effort on the part of the library user.
Functions such as Load() should throw exceptions (or equilv.), not use asserts.
Need to figure out a default mapping for how outputs translate to moves around a state grid. -1 = Back up ; 0 = Turn left ; 1 = Move fast-forwards ; 2 = Turn right
Allow StateGridInfo to be built inside of StateGrid (change reference to pointer and possible ownership)
Technically, we don't need to keep the ancestors in a set in order to track a lineage... If we delete all of their descendants they should automaticaly be deleted.
We should provide an option to back up systematics data to a file so that it doesn't all need to be kept in memory, especially if we're only doing post-analysis.
This inheritance system makes adding new systematics-related data tracking kind of a pain. Over time, this will probably become a maintainability problem. We can probably make the whole inheritance thing go away through judicious use of signals.
This does not currently handle situations where organisms change locations during their lifetimes gracefully.
Tables should more directly manage internal slates rather than just adding divs and then having them filled in.
TextTables should be created that simply use text in cells, radically speeding up printing of such tables (and covering 80% of use cases).
IDEALLY: Make a single table that will look at what each cell is pointing to (table or text) and write out what it needs to, in place.
Add a ClearColumn method, as well as other column functionality.
Add an operator[] to table that returns the appropriate row (and one to row for cell).
Need to setup an AddPath that actually uses widgets and properties (stub in place).
Need a Reverse(), which swaps start and end positions.
Need a Reset()
Should use std::is_convertible<X,Y>::value to determine if casting on base type is allowed.
Functions should be able to have fixed type values mixed in.
Convert to a template that acts as a glorified vector, simplifying random selection?
Should operator[] index by element count or by weight?
Make sure when mutations occure before placement into the population we can control whether or not they also affect injected organisms. (Right now they alwyas do!!)
We should Specialize World so that ANOTHER world can be used as an ORG, with proper delegation to facilitate demes, pools, islands, etc.
We should be able to have any number of systematics managers, based on various type_trait information a that we want to track.
Add a signal for DoBirth() for when a birth fails.
Add a signal for population Reset() (and possibly Clear?)
Add a feature to maintain population sorted by each phenotypic trait. This will allow us to more rapidly find phenotypic neighbors and know the current extremes for each phenotype.
Add a const interator.
Currently we do MakeValid after every change AND before many accesses. Pick one?
Fix operator-- which can go off of the beginnig of the world.