Remove unused encoders

[scottpurdy]

Remove the following encoders:

• [x] ArithmeticEncoder - I wrote this but it isn't clear that we want to encourage adaptive encoders
• [ ] AdaptiveScalarEncoder - RDSE is better
• [x] SDRRandomEncoder - don't understand utility of this
• [x] NonUniformScalarEncoder - again, not sure we want to encourage adaptive encoders
• [x] ScalarSpaceEncoder
• [x] VectorEncoder - just wraps multiple encoders
• [x] UtilityEncoder - functionality is outside the scope of encoders

[wilsondy]

I'm kicking off a port of the BitmapEncoder for the htm.java project. I saw some discussion about extending The PassThru to implement Bitmap. Any comments on whether that will be done on the Python side ?

https://github.com/numenta/htm.java/issues/93

[scottpurdy]

@wilsondy - I think it likely will. I will take a look right now

[scottpurdy]

@wilsondy - See #1502 - still needs to go through the review process and such though

[breznak]

I might need to revive VectorEncoder some time soon, try encoding a 10000 values list with multiencoder - it will hog the RAM and I cant see how you manually initialize the encoder.

[david-ragazzi]

Hey.. where's Wilson??

(Ok.. Not funny at all)

[scottpurdy]

@breznak - Thanks for letting me know. I'm having a hard time deciding whether I think that is a useful general purpose encoder. Perhaps you can just have it in your codebase? Or does it have to be in the NuPIC codebase for some reason (like if you want to use it in the OPF)?

You could also do the encoding separately and use the pass through encoder.

I am open to putting it back in if it is going to be useful for you though so let me know.

[breznak]

One more candidate pair: CategoryEncoder vs SDRCategoryEncoder - their description is exactly the same, with note that implementation differs, probably we could choose a better one then.

[david-ragazzi]

I'm having a hard time deciding whether I think that is a useful general purpose encoder.

Following this reasoning of general purpose encoder, I think that BitMapEncoder/SparsePassThruEncoder could be discarded in favor of PassThruEncoder as the latter already handle pure arrays of 0's and 1's in a more intuitive fashion.

[scottpurdy]

@breznak - I originally agreed on Category vs SDRCategory but Subutai pointed out that SDRCategoryEncoder is much better for production while it is still nice having CategoryEncoder for debugging since it is easier to visualize. Essentially the same reason as the ScalarEncoder vs RDSE.

Does one of my suggestions work for your use case or do you think I should bring the vector encoder back in?

[scottpurdy]

@david-ragazzi - I agree that PassThroughEncoder is more intuitive. But in the case that you have sparse arrays, it may be much more efficient to use the SparsePassThroughEncoder. No one at Numenta is using either AFAIK so this is just speculation that it will be useful. If no one else is using it then open to taking it out as well.

[rhyolight]

Not much traction on the last few encoders to remove, so I'm moving to 0.2.

[rhyolight]

@scottpurdy ping

[scottpurdy]

@rhyolight What is the action item for me?

[rhyolight]

@scottpurdy Remove the AdaptiveScalarEncoder? I figured you weren't done, since you assigned to yourself and did all but one task.

[scottpurdy]

@rhyolight Right, yes that is still remaining. I'll want to check with people to make sure the alternatives are sufficient. Not a priority right now.