A possible approach to 'Overlapping Circles'? ( OEIS A250001 )

66 views
Skip to first unread message

Nart Tehaucha

unread,
Sep 2, 2025, 2:17:59 AM (5 days ago) Sep 2
to SeqFan
Hello seqfans. I open this conversation at the risk of making a fool of myself as I am not a mathematician nor someone who is capable of deciding if what I came up with is nonsensical or not, so I apologize if it is!

This problem deals with calculating how many different configurations of N circles we can create. The number of possibilities predictably explode as you add more circles, and become prohibitive to calculate with brute force.

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)

parent.PNG

The PI is defined by the numberings of its component circles, and we mark it down as  - [1,2]


(Fig 2, Sibling)

sibling.PNG

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)

uncle.PNG

An uncle is a circle that intersects with both parents, while crossing only one of the  intersection points between the parents.

(Fig 4, Child)

child.PNG

A child is a circle that is fully contained inside the PI, without touching any of the parent circles.

(Fig 5, Host)

host.PNG

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:


sample config.png


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:

sample config3.PNG


Config 2:

sample config2.PNG


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:

overlapping circles ex1.jpg


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:


Screenshot_20250902-090322_Squid.jpg


It seems to explode in a similar fashion to A250001. 


Please let me know if there's any viability with this approach, and sorry if you've winced in pain while reading this stuff. 

And finally, have a great rest of your week!

Armand Brunellle

unread,
Sep 2, 2025, 9:23:03 AM (5 days ago) Sep 2
to SeqFan
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. 

The reality is, a sperical environment isn't best to classify those, or to represent them in a meaningfull way. 
So from my view, using the [-0, 1, -0] ... [0, -1, 0] is actually the same approach where the root node is at the intersection of only 2 units and the third is the expansion into a different environment or cluster, so you triangulate it.

Does it makes sense to you? (I might be a fool as well so...)

Arthur O'Dwyer

unread,
Sep 2, 2025, 9:59:23 AM (5 days ago) Sep 2
to seq...@googlegroups.com, Nart Tehaucha
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.

The reason I don't think the approach is viable is what you've already identified: your approach fundamentally can't distinguish between—


Config 1:
sample config3.PNG
Config 2:
sample config2.PNG


Less importantly, I see a source of confusion with your definition of "sibling":

[...]

(Fig 2, Sibling)

sibling.PNG

A sibling is a circle that intersects with one (or both) of the parent circles without crossing the intersection points between the parents.


What do you mean by "intersects with one (or both)"? In the diagram above, circle 3 clearly can't intersect with both circle 1 and circle 2.
But circle 2 does intersect with both 1 and 3; does this make 2 a sibling with respect to (1,3)?  I want to say no (the definition is just too loose), because 2 is definitely a host with respect to (1,3), and I don't think you intended for your categories to be overlapping like that.

...Aha, you mean like in your diagram below! Below, 3 is a sibling of (1,2) and intersects both 1 and 2.

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.

Sample configuration of 4 circles:


sample config.png



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.

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.


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.

It would be useful to fully understand this comment on A250001:
Once you get to n=5, geometric concerns mean that not all topologically-conceivable arrangements are actually circle-drawable. My program enumerated 16977 conceivable arrangements of 5 pseudo-circles, and Christopher Jones and I together have figured out how to show that 26 of these arrangements are not actually circle-drawable. [...] There will be a new sequence [A288559] for the number of topologically-conceivable arrangements. - Jon Wild, Aug 25 2016

IIUC, by "topologically-conceivable" Jon meant "if you simplify the problem down from circles to arbitrary closed curves in the plane, forbidding a curve to self-intersect, and forbidding two curves to intersect in more than two points." A288559 calls these curves "pseudocircles." Obviously there are more arrangements of pseudocircles than of circles; but apparently not too many more?
Stefan Felsner & Manfred Scheucher, Homepage of Pseudocircles
Stefan Felsner & Manfred Scheucher, "Arrangements of Pseudocircles: On Circularizability" (2017) — Figure 3, on page 5, shows four of the 26 non-circularizable arrangements of pseudocircles, although the diagrams are super squiggly and hard to reason about. Maybe you could arrange those diagrams into a nicer, almost-circular-but-by-definition-not-quite-circular form!  Also, personally I didn't bother to understand the symmetries that allowed them to show only these 4 arrangements as representatives of the whole 26; it would be nice to see all 26 diagrammed out. Such a diagram would make a great addition to the comments on A288559 and A250001.

