diff --git a/README.md b/README.md index 72f5c3c..b359d3c 100644 --- a/README.md +++ b/README.md @@ -21,6 +21,7 @@ by your model. ## Available Solvers +- [simplex](https://github.com/MatProGo-dev/simplex) - [Gurobi](https://github.com/MatProGo-dev/Gurobi.go) ## Modeling the Mathematical Program Above @@ -66,19 +67,11 @@ p1.Objective = *problem.NewObjective( ## FAQs -> Why are the solvers not bundled into the interface? +> Why are the solvers not bundled into `MatProInterface.go`? -The solvers are separated into separate repositories to avoid compilation issues. -A compilation issue would arise, for example, if Gurobi bindings were built into this interace, -but your computer did not have Gurobi installed on it. The same can be said for a number of other -solvers as well. To avoid such issues, ALL SOLVERS should be included in separate pacakages -that implement the `solver` interface in this package. +The solvers are not bundled into this module to avoid having a large number of dependencies. In other words, to avoid including a large number of solvers in the dependencies (e.g., Gurobi, SNOPT), we will require developers to implement those in separate modules. This should hopefully keep this module "lightweight". -With this in mind, you should be able to use any solver by installing its associated -MatProGo.dev pacakage and then calling its "Solver" object. - -> I feel like things can be done more efficiently in this library. -> Why did you avoid using things like pointer receivers? +> Why did you avoid using things like pointer receivers in your implementations? This project was written to make it easier for first-time Go contributors/users to easily understand. For this reason, I've avoided making some optimizations @@ -93,8 +86,8 @@ ask if this is intentional by creating an issue. > Why do most functions return `error` values? There are two dominant approaches for handling errors/problems -during numerical Go programs. One is to raise an exception/create a fatal flag which terminates the program. -The other is to share error messages to the user using Go's build-in `error` type (or extensions of it) during +in numerical Go programs. One is to raise an exception/create a fatal flag which terminates the program. +The other is to share error messages to the user using Go's built-in `error` type (or extensions of it) during most function calls. In most cases, these error messages will be `nil` indicating that no error occurred, but occasionally they will contain valuable information. @@ -103,6 +96,16 @@ and how to use certain functions through a direct message. Sometimes, the first method of error handling can point users to unintuitive/difficult to read parts of code. Hopefully, this is avoided using this format. +> I have a question for you. How can I ask it? + +Feel free to create an issue (see the Issues tab above) in this repository! + +> I have noticed an error in the code. What should I do? + +You can either: +- Create an issue describing the error and how to reproduce it (see the Issues tab above) +- Fork the repository and create a Pull Request + ## Design Philosophies * Share error information @@ -112,17 +115,6 @@ code. Hopefully, this is avoided using this format. ## To-Dos * [X] Create New AddConstr methods which work for vector constraints -* [ ] Mult - * [ ] General Function (in operators.go) -* [ ] Plus - * [ ] General Function (in operators.go) +* [ ] Deprecate the `optim` package * [ ] Introducing Optional Input for Variable Name to Var/VarVector -* [ ] Consider renaming VarVector to VectorVar -* [ ] Decide whether or not we really need the Coeffs() method (What is it doing?) -* [ ] Write changes to all AtVec() methods to output both elements AND errors (so we can detect out of length calls) -* [ ] Determine whether or not to keep the Solution and Solver() interfaces in this module. It seems like they can be solver-specific. -* [ ] Add Check() to: - * [ ] Expression - * [ ] ScalarExpression - * [ ] VectorExpression interfaces * [ ] Add ToSymbolic() Method for ALL expressions \ No newline at end of file