Math Question.

Post Reply New Topic

I need to quickly calculate both ways between sets of permutations and their index.

An example:
1=0123456789
what equals 0246813579 and 9876543210?

Forget that.
I need one of these:
1=000,000,000,000,000,000,000,000,111,111,111,111,111,111,111,111
OR
1=010101010101010101010101010101010101010101010101
whichever is easiest. These can also equal 0 instead of 1

I need to know what permutation is indexed by any number
AND
I need to know what the index of any permutation is.

Although the first binary set should be trivial it is finite.
The second binary set is infinite, which is better than trivial.
I'd like to know how to do this for either or both.

And I wish to know how to do it with arithmetic in a reasonable amount of time.

But in any case I need to know how to calculate this as manually as possible.

I must count these ways but I have trouble with big numbers.
1=0011
2=0101
3=0110
4=1001
5=1010
6=1100

To be quite honest, I really don't know what you're talking about

However, a scientific computing library like NumPy might serve your needs

Sorry ValMikeSmith, but you have be much clearer what exactly you are asking for.

There is no unique "index" associated with a permutation. I.e. for three items, you have six permutations. You can choose to allocate the indices 0..5 to those permutations in whatever order you feel like. There is one fairly "obvious" pattern to choose:

0: 012
1: 021
2: 102
3: 120
4: 201
5: 210

I.e. to arrange the permutations in lexical order.

However, that's not (I believe) the best way to choose, if you wish to have an efficient conversion both ways. There is, of course, a reasonably efficient way to reverse it, which is of o(n).

When you also get into permutations of sets where not all items are unique, that's another problem. I.e. for three items, two of which are identical, you could have:

0: 001
1: 010
2: 100

(using the same, poor, lexical arrangement.)

Also, in order to attempt to define the reverse function, you will have to think about how you represent the permutation.

Are you specifically after permutations of 0s and 1s, with an equal number of each? If so, a table lookup, both ways, is probably the best way to do it.

PS. Nothing here is infinite.

YES, And...
Lookup table seems unlikely because I'm working with extraordinarily large sets.
(Unless I can figure out the fractal pattern and use recursion. There is one.)

I don't need the nonexistent 'unique' permutation index.
I just need to be able to reversably index them.

The sets varying in size start with all ones on one half, I've figured out more about them.
If the sets vary in size and start with alternating ones and zeros, then they
are defined as infinite, or at least the permutation index does not vary with scale.
(In other words, appending 0101 to the permutation doesn't change it's index.)
I THINK I have a way to translate between the permutations that start with
opposing ones and zeros, and permutations with alternating ones and zeros.

I have lots of (autistic-math) work on this, which I should be able to post hopefully soon.
I will be able to show the patterns I see. I may not understand greek symbols.
I have built a strange machine for this, and existing software can't connect to it.

All responses appreciated.

Nope. You've lost me. I don't know what you are calling a "set". I have no idea why you are talking about fractals. I have no idea what you are applying the word "infinite" to. Where did Greek symbols come in? In fact, I don't see what you are after at all.

Except...

You could define the members of your sets as the strings of 0s and 1s.

You could identify the sets Si as those sets of strings that contain no 1s after the first i positions.

You could define Di = Si-S(i-1).

You could define Ei as those D(2i) which had exactly i 1s.

Forget I said infinite. By greek symbols I meant avoiding calculus.

Above I indexed the "set" of 6 permutations that have 2 zeros and 2 ones.
No I didn't really. I COUNTED using a counting-like pattern of permutation
the permutations of binary numbers in the set are in binary counting order.
PERMUTATION COUNTING is better than testing every binary number to see
if it's in the set by counting the number of ones and zeros in it. But it doesn't
solve the problem with big numbers.

There is a fractal pattern in permutation but you haven't seen it because I
haven't showed you what it looks like yet. I know what it looks like but not
very well the pattern of how a big set of permutations is made of smaller
sets of permutations, which I also found to be true. We will think about the
fractal pattern after I post a picture of it. I try many ways to solve my problem
of indexing these permutations of numbers with as many zeros as ones.

*The question is still what is the simplest way to index the permutations
*of numbers with as many zeros and ones in them, and also be able to
*find the same index given the permutation.

