php-general Digest 29 May 2012 20:57:11 -0000 Issue 7831
Topics (messages 318012 through 318023):
Re: Function size
318012 by: Stuart Dallas
318017 by: Stuart Dallas
318021 by: Tedd Sperling
318023 by: Matijn Woudt
Re: Simple XML, (x)html, and xpath
318013 by: Gary
Too many arrays! My head is exploding!
318014 by: Gary
318015 by: Vikash Kumar
318016 by: Florian Lemaitre
318018 by: Gary
318019 by: Tedd Sperling
318020 by: Adam Richardson
318022 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 23 May 2012, at 15:14, Tedd Sperling wrote:
> Hi gang:
>
> On May 21, 2012, at 8:32 PM, tamouse mailing lists wrote:
>> A rule of thumb is no more than 50 lines per
>> function, most much less. Back in the day when we didn't have nifty
>> gui screens and an 24 line terminals (yay green on black!), if a
>> function exceeded one printed page, it was deemed too long and marked
>> for refactoring.
>
> You hit upon a theory of mine -- and that is our functions grow in size up to
> our ability to view them in their totality. When our functions get beyond
> that limit, we tend to refactor and reduce.
>
> I know from the last several decades of programming, my functions have
> increased in number of lines. But, they have reached a limit that limit is
> generally about the number of lines I can read in half of my monitor's
> height. This of course, is dependent on monitor resolution, font-size, and
> how far I am sitting from the monitor. But I think this is a natural and
> physical limit that we don't normally recognize. I can cite studies that
> support my theory.
>
> It would be an interesting survey to ask programmers to review their code and
> provide the average number of lines in their functions AND how many lines of
> code their monitor's can display. In other words, look at your editor; count
> the number of lines your monitor can display; estimate the number of lines in
> your average function; and report the findings. For example, mine is about
> half -- my monitor can display 55 lines of code and my average function is
> around 25 lines. YMMV.
>
> Interesting, yes?
It's a theory, yes, and for many people it may be valid, but it's not for me.
The resolution of your screen; the size of your font; the colour scheme you
use. These should not be a factor in the way you write your code. If they are
then you'll be making decisions for all the wrong reasons.
The art of software development is in taking a problem, breaking it up in to
bite-size chunks, and putting those chunks together to form a practical
solution. Anyone who considers themselves a "better" programmer because their
functions are large due to their ability to handle large functions needs to
keep their ego in check. Mental capacity has nothing to do with it.
My philosophy for functions is simple... a function does one well-defined,
discrete task, and it does it well. The inputs are clearly specified, and the
potential outputs/exceptions are fully understood. Sound familiar? These
requirements make it incredibly easy to write unit tests for the code.
The number of times a function is used does not enter my field of interest.
It's irrelevant, as is the number of lines in each function. Following this
philosophy does naturally lead to fairly small functions, but as you move up
the levels of abstraction they tend to grow larger. For PHP, I consider code in
a file that's not within a function to be a function in itself, and the same
philosophy applies.
I wasn't going to respond to this thread because I think it's a largely
ridiculous topic, but some of the responses have scared me. Sir Cummings
(hopefully) sarcastic response about using a 5px font size demonstrated how
daft it is to base function size on how much code you can see on the screen at
once.
Looking at the stats for your code is meaningless, and it's particularly
meaningless if you're looking at lines rather than statements, but even then it
lacks sufficient meaning to be worthwhile.
Shiplu posted a great video on using polymorphism to properly model different
behaviours of a base type, and that's great, but for PHP you need to factory in
the sizeable speed difference between using a switch statement and using
objects. You should never let the elegance of a solution take priority over
efficiency.
Tony had some curious comments...
On 29 May 2012, at 08:52, Tony Marston wrote:
> The only reason to take a block of code and put it into its own function
> is when that code is likely to be called more than once so that it conforms
> to the DRY principle. If it is only ever used in one place then there is no
> point.
The DRY principle -- a great principle to observe. However, having functions
that are only used once does not violate the DRY principle, in fact in some
ways it makes it easier to adhere to it. Also, there is a point to pulling out
code that's only used once into a separate function, it's called unit testing,
and if you're not doing that then YOU are in the wrong job :)
KISS is more important than DRY in my opinion, and KISS should naturally lead
to DRY (in most cases).
> The problems I have with creating lots of small used-only-once functions is
> as follows:
> - you have to create a meaningful name for each function.
Oh, dear $DEITY, the hardship. Hmm, then again, naming my functions properly
will help you with your DRY goals. Hmm.
Seriously tho, you've refactored that code into its own function BECAUSE it's
doing a discrete task. Naming it should not be difficult if you're refactoring
it for the right reasons.
> - all those functions should be arranged in alphabetical order within their
> containing file - having them in a random sequence makes it difficult to
> find the one you want.
Should they? Why should they? I have never organised my functions in
alphabetical order! If you're having trouble locating a function then you need
a better editor. One with a decent search function should suffice; searching
for "function myfunction" usually works for me. If you're stuck I'd recommend
you check out Sublime Text 2 -- it's awesome, and has a very fast multi-file
search facility!
> - when browsing through the code you have to keep jumping to another
> function, and then returning to where you came from.
My my, you do have a hard life. But, seriously...?
> Another problem I have encountered in the past with such an idea is that it
> encourages a stupid programmer to decrease the number of lines of code by
> compressing as many statements as possible into a single line, which then
> makes the code less easy to read and understand. This is much worse than
> having more than 20 lines in a function.
Thanks for this, it naturally segues me into a brief summary of my thoughts...
1) First and foremost, if the programmers you're working with really think like
that, change them. I don't care if that means changing jobs -- trust me, you'll
be better off in the long run.
2) Education is what turns a "stupid" programmer into a "better" programmer. Be
an educator and make the world that little bit better.
3) Specifying a maximum number of lines for functions is dumb.
4) Specifying a maximum number of statements for functions is slightly less
dumb but it's still up there.
5) Use your common sense. If a function is doing more than one job, break it
up. Obviously by that logic you can break it up so that each function contains
a single line, but that's daft. With some experience it should become obvious
where you should draw the line in any given situation.
6) When you add or modify code, evaluate whether you should refactor it. Code
is fluid and you should approach it as such (a cup of water is easier to
control than a stream, which is easier to control than a river, which is easier
to control than a sea).
7) Don't measure meaningless stuff. Measure stuff that matters. The average
number of lines or statements in your functions doesn't matter. Ever.
> Whether a file contains 10 functions of 100 lines each, or 100 functions of
> 10 lines each, you still end up with 1000 lines of code. If you do not have
> the mental capacity to deal with a 100-line function then you are in the
> wrong job.
If you think being able to deal with a large block of code makes you a better
programmer, YOU are in the wrong job. A good programmer, in my opinion, knows
that the simpler and more discrete each block of code is the less room there is
for errors. An excellent programmer knows that 100-line functions are generally
impossible to adequately unit test.
The bottom line is to use your common sense rather than sticking to some
arbitrarily prescribed, measurable target.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On 29 May 2012, at 14:38, Tedd Sperling wrote:
> On May 29, 2012, at 7:17 AM, Stuart Dallas wrote:
>>
>> It's a theory, yes, and for many people it may be valid, but it's not for
>> me. The resolution of your screen; the size of your font; the colour scheme
>> you use. These should not be a factor in the way you write your code. If
>> they are then you'll be making decisions for all the wrong reasons.
>
> As gifted as you are, you missed the point.
I'm don't think I did, but as gifted as you are, I think you missed mine :)
> At no time did I say that anyone should do anything to the number of lines
> they write.
Quite right, but you did say that your functions have grown in size as the
number of lines you can fit on half your monitor height has increased. So on
some level you are basing your architectural decisions on that measurement,
whether consciously or not.
> Also, at no time did I say anything about "Mental capacity".
Quite right, it was Tony who brought that into it. I apologise for mixing it
into my general response but I couldn't let it go unchallenged because it's
trying to turn it into a pissing contest which is not good for any developer in
the ecosystem.
> My statement was not a recommendation, nor a suggestion, but rather an
> observation. An observation regarding known limits of human perception and
> comprehension.
>
> It is a known fact that we have short term memory limits -- there have been
> countless studies on this -- I do not want to belabor the point further. Web
> promotion has rekindled and advanced this interest. Here are a few
> contemporary books on the subject (they are all a good read):
>
> 1. "Don't make me think" by Steve Krug
> 2. "Submit Now" by Andrew Clark
> 3. "Neuro Web Design" by Susan Weinschenk
> 4. "!00 Things" by Susan Weinschenk
> 5. "Seductive Interaction Design" by Stephen Anderson
> 6. "Designing with the Mind in Mind" by Jeff Johnson
> 7. "Rocket Surgery Made Easy" by Steve Krug (this is not as important as
> above, but should be considered LAST)
>
> The earliest study I have been able to find on human perception and
> comprehension limits is:
>
> http://symboldomains.com/sperling.html (his study is there)
>
> George Sperling laid the basic foundation for this "span of apprehension" (as
> he called it) and many are continuing the investigation.
I'm familiar with the theories (tho I must admit I hadn't come across that
one), and I don't disagree with the general point. As you say there's an
abundance of studies that support the idea that we have a limited mental work
area. However, I don't think they should factor into decisions about how you
organise your code because I see those as extremely subjective. The point I was
trying to make (poorly it seems) was that if you follow common software
engineering principals, use your common sense and refactor based on the logical
way a problem breaks up into pieces, you'll usually end up with the same result.
"So why make the point?" I hear you ask… I think the motivation behind
architectural decisions, whether macro or micro, is fundamental. Making those
decisions because you can see it all on your screen, or hold it all in your
head, or any other "I can do this therefore" reason has great potential for
resulting in code that's difficult for anyone but you to maintain.
Let's say you're working on a text-only terminal. Your functions (or groups of
logic to be more accurate) are likely to fit within 24 lines. Then you take on
a project that's been developed by someone using a 30" monitor in portrait. She
can see far more lines at once than you can. In fact she can see lines from
multiple files at once. If their code structure has been determined by
arbitrary, personal preferences such as how much they can see on the screen at
once, their code will be a maintenance nightmare, especially for you on your
24-line terminal.
That was the only point I was trying to make. Your observation is not wrong; it
makes a lot of sense. However, I don't believe it should be given any further
consideration than noting the observation, and you may want to consider what
that observation means as far as the overall structure of your code.
In essence you are writing more complex functions, "because you can" which I
think is a very dangerous road to be on.
> As for the rest of your post, but of course, you are correct as you always
> are. You just missed the point that you are human and thus are subject to the
> same physical limits as the rest of us. Of course, you are free to think
> otherwise, but knowing you, the truth will eventually win out. :-)
I am human, but we appear to see our limits differently. I see my limits as
"I'm fallible therefore the simpler I can make my code the more likely it is to
behave the way I want, regardless of what level of complexity with which I
think I'm capable of working" whereas you see it in a similar way to Tony,
where your limits are based on how much you can see at any one time. I'm not
saying there's a right answer, just putting forth my philosophy.
Besides, truth is subjective, but then so is everything, including that
assertion.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On May 29, 2012, at 10:20 AM, Stuart Dallas wrote:
> -snip-
> Besides, truth is subjective, but then so is everything, including that
> assertion.
>
> -Stuart
You reply was longer than my monitor was high so I can't give an immediate
reply -- I have to scroll. :-)
However, with that said, you made good points and I don't disagree with any of
them.
As for me, I was speaking from my experience where the size of my functions
over the last few decades has grown (up to a point) with my increasing monitor
size. However, my eyesight has not improved and thus should be figured into
this somehow.
As I said before, mine is just an observation that supports the limits in
reception/comprehension articles I have read.
I think your 24 line terminal vs the 30" monitor argument is a valid one, up to
a point. But I think the problems (if any) would depend upon many factors --
too numerous to elaborate here.
But let me pose an idea.
When I was in college, my degrees were in Geology. My Summer Field study (6
weeks) was to map out Geologic outcrops on a USGS topographic map. At the end
of the study, all maps that matched the Professors' maps, were given the
highest grades (mine the highest in all modesty). Not because they were alike,
but because they approached the "truth" of the matter. The truth here was not
subjective for there was only ONE defining truth and that could be discovered
by detailed mapping. We all (including the Professors) approached the same
problem in the same way and reached similar results. The closer to the truth,
the more similar the maps.
Over the years I've seen programming languages converge producing single
solutions for common tasks, such as a FOR loop and IF statements. These seem to
be universal constructs in programming logic. So my question is, as in my
Geology study "Is this convergence in programming logic discovering the truth
of the task?" Do you see what I mean?
If so, then maybe the way we break down problems into smaller subsets might
also be approaching an optimum method as well. I used to use (30+ years ago):
1) Input; 2) Calculation; 3) Display; as the main categories in my division
logic to tackle problems and that was long before I heard of MVC.
So, what I am saying is that we might all be approaching and contributing to an
overall optimal logical solution in programming. Kind of an ant-colony think
sort of thing. The solution is certainly not simple, but it might be an
universally single solution to all the problems we perceive.
Said only for "Food for thought".
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
> The art of software development is in taking a problem, breaking it up in to
> bite-size chunks, and putting those chunks together to form a practical
> solution. Anyone who considers themselves a "better" programmer because their
> functions are large due to their ability to handle large functions needs to
> keep their ego in check. Mental capacity has nothing to do with it.
>
> My philosophy for functions is simple... a function does one well-defined,
> discrete task, and it does it well. The inputs are clearly specified, and the
> potential outputs/exceptions are fully understood. Sound familiar? These
> requirements make it incredibly easy to write unit tests for the code.
>
> The number of times a function is used does not enter my field of interest.
> It's irrelevant, as is the number of lines in each function. Following this
> philosophy does naturally lead to fairly small functions, but as you move up
> the levels of abstraction they tend to grow larger. For PHP, I consider code
> in a file that's not within a function to be a function in itself, and the
> same philosophy applies.
>
Stuart,
Your philosophy is interesting. Of course, a function should have one
well-defined and discrete task, but it is not always clear what one
task is. Let me take an example of a list. For example, you want to
write a function that removes an element from a list. In this example,
we will only use this list to remove items from it, so the code
required here won't be used another time. Now you have a few
possibilities:
1) (This one is probably Tony's approach): Write a single function
that searches the element and removes it from the list.
2) (My approach): Write a search function first, even though we're not
going to use it elsewhere), then write a delete function that uses the
search function to find it and remove it.
3) (Crazy approach ;)): Write a function that gets the next element in
the list, write a search function that uses the previous one. Write a
delete function that uses the search function, and then calls a
function that removes the actual element.
With your philosophy all three can fit.
The other interesting part in this discussion is the limited mental
work area. I assume that this is true, supported by the related
studies, makes me feel that we should write code as compact as
possible, right?
- Matijn
--- End Message ---
--- Begin Message ---
Andrew Ballard wrote:
> On Fri, May 25, 2012 at 3:57 AM, Gary
> wrote:
>> If I use simplexml_load_string to create an XML object
[...]
>> I cannot seem to get anything out of an xpath expression, no matter
>> what I try.
>>
>> If, however, I remove the 'xmlns="http://www.w3.org/1999/xhtml";' in
> the
>> html element, it works fine.
> I am not sure what you have tried, but namespaces change everything in
> XPath compared to documents without them.
I tried the simplest thnig I could think would work. I didn't know about
the namespaces thing (I haven't had a lot to do with xpath
before). Thanks. I'll sort something out from that info.
--
Gary Please do NOT send me 'courtesy' replies off-list.
--- End Message ---
--- Begin Message ---
Okay, let's assume I have three "things", A, B, and C. I need to produce
an array with a list of all possible combinations of them, however many
there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
ABC (not sure if I've missed any!). Normally I'm pretty good at working
this stuff out, but to be honest I'm struggling with this one, at least
to do it in any kind of elegant way. Does anyone have any ideas?
Idealy what I'd like is a multidimensional array depending on the number
of "things" in the combination. Something like:
array(2) {
[0]=>
array(3) {
[0]=>
array(1) {
["name"]=>
string(7) "A"
}
[1]=>
array(2) {
["name"]=>
string(5) "B"
}
[2]=>
array(2) {
["name"]=>
string(4) "C"
}
}
[1]=>
array(...) {
[0]=>
array(2) {
["name"]=>
string(13) "A+B"
}
[1]=>
array(2) {
["name"]=>
string(12) "A+C"
}
(etc.)
--
Gary Please do NOT send me 'courtesy' replies off-list.
--- End Message ---
--- Begin Message ---
On 29 May 2012 18:15, Gary <listgj-phpgene...@yahoo.co.uk> wrote:
> Okay, let's assume I have three "things", A, B, and C. I need to produce
> an array with a list of all possible combinations of them, however many
> there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
> ABC (not sure if I've missed any!). Normally I'm pretty good at working
> this stuff out, but to be honest I'm struggling with this one, at least
> to do it in any kind of elegant way. Does anyone have any ideas?
>
> Idealy what I'd like is a multidimensional array depending on the number
> of "things" in the combination. Something like:
> array(2) {
> [0]=>
> array(3) {
> [0]=>
> array(1) {
> ["name"]=>
> string(7) "A"
> }
> [1]=>
> array(2) {
> ["name"]=>
> string(5) "B"
> }
> [2]=>
> array(2) {
> ["name"]=>
> string(4) "C"
> }
> }
> [1]=>
> array(...) {
> [0]=>
> array(2) {
> ["name"]=>
> string(13) "A+B"
> }
> [1]=>
> array(2) {
> ["name"]=>
> string(12) "A+C"
> }
> (etc.)
>
>
>
If you are using linux, you can use the following:
$a = shell_exec("echo {a,b,c,d} && echo {a,b,c,d}{a,b,c,d} && echo
{a,b,c,d}{a,b,c,d}{a,b,c,d} && echo {a,b,c,d}{a,b,c,d}{a,b,c,d}{a,b,c,d}");
This will give you one line for 1 character combination, 1 line for 2
character combination and so on. You can then use explode to convert each
line to arrays.
Thanks,
Vikash
> --
> Gary Please do NOT send me 'courtesy' replies off-list.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Le 29/05/2012 14:45, Gary a écrit :
Okay, let's assume I have three "things", A, B, and C. I need to produce
an array with a list of all possible combinations of them, however many
there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
ABC (not sure if I've missed any!). Normally I'm pretty good at working
this stuff out, but to be honest I'm struggling with this one, at least
to do it in any kind of elegant way. Does anyone have any ideas?
Idealy what I'd like is a multidimensional array depending on the number
of "things" in the combination. Something like:
array(2) {
[0]=>
array(3) {
[0]=>
array(1) {
["name"]=>
string(7) "A"
}
[1]=>
array(2) {
["name"]=>
string(5) "B"
}
[2]=>
array(2) {
["name"]=>
string(4) "C"
}
}
[1]=>
array(...) {
[0]=>
array(2) {
["name"]=>
string(13) "A+B"
}
[1]=>
array(2) {
["name"]=>
string(12) "A+C"
}
(etc.)
--
Gary Please do NOT send me 'courtesy' replies off-list.
Enjoy !
function combinations($letters) {
$combinations = array(array());
foreach ($letters as $letter) {
foreach ($combinations as $combination) {
$combinations[] = array_merge($combination, array($letter));
}
}
return $combinations;
}
print"<pre>";print_r(combinations(array('a','b','c')));print"</pre>";
outputs :
Array
(
[0] => Array
(
)
[1] => Array
(
[0] => a
)
[2] => Array
(
[0] => b
)
[3] => Array
(
[0] => a
[1] => b
)
[4] => Array
(
[0] => c
)
[5] => Array
(
[0] => a
[1] => c
)
[6] => Array
(
[0] => b
[1] => c
)
[7] => Array
(
[0] => a
[1] => b
[2] => c
)
)
--
Florian Lemaitre
Développeur Web -- Cellule Edition Web/Publishing
Ligne directe : +32 69 250 554
Nos sites :
www.Potoroze.com <http://www.Potoroze.com> le portail de shopping mode
et beauté
www.Flash-Promos.com <http://www.Flash-Promos.com> le portail des codes
promos
_www.LaFriperieduCoin.com <http://www.LaFriperieduCoin.com>_ le
spécialiste des petites annonces mode gratuites
/Pôle Digital//, Evolution S.A/
12 rue des sablières, ZI Tournai Ouest II, 7503 Froyennes - BELGIQUE
Fax: +32 69 221 122
www.evolutioncom.eu <http://www.evolutioncom.eu>
--- End Message ---
--- Begin Message ---
Florian Lemaitre wrote:
> Le 29/05/2012 14:45, Gary a écrit :
>> Okay, let's assume I have three "things", A, B, and C. I need to
> produce
>> an array with a list of all possible combinations of them, however
> many
>> there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
>> ABC (not sure if I've missed any!).
> Enjoy !
>
> function combinations($letters) {
> $combinations = array(array());
> foreach ($letters as $letter) {
> foreach ($combinations as $combination) {
> $combinations[] = array_merge($combination, array($letter));
> }
> }
> return $combinations;
> }
:-) Looks to do pretty much exactly what I want, thanks! The key is the
array_merge, I guess :) Let's just say I wrote a *lot* more code than
that :")
--
Gary Please do NOT send me 'courtesy' replies off-list.
--- End Message ---
--- Begin Message ---
On 29 May 2012 18:15, Gary <listgj-phpgene...@yahoo.co.uk> wrote:
> Okay, let's assume I have three "things", A, B, and C. I need to produce
> an array with a list of all possible combinations of them, however many
> there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
> ABC (not sure if I've missed any!). Normally I'm pretty good at working
> this stuff out, but to be honest I'm struggling with this one, at least
> to do it in any kind of elegant way. Does anyone have any ideas?
Sure, but what you are asking for is a permutation and not a combination.
Here's a good read on the subject:
http://www.mathsisfun.com/combinatorics/combinations-permutations.html
Here's the deciding difference:
* If the order doesn't matter, then it's a combination.
* If the order does matter, then it's a permutation.
A combination of ABC is ABC.
However, the permutation of ABC is:
ABC
ACB
BAC
BCA
CAB
CBA
Oddly enough, a "combination lock" is a misnomer -- it should be a "permutation
lock" because the order of the "combination" does matter.
In any event, here's the code for as large a permutation as you may want:
http://www.webbytedd.com/b1/permutation/
Cheers,
tedd
_____________________
tedd.sperl...@gmail.com
http://sperling.com
--- End Message ---
--- Begin Message ---
On Tue, May 29, 2012 at 10:55 AM, Tedd Sperling <t...@sperling.com> wrote:
> On 29 May 2012 18:15, Gary <listgj-phpgene...@yahoo.co.uk> wrote:
>
>> Okay, let's assume I have three "things", A, B, and C. I need to produce
>> an array with a list of all possible combinations of them, however many
>> there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
>> ABC (not sure if I've missed any!). Normally I'm pretty good at working
>> this stuff out, but to be honest I'm struggling with this one, at least
>> to do it in any kind of elegant way. Does anyone have any ideas?
>
> Sure, but what you are asking for is a permutation and not a combination.
His example seems to suggest order does not matter (I've omitted 'D',
which I suspect was a typo given the set of A, B, and C):
A
B
C
AB
AC
BC
ABC
If order did matter, he would have included BA, etc.
That all said, combinations typically involve a consistent number of
choices, and his example includes various ranges of r.
These would be combinations for r = 1:
A
B
C
These would be combinations for r = 2:
AB
AC
BC
This would be the combination for r = 3:
ABC
What it seems like he's after is the power set of set ABC (minus the empty set):
http://en.wikipedia.org/wiki/Power_set
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On May 29, 2012, at 11:41 AM, Adam Richardson wrote:
> On Tue, May 29, 2012 at 10:55 AM, Tedd Sperling <t...@sperling.com> wrote:
>> On 29 May 2012 18:15, Gary <listgj-phpgene...@yahoo.co.uk> wrote:
>>
>>> Okay, let's assume I have three "things", A, B, and C. I need to produce
>>> an array with a list of all possible combinations of them, however many
>>> there might be in those combinations: e.g. A, B, C, D, AB, AC, AD, BC,
>>> ABC (not sure if I've missed any!). Normally I'm pretty good at working
>>> this stuff out, but to be honest I'm struggling with this one, at least
>>> to do it in any kind of elegant way. Does anyone have any ideas?
>>
>> Sure, but what you are asking for is a permutation and not a combination.
>
> His example seems to suggest order does not matter (I've omitted 'D',
> which I suspect was a typo given the set of A, B, and C):
Ahhh yes, he said AB, AC, BC, and ABC, but not AB, BA, AC, CA, and so on.
I stand corrected.
Cheers,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
