Related
So, here is a question when user input 3 than it prints the 7 as output and when user input 7 than it prints 3 as output, but without using any condition and loop.
here is what I done.But the problem is i'm using 2 numbers as input but i have to done it with one input.
void main() {
print(mod(7, 3));
}
int mod(int num1, int num2) {
//3*2 mod 7
//7*2 mod 3
int answer = (num1 * 2) % num2 + 1;
return answer;
}
please help how to do this.You can use any language to solve this.
Let's look at the binary representation of 3 and 7 : 3 is 0...0011 and 7 is 0...0111, which means that the only bit that differs between 3 and 7 is the 3rd bit. Therefore, we can transform 3 into 7 and vice-versa simply by "flipping" that 3rd bit.
"Flipping a bit" can be done with an "exclusive-or" operation. Xor is a very useful operation (one of my favorite): one way to look at it is to consider that you have a data input and a control input, and if the control input is 0, then the data input is left unchanged, but if the control input is 1, then the data input is flipped (you can draw the truth table of Xor to convince yourself of that interpretation). Of course, it's only a way to consider the xor operation, but it's particularly useful in our case : we want to flip the 3rd bit, and leave all of the other bit unchanged.
C offers a "bitwise xor" operation ( A ^ B), which do a xor of each bit of A and B. Therefore, what we want is to have a number, that we will use as the control number, which 3rd bit is 1 and all other bits are 0: this number is 4.
Finally, we can have this function that converts 3 into 7 and vice-versa by simply applying a Xor with 4 to the input.
#include <stdio.h>
int flip(int num1) {
return num1 ^ 4;
}
void main() {
printf("%d", flip(3));
}
I was doing a project in ASM about pascal triangle using NASM
so in the project you need to calculate pascal triangle from line 0 to line 63
my first problem is where to store the results of calculation -> memory
second problem what type of storage I use in memory, to understand what I mean I have 3 way first declare a full matrices so will be like this way
memoryLabl: resd 63*64 ; 63 rows of 64 columns each
but the problem in this way that half of matrices is not used that make my program not efficient so let's go the second method is available
which is declare for every line a label for memory
for example :
line0: dd 1
line1: dd 1,1
line2: dd 1,2,1 ; with pre-filled data for example purposes
...
line63: resd 64 ; reserve space for 64 dword entries
this way of doing it is like do it by hand,
some other from the class try to use macro as you can see here
but i don't get it
so far so good
let's go to the last one that i have used
which is like the first one but i use a triangle matrices , how is that,
by declaring only the amount of memory that i need
so to store line 0 to line 63 line of pascal triangle, it's give me a triangle matrices because every new line I add a cell
I have allocate 2080 dword for the triangle matrices how is that ??
explain by 2080 dword:
okey we have line0 have 1 dword /* 1 number in first line */
line1 have 2 dword /* 2 numbers in second line */
line2 have 3 dword /* 3 numbers in third line */
...
line63 have 64 dword /* 64 numbers in final line*/
so in the end we have 2080 as the sum of them
I have give every number 1 dword
okey now we have create the memory to store results let's start calculation
first# in pascal triangle you have all the cells in row 0 have value 1
I will do it in pseudo code so you understand how I put one in all cells of row 0:
s=0
for(i=0;i<64;i++):
s = s+i
mov dword[x+s*4],1 /* x is addresses of triangle matrices */
second part in pascal triangle is to have the last row of each line equal to 1
I will use pseudo code to make it simple
s=0
for(i=2;i<64;i++):
s = s+i
mov dword[x+s*4],1
I start from i equal to 2 because i = 0 (i=1) is line0 (line1) and line0 (line1)is full because is hold only one (tow) value as I say in above explanation
so the tow pseudo code will make my rectangle look like in memory :
1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
1 1
...
1 1
now come the hard part is the calculation using this value in triangle to fill all the triangle cells
let's start with the idea here
let's take cell[line][row]
we have cell[2][1] = cell[1][0]+cell[1][1]
and cell[3][1]= cell[2][0]+cell[2][1]
cell[3][2]= cell[2][1]+cell[2][2]
in **general** we have
cell[line][row]= cell[line-1][row-1]+cell[line-1][row]
my problem I could not break this relation using ASM instruction because i have a
triangle matrices which weird to work with can any one help me to break it using a relation or very basic pseudo code or asm code ?
TL:DR: you just need to traverse the array sequentially, so you don't have to work out the indexing. See the 2nd section.
To random access index into a (lower) triangular matrix, row r starts after a triangle of size r-1. A triangle of size n has n*(n+1)/2 total elements, using Gauss's formula for the sum of numbers from 1 to n-1. So a triangle of size r-1 has (r-1)*r/2 elements. Indexing a column within a row is of course trivial, once we know the address of the start of a row.
Each DWORD element is 4 bytes wide, and we can take care of that scaling as part of the multiply, because lea lets us shift and add as well as put the result in a different register. We simplify n*(n-1)/2 elements * 4 bytes / elem to n*(n-1) * 2 bytes.
The above reasoning works for 1-based indexing, where row 1 has 1 element. We have to adjust for that if we want zero-based indexing by adding 1 to row indices before the calculation, so we want the size of a triangle
with r+1 - 1 rows, thus r*(r+1)/2 * 4 bytes. It helps to put the linear array index into a triangle to quickly double-check the formula
0
4 8
12 16 20
24 28 32 36
40 44 48 52 56
60 64 68 72 76 80
84 88 92 96 100 104 108
The 4th row, which we're calling "row 3", starts 24 bytes from the start of the whole array. That's (3+1)*(3+1-1) * 2 = (3+1)*3 * 2; yes the r*(r+1)/2 formula works.
;; given a row number in EDI, and column in ESI (zero-extended into RSI)
;; load triangle[row][col] into eax
lea ecx, [2*rdi + 2]
imul ecx, edi ; ecx = r*(r+1) * 2 bytes
mov eax, [triangle + rcx + rsi*4]
This assuming 32-bit absolute addressing is ok (32-bit absolute addresses no longer allowed in x86-64 Linux?). If not, use a RIP-relative LEA to get the triangle base address in a register, and add that to rsi*4. x86 addressing modes can only have 3 components when one of them is a constant. But that is the case here for your static triangle, so we can take full advantage by using a scaled index for the column, and base as our calculated row offset, and the actual array address as the displacement.
Calculating the triangle
The trick here is that you only need to loop over it sequentially; you don't need random access to a given row/column.
You read one row while writing the one below. When you get to the end of a row, the next element is the start of the next row. The source and destination pointers will get farther and farther from each other as you go down the rows, because the destination is always 1 whole row ahead. And you know the length of a row = row number, so you can actually use the row counter as the offset.
global _start
_start:
mov esi, triangle ; src = address of triangle[0,0]
lea rdi, [rsi+4] ; dst = address of triangle[1,0]
mov dword [rsi], 1 ; triangle[0,0] = 1 special case: there is no source
.pascal_row: ; do {
mov rcx, rdi ; RCX = one-past-end of src row = start of dst row
xor eax, eax ; EAX = triangle[row-1][col-1] = 0 for first iteration
;; RSI points to start of src row: triangle[row-1][0]
;; RDI points to start of dst row: triangle[row ][0]
.column:
mov edx, [rsi] ; tri[r-1, c] ; will load 1 on the first iteration
add eax, edx ; eax = tri[r-1, c-1] + tri[r-1, c]
mov [rdi], eax ; store to triangle[row, col]
add rdi, 4 ; ++dst
add rsi, 4 ; ++src
mov eax, edx ; becomes col-1 src value for next iteration
cmp rsi, rcx
jb .column ; }while(src < end_src)
;; RSI points to one-past-end of src row, i.e. start of next row = src for next iteration
;; RDI points to last element of dst row (because dst row is 1 element longer than src row)
mov dword [rdi], 1 ; [r,r] = 1 end of a row
add rdi, 4 ; this is where dst-src distance grows each iteration
cmp rdi, end_triangle
jb .pascal_row
;;; triangle is constructed. Set a breakpoint here to look at it with a debugger
xor edi,edi
mov eax, 231
syscall ; Linux sys_exit_group(0), 64-bit ABI
section .bss
; you could just as well use resd 64*65/2
; but put a label on each row for debugging convenience.
ALIGN 16
triangle:
%assign i 0
%rep 64
row %+ i: resd i + 1
%assign i i+1
%endrep
end_triangle:
I tested this and it works: correct values in memory, and it stops at the right place. But note that integer overflow happens before you get down to the last row. This would be avoided if you used 64-bit integers (simple change to register names and offsets, and don't forget resd to resq). 64 choose 32 is 1832624140942590534 = 2^60.66.
The %rep block to reserve space and label each row as row0, row1, etc. is from my answer to the question you linked about macros, much more sane than the other answer IMO.
You tagged this NASM, so that's what I used because I'm familiar with it. The syntax you used in your question was MASM (until the last edit). The main logic is the same in MASM, but remember that you need OFFSET triangle to get the address as an immediate, instead of loading from it.
I used x86-64 because 32-bit is obsolete, but I avoided too many registers, so you can easily port this to 32-bit if needed. Don't forget to save/restore call-preserved registers if you put this in a function instead of a stand-alone program.
Unrolling the inner loop could save some instructions copying registers around, as well as the loop overhead. This is a somewhat optimized implementation, but I mostly limited it to optimizations that make the code simpler as well as smaller / faster. (Except maybe for using pointer increments instead of indexing.) It took a while to make it this clean and simple. :P
Different ways of doing the array indexing would be faster on different CPUs. e.g. perhaps use an indexed addressing mode (relative to dst) for the loads in the inner loop, so only one pointer increment is needed. But if you want it to run fast, SSE2 or AVX2 vpaddd could be good. Shuffling with palignr might be useful, but probably also unaligned loads instead of some of the shuffling, especially with AVX2 or AVX512.
But anyway, this is my version; I'm not trying to write it the way you would, you need to write your own for your assignment. I'm writing for future readers who might learn something about what's efficient on x86. (See also the performance section in the x86 tag wiki.)
How I wrote that:
I started writing the code from the top, but quickly realized that off-by-one errors were going to be tricky, and I didn't want to just write it the stupid way with branches inside the loops for special cases.
What ended up helping was writing the comments for the pre and post conditions on the pointers for the inner loop. That made it clear I needed to enter the loop with eax=0, instead of with eax=1 and storing eax as the first operation inside the loop, or something like that.
Obviously each source value only needs to be read once, so I didn't want to write an inner loop that reads [rsi] and [rsi+4] or something. Besides, that would have made it harder to get the boundary condition right (where a non-existant value has to read as 0).
It took some time to decide whether I was going to have an actual counter in a register for row length or row number, before I ended up just using an end-pointer for the whole triangle. It wasn't obvious before I finished that using pure pointer increments / compares was going to save so many instructions (and registers when the upper bound is a build-time constant like end_triangle), but it worked out nicely.
I am reading and studying The Elements of Computing Systems but I am stuck at one point. Sample chapter skip the next 5 instruction s can be found here.
Anyway, I am trying to implement a Virtual Machine (or a byte code to assembly translator) but I am stuck at skip the next 5 instruction one point.
You can find the assembly notation here.
The goal is to implement a translator that will translate a specific byte code to this assembly code.
An example I have done successfully is for the byte code
push constant 5
which is translated to:
#5
D=A
#256
M=D
As I said, the assembly language for Hack is found in the link I provided but basically:
#5 // Load constant 5 to Register A
D=A // Assign the value in Reg A to Reg D
#256// Load constant 256 to Register A
M=D // Store the value found in Register D to Memory Location[A]
Well this was pretty straight forward. By definition memory location 256 is the top of the stack. So
push constant 5
push constant 98
will be translated to:
#5
D=A
#256
M=D
#98
D=A
#257
M=D
which is all fine..
I also want to give one more example:
push constant 5
push constant 98
add
is translated to:
#5
D=A
#256
M=D
#98
D=A
#257
M=D
#257 // Here starts the translation for 'add' // Load top of stack to A
D=M // D = M[A]
#256 // Load top of stack to A
A=M // A = M[A]
D=D+A
#256
M=D
I think it is pretty clear.
However I have no idea how I can translate the byte code
eq
to Assembly. Definition for eq is as follows:
Three of the commands (eq, gt, lt) return Boolean values. The VM
represents true and false as -1 (minus one, 0xFFFF) and 0 (zero,
0x0000), respectively.
So I need to pop two values to registers A and D respectively, which is quite easy. But how am I supposed to create an Assembly code that will check against the values and push 1 if the result is true or 0 if the result is false?
The assembly code supported for Hack Computer is as follows:
I can do something like:
push constant 5
push constant 6
sub
which will hold the value 0 if 2 values pushed to the stack are equal or !0 if not but how does that help? I tried using D&A or D&M but that did not help much either..
I can also introduce a conditional jump but how am I supposed to know what instruction to jump to? Hack Assembly code does not have something like "skip the next 5 instructions" or etc..
[edit by Spektre] target platform summary as I see it
16bit Von Neumann architecture (address is 15 bits with 16 bit Word access)
Data memory 32KW (Read/Write)
Instruction (Program) memory 32KW (Read only)
native 16 bit registers A,D
general purpose 16 bit registers R0-R15 mapped to Data memory at 0x0000 - 0x000F
these are most likely used also for: SP(R0),LCL(R1),ARG(R2),This(R3),That(R4)
Screen is mapped to Data memory at 0x4000-0x5FFF (512x256 B/W pixels 8KW)
Keyboard is mapped to Data memory at 0x6000 (ASCII code if last hit key?)
It appears there is another chapter which more definitively defines the Hack CPU. It says:
The Hack CPU consists of the ALU specified in chapter 2 and three
registers called data register (D), address register (A), and program
counter (PC). D and A are general-purpose 16-bit registers that can be
manipulated by arithmetic and logical instructions like A=D-1 , D=D|A
, and so on, following the Hack machine language specified in chapter
4. While the D-register is used solely to store data values, the contents of the A-register can be interpreted in three different ways,
depending on the instruction’s context: as a data value, as a RAM
address, or as a ROM address
So apparently "M" accesses are to RAM locations controlled by A. There's the indirect addressing I was missing. Now everything clicks.
With that confusion cleared up, now we can handle OP's question (a lot more easily).
Let's start with implementing subroutine calls with the stack.
; subroutine calling sequence
#returnaddress ; sets the A register
D=A
#subroutine
0 ; jmp
returnaddress:
...
subroutine: ; D contains return address
; all parameters must be passed in memory locations, e.g, R1-R15
; ***** subroutine entry code *****
#STK
AM=M+1 ; bump stack pointer; also set A to new SP value
M=D ; write the return address into the stack
; **** subroutine entry code end ***
<do subroutine work using any or all registers>
; **** subroutine exit code ****
#STK
AM=M-1 ; move stack pointer back
A=M ; fetch entry from stack
0; jmp ; jmp to return address
; **** subroutine exit code end ****
The "push constant" instruction can easily be translated to store into a dynamic location in the stack:
#<constant> ; sets A register
D=A ; save the constant someplace safe
#STK
AM=M+1 ; bump stack pointer; also set A to new SP value
M=D ; write the constant into the stack
If we wanted to make a subroutine to push constants:
pushR2: ; value to push in R2
#R15 ; save return address in R15
M=D ; we can't really use the stack,...
#R2 ; because we are pushing on it
D=M
#STK
AM=M+1 ; bump stack pointer; also set A to new SP value
M=D ; write the return address into the stack
#R15
A=M
0 ; jmp
And to call the "push constant" routine:
#<constant>
D=A
#R2
M=D
#returnaddress ; sets the A register
D=A
#pushR2
0 ; jmp
returnaddress:
To push a variable value X:
#X
D=M
#R2
M=D
#returnaddress ; sets the A register
D=A
#pushR2
0 ; jmp
returnaddress:
A subroutine to pop a value from the stack into the D register:
popD:
#R15 ; save return address in R15
M=D ; we can't really use the stack,...
#STK
AM=M-1 ; decrement stack pointer; also set A to new SP value
D=M ; fetch the popped value
#R15
A=M
0 ; jmp
Now, to do the "EQ" computation that was OP's original request:
EQ: ; compare values on top of stack, return boolean in D
#R15 ; save return address
M=D
#EQReturn1
D=A
#PopD
0; jmp
#EQReturn1:
#R2
M=D ; save first popped value
#EQReturn2
D=A
#PopD
0; jmp
#EQReturn2:
; here D has 2nd popped value, R2 has first
#R2
D=D-M
#EQDone
equal; jmp
#AddressOfXFFFF
D=M
EQDone: ; D contains 0 or FFFF here
#R15
A=M ; fetch return address
0; jmp
Putting it all together:
#5 ; push constant 5
D=A
#R2
M=D
#returnaddress1
D=A
#pushR2
0 ; jmp
returnaddress1:
#X ; now push X
D=M
#R2
M=D
#returnaddress2
D=A
#pushR2
0 ; jmp
returnaddress2:
#returnaddress3 ; pop and compare the values
D=A
#EQ
0 ; jmp
returnaddress3:
At this point, OP can generate code to push D onto the stack:
#R2 ; push D onto stack
M=D
#returnaddress4
D=A
#pushR2
0 ; jmp
returnaddress4:
or he can generate code to branch on the value of D:
#jmptarget
EQ ; jmp
As I wrote in last comment there is a branch less way so you need to compute the return value from operands directly
Lets take the easy operation like eq for now
if I get it right eq a,d is something like a=(a==d)
true is 0xFFFF and false is 0x0000
So this if a==d then a-d==0 this can be used directly
compute a=a-d
compute OR cascade of all bits of a
if the result is 0 return 0
if the result is 1 return 0xFFFF
this can be achieved by table or by 0-OR_Cascade(a)
the OR cascade
I do not see any bit shift operations in your description
so you need to use a+a instead of a<<1
and if shift right is needed then you need to implement divide by 2
So when I summarize this eq a,d could look like this:
a=a-d;
a=(a|(a>>1)|(a>>2)|...|(a>>15))&1
a=0-a;
you just need to encode this into your assembly
as you do not have division or shift directly supported may be this may be better
a=a-d;
a=(a|(a<<1)|(a<<2)|...|(a<<15))&0x8000
a=0-(a>>15);
the lower and greater comparison are much more complicated
you need to compute the carry flag of the substraction
or use sign of the result (MSB of result)
if you limit the operands to 15 bit then it is just the 15th bit
for full 16 bit operands you need to compute the 16th bit of result
for that you need to know quite a bit of logic circuits and ALU summation principles
or divide the values to 8 bit pairs and do 2x8 bit substraction cascade
so a=a-d will became:
sub al,dl
sbc ah,dh
and the carry/sign is in the 8th bit of result which is accessible
In languages such as... well anything, both operators for < and <= (and their opposites) exist. Which would be faster, and how are they interpreted?
if (x <= y) { blah; }
or
if (x < y + 1) { blah; }
Assuming no compiler optimizations (big assumption), the first will be faster, as <= is implemented by a single jle instruction, where as the latter requires an addition followed by a jl instruction.
http://en.wikibooks.org/wiki/X86_Assembly/Control_Flow#Jump_if_Less
I wouldn't worry about this at all as far as performance goes. Using C as an example, on a simple test I ran with GCC 4.5.1 targeting x86 (with -O2), the (x <=y ) operation compiled to:
// if (x <= y) {
// printf( "x <= y\n");
// }
//
// `x` is [esp+28]
// `y` is [esp+24]
mov eax, DWORD PTR [esp+24] // load `y` into eax
cmp DWORD PTR [esp+28], eax // compare with `x`
jle L5 // if x < y, jump to the `true` block
L2:
// ...
ret
L5: // this prints "x <= y\n"
mov DWORD PTR [esp], OFFSET FLAT:LC1
call _puts
jmp L2 // jumps back to the code after the ` if statement
and the (x < y + 1) operation compiled to:
// if (x < y +1) {
// printf( "x < y+1\n");
// }
//
// `x` is [esp+28]
// `y` is [esp+24]
mov eax, DWORD PTR [esp+28] // load x into eax
cmp DWORD PTR [esp+24], eax // compare with y
jl L3 // jump past the true block if (y < x)
mov DWORD PTR [esp], OFFSET FLAT:LC2
call _puts
L3:
So you might have a difference of a jump around a jump or so, but you should really only be concerned about this kind of thing for the odd time where it really is a hot spot. Of course there may be differences between languages and what exactly happens might depend on the type of objects that are being compared. But I'd still not worry about this at all as far as performance is concerned (until it became a demonstrated performance issue - which I'll be surprised if it ever does for more than once or twice in my lifetime).
So, I think the only two reasons to worry about which test to use are:
correctness - of course, this trumps any other consideration
style/readabilty
While you might not think there's much to the style/readability consideration, I do worry about this a little. In my C and C++ code today, I'd favor using the < operator over <= because I think loops tend to terminate 'better' using a < than a <= test. So, for example:
iterating over an array by index, you should typically use an index < number_of_elements test
iterating over an array using pointers to elements should use a ptr < (array + number_of_elements) test
Actually even in C, I now tend to use a ptr != (array + number_of_elements) since I've gotten used to STL iterators where the < relation won work.
In fact, if I see a <= test in a for loop condition, I take a close look - often there's a bug lurking. I consider it an anti-pattern.
Noe I'll grant that a lot of this may not hold for other languages, but I be surprised if when I'm using another language that there's ever a performance issues I'll have to worry about because I chose to use < over <=.
What data-type?
If y is INT_MAX, then the first expression is true no matter what x is (assuming x is the same or smaller type), while the second expression is always false.
If the answer doesn't need to be right, you can get it even faster.
Have you considered that both those arguments are different? In case x and y are floating point numbers - they may not give the same result. That is the reason both comparison operators exists.
Prefer the first one.
In some languages with dynamic types the running environment has to figure out what the type of y is and execute the appropriate + operator.
Leaving this as vague as you have has caused this to be an unanswerable question. Performance cannot be evaluated unless you have software and hardware to measure - what language? what language implementation? what target CPU architecture? etc.
That being said, both <= and < are often identical performance-wise, because they are logically equivalent to > and >=, just with swapped destinations for the underlying goto's (branch instructions), or swapped logic for the underlying "true/false" evaluation.
If you're programming in C or C++, the compiler may be able to figure out what you're doing, and swap in the faster alternative, anyway.
Write code that is understandable, maintainable, correct, and performant, in that order. For performance, find tools to measure the performance of your whole program, and spend your time wisely. Optimize bottlenecks only until your program is fast enough. Spend the time you save by making better code, or making more cool features :)
This question already has answers here:
How does finding a cycle start node in a cycle linked list work?
(23 answers)
Closed 5 years ago.
From several posts inside stackoverflow and outside, I have come to know how to detect cycles in a linked list, the length of a cycle. I also found the method on how to detect the start of the loop.
Here are the steps again for reference.
Detecting Loop:
Have two pointers, classically called hare and tortoise. Move hare by 2 steps and tortoise by 1. If they meet at some point, then there is surely a cycle and the meeting point is obviously inside the cycle.
Finding length of Loop:
Keep one pointer fixed at meeting point while increment the other until they are same again. Increment a counter as you go along and the counter value at meet will be the length of cycle.
Find the start of cycle
Take one pointer to start of the list and keep the other at the meeting point. Now increment both by one and the meet point is the start of loop. I verified the method using some cases on paper, but I don't understand why it should work.
Can someone, provide a mathematical proof as to why this method works?
If you represent a list by a pointer to its first node (list)
The algorithm to detect loops is described as follows:
Declare two pointers (pFast) and (pSlow).
Make pSlow and pFast point to list.
Until (pSlow), (pFast) or both point to NULL:
If , then STOP as a loop has just been found.
If this point has been reached (one or both two pointers are NULL) then there are no loops in the list.
Lets assume that this algorithm is correct.
In this scheme, a loop situation is represented by the following diagram:
Note how every node, except the one pointing to the begining of a loop, is labeled with the number of its target minus one. So, if one node is labeled with i and it is not the begining of a loop, then it is pointed as next element by the node labeled with i-1.
The algorithm explained above can be described as a loop since its main step (3) is a set of sub-steps which repeated until the exit condition is satisfied. That forces us to represent pFast and pSlow in function of the iteration number in the algorithm execution (t).
If the list hadn’t have loops, pointers positions would be described in function of t as:
However there is a node where the loop starts and that function stops describing the evolution of the pointers. Assuming that this pointer is tagged with m, that the loop contains nodes (that is and ), and setting t=0 as iteration value when then:
If one pointer is indeed enough to detect loops using the algorithm described, then it must exist at least a solution to the equation .
This equation is true if and only if there is a value for t that makes:
This ends in a function, which generates values of t that are valid solutions to the equation described above:
Thus It is proved that one slow pointer and one fast pointer are enough to detect loop conditions in a linked list.
You can make your 'Find the start of cycle' proof simpler if you don't use meeting point.
Let second pointer start not at the 'meeting point', but M steps ahead of first pointer. (Where M is the length of the loop.)
This way, proof is pretty obvious. When the first pointer reaches start of the loop, second will be exactly M steps ahead: also at the start of the loop.
Distance travelled by slowPointer before meeting = x + y
Distance travelled by fastPointer before meeting = (x + y + z) + y = x + 2y + z
Since fastPointer travels with double the speed of slowPointer, and time is constant for both when the reach the meeting point.
So by using simple speed, time and distance relation 2(x+y)= x+2y+z => x+2y+z = 2x+2y => x=z
Hence by moving slowPointer to start of linked list, and making both slowPointer and fastPointer to move one node at a time, they both have same distance to cover .
They will reach at the point where the loop starts in the linked list.
The second part, stating that "to find the start of the loop, just move one pointer back to the start of the list then iterate both until they meet" is wrong!
It is correct only if the fast pointer has gone round the loop exactly once - i.e. that the portion before the start of the loop is shorter than the length of the loop - but if it is longer then the algorithm doesn't work; you can get stuck in an infinite loop.
Try it with a linked list with 11 elements, where the 11th points to the 7th:
1 1 -> 3 2 -> 5 3 -> 7 4 -> 9 5 -> 11 6 -> 8 7 -> 10 8 -> 7 9 -> 9 9
-- loop detected
Move one back to start and increment them:
1 9 -> 2 10 -> 3 11 -> 4 7 -> 5 8 -> 6 9 -> 7 10 -> 8 11 -> 9 7 -> 10 8 -> 11 9 -> 7 10 -> 8 11 ->...
/* Algorithm : P2 is moving through the list twice as fast as P1.
If the list is circular, it will eventually get around P1 and meet */
public boolean hasCycle()
{
DoubleNode p1,p2;
p1=p2=firstNode; //Start with the first loop
try
{
while (p2 != null) //If p2 reaches end of linked list, no cycle exists
{
p1=p1.next; //Move to next
p2=p2.next.next; //Move to 2 steps next
if(p1==p2)
return true; //p1 and p2 met, so this means that there is a cycle
}
}
catch(NullPointerException npe)
{
//This means that p2 could not move forward
return false;
}
return false;
}