The Math Forum



Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.


Math Forum » Discussions » sci.math.* » sci.math

Topic: Algorithm for deriving permutations
Replies: 26   Last Post: Oct 21, 2007 2:16 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
Grouchy

Posts: 6
Registered: 1/12/07
Re: Algorithm for deriving permutations
Posted: Oct 20, 2007 9:45 AM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

On Oct 18, 6:05 pm, Water Cooler v2 <wtr_...@yahoo.com> wrote:
> If you have, say, 4 boxes to put the following 6 types of things in:
>
> Apples
> Oranges
> Pears
> Bananas
> Gooseberry
> Lemon
>
> Such that you could:
>
> a) only put one piece of each of the things in one box; and
>
> b) you could put the same thing in all the boxes, i.e you could put,
> say, an apple each in each of the boxes. In the mathematical jargon,
> if repetition was allowed
>
> Then, I know that we could have 6*6*6*6, i.e 1296 permutations.
>
> However, I want to know the algorithm to decide what those
> combinations are. Help appreciated.


Water cooler,

I'm sorry I can't offer you the references I'd like to at the moment,
but I'm not posting from my home or office.

I agree with a lot of the above postings, and hope I can add
something. First, the application obviously isn't putting fruit in
four baskets;) If you're working on the smoothing alogrithm for an
ion trap set up (aka quantum computing), then there's a paper at EEEL
labs over at NIST that goes over the question of setting some general
operational standards for all the various labs that have some form of
ion trap set up to study the "quantum computing" field. The guy's
over at EEEL really know this particular applied problem way way
better than I, and might give you a better insight into a QC
algorithm. (http://www.boulder.nist.gov/div818/index.html)

Second. The 'actual' grid consideration of 60 by 255 actually comes
closer to a different applied process, the original PBasic pin coding
library functions (like eeprom location instructions). The original
PBasic (BASIC stamp) library isn't very large, and can be found at the
Parallax web-site (www.parallaxinc.com) in a pdf form... although the
PBasic kit has 0-7 pins, rather than 0-5, and distinguishes between
0-255 qualifiers versus 0-255 variables for the purposes of it's
functions. Also, the Basic stamp and PBasic have additional hardware
bounds that don't typically concern logicians: the power limit is
like 5-15 DC V @ a minima of 2 mA (without I/O current), and can sink
25 mA and source 20 mA (with a lower total sum limit if all 8 I/O pins
are used). In addition, the PBasic version I'm semi-familiar with
doesn't support floating point calculations, and evaluates
mathematical expressions strictly left to right (pretty limiting).
Regardless, without knowing your precise application the best I can do
is recommend that library (which is probably much improved in the
current distro). For an interesting 6 by 2 by 5 by 0-255 (which is
KIND of like 60 by 255...) check out the PBasic CW conversion function
(morse code). After that the eeprom storage code function might be
what you want.

Third. The old (very old) magnetic cylinder storage techniques often
used a 5 bit process to serve as a 4 bit process because the extra bit
solved some self checking errors that arose due to base four
conversion to a radix 10 schema. So in practice a 'byte' was REALLY
10 bits rather than 8 bits (pretty typical engineering view... don't
include the correction bit outside the databook and no mathematician
can get it into their head that they should USE something only built
in as a processing tool). These older processes might be useful, as
the 10 bit byte IC logics used a 6 pin model (like a 555), but I don't
have the actual books near me at the moment. So the best I can think
of for these algorithms is to point you back to the NIST algorithm
library (long shot), and the following link, which is to the IBM
Journal of Research on-line dating back to 1956 (great, great
resource!):

http://www.math.utah.edu/pub/tex/bib/toc/ibmjrd.html

Fourth. rossum's suggestion regarding iteration logics seems to me to
be a very good one, although the formal logical processes don't
translate directly to a good eeprom algorithm (due to operational
variables not considered by logicians, see above). My bookmarks are
somewhat out of date (sorry) so I don't have a working direct link
anymore... but the basic logic problem (might) fall under "binary
connectives", which will look somewhat familiar to physicists who use
the Fourth Series binary connective proof to (incorrectly) represent
'quantum computing'. If I recall right, a pair of logicians in the
late 1980's published a couple papers that took C.S. Peirce's method
up to the Fifth Series... but without the physical text in front of
me, I can't give you their names (sorry again). All I can suggest is
that you dig through searches on "binary connectives", "Charles S.
Peirce", and etc. and hope the articles are digitized (I think they
are).

