Mailing List Archive

name for a mutually inclusive relationship
I'm looking for a name for a group of options that, when one is specified, all of them must be specified.

For contrast,

- radio buttons: a group of options where only one can be specified (mutually exclusive)
- check boxes: a group of options that are independent of each other (any number of
them may be specified)

- ???: a group of options where, if one is specified, all must be specified (mutually
inclusive)

So far, I have come up with:

- the Three Musketeers
- clique
- club
- best friends
- tight knit
- group

Is there a name out there already to describe that concept?

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
Hi !

In case you didn't though about that, in argparse,
MutuallyExclusiveGroup is used for the mutually exclusive logic. You may
use the same nomenclature, which happens to be IMHO much clearer than
the one you came up with.

In GUIs, i guess that such an option would be implemented by a checkbox
that, when checked, enables the widgets associated to all the mutually
inclusive options.

Best regards,
--lucas


On 24/02/2021 17:12, Ethan Furman wrote:
> I'm looking for a name for a group of options that, when one is
> specified, all of them must be specified.
>
> For contrast,
>
> - radio buttons: a group of options where only one can be specified
> (mutually exclusive)
> - check boxes:   a group of options that are independent of each other
> (any number of
>                  them may be specified)
>
> - ???: a group of options where, if one is specified, all must be
> specified (mutually
>        inclusive)
>
> So far, I have come up with:
>
> - the Three Musketeers
> - clique
> - club
> - best friends
> - tight knit
> - group
>
> Is there a name out there already to describe that concept?
>
> --
> ~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2021-02-24 at 08:12:58 -0800,
Ethan Furman <ethan@stoneleaf.us> wrote:

> I'm looking for a name for a group of options that, when one is specified, all of them must be specified.
>
> For contrast,
>
> - radio buttons: a group of options where only one can be specified (mutually exclusive)
> - check boxes: a group of options that are independent of each other (any number of
> them may be specified)
>
> - ???: a group of options where, if one is specified, all must be specified (mutually
> inclusive)

I've run across this before, and almost always end up incorporating one
option or the other. For example, consider a program's output. By
default, it goes to stdout, but the program also supports plain output,
logging, and syslog. So instead of mutually inclusive (for lack of a
better phrase right now) options:

--output-disposition [logging|syslog|flatfile]
--output-options [depends on --output-disposition]

do this:

--output-to-log logging-options
--output-to-syslog syslog-options
--output-to-plain-file plain-file-options

aka three mutually *exclusive* options.

> So far, I have come up with:
>
> - the Three Musketeers
> - clique
> - club
> - best friends
> - tight knit
> - group
>
> Is there a name out there already to describe that concept?

Codependent?
Circularly dependent?
Entangled?
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 24/02/2021 16:12, Ethan Furman wrote:
> I'm looking for a name for a group of options that, when one is specified, all of them must be specified.
>
> For contrast,
>
> - radio buttons: a group of options where only one can be specified (mutually exclusive)
> - check boxes: a group of options that are independent of each other (any number of
> them may be specified)
>
> - ???: a group of options where, if one is specified, all must be specified (mutually
> inclusive)

Given that radio buttons and check boxes are all effectively
using boolean states, doesn't this mean none of the group
or all of the group?

In which case it's a single boolean value - a check box that
controls all options.

I suspect I'm missing something...

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2/24/21 8:28 AM, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:

> Entangled?

Hey, I like that one! ;-)

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2/24/21 12:40 PM, Alan Gauld via Python-list wrote:
> On 24/02/2021 16:12, Ethan Furman wrote:
>> I'm looking for a name for a group of options that, when one is specified, all of them must be specified.
>>
>> For contrast,
>>
>> - radio buttons: a group of options where only one can be specified (mutually exclusive)
>> - check boxes: a group of options that are independent of each other (any number of
>> them may be specified)
>>
>> - ???: a group of options where, if one is specified, all must be specified (mutually
>> inclusive)
>
> Given that radio buttons and check boxes are all effectively
> using boolean states, doesn't this mean none of the group
> or all of the group?
>
> In which case it's a single boolean value - a check box that
> controls all options.
>
> I suspect I'm missing something...
>

radio buttons (none or one):

t-shirt size: Small Medium Large


check boxes (none or one or several or all):

sandwich toppings: lettuce tomato onion cheese


