victosvertex / flatland-asp Goto Github PK
View Code? Open in Web Editor NEWApplication of Answer Set Programming to the Flatland environment
Application of Answer Set Programming to the Flatland environment
Currently ASP instance generation/storage is part of the core capability of FlatlandASP. This makes sense, as it works with basic structures and generating instances from an environment is a fudnamental functionality required for the project to even be functional.
However the same could be said about environment generation/storage, which currently resides in the environments feature.
This seems inconsistent and should be changed. Either both are part of separate features (ASP instance generation could be part of the solver) or both are part of core.
This error message is just annoying.
In order to save custom maps, for example created in an editor, an endpoint to save them is necessary.
This endpoint should accept very specific input.
Because of the shift towards an API, the FlatlandASP class can be split into a solver and a simulator.
Each of these end up as separate features:
There should be an endpoint to load an environment and display its data.
This may require separate endpoints for json and pickle.
environment_crud so far only provides the ability to load directly from pickle or load EnvironmentData, it should be possible to load environmetns from json just like from pkl. Maybe add an optional parameter for agent variability and a custom line generator.
The asp instance generation should be completely independent of the encoding. Thus a minimum instance description should be provided that only describes the flatland environment in terms that are a direct representation.
Suggestion:
An endpoint should exist that tries to solve a specified environment with a specific encoding
The calculated horizon Flatland provides can be too small under certain circumstances as it ignores collisions which may force trains to take way longer paths than the shortest ones.
Thus a way should be added to set the limit manually in case it doesn't fit (or find a better formula)
The user should be able to view models, paths, actions, statistics etc. of any already found solution.
To achieve this, the solution has to be uniquely identifiable.
One way could be, to simply add environment_name, encoding_name and number_of_agents into the file name of the solution. This approach would however result in potentially very large urls if the name is used as a query parameter.
Another approach could be to instead take these parameters, hash them to some fixed length and use this hash as a unique identifier.
A file could be added which stores hashes and their respective configurations.
Calling .reset() on Flatland environments inside of the solver and simulator introduces a side effect that's hidden for outside viewers.
Instead the call to reset should be done after instantiating the environment and the already reset environment should be provided to both, solver and simulator.
Recently an error occurred in a similar project (actually the error occured twice in different ones) because the developers did not call .reset(). They then tried to find help in my project, but since the call to .reset() was hidden, they - and I myself after investigating their problem - spent too much time realizing that all that was missing was a simple .reset() call. If that call was outside the classes instead of in their initialization methods the solution would've been immediately obvious.
Since the project changed from being a package (because it was too small and meaningless) to an application (in the form of a backend API) the user now should be presented with information on how to run and interact with it.
Wiki pages should be updated with more information about the ASP instance and encoding, especially the thought process behind each element.
Test and benchmark environments are helpful in finding better encodings and ensure that they work at each iteration.
A custom logger config would be beneficial as it can show which module has logged which messages, granted logging modules create a new logger with a name.
Some files got pushed that are no longer in use or shouldn't have been pushed in the first place. They should be removed to clean up the project.
After the change in project structure due to the /data/
directory the README is no longer accurate.
Because of the future introduction of an actual base instance that is independent of encodings, thus only provides the actual minimum data, the old BaseInstance is no longer the base.
It should be considered to completely rework the instance generation because if the instance is independent and only a single one is used, then the entire concept of multiple instance formats is not of any use.
The name is just too long at the encoding is basically the current main encoding for all maps, not just for passing siding maps.
Currently the solver seems to have too many (and apparently confusing) side effects.
.lp
to encoding name which actually already caused confusion when someone used the projectThe class so far seems like a mix between an abstraction over clingo/flatland and not being one. I think the class should be either changed to be a real abstraction (probably no clingo control as input, fixed subset of allowed parameters) or to not be one at all.
.lp
inside the solverIf all suggestions are implemented, the solver would just use normal clingo functionality such as adding the encoding to the clingo control, ground and solve. The only actually useful functionality left would be the extraction of the last model/solution data. So instead of a solver this just is a callback container.
main.py should be the entrypoint of this application, it should only be concerned with setting up the necessary basis like api with routers and actually run the server.
In the last added environments the sparse_line_generator
can't find a proper orientation because all city orientations are set to 0.
To solve this the proper city orientation should be supplied. This requires a corresponding issue in FlatlandASPView.
All maps should be replaced with versions using proper orientations.
Implement endpoint that shows all currently loadable environments.
Feature router is missing, needs to be committed.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.