Serving the Quantitative Finance Community

 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

circle-ellipse inheritance problem

February 16th, 2016, 7:22 am

Here's a nice one. Anyone care to come up to the plate and give operations for?Option, CallOption, PutOption etc.?I wait :) Let's have a real discussion :)
Last edited by Cuchulainn on February 15th, 2016, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

circle-ellipse inheritance problem

February 16th, 2016, 7:44 am

QuoteOriginally posted by: outrunThe discussion about the OP problem was just as good. There has been lots of discussion why it was wrong. OO text book don't make it clear that you *don't* need to *specialize* a type when you want to implement different behavior for a special case.I agree 100%.In CS terms, it's class-based inheritance and you are talking about object-based/delegation inheritance (ECMAScrpt has it?)BTW any ideas on options;)
Last edited by Cuchulainn on February 15th, 2016, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

circle-ellipse inheritance problem

February 16th, 2016, 8:03 am

QuoteOriginally posted by: outrunThe discussion about the OP problem was just as good. There has been lots of discussion why it was wrong. OO text book don't make it clear that you *don't* need to *specialize* a type when you want to implement different behavior for a special case.more marketing
 
User avatar
Traden4Alpha
Posts: 3300
Joined: September 20th, 2002, 8:30 pm

circle-ellipse inheritance problem

February 16th, 2016, 12:18 pm

QuoteOriginally posted by: CuchulainnBTW any ideas on options;)What is the purpose of Option, CallOption, PutOption?I can imagine at least four very different data structure & behavior sets that might all be called "Option":1. Option pricer2. Option data storage (i.e., data + code for managing historical data on options)3. Option composition objects (i.e., a data structure & methods useful for constructing straddles, condors, etc.)4. Option contract model (i.e., text data structures and configuration code in which instances define complete and consistent bespoke/OTC contracts)No doubt, there are others.
 
User avatar
Traden4Alpha
Posts: 3300
Joined: September 20th, 2002, 8:30 pm

circle-ellipse inheritance problem

February 16th, 2016, 1:22 pm

BTW:1. Circles have well defined states and behaviors for radius and diameter, Ellipses do not.2. Ellipses are not flattened circles when it comes to approximating the object with a set of OpenGL line segments or triangles.Perhaps one of the biggest problems with the OOP approach is that it's easy to think X IS-A Y during the initial phases of design only to discover later that X IS-NOT-A Y due to some more subtle property, corner case, or secondary requirement. Maybe OOP should be avoided until version 2.0 when the domain is sufficiently well understood for creating a valid class hierarchy.
 
User avatar
Traden4Alpha
Posts: 3300
Joined: September 20th, 2002, 8:30 pm

circle-ellipse inheritance problem

February 16th, 2016, 3:09 pm

QuoteOriginally posted by: outrunQuoteOriginally posted by: Traden4AlphaBTW:1. Circles have well defined states and behaviors for radius and diameter, Ellipses do not.2. Ellipses are not flattened circles when it comes to approximating the object with a set of OpenGL line segments or triangles.Perhaps one of the biggest problems with the OOP approach is that it's easy to think X IS-A Y during the initial phases of design only to discover later that X IS-NOT-A Y due to some more subtle property, corner case, or secondary requirement. Maybe OOP should be avoided until version 2.0 when the domain is sufficiently well understood for creating a valid class hierarchy.Yes, it's taught that way, every educational OO book starts with some real-world object (like a DVD player) and then start modelling it with objects. OO is however not about real-world objects, it's a set of programming language tools, just like the tools in your regular toolbox (quantum correlator, geiger counter, superconducting magnetic plasma stabelizer etc) . I won't go and try to capture the real world relations and proxy those in code because that's most of the times that's not what the task is. You much better of decomposing a problem into algorithms and datastructures (the core business of computers: compute and proccess data) that are centered around objectives and requirements. A circle would probably better be named (or even better tagged) a "rotationInvariantObject" because that directly maps in a relevant way to operations that need to be performed on it.Exactly! It's a tool that may be good/bad, cost efficient/inefficient, orfragile/robust depending of the top-level requirements and context.One issue is that very large systems inevitably end up turning into a set of parallel development projects which then seems to require decomposition of the system into things and encapsulation of the data and code for each of those things. That, by itself, doesn't make OOP the right approach.But then comes the realization that sometimes two or more things have similar data structures and similar algorithms although perhaps the numbers of things and complexity of those things is too large for one person or team to write all the code for all the things. Those numerous and complex things might be physical objects (e.g., the data and code needed to work with each of a large number of different models of webcam) or logical things (e.g., the data and code needed to work with a different statistical distributions). Moreover, in the context of development, it's nice to create some baseline generic code that provides some functionality for some of the things for early alpha versions of the system with some efficient way of extending/specializing the data and code to cover more of the things (i.e., inheritance).One issue with the circle-ellipse example is that it is too simple to benefit from full blown OOP. It seems like more hassle than it's worth.(BTW a circle is not rotationally invariant in 3 or more dimensions.)
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

circle-ellipse inheritance problem

February 16th, 2016, 3:39 pm

Quote Maybe OOP should be avoided until version 2.0 when the domain is sufficiently well understood for creating a valid class hierarchy.As I said, inheritance is optimization. But C++ developers use it to simulate interfaces (wrongly).BTW it might be good if you define OOP. Do you agree OOP = Classes + objects + Encapsulation + InheritanceObject-based == OOP - Inheritance.//There is a C++ blind spot here .. it does not support interfaces. So we have this C++ legacy problem and people have to use abstract base classes.
Last edited by Cuchulainn on February 15th, 2016, 11:00 pm, edited 1 time in total.
 
User avatar
Cuchulainn
Posts: 20254
Joined: July 16th, 2004, 7:38 am
Location: 20, 000

circle-ellipse inheritance problem

February 16th, 2016, 3:54 pm

QuoteEllipses are not flattened circles when it comes to approximating the object with a set of OpenGL line segments or triangles.They are never flattened circles in any context!But an ellipse can be transformed to a circle, do things in circle space and then transform back to ellipse space in 2d CAD.Here's how we did it in optics. It's very clever. In s/w, we say Ellipse is an acquaintance class of Circle.
Last edited by Cuchulainn on February 15th, 2016, 11:00 pm, edited 1 time in total.
 
User avatar
Traden4Alpha
Posts: 3300
Joined: September 20th, 2002, 8:30 pm

circle-ellipse inheritance problem

February 16th, 2016, 4:04 pm

QuoteOriginally posted by: CuchulainnQuote Maybe OOP should be avoided until version 2.0 when the domain is sufficiently well understood for creating a valid class hierarchy.As I said, inheritance is optimization. But C++ developers use it to simulate interfaces (wrongly).BTW it might be good if you define OOP. Do you agree OOP = Classes + objects + Encapsulation + InheritanceObject-based == OOP - Inheritance.//There is a C++ blind spot here .. it does not support interfaces. So we have this C++ legacy problem and people have to use abstract base classes.Those definitions seem workable although some would also add message passing to the mix.Whether C++ implements one definition of OOP or another or just something that is OOP-like seems like more of a discussion for purists.