Pretty ambitious project. "Mathematical notation: We would like to reduce the time it takes for a domain expert to turn a mathematical specification into a working high-performance program. We are examining language changes which would enable computations to be written in a more mathematical format."
Why are these projects always in the research and D stage? But an AGI can plug itself into or encapsulate a math engine like Maple or Matlab or Mathematica for it's heavy duty symbology processing and computations or take open source or proprietary math engines and lay them on top of the language. Integration into the programming language is desirable, I imagine that there have been standards specs floated for these types of language enhancements though what I'm talking about would likely be a new language. John -----Original Message----- From: Chuck Esterbrook [mailto:[EMAIL PROTECTED] Sent: Friday, March 23, 2007 12:15 AM To: agi@v2.listbox.com Subject: Re: [agi] My proposal for an AGI agenda Sun has a fairly new language called Fortress that is targeted to scientists and engineers, and it has stronger notions of built-in math than your typical OO language. I don't know (and probably doubt) that it has the group/ring theory, category theory, etc. that you're looking for, but you can check into it yourself (if you haven't already): http://www.google.com/search?hl=en&q=sun+fortress&btnG=Search On 3/22/07, John Rose <[EMAIL PROTECTED]> wrote: > 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 > ----- 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
