Matthew Wilhelm

I've run into issues 2 & 3 that @JeffBezanson lists in the past and this has been quite painful to recognize and deal with. I'd vote for the parameterizing intervals...

> @mewilhel The problem is that the rounding mode is not a property of the intervals, but of the operations between intervals. @dpsanders Conceptually I agree. I just can't think...

> I think the use of context (typically through Cassette) is unavaoidable. Indeed, we do not want the user to be able to let interact Intervals with different rounding modes...

> However, after thinking about this some more, I think maybe the issue has generated more discussion than it maybe warrants: the method used for directed rounding is a trade...

Thanks for the heads up! I'll dive into this issue in the next couple days.

You can use the command `set_optimizer_attribute(m, "verbosity", X)` with X = 4 to get subproblem summary statistics.

@mzagorowska Thanks for the feedback regarding your problem. I'll look into this shortly. We didn't initially include tests for multiple expressions so I agree that it's likely an error with...

@evrenmturan Thanks for the feedback! 1. The routines accept either a function gSIP as an argument or a vector of functions gSIP = [gSIP1, gSIP2, gSIP3,...]. So that's one option....

We've added a default safeguard to the McCormick.jl operators to address this. Basically, z = y/x becomes MC{N,T}(union(y/Interval(x.Intv.lo,-MC_DOMAIN_TOL), y/Interval(MC_DOMAIN_TOL, x.Intv.hi))) this can be disable by setting `const MC_DOMAIN_CATCH = false`...

Excellent! I'm definitely interested in pursuing this. Would you all prefer the work to be done on a fork of TaylorSeries.jl or shall I start playing with the StaticTaylorSeries.jl repository?