hypercube (Qn: 2^n nodes, nx2^(n-1) links, each dimension (0,1,2,..., n-1) has 2^(n-1) links).
For nodes 0000 and 1111, there exists four node-disjoint paths of length 4 (which happens to be the hamming distance between them). These paths are listed as travel from source 0000 through dimension 0-1-2-3 or 1-2-3-0 or 2-3-0-1 or 3-0-1-2 to the destination 1111.
Question 1: how many node-disjoint paths between nodes 0000 and 1010 and what are their length?
Question 2: for any two arbitrary nodes with the hamming distance r, how many node-disjoint paths among them with the distance r and what are they?
Related
I have some sets of combinations and I want to find out the intersection function between say two of them. Then I want to represent the intersected results in ZDD.
I am thinking about using the CUDD package to do this.
An example:
All the 4-bit strings having hamming distance >= 2 with 1100 =
{ 0001, 0010, 0011,0101, 0110, 0111, 1001, 1010, 1011 }
All the 4-bit strings having hamming distance >= 2 with 0000 =
{ 0011, 0101, 0110, 1001, 1010, 0111, 1011, 1101, 1110 }
Intersected elements of the set (what I want):
{0011, 0101, 0110, 1010, 1001 }
From what I understand, I need to be able to express those sets of combinations first, with boolean functions, e.g. ( f = a b c d ) to represent their corresponding BDDs, convert them to ZDDs and then find out the intersection? Someone experienced with the CUDD package please help.
Your reasoning is correct. You can first build BDDs corresponding to the two string sets, convert them to ZDDs, and then build the intersection (logical AND).
However, you can also first compute the intersection (logical AND) and then translate the result to a ZDD.
It is however not clear what you mean by "find out the intersection" - what do you want to do with it? Print out all the elements? Count the number of elements? Depending what what is your aim, the translation to ZDDs may be unnecessary (or the use of CUDD altogether).
I have an edge-weighted undirected graph represented by a minimum spanning tree. Each vertice is represented by an integer. The MST looks like this:
I wonder, how can I use this MST to find the shortest path from a vertex x to a vertex y? Say I want to find the shortest path from 0 to 3. It's easy to see that the path is 0-2, 2-3 with total weight 0.26+0.17 = 0.43. But how should I construct a general way of doing this? in pseudocode
edge weight
6-2 0,40
4-5 0.35
5-7 0.28
2-3 0.17
0-2 0.26
1-7 0.19
0-7 0.16
In this case, since you are given an MST you only know that the total edge weights in the graph are minimal. However, a path between two nodes in an MST does not guarantee that it is the minimal path between those two nodes on the actual graph. In order to find the minimally weighted path from node x to node y, you can perform Dijkstra's Algorithm on the original graph (not the MST). Dijkstra's can find the minimum distance from a starting node, in this case, x, to every other node in the graph.
Perform Dijkstra's Algorithm as follows and store the information in a table:
Begin at the starting node, x in this case and go to the node with the least weight from x
From the lowest weight node just visited, explore the neighbors and again pick the edge with the lowest weight
Sum up the total cost so far from the edge you are visiting. If you started at x, then visited a, then c, find the total distance from x to a to c.
If the weight to a node is lower than what was previously recorded, update the value in the table because now a shorter path has been found.
Ultimately, after performing this algorithm, the table should contain the lowest weight path from x to y.
The MST does not necessarily contain the shortest path from one vertex x to another vector y. The minimum spanning tree is a tree that has found the minimal path for every node to be visited. This does not necessarily mean that the shortest path from x to y is included in the MST. To find the true shortest path from x to y you would have to run an algorithm to find the shortest path on the original graph, like Dijkstra's.
Assuming that the current PC is 0x00400010 (after increment) and the target label has the value of 0x00400040. What is the binary value of the constant in the instruction?
beq $s0, $s0, target
I'm not really sure how to approach this question. I would appreciate a hint, or explanation of how to find a solution to this.
I am not sure if I have understood your question. I am assuming that you are asking for the offset which will be coded into the instruction.
Since the target is at 0x00400040 and the current PC is at 0x00400010, the offset probably will be 0x00000030 (because 0x00400040 - 0x00400010 = 0x00000030). This can be easily converted into the binary format you asked for:
0000 0000 0000 0000 0000 0000 0011 0000
But please note that I don't know MIPS. In some processor architectures, the offset coded into the instruction is
(target PC) - ((current PC) + (size of current instruction))
Since I don't know MIPS, I don't know what the byte size of the beq instruction is. Thus, I can't compute the offset for this case. If you tell me the size of the beq instruction, I'll make an edit to that answer and add that.
Furthermore, in most processor architectures, relative offsets will be restricted for most instructions. Once again, I don't know MIPS, but chances are that the offset is limited to 16, 12 or even 8 bits. In that case, to get the actual binary offset representation, remove zeroes from the left from the binary number I gave above until only the bits which are used to store the offset are left.
EDIT (taking into account Busy Beaver's comment)
On MIPS, it seems that instructions are aligned to 32 bits / 4 bytes. This allows to store the actual offset needed divided by 4 (the CPU then reads the offset and multiplies it by 4 to compute the actual target). The advantage is that you can store bigger offsets with the bits given. In other words, you save 2 offset bits that way.
In your example, the PC should jump by 0x00000030 bytes to get to the target. The offset stored in the instruction then would be 0x00000030 / 4 which is the same as 0x00000030 >> 2 which is 0x0000000C0. You asked for the binary representation:
0000 0000 0000 0000 0000 0000 0000 1100
When decoding / executing the instruction, the CPU automatically multiplies that offset by four and that way gets back the real offset desired.
In the configuration space, let us say there is a configuration c_1 and a target configuration c_t, is there a way to determine "how far away" c_1 is from c_t? I assume "how far away" can be measures by number of pose changes. Is there a mathematical way of defining this distance between two configurations?
The distance between configuration vectors q_a and q_b in configuration space (C-space) is the norm of the difference between the two vectors (as an aside, configurations are normally denoted q). This is true for any n-dimensional space. The equation for this is:
To explain a bit more - as I'm sure you know, the distance between point a and b in 2D Euclidean space is given by the square root of the summation of the x and y distance squared:
d_x = a_x - b_x
d_y = a_y - b_y
distance = sqrt(d_x^2 + d_y^2)
To generalise this to n dimensions: the distance between two points a and b in an n-dimensional space is given by:
I have been trying to format binary opcodes for Motorola 68000, but I keep finding that it's not possible to encode both the destination memory address, instruction designation and addressing mode/size, and data value to be copied to the address bus for memory-mapped I/O.
For the Sega Genesis' Video Display Processor I am attempting to write to the control port which is memory mapped at C00004 in the Genesis' memory map.
C0004 is 1100 0000 0000 0000 0000 0100 in binary, or three bytes. The value I'm writing is 87, which the VDP recognizes as 8787 in VDP register #7. The issue I'm having is figuring out how to encode 32-bits worth of data, e.g. the instruction prefix designation move.b, value 87, which is #$87, and the destination memory address C00004 for MMIO re-routing to the correct VDP port on the way to the VDP.
Altogether it looks like this:
move.b #$87, $00C00004,
which loosely translates into not four, but four bytes and a nibble(36-bits to be exact!)
0001 1000 0111 1100 0000 0000 0000 0000 0100
Since Motorola 68000 will only parse 32-bits when working down to microcode, how is it possible to encode the required information if there's not enough space(and within the same instruction)?
Perhaps I'm understanding this incorrectly?
I know this is beyond the level most programmers would anticipate, but I'm hoping someone around can break this down for me and explain how this encoding scheme would work.
Your instruction, move.b #$87, $$00C00004 ought to encode to
0001111001111100 0000000010000111 00000000110000000000000000000100
(or similar; I'm not sure about the order of the operands).
The first 16-bit word can be broken down thusly:
The first four bits say that this is a move.b instruction.
The next six bits say that the destination addressing mode is an absolute 32-bit address.
The last six bits say that the source operand is immediate.
After that follows instruction extension words with the operands. The first is 16 bits for the immediate data, and the last 32 bits are for the address. (Might be the other way around.)
For more information, see http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf