SERVING THE QUANTITATIVE FINANCE COMMUNITY

 
User avatar
Cuchulainn
Topic Author
Posts: 62626
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The One-liner Agree/Disagree Thread

June 26th, 2015, 6:36 pm

QuoteMost functions are exception-neutral rather than noexceptI disagree.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
ppauper
Posts: 70239
Joined: November 15th, 2001, 1:29 pm

The One-liner Agree/Disagree Thread

June 28th, 2015, 11:16 am

I agree
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

The One-liner Agree/Disagree Thread

June 28th, 2015, 11:58 am

Interesting.....This seems to be the internal flip-side of whether functions test (or don't test) for the validity of pre-conditions -- if a function calls another function, then what does it assume will be returned and does it check the correctness of the returned result? In the world of commercial contracts (e.g., physical manufacturing), the supplier (the function) often has a responsibility to return the expected output with no excuses (=no exceptions) which implies the supplier/function MUST catch all exceptions and neutralize them. That is, the contract delegates some action to the suppler/function under the expectation of the competence of the supplier/function to get the job done (a "no-throw guarantee").One style of programming would have functions assume that all inputs are valid and all internal functions return valid values. The opposite extreme would have each function ensure that every possible error in inputs or internally received outputs of other functions is somehow caught and managed.P.S. The word "most" raises the question of how one samples functions -- is it the percentage of written functions (from the universe of open source, commercial libraries, OS APIs, etc.) or is it percentage of function calls which would bias the same toward popular functions.
 
User avatar
Cuchulainn
Topic Author
Posts: 62626
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The One-liner Agree/Disagree Thread

June 30th, 2015, 8:37 am

QuoteOne style of programming would have functions assume that all inputs are valid and all internal functions return valid values. The opposite extreme would have each function ensure that every possible error in inputs or internally received outputs of other functions is somehow caught and managed.This is the Design by Contract idea. An issue is how to make it all consistent. Who assumes what? Bertrand Meyer ==> customer is always wrong.C++ falls down IMO here. Standard exception hierarchies are frowned and current wisdom is to use noexcept?? C++11 compiler builders stand up :D Thanks a bunch :)
Last edited by Cuchulainn on June 29th, 2015, 10:00 pm, edited 1 time in total.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
dd3
Posts: 246
Joined: June 8th, 2010, 9:02 am

The One-liner Agree/Disagree Thread

June 30th, 2015, 10:19 am

QuoteOriginally posted by: CuchulainnQuoteOne style of programming would have functions assume that all inputs are valid and all internal functions return valid values. The opposite extreme would have each function ensure that every possible error in inputs or internally received outputs of other functions is somehow caught and managed.This is the Design by Contract idea. An issue is how to make it all consistent. Who assumes what? Bertrand Meyer ==> customer is always wrong.C++ falls down IMO here. Standard exception hierarchies are frowned and current wisdom is to use noexcept?? C++11 compiler builders stand up :D Thanks a bunch :)noexcept should only be used if you can tell that it's impossible an exception can occur, this really is only possible for the smallest of functions, constructors, one-liners etc.I've never seen anyone recommend using noexcept everywhere.
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

The One-liner Agree/Disagree Thread

June 30th, 2015, 1:38 pm

QuoteOriginally posted by: CuchulainnQuoteOne style of programming would have functions assume that all inputs are valid and all internal functions return valid values. The opposite extreme would have each function ensure that every possible error in inputs or internally received outputs of other functions is somehow caught and managed.This is the Design by Contract idea. An issue is how to make it all consistent. Who assumes what? Bertrand Meyer ==> customer is always wrong.C++ falls down IMO here. Standard exception hierarchies are frowned and current wisdom is to use noexcept?? C++11 compiler builders stand up :D Thanks a bunch :)If the customer is always wrong, what about the supplier? If one cannot trust the inputs to a function, why should one trust the outputs of a function?If one can assume that certain communications or data within a system are always provably correct, then one can write much more efficient code that doesn't have to check every single bit every single time for errors. Yet as soon as one opens up such as system to outside calls (or down-the-road extensions or maintenance ), then we can't trust provable correctness. Maybe that is the overall point here -- that correctness is fragile and that rampant checking (and rechecking) of inputs and outputs is robust.Personally, I think exceptions seem like a good way to handle anomalous qualitative outcomes associated with quantitative computations (e.g., non-convergence, out-of-bounds results, singularities, non-trivial incorrectness of inputs, etc.). Exceptions let one codify these events for mitigation. Returning a NaN is like facing a wailing baby -- one knows something is wrong but can't tell the cause.
 
User avatar
Cuchulainn
Topic Author
Posts: 62626
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The One-liner Agree/Disagree Thread

June 30th, 2015, 4:54 pm

QuoteIf the customer is always wrong, what about the supplier? If one cannot trust the inputs to a function, why should one trust the outputs of a function?The supplier MUST deliver in the case the input is good. aka postcondition. QuoteMaybe that is the overall point here -- that correctness is fragile and that rampant checking (and rechecking) of inputs and outputs is robust.Maginot Line?Personally, I think exceptions seem like a good way to handle anomalous qualitative outcomes associated with quantitative computations (e.g., non-convergence, out-of-bounds results, singularities, non-trivial incorrectness of inputs, etc.). Exceptions let one codify these events for mitigation. Returning a NaN is like facing a wailing baby -- one knows something is wrong but can't tell the cause. C++11 does not seem to like EH because it uses heap/unwind stack. Throw out the baby with bath water?
Last edited by Cuchulainn on June 29th, 2015, 10:00 pm, edited 1 time in total.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
Cuchulainn
Topic Author
Posts: 62626
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The One-liner Agree/Disagree Thread

