Essential Prime Implicants and Minterm Expressions - binary

I have an exam for a university course shortly, and upon reviewing one of my assignments I have come to realize that I don't understand why I have lost marks/how to do a couple of questions. Hopefully someone can shed some light on the subject for me! The questions were as follows:
Use K-Maps to simplify the following boolean functions (Note that d() represents a don't care minterm):
1.) F(w, x, y, z) = ∑(1,3,5,7,11,12,13,15)
My answer:
Prime Implicants: yz, w'z, xz, wxy'
Essential Prime Implicants: yz, w'z, wxy'
Possible Minimal Expression(s): yz + w'z + wxy'
Answer sheet (professor's answer):
Prime Implicants: yz, w'z, xz, wxy'
Essential Prime Implicants: Same as prime implicants
Possible Minimal Expression(s): yz + w'z + xz + wxy'
2.) F(w, x, y, z) = ∑(1,2,5,7,12) + d(0,9,13)
My answer:
Prime Implicants: w'x'z', y'z, w'xz, wxy', w'x'y'
Essential Prime Implicants: w'x'z', w'xz, wxy'
Possible Minimal Expression(s): w'x'z' + w'xz + wxy'
Answer sheet (professor's answer):
Prime Implicants: w'x'z', y'z, w'xz, wxy', w'x'y'
Essential Prime Implicants: w'x'z', w'xz, wxy'
Possible Minimal Expression(s): w'x'z' + w'xz + wxy' + y'z
I suppose I should add that I asked my professor after he returned my assignment to me if he had made a mistake and explained my point of view. He seemed pretty certain that he was correct, but couldn't really explain why because he speaks poor English (well, that's university for you..).
Thanks in advance to anyone who can help! This has been quite a task to try to figure out on my own!

1.) You are correct: XY is no essential prime implicant. It does not cover any minterm which is not covered by other prime implicants. Thus, is can be removed from the solution.
The Karnaugh map might help to see this more clearly:
wx
00 01 11 10
+---+---+---+---+
00 | 0 | 0 | 1 | 0 |
+---+---+---+---+
01 | 1 | 1 | 1 | 0 |
yz +---+---+---+---+
11 | 1 | 1 | 1 | 1 |
+---+---+---+---+
10 | 0 | 0 | 0 | 0 |
+---+---+---+---+
I am not sure what is meant by "possible minimal expressions". If you enumerate all potential encircled blocks in the map, XY would also be one.
2.) Your solution and the official solution are the same.
Again - like in 1.) - the solution sheet also includes the non-essential terms as "possible minimal expressions".
F = w x y' + w' x z + w' x' z' + w' x' y'

1.) F(w, x, y, z) = ∑(1,3,5,7,11,12,13,15)
wx
00 01 11 10
+---+---+---+---+
00 | 0 | 0 | 1 | 0 |
+---+---+---+---+
01 | 1 | 1 | 1 | 0 |
yz +---+---+---+---+
11 | 1 | 1 | 1 | 1 |
+---+---+---+---+
10 | 0 | 0 | 0 | 0 |
+---+---+---+---+
note : here essential prime implicants are the prime implicants which are formed by
wxyz
1100
1101
result is wxy'
if you compute the prime implicant which is formed 3, 7, 11 and 15
wxyz
0011
0111
1111
1011
result is yz
if you compute the prime implicant which is formed 1, 5, 3 and 7
wxyz
0001
0101
0011
0111
result is w'z
so essential prime implicants are wxy', yz and w'z
xz is not a essential prime implicant because prime implicant which is formed by 5, 13, 7, and 15 is redundant prime implicant

Related

Regression with all variables without explicitly declaring them

