More examples? about ai-toolbox HOT 11 CLOSED

I'm saying this because it would be really nice to have an example POMDP application, since by using template-ization so much the code is more difficult to understand.

from ai-toolbox.

The things missing to arrive at release 1.0 are:

• Adding a bunch of consts around the code
• Adding and improving existing examples

So yeah, it's definitely in-the-works. In the meantime you could check out the tests if you need some guidance. Feel free to make up more tests/examples as you go along! If you have a cool idea for an example, but you need help in making it work, just open an issue and I'll try to help you out.

from ai-toolbox.

Thank you for the information. I took a look at the test folder and now everything is much clearer 😄

On this topic, I have two questions:

1. Why didn't you add the test/POMDP/Utils/TigerProblem.hpp in the examples folder? It seems to me that that code is pretty much what would be needed to provide a tutorial on POMDPs.
2. Why didn't you add also the test folder to your CMakeLists.txt ? It would be much better to have everything compile-able from the build folder. Also, it would be easier to add POMDP code which needs additional libraries to link such as lpsolve

from ai-toolbox.

1. Not sure, I didn't think it was an example interesting enough. I suppose that can change.

2. Tests are in fact automatically compiled together with everything else. See the last line in the global CMakeLists.txt:

   add_subdirectory (${PROJECT_SOURCE_DIR}/test)

   To try out the tests you just have to call ctest in the build directory.

from ai-toolbox.

1. Agreed, but by lacking better examples, that could suffice 😄
2. Sorry, I had a typo. I meant: why didn't you add also the examples folder to your CMakeLists.txt? 😄
3. Also, I have seen that your tests are compiled into the test/bin folder. Is there a reason for that? Usually not being consistent with where executables and libraries go is an anti-pattern: if I have the build folder I would expect everything to be built in there.

All of these are very minor things, and you didn't probably think about them before. I'm asking them because I would like to contribute to the repo, since I think it's a promising project!

from ai-toolbox.

Well, some people don't really care about the examples and may not want to compile them, saving some time. I prefer to leave the test in just in case something does not work, so one could ask to run the tests just to see if everything is working.

For the tests, you are right. I mostly put them there due to my personal convenience. Sometimes a test does not work, and I'd like to compile just that one and test it alone. Rather than scavenging them inside the build folder (they would get created in a folder a bunch of levels deep) or having to remember each time what is the specific test to pass the parameter to ctest (if that even works), I opted for the easier solution of just putting the executables in that folder. It's kind of a cheap solution, I know, but it kind of worked for me. Maybe putting them in a tests folter inside the build directory could be a better solution. I had to fight a bit with ctest though at first to get it to find the executables so I didn't try to change it again. If you feel like trying feel free to!

Thanks for the kind words! In general I appreciate patches that improve usability of the library (like these modifications we have been discussing about CMakeLists.txt and so on), while I'd like to at least try to implement new methods myself (as long as I find them interesting, otherwise patches are welcome). This is because, as I said, I try to use this project a lot as a learning project, so the more I get to implement myself the more I'm happy. So if you're interested about some specific thing feel free to ask, and we can decide whether I'd like to try first to add it to the library or not.

Additionally (I'm going to copy-paste half this post soon in a CONTRIBUTE.md file) if you end up implementing a method I'll probably have to ask you to sign a CLA. Maybe one day I'll get to use this in a job or something and I'd love not to have licence problems for that (the library itself will always remain GPL'd though).

from ai-toolbox.

@alecive I have thought a bit about the CLA and I think it would actually not be a good idea. I didn't have time today to finish the CONTRIBUTE.md file, but the jist of it remains the same - without anything to sign =)

from ai-toolbox.

Well, some people don't really care about the examples and may not want to compile them, saving some time. I prefer to leave the test in just in case something does not work, so one could ask to run the tests just to see if everything is working.

I would put a flag MAKE_TESTS and MAKE_EXAMPLES, so that the user is free to choose. In particular when developing, it may be cumbersome to have to compile all the tests every time you want to build the code. If something does not work, it's only one flag away 😄

I had to fight a bit with ctest though at first to get it to find the executables so I didn't try to change it again. If you feel like trying feel free to!

I'll try 👍

So if you're interested about some specific thing feel free to ask, and we can decide whether I'd like to try first to add it to the library or not.

We can talk about that in #7, am I right? Anyway, that will happen only after I find enough time to be confident with your code. FYI I would be specifically interested in multi-agent MDPs.

Additionally (I'm going to copy-paste half this post soon in a CONTRIBUTE.md file) if you end up implementing a method I'll probably have to ask you to sign a CLA. Maybe one day I'll get to use this in a job or something and I'd love not to have licence problems for that (the library itself will always remain GPL'd though).

No problem whatsoever on this, whatever works best for you for me is fine :)

from ai-toolbox.

Those flags make sense. I though that maybe making things too complex with too many flags could be a hindrance to a new user that just wants to cmake/make to get going, and instead sees a bunch of random flags in the README on how to setup. Maybe the flags could deactivate stuff rather than activate it, not sure.

There's another advantage in automatically compiling the tests when writing code: since a lot of the library is templatized, a lot of errors are caught only when a class or template method are actually instantiated. Since tests do just that, they catch automatically a lot of compilation errors you wouldn't see otherwise.

In #7 you can definitely propose papers that should in general be included in the library. If you wish to discuss whether you'd like to implement a particular one I suppose you could open a separate issue, to avoid cluttering that one.

About the CLA point, I don't think I'll have it, but I'm asking a couple people about opinions on what could be best. Maybe just something like the http://developercertificate.org/ (as used by Linux to accept patches) and having people sign commits should suffice. I'm not sure whether we should bother, though.

from ai-toolbox.

Maybe the flags could deactivate stuff rather than activate it, not sure.

Yes they can. But simply having a MAKE_ALL (as you already have) to compile everything would be sufficient for the casual user. It's only a matter of adding more flags inside MAKE_ALL.

Since tests do just that, they catch automatically a lot of compilation errors you wouldn't see otherwise.

Totally true. But this is what Travis is for, isn't it? If you have a CI server that does all the dirty job (compiling + testing your code), you don't have to force your users to spend time in compiling tests and running them unless some issue arises. On Travis you can enable tests, but by default you can keep them disabled.

In #7 you can definitely propose papers that should in general be included in the library. If you wish to discuss whether you'd like to implement a particular one I suppose you could open a separate issue, to avoid cluttering that one.

Sure 👍

About the CLA point, I don't think I'll have it, but I'm asking a couple people about opinions on what could be best. Maybe just something like the http://developercertificate.org/ (as used by Linux to accept patches) and having people sign commits should suffice. I'm not sure whether we should bother, though.

I'm fine with it, it's up to you 😄

from ai-toolbox.

Closing this. It diverged enough away from its original purpose 😄

from ai-toolbox.