I have been having some difficulty making sense of the Hungarian Algorithm outlined here. It seems incomplete and/or erroneous to me. The main issue is the line:
If R_T ^ Z is nonempty, then reverse the orientation of a directed
path in...
How do we know which path to select as "a path"? If we select the wrong path, how do we recover? This seems to be a monotonically assigning algorithm, in that we can only ever create new assignments, but never remove or alter existing ones.
Suppose we have a simple example of S = {A, B}, T = {W, X} with weights AW: 2, AX: 2, BW: 6, BX: 4. How do we select whether to add AW or AX to the mapping first, or how to we recover from making the wrong selection?
I'm more familiar with the matrix interpretation, but it does look like there's a bit missing.
How do we know which path to select as "a path"?
Just choose one; it doesn't matter which (as long as it's in RT). They should all be equivalent at this point.
If we select the wrong path, how do we recover? This seems to be a monotonically assigning algorithm, in that we can only ever create new assignments, but never remove or alter existing ones.
This is the part that's missing, and as I'm not as familiar with the graph approach I can't tell you exactly how to do it, but it is allowed to alter existing assignments. The missing option is that you can swap an existing assignment to an unassigned edge of equal cost, allowing you to then make a new assignment. The harder part of this is finding the edge to swap to such that it doesn't conflict with any other assignments, and that by making this swap you are able to make a new assignment.
Related
I'm currently working on a model, where I want to use an Array of Integers in order to redeclare the shown components:
Image of the blocks and redeclaration-window
My goal is to have i.e. the blank at the top left corner redeclared to a pump if the integervalue in my reference array is 1. My question would be, if it is even possible to accomplish my goal this way, or if I have to go with the dropdown-menus/manual implementation?
I already tried to use an if-clause or an Array filled with strings, but Modelica/Dymola is only allowing records to be used in the fields for redeclaration. I also tried using "redeclare model extends", to vary the extends which didn't work because of errors in the syntax.
[Possible(?) workaround]
If this is truly impossible, could it be done by piling all the components/parameters up into one model and activate/deactivate the needed parts with a parameter as shown below?
small scale of the described "workaround"
Unfortunately I'm lacking a lot of knowledge when it comes to scripting. I hope my problem is understandable.
You cannot base a redeclare on the value of an Integer parameter.
Having all of the components in one model and disabling the unneeded parts simply doesn't work for parameters (it may possibly work in some cases for components, but it will be complicated, and I wouldn't recommend it) because you aren't allowed to use the conditional parameter.
I think you should present the original goal so that we can find a better solution.
Added: In case was just to redeclare all of the blocks in the same way you could use a "class parameter", i.e. replaceable model M=... and use that for all of the components.
But it seems the intent is to have them different which makes it trickier.
I was trying to solve a question regarding proving whether the given decomposition is lossy or lossless:
Verify which among the following decompositions of R(ABCDE) are
lossless or lossy by applying the test for lossless join property. F =
{AB→C, C→E, B→D, E→A} is the set of functional dependencies on R.
R(ABCDE) is decomposed as R1(AB), R2(ADE) and R3(BCD)
R(ABCDE) is decomposed as R1(BCD) , R2(ACE) and R3(BD)
My attempt at the solution:
A decomposition can only be lossless if there are common attributes between the given tables and the common attributes are candidate key/super key.
In the first part, we have no candidate key in R1 and none in R2 so can we call it as lossy decomposition ?
In the second part, C is the candidate key for R2 and B is the candidate key for R3, but R1 has no key and also R2 and R3 share no common attributes so its also not a lossless decomposition ?
Is my explanation valid or are there any more criteria ?
The instructions are clear: "by applying the test for lossless join property". Presumably that is the important theorem that says that a binary join/decomposition is lossless when/iff .... But you don't quote it. Look in your textbook. (Beware, the Wikipedia article has problems.) You do say "can only be lossless if" but that's just saying something is necessary, which is the "if" in one direction, whereas you haven't said what's also sufficient, which is the "if" in the other direction, which is the direction you need, so your reasoning is not sound--unless you are just using poor language and you mean "iff". But even using "iff" your definition is wrong. You need to say that "the common columns form a superkey" of at least one of the components. And "there are common attributes between" doesn't belong--there don't need to be common attributes whether or not a join is lossless. No common attributes means a common attribute set {} and a cross join; but if its subset {} is a CK of a component--that component has at most one row--the join is lossless.--But you don't need to know that, you just have to use the theorem. Also you need to be told F is a cover--then tell us--or CKs can't be found. Another problem is "we have no CK"--every schema has a CK, since the set of all columns forms a superkey--and there are always the trivial FDs.--But you don't need to know that, you just have to use the definitions, theorems & algorithms for finding CKs. Also you need to find all the FDs of the closure of the cover you were given & then calculate the new CKs for each component using the FDs that have all their attributes in it. There's another theorem that says that those FDs of the closure are exactly the FDs that hold in the components. There could be FDs that are implied by the given ones & have all their attributes in a component even though the given ones don't.--But you don't need to know that, you just need to justify you have the CKs by justifying you have the FDs by using definitions, theorems & algorithms. But also the "property" theorem involves binary decompositions--so have you been told to assume--but not told us--that R = R1 JOIN (R2 JOIN R3) in that order? This is all clear from the theorems & algorithms & definitions of FD, cover, closure & CK but you need to memorize definitions & theorems exactly & then apply them precisely & tediously. That's all I just did.
Why do you have doubts in your questions in the 2 parts? Why are you not applying the "property" theorem? Why are you not addressing the fact that it is about binary joins?
If you are ever unsure of how to do an exercise that you have seen in your textbook that you know doesn't require creativity then you literally don't know what you are doing so go back in your textbook & find out.
Usually I just close vote questions like this with this comment:
Re "is this right": Show the steps of your work following your reference/textbook, with justification--you may find mistakes that make your question unnecessary & we don't know exactly what algorithm you are following & we want to check your work but not redo it & we need your choices when an algorithm allows them & otherwise we can't tell you where you went right or wrong & we don't want to rewrite your textbook. Please see How to Ask, hits googling 'stackexchange homework' & the voting arrow mouseover texts.
Usually when I see good ol' F or other set or list of FDs in a quoted database normalization assignment without explanation I try to work towards an answerable post by commenting a variant of this:
What does "I have these FDs" mean? "These are all the FDs that hold"?--Not possible. "These are all the non-trivial FDs that hold"?--Not possible. "These are some FDs that hold"?--Question can't be answered. Find out what a cover is & what the exact conditions are to apply a particular definition/rule/algorithm. To determine CKs & NFs we must be given FDs that form a cover. Sometimes a minimal/irreducible cover. And the set of all attributes must given. See this answer.
So when you redo this exercise, if you're not certain you know what to do at some point & post another question please be sure to follow those comments.
Let's say we have the following model:
Collector:
model Collector
Real collect_here;
annotation(defaultComponentPrefixes="inner");
end Collector;
and the following model potentially multiple times:
model Calculator
outer Collector collector;
Real calculatedVariable = 2*time;
equation
calculatedVariable = collector.collect_here;
end Calculator;
The code above works if calcModel is present only once in the system to be simulated. If the model exists more than once I get a singular system. This is demonstrated by the Example below. Changing the parameter works either gives a working or failing system.
model Example
parameter Boolean works = true;
inner Collector collector;
Calculator calculator1;
Calculator calculator2 if not works;
end Example;
Using an array inside the collector to pass multiple variables in it doesn't solve it.
Another possible way to solve this is possible by use of connectors, but I only made it work with one calcModel.
Using multiple instances of Calculator does brake the model, as the single variable calculatedVariable will have multiple equations trying to compute its value. Therefore Dymola complains that the system is structurally singular, in this case meaning that there are more equations than variables in the resulting system of equations.
To give a bit more of an insight: Actually checking Collector will fail, as since Modelica 3.0 every component has to be balanced (meaning it has to have as many unknowns as states), which is not the case for Collector as it does have one unknown but no equation. This strongly limits the possible applications for the inner/outer construct as basically every variable has to be computed where it is defined.
In the given example this is compensated in the overall system if exactly one Calculator is used. So this single combination will work. Although this works, it is something that should not be done - for the obvious reason of being very error-prone (and all sub-models should pass the check).
Your question on how to solve this issue actually misses a description of what the issue actually is. There are some cases in my mind that your approach could be useful for:
You want to plot multiple variables from a single point, which would be collector. For this purpose "variable selections" should be the most straight-forward way to go: see Dymola Manual Vol. 1, Section "4.3.11 Matching and variable selections" on how to apply them.
You want to carry out some mathematical operation on that variables. Then it could be useful to have a vectorized input of variable size. This enables an arbitrary number of connections to this input. For an example of this take a look at: Modelica.Blocks.Math.MultiSum
You want to route multiple signals between different models (which is unlikely judging from your description, but still): Then expandable connectors would be a good possibility. To get an impression of what that does take a look at Modelica.Blocks.Examples.BusUsage.
Hope this helps, otherwise please specify more clearly what you actually want to achieve with your code.
I prepared a demonstrative library for such scenario some days ago. You can access it at https://gist.github.com/beutlich/e630b2bf6cdf3efe96e5e9a637124fe1. If you read the documentation on Example2 you can see the link to an article from H. Elmqvis et. al., which is the clue to your problem. That is, you need a connector, and inherited connects from every Calculator to the one Collector.
I would like to encode "implies" logic in LogicBlox.
I have a predicate:
Number(n),hasNumberName(n:i)->int(i).
isTrue[n] = i -> Number(n), boolean(i).
And I add some data in that predicate:
+Number(1).
Now, I want to create number 2 and number 3, and the truth value for these two number following this logic rule:
If isTrue[1] is true, then isTrue[2] is true or isTrue[3] is true. (isTrue[1] implies (isTrue[2] or isTrue[3]))
So I create a predicate:
implies[n1,n2,n3] = e -> Number(n1), Number(n2), Number(n3),boolean(e).
Then I try to create a rule like that:
isTrue[n2] = true;isTrue[n3] = true <- isTrue[n1] = true,implies[n1,n2,n3] = true.
But LogicBlox reports:"error: disjunction is not supported in the head of a rule "
So how can I encoding this implies logic in LogicBlox?
From your question it looks like you're asking this question with a Prolog background. If so, then it might be helpful to read a Datalog introduction, for example "What you always wanted to know about Datalog (and never dared to ask)".
The logic you want to express is on purpose not allowed in Datalog, because it requires a solving or search strategy. As opposed to Prolog, Datalog is on purpose restricted in the computational complexity of the programs you can express. As a result of these restrictions it meets important requirement for use in a database management system, most importantly supporting very large data sets. The computational complexity restrictions will be more clear after reading a good introduction to Datalog.
People have studied extensions of Datalog to allow more programs to be expressed (without going to full Prolog, which would result in a more procedural semantics). This particular example is called "Disjunctive Datalog". The hits on Google look good for this if you want to read more. LogicBlox does (at least currently) not implement Disjunctive Datalog because our primary objective is to be a scalable database management system.
LogicBlox does support using a solver for specific programs. A typical example is the knapsack problem. If your problem is expressible as an optimization problem (it almost certainly is, but the formulation usually requires some creativity for things that are not conventional optimization problems), then you could use this feature. The solver functionality is not very well documented in publicly available material yet. Please reach out to us directly if you would like to give this a try.
I assume you are trying to enforce a constraint that 1 -> 2 or 3 ? If so, trying to derive a value using <- is not going to work: if neither 2 nor 3 is present, which one(s) are you telling the system create? Instead, just write the constraint using -> syntax. Constraints are implications, after all (the right arrow syntax is no accident!), and that puts the disjunction on the right hand side where the language allows it. Then, if you ever try to create 1 and neither 2 nor 3 exists, the system will report a constraint failure because the implication was not found to hold.
Also, you don't usually need boolean-valued functions in logic languages; isTrue(x) can just be the set of x which you consider to be "true" (and any not present are "false").
I'm trying to write a function what detect this relation between the variables I have got in the workspace:
v1 - fft(v2) = 0
Where v1, v2 are variables of my workspace.
Sometimes I need to know which variables have a certain numerical relation. If I have thirty, I don´t want to be looking for this relation in "manual way", just introducing a sentence for each pair of different variables.
I would like a function in which I introduce (or I modify this function every time I need it) the sentence (for instance what I wrote before) and the function show me the pair of variables a I am looking for.
Does anyone know how to do it?
You can use who() to programatically obtain a list of variables that currently exist. You can then use eval() to get their values. At that point, you can use a fairly trivial nested loop to iterate over all possible pairs, looking for that relationship.
Note 1: Using eval() for "normal" programming is considered bad style; it should only really be used for meta-programming tasks like this.
Note 2: If you have N variables in the workspace, there are N^2 ordered pairs. This may take a while to iterate over if N is large.
Note 3: You're essentially looking for equality between variables, which may not be particularly reliable in floating-point.