I have a dataset that I would like to run a regression on in Stata. I want to make one of the dummy variables the base so I use the ib1.month1 in the regress command.
Is it possible to include in my regression all other variables in the dataset without explicitly writing out each variable again?
You can use the ds command:
sysuse auto, clear
drop make
ds price foreign, not
regress price ib1.foreign `r(varlist)'
Source | SS df MS Number of obs = 69
-------------+---------------------------------- F(10, 58) = 8.66
Model | 345416162 10 34541616.2 Prob > F = 0.0000
Residual | 231380797 58 3989324.09 R-squared = 0.5989
-------------+---------------------------------- Adj R-squared = 0.5297
Total | 576796959 68 8482308.22 Root MSE = 1997.3
------------------------------------------------------------------------------
price | Coef. Std. Err. t P>|t| [95% Conf. Interval]
-------------+----------------------------------------------------------------
foreign |
Domestic | -3334.848 957.2253 -3.48 0.001 -5250.943 -1418.754
mpg | -21.80518 77.3599 -0.28 0.779 -176.6578 133.0475
rep78 | 184.7935 331.7921 0.56 0.580 -479.3606 848.9476
headroom | -635.4921 383.0243 -1.66 0.102 -1402.198 131.2142
trunk | 71.49929 95.05012 0.75 0.455 -118.7642 261.7628
weight | 4.521161 1.411926 3.20 0.002 1.694884 7.347438
length | -76.49101 40.40303 -1.89 0.063 -157.3665 4.38444
turn | -114.2777 123.5374 -0.93 0.359 -361.5646 133.0092
displacement | 11.54012 8.378315 1.38 0.174 -5.230896 28.31115
gear_ratio | -318.6479 1124.34 -0.28 0.778 -2569.259 1931.964
_cons | 13124.34 6726.3 1.95 0.056 -339.8103 26588.5
------------------------------------------------------------------------------

Rounding results in OLS regression

This is my regression and its output:
How can I round the coefficients and the standard errors in two decimal places?
You can use the option cformat().
For example::
sysuse auto
regress price length, cformat(%5.2f)
Source | SS df MS Number of obs = 74
-------------+---------------------------------- F(1, 72) = 16.50
Model | 118425867 1 118425867 Prob > F = 0.0001
Residual | 516639529 72 7175549.01 R-squared = 0.1865
-------------+---------------------------------- Adj R-squared = 0.1752
Total | 635065396 73 8699525.97 Root MSE = 2678.7
------------------------------------------------------------------------------
price | Coef. Std. Err. t P>|t| [95% Conf. Interval]
-------------+----------------------------------------------------------------
length | 57.20 14.08 4.06 0.000 29.13 85.27
_cons | -4584.90 2664.44 -1.72 0.090 -9896.36 726.56
------------------------------------------------------------------------------
In the Stata manual for regress there is a useful discussion of display options.

How to flip the trigonometric circle around the 45° angle?

I am looking for a mathematical function capable of flipping the trigonometric circle around the "axis" located on the 45° vector (or pi/4 radians).
Such as :
|---------|---------|
| x | f(x) |
|---------|---------|
| 0 | 90 |
| 45 | 45 |
| 90 | 0 |
| 135 | 315 |
| 180 | 270 |
| 225 | 225 |
| 270 | 180 |
| 315 | 135 |
|---------|---------|
Just to give a few examples.
So basically I need to turn a compass rose :
into a trigonometric circle :
I only found things like "180 - angle" but that is not the kind of rotation I'm looking for.
Is it possible ?
The main difficulty in your problem is the "jump" in the result, where f(90) should be 0 but f(91) should be 359. A solution is to use a jumpy operator--namely, the modulus operator, which is often represented by the % character.
In a language like Python, where the modulus operator always returns a positive result, you could use
def f(x):
return (90 - x) % 360
Some languages can return a negative result if the number before the operator is negative. You can treat that by adding 360 before taking the modulus, and this should work in all languages with a modulus operator:
def f(x):
return (450 - x) % 360
You can demonstrate either function with:
for a in range(0, 360, 45):
print(a, f(a))
which prints what was desired:
0 90
45 45
90 0
135 315
180 270
225 225
270 180
315 135
If your language does not have the modulus operator, it can be simulated by using the floor or int function. Let me know if you need a solution using either of those instead of modulus.

Mysql (5.5) precision issue with function SUM with decimal field

Simple precision issue with mysql list of numbers do not calculate the same with sum as a single calculation. (How does one handle this senario?) There is a one(1) cent difference?
Sample of rows:
Select qty, (qty*21.25)
6.5 | 138.125
0.5 | 10.625
0.5 | 10.625
0.25 | 5.3125
1 | 21.25
2 | 42.5
1 | 21.25
2 | 42.5
2.5 | 53.125
2.5 | 53.125
2 | 42.5
3 | 63.75
3 | 63.75
3.5 | 74.375
Sample 2:
Select sum(qty), sum(amount)
30.25 | 642.8175
Sample 3:
Select 30.25*21.25
642.8125
Since the answer was so vague. Let try this. Can anyone explain why the mysql statement produces the wrong results.
SELECT 6.875+3.125
10.00
Shouldn't this be
10.01
Read this article. Floating point numbers are not stored as exact values, therefore could be problems with calculation precision

Storing shipping prices in MySQL table where many columns will be added in future

I'm looking to create a system where users specify shipping prices for their items. The variables I need to cover are the weight band (from in grams to in grams), the price and the countries covered. From this data I can calculate shipping cost by referencing the customers country and the total weight of the basket.
My first thought is something like this:
id from_weight to_weight price us ca gb fr es de it
------------------------------------------------------------------
1 0g 499g 1.99 Y Y N N N N N
2 500g 999g 2.99 Y Y N N N N N
3 1000g 1999g 4.99 Y Y N N N N N
4 2000g 2999g 7.99 Y Y N N N N N
5 0g 499g 4.99 N N Y Y Y Y Y
6 500g 999g 6.99 N N Y Y Y Y Y
7 1000g 1999g 9.99 N N Y Y Y Y Y
8 2000g 2999g 14.99 N N Y Y Y Y Y
However the plan would be to add more and more country options. This would mean adding more columns each time. Is this the best way to structure this kind of data. Any other suggestions
normally it is preferred practice to leave the table structure the same, and just add rows to cater for the case that you illustrated. (there are reasons such as optimisation where you can deviate from this)
I would suggest at looking up "3rd Normal Form", if your database complies with the rules to be in 3rd normal form then, you generally end up with a lot less maintenance and easier extendibility down the track.
table1
id | from_weight | to_weight | price
1 | 0g | 499g | 1.99
table2
id | table1id | countrycode | status
1 | 1 | us | Y
2 | 1 | ca | Y
3 | 1 | gb | N
this is how you would query the data
select price from table1
join table2 on table1.id=table2.table1id
where countrycode='us' and status='Y' and
300 between from_weight and to_weight
If you want to avoid adding columns, you can add a 2nd table that has priceID and Country as columns and just remove all the country columns. Then you just make priceID have a foreign key referencing the ID from your first table and you can add new countries as needed.
Yes, I'd say so. Your goal is going to be to find the price for a given weight and country combination, so it should be easy to perform this query:
SELECT price FROM table WHERE $weight > from_weight AND $weight < to_weight AND $country;
And your schema allows that easily. I'd recommend that you select your to_weight such that a value of 499.9 fits in one of the categories, unless weight is restricted to be an integer. I wouldn't worry about adding new columns, that's easy and you can default it to false for any new country.
It seems the rows of your table form groups of related pricing plans. If that's the case, I would suggest you have a PricingPlan table and a PlanDetail table.
PricingPlan
-----------
PricingPlanId* PlanTitle
----------------------------------------
1 planA for North America
2 planB for EU
PlanDetail
----------
PricingPlanId* DetailId* FromWeight ToWeight Price
------------------------------------------------------
1 1 0g 499g 1.99
1 2 500g 999g 2.99
1 3 1000g 1999g 4.99
1 4 2000g 2999g 7.99
2 1 0g 499g 4.99
2 2 500g 999g 6.99
2 3 1000g 1999g 9.99
2 4 2000g 2999g 14.99
A third, PlanCountry table should used so you don't have to add any columns for new countries that you want to relate to a pricing plan (a new row would be added in that table, if for example you want Mexico to be included in planA):
Country
-------
CountryCode* CountryName
-----------------------------
us USA
ca Canada
uk United Kingdom
fr France
es Spain
de Germany
it Italy
PlanCountry
-----------
PricingPlanId* CountryCode*
---------------------------
1 us
1 ca
2 uk
2 fr
2 es
2 de
2 it
1 mx --- Mexico added for planA