Develop Reference

Unknown Data Structure?

I had a question about whether or not Java has its own data structure for what I am looking for. It is something like a combination of an array, linked list and a tree.
If it is not in Java, but exists already as a concept in computer science/other languages, that is also an acceptable answer so I can research it more and find out how to implement it myself.
Here is a picture to better illustrate what I am looking for. Excuse the lack of professionalism; I made it as best as I could:
I am looking for something that starts with several indexed starting elements, that eventually link to other elements and end in a convergence of sorts (one final element). In the end, each index has its corresponding starting element, which is linked all the way to the final converged element.
It should be the case that asking for unknownStructure[i] or something should grab an object that is a representation of the ith starting element linked all the way to the final converged element. (This thing to be grabbed is outlined in various bright colors in the picture).

It seems to me that you are looking for a directed Graph data structure.
You may need to use a list of graphs if needed.
See this page for algorithms and this for implementation.

There is no "name" for this that I know of, but an array of linked list nodes would work quite well for this.
Traditionally linked lists are separate and simply a row of items pointing to the next. However, there is no reason why certain linked list nodes cannot point to the same child node. After all, trees and linked lists are essentially created the same way in Java.
The only foreseeable problem would be if you want to traverse this "tree" back to the starting node in the array. (Which could still be achieved with multiple parent support.)
To implement your linked-list array, simply created a Node class as for a linked list and then created an array of these elements:
Node[] myTreeArray = new Node[];
Then simply fill this array with your "base" nodes and link them to their appropriate children (eventually leading the the "end" node, which has a child of null)

Comparing 2 b-tree's to see if they contain the same values

Seeing that a 2 b-tree's could have the same values, yet a different shape, is there an algorithm to go through the values and compare if both tree's have the same keys?
The point is to be able to bail out if they contain different keys (as soon as possible).
A recursive algorithm probably won't work unless you are performing a lookup in both b-tree's at the same time I'm guessing.
I've seen algorithm's that traverse a b-tree, but I don't want to traverse both, and then compare the keys, I want something smarter that will bail out as early as possible if there is a difference.
Basically the function returns true/false.

The fundamental technique is to somehow have an object that represents the current point in the in-order traversal. Once you have two of those, one for each instance of the tree, you just keep pumping them for the next key, and the first time the two return a different next key, you're done.
In C# you'd use yield return to make a traversal that yields up a single key at a time, and keeps track of where it is in the tree. You can then pass two of those to SequenceEquals, and it will bail out as soon as it encounters the first difference. In Java you'd have to build that mechanism yourself, but it's not that hard to do.

Assuming you mean a b-tree then all you need to do is iterate over both at once. Any deviation between either iterator will prove that their contents differ. It is unlikely you will find a better algorithm than that without collecting more details as you build the trees.
If you are not talking about the b-tree which is described as:
... a B-tree is a tree data structure that keeps data sorted and allows searches, sequential access, insertions, and deletions in logarithmic time.
then you need to sort it first then traverse it.

To ArrayList once, or to ArrayList each time?

I have a program which has a structure like this.
Document which contains (up to 20)
Chapters which contain (up to 100)
Pages which contain (up to 20)
Elements
This structure is represented by JPanels in my program. Meaning this structure has to be visually represented, and I'd rather not make a whole complex of ArrayList (unless absolutely neccessary) since each JPanels have a ZOrder of component, and a getParent() method.
This structure is one-dimenisonal, meaning that the parent has an one-dimensional array (and when I say array, it's purely descriptive, I don't mean ArrayList or anything similar) of its children. Each individual element has an index which represents it's location in(on?) it's parent. Number of elements in a page, and pages in a chapter is inconsistent.
It's easy to get the child's index within it's parent, but what about it's grandparents?
Since the elements can be (and usually are) numbered, having a one numbered list per chapter, I'd have to know the index of element in the Chapter, so I can adjust the numbers when a new element is added to the list (it doesn't have to be added in the end).
This can be solved in two ways (that I know of, that is):
Have an ArrayList in each chapter that keeps all the elements. This would require me that, everytime I add a new element to any page, to add it to the chapter array too.
To accomplish that I'd have to go trough all the previous pages, add up all the elements on them and add index of the new element on the present page to that number, the result being the index of the new element in the chapter, and therfore, in the array. And do that each time I add a new element.
Recreate the arrayList each time I need to get the order of elements in the chapter. Which again means going trought each page and adding each element one after another until I reach the end of chapter. And I'd need it each time a new element is added.
So the question is, which of this two methods is better (more efficient memory or processor time wise)? Which is more in the spirit of Java and programming altogether? Is there a third option that I am unaware of??
Chapter example:
Page one {
1. something
2. more something
3. nothing
.
.
.
16. still nothing
}
Page two {
17. maybe something
18. nope, still nothing
.
.
.
21. giberish
}
etc.
The question is: Which way of doing it is better? If you have a better idea, you can tell me, but I want to know which way of the above two is better non the less.

