Enhancements to existing computer languages or new computer languages that could possibly grease the wheels for AGI development would be aligning the language more closely to mathematics. Many of the computer languages are the same old things rehashed in different though new and evolutionarily better ways but nothing I've seen too revolutionary. Same old looping structures, classes, OOP, etc.. nothing new. But if someone could add some handy math structures into the language - group/ring theory, category theory, advanced graph structures have this stuff built right in not utilized through add-ons or libraries or coded in house. These math structures should be standardized and made part of the language now. Believe me, non mathematician programmers would learn these tools rapidly and use them in new and exciting ways. Now many are going in all sorts of wild goose chase directions due to lack of standard mathematical guidance built in. Growing a crop of potential AGI developers who don't need no math PHd's would happen if this came about. Granted good C++ coders can accomplish just about "anything" with the language, there is a complexity overhead tradeoff that needs to be maintained in doing so (in exchange for speed usually in C++). But as many here understand, having good patterns, algorithms and particularly math systems and structures, speed issues can be bridged and many times eliminated by designing and solving things through math verses CPU cycles. Now naturally AGI systems can and do have handcrafted or other incorporated languages built in, these too many times suffer from the same limitations. Though I imagine certain AGI's have some pretty advanced languages cooked up inside. And perhaps these are the ones that grapple more efficiently with machine and network resource limitations....
John -----Original Message----- From: David Clark [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 10:16 AM To: agi@v2.listbox.com Subject: Re: [agi] My proposal for an AGI agenda I totally agree that maximum speed is required for AGI. I agree with Ben that flexabilty is also needed (he might have said liked, not needed) like seen in Ruby. My language IDE has a small simple editor built-in that automatically reformats the code and compiles as it saves making compiling totally invisible. Edit/compile/run turnaround is as fast as one click of the mouse. My system, although unintentionally somewhat like Ruby (my system was totally designed without any knowledge of Ruby) has almost all of it's flexability while retaining almost the speed of C++. My worst case internal looping is 15x slower than C++ but most functions and overall program execution are much closer to C++ speed. The looping overhead on my machine is about 10M/sec for a store operation. My looping speed is 2-3 times faster than Visual FoxPro which is very fast for a compiler/byte code interpreter. I haven't tested Ruby on my machine but I would suggest it's looping overhead to be at least 100-200 times slower than C++. My indexing times are similiar to Visual FoxPro or better. I have never seen a faster indexing/data access system than Visual FoxPro (any bench mark between MySQL and Visual FoxPro would be no contest at all). I can import 100,000 names/addresses in 1.5 seconds and search every record in this file by first name, last name and prov in 1/10 second (data searched is 17.8M and all records are stored on the disk). I have tested full text search on 16K emails representing 100M of data in 1 second where the data is stored on the disk (it would be faster if only in memory). I have had 2.5K programs running at the same time and created tables of over 2M records. I have created arrays up to 10M elements. (size is limited to memory space) -- David Clark ----- Original Message ----- From: "Chuck Esterbrook" <[EMAIL PROTECTED]> To: <agi@v2.listbox.com> Sent: Tuesday, March 20, 2007 7:43 PM Subject: Re: [agi] My proposal for an AGI agenda > Sometimes the slowness of a program is not contained in a small > portion of a program. Especially, after a few rounds of profiling and > improving performance render the profile graph fairly flat. > > I experienced this on a financial program that I ported from Python to > C# for an 18 X speed up (and I had already improved the Python program > itself 2 - 4 X (memory getting fuzzy...) before running out of > reasonable ways to make it faster). So then instead of having to wait > 20 minutes per run to study the results and continue development, I > only needed to wait a little over a minute. That made a *huge* > improvement in speed of development. > > Unfortunately, C# is not a rapid coding language like Python and Ruby > and consequently some of the speed up (but not all) was lost in > development. > > There are some applications that don't suffer much from this either > because they are overwhelmed by external factors (such as network > latency), or they are a small part of the system (providing glue), or > they have a specific piece of code that overwhelms performance which > can be pushed out to C or C++ (tight inner loop). > > But there's plenty of programs that are down right fascinating *and* > compute intensive including AGI, GP/GA/EC, NNs, simulation, finances, > compression, search and more. Many of these require speed in order to > work with non-trivial data sets while still enabling a fast "run, > study, edit" loop. And, of course, you want quick, high level coding > to keep the "run, study, edit" loop tight as well. > > I think we can have both with the right language design. I'll finish > this off in a response to Ben in this same thread... > > -Chuck > > ----- > This list is sponsored by AGIRI: http://www.agiri.org/email > To unsubscribe or change your options, please go to: > http://v2.listbox.com/member/?list_id=303 ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303 ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?list_id=303