Hi Curt, Tim, On Friday 12 June 2009 20:10:17 Curtis Olson wrote: > I have one concern that I may not have voiced clearly before. Well, I believe that I have to contribute here :)
> I tend to think about these design choices in terms of what is often called > "orthogonality". The idea stems from the world of vectors. > > The idea of orthogonality is if you want to represent any point in 3d > space, you can do it by some combination of x, y, z components. The x, y, > and z axes are arranged orthogonal or at right angles to each other. Each > axis is completely independent from the other axes. You could imagine some > other space where the axis go in odd skewed directions that aren't at right > angles to each other, and you could still represent point locations, but > the numbers would be odd and hard to deal with, hard to add and subtract > and manipulate. So an orthogonal (at right angles, or said another way, > completely independent) components are an ideal way to represent a point in > 3d space. > > So if you translate that concept over to computer languages, or computer > API's, I believe strongly that these things also work best when they are > "orthogonal". In other words, we want a minimal set of independent > components we can use to specify or accomplish what we want. This makes > for clear and understandable and maintainable code. I totally agree here! BTW, what I try to do in some cleanup stuff currently is to regain that kind of orthogonality in the implementation where we have already too much mixed up. > Going back to the 3d point example. If we start adding components like a > curving axis in some random direction, or points that are only valid on the > 2nd tuesday of every month, you wind up with a huge mess of special cases. > You lose the ability to perform simple functions (like + or -) on > individual components. Basic principles like 0 * x = 0 and 1 * x = x may > no longer be true. And if you have points that are only valid on the 2nd > tuesday of every month, it probably doesn't make sense to define a special > data type for that with mixed interdependent components, instead it makes > sense to think about what independent components we can use to build what > we want. > > So as you speak of adding Vec3 and Vec4 types to the property system, I > immediately have orthogonality concerns. We seems to be adding a > specialized core type that is only good for one purpose along with the > specialize code to handle just that particular type, and we are moving > against the concept of orthogonality (which I feel is highly important when > designing api's, computer languages, vector spaces, etc.) This is where I start to disagree! Vectors are such an abstract thing that I have no orthogonality concerns at all. So a vector is just a tuple of n scalars that can be added and scalar multiplied. That is so far the mathematical definition. So introducing such an abstract type is nothing more special than introducing an other abstract type like a double for example. For the property system the data type could be reduced to a tuple of n scalar values. You do not need to know something about the arithmetics from the property system. Curt, I am not voting for your example of 'Tims-best-datatype' stuff of things to the properties, but given he wants to add tuples of scalars so often called vectors, that is a concept that is almost as general like a floating point value, I have to say that I would love to have that ... > Now, just to show you how fair I am, there is another side to this > discussion that is also just as important to consider. > > Languages and API's often develop idioms and short cuts for things that are > heavily used. It makes life more complex in the sense that now you have to > learn the idioms that don't necessarily have any obvious literal meaning, > but once you learn the short cuts, you have a much more efficient way to do > something or express some particular idea. That can be very useful and > very practical for things you might do quite often. > > So as I see it, the debate breaks down to practicality versus > orthogonality. Do we permit some idioms to develop for commonly used > operations or commonly used structures? That doesn't have to be a bad > thing in my view. But orthogonality is a really good thing, so we should > strive to maximize orthogonality and minimize idioms (to mix langauge and > math terminology in the same sentence.) We need to set a pretty high > threshold before allowing new idioms to be added, and especially when > adding the first idiom to a purely orthogonal system. > > Speaking figuratively, what it looks like to me is that we will be adding > two more axes to our beloved X, Y, Z (figurative) system. The Tim1 axis > and the Tim2 axis ... both point directly to your two specific points in > space. That may be ok from a notational stand point, but I can understand > the resistance to poluting the well loved and well understood traditional > X, Y, Z space just because one person is solving a problem that involves a > bunch of points that line up on some other arbitrary axis. > > This might come as a very late suggestion, but would it be able to derive a > new class using SGPropertyNode as the base (maybe call it > SGPropertyNodeExt) and then add your new types to the derived class? I > supose then you wouldn't be able to use the same xml reader/writer code. Hmm, I have thought several times in redoing the property implementation in a more 'orthogonal' way. That would allow for such extensions in a natural way. Also from what I currently work on the HLA component seperation, a more flexible property system might allow me to greatly reduce the communication load on the HLA server. Also I believe that we can make that property system a little faster and more clear in its semantics I guess. We already have several too special cases there which I hope to clean up. > I'm very conflicted on this one. It is messy. So far I haven't seen a > slam dunk argument either way. We are trying to balance convenience and > ease of use against well conceived design. Typically we try to build more > complex structures out of simpler base structures. But this is a case > where the interdependencies of our property system, xml reader/writer code, > and opengl/osg seem to force a cascading sequence where one change implies > another which implies another and we are right back to specific vec3 and > vec4 types and it's really hard to create an optimized and convenient > system that is more generalized and maintains pure principles of > orthogonality. May be I should look closer at Tims actual implementation! But having a vector in the property system will not introduce OpenGL nor osg dependencies. At least my understanding of this is to use SGVec* for that. osg and OpenGL should not show up in the property system. But a generic vector can show up. What strikes me with the property system is the lack of composed datatypes that in some cases need to set in an atomic way. The scalar world of the current property system where we have scalar accessors for the components of a composed datatype, we have several partial updates that will leave the object that is accessed by the property system in an partially updated state until the last update happened. Having compound atomic types like a vector for example solves that problem. Tim, what I am also concerned about is the use of property listeners to work on osg's datastructures. I believe we should not intermix code paths that can happen during the application/update phase with the osg scenegraph structures. Think of the multithreaded viewer we are talking about with Curt. I would prefer to separate these steps in a way that we could also streamline the data flow somehow. With these listeners we change things in the viewer directly from the application step I guess. I believe that we better think of such a simulation as a pipeline that starts with the users inputs (joystick and such) the data is put into the simulation (FDM, instrument simulations, etc ...) the data is then put into the viewer's scengraph, which itself is used to render things that appear on the screen. Separating these steps with clear points in this pipeline where data is moved from one stage to the next would provide the ability to do these steps mostly in parallel (even more, we could do independent simulation entities in parallel). But fiddling with listeners here can make the first pipeline steps modify the data of the last pipeline step - which adds the need for either locks or if we do not lock, we stick even tighter to an application step that cannot run in parallel to the viewer stages. Greetings Mathias ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
