aatxe / markov Goto Github PK

markov 0.0.30 has a 11MB log file in its cargo package source. Consider releasing a new clean version.

This is a reminder that cargo includes all non-ignored files in your working directory when you publish — look at git status before you publish.

(I downloaded all crates.io crates and I started to grep for junk)

Hey,

I'm working on a fitting a model to user behaviour data and was wondering how the data is structured inside this library. Specifically, I wonder how you deal with n-tuples: if you have a state s1, s2, s3 and s4, how is the chain s1 -> s4 stored?

I found multiple naive implementations (not this) that were actually just tuples: s1 -> s2, s2 -> s3, which isn't exactly accurate. Maybe you could outline the architecture of this library in a few words in the readme?

Thanks 🍻

Rust-ci.org appears to have its domain scooped up and parked at some spam site. Maybe consider moving the documentation somewhere else?

ce148e1 caused regression.

I currently use it in my Tox markov bot, and I would be very sad ( :c ) if I had to rewrite that stuff.

src/main.rs:148:11: 148:27 error: no associated item named `load_utf8` found for type `markov::Chain<_>` in the current scope
src/main.rs:148     match Chain::load_utf8("markov.json") {

Will there be a replacement?

Also, documentation should be updated, since it's no longer possible to use this functionality in 0.0.30

If you attempt to load a previously saved chain where one of the tokens is >= 128 characters, the yaml parser throws an error that the key does not exist. Saving the chain to yaml does not have this problem.

I don't think this will be easy to fix, since the problem lies with the limits of yaml. Instead, either in feed or save, I believe an error should be thrown to prevent unloadable chains from ever been saved.

I'd like to move this project into the public domain. The following is a log for future reference of @retep998 granting me his IP rights over his contribution in order to allow the license transfer. This conversation took place in #vana on irc.fyrechat.net.

[20:30:32]  <awe>   SpaceUnicorn: Can you confirm that you're okay with my switching markov from MPL to Unlicense?
[20:30:49]  <awe>   SpaceUnicorn: Also, will you sign a CLAHub public domain declaration on behalf of your contributions?
[20:31:31]  <%SpaceUnicorn> awe, I transfer all copyright of my contributions to your markov thing to you
[20:31:43]  <awe>   Okay, thanks.
[20:31:57] SpaceUnicorn has userhost [email protected] and real name "realname"

We need to do some custom serialization here. JSON has forced constraints like specifying a start/end marker and is incompatible with higher-order chains as implemented by @BenBergman. The reason for this is that in JSON, the only valid object key is a string. So, we'll need to implement our own format to serialize it to (or find another existing format that works better).

As it is, I can't use Chain in a threaded context because it uses Rc internally (hence, Sync is not implemented). I'd very much like to be able to use it in a threaded context, so I was hoping you could find a way to make this lib thread-safe (through Arc or something).

When I have a Chain with an order of 2 or higher, a token should be a Vec if I'm getting this right.

Since generate_str_from_token only accepts a &str and never converts that to a Vec, it's impossible for generate_str_from_token to succeed in this scenario, as far as I can tell.

Have I gotten something wrong? If so, how do I use this method on a Chain of order 2+? If not, is this intended behaviour or a bug?

Thanks for the great work on this library!

as far as I understand the code if I feed then change order then feed again the first feed are unattainable states.

The solution is to ask the order in the new method

The Unlicense is a bad public domain license, as it does not care about different juristdictions at all. Current reading is that using code under Unlicense is a copyright violation in Germany, for example (and all other countries where you get certain unwaivable rights granted by default).

See http://projects.opensource.org/pipermail/license-review/2012-January/000052.html for an explanation.

For that reason, the GNU project recommends using the CC0 instead. https://www.gnu.org/philosophy/license-list.html#Unlicense

IANAL, but I'm also sure that I cannot sign the CLA were I intending to commit to this project.

Generating a graph of a chain with chain.graph() on string data produces the following structure:
petgraph::graph_impl::Graph<Vec<Option<std::string::String>>, f64

This does not seem to play nicely with petgraph bounds.

Looking at this example from your repo the code appears to require a petgraph feature which is no longer present (as of petgraph 0.6.3).

Notably, {:?} printing of the graph structure does produce valid seeming data and the markov production process with the chain appears to work appropriately. So the underlying data appears to be mostly correct.

(Great tool btw!)