Fifth. Again, depending on the actual application, there are a
handful of quirky issues that are worth mulling over. To use the
'fruit' in a basket analogy: there are additional predicate classes
that could be used to narrow down an iterated function/algorithm.
e.g. Check_is_fruit_genus_citrus? Check_is_fruit_genus_Ribes?
(gooseberries are the only fruit listed from the Ribus genus, as
Banana's are the only option in the genus Musa). So although you have
six types of fruit, you only have FOUR genus' of fruit (Malus, Citrus,
Musa, and Ribes), which makes 'genus' a good variable for algorithm
construction. To mathematicians (and some logicians), who don't like
to bother over messy categories (they just jump to "infinite" as if
this is useful to engineers), LCB's or component tolerance is trivial,
but if something like 'entropy' in a cryptological encoding sense is
sitting on ones desk as an applied problem, reliance on brute
processing force rarely is a practical option. So while additonal
variable categories might look clunky at first, often they're exactly
where one can find a good trade off between elegance and application
(or between theory and practice).

Remember Ockham's "razor" is derived from: "Entia non sunt
multiplicanda praeter necessitatum"... the catch-22 qualification
being "necessity", which is often left out in translation. I usually
find that listing all the measurable categories of variables that
might be applicable vis a vis a particular applied algorithm to be a
great aid.

anyway, I hope you can get some use from the links.

Grouchy



Date Subject Author
10/18/07
Read Algorithm for deriving permutations
Water Cooler v2
10/18/07
Read Re: Algorithm for deriving permutations
Randy Poe
10/18/07
Read Re: Algorithm for deriving permutations
Water Cooler v2
10/18/07
Read Re: Algorithm for deriving permutations
hardwidg
10/18/07
Read Re: Algorithm for deriving permutations
Richard Heathfield
10/18/07
Read Re: Algorithm for deriving permutations
Proginoskes
10/18/07
Read Re: Algorithm for deriving permutations
Robert Israel
10/18/07
Read Re: Algorithm for deriving permutations
Proginoskes
10/19/07
Read Re: Algorithm for deriving permutations
David Bernier
10/19/07
Read Re: Algorithm for deriving permutations
Richard Heathfield
10/21/07
Read Re: Algorithm for deriving permutations
Richard the Dreaded Libertarian
10/21/07
Read Re: Algorithm for deriving permutations
Richard the Dreaded Libertarian
10/18/07
Read Re: Algorithm for deriving permutations
Randy Poe
10/19/07
Read Re: Algorithm for deriving permutations
David Breton
10/19/07
Read Re: Algorithm for deriving permutations
Proginoskes
10/19/07
Read Re: Algorithm for deriving permutations
Richard Harter
10/19/07
Read Re: Algorithm for deriving permutations
Marshall
10/19/07
Read Re: Algorithm for deriving permutations
Patricia Shanahan
10/18/07
Read Re: Algorithm for deriving permutations
briggs@encompasserve.org
10/18/07
Read Re: Algorithm for deriving permutations
Patrick Hamlyn
10/19/07
Read Re: Algorithm for deriving permutations
mensanator
10/19/07
Read Re: Algorithm for deriving permutations
hagman
10/19/07
Read Re: Algorithm for deriving permutations
Patrick Hamlyn
10/19/07
Read Re: Algorithm for deriving permutations
Richard Heathfield
10/19/07
Read Re: Algorithm for deriving permutations
mensanator
10/19/07
Read Re: Algorithm for deriving permutations
rossum
10/20/07
Read Re: Algorithm for deriving permutations
Grouchy

Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© The Math Forum at NCTM 1994-2017. All Rights Reserved.