I'm a newbie in both deep learning and tensorflow and now trying to learn how to implement deep learning codes based on function API (not keras) by following example codes.
Inside the codes I'm looking at, I found out sources saying 'gradients=tape.gradient(loss,model.trainable variables)'
I intuitionally got what trainable variables mean, however in order to understand clearly,I tried to search on tensorflow documentation (which module or class the method belongs to, which are key arguments, etc) ,but I wasn't able to find the information I want. ('trainable variables' method was not in their documentation index and I'm wondering why)
So can anyone please tell me the module/class which trainable_variable method belongs to, and which arguments it takes, and also how it is able to judge and get all the trainable variables from the model ?
The reason you did not find this method is because trainable_variables is not a method, but an attribute/property. The Model class has a trainable_variables attribute, which is not documented officialy. It is inherited from the base class Layer, and to put it shortly, the list (of trainable variables) gets populated as new layers are added, since all layers have an init parameter trainable (this comes from base class Layer too). You can check the source code if you want to: "the source of the property", "adding new weights to layer appends to the list".
Related
I am trying to find a clean way to access the regmap that is used with *RegisterNode for creating documentation and testing files. The TLRegisterNode has methods for generating the json through some Annotations. These are done in the regmap method by adding them to the ElaborationArtefacts object. Other protocols don't seem to have these annotations.
Is there anyway to iterate over the "regmap" Register Fields post elaboration or during?
I cannot just access the regmap as it's not really a val/var since it's a method. I can't quite figure out where this information is being stored. I don't really believe it's actually "storing" any information as much as it is simply creating the hardware to attach the specified logic to the RegisterNode based logic.
The JSON output is actually fine for me as I could just write a post processing script to convert JSON to my required formats, but I'm wondering if I can access this information OR if I could add a custom function call at the end. I cannot extend the case class *RegisterNode, but I'm not sure if it's possible to add custom functions to run at the end of the regmap method.
Here is something I threw together quickly:
//in *RegisterRouter.scala
def customregmap(customFunc: (RegField.Map*) => Unit, mapping: RegField.Map*) = {
regmap(mapping:_*)
customFunc(mapping:_*)
}
def regmap(mapping: RegField.Map*) = {
//normal stuff
}
A user could then create a custom function to run and pass it to the regmap or to the RegisterRouter
def myFunc(mapping: RegField.Map*): Unit = {
println("I'm doing my custom function for regmap!")
}
// ...
node.customregmap(myFunc,
0x0 -> coreControlRegFields,
0x4 -> fdControlRegFields,
0x8 -> fdControl2RegFields,
)
This is just a quick example I have. I believe what would be better, if something like this was possible, would be to have a Seq of functions that could be added to the RegisterNode that are ran at the end of the regmap method, similar to how TLRegisterNode currently works. So a user could add an arbitrary number and you still use the regmap call.
Background (not directly part of question):
I have a unified register script that I have built over the years in which I describe the registers for a particular IP. It works very similar to the RegField/node.regmap, except it obviously doesn't know about diplomacy and the like. It will generate the Verilog, but also a variety of files for DV (basic `defines for simple verilog simulations and more complex uvm_reg_block defines also with the ability to describe multiple of the IPs for a subsystem all the way up to an SoC level). It will also print out C Header files for SW and Sphinx reStructuredText for documentation.
Diplomacy actually solves one of the main issues I've been dealing with so I'm obviously trying to push most of my newer designs to Chisel/Diplo.
I ended up solving this by creating my own RegisterNode which is the same as the rocketchip RegisterNodes except that I use a different Elaboration Artifact to grab the info and store it for later.
I'm new to om.next (and to clojurescript), and I have the following question. I can only get the root component to be invoked with the reconciler (i.e. have its query method invoked); every other component seems to need to be invoked with props and with om/factory. I think I'm missing something.
I am attempting to create a todo list app (100 points for originality!), with a filter to show completed/incomplete/all items. If my TodoList component is the root component, I can invoke it with query: [:todos] with no problem. I'd like to have a different root component, and also have a Filter component that goes through the reconciler.
Possible options I can see:
have multiple om/add-root! calls (this prevents us from having nested components that use the reconciler, and is not the pattern that I see in tutorials)
wrap everything in a global component and pass state down through props. But the examples make read a multimethod, which doesn't jive with this approach.
Is this possible? Thank you!
If you haven't already please take a look at Components, Identity & Normalization · omcljs/om Wiki · GitHub. This tutorial shows how to organize a multi-component application under a single root - and it should also make clear how read, mutate, Ident, IQuery, etc. are being used by each individual component to coordinate interaction with the one-and-only app state via the reconciler. The app-state is basically the application's database - using nested data structures inside a single Map.
React applications typically only have a single root component - if there are multiple roots they are typically organized by routes, i.e. one root per route (see also Top-level React Components — Medium).
Also: Om/Next: The Reconciler — Medium
The concept behind Om Next (and others such as reframe) is that there is one source of truth - your app state. With Om Next the UI of your application is made up of one (upside down) component tree. During rendering your app state is loaded into your Root component by Om Next interpreting its static query. This app state is received as 'props'. It is your job to pick these props apart and hand 'sub props' down the rest of the tree. You do this in the render method of each of your components.
So your second option is the way to go. reads are related to keywords that are in your static component queries. If you make sure that your state is in default db format, then in fact every read can be implemented the same way, making use of db->tree. Having a global component and making every read a multimethod are unrelated concepts, and thus not incompatible. In fact having both is quite idiomatic.
There are ToDo application examples already that you may wish to look at for reference: here and here.
One thing to note is that your Root component query will use joins to include the other components, so your query [:todos] does not look right to me. Something like [{:todos (om/get-query TodoList)}] would be better :-)
There are multiple draw_if_interactive() expressions in the pyplot module but I can't find this function's definition anywhere in the module.
From intuition and readings, it's an easy guess that the function enables on-demand plotting but where can I read its definition? Thanks.
The function is actually in the backend code. The actual implementation depends on your backend. For example the function with the TkAgg backend is in backend_tkagg.py:
def draw_if_interactive():
if matplotlib.is_interactive():
figManager = Gcf.get_active()
if figManager is not None:
figManager.show()
Same kind of functions seem to be for other backends, they use the matplotlib.is_interactive to determine if this is an interactive session and then use the backend specific drawing commands to draw the image.
I'm following the example of JTreeTable filesystem2 taken from the sun site http://java.sun.com/products/jfc/tsc/articles/treetable2/index.html#updating_the
My problem is that I can't update my model (and then my JTreeTable)...
In fact I create my model, I pass it to the JTreeTable and all work fine...but I need to modify the model...
I've yet answer a similar question, but now I've changed my code, without find a solution.
The problem is when and how I have to call the method fireTreeNodesChanged()...in the example above is used the method getPath() to retrieve information about the root node...but this is a method of File class..not my case...
Does anyone have a link to a simple code which shows how create a TreeTabelModel (with objects as nodes) and how update it?
FileBrowser is a good example of modeling a hierarchical file system as a tree. While its TreeModel is implemented using DefaultTreeModel, an alternative FileTreeModel is shown here. As mentioned in How to Use Trees: Creating a Data Model "the TreeModel interface accepts any kind of object as a tree node."
I have a tree control in my GUI (with naturally lots of GUI/platform specific functions to handle the nodes).
I have a data model with its own complex set of nodes, children, properties etc..
I want the tree to display a representation of the model, be able to send messages to the nodes inside the model and be told to redraw itself when the model changes.
But I don't want the GUI code to need to know the details of the model's data types and I don't want to pollute the model by linking it to the GUI classes.
I can't get my head around how the controller is supposed to do this and what functions it should provide?
(this is in C++ but that shouldn't matter)
GUI "controls" don't quite fit neatly into a model-view-controller pattern because they typically have their own internal model rather than accepting a reference to one. If the control is structured that way, you'll need an adapter class that "data-binds" the control's internal model to the underlying data model.
This can accomplish something similar to what model-view-controller would, except that the adapter class plays the role both of a view hookup component (updating the GUI from the data model) and a controller (interpreting GUI events into model actions).
Qt provides a group of classes for model-view programming. You can hook a tree view to a filesystem model, for example, and neither directly know anything about each other (except a pointer to the model in the view).
Your requirements are:
Tree displays representation of model
Nodes in tree can send messages to nodes inside model
Tree redraws itself based on model changes
I don't know exactly what kind of data you're working with here, but a hierarchical model is a fairly simple thing. I'll take it as a given you know how to iterate hierarchical data and populate a tree view.
Your controller should have member function(s) for sending messages to the model. The parameters should be a model element and the message you want to send. This way, the UI is completely unaware of how the message gets to the element, but can get the messages through.
The last requirement is more tricky, and depends on a few things (e.g., the lifetime of the controller, application architecture, etc.) I'm going to assume the controller lives as long as the tree view does. If that's the case, then your controller should provide a way to set a callback on model changes. Then, when the controller changes the model, it can callback to the UI without being aware of the UI.
i think your troubles start with an unfortunate choice of words. the 'control' thingies doesn't have anything to do with the 'controller' in MVC. that's why some GUI libraries use other names (widgets is a common one).
your 'tree control' is the view, not the controller. it should be tied to the GUI, both for display, and to get GUI events and turn them into 'tree events'.
the controller gets those 'tree events' and does the necessary modifications to the model. that's where you couple the 'action' with the 'response'.
First Solution: You can implement a "Subject observer" pattern between model and view, with model as the subject and view as the observer. Whenever there is a change in the state of model, it can fire a event to all the observers those are registered, they can update themselves.
Second Solution: Introduce a controller, which registers with model as observer. Upon receiving a event for update from Model, it can update the view. Even you can decouple view from controller using one more subject observer pattern between controller and view
Third Solution: Use MVP pattern. Model view Presenter. This pattern used whenever there is no much computation in controller i.e., job of the controller is just to update its corresponding view. Here controller becomes Presenter.
You need a controller that sits outside the display widget but has the state of the tree (in MFc there are CTreeView/CTreeCtrl classes - there is a similiar separation in Qt) the tree controller handles all the data storage and calls redraws on the tree widget.
Changes in the tree widget get sent to the tree controller - so this controller needs to know about the gui functions.
The model will need set/get functions for all the relevant parameters for the nodes. But these can return simple types so aren't dependent on the gui.
Updating the view form the model requires sending a message, if you don't want the model to know about your gui messaging the best you can do is register a callback function (a void pointer to a function) from the tree controller - and call this to do an update.
This update function can then query the model for the changes.