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

I have, what to me, looks like a large project. Originally written about 90% in VB6 and the remainder in VC++ (Visual C++ 6.0 Enterprise Edition). There are maybe 2,000 lines of code written in VC++ which constitute a DLL with about 80 functions (81 to be precise)

There are two reasons I have used VC++. The first is that speed is of the essence - the program may literally run for weeks finding solutions and the speed of the central loop is crucial. From experience it seems like the routines in VC++ run about three times quicker than the equivalent written in VB6

Secondly, I have written a lot of bit handing routines using inline ASM.

I have spent several months converting the VB6 stuff into vb.net (which run at about half the speed of VB6) and am now looking at the VC++ stuff

Some questions:

1. Is VC++.net going to run at the same speed as vb.net as I understand they both translate into an Intermediate language? If so, it will be a LOT slower than VC++ 6.0?

2. Can I use inline ASM in VC+.net?

3. Can I view (somehow) the disassembled code as I can in VC++? This is very handy when you are trying to optimise speed

4. What version of VC++.net should I use (I am currently using VB 2010 but am happy to spend money and upgrade if necessary)

5. Any general observations from people who have already experienced this transition will be very much appreciated

Many thanks!

Quote:

---

Originally Posted by wavering

1. Is VC++.net going to run at the same speed as vb.net as I understand they both translate into an Intermediate language? If so, it will be a LOT slower than VC++ 6.0?

---

Let's clear up some misconceptions. Understand that the versions of Visual Studio since VC/VB 6 still offer native VC++ coding - and they offer VC++.Net (which is managed).

In other words, you can still create non-managed native C++ applications in Visual Studio.

If you don't mind upgrading, I'd suggest upgrading to VS2013 before starting your porting project. VS2013 C++ supports C++11 features that 2010 does not. Why start with a 4 year old compiler?

Quote:

---

Originally Posted by wavering

Secondly, I have written a lot of bit handing routines using inline ASM.

---

probably not needed, potentially this is going to slow down your app rather than speed it up.

if as functions, you're forcing calls, and restricting the compiler to manage registers on it's own best interest.
if as inline functions, may still incur a call, still restricts the compiler to manage registers
if as inline defined asm, still restricts the compiler to manage registers

Except for a few 'oddball' bit routines (such the the rotates), the compiler optimizer will probably do most of your 'bit handling' in c++ better than your asm.

Quote:

---

2. Can I use inline ASM in VC+.net?

---

no for .net (managed) code, you can write an unmanaged section, but in this case the change from managed/unmanaged is going to ruin any kind of speedup you hoped to achieve.
for unmanaged code: yes

I'm not sure if the express edition supports inline asm.

Quote:

---

3. Can I view (somehow) the disassembled code as I can in VC++? This is very handy when you are trying to optimise speed

---

1) you can create an asm listing.
2) don't try to bother. If you want to do better than the compiler, you need to think about different algorithms/strategies to solve the problem rather than trying to micro.

Quote:

---

5. Any general observations from people who have already experienced this transition will be very much appreciated

---

start by getting your program to WORK first.
worry about optimizing after, rather than starting by what you think needs to be optimized.

profile your app and optimize only where it matters.
if you make the bit of code that takes 1second of time in the entire duration of your app 100% faster, you'll have made your entire program 1 second faster, that's not a good investment of time.
if you make the routine that is executed 1 million times 0.001 second faster, you'll have made your program take 1000s faster.

Quote:

---

Originally Posted by wavering

The first is that speed is of the essence - the program may literally run for weeks finding solutions and the speed of the central loop is crucial.

---

Or rather the central algorithm is crucial. Why not take this opportunity to have a hard look at it?

Maybe it can be replaced altogether with a more efficient alternative. Or maybe it can be improved for example by replacing the innermost loop with a table lookup. Or maybe it can be parallelized at the CPU level or by making use of the massive parallelism offered by todays GPUs.

First lower the algorithmic complexity to a minumum and only then start fiddling with micro-optimizations.

Firstly, many thanks for the detailed replies - very much appreciated. Just to clarify a few points ...

