What is the main difference between minimize(method=’BFGS’) and scipy.optimize.fmin_bfgs? In which situations should one be preferred over the other?
It's the same function.
Choose the interface you prefer, minimize usually being easier to use also allowing to swap out the algorithm if needed.
I have to implement an algorithm which fits perfectly to the procedural design approach. It has no relations with some data structure, it just takes couple of objects, bunch of control parameters and performs complicated operations on them, including creating and modifying intermediate temporal data, subroutines calls, many cpu-intensive data transformations. The algorithm is too specific to include in either parameter object as method.
What is idiomatic way to wrap such algorithms in an OOP language? Define static object with static method that performs calculation? Define class that takes all algorithm parameters as constructor arguments and have result method to return result? Any other way?
If you need more specifics, I'm writing in scala. But any general OOP approach is also applicable.
A static method (or a method on a singleton object in the case of Scala -- which I'm just gonna call a static method because that's the most common terminology) can work perfectly fine and is probably the most common approach to this.
There's some reasons to use other approaches, but they aren't strictly necessary and I'd avoid them unless you actually need an advantage that they give. The reason for this is because static methods are the simplest (if least versatile) approach.
Using a non-static method can be useful because you can then utilize design patterns like the factory pattern. For example, you might have an Operator class with a method evaluate. Now you could have different factories create different Operators so that you can swap your algorithm on the fly. Perhaps a calculator might have an AddOperatorFactory, MultiplyOperatorFactory and so on. Obviously this requires that you are able to instantiate an object that represents the algorithm. Of course, you could just pass a function around directly, as Scala and many other languages allow. Classes allow for inheritance, though, which opens the doors for some design patterns and, well, you're asking about OOP, not Scala specifically.
Also useful is the ability to have state with an object. With static methods, your only options for retaining state are either having global state (ew) or making the user of the static methods keep track of this state (more work for the users). With an instance of an object, you can keep that state inside the instance. For example, if your algorithm is a graph search, perhaps you'd want to allow resuming a search after you find the first match (which obviously requires storing state).
It's not much harder to have to do new MyAlgorithm().doStuff() instead of MyAlgorithm.doStuff(), so if in doubt, I would err on the side of avoiding static methods if you think you'll need the functionality that having an instance offers.
When I work with UITableViewControllers - especially when using NSFetchedResultsController - I find myself repeating a lot of base functionality on every controller. Which I hate. I'd much rather love to write these methods once and keep it all neat and tidy.
So I was wondering: What do you guys do to not repeat yourself writing UIViewControllers. How do you DRY up your code. Inheritance, protocols, whatever.
Thanks! Looking forward to your answers.
(Since this question doesn't have a definitive answer, I will accept the one I find the best.
Is that the way to do it?)
You can write your own controllers with the basic functionality and then subclass and reuse them. Check the CoreDataTableViewController class that was built for the Stanford iPhone Application Development course -> http://www.stanford.edu/class/cs193p/cgi-bin/drupal/node/167
One technique is to subclass your own subclass. This, modularizes and isolates the differences nicely, however it generates a lot of classes and files, which some find harder to read.
Another technique, which you can use when you want to create a bunch of almost identical controllers with just slight differences, is to give one class a "type" parameter or instance variable. Set the controller's type when you init a controller, and use the controller's type in "if" or switch statements (etc.) to select between slight differences in controller behaviors at run-time. This can help keep all the differences more compactly located in source code.
I made this new Core Data wrapper for iOS in Swift - https://github.com/tadija/AERecord
It has Swift version of CoreDataTableViewController, and CoreDataCollectionViewController also.
Beside that you can use it to setup Core Data stack like this:
AERecord.setupCoreDataStack()
Access context for current thread like this:
AERecord.defaultContext
Save context like this:
AERecord.saveContext()
Create fetch requests like this:
NSManagedObject.create()
NSManagedObject.firstOrCreateWithAttribute("city", value: "Belgrade")
NSManagedObject.deleteAll()
let predicate = ...
NSManagedObject.firstWithPredicate(predicate)
NSManagedObject.allWithAttribute("year", value: 1984)
And much more... I hope it will be useful for someone.
What is the right code pattern for NSNumberFormatter?
There are many example on the Internet (including this one: http://mac-objective-c.blogspot.com/2009/04/nsnumberformatter-some-examples.html) where the NSNumberFormatter is allocated and initialized each time it is needed.
Yet some other examples in the Apple Documentation (including International Mountains) prefer to use it as a private property. Another example (Locations) use it through a static variable.
How do you use an NSNumberFormatter? What is the most efficient technique?
NSNumberFormatter is not an excessively complicated object, so unless you're using it frequently in a tight loop, efficiency doesn't really matter.
With that said, I'd tend to default to keeping it around in a static variable, if you're trying to minimize the number of instances you create.
I think the examples are just showing how to create and use the formatters, not necessarily the most efficient way to use them. My rule of thumb is if the code will use them more than once, I keep them around somewhere. This also makes debugging and maintenance easier.
I have class method that returns a list of employees that I can iterate through. What's the best way to return the list? Typically I just return an ArrayList. However, as I understand, interfaces are better suited for this type of action. Which would be the best interface to use? Also, why is it better to return an interface, rather than the implementation (say ArrayList object)? It just seems like a lot more work to me.
Personally, I would use a List<Employee> for creating the list on the backend, and then use IList when you return. When you use interfaces, it gives you the flexability to change the implementation without having to alter who's using your code. If you wanted to stick with an ArrayList, that'd be a non-generic IList.
# Jason
You may as well return IList<> because an array actually implements this interface.
The best way to do something like this would be to return, as you say, a List, preferably using generics, so it would be List<Employee>.
Returning a List rather than an ArrayList means that if later you decide to use, say, a LinkedList, you don't have to change any of the code other than where you create the object to begin with (i.e, the call to "new ArrayList())".
If all you are doing is iterating through the list, you can define a method that returns the list as IEnumerable (for .NET).
By returning the interface that provides just the functionality you need, if some new collection type comes along in the future that is better/faster/a better match for your application, as long as it still implements IEnumerable you can completely rewrite your method, using the new type inside it, without changing any of the code that calls it.
Is there any reason the collection needs to be ordered? Why not simply return an IEnumerable<Employee>? This gives the bare minimum that is required - if you later wanted some other form of storage, like a Bag or Set or Tree or whatnot, your contract would remain intact.
I disagree with the premise that it's better to return an interface. My reason is that you want to maximize the usefulness a given block of code exposes.
With that in mind, an interface works for accepting an item as an argument. If a function parameter calls for an array or an ArrayList, that's the only thing you can pass to it. If a function parameter calls for an IEnumerable it will accept either, as well as a number of other objects. It's more useful
The return value, however, works opposite. When you return an IEnumerable, the only thing you can do is enumerate it. If you have a List handy and return that then code that calls your function can also easily do a number of other things, like get a count.
I stand united with those advising you to get away from the ArrayList, though. Generics are so much better.
An interface is a contract between the implementation and the user of the implementation.
By using an interface, you allow the implementation to change as much as it wants as long as it maintains the contract for the users.
It also allows multiple implementations to use the same interface so that users can reuse code that interacts with the interface.
You don't say what language you're talking about, but in something .NETish, then it's no more work to return an IList than a List or even an ArrayList, though the mere mention of that obsolete class makes me think you're not talking about .NET.
An interface is essentially a contract that a class has certain methods or attributes; programming to an interface rather then a direct implementation allows for more dynamic and manageable code, as you can completely swap out implementations as long as the "contract" is still held.
In the case you describe, passing an interface does not give you a particular advantage, if it were me, I would pass the ArrayList with the generic type, or pass the Array itself: list.toArray()
Actually you shouldn't return a List if thats a framework, at least not without thinking it, the recommended class to use is a Collection. The List class has some performance improvements at the cost of server extendability issues. It's in fact an FXCop rule.
You have the reasoning for that in this article
Return type for your method should be IList<Employee>.
That means that the caller of your method can use anything that IList offers but cannot use things specific to ArrayList. Then if you feel at some point that LinkedList or YourCustomSuperDuperList offers better performance or other advantages you can safely use it within your method and not screw callers of it.
That's roughly interfaces 101. ;-)