According to this paper: "Modularity. The modular design allows us to extend the language and the API easily. It is possible to add custom aggregation, activation or accumulation methods, defuzzifiers, or membership functions by extending the provided object tree (see Figure 5)."
I tried to create a new Activation method by extending RuleActivationMethod class, but the FCL did not recognize the name of my new activation
How can I create a custom activation method?
I am pretty sure it is not straightforward to do this in jfuzzylogic. Take a look at jfuzzylite instead: https://fuzzylite.com/downloads
Related
I am new to Pyomo and would like to implement a custom finite difference discretization scheme. Pyomo documentation implies one needs to copy a function for the forward difference method and just replace the equation next to the first return statement with a new one. After implementing a custom finite difference method using the above function template, the only other change that must be made is to add the custom method to the all_schemes dictionary in the dae.finite_difference class.
Can anyone please provide an example of solving an optimal control problem with manual implementation of finite difference (NOT collocation) discretization?
In TensorFlow (Python), when adding to the graph a tf.train.RMSPropOptimizer, are any additional variables added that need initialization? If yes, how can I get access to them and initialize them manually? (I'd rather not use tf.global_variables_initializer). In other words:
(1) How can I decide which initializer to use?
(2) How can I add the initilizer op to the graph, specifically for these variables?
EDIT 1:
I'm referring here to any new tf.Variable that is added to the graph whenever I add the RMSPropOptimizer, and how it is initialized (just like other tf.Variables). I'm not referring to the arguments in constructor of the RMSPropOptimizer, (which are hyper parameters of the model).
In TensorFlow (Python), when adding to the graph a tf.train.RMSPropOptimizer, are any additional variables added that need initialization?
Yes.
If yes, how can I get access to them and initialize them manually? (I'd rather not use tf.global_variables_initializer).
From the docs:
tf.train.RMSPropOptimizer.__init__(learning_rate, decay=0.9, momentum=0.0, epsilon=1e-10, use_locking=False, centered=False, name='RMSProp')
There are at least 3 (decay, momentum, and epsilon).
In other words: (1) How can I decide which initializer to use?
This I don't have a good answer to - I've been told in class "just use Adam". That might be good advice in general, but I imagine there are cases where others work better. This might be worth searching online for blog posts or survey papers or something.
(2) How can I add the initializer op to the graph, specifically for these variables?
You can pass them into the constructor as named parameters.
I know there are numerous aspect-oriented frameworks for VB.NET. It's a little heavy to pull an entire framework into play in order to add an aspect to a couple methods. Does VB.NET offer a simple means (via some sort of metaprogramming/reflection) in which to layer an aspect over an existing method in a class/object?
Basically, the goal is intercept a method's incoming message to invoke it and add side effects or to manipulate the request, just as one would normally do in standard AOP.
Are there any plans to integrate aspects directly into the language?
Is polymorphism not an option in this case? I think you'll find that, outside of an AOP framework of some kind, there is no way in VB to change the functionality of an existing class. You can inherit and override base members, or you can use extension methods to add additional functionality to an existing class, but there's no way to alter existing functionality in an existing class.
It is possible to create a new library that mimics another existing library and trick existing code into thinking your new library is the original one, but unless absolutely necessary, this is a bad idea. Chances you just need to rethink your design in a standard OOP way rather than thinking in AOP terms.
How about the decorator (or proxy) pattern? Since it's only a few methods, then you only need one or two decorator classes. If you discover later that it's not just one or two methods, then you can consider bringing in an AOP tool.
Here's an example in C# that should translate pretty easily to VB.NET
In Zend Framework 1.X which of the following approaches is better and why?
Approach-1:
Create a (sub)Class extending Zend_Acl and use is to manage all the Acl. It will allow us to use all the Zend_Acl features/function using $this object.
Approach-2:
Create a Custom Class which holds Zend_Acl object and perform actions on the object. Here we can create wrapper functions and can control the access to Zend_Acl's base functions and use only a handful features.
Singleton pattern can be used for both approaches as well to make sure that throughout the site, same Zend_Acl is used.
I will looking for an approach which I can later port to ZF-2.0 easily. If there is any-other approach, please mention it and I will update the post accordingly.
Update: Are there any approaches other thn singleton to maintain single Zend_Acl object throughout the site? And what do you think about using a singleton with approach-1 and use custom methods as well, which will give us all the predefined methods of Zend_Acl along with our custom wrappers.
I will looking for an approach which I can later port to ZF-2.0 easily. If there is any-other approach, please mention it and I will update the post accordingly.
This remark strongly favors approach 2, since your wrapper acts as an adapter to the ACL implementation, and your application interacts only with your adapter, not Zend_Acl directly. Thus you can later change the specific implementation (i.e. composition of Zend_Acl) to another one, be it Zend\Acl or a Symfony 2 component or something you write yourself..
In my projects, I use a Model to manage the whole ACL system (add resources, add roles and so on). Obviously this class extends Zend_Acl. Moreover I use a plugin, that use a preDispatch method, to check if the user who made the request is allowed to access the requested url or not.
A little background: We're building a library/framework for working with scientific models. We have an interface Model which defines the operations that a model must implement, which is pretty minimal. That is: the Model interface defines the contract of a model from the point of view of a model implementor.
The framework adds a bunch of other functionality around the model, but right now client code has to access that functionality by using a bunch of other classes, such as ModelInfo, ModelHost, ModelInstance, etc.
In our application that uses this framework, we don't want to actually have to deal with all this mechanism of running models, etc. So we've decided to use the façade pattern to wrap up the framework functionality in an easy-to-use object. (We've already applied this pattern to other parts of the framework, with good success.)
Here is the question: given that we already have an interface Model, what would be a good name for the façade class? The Model interface is the contract between the framework and the model implementation, and the new class will define the contract between the framework and the client application.
Or, more generally: when we have an abstraction provided by a library or framework, how can we name the "two sides" of the abstraction so as to clearly identify the "provider" and "consumer" interfaces to the abstraction?
(If it matters, for this project we're using Java 6.)
I know this seems trite, but... have you considered using "ModelFacade" as the class name for the facade class? I think with documentation that indicates that the interface was already named Model, it seems relatively straightforward, and makes it very clear which design pattern you're using.
How about *Provider and *Consumer? I think you said it yourself in your question. Perhaps *Producer and *Consumer is a better match?
In discussions within our team, another option has been proposed: we can rename the existing Model interface to something else, and just call the new façade Model. In fact, they can both be called Model right now, because they will live in separate packages. (Although I'm not a fan of identically-named classes in different namespaces.)
Sounds like ModelInfo, ModelHost, and ModelInstance should all be members of Model.
See https://softwareengineering.stackexchange.com/questions/316840/is-it-bad-practice-to-name-a-class-with-a-facade-suffix for why you generally shouldn't name classes with the specific implementation used. Basically, some day you may want to use a different implementation of Model, which happens to not be a facade.
PureMVC uses a singleton named ApplicationFacade and registers all the models with methods like registerProxy which are defined in IFacade