Regarding lower bounds, I see this comment on A250001:
a(n) >= A000081(n+1) - Benoit Jubin, Dec 21 2014.
and I would add:
For n > 1, a(n) >= A000081(n+1) + A000055(n)
because you can take any tree and convert it to an arrangement of circles in the "obvious" way, too (convert each node to a circle and each edge to a pair-of-intersections). But for n=5, that gets you only to 9+3 = 12 arrangements, where in reality A250001(5) = 16951 ≫ 12. So neither of those observations is terribly useful in practice.

HTH,
–Arthur

Nart Tehaucha

unread,
Sep 2, 2025, 1:42:01 PM (5 days ago) Sep 2
to Arthur O'Dwyer, seq...@googlegroups.com
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. 

 Hello Armand! That went over my head a bit, sorry.. I am a bit out of my depth here.

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.

Hello Arthur, thank you for the detailed response, and encouraging words!

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.

I agree that the whole terminology with siblings, uncles, and children is arbitrary and needlessly confusing. I didn't intend any of it to hold semantic value, I just came up with terms that I personally would remember. It would definitely be better to replace them with symbols or numbered letters. But I hope the definitions of each one made sense.

As for your example for shifting the sibling circle down in this diagram:

sample config.png

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.

You are correct that circle #3 will still be called a sibling of PI [1,2], however, you can also notice that the shifted-down #3 is now contained inside circle #2, thus creating a different ID card.
Here's an illustration of the difference:

image.png
New ID Card:

Circles:
[ 1 , 2(3,4) , 3 , 4 ]

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 ]
So the PI's section remains the same, but the difference is reflected in the Circles section of the ID card.
This is why I took the liberty of allowing a Sibling to overlap either one or both parent circles, as the difference is always "made up for" somewhere else in the ID card.

------------

Now for a possible solution for the 'loop' / 'ring' problem:

sample config3.PNG

Is to make an 'amendment' to our ID card, and add in a new category called "loops" which we will define as so:

(Fig 6, Loop)
image.png
A loop is a string of overlapping circles that form a closed loop, meaning - each circle in the loop overlaps with exactly two other circles in the loop and no more.
(This definition might be shoddy and not correctly describe a loop, I'll have to think about it more carefully)

We denote a loop with all the numberings of its component circles, sort of how we did with PI's. For the example figure above, the loop is: [ 1 , 2 , 3 ]. For each loop that exists in a given config, we add to the ID card any circles that are placed inside that loop. This is how the new updated ID card will look like for Fig 6:

ID Card:

Circles:
[ 1 , 2 , 3 , 4 ]

PI's:
[1,2] -
Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
[1,3] -
Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
[2,3] -
Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]

Loops:
[1,2,3]: [ 4 ]

-------

Now if we remove circle #4 from the loop, the resulting ID card will reflect the difference.
image.png

ID Card:

Circles:
[ 1 , 2 , 3 , 4 ]

PI's:
[1,2] -
Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
[1,3] -
Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
[2,3] -
Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]

Loops:
[1,2,3]: [ - ]
 
-------------

I am aware how contrived this whole process is, but my (admittedly baseless) hope is that it wouldn't take too much more of these 'amendments' and additions until we arrive at a final, air-tight ID card.

Once you get to n=5, geometric concerns mean that not all topologically-conceivable arrangements are actually circle-drawable.

I did read a bit into the pseudocirclar  stuff, can't say I could fully wrap my head around it. I will trust you that these issues don't go away using the ID card approach either.

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.

Yeah I was afraid that this was the case. But at least for the purposes of determining an upper bound for A250001, isn't it true that we don't actually need to enumerate all the possible ID cards? but instead combinatorially determine the maximum number of different configurations that can be described by said ID card. That is more or less what I tried to do with the formula that I scribbled down towards the end of the original post. This does admit defeat however that this approach will never crack A250001 itself, just at best give us a good useful upper bound, maybe.

Allan Wechsler

unread,
Sep 2, 2025, 4:21:04 PM (5 days ago) Sep 2
to seq...@googlegroups.com, Arthur O'Dwyer
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.

-- Allan

--
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.

Arthur O'Dwyer

