CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 33
  1. #16
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Location
    Florida
    Posts
    12,635

    Re: Moving from VC++ 6.0 to VC++.NET

    Quote Originally Posted by wavering View Post
    Understood but if there is an easier or better way then I will take that route ...
    You seem to be missing the point that you can build C++ apps without using .Net.

  2. #17
    Join Date
    Jul 2013
    Posts
    576

    Re: Moving from VC++ 6.0 to VC++.NET

    Quote Originally Posted by wavering View Post
    The central routine runs to well over a thousand lines of code and actually calls itself (up to about ten layers deep in practice) but with many "if" tests so it runs through about 20 million times per second using one core. I have 10 machines with 8 cores each so can use 80 cores where necessary. The central routine literally runs trillions of times (ie 10 ^ 12). The next step may be using FPGA and multicore hardware (I have a friend who is a hardware guy who tells me you can have up to 500 cores on a single chip but this is very early days for that) but that will be in maybe two or three years time.
    When you start optimizing I strongly suggest you analyze the core algorithm to establish what you're actually dealing with. The use of recursion indicates it's a combinatorial problem. When naively implemented they often suffer from the so called combinatorial explosion and become almost intractable. You must come down from exponential to polynominal complexity. It won't help to throw hardware at it.

    That may very vell be enought to take care of the performance problem. Of course you should utilize all cores but don't start there for that alone is unlikely to make much of a difference.

  3. #18
    Join Date
    Aug 2010
    Posts
    47

    Re: Moving from VC++ 6.0 to VC++.NET

    A supplementary question ("debugging a vc++ 6.0 dll called from a vb.net routine")

    At the moment, using the program written in vb6 which calls my dll written in vc++ 6.0, I can trace through the dll line by line by using Ctr F10 etc - perfect, no problem

    Before I move to vc++.net (yes, that seems to be the route) I had hoped that I could trace through the vc++ 6.0 dll when called from the debug version written in vb.net but it says ".exe does not contain debugging information" despite the fact that there is a pdb file generated by the vb.net compiler in the same folder as the exe file.

    So, is this possible? If so, what do I need to do?

    Thanks in anticipation
    MOPEKS - a freeware program that generates programs that use each other to solve problems. Is this the correct route to a genuinely intelligent machine?

  4. #19
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Moving from VC++ 6.0 to VC++.NET

    if you are going to convert your app to .NET, as in, using the .NET framework: then you will loose performance and gain UI integration benefits.

    C++ en C++.net/cli while similar, are essentially different languages.
    I'm not into VB, but i believe, VB has dropped support entirely for non .NET based apps. So if you're going VB, it's .NET or nothing.

    Your VC 6.00 code may need some changes to compile properly, there's been some changes to the language syntax, and a lot of old libraries have become obsolete. They're still there, but you'll get obsoletion warnings. Typically speaking, you want to clean those up.

    If your code currently runs as a single thread on a single cpu... Then while parallellizing may be a fantastic speed improvement, you won't be getting this for free. This is going to be a big undertaking, and depending on the problem, may not even be possible at all. It depends how your app works and what it does.
    It's close relation multithreading is typically easier to conceptualize but again, may not be feasible.

    Countrary to myth, multithreading, parallellizing and using the GPU code (cuda ?) are not about improving speed. On the countrary, the speed usually goes down because of the extra management and need to synchronize. It is however about getting more overall throughput. Some problem domains don't lend themselves to increased throughput.


    And repeating myself, going to (inline) asm doesn't really benefit you unless you can put a computationally significant amount of code in the single block of (inline) asm. If your asm is 1 or 2 instructions, then you'l get all the disadvantages and none of the advantages.

    the exception would be the handfull instructions the compiler doesn't use, but... Those tend to be the slow instructions (taking multiple clock cycles), that either don't allow running in parallel in the CPU pipeline or which stall the CPU pipeline. So those single 'complex' instructions tend to eat up the equivalent of a handfull of simpler instructions. So you're often still better off letting the compiler do the work for you.

    Like I said before, get your program to work first, worry about optimizing later (by profiling and optimizing the bit that matters).

  5. #20
    Join Date
    Jul 2013
    Posts
    576

    Re: Moving from VC++ 6.0 to VC++.NET

    Quote Originally Posted by wavering View Post
    Before I move to vc++.net (yes, that seems to be the route)
    Why don't you write it in MOPEKS instead?

    Just kidding but if it's MOPEKS we're dealing with here than it's most likely a combinatorial problem (I've suspected in my previous posts). In that case I strongly suggest you go back to the drawing board before you continue because you most certainly have an NP-hard problem on your hands. No amount of hardware and micro-optimizations will fix this. You need an algorithmic solution.

    I suggest you start over and work out a solution strategy to MOPEKS that is tractable before you continue. It's not enought to have something in principle. It's easy to say:- "generate all combinations and pick the best". This works in theory and in principle but not in practice. Not in multidimensional combinatorial search space. You must get down to polynominal complexity.

    Furthermore for a project like MOPEKS I don't think .NET is the optimal platform because it's not portable. I think you should seriously consider Java or a native C++ with Qt combination. It will work on many platforms including Windows too so why limit yourself to Windows only?

    So don't just port. First come up with a feasible solution and then make a proper new design based on your experience with the old program. Otherwise the project is doomed. Good luck.
    Last edited by razzle; August 5th, 2014 at 01:27 AM.

  6. #21
    Join Date
    Jul 2013
    Posts
    576

    Re: Moving from VC++ 6.0 to VC++.NET

    --- double post by mistake ---
    Last edited by razzle; August 5th, 2014 at 01:12 AM.

  7. #22
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Moving from VC++ 6.0 to VC++.NET

    Quote Originally Posted by razzle View Post
    In that case I strongly suggest you go back to the drawing board before you continue because you most certainly have an NP-hard problem on your hands. No amount of hardware and micro-optimizations will fix this. You need an algorithmic solution.
    Unless the problem is defined incorrectly, NP (hard) problems tend not to have algorithmic solutions (or rather "none have been foud yet").

    In that case, parallellizing is a feasible solution to try more possibilities in a given timeframe.

    Small scale, this could be a rack of CPU servers.
    Larger scale, this could be an elementary grid.
    Massively scaled up, it could be a global effort.

    There's a reason why we have such stuff like SETI@Home, Protein (un)folding and lots of other internet based efforts. It is by no means ideal, but it is a way to chop off a few digits in the total computation time needed.

    Many NP (hard) type problems find "adequate" solutions using genetic algoritms, or "ant colonies" or other similar. In that case, parallellizing/sharing the computation means you can try significantly more combinations and find better results within the same amount of time.

  8. #23
    Join Date
    Aug 2010
    Posts
    47

    Re: Moving from VC++ 6.0 to VC++.NET

    Quote Originally Posted by razzle View Post
    Why don't you write it in MOPEKS instead?
    In 20 years that may be possible! MOPEKS works by finding a program that fits the data so here is some data

    1, 1
    9, 3
    144, 12

    Clearly, this is square roots and here is the program that MOPEKS came up with this morning from that data
    Code:
    double _stdcall SquareRoots(double R){
      // Problem Description: '02    Square Roots'
      // Generated by MOPEKS at 9.35 am on Tuesday 5th August 2014
    
      // Initialise variables at zero
      double ax = 0;
      double bx = 0;
      double cx = 0;
      double dx = 0;
    
      //                                                  64 bits in Hex    1   2      3   4    5      6    7      8     9       10       11
      //                                                                 Type LHS   EPrp Opr RHS1  Prop1 RHS2  Prop2  Goto   Method    Steps
    
      Line1: ax = 3 - R;                           // &H9208B5C4187A8CBC    4   0      1   1    5     14    4      3     3       40       94  
      Line2: cx = R / ax;                          // &H18DBB330669188DB    0   2     27   3    4     25    0     12     4       24      109  
      Line3: ax = cx + ax;                         // &H1000080048200002    0   0      0   0    2      0    0      9     1        0        1  
      Line4: ax = ax / 2;                          // &H9009A0A7443D179E    4   0      1   3    0      5    7      8     1       81       79  
      Line5: if(cx < R / ax)goto line2;            // &H5937F1B01820D033    2   2      6   3    4     13    0      3     1       13       25  
    
      out: return ax;
    }
    It can then go on to build a whole stack of programs using each program it has generated so far until you get something like:

    Code:
    Private Function R_Orbts_S_AntCl(ByVal R As Long, ByVal S As Long)
    Dim ax As Double, bx As Double, cx As Double, dx As Double
    
    1:  ax = AnglSbtnddBy2Ob(S, R)
    2:  bx = 1 - 1
    3:  bx = ax + bx                    'bx is the relevant angle to use so far ...
    4:  cx = DistBtwn2Objcts(R, S)
    5:  cx = R.Speed / cx
    6:  cx = cx / 2
    7:  cx = ATan(cx)                   'cx is the angle correction (to allow for triangle)
    8:  bx = bx - cx                    'bx is the relevant angle to use!
    9:  dx = Return180()
    10: bx = bx + dx
    11: ax = Cos(bx)
    12: ax = R.Speed * ax
    13: ax = ax + R.XAxis
    14: ax ==> NextStep(R.XAxis)
    15: ax = Sin(bx)
    16: ax = R.Speed * ax
    17: ax = R.YAxis - ax
    18: ax ==> NextStep(R.YAxis)
    End Function
    I believe this is the correct route to artificial intelligence ... as a friend of mine remarked "if you are right, this is the most significant thing since the origin of life 4 billion years ago". So, no pressure

    Quote Originally Posted by razzle View Post
    Just kidding but if it's MOPEKS we're dealing with here than it's most likely a combinatorial problem
    Well, the programs evolve in a breeding pool and this is classic Genetic programming. Where I have extended it is the programs using each other and attach themselves to objects which interact in an environment - if you want to see more see the website. Bear in mind this is fully operational, you can download and install a fully working version for free - this is not about making money, it is about promoting an idea.

    Once I have got the .net versions working the next step is a camera trained on an interactive situation (eg a billiard table) and it will derive programs that have predictive power ie which ball will go where and the ideal angle etc

    Quote Originally Posted by razzle View Post
    Furthermore for a project like MOPEKS I don't think .NET is the optimal platform because it's not portable. I think you should seriously consider Java or a native C++ with Qt combination. It will work on many platforms including Windows too so why limit yourself to Windows only?
    A bit late now - this has got 35,000 lines of code written by me and has taken me almost 20 years so I am stuck with what I have!

    Quote Originally Posted by razzle View Post
    So don't just port. First come up with a feasible solution and then make a proper new design based on your experience with the old program. Otherwise the project is doomed. Good luck.
    Well, maybe if others think the basic principles have merit but if I am the sole person working on it that will not happen - I will die of old age first!
    MOPEKS - a freeware program that generates programs that use each other to solve problems. Is this the correct route to a genuinely intelligent machine?

  9. #24
    Join Date
    Jul 2013
    Posts
    576

    Re: Moving from VC++ 6.0 to VC++.NET

    Quote Originally Posted by OReubens View Post
    Unless the problem is defined incorrectly, NP (hard) problems tend not to have algorithmic solutions (or rather "none have been foud yet").
    That's not true. Also NP-hard problems have algorithms that solve them, just not in polynominal time (what hasn't been found yet is a formal proof of this).

    My point is that if the OP is trying to solve a problem in this category it's futile to just throw more and more hardware and micro-optimizations at it. This won't do. The problem must be approached at a more fundamental level. I called it algorithmic because the purpose is to find a solution based on a polynominal time algorithm. It could involve relaxing or reformulating the problem or seeking approximate solutions, etcetera, whatever it takes.
    Last edited by razzle; August 6th, 2014 at 03:36 AM.

  10. #25
    Join Date
    Jul 2013
    Posts
    576

    Re: Moving from VC++ 6.0 to VC++.NET

    Quote Originally Posted by wavering View Post
    I believe this is the correct route to artificial intelligence ... as a friend of mine remarked "if you are right, this is the most significant thing since the origin of life 4 billion years ago". So, no pressure
    Why not allign your ideas with other ongoing research in the same area. Check out this for example,

    http://www.cgchannel.com/2014/01/coo...on-for-bipeds/

    Before you continue putting more effort into this old program of yours I think you should step back and have a hard look at your approach. Maybe it's not that novel after all and maybe others even are ahead of you?

    I don't want to discourage you but you seem rather bogged down by the program. I know the feeling, it's like abandoning an old friend but sometimes it's better to unsentimentally let go and start anew. It may even allow you to finish sooner. Especially if you graduate from the procedural paradigm and start using object oriented and functional techniques part of modern languages. A program whose purpose it is to induce flexibility in the programming process should reflect at least some if this in its own design I think. It looks like the program itself is delaying the project. A redesign making use of modern design methods seems long overdue.

    So this is what I suggest you do at this point instead of just trucking on:

    1. Reality check. Allign your project with current research. How novel are your ideas? What have others done?
    2. Analyze core algorithm(s). Classify in terms of complexity and devise tractable solutions.
    3. Modernize. Bring the program up to todays standard using modern design and programming methods.

    Good luck!
    Last edited by razzle; August 7th, 2014 at 05:58 AM.

  11. #26
    Join Date
    Jan 2012
    Location
    India
    Posts
    193

    Red face Re: Moving from VC++ 6.0 to VC++.NET

    I have successfully ported my vc++ 6.0 assembly code to vc++ 2010 express and even to C# ..

    I had written a device driver in vc++ 6.0 .. as it supports assembly code ..

    for vc10 and C# , I made a DLL and imported it in my project .. It worked well

  12. #27
    Join Date
    Jan 2012
    Location
    India
    Posts
    193

    Re: Moving from VC++ 6.0 to VC++.NET

    In VC .net is more friendly to handle DataBase. VC6 although it has less graphics design in built facilities than vc10,
    it is easy to handle. Or may I am used to it. I am in systems programming and need many dialog boxes .. for which I prefer VC 6 .. Now I will have to port to C# or wpf .. but I may not love that ..

  13. #28
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: Moving from VC++ 6.0 to VC++.NET

    actually, what you're describing about mopeks (I didn't really make out what you intended it to do)
    sounds a lot like Eureqa of which a demonstration program was released in 2009 and usable versions for other scientists have been available for a few years. (even better, it's absolutely free).

    You feed it datapoints, and it finds the equation(s) that fit the data.

    It sounds similar to what your mopeks appears to want to do, but it's incredibly fast. It finds a solution for a double pendulum in a matter of hours. (this is several orders of magnitude more complex than a square root).

    It is a feat in itself to make a proper simulator for this, then think about reversing the output of the simulator back into it's input of pendulum lengths and mass and gravity.

  14. #29
    Join Date
    Jul 2013
    Posts
    576

    Re: Moving from VC++ 6.0 to VC++.NET

    Since it's now known that the OP's question is not about any program but specifically about MOPEK and because the OP is referring to this project in every one of his post, I feel it's okay to comment on this project.

    There is so much lacking in the MOPEK project. The most troublesome aspect is that there is no scientific basis for it. There is no theory, only "views" based of quotes from authority figures in science taken out of context.

    And the approach is also troublesome. There's no theory that can be tested up front, instead a program must be developed. This has been going on for 20 years already and is expected to go on for another 20 years still before any results can be expected.

    I think this is nuts and has become an obsession on part of the OP. Other research is ahead already as I've shown in previous posts.

    In saying this I agree with the OP who is anticipating a "negative reaction" to his project. (In fact it's the first time I fully agree with anyone at this forum.) Hopefully he reconsiders, but regardless, I wish him good luck in pursuit of his happiness.
    Last edited by razzle; August 8th, 2014 at 04:55 PM.

  15. #30
    Join Date
    Aug 2010
    Posts
    47

    Re: Moving from VC++ 6.0 to VC++.NET

    Quote Originally Posted by razzle View Post
    This has been going on for 20 years already and is expected to go on for another 20 years still before any results can be expected.
    Well, I didn't come here to argue about the merits or otherwise of Mopeks but after that comment I have little choice but to reply. What I am trying to do here is move a FULLY OPERATIONAL program from VB6 and VC++ 6.0 to .net

    My fundamental contention is that a program which generates programs is the correct route to AI but you are totally free to think I am deluded (and doubtless that is what you do think)

    As for no results for another 20 years, it ALREADY solves generalised problems concerning the interaction of objects. To spell it out

    "It is my contention that:

    The major use of simple human intelligence is the solving of problems whether they be of survival, finding a mate or just making a cup of coffee.

    These problems normally involve the interaction of objects in a particular environment - eg in making a cup of coffee the environment is the kitchen and the objects concerned are you, a kettle, cup, teaspoon, coffee, sugar, milk, etc. The 'problem' may be to make the cup of coffee with the minimum amount of movement.

    I believe a human being is a computing machine which can copy, learn or generate procedures which enable it to solve such problems. It is this ability which gives human beings their enormous degree of flexibility compared with animals - birds can build beautiful nests but would struggle to make a hat.

    Similarly, "normal" computer programs written by human beings can only cope with events which have been anticipated by the person who wrote the program - a bridge playing program cannot play poker. To this extent, they are like animals.

    The procedures which human beings copy, learn or generate, in turn use procedures which have been previously acquired. When you pick up a cup you are using dozens of procedures concerned with the estimation of angles, distances, gripping and co-ordination that you have learned previously.

    'Understanding' and 'comprehension' (I believe) come from having an internal simulator which can reproduce the actions of objects and can therefore be used to make predictions and also evaluate alternative strategies.

    Mopeks is built to imitate human intelligence insofar as it uses Genetic Programming to generate computer programs which can use each other to generate further computer programs in an endless upward progression of ever-increasing sophistication.

    At its most sophisticated, it enables an "intelligent" object to solve problems which involve actions of objects in a particular environment. For example, the problem may be to avoid being eaten on the plains of Africa. Or maybe plan a seating arrangement to minimise the extent of arguments between guests with strongly held but opposing views (eg Razzle and myself)

    It is a generalised problem solver and it is my belief that it is the correct route to real machine intelligence. "

    Incidentally, in terms of speed, it will often find functions in less than a second eg "Sum of Integers". Square roots maybe a few minutes. The problems that may take days are those of an object in an environment (eg Cassius tries to murder Caesar in an optimum manner or maybe Flash Gordon is using the gravitational effect to intercept an object in space). It will usually find a solution in an hour or so but the optimum solution may take days.

    I have now effectively removed my signature to avoid any offence ...
    Last edited by wavering; August 9th, 2014 at 06:34 AM.
    MOPEKS - a freeware program that generates programs that use each other to solve problems. Is this the correct route to a genuinely intelligent machine?

Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured