c
I'm building some sorft of treeview on iOS. It should basically contain simple items/objects and their positions. I thought I could use NSMutableDictionary where NSIntexPaths would be keys. Is that sound idea? Would it make me worth while when navigating through tree?
I wouldn't recommend it as your tree would never be sorted. Reconstructing the tree or iterating along the branches would be very slow.
iOS doesn't have NSTreeNode, but you can use that as a model and try to reimplement that on your own (it's not too hard).
Related
For some odd reason NSOrderedSet does not appear to be implemented in iOS. Is there another object that gives similar functionality -- basically the ability to insert/remove objects randomly and access the first/last in sort order?
It seems to me that something like this would be needed in order to implement basic FIFO queues and the like.
Edit: I ended up doing an RYO solution.
One option is this open source data structures library:
http://dysart.cs.byu.edu/CHDataStructures/index.html
In that library is a CHOrderedSet
http://dysart.cs.byu.edu/CHDataStructures/interface_c_h_ordered_set.html
It's only dependency is NSMutableSet so it should work across all your iOS versions.
EDIT:
As Bourne pointed out above, it's also in iOS5 (reference):
The new NSOrderedSet collection class offers the semantics of sets,
whereby each element occurs at most once in the collection, but where
elements are in a specific order.
CHOrderedSet is a good option if you don't have a hard dependency on iOS5.
NSOrderedSet and NSMutableOrderedSet are not available in iOS 5. Here's the reference for anyone curious:
http://developer.apple.com/library/ios/#documentation/Foundation/Reference/NSMutableOrderedSet_Class/Reference/Reference.html#//apple_ref/occ/cl/NSMutableOrderedSet
How mouch Scala standard library can be reused to create variant of HashMap that does not handle collisions at all?
In HashMap implementation in Scala I can see that traits HashEntry, DefaultEntry and LinkedEntry are related, but I'm not sure whether I have any control over them.
You could do this by extending HashMap (read the source code of HashMap to see what needs to be modified); basically you'd override put and += to not call findEntry, and you'd override addEntry (from HashTable) to simply compute the hash code and drop the entry in place. Then it wouldn't handle collsions at all.
But this isn't a wise thing to do since the HashEntry structure is specifically designed to handle collisions--the next pointer becomes entirely superfluous at that point. So if you are doing this for performance reasons, it's a bad choice; you have overhead because you wrap everything in an Entry. If you want no collision checking, you're better off just storing the (key,value) tuples in a flat array, or using separate key and value arrays.
Keep in mind that you will now suffer from collisions in hash value, not just in key. And, normally, HashMap starts small and then expands, so you will initially destructively collide things which would have survived had it not started small. You could override initialSize also if you knew how much you would add so that you'd never need to resize.
But, basically, if you want to write a special-purpose high-speed unsafe hash map, you're better off writing it from scratch or using some other library. If you modify the generic library version, you'll get all the unsafety without all of the speed. If it's worth fiddling with, it's worth redoing entirely. (For example, you should implement filters and such that map f: (Key,Value) => Boolean instead of mapping the (K,V) tuple--that way you don't have to wrap and unwrap tuples.)
I guess it depends what you mean by "does not handle collisions at all". Would a thin layer over a MultiMap be sufficient for your needs?
I'm getting up to speed with the new APIs introduced in OS 3.0, especially the cool new improvements to Core Animation (mostly on CALayer etc...). Now I'm trying to figure out how to use CAGradientLayer. It looks simple at first, but the NSArray it requires for the colors property must contain CGColorRef (according to the header file). I've tried casting to (id), but then the NSArray seems to contain NSCFType objects, which doesn't sound good.
Anybody figured how to use it or could point to some good code samples?
Thanks
Even though the NSCFType objects in the array "don't sound good", you are supposed to use CGColorRefs directly in the array. The same principle applies here as for the animation question I asked a while back. The examples I've seen for using this class all employ arrays of CGColorRefs.
I've got a pretty big A* pathfinding function that gets called frequently and has to be put in another thread because otherwise it will make my game stutter. I come from a Java background, and recently read a discussion about the speed of HashMap's (essentially the equivalent of NSDictionary) and the different implementations you can use. I'm curious how fast NSDictionary is and whether anyone has found it to be viable option for dealing with lots of immediate and temporary object allocations, or whether it's too slow for that.
Currently I'm using an NSMutableArray for the open and closed lists in the A* algorithm - I would be replacing the closed list with NSMutableDictionary due to the O(1) setObject:forKey and removeObject:forKey, and also creating an NSMutableDictionary that "mirrors" the open list. The pathing data is stored in a big NSMutableArray - I would leave this as-is because index access is fast enough (of course).
So my question is... would this be a noticeable speed improvement or should I roll my own lists and/or maps? I'm just not sure what NSDictionary does and I'd like to know.
If you're wondering how to optimize A*, I'd first ask you if you're using platform-independent extensions, like Iterative Deepening A* (aka IDA*), what kind of a heuristic you're using, and if you're using caching (transposition tables, pattern databases). The questions you're asking are too close to the metal for the moment, because you're optimizing parts of the system which are likely not holding you back.
Have a look at these course slides (especially lecture 10 and lecture 11)
Absolutely it makes a difference - I recently changed a naive implementation of A* using NSArray (is something in the list? iterate to find out...) for the lists and adjacents for NSDictionary (in the list? objectForKey!) and increased performance from not acceptable to acceptable with not too much work.
I am wrapping up an application where I am using a lot of Dictionary classes to store Function and Action delegates. I am now refactoring my project a bit and cleaning code. My question is where do or would you put your Dictionary classes in your project structure? Right now, they are located within the calling class source files but I was wondering if I should create a separate source file to store all my Dictionaries. I hope this is enough information. Please forgive me if it is not. Thanks.
I would organize the dictionaries in the same way as the rest of the code; group related functionality together, and separate unrelated functionality.
In addition, I'd look at how the delegation dictionaries are used. If your usage pattern is always to retrieve a delegate and immediately invoke it, then I'd wrap that behavior into a class with a "do-the-right-thing" method. Then each such class can be named by the domain concept it represents.
For example, if you had a dictionary which mapped US state abbreviations to a sales tax calculation, then you could wrap all of that into a class with a "compute sales tax" method taking a state code and subtotal as arguments. The fact that it's using a dictionary to look up the right computation scheme then becomes a hidden implementation detail.
Normally, the Dictionary class would be a thing unto itself (a library) and your various users would create instances of it.
If need be, they might specialize / sub-class it, but this should be rare.
Maybe the question you really should be asking yourself "why do I have multiple Dictionary classes"?