unread,
Sep 2, 2025, 5:37:32 PM (5 days ago) Sep 2
to Allan Wechsler, Nart Tehaucha, seq...@googlegroups.com
On Tue, Sep 2, 2025 at 4:21 PM Allan Wechsler <acw...@gmail.com> wrote:
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.

I think "combinatorial representation" is another way of saying "ID card," yes? They both mean (IIUC) what I would by yet another name call a "serialization" or "stringification": a way of boiling down a diagram into a string of characters, such that equivalent diagrams produce equal strings. Anyway, yes, agreed. :)
 
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.

That's a good example! However, that raised a new question for me: Is A250001 counting "free" arrangements or "one-sided" arrangements? That is, are these two arrangements the same or different?
circles-chiral.png
It's not obvious from the sequence title... although it is obvious from the description, which explicitly says "Turning the whole configuration over is allowed." So, OK, we're counting "free" arrangements.
Unfortunately I don't think it's possible to create such a "chiral pair" with any fewer than 5 circles.

But these two arrangements are certainly different, no question... right? And again they have the same containment and intersection relations.
circles-distinct-for-sure.png
As a wise man once said: cars have windows and can move. houses have windows and can’t move. so it’s not the windows that make the car go, it’s something else entirely

It occurs to me to wonder:
- What if all the circles must have unit radius? (Already in a comment on A250001, but I don't see such a sequence.)
- Consider A250001's equivalence condition: "Two arrangements are considered the same if one can be continuously changed to the other while keeping all circles circular (although the radii may be continuously changed), without changing the multiplicity of intersection points, and without a circle passing through an intersection point." What happens if you replace "(although the radii may be continuously changed)" with "and of unchanging radius"? IMHO this constraint is most interesting when all circles must have the same radius to begin with; otherwise you're just counting a lot of boring permutations of diameters.
- What about circles on the sphere instead of in the plane?
- What about arrangements of great circles on the sphere? (Does this end up equivalent to counting arrangements of lines on the projective plane, or something to that effect?)

–Arthur

Neil Sloane

unread,
Sep 2, 2025, 9:39:22 PM (4 days ago) Sep 2
to seq...@googlegroups.com, Allan Wechsler, Nart Tehaucha
I am posting this reply (to this conversation) at the request of Jon Wild, who is in the process of updating his SeqFan email address, and just realized that he doesn't yet have "send" permission from his new address.  So he asked me to post it for him.  Here it is.  There is his new message, which as an appendix has a very long tail of the messages that he is applying to!

Here goes: This is from Jon Wild at McGill, relayed by Neil Sloane


I couldn't quite follow the proposed representation scheme, but I
thought I could share how my enumeration program represented
arrangements (I'm the author of A250001). It wasn't really meant for
public consumption but since it's being discussed, the attached pdf is
one I've sent a few times to people who enquired via email.

When I worked on the problem myself, I found any shortcut to the
representation of an arrangement wasn't enough to distinguish them: you
basically need the full description of the planar map (embedded graph)
that the arrangement represents. I'm not sure how these are represented
conventionally in graph theory packages; my representation works because
we know the map has degree 4, among other restrictions.

Once you have all abstract possibilities, the ensuing geometry problem
(which of the abstract planar maps are realizable with actual honest
round circles?) is very hard.

By the way Andrii Shportko recently helped to format and process the
output of my program for n=6, so there is now an upper limit on the
number of n=6 arrangements that are circle-realizable. There are over 17
million arrangements of 6 pseudo-circles! That sequence is A288559.

Kind regards,

Jon Wild

On 2025-09-02 4:20 PM, Allan Wechsler wrote:
>       
> You don't often get email from acw...@gmail.com. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>

>       
>
> 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 <https://
can01.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Foeis.org%2FA250001%2Fa250001_4.pdf&data=05%7C02%7Cjon.wild%40mcgill.ca%7C85a88820c9904c000f6908ddea5e3fa4%7Ccd31967152e74a68afa9fcf8f89f09ea%7C0%7C0%7C638924413301053423%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AXzHZgiQLQS5BL%2B4kuhkF7p0%2B5lxJJXLhc9bxnwBJaU%3D&reserved=0>, 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.
>
> -- Allan
>
> On Tue, Sep 2, 2025 at 1:42 PM Nart Tehaucha <nartte...@gmail.com
> <mailto:nartte...@gmail.com>> wrote:
>
>         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.
>
>
>       Hello Armand! That went over my head a bit, sorry.. I am a bit out
>     of my depth here.
>
>         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.
>
>
>     Hello Arthur, thank you for the detailed response, and encouraging
>     words!
>
>         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.
>
>
>     I agree that the whole terminology with siblings, uncles, and
>     children is arbitrary and needlessly confusing. I didn't intend any
>     of it to hold semantic value, I just came up with terms that I
>     personally would remember. It would definitely be better to replace
>     them with symbols or numbered letters. But I hope the definitions of
>     each one made sense.
>
>     As for your example for shifting the sibling circle down in this
>     diagram:
>
>     sample config.png
>
>         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.
>
>
>     You are correct that circle #3 will still be called a sibling of PI
>     [1,2], however, you can also notice that the shifted-down #3 is now
>     contained inside circle #2, thus creating a different ID card.
>     Here's an illustration of the difference:
>
>     image.png
>     *_New ID Card:_*
>
>     _Circles:_

>     [ 1 , 2(3,4) , 3 , 4 ]
>
>     _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 ]
>     So the _PI's_ section remains the same, but the difference is
>     reflected in the _Circles_ section of the ID card.

>     This is why I took the liberty of allowing a Sibling to overlap
>     either one or both parent circles, as the difference is /always/

>     "made up for" somewhere else in the ID card.
>
>     ------------
>
>     Now for a possible solution for the 'loop' / 'ring' problem:
>
>     sample config3.PNG
>
>     Is to make an 'amendment' to our ID card, and add in a new category
>     called "loops" which we will define as so:
>
>     _(Fig 6, Loop)_
>     image.png
>     /A loop is a string of overlapping circles that form a closed loop,
>     meaning - each circle in the loop overlaps with //exactly //two
>     other circles in the loop and no more./

>     (This definition might be shoddy and not correctly describe a loop,
>     I'll have to think about it more carefully)
>     /
>     /

>     We denote a loop with all the numberings of its component circles,
>     sort of how we did with _PI's_. For the example figure above, the

>     loop is: [ 1 , 2 , 3 ]. For each loop that exists in a given config,
>     we add to the ID card any circles that are placed inside that loop.
>     This is how the new updated ID card will look like for Fig 6:
>
>     *_ID Card:_*
>     *_
>     _*
>     _Circles:_

>     [ 1 , 2 , 3 , 4 ]
>
>     _PI's:_

>     [1,2] -
>     Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
>     [1,3] -
>     Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
>     [2,3] -
>     Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
>
>     _Loops:_

>     [1,2,3]: [ 4 ]
>
>     -------
>
>     Now if we remove circle #4 from the loop, the resulting ID card will
>     reflect the difference.
>     image.png
>
>     *_ID Card:_*
>     *_
>     _*
>     _Circles:_

>     [ 1 , 2 , 3 , 4 ]
>
>     _PI's:_

>     [1,2] -
>     Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
>     [1,3] -
>     Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
>     [2,3] -
>     Siblings: [ - ] , Uncles: [ - ] , Children: [ - ] , Hosts: [ - ]
>
>     _Loops:_

>     [1,2,3]: [ - ]
>     -------------
>
>     I am aware how contrived this whole process is, but my (admittedly
>     baseless) hope is that it wouldn't take too much more of these
>     'amendments' and additions until we arrive at a final, air-tight ID
>     card.
>
>         Once you get to n=5, geometric concerns mean that not all
>         topologically-conceivable arrangements are actually circle-drawable.
>
>
>     I did read a bit into the pseudocirclar  stuff, can't say I could
>     fully wrap my head around it. I will trust you that these issues
>     don't go away using the ID card approach either.
>
>         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.
>
>
>     Yeah I was afraid that this was the case. But at least for the
>     purposes of determining an upper bound for A250001, isn't it true
>     that we don't actually need to enumerate all the possible ID cards?
>     but instead combinatorially determine the maximum number of
>     different configurations that can be described by said ID card. That
>     is more or less what I tried to do with the formula that I scribbled
>     down towards the end of the original post. This does admit defeat
>     however that this approach will never crack A250001 itself, just
>     at best give us a good useful upper bound, maybe.
>
>
>     On Tue, Sep 2, 2025 at 4:59 PM Arthur O'Dwyer
>     <arthur....@gmail.com <mailto:arthur....@gmail.com>> wrote:
>
>         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.
>
>         The reason I don't think the approach is viable is what you've
>         already identified: your approach fundamentally can't
>         distinguish between—
>
>
>             Config 1:
>             sample config3.PNG
>             Config 2:

>             sample config2.PNG
>
>
>         Less importantly, I see a source of confusion with your
>         definition of "sibling":
>
>             [...]
>
>             (Fig 2, Sibling)
>
>             sibling.PNG
>
>             A sibling is a circle that intersects with one (or both) of
>             the parent circles without crossing the intersection points
>             between the parents.
>
>
>         What do you mean by "intersects with one (or both)"? In the
>         diagram above, circle 3 clearly can't intersect with /both/

>         circle 1 and circle 2.
>         But circle 2 does intersect with both 1 and 3; does this make 2
>         a sibling with respect to (1,3)?  I want to say no (the
>         definition is just too loose), because 2 is /definitely/ a /
>         host/ with respect to (1,3), and I don't think you intended for

>         your categories to be overlapping like that.
>
>         ...Aha, you mean like in your diagram below! Below, 3 is a
>         sibling of (1,2) and intersects both 1 and 2.
>
>         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.
>
>             Sample configuration of 4 circles:
>
>
>             sample config.png
>
>
>             _**_

>
>
>         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.
>
>             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.
>
>
>         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.
>
>         It would be useful to fully understand this comment on A250001:
>         Once you get to n=5, geometric concerns mean that not all
>         topologically-conceivable arrangements are actually circle-
>         drawable. My program enumerated 16977 conceivable arrangements
>         of 5 pseudo-circles, and Christopher Jones and I together have
>         figured out how to show that 26 of these arrangements are not
>         actually circle-drawable. [...] There will be a new sequence
>         [A288559 <https://can01.safelinks.protection.outlook.com/?
>         url=https%3A%2F%2Foeis.org%2FA288559&data=05%7C02%7Cjon.wild%40mcgill.ca%7C85a88820c9904c000f6908ddea5e3fa4%7Ccd31967152e74a68afa9fcf8f89f09ea%7C0%7C0%7C638924413301081145%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Z7AoWg9nMYIeN02hols2A3UHAS3OwUSZxZvwDH3vR9c%3D&reserved=0>] for the number of topologically-conceivable arrangements. - Jon Wild <https://oeis.org/wiki/User:Jon_Wild>, Aug 25 2016

>
>         IIUC, by "topologically-conceivable" Jon meant "if you simplify
>         the problem down from /circles/ to /arbitrary closed curves/ in

>         the plane, forbidding a curve to self-intersect, and forbidding
>         two curves to intersect in more than two points." A288559
>         <https://can01.safelinks.protection.outlook.com/?
>         url=https%3A%2F%2Foeis.org%2FA288559&data=05%7C02%7Cjon.wild%40mcgill.ca%7C85a88820c9904c000f6908ddea5e3fa4%7Ccd31967152e74a68afa9fcf8f89f09ea%7C0%7C0%7C638924413301124065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vm02szIObvzJT6jjapik9HWgYZ2ySQ6D7X910D0MCGI%3D&reserved=0> calls these curves "pseudocircles." Obviously there are more arrangements of pseudocircles than of circles; but apparently not /too many/ more?

>         Stefan Felsner & Manfred Scheucher, Homepage of Pseudocircles
>         <https://can01.safelinks.protection.outlook.com/?
>         url=https%3A%2F%2Fwww3.math.tu-
>         berlin.de%2Fdiskremath%2Fpseudocircles%2F&data=05%7C02%7Cjon.wild%40mcgill.ca%7C85a88820c9904c000f6908ddea5e3fa4%7Ccd31967152e74a68afa9fcf8f89f09ea%7C0%7C0%7C638924413301139805%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g7MWcCnNLubfNwzyHHkg%2BAL83TZy2LVlyJvNeQyiS9E%3D&reserved=0>

>         Stefan Felsner & Manfred Scheucher, "Arrangements of
>         Pseudocircles: On Circularizability" <https://
>         can01.safelinks.protection.outlook.com/?
>         url=https%3A%2F%2Farxiv.org%2Fabs%2F1712.02149&data=05%7C02%7Cjon.wild%40mcgill.ca%7C85a88820c9904c000f6908ddea5e3fa4%7Ccd31967152e74a68afa9fcf8f89f09ea%7C0%7C0%7C638924413301153421%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iO4GvJy57Z33p6zKuUG8nvea%2FVt2tJiWEF8hVBxBJa0%3D&reserved=0> (2017) — Figure 3, on page 5, shows four of the 26 non-circularizable arrangements of pseudocircles, although the diagrams are super squiggly and hard to reason about. Maybe you could arrange those diagrams into a nicer, almost-circular-but-by-definition-not-quite-circular form!  Also, personally I didn't bother to understand the symmetries that allowed them to show only these 4 arrangements as representatives of the whole 26; it would be nice to see all 26 diagrammed out. Such a diagram would make a /*great*/ addition to the comments on A288559 and A250001.

>
>         Regarding lower bounds, I see this comment on A250001:
>         a(n) >= A000081 <https://
>         can01.safelinks.protection.outlook.com/?
>         url=https%3A%2F%2Foeis.org%2FA000081&data=05%7C02%7Cjon.wild%40mcgill.ca%7C85a88820c9904c000f6908ddea5e3fa4%7Ccd31967152e74a68afa9fcf8f89f09ea%7C0%7C0%7C638924413301166609%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V8k1laYLeMUMb3SP0nPw33%2FtnUm%2ButFJwX9A5ak0Kb4%3D&reserved=0>(n+1) - Benoit Jubin <https://oeis.org/wiki/User:Benoit_Jubin>, Dec 21 2014.
>         and I would add:
>         For n > 1, a(n) >= A000081 <https://
>         can01.safelinks.protection.outlook.com/?
>         url=https%3A%2F%2Foeis.org%2FA000081&data=05%7C02%7Cjon.wild%40mcgill.ca%7C85a88820c9904c000f6908ddea5e3fa4%7Ccd31967152e74a68afa9fcf8f89f09ea%7C0%7C0%7C638924413301193247%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZI5JTrZQgoWDAxTklyuOMayEvcwJ0V2dWdS0MRv4dh4%3D&reserved=0>(n+1) + A000055 <https://oeis.org/A000055>(n)

>         because you can take any tree and convert it to an arrangement
>         of circles in the "obvious" way, too (convert each node to a
>         circle and each edge to a pair-of-intersections). But for n=5,
>         that gets you only to 9+3 = 12 arrangements, where in reality
>         A250001(5) = 16951 ≫ 12. So neither of those observations is
>         terribly useful in practice.
>
>         HTH,
>         –Arthur
Best regards
Neil 

Neil J. A. Sloane, Chairman, OEIS Foundation.
Also Visiting Scientist, Math. Dept., Rutgers University, 



--
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.

Allan Wechsler

unread,
Sep 2, 2025, 9:46:47 PM (4 days ago) Sep 2
to Neil Sloane, seq...@googlegroups.com, Nart Tehaucha
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.

M F Hasler

unread,
Sep 2, 2025, 9:50:17 PM (4 days ago) Sep 2
to seq...@googlegroups.com
On Tue, Sep 2, 2025 at 9:46 PM Allan Wechsler <acw...@gmail.com> wrote:
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.

I agree, but a few hundred lines of multiply quoted text should be omitted in subsequent replies to this list.

-M.

Neil Sloane

unread,
Sep 2, 2025, 10:10:28 PM (4 days ago) Sep 2
to seq...@googlegroups.com
Here (perhaps) is Jon Wild's pdf file
Best regards
Neil 

Neil J. A. Sloane, Chairman, OEIS Foundation.
Also Visiting Scientist, Math. Dept., Rutgers University, 


--
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.
A250001_jonsRepresentationOfArrangements.pdf

Jon Wild

unread,
Sep 2, 2025, 10:35:53 PM (4 days ago) Sep 2
to Neil Sloane, seq...@googlegroups.com
(Replying to Neil and to the group -- if it doesn't get posted to the
list perhaps Neil will forward):

I might add to the description in the pdf that Neil forwarded for me,
that the "table of nodes" representation shown there can be easily
translated into a "table of circles" representation. The example shown
on page 4 of the pdf, for example, could instead be represented as:

1: a b d g j l
2: a b c f i h
3: c e i k l d
4: e h k j g f

As long as you ensure node 'a' is on the outside boundary, that table of
circles can be unambiguously turned into a sketch.

My enumeration program only deals with these text representations of the
arrangements (the actual circle drawings come later). The enumeration
program figures out all the ways you can add a new closed path to
existing arrangements, such that the new path intersects every existing
circle (or pseudo-circles) exactly 0 or 2 times, does not
self-intersect, and results in a clockwise orientation. I compute the
new node table, put it in canonic form, and check whether I already have
it or not.

In counting the ways of adding disconnected circles and arrangements of
circles to a connected arrangement, the tricky part is taking into
account the symmetries of the enclosing figure.

It's actually easy for my program to also take care of tangent
relationships, and I've generated those numbers too, but never posted them.

Recently I realized that it would also be quite straightforward to
generalize to arrangements where 3 circles are allowed to intersect in a
single point.

Arrangements of pseudo-ellipses will take a little more work but can
follow the same process. A new pseudo-ellipse can intersect 0, 2, or 4
times with each existing pseudo-ellipse (with an additional restriction
because not every ordering of those 4 intersections results in something
drawable with convex curves).

So there are many combinations of these parameters that need new
sequences made for them! I've been meaning to...

Jon Wild

Jon Wild

unread,
Sep 2, 2025, 10:36:01 PM (4 days ago) Sep 2
to seq...@googlegroups.com

Jon Wild

unread,
Sep 2, 2025, 11:02:56 PM (4 days ago) Sep 2
to seq...@googlegroups.com
Arthur, a couple of things:

> It's not obvious from the sequence title... although it is obvious from
> the description, which explicitly says "Turning the whole configuration
> over is allowed." So, OK, we're counting "free" arrangements.

Correct, in other words A250001 is reduced for mirror symmetry.

> 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?

> - What about circles on the sphere instead of in the plane?

Yes, on the sphere I've also computed these. The planar arrangements
collapse into equivalence classes that are indistinguishable on the
sphere. (There's a new symmetry that you can introduce to the node
tables that lets you do this quickly.) For example, there are 21
connected arrangements of 4 circles on a sphere (representing the 112
arrangements in the plane, so on average 5 or 6 per equivalence class);
984 using 5 circles (representing the 15528 in the plane, so on average
about 15 per equivalence class -- this comes from the fact that any of
the interior regions can be re-projected as the unbound face).

When you start caring about real circles rather than pseudo-circles, a
given arrangement will not become drawable on the sphere if it wasn't
drawable in the plane, and vice-versa.

Best,

Jon Wild


Arthur O'Dwyer

unread,
Sep 3, 2025, 12:23:14 AM (4 days ago) Sep 3
to seq...@googlegroups.com, jon....@mcgill.ca
On Tue, Sep 2, 2025, 11:02 PM Jon Wild <jon....@mcgill.ca> wrote:
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.

Can you give an example? I still can't think of any way to do it with only 4.

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?

Ooh, tricky. For A250001's purposes the answer is "no," right?

–Arthur

Jon Wild

unread,
Sep 3, 2025, 12:54:08 AM (4 days ago) Sep 3
to Arthur O'Dwyer, seq...@googlegroups.com
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.

> 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?
>
> Ooh, tricky. For A250001's purposes the answer is "no," right?

That would be my interpretation, too. (But it shows that "being allowed
to turn it over" isn't a super precise formulation.)

Jon

some_chiral_4_arrangements.pdf

Arthur O'Dwyer

unread,
Sep 3, 2025, 10:30:08 AM (4 days ago) Sep 3
to Jon Wild, seq...@googlegroups.com
On Wed, Sep 3, 2025 at 12:54 AM Jon Wild <jon....@mcgill.ca> wrote:
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.

Oh, right. I should have seen it sooner, because here's how one can remove one circle from my earlier five-circle example:
circles-chiral4 (1).png
(Re Jon's PDF of 23 examples: This is the one shown tilted at the very bottom of the first page. The fifth one in the first row has the same idea, but distinct. Jon already realized that the third one in the first row doesn't belong. ;))

Thanks!
–Arthur

Ali Sada

unread,
Sep 3, 2025, 2:57:40 PM (4 days ago) Sep 3
to seq...@googlegroups.com
Hi everyone, I just have one question. Are there cases where the diameters of the circles or the x,y coordinates of their centers cannot be integers? 

--
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.

Salsero Blanco

unread,
Sep 3, 2025, 3:59:36 PM (4 days ago) Sep 3
to seq...@googlegroups.com
Hi Ali,
all centers and diameters can always be integer. 
None must be irrational. So when all are rational the whole design can be scaled up by the denominators so all values become integer.

Reply all
Reply to author
Forward
0 new messages