Re: Memory leak?
- Posted by jimcbrown (admin) Feb 13, 2014
- 3506 views
Jim
The 112!/3! was a stupid error and certainly not = 112*111*110. I realised after I submitted that it was stupid.
Okay.
I choose 3 stars in order. If I choose 1 2 3 then I will not choose 2 1 3 later and vice versa.
Ok, so it's a combination without repetition in that case.
But I could have as I did not specify a particular order (like the key of a combination lock).
If you did so, then you'd change it into a permutation. Why would gwalters want to do that though? He's better off doing a combination if he can get away with it (as that means fewer overall computations).
So, I guess, Derek is wrong on that.
I disagree. If we both agree that it's a case of using combination without repetition, then Derek's original number is correct.
If gwalters is doing a permutation instead (either because he has to, or perhaps because gwalters enjoys the music of gnashing hard disks and the flash of blinkenlights), then Derek's number is wrong.
Second the point about accuracy. Quoting:
"I'm looking for star triplets that are in a straight line and are not off the straight line more then 1 arc sec."
That sounds to me like testing for collinearity with stars close together will have accuracy problems.
The data on star position is supposedly accurate to 2.5 milliarcseconds. So the margin of error is 400 times smaller than what gwalters is looking for. There's always room for errors in measurement and other forms of accuracy, but it seems that gwalters has plently of wiggle room.
Third:
I would have thought Derek's approach was obvious but it has a problem in that a star may be collinear with a star or stars not in the 112 chosen. I have no idea how close together stars need to be to be considered "in a line". This is a complication.
I agreed that this looks like a potential complication, but it's also one present in the original EDBC using program.
