Forum Replies Created
thanks for bringing this up.
We recently changed hosting provider, which broke the links. Sorry about that.
The links should be working again.
Juan.October 23, 2018 at 18:39 in reply to: Pipe output of one fuzzy model into another fuzzy model using QTFuzzylite #6234
sorry for the delay.
What I mentioned is meant to be done programmatically in the fuzzylite libraries for Java, C++ or Python, not within QtFuzzyLite.October 5, 2018 at 07:47 in reply to: Pipe output of one fuzzy model into another fuzzy model using QTFuzzylite #6222
I think the easiest is to create an output variable that you construct and use as input variable. For example, create output variable
output_state, your rules in the form “if output_state is walking then …”.
The trick is that you are going to manipulate the fuzzy value of
output_state. Every time that you get your set of three values, you are going to do something like:
output_state = engine.output_variable("output_state") walking = output_state.terms running = output_state.terms stationary = output_state.terms output_state.clear() implication = engine.rule_block.implication output_state.fuzzy.terms.append(Activated(walking, walking_value, implication)) output_state.fuzzy.terms.append(Activated(running, running_value, implication)) output_state.fuzzy.terms.append(Activated(stationary, stationary_value, implication))
(The code above is Python, but should give you an idea to do so in C++/Java)
You will also need to process the engine manually because in
engine.process()all the output variables are cleared, and you do not want this
output_statecleared.October 4, 2018 at 07:26 in reply to: Pipe output of one fuzzy model into another fuzzy model using QTFuzzylite #6220
thanks for your questions.
You can merge the two models into a single engine (just append the contents of one FLL into the other without the Engine tag). This merge assumes you have different names for Variables and RuleBlocks.
Once merged, you could add in your relevant rule block a rule using the output variable in the antecedent.
Just make sure that the order of rules execution updates the output variable (to be used as input) before the rule.
Also, have in mind that this approach is not exactly piping. Piping to me means that you defuzzify your output and use it as input in an input variable, thereby losing information in the process. The approach I am suggesting uses the fuzzy output directly, without defuzzification, thereby not losing information in the process.
If this approach does not work for you, I am afraid that piping as you want it is not currently possible in QtFuzzyLite, but would be pretty easy to set up programmatically using the libraries.
your problem is that the paths are wrong. In particular,
-l/fuzzylite-6.0/fuzzyliteis pointing to root
/, and same as
-L/fuzzylite-6.0/fuzzylite/release/bin. They should be
In any case, make sure that both paths are accessible from where you run. Just executing the path will tell you whether it is a directory or not in terminal:
-bash: /fuzzylite-6.0/fuzzylite: No such file or directory
-bash: /Users/juan/dev/fuzzylite-6.0/: is a directory
Your code is using fuzzylite 5, but you are compiling against version 6. There were some name
Changes. Please check the changelog. For example, setAccumulation is now setAggregation.
thanks for your post.
729 rules is a lot. FuzzyLite can handle that gracefully, but the problem you are having might be that none of the rules apply for the given set of input values. If you post or email me your FLL, I could check your engine next week.
As for the 64 bits, please download https://www.microsoft.com/en-nz/download/details.aspx?id=48145 and try again.
What is the output of your process?
Instead of printing
print “WARNING: unable to determine total simulation runs”, can you please print the real output?
I am not sure how you compiled Castalia, but seems the main entry points got mixed up. The main entry point in fuzzylite is
main.cpp, which is why I asked you to delete that file with the goal of ensuring compilation would not grab it. However, the proper solution is not to delete it, but to make sure the file is not present in the build process.
I do not know how you are compiling fuzzylite or castalia, maybe you would want to go step by step over the building process of fuzzylite (See https://github.com/fuzzylite/fuzzylite#compile-link-and-execute for the details), and then Castalia again.
I would suggest you practice and learn linking fuzzylite with the example application available at: https://github.com/fuzzylite/fuzzylite/tree/release/examples/application
Then, apply a similar process to link to Castalia.
How about running manually from console the
I do not know what Castalia is, but did you recompile Castalia? Is it software you are building from sources?
My thoughts on this would be to print information to console from the main entry points of both castalia and fuzzylite. And then to debug the projects and find out what is happening.