Math Puzzle Challenge For You Wizards.

[CoyoteRed]

We've all seen them. The fill in the blank puzzles where you look up dead people's names or dates, or count some objects, and fill in the blank. One for one. Find the number, have the number for that position in the coords. Pretty simple.

 

...but not very secure. In many cases you can skip one or more numbers and still find the cache. For instance, if you are missing the .0x0 (one hundredths) of the minute, there are only 10 places where it could be. Plus, if you are smart about it you can eliminate many of the 10 and narrow it down even further.

 

In short, this scheme is not secure. It's fine for many instances, but not all. Try to get more secure and you start needing advanced math or have other issues in the field.

 

Here's the challenge. Come up with a simplest, but secure, scheme to produce an offset to use against a given set of coordinates. You can use 6-10 numbers as clues. (Flexible use of numbers with the same scheme is prefered.) You must use only math that can be done on paper and in field, or on a plain calculator, i.e. add, subtract, multiply, and divide.

 

Here's the kicker: change only one number and the resulting offset can change to anywhere within the total range for that scheme for both numbers that make up the coordinates.

 

I thought up one this afternoon, but I'm sure there can be and easier way. I'll post mine below.

 

Can you come up with a better one?

[CoyoteRed]

This is what I thought up. It's kind of cumbersome, but can be done on paper and I'm thinking it'd be pretty hard to guess at the coordinates with just one missing number.

 

A series of 8 numbers (could be more or less) between 1 - 99.

 

Example:27 73 14 92 43 56 21 84

 

Arrange the numbers in ascending order and then label A-H.

 

14-A, 21-B, 27-C, 43-D, 56-E, 73-F, 84-G, 92-H

 

You now calculate two numbers using the following:

 

(A+E)*(B+F)*(C+G)/(D*H) for Lat offset and (A+G)*(B+E)*(C+H)/(D*F) for Long offset

 

In this example:

 

A+E=14+56=70

B+F=21+73=94

C+G=27+84=111

D*H=43x92=3956

70 x 94 x 111 / 3956=184.62588

 

For the other equation, it is 286.07008

 

This math can be kept staight fairly easily if there is a premade template to use.

 

To get the offset from the above numbers, the hider designates which part of the number to use. i.e. XX_._ _ _ which would mean the offset would be 4.625 and 6.070. Add these to a predetermined set of coordinates to find the cache.

 

The entire clue set could be, "Using CR's puzzle scheme you are looking for 8 numbers. Distill these to XX_._ _ _ and add to N32° 32.834 W080° 43.883 to find the cache."

 

In this example the resulting coords would be N32° 37.459 W080° 49.953.

 

You can see if you change any one number the end result is vastly different for both results and in this case anywhere within a 100 square minute area! While not every number will result in a logical end number, the possiblities are pretty large for someone doing this with just a pad of paper. The offset can be large or small. It can be adapted to more or fewer numbers.

 

Like I said, pretty cumbersome. But it can be done in the field and is a lot more secure.

[2oldfarts (the rockhounders)]

Sent you an E-mail. If you wish to share it on the forums feel free to do so.

 

John

[CoyoteRed]

Get your coordinates, say 45 XX.XXX & 110 XX.XXX.  Divide XX.XXX by Y where Y is the last number they will find.

They must find the digits  from your division answer and then multiply by Y. Substituting another number for Y will throw the answer way off course. Substituting for any of the digits in the answer could throw the coordinates off by as much as 2,600 feet or more. For example you have the digits XX.101 and a multiplier of 5 your answer would be XX.505, but if you substituted a 9 for the 0 (as in XX.1X1) you would get XX.945 (which is off by 2,640 feet).

You could do this for either one or both set of numbers (Lat/Long).

This is what John sent me.

 

Not bad. Harder to crack than the straight foward fill-in-the-blanks. A lot easier than mine that's for sure!

[+SylvrStorm]

Can you come up with a better one?

