Skip to content
This repository has been archived by the owner on Oct 31, 2020. It is now read-only.

Consolidate auxiliary information about nodes into getData/setData calls #393

Open
tcstewar opened this issue Apr 16, 2013 · 5 comments
Open
Assignees

Comments

@tcstewar
Copy link
Contributor

The idea here is to get rid of the bizarre global variables that serve to associate some sort of information with a particular node in the network. In particular, we have

hrr.Vocabulary.registered
timeview.watches.FuncRepWatchConfig.config

which can both grow without bound, and have no way of removing elements when a network is closed.

This capability would also be able to get rid of the setDocumentation abuse that happens in spa.bg and spa.thalamus

Another use case is storing the x/y/z location of a node

This system should also have an interface to the nef API, allowing something like:

net.data('node')['info'] = whatever
...
something = net.data('node')['info']
@ghost ghost assigned tcstewar Apr 16, 2013
@tbekolay
Copy link
Member

Sounds like a good idea. Can I propose that we call it metadata and not data?

@tcstewar
Copy link
Contributor Author

Sure, that works for me. The java object interface would be something like

obj.setMetadata("key",value);
value = obj.getMetadata("key");

and the nef API interface will be

net.metadata('name')['key'] = value
value = net.metadata('name')['key']

For simplicity, if you ask for metadata that is not set, you get None (or null) as a response.

@tbekolay
Copy link
Member

So metadata finds a dict attached to a node? Would a node-centric implementation make more sense than a network-centric one? I.e.,

net.get('name').metadata['key'] = value
value = net.get('name').metadata['key']

I'm not really attached to either way, just putting it out there for discussion.

@tcstewar
Copy link
Contributor Author

That would be an option, but I don't think there's a decision yet as to what net.get('name') should return. Basically, if we include net.get() as part of our API, then we have to define an API for what functions are expected to be callable on that returned object, regardless of whether we're using the Java or Theano or whatever version. Personally, I'd prefer to not have net.get() and to not have net.make* return anything at all. But that's a whole other discussion. :)

@tbekolay
Copy link
Member

Hah, yeah for sure 😄 Friday's discussion!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants