fractal realms regions

[shaun gilchrist]

So I am making some good progress on fractal realms this evening. I
have the routes for adding regions and storing edges as well as
fetching them working. However I just realized that there is no
implicit/guaranteed order when storing the edges. SO this means I
need to either a) implement linked list structure b) add an
:edge/order attribute or c) not worry about it and somehow make
assumptions based upon shared points implying order? Anyone have
feedback on this?

To refresh - a result from GET /region/square-land would yield:

{:name "square-land"
:edges [
{:first-point {:x 0 :y 0} :second-point {:x 3 :y 0}}
{:first-point {:x 3 :y 0} :second-point {:x 3 :y 3}}
{:first-point {:x 3 :y 3} :second-point {:x 0 :y 3}}
{:first-point {:x 0 :y 3} :second-point {:x 0 :y 0}}]}

The problem I am envisioning is that while that result is in vector
form the order is not guaranteed.

Another thought I have had is that each point has an ID and thus
sorting by the shared points would be viable as well if I returned
{:point-id 12323 :x 2 :y 3} for instance.

Anyway I am near the point I can start actually working on the
actor/region collision detection stuff to test performance.

I am thinking we should start another repository for a web based
client to create/visualize regions/actor positions.

On Wed, Sep 26, 2012 at 9:19 PM, Edgar Honing <epho...@gmail.com> wrote:
>
>
> On Tuesday, September 25, 2012 1:02:40 AM UTC-5, shaun gilchrist wrote:
>>
>> We have mentioned this article a few times so just wanted to link to it
>> here http://www.artima.com/articles/hickey_on_time.html super interesting
>> stuff!
>
>
> Also have a look here:
> http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey
>
> --
>
>

[Edgar Honing]

Is there a compelling need for edge ordering? Not necessarily I think. Can you provide an example where edge ordering is required? What's more: the user of the set of edges can - if needed - perform just in time ordering if so required for that user's purposes.

Alternatively, a completely different representation where points are uniquely represented in a list, followed by a set of edges that make reference to pairs of points (either by index or by keyword). Still no ordering (required). For example (assuming index based point references):

{:name "square-land" 

 :points ( {:x 0 :y 0} {:x 3 :y 0} {:x 3 :y 3} {:x 0 :y 3} )

 :edges { {:fst 0 : snd 1} {:fst 1 : snd 2} {:fst 2 : snd 3} {:fst 3 : snd 0} } }

But ultimately, though. I would argue for a representation that does not repeat 'data', only references to data in whatever shape or form (as in the above example where 2 edges refer to the same point). I would think that such as representation has the best chance as being acceptable as a canonical representation.

Oh, just read the rest of your post and realized the :point-id approach. I like. This also allows for data retrieval by clients where earlier retrieved point sets can be referred to by shapes fetched in subsequent requests. Again, the 'reference' approach - no duplication of data.

[Chad]

If you don't have edge ordering or correlation between regions then the regions could overlap causing incorrect bordering. Yes? No?

Sent from my iPhone

--
 
 

[shaun gilchrist]

Well ordering is basically a "nice-to-have" but not a necessity so
long as it is enforced that all edge points are distinct per region.
Meaning there can not be two edges which share a point for
first-point.

The more I think about this though the more I realize that perhaps the
notion of edge is actually an un-necessary/clumbsy abstraction e.g.
there is no point recording the edge in datomic but rather it should
just contain an ordered set of points to define the shape of the
region. Otherwise there will always be duplicated data for no reason.

This would require that a region is initially defined with a minimum
of 3 points, some sort of triangle. After that I am thinking there
would be a method for adding a point after an existing one (thus
subdividing an edge). The potential issue I can see with this approach
though is that each time a point is added it would require updating
the order attribute of all subsequent points - unless the order
attribute is a float and thus having points w/ orders (1 2 3) and you
added one between 2 and 3 you would have (1 2 2.5 3). This feels
clever and bad at the same time which is usually a good clue that its
the Wrong Thing to do. This leads me back to the notion of
implementing a linked list structure within datomic itself so that
adding a point would only require adding one point and asserting the
tail of the prior point to refer to the new point. As all entities
have ids implicitly that is not explicitly represented but that is
what vertice/region and vertice/tail refer to (an id of another
entitiy - a region and another vertice in thei cse)

So now the current fractal realms schema is:

region
name string

vertice (btw going to adopt this from edgar as it better )
region ref
x float
y float
tail ref

actor
name string
x float
y float

This has been rad having people to bounce ideas off! Hopefully have
this working and committed later tonight -shaun

> --
>
>

[Edgar Honing]

To determine - for convex and concave shapes, whether a point lies within such as shape, you need directed edges, but they do not need to be ordered. 

[Edgar Honing]

linked list => cons cell  ;-)