Make index_table a Vector{Vector{UInt128}}, and add tests

[lbenet]

This is a small modification addressing [#85]. It simply carries
on the hashing of the vectors of integers in UInt128 arithmetic.

[dpsanders]

This will slow down (I would guess by rather a lot) every single calculation with the package.
It will also have its own upper bound on the number of possible variables.

I think a better solution is the one I posted in #85 (comment)

although that will require more work to make everything type stable again.

[coveralls]

Coverage remained the same at 97.147% when pulling 6e27470 on index_table into 99a4d8e on master.

[lbenet]

This will slow down (I would guess by rather a lot) every single calculation with the package.
It will also have its own upper bound on the number of possible variables.

Both statements are correct. Running perf/fateman.jl with Julia v0.5 yields almost a factor ~1.7 slower if #86 would be merged, though (interestingly) no more allocations. (Using Int128 instead of UInt128 yields essentially the same results.)

I think a better solution is the one I posted in #85 (comment)
although that will require more work to make everything type stable again.

I also agree with this. Yet, this is quite tricky, since the choice must depend on the values.

A possible approach could be to define a (global) parameter which fixes the parameterization of generate_tables{T} and in_base{T}, which eventually defines the type of index_table. Throwing an error message would also be nice, but I'm not sure how to do that.

[lbenet]

@PerezHz The performance hit is important, and as @dpsanders states, it is not common to have situations where the used hashed numbers is so important. I suggest that you use the branch "index_table" to get access to what has been done here.

[dpsanders]

I think we should move away from any kind of global table. Then each Taylor polynomial can store a reference to an object of the relevant type / size.

[lbenet]

I agree that we should look for alternatives (including moving away from the global table scheme), but if such alternatives involve memory overhead, I don't think that's the way to go.

[lbenet]

I closed this, push -f the corresponding commits adapted to the new organization of the files (#87), and keep this open, in case it may be needed.

[coveralls]

Coverage remained the same at 97.579% when pulling e1c624b on index_table into 0a91842 on master.

[coveralls]

Coverage remained the same at 97.579% when pulling e1c624b on index_table into 0a91842 on master.

[PerezHz]

Thanks @lbenet and @dpsanders for the work you are putting into this; it is helping me a lot! Perhaps a note should be added in the documentation regarding the fact that TaylorN works with at most 65 variables and if more are needed then the current solution is to use the index_table branch?

[coveralls]

Coverage remained the same at 98.251% when pulling b7966f6 on index_table into 88f2fe9 on master.

[coveralls]

Coverage remained the same at 98.274% when pulling 3a4d4a4 on index_table into 4a40685 on master.

[coveralls]

Coverage decreased (-1.5%) to 96.552% when pulling 8766c58 on index_table into d4f0c20 on master.

[lbenet]

Addressed by #314 and #316