From: mailbox@dmitry-kazakov.de   
      
   On Fri, 19 Jan 2007 15:40:44 +0100, Seweryn Habdank-Wojewódzki wrote:   
      
   > Dmitry A. Kazakov wrote:   
   >   
   >> This rule is correct for C++, but it need not to be so in general.   
   >> Dynamically polymorphic objects should cause no overhead compared to   
   >> statically polymorphic ones. C++ has an OO-design fault, which forces   
   >> re-dispatch.   
   >   
   > I do not know what you mean by saying "OO-design fault, which forces   
   > re-dispatch", but e.g. both Ada and C++ have similar object model,   
      
   There is an essential difference. In Ada class T and T are two different   
   types. Not to distinguish them was the design fault of countless OO   
   languages. And the punishment was very hard. Loosing performance is only   
   one of numerous consequences.   
      
   > but e.g. Ada has no "template specialisations".   
      
   Yes. But in my view there should be no templates at all. Templates are   
   macros, they arose in the times when people didn't know how to achieve   
   polymorphism in a sane and efficient way.   
      
   >> In short, without going into much details, it is quite obvious. Consider,   
   >> if the type is statically known, and this is the only case where static   
   >> polymorphism can work, then there is no any need to dispatch.   
   >   
   > Not quite. Consider Java design. All objects are derived from JObject.   
   > This is full dynamical polymorphism. And full static polymorphism is when   
   > you set that you have e.g. CClass and function is working on this type.   
      
   Both cases are same. If you have a polymorphic subprogram then as any   
   subprogram in a typed language it works on exactly one type of objects. The   
   trick is that these objects are polymorphic. Once this gets fixed the rest   
   is easy.   
      
   > But in the middle is a situation that you can define a base class quite   
   > close to the region of your interest and you can specialize templete   
   > function to work on the pointer on this class. This will lead to two   
   > things, from one side you can prepare dedicated generally staticall   
   > constructed code for your case, but your case will be not very strict,   
   > because you will work on the pointer to the base class. As example you can   
   > observe how easy is a construction functors that can switch internal   
   > working function. You can parametrise templete class with a functor that   
   > contains a state or whatever, but the functor can have a pointer to the   
   > other raw function this function you cat change in runtime. It means that   
   > partially you can fix system e.g. to work on std::strings, but e.g. logical   
   > operations on the fuzzy properties you can change. However in my experience   
   > with statically created functionals there are many possibilities that you   
   > can design and place in the code statically constructed object and use it   
   > later. E.g. I have developer Kohonen Neural Network library, and fully   
   > equipped training functor has size of 78 bytes. The shape is fixed,   
   > parameters you can change. And the question is hom meny combinations of   
   > such a trainnig functionals you can use in the runtime, 10, 100, 1000. Even   
   > 1000 it is only 78 000 Bytes - who cares about 78 000 Bytes? The same in   
   > Fuzzy Logic. Consider most part of logical operations there are about 10-20   
   > kinds of AND operator 10-20 OR. less than 10 NOT operations, so even if you   
   > need to construct inference system using all of them you can multiply   
   > 20x20x10 = 4 000, so there are possible about 4000 combination of all sets   
   > of fuzzy logical functors.It is quite small amount. So in my opinion better   
   > is to focus hot to prepare good design of the system where objects are very   
   > small and flexible, rather then prepares huge heavy and full od dynamical   
   > polymorphism objects.   
      
   The problem is not in AND and OR, I am using only min and max, for that   
   matter. (Other connectives are inconsistent without additional   
   assumptions.) The problem is the domain sets of the fuzzy subsets involved.   
   If you make it parametric types, then you will get different independent   
   and incompatible types of fuzzy sets. If you have different types then you   
   cannot have one program that handles them all at run-time. Even if you pass   
   some ugly closure functions down to. The point is that fuzzy sets need to   
   be of different *subtypes* rather than types.   
      
   But what you describe is actually a manually implemented dynamic   
   polymorphism!.. (:-)) I remotely remember a discussion in comp.object about   
   whether it were possible to mimic C++ classes using templates. This is what   
   you are doing.   
      
   >> The compiler   
   >> can find the target already at compile-time, without looking into the   
   >> dispatch table at run-time. It is a trivial optimization, which is   
   >> unfortunately impossible in C++ (for many reasons).   
   >   
   > So if you just define that all functors are derived from basic_functor   
   > object then you can change pointer in the runtime, but the structure of the   
   > functor is compiled in, withot any creation, you just switch the pointer -   
   > it is really fast.   
      
   This is exactly what dispatching is = switching pointers. You propose to do   
   it manually. I prefer the compiler to handle it for me. But what I mean was   
   more, in static cases you wouldn't need any pointers at all, if the OO   
   model were right. The target would be resolved statically, no any overhead.   
      
   > There is no allocations, no destroying in the time of   
   > work, just at the beginning of the program and at exit.   
      
   I am not sure what you mean, but it looks like C++ problematic. In Ada one   
   can return polymorphic objects on the stack.   
      
   >> It is any, but the system works with only nominal representations.   
   >> Continuity is left after fuzzification and merged with it. So it is:   
   >   
   > I have to look on your design and implementation, to understand more of your   
   > backgrounds and features request :-).   
      
   Features are not there. They are in a machine learning system which is   
   presently under developing.   
      
   >> When some   
   >> temperature value, say 2°C (or again an almost linear function of °C)   
   >> comes in, the feature translates (fuzzifies) it into an IFS over {cold,   
   >> tepid, warm}. After this point any continuity and infinity is killed and   
   >> buried.   
   >   
   > Why? I think if you will construct functionals then all time you can have   
   > continuous variables. Like a composition od operators.   
      
   There are too many operations which cannot be analytically expressed in   
   AND, OR, NOT. OK, formally they can, but technically when dealing with   
   uncountable sets, that would be incomputable.   
      
   > E.g. in C++ you can   
   > do like that you have a functor which is paramtrized by the container of   
   > logical operators and paramtrized by fuzzy sets, then it combines sets with   
   > operators and this leads to construction of the predecessor of the fuzzy   
   > rule consequent of the fuzzy rule can be other typically it is similar to   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)