My approach to the problem started with the thought of forgoing thinking about the circles themselves, and instead focusing on their intersections. Specifically, we look at every pair of circles that intersect, we call these intersections the "Parent Intersections" - with this parent as our focal point, we look if other circles interact with it, and in how many 'unique' ways do they interact with it.
To illustrate - we will start with a generic Parent intersection (PI) between circles 1 and 2, and show 4 different unique ways other circles interact with it:
(Fig 1, Parent Intersection)
The PI is defined by the numberings of its component circles, and we mark it down as - [1,2]
(Fig 2, Sibling)
A sibling is a circle that intersects with one (or both) of the parent circles without crossing the intersection points between the parents.
(Fig 3, Uncle)
An uncle is a circle that intersects with both parents, while crossing only one of the
intersection points between the parents.
(Fig 4, Child)
A child is a circle that is fully contained inside the PI, without touching any of the parent circles.
(Fig 5, Host)
A host is a circle that fully contains the PI (both of the intersection points between the parent circles are inside the host).
So far we have shown 4 different interactions that any given Parent Intersection (PI) could possibly have with other circles.
The idea is that given an exhaustive list of all possible unique interactions with the PI (it could be more than the 4 I've listed), one could arrange a sort of "ID Card", that goes over each and every PI in a given configuration on N circles, and lists out every unique interaction it has with other circles, and as a result generating a unique ID to that specific configuration of circles.
One more addition to the ID card that’s required beyond the 4 listed interactions (Siblings, Uncles, Children, Hosts), is to also list every circle that is contained in another circle in a given configuration. Here’s an example of how it would look like:
Sample configuration of 4 circles:
ID Card:
Circles: [ 1 , 2(4) , 3 , 4 ]
(A number in parenthesis denotes a circle that is contained within the circle.)
PI’s:
[1,2] -
Siblings: [ 3 ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
[1.3] -
Siblings: [ 4 ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ 2 ]
[2.3] -
Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ 1 ]
[3,4] -
Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ 2 ]
The assumption is that any meaningful change we make to this configuration of circles, no matter how subtle, will also change the resulting ID card.
If the 4 interactions (Siblings, Uncles, Children, Hosts) are not enough to describe a configuration fully, then there will be differing configurations that result in the same ID card (a collision). One possible example of this is these two configs:
Config 1:
Config 2:
These two configs are fundamentally different, but they produce the same ID card following our system, meaning that the 4 interactions (S,U,C,H) are not enough to exhaustively describe all configs in a unique manner.
My hope is that by adding more and more (a finite amount) of unique interactions to account for in the ID card, we will get a final ID card that won’t produce any collisions.
So the problem of knowing how many configurations of N circles there can be becomes analogous to how many different valid unique IDs can our ID card generate for N circles, which hopefully would make this problem more approachable, or at least give some useful upper bound.
Here's a test run I've done on 3 differing configs:
So far I didn't find any configs that cause ID collisions, aside from the "ring" config problem I've shown above.
A very rough (maybe nonsensical) equation that I wrote down that maybe could resemble an upper bound. It doesn't take into account any constraints that are imposed by the S,U,C,H interactions, so most of the IDs generated with this will not be viable:
Config 1:
Config 2:
[...]
(Fig 2, Sibling)
A sibling is a circle that intersects with one (or both) of the parent circles without crossing the intersection points between the parents.
Sample configuration of 4 circles:
My hope is that by adding more and more (a finite amount) of unique interactions to account for in the ID card, we will get a final ID card that won’t produce any collisions.
So the problem of knowing how many configurations of N circles there can be becomes analogous to how many different valid unique IDs can our ID card generate for N circles, which hopefully would make this problem more approachable, or at least give some useful upper bound.
Hi there, I hope you are doing well!
It is viable in itself, still I am not quite sure of your question ? If you could be more precise please...
Your simulation use a linear approach, and so while this is great for pairs of units or cells, this isn't sufficient for a multi-dimension system or binding objects from different environments or clusters. So you could also use;
[-0, 1, -0] ... [0, -1, 0] where you triangulate as an overlap your point of coercion within your spherical system for example. And so your mapping coordinate points are "flipped" around and it should also bring precision or additional paths.
Hi Nart,I don't think the approach is viable for A250001, but those are great diagrams! Maybe your diagramming tool (whatever it is) can be used to create nice visualizations for other geometry-based sequences. I give one concrete suggestion near the end of this email.
In general your terminology is counterintuitive: in English "sibling" is a symmetric relationship (if A is a sibling of B, then B is also a sibling of A), and it is never possible to be a [full] sibling of your own parent, nor an uncle of your parent. You might do better to use less loaded terms, e.g. "cats, dogs, birds, sharks, and turtles," just to clear away those pre-existing semantic cobwebs.
Now here's the problem: If you take the same diagram and simply shift 3 down a bit, so that it no longer intersects 2 (but continues to intersect 1), you'll continue calling 3 a sibling of (1,2) — your "ID card" won't have changed — but the topological configuration of circles will have changed. So your current "ID card" isn't sufficient.
Once you get to n=5, geometric concerns mean that not all topologically-conceivable arrangements are actually circle-drawable.
I'd phrase that implication in the opposite direction: It seems to me that enumerating a set of "ID cards" that uniquely describes each topologically possible arrangement must (by definition) be at least as hard as just enumerating the arrangements of circles themselves.
--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAA5vYbCcL%3D%2B%3D5QkWcXZksu%2BrJsB45uwLo8nyKqUkOX-dcpxSiA%40mail.gmail.com.
I'm not sure I have read the OEIS entry properly, but I think part of the problem here is that we don't have a reliable combinatorial representation yet.
To show how hard this problem is, I'm going to describe two five-circle configurations, which are definitely different, but any obvious "annotated graph" representation will not distinguish them. Start with three circles in a triangular loop, each just slightly overlapping the two others, but with no three-way overlap. The overlapping areas should be like long thin spindles. Pick one of those spindles and put a small circle right in the middle, intersecting each side of the spindle twice. The spindle has been split into three regions, one four-sided region, with a three-sided region on each side. See https://oeis.org/A250001/a250001_4.pdf, page 5: the third diagram in the second row gives this four-circle configuration.You can stick a tiny fifth circle right in the interior of either of the small triangular regions. These regions are quite different -- one is right next to the original central triangle; the other is off on the periphery of the figure. But these two five-circle configurations have identical containment and intersection relations. These two figures make a good challenge for any candidate notation that purports to assign a "signature" or "ID card" to each.
--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/seqfan/CADvuK0LwoheXN5wOfAoSOg87G7dy-f0Ho5Wr7nE%2BTGneHFsC%3Dw%40mail.gmail.com.
I'm not seeing any attached PDF; Wild says he was attaching one that gave the details of his program's representation. It would certainly be helpful for anybody wanting to work on this sequence.
--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/seqfan/CAFqvfd8bS87GxJodd%2BotOXp6he3L8Yv%3D6vgDs_cfZP51BtXawg%40mail.gmail.com.
Arthur, a couple of things:
> Unfortunately I don't think it's possible to create such a "chiral pair"
> with any fewer than 5 circles.
Actually there are chiral pairs with 4 circles! I believe there are 27
chiral pairs, among the 112 connected 4-arrangements.
One tricky distinction that won't crop up until 8-arrangements: what if
you have a chiral connected 4-arrangement placed next to another chiral
connected 4-arrangement -- are you allowed to turn just one of them over?
Arthur wrote:
>> Actually there are chiral pairs with 4 circles! I believe there are 27
>> chiral pairs, among the 112 connected 4-arrangements.
>
> Can you give an example? I still can't think of any way to do it with
> only 4.
I quickly grabbed this selection "by hand" from a document with all the
arrangements, it's not quite complete for the chiral ones (and there's a
chance there are 1 or 2 of these that only look chiral), but you get the
idea.
--
You received this message because you are subscribed to the Google Groups "SeqFan" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seqfan+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/seqfan/CADvuK0LfMzgszg1mm-7fy1g-nWrtmObpcsE1d3dxRCXPQOFShw%40mail.gmail.com.
To view this discussion visit https://groups.google.com/d/msgid/seqfan/CACOfRNpV-x4ABw1dvync38RhEwsTa7WVuwcZXz1C9CehhFxiWA%40mail.gmail.com.