July 1st, 2015, 6:58 am

QuoteThe prevailing programming paradigm, object oriented programming, doesn?t buy you anything in the realm of concurrency and parallelism, and instead encourages dangerous and buggy design. Data hiding, the basic premise of object orientation, when combined with sharing and mutation, becomes a recipe for data races. The idea of combining a mutex with the data it protects is nice but, unfortunately, locks don?t compose, and lock hiding makes deadlocks more likely and harder to debug. Y/N?
Last edited by Cuchulainn on June 30th, 2015, 10:00 pm, edited 1 time in total.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
Cuchulainn
Topic Author
Posts: 62626
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The One-liner Agree/Disagree Thread

July 4th, 2015, 5:40 pm

Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
ExSan
Posts: 4574
Joined: April 12th, 2003, 10:40 am

The One-liner Agree/Disagree Thread

July 4th, 2015, 6:04 pm

QuoteOriginally posted by: ppauperI agreedo you agree only because Cuchulainn agrees?
 
User avatar
Cuchulainn
Topic Author
Posts: 62626
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The One-liner Agree/Disagree Thread

July 13th, 2015, 8:44 am

QuoteLet Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.1. agree2. disagree3. agree + qualifications4. disagree + qualifications The quote implicitly assumes that specialization is a structural thing and not a behavioural thing. Q how to create a hierarchy of dangerous/risky animals?Good example?QuoteA typical example that violates LSP is a Square class that derives from a Rectangle class, assuming getter and setter methods exist for both width and height. The Square class always assumes that the width is equal with the height. If a Square object is used in a context where a Rectangle is expected, unexpected behavior may occur because the dimensions of a Square cannot (or rather should not) be modified independently. This problem cannot be easily fixed: if we can modify the setter methods in the Square class so that they preserve the Square invariant (i.e., keep the dimensions equal), then these methods will weaken (violate) the postconditions for the Rectangle setters, which state that dimensions can be modified independently. Violations of LSP, like this one, may or may not be a problem in practice, depending on the postconditions or invariants that are actually expected by the code that uses classes violating LSP. Mutability is a key issue here. If Square and Rectangle had only getter methods (i.e., they were immutable objects), then no violation of LSP could occur. IMO the above line-of-thought implicitly assumes that you must use ISA relationship. Based on this assumption, we have to find nasty workarounds.
Last edited by Cuchulainn on July 12th, 2015, 10:00 pm, edited 1 time in total.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
 
User avatar
Traden4Alpha
Posts: 23951
Joined: September 20th, 2002, 8:30 pm

The One-liner Agree/Disagree Thread

July 13th, 2015, 11:41 am

Two issues here: 1) The original statement is true with exceptions that are not germane to this discussion (i.e, if the provable property on Type T operates on or derives from the totality of T, then it may not be true for a subset of T)2) In the rectangle/square example, rectangles have been defined as things "that have independently settable width and height." Squares are not a subtype of that. Maybe the issue is that rectangle has not been properly defined in a way that admits the many subtypes of rectangles (e.g., squares, golden-ratio rectangles, unit-area rectangles, skinny rectangles (w<h), fat rectangles (h>w), etc.)
 
User avatar
Cuchulainn
Topic Author
Posts: 62626
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

The One-liner Agree/Disagree Thread

July 13th, 2015, 3:04 pm

QuoteOriginally posted by: outrunI think I agree, and this would imply that you shouldn't use subtypes to model dangerous animals, don't have rectangles and squares be subtypes.I would turn it into a subtype requirement (instread of definition). It would disallow the overloading of public base class member functions.Indeed! The Liskov Substitutability Principle (LSP) is the sacred cow of OOP. In a kind of a flash I realized it is based on data an not on behavior, so it is awful wrongSo, it is like:void func(Base& b);and any subtype Derive can use it if Derive implements virtual functions, as everyone knows.But:1. We mist derive from Base2. We probably just call a polymorphic function inside func()You cannot model dangerous animal with LSP because they have no structural commonality. Of course, most developers learn Animal -> Mammal -> {Dog, Cat} woof woof/miauw maiuwBut what we need is not classes but functionsThis idea:void func(InfllctInjury());So, indeed as you say make it a requirement. Then it can be satisfied by ants and an elephant (and aliens from Uranus).So, I agree OO hierarchies are not even wrong. (disclaimer; I knew it all along but LSP has now become a real eyesore).
Last edited by Cuchulainn on July 12th, 2015, 10:00 pm, edited 1 time in total.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl
ABOUT WILMOTT

PW by JB

Wilmott.com has been "Serving the Quantitative Finance Community" since 2001. Continued...


Twitter LinkedIn Instagram

JOBS BOARD

JOBS BOARD

Looking for a quant job, risk, algo trading,...? Browse jobs here...


GZIP: On