entangled (none or all):

image size override: height width

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2021-02-24 at 13:05:05 -0800,
Ethan Furman <ethan@stoneleaf.us> wrote:

> entangled (none or all):
>
> image size override: height width

IMO, that's *one* option (-s 640x480 or -s 640,480), not two. In
argparse/optparse terms, a required argument with a custom type.

(OTOH, in a GUI, it'd be two separate mandatory text fields, both
controlled (i.e., enabled or disabled) by one checkbox.)
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2/24/21 1:23 PM, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:

>> entangled (none or all):
>>
>> image size override: height width
>
> IMO, that's *one* option (-s 640x480 or -s 640,480), not two. In
> argparse/optparse terms, a required argument with a custom type.
>
> (OTOH, in a GUI, it'd be two separate mandatory text fields, both
> controlled (i.e., enabled or disabled) by one checkbox.)

I didn't say it was a good example. ;-) Hopefully it gets the idea across.

--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2021-02-24 at 13:31:42 -0800,
Ethan Furman <ethan@stoneleaf.us> wrote:

> On 2/24/21 1:23 PM, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
>
> > > entangled (none or all):
> > >
> > > image size override: height width
> >
> > IMO, that's *one* option (-s 640x480 or -s 640,480), not two. In
> > argparse/optparse terms, a required argument with a custom type.
> >
> > (OTOH, in a GUI, it'd be two separate mandatory text fields, both
> > controlled (i.e., enabled or disabled) by one checkbox.)
>
> I didn't say it was a good example. ;-) Hopefully it gets the idea across.

Ditto. ;-)

IMO, the whole idea of "my program has two options, and the user has to
specify both or neither," isn't a question of whether or not the
argument parsing library supports it, but a question of whether or not
it's a good API.

Is the following a good API for a function?

def override_image_size(image, height=0, width=0):
'''specify height and width, or set both to 0'''
if (height == 0 and width != 0) or (height != 0 and width == 0):
raise ArgumentError('both or neither')
if height != 0 and width != 0:
image.height = height
image.width = width

Or would you more likely write something like this:

def override_image_size(image, size):
'''size is a (height, width) tuple'''
image.height, image.width = size

So why is the former a good API for a command line utility?

Or maybe I don't write command line utilitis with sufficiently complex
argument structures.
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2/24/21 1:54 PM, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
> Ethan Furman wrote:

>> I didn't say it was a good example. ;-) Hopefully it gets the idea across.
>
> Ditto. ;-)
>
> IMO, the whole idea of "my program has two options, and the user has to
> specify both or neither," isn't a question of whether or not the
> argument parsing library supports it, but a question of whether or not
> it's a good API.

Like I said, at this moment I don't have a good example, only an awareness that such a thing could exist and I don't know the name for it (if it has one).

So far I have seen that there are even fewer good use-cases than I might have guessed, and that no one seems to have a name for the general idea.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2021-02-24 08:12, Ethan Furman wrote:
> I'm looking for a name for a group of options that, when one is
> specified, all of them must be specified.
[snip]
> - ???: a group of options where, if one is specified, all must be
> specified (mutually inclusive)
[snip]
> Is there a name out there already to describe that concept?

For two items, the XNOR logical operator (effectively a "not (a xor
b") has the desired truth-table.

https://en.wikipedia.org/wiki/Xnor

sometimes called a "logical biconditional"

https://en.wikipedia.org/wiki/Logical_biconditional

But in more human terms, the common phrase "all or nothing" seems to
cover the concept pretty well.

-tkc







--
https://mail.python.org/mailman/listinfo/python-list
RE: name for a mutually inclusive relationship [ In reply to ]
Is there a more general idea here? How about asking for a control that
internally manages N items and requires exactly M of them before the entry
is accepted when you click? The case being discussed sort of wants N out of
N, or nothing.

Example, you order a family dinner from a Restaurant and are told that for a
fixed price, you must order exactly 4 items from column A and another 5 from
column B.

Now linking the two is a bit much but if there are ten items in column A,
the only valid choices might be to not order at all or pick exactly 4.
Picking your first item would be easy and picking your second and third too.
Once you have 4, the setup should sort of lock so you cannot add more. But
if you unclick one, you should be able to select another. To get out of the
setup you either stop at exactly 4 or cancel out.

The problem with the N out of N case is that it is all or none. Unclicking
anything in this case may not be enough and perhaps the code should clear
all other items too. Clicking on any one, should mark all of them. So not
really a simple subset of the cases.

And what messages does a user get as they use the control?




-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Ethan Furman
Sent: Wednesday, February 24, 2021 5:14 PM
To: python-list@python.org
Subject: Re: name for a mutually inclusive relationship

On 2/24/21 1:54 PM, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
> Ethan Furman wrote:

>> I didn't say it was a good example. ;-) Hopefully it gets the idea
across.
>
> Ditto. ;-)
>
> IMO, the whole idea of "my program has two options, and the user has
> to specify both or neither," isn't a question of whether or not the
> argument parsing library supports it, but a question of whether or not
> it's a good API.