Development: The project is already up and working (MOPEKS - see signature below) so I am trying to do a straight transfer to vb.net and vc++.net. There is no element of development or optimisation at this stage but there will be later ...

ASM: I am using it for complex bit manipulation, not for speed. It may be possible to do this in C++ but I would not know where to start and the great advantage of ASM is that you are right inside the engine and it is very easy to check exactly what is happening line by line

Disassembled code: I want to view this not to try and outdo the compiler but so that in certain cases I can see what is really happening - what I am doing is hideously complicated (to me anyway - MOPEKS generates computer programs and provides an environment in which they run and call each other - my output is not data but computer programs) and I need all the help I can get making it work during transfer to .net and later during development in years to come.

Speed: Obviously, I have given huge thought to this given that it may take weeks to find a solution on occasion. 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.

Complexity: Having been built over a 25 year period I am close to losing control of the code so I need to transfer to vc++.net as simply as possible. Is the transfer going to be difficult - are there any fundamental changes in the way vc++.net works? Although the logic is hideously complicated the code itself is really just simple C and C++. It does not really call any C or C++ functions as such. Sample below of the recursive part ...

Code:

---

// This is the part where it calls itsefl
intLevelGL++;
dblTotalMethodsRunGL++;
dblReturn = ScorerKernel(dblObjectArray,
                        dblEnvPropValues,
                        intEnvPropNumber,
                        intMethodArray,
                        intMethodLines,
                        intMethodNumberCalled,
                        intMethodClass,
                        0,
                        intMethodClassSignal,
                        dblR1,
                        dblR2,
                        dblAnswer,
                        intTrialNo,
                        intStep);


// Stop if duff
intLevelGL--;
if(dblReturn != 0){
  dblErrorNumber = dblReturn;
  goto notgood;
}

result:;
// Put the answer into the LHS (UNLESS it is NextStep)
if(usiMethodCalledHash != 2732976079){
  dblStorit[intInstruction2] = dblAnswer[0][0];
}
intLine++;
}  // end of "if(intInstructionType == 7)"

//                                                  Calling a Method ENDS here

endofloop:; 
intLinesRunPerScorerKernelVisit++;
intLinesRunTotalGL++;
        if(intLevelGL == 1)intTopLevelLinesRunGL++;

// Check NOT run too long
if(intLinesRunPerScorerKernelVisit > LRM_PER_SK_VISIT){
          {dblErrorNumber = 160; goto notgood;}
}
if( (intMethodClassSignal != 34 ) && (intLinesRunTotalGL > LRM_PER_TRIALS) ){
          {dblErrorNumber = 161; goto notgood;}
}
if( (intMethodClassSignal == 34 ) && (intLinesRunTotalGL > LRM_PER_SIMULATION) ){
          {dblErrorNumber = 162; goto notgood;}
}

---

So, how hard is this going to be?!

Why .Net? Wouldn't regular C++ work for you?

Quote:

---

Originally Posted by GCDEF

Why .Net? Wouldn't regular C++ work for you?

---

Yes, it would but I assume that VC++ 6.0 will be dropped in due course. I am using Win XP but assume that I cannot use VC++ 6.0 on Win 8 etc. What do you suggest?I used to use Quick C last century ...

Suggestion(s) welcomed - I need to build a DLL so any GUI and Compiler that can do that would be perfect ...
.

It seems you don't get it. Despite the fact that VS name includes .NET part, you are still allowed to create pure native C++ projects. Or just make use of convertion from VC 6.0 C++ project to the latest format.

Unlike the situation with VB6.0, pure old C++ is not banned in contemporary VS versions.

Quote:

---

Originally Posted by Igor Vartanov

It seems you don't get it. Despite the fact that VS name includes .NET part, you are still allowed to create pure native C++ projects. Or just make use of convertion from VC 6.0 C++ project to the latest format.

Unlike the situation with VB6.0, pure old C++ is not banned in contemporary VS versions.

---

Understood but if there is an easier or better way then I will take that route ...

I hardly could say anything except maybe pretty obvious things like "you should go with the language you are comfortable the most with", or "language hardly could help in a case when it's more about algorithms", or "you should stay away from ASM as much as possible in case chances are for your SW to run on more than one HW platform", etc.