I wouldn't say it's necessarily better, and it's not generic like yours or 2oldfarts, but I've got a cache that I think you need every number to find: Memorial Benches.

 

I like the fact that it's not an offset (unless you count it as an offset from the minute integers). You are calculating the actual coords directly. Took a bit of fiddling with the numbers to get it to work out. By calculating the coords directly, you reduce the hidden clues, like 'this digit will have to be less than three for it to work out'.

 

I think the key to anything like this is to include multiplication with a minimum of one two digit number, and if there's any addition in the final step, it must be at least a two digit number, and those digits must be completely unpredictable. At a more fundamental level, it's important to use math (even simple math) rather than direct substitution, because then the impact of one missing number will always be to more than a single digit in the final solution.

 

SylvrStorm

[+geo-jedi]

Factors work. We did a cache that required the multiplication of a set of numbers to come up with the coordinates of the cache. The final product was 17 digits. The last fifteen represented the coords. Do make it even more secure, you could make the middle fifteen the coords.

 

The hard part is finding the factors once you know where the final cache is going to be. Fortunately, there are factoring programs out there that will help. You may have to play with the non-coord digits a bit to come up with reasonable factors.

 

We did this as a puzzle cache where factors were left in a number of caches that needed to be found first. This technique prevented anyone from guessing the final coords without having found all of the preliminaries.

 

As an example, your GCGY97 hide at 33 12.221 79 58.371 would be

embedded in 8733122217958371 which is the product of

3

31

109

766,261 and

1,124,303.

 

or in 2533122217958371 which is the product of

169

19

31

227

233, and

481,141.

 

Team Geo-Jedi

[+nfa]

The hard part is finding the factors once you know where the final cache is going to be. Fortunately, there are factoring programs out there that will help. You may have to play with the non-coord digits a bit to come up with reasonable factors.

Hi,

 

where did you get the factoring program? Is it a download, if so, from where?

 

thanks

 

nfa

[+LETaylor]

All of the above points out that fact that there are a vareity of reasons that people get involved in this sport. From families with little kids they want to take on walks, to those who want to develop "secret codes". The beauty is that there's no reason why everyone can't take part at the level they desire. One isn't better than the other, it's just different.

 

I'm just looking for a cache that contains a cold glass of milk and three oreo cookies.

[+fizzymagic]

Just use SHA-1.

 

You can't calculate SHA-1 in your head? For shame!

 

Seriously, what you describe is exactly what secure hash algorithms are designed to do.

 

However, a trivial and simple way to achieve what you want is to use a sum and reverse the digits.

 

e.g. XX + YY + ZZ = CBA

 

latitude = 37 19.ABC

[CoyoteRed]

Factors work. ...

I was excited about this until I realized my calculator only does 8 digits.

 

I thought about doing it with only one of the pair of coords but that defeats the "change one number and both coords change" critiria.

 

It does present an interesting direction, though...

[+nfa]

ok...how about this?

 

location: N 44 22.332 W 74 11.798

 

for north coords, give cachers 2.2459786 and have them hunt the number to multiply this number by to yield coords (in this case, my year of birth, 1969, which would give them 4422.3318, and have them round the 1000ths place)

 