Like I said, at this moment I don't have a good example, only an awareness
that such a thing could exist and I don't know the name for it (if it has
one).

So far I have seen that there are even fewer good use-cases than I might
have guessed, and that no one seems to have a name for the general idea.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2021-02-24 6:12 PM, Ethan Furman wrote:
> I'm looking for a name for a group of options that, when one is
> specified, all of them must be specified.
>
> For contrast,
>
> - radio buttons: a group of options where only one can be specified
> (mutually exclusive)
> - check boxes:   a group of options that are independent of each other
> (any number of
>                  them may be specified)
>
> - ???: a group of options where, if one is specified, all must be
> specified (mutually
>        inclusive)
>
> So far, I have come up with:
>
> - the Three Musketeers
> - clique
> - club
> - best friends
> - tight knit
> - group
>
> Is there a name out there already to describe that concept?
>

I have something vaguely similar, but my approach is different, so I
don't know if this will be helpful or not.

Take an example of a hospital admission form. One of the fields is
'Sex'. If the answer is Male, then certain fields are required, if the
answer is Female, certain other fields are required.

There can be more than one such occurrence on the same form. A field for
'Has Insurance?' could require insurance details if True, or payment
method if False.

I construct a dialog for each possibility, with all the fields
associated with that possibility.

Initially the dialogs are hidden. When the selection is made, the
appropriate dialog is shown.

The controlling field can have multiple options, so rather than a
check-box, it is the equivalent of a radio-button.

The term I use for this arrangement is 'sub-types'.

Frank Millman

--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2021-02-24 6:12 PM, Ethan Furman wrote:
> I'm looking for a name for a group of options that, when one is
> specified, all of them must be specified.
>
> For contrast,
>
> - radio buttons: a group of options where only one can be specified
> (mutually exclusive)
> - check boxes:   a group of options that are independent of each other
> (any number of
>                  them may be specified)
>
> - ???: a group of options where, if one is specified, all must be
> specified (mutually
>        inclusive)
>
> So far, I have come up with:
>
> - the Three Musketeers
> - clique
> - club
> - best friends
> - tight knit
> - group
>
> Is there a name out there already to describe that concept?
>

I have something vaguely similar, but my approach is different, so I
don't know if this will be helpful or not.

Take an example of a hospital admission form. One of the fields is
'Sex'. If the answer is Male, then certain fields are required, if the
answer is Female, certain other fields are required.

There can be more than one such occurrence on the same form. A field for
'Has Insurance?' could require insurance details if True, or payment
method if False.

I construct a dialog for each possibility, with all the fields
associated with that possibility.

Initially the dialogs are hidden. When the selection is made, the
appropriate dialog is shown.

The controlling field can have multiple options, so rather than a
check-box, it is the equivalent of a radio-button.

The term I use for this arrangement is 'sub-types'.

Frank Millman
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On Thu, Feb 25, 2021 at 4:06 PM Avi Gross via Python-list
<python-list@python.org> wrote:
>
> Is there a more general idea here? How about asking for a control that
> internally manages N items and requires exactly M of them before the entry
> is accepted when you click? The case being discussed sort of wants N out of
> N, or nothing.
>

YAGNI.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
RE: name for a mutually inclusive relationship [ In reply to ]
YAGNI? True, Chris, I never have.

And if I ever did, I might not even know someone has implemented similar
functionality with 86 optional function arguments that fine-tune what
happens in various cases and what error messages to supply, LOL! So, I would
end up re-implementing it myself.

But isn't this true for so much software we discuss here. The usual mantra
is that 80% of features are used maybe 20% of the time and a few are used
never except maybe while testing.