What I am asking right now is whether there is a good alternative to vc++.net (with emphasis on the IDE aspect with ease of use and versatility being the criteria) that I should consider. For example, a quick search comes up with the following that are useable under Win 8

1. Turbo C++ 3.0 from Borland

2. Intel® C and C++ Compilers

3. codeblocks

4. C-Free - C++ Compiler for windows 7 , 8 .

5. CodeLite

6. Digital Mars

7. MinGW

And now doubt many others - so now I really am confused as to the best way forward. Cost is not a major factor - I just want the best and easiest to use ...

Edit:
Since writing the above I have found this definitive article but people's experiences here would be very useful

http://en.wikipedia.org/wiki/Compari...t_environments

Thanks ..

Quote:

---

Originally Posted by wavering

2. Can I use inline ASM in VC+.net?

3. Can I view (somehow) the disassembled code as I can in VC++? This is very handy when you are trying to optimise speed

---

2. Yes, in native C++, but not in x64 build. You can, however, compile Assembly modules and link them with C++ modules. As mentioned before, it is much better to write this stuff in C++.

3, Yes, by printing Assembly listing, and during debugging, in Disassembly window.

Regarding your last post - most options are not C++ compilers, but IDE or frameworks. Talking about compilers, serious candidates are VC++ (of course, latest version available), g++ (part of MinGW package) and Intel C++ compiler. VC++ looks like an optimal choice. If performance is really critical, all Intel software products are known by very good performance and optimization.

Quote:

---

Originally Posted by Alex F

VC++ looks like an optimal choice

---

Yes, looks like I will probably stick with Microsoft!

Two questions:

1. Do you know if there is a version that offers conversion from VC++ 6.0? I ask this because in vb.net the 2008 Express offers a conversion facility but the 2010 Express does not. Or can I just open it and it will sort of work ie are there major changes like there are from vb6 to vb.net (that conversion has taken me 6 months so far)?

2. It appears that the latest free version is 2013 - is that correct?

Once I am happy I will buy the latest full version as I believe that will enable me to use extensions (particularly MZ Tools in vb.net)

Thanks Alex - or others who may answer

Quote:

---

Originally Posted by wavering

What I am asking right now is whether there is a good alternative to vc++.net (with emphasis on the IDE aspect with ease of use and versatility being the criteria) that I should consider. For example, a quick search comes up with the following that are useable under Win 8
...
Cost is not a major factor - I just want the best and easiest to use ...

---

As for me, VS is the most attractive IDE for Windows. I really love it's debugger, though Whole Tomatoe's add-in is still a recommendation for improving its editor. Express edition, which is free, but equipped with the contemporary compiler, would be fine for your needs, as Pro version is required only in case you use MS libraries like MFC or ATL, or need an integrated resource editor.

As for ease of use and versatility, I would say these are too vague criteria to ask for recommendations from people you never know. Again, according to what I got from your post, your main problem is algorithm's complexity, where IDE hardly could be of any help.

As for compiler's quality, VC++ is really good, and its only competitors are Intel and g++.

Quote:

---

Originally Posted by wavering

1. Do you know if there is a version that offers conversion from VC++ 6.0? I ask this because in vb.net the 2008 Express offers a conversion facility but the 2010 Express does not. Or can I just open it and it will sort of work ie are there major changes like there are from vb6 to vb.net (that conversion has taken me 6 months so far)?

2. It appears that the latest free version is 2013 - is that correct?

---

1. Unlike VB6 - VB .NET, C++ remains the same language. Conversion is pretty straightforward - open old VC++ project in new Visual Studio, fix all compilation, build and runtime errors. I don't know any conversion tool, I think it doesn't exist. There is only project conversion wizard, which is executed automatically when old project file is opened. It doesn't change anything in source code.

2. Yes.

Quote:

---

Originally Posted by wavering

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.

Quote:

---

Originally Posted by wavering

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.

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

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).

Quote:

---

Originally Posted by wavering

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.

--- double post by mistake ---

Quote:

---

Originally Posted by razzle

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.

Quote:

---

Originally Posted by razzle

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

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

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

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!

Quote:

---

Originally Posted by OReubens

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.

Quote:

---

Originally Posted by wavering

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! :)

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

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 ..

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.

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.

Quote:

---

Originally Posted by razzle

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 ...

Quote:

---

Originally Posted by wavering

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

---

You did mention performance in your original post and I consider it a more important problem than the rather trivial porting issue. And obviously you referred to Mopeks in order to draw attention to this project. There's nothing offensive about that.

http://www.mopeks.org/

You state human higher intelligence is about playing out different scenarios in the mind and then pick the best. Certainly, but there is nothing novel about that and when you decide to simulate it with a genetic algorithm it becomes just an ordinary evolutionary approach (despite your attempts to dress it up in a metaphysical garment).

There's lots of research going on in this area. If you missed my link please have a look,

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

Watch how the creatures first evolve to walk and then learn to run and to avoid objects thrown at them.

I didn't say the 20 years you've spent on this have been wasted. You've obviously learned a lot and have a working program. What I'm saying is that your image of yourself as the leader of a paradigm shift is not grounded in reality. Your project shows a resemblance with alchemy and the search for the philosopher's stone. I've seen it before. People hope that by molding a program long enough it will magically transmute into an elixir of life, in your case show human intelligence. I strongly recommend that instead of just tugging on for another 20 years you consolidate this project in real science and devise a more realistic strategy for the future (see my previous post).

Good luck.

Razzle
The project you highlight looks to me like a perfectly straightforward Genetic Programming project - a computer program evolves over time. That is old hat and the principle has been around for decades. I was writing such programs in the previous century. The first were written in about 1948 eg "Core Wars", in which evolving programs fight each other for supremacy in RAM, or core as it was called in those days

What mopeks does which I believe is original is to use GP to produce a Library of general purpose programs which use each other. So, if an object in mopeks wants to know the distance to another object is evolves a suitable program which will doubtless use the Square Root program it found earlier. And so on.

I believe this is how human intelligence operates - to solve a problem we use a whole raft of procedures which we have previously learned or generated to create a new procedure. So, you start with virtually nothing as a baby and build up a vast library which is stored in memory.

In mopeks, this evolved library can then be used by any arbitrary object in any environment. So the objects could be:

Razzle, wavering, Observer1, Observer2, Observer3 etc

The environment could be:

CodeGuruBoard

The objective could be to send the audience to sleep as soon as possible

Each object can have totally arbitrary properties eg

IQ, experience, grumpiness, persistence and so on

All of the objects interact in the simulator and an optimum approach is produced. There is no computer programming involved - the evolved programs run within mopeks itself. This is clunky and time consuming right now but so were the early planes - no passengers and a range of a few hundred yards.

Here is Flash Gordon homing in on his objective using the gravity slingshot effect:

http://www.mopeks.org/images/form_di...l_animated.gif

Yes, pretty trivial but bear in mind that this uses a whole library of routines generated by mopeks and is totally general purpose. So, in principle, MOPEKS can be used to solve ANY problem which involves the interaction of totally arbitrary objects, with totally arbitrary properties in a totally arbitrary environment.

I am not aware of anybody releasing a fully operational program to do that. And its free ...

Quote:

---

Originally Posted by wavering

So, in principle, MOPEKS can be used to solve ANY problem which involves the interaction of totally arbitrary objects, with totally arbitrary properties in a totally arbitrary environment.

---

You may be inspired by human intelligence but your approach to problem solving is based on the principle of emergence with evolution as the direction force. That's completely general as you say. It's also why GA is a suitable computational strategy for your project.

The big challenge is to devise a parametrization of the participating objects which allows GA to be efficiently applied (compare the moving biped project I linked to). And to develop a theory for this, that is applying science as opposed to just tinkering with a program.

Mopeks should be pretty small and simple. If it's big and complex (as you indicated) you probably are hardwiring problem solving capabilities into Mopeks and that's cheating because it's supposed to emerge by itself. So why do you need to refine Mopeks further?

If your system is able to come up with the variational principle of physics and apply it to solve the differential game problem you referred to, it's quite an achievement. So why don't you drop the metaphysics and write up an ordinary scientific paper?