why did you implement these two methods on the space instead of the cell?

A Cell usually only knows its own coordinate and its contents. It does not know about the boundaries of the world, whether the world wraps around (torus), or the dimensions of the grid.
To convert a physical position (x, y) to a cell, you need to know the Space Dimensions.

Looking at the logic you will see, It relies heavily on self.torus and self.dimensions, which exist on the Grid, not the Cell.

def pos_to_cell(self, position):
    # Needs Grid Dimensions to know if pos is out of bounds
    if not 0 <= position[0] < self.width:
        # Needs Torus setting to know if we should wrap or raise error
        if self.torus:
            coord = position % self.dimensions 
        else:
            raise ValueError("Out of bounds")
            
    return self._cells[coord]

Hypothetical Alternative: If we moved this to Cell, we would have to inject the Grid into every function call, which is clumsy and circular.

# Method on the Cell class
class Cell:
    def pos_to_cell(self, position, grid_instance): # Must pass grid!
        # The cell itself doesn't know the grid's width/height
        if grid_instance.torus:
            ...

I think we also did something like this in mesa/mesa-geo#299, where RasterLayer(eq. to Grid) owns the global context(transform etc.) and Cell only holds their positions

Thanks for the clarification. It makes sense now. But then naming matters as stated below.

Should this ever return None?

Also, if you have the cell already, what's the point of this method? You can just check cell.position yourself.

In my view, when instantiating a discrete space, we generate the indices and the positions a give these to the cell. Afterwards, there is no need to interact much with a space at all.

In case of stacked spaces, we still might need find nearest cell which returns the cell for a given position.

Honestly, I don't see it as an ideal choice for obvious reasons

Not sure what you mean here. To me, it makes more sense that the cell.coordinate is the cell.position in the case of OrthogonalGrids. And then, for finding the nearest cell for a coordinate in case of orthogonal grids, you just round to the nearest integer.

Because of this, on the visualization side, we have to map these coordinates to x,y positions.

1. Looking at the long term, this function will essentially act as the coordinate provider for our visualization modules. If get_position returns the raw index (the corner), agents will be rendered sitting on the grid intersections (vertices) rather than inside the cells, which visually implies a physics bug. If we attempt to fix this 'downstream' by having the visualization layer manually normalize the coordinates (e.g., adding 0.5), we force the renderer to understand the specific geometry rules of the grid. That reintroduces the exact tight coupling we are trying to eliminate

Given a way of declaring the relationship between spaces, the next thing is to automatically make an agent show up in all "stacked" spaces. This is an implementation detail. But, whenever agent.position, this should be propagated to all relevant spaces. We also need an API for an agent or perhaps even an agent type to "opt out" of any given space.

2. I interpret this as:

• Continuous agent has agent.position (e.g., [5.7, 3.2])
• Agent registers in stacked Grid space
• Grid automatically determines which cell: find_nearest_cell([5.7, 3.2]) → cell (5, 3)
• Agent appears in cell (5, 3) for grid-based operations

But: When the agent needs to reference the cell's position (for physics, movement, attraction), what should cell.position return?

Another weak argument is if we look at it through lens of pure physics, agents at center of cell looks more intuitive to me...

Curious to know your thoughts or please correct if I am assuming anything wrong.

If get_position returns the raw index (the corner), agents will be rendered sitting on the grid intersections (vertices) rather than inside the cells, which visually implies a physics bug.

I don't follow. The grid line drawing is an implementation detail that should be derived from how we handle the position of the cell. If we put the cell on 1,1, then grid lines should be drawn on 0.5 and 1.5. So what is considered the corner is a choice we can make while implementing this.

I interpret this as:

Good questions, and part of implementing all this is to flesh out the answers to these questions.

1. The agent position is leading in my view.
2. Once it is determined that a given agent is in cell 5.3, its agent.cell attribute can be set to that cell, and so it is added to cell.agents. This means, if other agents want to use cell-based lookups, they can easily find them. For example, what are the agents that live in the same postcode area as me? Here, postcode areas could be implemented using a DiscreteSpace.
3. I don't know of a use case where the physical position of the cell should matter inside a discrete space itself. Through the connections, we already specify the topology of a discrete space. If you want to know neighboring cells, you can just do a cell.neighborhood.
4. Of course, in the case of the postcode example, an agent might want to know the nearest neighboring postcode to itself. But then, it could just ask the postcode space for k nearest neighbors via agent.position.

I don't follow. The grid line drawing is an implementation detail that should be derived from how we handle the position of the cell. If we put the cell on 1,1, then grid lines should be drawn on 0.5 and 1.5. So what is considered the corner is a choice we can make while implementing this.

Understood.

I don't know of a use case where the physical position of the cell should matter inside a discrete space itself. Through the connections, we already specify the topology of a discrete space. If you want to know neighboring cells, you can just do a cell.neighborhood

Should cells have SPATIAL EXTENT (position in space) or only TOPOLOGICAL EXTENT (connections)?

If cells are purely topological, then:

1. Cells only matter for lookups ("who's near my cell?")
2. All physics happens agent-to-agent via agent.position
3. Cell.position is rendering-only

If cells have spatial extent, then:

1. Cells can have spatial properties (temperature at center, resource density)
2. Physics can be agent-to-agent AND agent-to-cell
3. Cell.position is needed for physics calculations

For now, I think we can agree over cell to be purely topological but as we move closer to implementation of stacked spaces, it might be worth exploring the second alternative and its use-cases. Also, Thanks for detailed clarification

Should cells have SPATIAL EXTENT (position in space) or only TOPOLOGICAL EXTENT (connections)?

That is a very good question. I don't know. For simple spaces like hexes and orthogonal grids, the spatial extent is simple (assuming a given size for a cell). For Voronoi, we can generate it by construction. For networks, there is no natural answer to the question.

Should we not turn DiscreteSpace into an ABC and then handle this and the methods above as abstract methods?

Agree. If you advice, I can do this in follow-up PR