I want to create a more complex architecture than requires layers connected in a custom way.Can I achive this in skflow ? And if not which framework is best ?
Thanks
You can define your own custom model function or even build your own estimator. For example, you can find a ResNet example under tensorflow/examples/learn implemented using TF.Learn (originally skflow).
Related
What are the differences between
inherit nativesdk
and
BBLASSEXTEND="nativesdk"
in a bb recipe?
When you use inherit nativesdk, recipe is made only for nativesdk purpose and must be named nativesdk-myrecipe.bb.
If you want a normal recipe to be also used in nativesdk, you have to extend it by using BBCLASSEXTEND="nativesdk".
Details can be found in Yocto manual.
I am trying to load model from urdf file.
I can achieve this via RigidBodyTree class:
rbtree = RigidBodyTree(file_name, floating_base_type)
Unfortunately, as it said at pydrake.attic reference page, it will be deprecated soon.
I tried to add model using pydrake.multibody.parsing.Parser and pydrake.multibody.plant, but it seems that model is attached only with floating quaternion joint.
Is there a legal way of setting floating base type not with attic API?
For a fixed base, the method you're looking for is MultibodyPlant.WeldFrames(). If plant is the MultibodyPlant object to which you've added your model, and the frame in your model named "my_base_frame" is supposed to be fixed to the world, the appropriate call would be:
plant.WeldFrames(plant.world_frame(), plant.GetFrameByName("my_base_frame"))
Note that this call should be made prior to calling plant.Finalize().
I believe that MultibodyPlant currently does not support roll-pitch-yaw floating bases.
There do not seem to be analogous setters. If I want to fill in the relevant pieces of an array, is there an interface for doing that?
Three ways of doing this:
Using the joint specific APIs as in the example here.
For free bodies you can use the plant's API as here.
If you know what you are doing, you can play with the state vector as done here.
I added methods to provide exactly this functionality in this PR: https://github.com/RobotLocomotion/drake/pull/9503
What are the necessary steps to implement a custom loss function in Torch?
It seems like you have to write an implementation for updateOutput and updateGradInput.
Is that all? So then you basically create a new class:
local CustomCriterion, parent = torch.class('CustomCriterion','nn.Criterion')
and implement the following two functions:
function CustomCriterion:updateOutput(input, target)
function CustomCriterion:updateGradInput(input, target)
Is that correct, or is there more to be done?
Also, for the provided criterions these functions are implemented in C, but I suppose a Lua implementation will also work, albeit possibly a little slower?
I've implemented functions of the form (in pseudo-code)
--assuming input is partitioned in input_a,input_b
-- target is accordingly partitionend in target_a, target_b
f(input)=MSE(input_a,target_a)+ custom_sutff(input_b,target_b)
quite a few times just the way you describe it. So, as far as I know, I think the answer to both your questions is yes.
Basically nn/MSECriterion.lua and this seem to back this up.
A rule in xText called "Component" will typically generate a class "Component" in the src-gen folder.
I would like to add additional methods to these classes without them being overridden every time I make minor changes to the DSL. What's the proper way to inject my own code into these classes and is there a way to make all classes extend my own root class instead of the default EObject?
Thanks in advance.
You basically have two choices:
You can use a IXtext2EcorePostProcessor to modify the EMF-model which Xtext inferred from your grammar. The actual code generation is done by EMF, so you have to fiddle your code through that bottleneck. The details are described in a blog of Christian Dietrich. This approach is only suitable for small modifications.
You can use the "generation gap pattern" (a.k. "implementation gap pattern") which allows you the write classes which derive from the generated model classes. Here you can add anything you want. The details are described in a blog of Heiko Behrens. This approach is better suited for large scale modifcations by inheritance.
You may of course mix the two approaches...