You need to make a tree. For some reason, programmers want to flatten everything out into tabular structures. You are talking about a tree, you need to either use one or make one.
Sadly, there is nothing in the Java Collections for implementing Trees. You can make them fairly easily.
If you have things that are different contained in the tree, but that need to be treated similarly (as nodes), then do a simple implementation of the Composite Pattern. A good example is a filesystem tree: each node is either a Folder or a File. If you both have them implement an interface called FilesystemItem, then you can put them into their tree structure.
Since you are doing a Document, I would recommend Composite.

At what level is a given element in a Java TreeSet?

Does anybody know a fast way to detect at what level a given element is in a TreeSet? By level, I mean the depth of this element in the tree, i.e. the number of its ancestors.
Background.
I use Java's TreeSet class to store my elements.
To compare two elements I need to compute some auxiliary information about them. I cannot store this auxiliary information for each element as it would take too much memory.
On the other hand, if I regenerate the auxiliary information for each comparison, my program is too slow.
When an element is inserted in the TreeSet, my current implementation computes the auxiliary information for the element it inserts and does not recompute it until the element has found its place in the TreeSet. Afterwards, the auxiliary information is discarded.
To speed up my program, I would like to store the auxiliary information also for the top levels of the TreeSet, as they are involved in many comparisons. So, after comparing two nodes, I would like to decide whether to keep or discard their auxiliary information based on their depth in the TreeSet.
Update.
I would also be grateful if somebody could suggest an alternate class implementing some kind of balanced trees (AVL trees, red/black trees, Splay trees, ...), and where one has access to the height of an element.

The exact depth of each node is simply not exposed by a TreeSet. You'd have to write your own if this is how you want to do it.
You might be able to do something like have each key in the set refer to a shared object that manages the auxiliary information. Each time compareTo() is invoked on a key, it would notify the manager to update its counter for that key. The manager would use these stats to decide which should maintain their auxiliary information.

Data structures: Which should I use for these conditions?

This shouldn't be a difficult question, but I'd just like someone to bounce it off of before I continue. I simply need to decide what data structure to use based on these expected activities:
Will need to frequently iterate through in sorted order (starting at the head).
Will need to remove/restore arbitrary elements from the/a sorted view.
Later I'll be frequently resorting the data and working with multiple sorted views.
Also later I'll be frequently changing the position of elements within their sorted views.
This is in Java, by the way.
My best guess is that I'll either be rolling some custom Linked Hash Set (to arrange the links in sorted order) or possibly just using a Tree Set. But I'm still not completely sure yet. Recommendations?
Edit: I guess because of the arbitrary remove/restore, I should probably stick with a Tree Set, right?
Actually, not necessarily. Hmmm...

In theory, I'd say the right data structure is a multiway tree - preferably something like a B+ tree. Traditionally this is a disk-based data structure, but modern main memory has a lot of similar characteristics due to layers of cache and virtual memory.
In-order iteration of a B+ tree is very efficient because (1) you only iterate through the linked-list of leaf nodes - branch nodes aren't needed, and (2) you get extremely good locality.
Finding, removing and inserting arbitrary elements is log(n) as with any balanced tree, though with different constant factors.
Resorting within the tree is mostly a matter of choosing an algorithm that gives good performance when operating on a linked list of blocks (the leaf nodes), minimising the need to use leaf nodes - variants of quicksort or mergesort seem like likely candidates. Once the items are sorted in the branch nodes, just propogate the summary information back through the leaf nodes.
BUT - pragmatically, this is only something you'd do if you're very sure that you need it. Odds are good that you're better off using some standard container. Algorithm/data structure optimisation is the best kind of optimisation, but it can still be premature.

Standard LinkedHashSet or LinkedMultiset from google collections if you want your data structure to store not unique values.