Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MadocComadrin]

O wait, I do have a question. Does anyone know how to extract the row and position in the row(and the other way around) from a pyramid thing like this:

Code: [Select]

    1
  2 3 4
5 6 7 8 9Where the pyramid has n rows. I am passing around the n and the number of the tile, or should I just scrap that plan and make some weird 2 dimensional array?

Edit: scratch that. Too early in the morning to be dealing with non-pascal-esque triangles. You can indeed fit it into a 1-dimensional array though. 

[GlyphGryph]

All you need to do is of the position of the first tile, and the others can easily be found. As mentioned in the previous post, they can be represented as elements in a single one dimensional array fairly easy, and thus it's a pretty straightforward operation to deduce their position.

I also don't understand exactly what you are trying to do, however. So it's hard to be more helpful.

[Aqizzar]

Anyone ever do something as retarded as make a data table with a self-joining key relationship?  Because one of my coworkers did.  I whooped like I'd won a rodeo when I finally figured out how to not just bypass but master the damn thing.

I mean Jesus, why would somebody even do that?

[cerapa]

All you need to do is of the position of the first tile, and the others can easily be found. As mentioned in the previous post, they can be represented as elements in a single one dimensional array fairly easy, and thus it's a pretty straightforward operation to deduce their position.

I also don't understand exactly what you are trying to do, however. So it's hard to be more helpful.

Obviously they can be easily represented, but my problem is with the deducing. Allow me to show you the structure of the pyramid.

Each tile is actually a triangle and has 3 neighbours. I need an easy way to deduce what is the neighbour of what. Complicating matters is the fact that the border tiles have neighbours in other similar pyramids(the pyramids form an icosahedron actually). I think the easiest way to check the neighbours is to convert the size of the pyramid (n) and the ID of the tile into row+position in row, to then get the row+position of the neighbour and to then deduce the ID of the neighbour and return it.

[GlyphGryph]

Yeah... sorry, I still don't know enough to actually help you here. I still understand what you're actually trying to do, to be perfectly honest. And that pictures made me more confused than when I started.

However, if you know the elements of a pyramid in numerical order, as you did before, finding neighbors is trivial, especially if you do a straight up crawl through the pyramid. If you're keeping a 2-dimensional array of them, it is even easier.
(for example:
[[1]
[2,3]
[4,5,6]
[7,8,9,10]])
Since every element is bordering those above it and below it, those adjacent to it, and those below it (x+1).

But, again, I don't understand the context at all, so I don't know if this is helpful or not yet.

Also, I have no idea how you're displaying that with a tile system - offsets, perhaps? If you're using offsets, the array example above should still hold even if it's components of a larger image with only some minor tweaks. You'd just have to ignore the non-pyramid elements, for example.

[Siquo]

That... is actually quite an interesting problem. Even the OEIS (http://oeis.org/) doesn't know that sequence, and Wolfram Alpha doesn't either. Both the left-hand line (1,2,5,10,18,27) and the center-column (1, 3, 7, 14, 22, 32, 44).

I can't come up with a solution, yet, either (at work don't have a lot of time), but it seems to me it must be a very simple one. ARGH!

Anyone ever do something as retarded as make a data table with a self-joining key relationship?

What, you mean like have a column that references an id of the same table? All the time.

[Siquo]

Obviously they can be easily represented, but my problem is with the deducing. Allow me to show you the structure of the pyramid.

Each tile is actually a triangle and has 3 neighbours. I need an easy way to deduce what is the neighbour of what.

Oh, that one is easier. http://oeis.org/A000124

[MadocComadrin]

Here's a relationship that might help:

Code: [Select]

[1]   1
[2]  123
[3] 12345
[4]1234567

for any position, it's neighbors "below" is it's relative position number +[0,1,2]. For example, the neighbors below [1]1 are [2]1+0,  [2]1+1, and  [2]1+2 (or 1, 2 and 3) and the neighbors below [3]4 are [4]4+0, [4]4+1 and [4]4+2 (or 4, 5 and 6).

The "above" neighbors follow the same relationship, but you must test for existence. (For example, [4]3 has above neighbors [3]1, 2 and 3, but [2]3 has only [1]1).

Edit: misinsterpreted what you meant by neighbors. See mendoca's post and my next post.

[mendonca]

Just writing some things down on paper, this is what I think:

with data structured like:

[ [1],
  [2, 3, 4],
  [5, 6, 7, 8, 9],
  etc.
]

Each entry has three neighbours.

The first two neighbours are easy: They are either side of the reference, on the same row.

Where this is an illegal call, this is a boundary reference and it should look for the neighbour on an adjacent set.

If the reference index is 'odd' [1], [3], [5] etc. the third neighbour is on the row above, at an index 1 less than its own.

If the reference index is 'even' [0 ], [2], [4] etc. the third neighbour is on the row below, at an index 1 greater than its own.

I'm reasonably sure that works in general, could you work a function around those rules to check? Probably not that elegant, but that's how I'd try and do it.

e: Ninja'd, posting anyway.

[MadocComadrin]

Ah, this is a sort of coloring problem. If you take two colors and alternate colors for each triangle in a row, any triangle's neighbors are the closest fitting triangles not of the same color.

[cerapa]

Yep, those are the correct neighbours mendonca.

Seems that a 2d array is the way to go?

In that case I have another problem. How the hell do I make a 2d array like that? (I need its size to be variable)

[MadocComadrin]

You can still fit it into a 1-dimensional array and do row+offset math. Nonetheless, what language are you using?

[MagmaMcFry]

Here's the row+offset math:

Code: [Select]

    1
  2 3 4
5 6 7 8 9
Let's say that tile 1 is at (0,0), and tile 8 is at (1, 2).

Code: (Pseudocode) [Select]

num(col, row) {
  return (1 + row^2 + row + col);
}
row(num) {
  return floor(sqrt(num-1));
}
col(num) {
  return num - num(0, row(num));
}

If you reindex your pyramid, then the code is even easier:

Code: [Select]

    0
  1 2 3
4 5 6 7 8

Code: (Pseudocode) [Select]

num(col, row) {
  return (row^2 + row + col);
}
row(num) {
  return floor(sqrt(num));
}
col(num) {
  return num - num(0, row(num));
}



[Nadaka]

Anyone ever do something as retarded as make a data table with a self-joining key relationship?  Because one of my coworkers did.  I whooped like I'd won a rodeo when I finally figured out how to not just bypass but master the damn thing.

I mean Jesus, why would somebody even do that?

Yes. This is one way to create a "tree" data structure with a relationship of parent and child records.
Though it is generally a pain to query arbitrary levels of a tree without repeating a query multiple times.

[cerapa]

Here's the row+offset math:
*snip*

PERFECT! (With slight modifications)