for west coords, give cachers 3.7719073 and have them hunt the number to multiply this number by to yield coords (in this case, my wife's year of birth, 1965, which would give them 7411.7978, and have them round the 1000ths place)

 

to make the #s you give the cachers, you simply take the coords with degrees and minutes on one side of the decimal, and the last 3 digits on the other side, and divide it by the number you need plugged in (this is based on whatever clue you have them find the answer to)

 

this would yield the correct coords, prevent lucky guesses, can be done on very basic calculators, and can be easily adapted to meet individual cache needs...what's the blatant dumb-a** factor I'm missing?

 

nfa

Edited May 19, 2004 by NFA

[CoyoteRed]

However, a trivial and simple way to achieve what you want is to use a sum and reverse the digits.

 

e.g.  XX + YY + ZZ = CBA

 

latitude = 37 19.ABC

Ah! I was wondering when you'd show up!

 

Your solution works grandly for one direction. Got a way for changing just one of a series of numbers and it affects both directions?

 

Maybe a combination of yours and geo-jedi's?

 

XX * YY * ZZ = FEDCBA (This could be any combination of simple math. Even addition with sufficient number of large numbers. )

 

32° 19. ACE 80° 49.BDF

 

Longitude is not as sensitive to change as the latitude, but it seems as though it could work.

Edited May 19, 2004 by CoyoteRed

[+GSVNoFixedAbode]

I'm looking at a slightly different route but just as simple & secure.

Give the full co-ords on the page but encryped with a modified (a-Z+0-9) Vigenere Cipher (google it! ) Then the cachers need to find the text/numeric key to decode.

 

The beauty of this is that it could be done on paper out in the field so to speak.

[MOCKBA]

I think that the hallmark of geocache math puzzle is that the calculation should result in a meaningful location ... within the available contraints such as what state it's in, distance from a known point, terrain type, property ownership, etc. ... it's like a checksum if you think you solved everything, or like a magic wand if you are still missing some elements.

I like geo-puzzles & I seldom care about "standalone" math puzzles, possibly because the distance contraints, the maps, the aerial photos add a lot to my fun. The puzzle just comes alive.

BTW in one of my puzzles you have to factor in the terrain in your computations, because you are looking for the intersection of a certain shape with the actual ground level: Suspended between Benchmarks

Here are some shots of an analytical

vs. analog

solutions

[+geo-jedi]

CR,

 

When we first set this up for a puzzle cache, we considered using a 19 digit number which is more precision than most calculators and computer based spreadsheets. To get the right answer would require doing at least some of the calculations with pencil and paper. We then decided that was too mean.

 

For a simpler scheme with fewer digits, one can use the following idea...

 

lat is XX xx.abc, lon is YYY yy.def where you give the XX xx and YYY yy.

 

Then the product of the factors is ZabcdefZ. Sandwiching the required decimal minutes makes the scheme more "secure". Again, the only security that is of concern is that the person can't guess the final answer without finding all of the preliminaries.

 

This scheme doesn't work so easily when the "factors" are simply numbers that are visible on signs or statutes. It is better if the factors are numbers that are placed in micros or somehow under the control of the cacher.

 

Geo-Jedi

[CoyoteRed]

I understand all about ciphers. We've got plenty of those around here already, simple substitution, Ceasar Shift, Vigenere, and more.

 

This is not about making a puzzle for a cache, but more of a way to get a more secure scheme than the one-for-one substitution of numbers found in the field to the coordinates.

 

We've had some pretty good ideas so far!

[+fizzymagic]

Your solution works grandly for one direction.  Got a way for changing just one of a series of numbers and it affects both directions?

Oops. I didn't notice that. Since I usually do the lat and long as separate problems, it didn't occur to me.

 

Simple enough solution, though; suppose your coords are DD MM.ABC and DDD MM.DEF, where the unknowns are ABC and DEF.

 

Choose XXX, YYY, and ZZZ such that:

 

XXX + YYY + ZZZ = CBA

XXX * YYY / ZZZ = FED

 

This doesn't give you complete choice of XXX, YYY, and ZZZ, but it is relatively simple and has the properties you desire.

 

A couple of others I think would be fun:

 

XXX + YYY = CBA

XXX - YYY = FED

 

uses fewer numbers but is still quite secure from your perspective. Same thing goes for:

 

XX * YY = CBA

XX / YY * 1000 = FED

 

That one is a little harder, perhaps, and restricts your choices of ABC and DEF a little.

 

This was a fun problem to think about.

[CoyoteRed]

Here's a thought, by using the number rearranging aspect presented by FM and the factoring of GJ you can satisfy all of the critiria of the original post.

 

If you have dd° mA.BCD ddd° mE.FGH and the ABCDEFGH are the numbers you have to work with, you can use a permutation of those numbers to factor out to numbers that are more suitable. You eliminate the need for extra throw-away digits.

 

You would end up with:

 

XX * YY * ZZZ =

 

_ _ _ _ _ _ _ _

D G A H F C B E

 

32° 1A.BCD 80° 4E.FGH

 

A little bit harder to do it on paper, but can be done. Pretty easy with a calculator.

 

Any one number missing will throw off the final coords--in both directions.

Can be done on paper, pretty easy with a basic calculator.

Has the potential for a large physical range and the range is flexible.

Number of "seed numbers" is flexible.

Not complicated for the finder.

Seems to be fairly "guess-proof."

[+nfa]

Hi,

 

I still like the simple one I came up with yesterday...it doesn't require advanced mathematics, can be done on a basic calculator, and can easily work for any coords and given number as key.

 

nfa

[CoyoteRed]

Hi,

 

I still like the simple one I came up with yesterday...it doesn't require advanced mathematics, can be done on a basic calculator, and can easily work for any coords and given number as key.

 

nfa

While it is certainly one way of munging coordinates, it's not exactly what I was looking for. I didn't specify, but I was looking for intergers and numbers with fewer digits for the seed. Plus, I wanted to change any one seed number and both numbers of the coordinates change.

 

In my last example, the finder simply needs to multiply all of the numbers together and enter them into the template to get the coords. Once the finder has all of the required numbers it's a simple two step process to complete--much easier than my original scheme.

[CoyoteRed]

Okay, I've created a page that does something like what I was talking about.

 

You take your four least significant numbers on your pair set for your coordinates and plug the 8 digits into the input box. This program takes the numbers and randomly shuffles them and finds the prime factors of the resulting number. I've limited the result to primes no larger than 200.

 

You would them create a puzzle with those numbers where the finder would then reconstruct the coordinates by multiplying the numbers together and using a provided template.

 

You can combine the primes into different numbers or split the primes into two questions to be added together. The possibilites are endless.

 

If you are interested, check it out HERE.

 

Please let me know if you have any problems or questions.

[+geo-jedi]

CR,

 

I like it, I like it.

 

Good job!

 

I suppose the user of the tool can figure out how many factors and how the original digits have been re-ordered (although that would be a useful extension to the tool).

 

Geo-Jedi

[CoyoteRed]

I guess I could see if I could do something like have you simply put the coords in and the program extracts the digits and then issues the ABCDEFGH pattern.

 

I would have to use a completely different algorithm. It would involve shuffling associative arrays. Right now, I've got it simple, the numbers are in a string and I just shuffle the string. No telling how much overhead would be added. You can see the number of interations and time it took at teh bottom of the page to get just the 20 results.

 

I'll change the algorithm and see how long it takes compared to how I'm doing it now. But it might be a while. I did this to get it out of my head because it's been bugging me since last week.

[+HoPri]

I still haven't completely understood what exactly you are looking for.

 

If it is a way to transform found numbers into coordinates in such a way that

- if you get a number wrong

- then the coordinates shall be way off the correct ones,

have a look at the following scheme:

 

Assume that x and y are the found numbers, for example 3 and 4,

now sum them up (or multiply, whatever you want), result in the example is 7.

 

Now, the given formula for the coordinates may look like

z * [(x+y) mod (x+y+1)], mod being the well-known integer division reminder.

 

In the example, 7 mod 8 is 7, which is then multiplied by z to yield the coordinates (example: z=23, (decimals of the minutes of the) coordinates=23*7=161). If one mistakes x or y by something larger, then the mod ensures that the resulting factor is way off: found y=5 instead of 4, then x+y=8, 8 mod 8 = 0 (instead of 7), and 23*0 = 000. If it is more likely to mistake the figures x,y by something smaller then choose a mod just below the correct result.

 

However, the multiplication with z still ensures in all cases that you get coordinates quite away from the correct ones if you have a wrong x or y. The mod just makes things even worse in case of a mistake into the "wrong" direction. And the scheme works for all coordinates that aren't, by accident, prime.

 

Best regards,

Holger