I have simplified a Boolean expression using 14 Boolean Algebra law steps and now have a working resultant function which according to a KV map still has a redundant term.
In an attempt to remove this term I have tried various distribution, complement and identity applications followed by a deMorgans law, as well a Consensus Theorem approach. Of the text books I've consulted they all say there is no theory or set rules to resolving such an issue, just experience!
After much simplification (page and half) my resultant expression is,
z = ~a~cd + b~a + b~d + bc [1]
Using a KV map I get a slightly simpler expression of,
z = ~a~cd + b~d + bc [2]
The truth table of each expression is equivalent therefore the b~a of my first expression [1] appears to be redundant.
I expected to be able to cancel the redundant **b~a** function by applying the laws of Boolean algebra but after much experimenting I'm unable to find an entry point.
This is an assignment question so I do not expect anybody to do my homework but advise on how to approach this challenge would be appreciated.
Related
According to this manual page, we can use reduce to perform reduction like
summation (+):
var a = (+ reduce A) / num;
var b = + reduce abs(A);
var c = sqrt(+ reduce A**2);
and maximum value/location:
var (maxVal, maxLoc) = maxloc reduce zip(A, A.domain);
Here, Chapel defines reduce to be an infix operator rather than a function (e.g., reduce( A, + )). IMHO, the latter form seems to be a bit more readable because the arguments are always separated by parentheses. So I am wondering if there is some reason for this choice (e.g., to simplify some parallel syntax) or just a matter of history (convention)?
I'd say the answer is a matter of history / convention. A lot of Chapel's array and domain features were heavily inspired by the ZPL language from the University of Washington, and I believe this syntax was taken reasonably directly from ZPL.
At the time, we didn't have a notion of passing things like functions and operators around in Chapel, which is probably one of the reasons that we didn't consider more of a function-based approach. (Even now, first-class function support in Chapel is still somewhat in its infancy, and I don't believe we have a way to pass operators around).
I'd also say that Chapel is a language that generally favors syntax for key patterns rather than taking more of a "make everything look like a function / method call" approach (e.g., ranges are supported via a literal syntax and several key operators rather than using an object type with methods).
None of this is to say that the choice was obviously right or couldn't be reconsidered.
I'm trying to evaluate some matrix multiplications in MuPAD. The output is using sigmas as placeholders for the matrix elements since they are long expressions (I assume that's the reason). Is there a way to get MuPAD to display the individual matrix elements as (in my case) the exponential functions that they really are, regardless of the length of the expression?
Below is an example of a case where MuPAD is using sigmas instead of the actual exponential functions. I would like to be able to see what the individual matrix elements of TotT^4 really are.
The commands I executed in the MuPAD interface that lead up to TotT^4 are:
T1 := matrix([[exp((J+B/2)/T),exp(-(J+B/6)/T)],[exp((-J+B/6)/T),exp((J-B/2)/T)]])
T2 := matrix([[exp((J1+B/2)/T),exp(-(J1+B/6)/T)],[exp((-J1+B/6)/T),exp((J1-B/2)/T)]])
T1d := linalg::transpose(T1)
TotT := T1d*T2
The class of your variable can be obtain via type(totT): Dom::Matrix. You may want to look at the many methods of this class in the documentation. As far as I can tell, this issue has something to do with the pretty printing of the class's print method. Other classes exhibit this same substitution, so it may be a function of the overloaded print. I was not able to change the behavior by adjusting setPrintMaxSize, PRETTYPRINT, TEXTWIDTH, or any of the optional arguments to print. You might still try yourself as there are many permutations.
I also tried using the expand function. expand(TotT,IgnoreAnalyticConstraints) nearly works though it could have undesirable effects in some cases if things were expanded too much. Calling simplify does get rid go the substitutions, but it also changes the nature of some of the entries by simplifying. It is probably also not a general solution to this issue.
One way that does work, but is ugly, is to use the expr2text method, which returns a result as a string:
expr2text(TotT)
which returns
"matrix([[exp((B/6 - J)/T)*exp((B/6 - J1)/T) + exp((B/2 + J)/T)*exp((B/2 + J1)/T), ...
exp(-(B/2 - J1)/T)*exp((B/6 - J)/T) + exp((B/2 + J)/T)*exp(-(B/6 + J1)/T)], ...
[exp(-(B/2 - J)/T)*exp((B/6 - J1)/T) + exp((B/2 + J1)/T)*exp(-(B/6 + J)/T), ...
exp(-(B/2 - J)/T)*exp(-(B/2 - J1)/T) + exp(-(B/6 + J)/T)*exp(-(B/6 + J1)/T)]])"
I think that this question would be a good one to ask over at Matlab Central or by filing a service request if you have a license with support.
Suppose one needs to select the real solutions after solving some equation.
Is this the correct and optimal way to do it, or is there a better one?
restart;
mu := 3.986*10^5; T:= 8*60*60:
eq := T = 2*Pi*sqrt(a^3/mu):
sol := solve(eq,a);
select(x->type(x,'realcons'),[sol]);
I could not find real as type. So I used realcons. At first I did this:
select(x->not(type(x,'complex')),[sol]);
which did not work, since in Maple 5 is considered complex! So ended up with no solutions.
type(5,'complex');
(* true *)
Also I could not find an isreal() type of function. (unless I missed one)
Is there a better way to do this that one should use?
update:
To answer the comment below about 5 not supposed to be complex in maple.
restart;
type(5,complex);
true
type(5,'complex');
true
interface(version);
Standard Worksheet Interface, Maple 18.00, Windows 7, February
From help
The type(x, complex) function returns true if x is an expression of the form
a + I b, where a (if present) and b (if present) are finite and of type realcons.
Your solutions sol are all of type complex(numeric). You can select only the real ones with type,numeric, ie.
restart;
mu := 3.986*10^5: T:= 8*60*60:
eq := T = 2*Pi*sqrt(a^3/mu):
sol := solve(eq,a);
20307.39319, -10153.69659 + 17586.71839 I, -10153.69659 - 17586.71839 I
select( type, [sol], numeric );
[20307.39319]
By using the multiple argument calling form of the select command we here can avoid using a custom operator as the first argument. You won't notice it for your small example, but it should be more efficient to do so. Other commands such as map perform similarly, to avoid having to make an additional function call for each individual test.
The types numeric and complex(numeric) cover real and complex integers, rationals, and floats.
The types realcons and complex(realcons) includes the previous, but also allow for an application of evalf done during the test. So Int(sin(x),x=1..3) and Pi and sqrt(2) are all of type realcons since following an application of evalf they become floats of type numeric.
The above is about types. There are also properties to consider. Types are properties, but not necessarily vice versa. There is a real property, but no real type. The is command can test for a property, and while it is often used for mixed numeric-symbolic tests under assumptions (on the symbols) it can also be used in tests like yours.
select( is, [sol], real );
[20307.39319]
It is less efficient to use is for your example. If you know that you have a collection of (possibly non-real) floats then type,numeric should be an efficient test.
And, just to muddy the waters... there is a type nonreal.
remove( type, [sol], nonreal );
[20307.39319]
The one possibility is to restrict the domain before the calculation takes place.
Here is an explanation on the Maplesoft website regarding restricting the domain:
4 Basic Computation
UPD: Basically, according to this and that, 5 is NOT considered complex in Maple, so there might be some bug/error/mistake (try checking what may be wrong there).
For instance, try putting complex without quotes.
Your way seems very logical according to this.
UPD2: According to the Maplesoft Website, all the type checks are done with type() function, so there is rather no isreal() function.
How to simplify a given boolean expression with many variables (>10) so that the number of occurrences of each variable is minimized?
In my scenario, the value of a variable has to be considered ephemeral, that is, has to recomputed for each access (while still being static of course). I therefor need to minimize the number of times a variable has to be evaluated before trying to solve the function.
Consider the function
f(A,B,C,D,E,F) = (ABC)+(ABCD)+(ABEF)
Recursively using the distributive and absorption law one comes up with
f'(A,B,C,E,F) = AB(C+(EF))
I'm now wondering if there is an algorithm or method to solve this task in minimal runtime.
Using only Quine-McCluskey in the example above gives
f'(A,B,C,E,F) = (ABEF) + (ABC)
which is not optimal for my case. Is it save to assume that simplifying with QM first and then use algebra like above to reduce further is optimal?
I usually use Wolfram Alpha for this sort of thing.
Try Logic Friday 1
It features multi-level design of boolean circuits.
For your example, input and output look as follows:
You can use an online boolean expression calculator like https://www.dcode.fr/boolean-expressions-calculator
You can refer to Any good boolean expression simplifiers out there? it will definitely help.
I am tutoring someone in basic search and sorts. In insertion sort I iterate negatively when I have a value that is greater than the one previous to it in numerical terms. Now of course this approach can cause issues because there is a check which calls for array[-1] which does not exist.
As underlined in bold below, adding the and x > 0 boolean prevents the index issue.
My question is how is this the case? Wouldn't the call for array[-1] still be made to ensure the validity of both booleans?
the_list = [10,2,4,3,5,7,8,9,6]
for x in range(1,len(the_list)):
value = the_list[x]
while value < the_list[x-1] **and x > 0**:
the_list[x] = the_list[x-1]
x=x-1
the_list[x] = value
print the_list
I'm not sure I completely understand the question, and I don't know what programming language this is, but most modern programming languages use so-called short-circuit Boolean evaluation by default so that the logical expression isn't evaluated further once the outcome is known.
You can use that to guard against range overflow, like this:
while x > 0 and value < the_list[x-1]
but the check of x's range here must come before the use.
AND operation returns true if and only if both arguments are true, so if one of arguments is false there's no point of checking others as the final value is already known at that point. As for your example, usually evaluation goes from left to right but it is not a principle and it looks the language you used is not following that rule (othewise it still should crash on array lookup). But ut may be, this particular implementation optimizes this somehow (which IMHO is not good idea) and evaluates "simpler" things first (like checking if x > 0) before it look up the array. check the specs why this exact order works for you as in most popular languages you would still crash if test x > 0 wouldn't be evaluated before lookup