You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi guys! I'm working on a new feature focused on students who want to understand the applications of the laws of Boolean algebra in the process of simplifying an expression. To achieve this, I'm utilizing the Visitor class. Ultimately, i generate a new String representing the simplified form of the original Expression, similar to the process in Expression.toString(), but in each step ,like in the visitBinary() and visitNot(), i check if it's possible to apply some law and if i can i remove or add elements in the final String.
Identifying the laws and creating the final String pose no challenges for me. I've already implemented the simplification for every law that can simplify an Expression. However, due to the Visitor's left-to-right approach, i can't easily find a way (or determine if there's one) to identify patterns requiring the associative law.
Let me illustrate with an example: "a.a.b" simplifies to "a.b" and in this case, my function works. However, if I input "a.b.a" instead of "a.a.b," my function doesn't "recognize" this as an expression that can be simplified. The main issue is that my String is created like the Expression.toString(). Even if i can identify the simplification in the previous example, it could be difficult to remake the String (what/where i need to remove/add), at least i don't see how to do that.
In summary, is there a better approach to this simplification process? Alternatively, is there a more effective way to create the new Expression rather than using a StringBuilder?
I know that maybe it's just a lack of acknowledgment in algorithms or Java. I would be very thankful if anyone could help me with that.
The text was updated successfully, but these errors were encountered:
There are many Boolean Algebra simplification programs available online. The first listed when I searched was www.boolean-algebra.com which will take an expression and show steps to simplify it. I'm not sure what advantage adding this to LE would provide.
If I were to try to implement it, I would start by parsing the string into a parse tree and investigate how compilers simplify expressions.
Hi guys! I'm working on a new feature focused on students who want to understand the applications of the laws of Boolean algebra in the process of simplifying an expression. To achieve this, I'm utilizing the Visitor class. Ultimately, i generate a new String representing the simplified form of the original Expression, similar to the process in Expression.toString(), but in each step ,like in the visitBinary() and visitNot(), i check if it's possible to apply some law and if i can i remove or add elements in the final String.
Identifying the laws and creating the final String pose no challenges for me. I've already implemented the simplification for every law that can simplify an Expression. However, due to the Visitor's left-to-right approach, i can't easily find a way (or determine if there's one) to identify patterns requiring the associative law.
Let me illustrate with an example: "a.a.b" simplifies to "a.b" and in this case, my function works. However, if I input "a.b.a" instead of "a.a.b," my function doesn't "recognize" this as an expression that can be simplified. The main issue is that my String is created like the Expression.toString(). Even if i can identify the simplification in the previous example, it could be difficult to remake the String (what/where i need to remove/add), at least i don't see how to do that.
In summary, is there a better approach to this simplification process? Alternatively, is there a more effective way to create the new Expression rather than using a StringBuilder?
I know that maybe it's just a lack of acknowledgment in algorithms or Java. I would be very thankful if anyone could help me with that.
The text was updated successfully, but these errors were encountered: