-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New class BaseEncoder #314
Conversation
I opinion is that if an encoder has state that would affect the outcome of a subsequent cycle then that state should be serialized. It could be argued that incoming data is not state because it is not the consequence of previous processing. I would think that most encoders are stateless. The configuration parameters in the NetworkAPI have been included in serialization for everything although I question if it should because it 'normally' is not the consequence of previous processing...perhaps a topic for a separate discussion. |
+1, serialize. For stateless (most?) encoders, this should be trivial. It is convenient that later the whole algoruthm/NetworkAPI network can be serialized. |
OK, I will make it serialize. Another reason to want serialization is that many encoders are initialized using a random seed, which is not stored anywhere. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, thanks!
Please add the Serializable,
I'm still not sure about the decode(), but that can be added later.
That would qualify as a state. So yes, it should serialize. |
I'd like to take the time with this PR to clean up the
|
That sound reasonable. ScalarEncoder would be a good place to try out the new base class. |
Also reorder sections of code, minor docs change.
I have NOT yet tested this!
e5b311d
to
e1163fe
Compare
Serialization keeps 6-digits, so check 5-digits of accuracy.
a65b78d
to
405b5f8
Compare
I finished implementing the new API in the ScalarEncoder and debugging it. Now it fails because of the network API & regions, which I thought I updated correctly but are failing their unit tests. I don't really understand how the networkAPI works, and I don't have any experience debugging it. Any help would be appreciated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good base for the encoders! 👍
A few more known TODOs and some my comments.
Looks good and hope we can merge this soon
tEnc.stop(); | ||
for(auto i = 0u; i < inputSDR.size; ++i) { | ||
input[i] = (UInt) inputSDR.getDense()[i]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit, you could use VectorHelpers::castVectorType<Byte, UInt>(inputSDR.data()) as used on other places of this PR.
PS: I'll be trying to avoid that by templating the SDR_dense_t 's datatype in SDR in another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be far easier & better to overhaul this example to use SDRs throughout.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once encoders support SDR, it should go there. So it could be part of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed you are creating a fourth extension library for encoders.
Would the .py code be expecting to find the encoders in a separate extension library?
I would think they would be part of the algorithms library. If you think it makes since to do that then ok but you have some more files to change for deployment.
- packaging/setup.py
__init__.py
- and probably some others.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Numenta Platform for Intelligent Computing (NuPIC)
* Copyright (C) 2018, chhenning
* 2019, David McDougall
*
* This program is free software: you can redistribute it and/or modify
I don't think we can change the copyright. There is a standard for what the copyright should look like. We can add our name after the copyright but we cannot include ourselves in the copyright.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with the fixes 👍
for me good to go, please have a look at what David was saying and we can merge
Previously python encoders existed at:
The encoders are bundled into the algorithms library, even though they have their own python module. As long as |
rhyolight answers this question at the end of this thread: https://discourse.numenta.org/t/what-is-a-community-fork/3112/10 Also: https://discourse.numenta.org/t/a-word-on-licensing/2023 There is an important distinction between copyright and a license to use the copyrighted work. We absolutely can not change the license. This all must be published under the Affero GNU Public License version 3. However, I own the copyright for all of the things I've written. If someone was paying me to write this code, then as part of our contract they would own the copyright. We can't change the copyright of the existing code, since we did not write it. If we edit existing code then we gain the copyright for the portions which we add. |
BTW: You're welcome to retroactively add your name to the copyright notices of the files you've added or improved :) |
I stand corrected. I worked for years as a software contractor where our contract specifically say we have NO rights and we cannot put our name on anything. When I signed the contributor agreement I assumed it contained similar wording but I do not remember if I actually read all of the fine print. Apparently a contributor does have some rights. Cool. |
I'd like to merge this PR so that other tasks can move forward (#291 #278 #304, probable merge conflict with #320). It's not 100% done yet. Here is a checklist list of the remaining tasks which I will post to issue #258 Encoders in C++. Outstanding Tasks for ScalarEncoder:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Thanks for a proper base design for encoders, and fitting it with the existing.
I'm good to merge 👍
Oops. I forgot about that change and I misunderstood your comment. I just made one last commit to include the The reason I added a fourth extension library was to make it show up in the python module hierarchy like it does now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think you have all of the parts now. Looks good.
I assume that each encoder will have its own Region implementation for NetworkAPI. Is that correct?
I think so! |
See issue #291
TODO:
getWidthWon't fixencodeIntoArrayWon't fix