I'll try to stay on track. It probably isn't necessary to use the fractals (which
only I have seen) to solve this. A fractal solution would be lateral thinking
and also of a synaesthetic nature. It only has yet served to give ME a deeper
understanding of the problem because I think of it in a variety of logical
abstractions that I naturally perceive.

Now I'll show how I "permutation count". Not index. Make permutations.

The Permutator's "counting" rule is simple.
Start from the right until there is a change from 1 to 0. (until you see 01)
Then change that pair from 01 to 10, and push all the passed "ones" back to the right.

00001111
000(10)111
0001(10)11
00011(10)1
000111(10)
00(10)0111 -these ones just got pushed all the way to the right
0010(10)11
00101(10)1
001011(10)
001(10)011 -the ones to the right of the flip just got pushed all the way to the right
(set continues, 70 permutations)

So The "Machine" already has a permutation "counting" mechanism.

The machine doesn't know the value of the permutations,
especially if it started permuting elsewhere than 00001111.

The machine doesn't know what permutation to start at if
the index starts to count elsewhere than 1.

The machine lacks the ability to sync it's 1,2,3 counter with it's Permutator.
So It needs a method of translating whenever the "123 counter" or the "Permutator"
is changed to a different value so that the other mechanism corresponds with it.



Those definitions are already "defined" indeed.
It's defined in great detail. Boiled down to fundamentals.
There will be no black boxes to magically do the job.
(It's not a PC so it can't possibly run Mathematica, etc.)

And you cant just reset the permutator?

Wouldn't it be easier to simply assign a "count" value to each possible permutation then do a table lookup (assuming I read correctly when you said there were only 70)?

I am simplifying the problem.
I am showing you small numbers but I am really using big ones.
I am using permutations with indexes higher than 1,000,000.
And yeah I can reset or change it but not waste time with counting then.

When you see what the machine does you will laugh at the idea of using a lookup table.
That would be like making a calculator with memory full of all the answers.
(Pentium math bugs LOL)

Please help. I make strange machines. See I made 3D machines without math help.
my 3D machine ... and me

1. What programming language are you using to run this simulation???

2. Just a hunch (I'm in astrophysics and we don't deal with set theory at all), but could you program a macro to solve this?? Basically design a program that will solve one permuation, and then have another program (typically these are fast ones) just be a sum from 0 to infinity of that one permutation. Should be the exact same answer you would have gotten otherwise, just less calculatory power, etc.

3. Just out of curosity, what are you doing this problem for???

Answers for skywatcher:
1.It is not a simulation. The machine only runs something like Assembly Language.
2.I would need to know how to do by hand what you are suggesting to program it.
If it can be done fast then that is good.
3.The problem is interesting. The results are interesting. Most people would agree.

Unfortunately I've learned the same lesson as the Wright Brothers.
If I ask for help then I only get it until people find out what I'm doing and start laughing.

Well, wouldn't "doing it by hand" be taking one permutation and then just ad hoc summing the thing to infinity? Which of course is a very easy thing to do in math, its something like sum ((x), 0, inf) and I doubt you need to know exactly what that sum is in order to know your perumation cycle by simply summing that sum over the permutation cycle.

Of course, writing a macro or some other form of program that would just take an already figured out sum and then fly through "infinite" summations of them to give you your answer would be the best bet.

Also, if this problem is just one that interests you, please also keep to your studies. I don't know if you have studies or work, but a problem of this nature could get you into a lot of trouble by taking up a ton of your time and killing grades or time for work. Its always good to work on pet projects, but its always good to keep a balance as well. I trust that you will do that with this.

Well I'm looking for a faster method with the least number of steps.

For example, Why would someone multiply a large number by adding it a number of times
when adding once per each digit of that number is faster?

I'm close to several solutions.

I already have inferior alternatives (to permutation indexes) that are working.

This is not a recreation. It is for increasing the speed of something.
Even the people who laugh at it don't think it's POINTLESS.

Don't worry, it's a small part of something. It's not like obsessions with pi or primes.

I was only looking out for your best interests...

I know that this is important - permutation math drives most of science and technology. The thought crossed my mind that you are still a student, undergrad or postgraduate, who might not have the same opportunities for publication or research as someone who is employed in research. I know now that I jumped to the wrong conclusions, and that you are probably a PhD scientist working on this problem (it was the name of the thread that threw me, to be quite honest), and that you probably don't have studies to worry about, just research and such.

I'm sorry for the misunderstanding.