is there a mathematical way to store 2 numbers (let's say x/y coordinates) as 1 number? perhaps like a seed?

if my x/y was -3002/1506 there doesn't seem to be a way to store that as 1 number, but is there a way to store a different number that somehow can be extrapolated into these 2?

You could maybe store them as hex and parse them out.. hex:AE would = 10,14

I supposed negative numbers would make that even more complicated. Any ideas? it's more of a curiosity...

It's more of a programming question that a math one. I guess you could try your luck with bits manipulation, however it's quite limited in its current implementation. See manual's system expression "getbit" and "setbit".

Magistross I could program parsing easy enough if it were saved as a string. I'm really asking is there a way to store 2 numbers as a single integer. i.e. do some sort of calculation to the two numbers so that a 3rd number somehow represents them both - one would obviously have to do something to the said 3rd number to "unpack" the other two...

I wasn't talking about parsing. getbit() and setbit() are used to set individual bits of a 32-bit integer. One could use them to create a function that take two integers in the 16-bit range and combine them in a single 32-bit integer. If we had bit-shifting operation, that would be much easier to do.

You could maybe try to use decimal shifting instead :

-packing

CombinedInt = FirstInt * 1000000 + SecondInt

-unpacking

FirstInt = floor(CombinedInt / 1000000)

SecondInt = CombinedInt % 1000000

It would work to combine numbers in the 0-999999 range.

Magistross yeah I've done bit shifting, but I see that as a sort of parsing since you need to elect 16 of the bits to be one number and the remaining 16 to be a different number.

That (decimal shifting) math is what I was looking for.. cool, thanks! the only problem is negative numbers which presents a real problem.

You can offset that too. Add 100000 to the number before storing, and subtract that on restore. As long as no number can be beyond +/- 100000, then it all works out.

So to offset to a positive, you need only add 20000, pushing the top to 40000. So use 100000 as the multiplier: 2,000,000,000 + 40000 = 2,000,040,000 max.

I was having a similar problem and being quite stubborn I was convinced there was a mathematical solution to this and I found one that works for me.

My problem was storing a bunch of x,y coordinates into a flat list that I could easily reference. I though of the two main ideas posted here and was about to give in to bit shifting when I found something you may be able to put to use. The trick is simple, use a prime number in the equation;