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

Reply via email to