Realistically, it adds to bloat if a fairly well-defined object is extended
to handle every possible feature that is allowed, and then some. We recently
discussed the "+=" feature for an object when much of the time, it is pretty
much as useful as just using the longer way of adding something to yourself.
But loading a longer object description the 99% of the time when it is not
used, also costs a bit.

My comment was thus mostly academic and suggested realistic scenarios some
people use commonly enough that might be possibly to implement to make it
easier to deal with such a structure and that arguably such could also
handle this edge case. No reason to think this is an important thing to add,
just a category that could be doable.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Chris Angelico
Sent: Thursday, February 25, 2021 1:14 AM
To: Python <python-list@python.org>
Subject: Re: name for a mutually inclusive relationship

On Thu, Feb 25, 2021 at 4:06 PM Avi Gross via Python-list
<python-list@python.org> wrote:
>
> Is there a more general idea here? How about asking for a control that
> internally manages N items and requires exactly M of them before the
> entry is accepted when you click? The case being discussed sort of
> wants N out of N, or nothing.
>

YAGNI.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
Ethan Furman <ethan@stoneleaf.us> writes:

> I'm looking for a name for a group of options that, when one is specified, all of them must be specified.

I don't fully understand the question (yes, I read the part I snipped).

Why is this not just a single option? Or is it hierarchical or
something so option 1 implies options 2 and 3, but option 2 does not
imply option 1?
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
Ethan Furman <ethan@stoneleaf.us> writes:

> On 2/24/21 1:54 PM, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
>> Ethan Furman wrote:
>
>>> I didn't say it was a good example. ;-) Hopefully it gets the idea across.
>> Ditto. ;-)
>> IMO, the whole idea of "my program has two options, and the user has
>> to
>> specify both or neither," isn't a question of whether or not the
>> argument parsing library supports it, but a question of whether or not
>> it's a good API.
>
> Like I said, at this moment I don't have a good example, only an awareness that such a thing could exist and I don't know the name for it (if it has one).
>
> So far I have seen that there are even fewer good use-cases than I might have guessed, and that no one seems to have a name for the general idea.

Do you have a specific problem you're trying to solve? That might help
us understand the question better.
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 2/25/21 7:06 PM, Joe Pfeiffer wrote:
> Ethan Furman writes:

>> Like I said, at this moment I don't have a good example, only an awareness that such a thing could exist and I don't know the name for it (if it has one).
>>
>> So far I have seen that there are even fewer good use-cases than I might have guessed, and that no one seems to have a name for the general idea.
>
> Do you have a specific problem you're trying to solve?

No, I just came across the concept in my browsing and was wondering if there was a name for it. I think the most accurate name at this point is probably "pain in the butt". ;-)

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On Fri, Feb 26, 2021 at 3:32 PM Ethan Furman <ethan@stoneleaf.us> wrote:
>
> On 2/25/21 7:06 PM, Joe Pfeiffer wrote:
> > Ethan Furman writes:
>
> >> Like I said, at this moment I don't have a good example, only an awareness that such a thing could exist and I don't know the name for it (if it has one).
> >>
> >> So far I have seen that there are even fewer good use-cases than I might have guessed, and that no one seems to have a name for the general idea.
> >
> > Do you have a specific problem you're trying to solve?
>
> No, I just came across the concept in my browsing and was wondering if there was a name for it. I think the most accurate name at this point is probably "pain in the butt". ;-)
>

"Design flaw" is a close second.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
Op 24/02/21 om 17:12 schreef Ethan Furman:
> I'm looking for a name for a group of options that, when one is
> specified, all of them must be specified.
>
It seems you are looking at an equivalence.
--
https://mail.python.org/mailman/listinfo/python-list
Re: name for a mutually inclusive relationship [ In reply to ]
On 26/02/2021 04:30, Ethan Furman wrote:

>> Do you have a specific problem you're trying to solve?
>
> No, I just came across the concept in my browsing and
> was wondering if there was a name for it.

If we stick with boolean values (like radio buttons
and checkboxes) then I think the name is "equality"

A B Result
--------------
0 0 1
0 1 0
1 0 0
1 1 1

So you determine "success" by whether all
inputs are equal. (Or as somebody else
said "not xor")

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


--
https://mail.python.org/mailman/listinfo/python-list