Loading ...
Sorry, an error occurred while loading the content.

javascript Re: Discipulus GP Software Recommendations?

Expand Messages
  • satya_it10
    ... I ll be ... lead ... via ... below. ... is ... many ... genetic ... solution. In ... problems, ... thank u sir,please send me some matlab coding for GA
    Message 1 of 23 , May 26 11:43 PM
    • 0 Attachment
      --- In genetic_programming@yahoogroups.com, "jmerelo666"
      <jmerelo@...> wrote:
      >
      > --- In genetic_programming@yahoogroups.com, Lee Spector <lspector@>
      > wrote:
      > >
      > >
      > > A late reply, but for those interested in GP using JavaScript
      I'll be
      > > presenting a paper at GECCO 2007, for which Jon Klein was the
      lead
      > > researcher, called "Unwitting Distributed Genetic Programming
      via
      > > Asynchronous JavaScript and XML". I'll include the abstract
      below.
      > >
      > > -Lee
      > >
      > > thanks u sir ,

      > > \begin{abstract}
      > > The success of a genetic programming system in solving a problem
      is
      > > often a function of the available computational resources. For
      many
      > > problems, the larger the population size and the longer the
      genetic
      > > programming run the more likely the system is to find a
      solution. In
      > > order to increase the probability of success on difficult
      problems,
      > > designers and users of genetic programming systems often desire
      > > access to distributed computation, either locally or across the
      > > internet, to evaluate fitness cases more quickly. Most systems


      thank u sir,please send me some matlab coding for GA
      > > internet-scale distributed computation require a user's
      explicit
      > > participation and the installation of client side software. We
      > > present a proof-of-concept system for distributed computation
      of
      > > genetic programming via asynchronous javascript and XML (AJAX)
      > > techniques which requires no explicit user interaction and no
      > > installation of client side software. Clients automatically
      and
      > > possibly even unknowingly participate in a distributed genetic
      > > programming system simply by visiting a webpage, thereby
      allowing for
      > > the solution of genetic programming problems without running a
      single
      > > local fitness evaluation. The system can be easily introduced
      into
      > > existing webpages to exploit unused client-side computation for
      the
      > > solution of genetic programming and other problems.
      > > \end{abstract}
      > >
      > >
      > >
      > In fact, we'll be publishing a paper on the same subject in one of
      the
      > GECCO workshops (it didn't make it into GECCO proper). A previous
      > version has also been uploaded to ArXiV:
      > http://arxiv.org/abs/cs.DC/0701115
      > Here goes the abstract:
      > The challenge of ad-hoc computing is to find the way of taking
      > advantage of spare cycles in an efficient way that takes into
      account
      > all capabilities of the devices and interconnections available to
      > them. In this paper we explore distributed evolutionary computation
      > based on the Ruby on Rails framework, which overlays a
      > Model-View-Controller on evolutionary computation. It allows
      anybody
      > with a web browser (that is, mostly everybody connected to the
      > Internet) to participate in an evolutionary computation experiment.
      > Using a straightforward farming model, we consider different
      factors,
      > such as the size of the population used. We are mostly interested
      in
      > how they impact on performance, but also the scaling behavior when
      a
      > non-trivial number of computers is applied to the problem.
      Experiments
      > show the impact of different packet sizes on performance, as well
      as a
      > quite limited scaling behavior, due to the characteristics of the
      > server. Several solutions for that problem are proposed.
      > --
      > I would be very interested in having an advance copy of your paper.
      > Can you please email it to me? If you had some time to discuss it,
      > previous or during the conference, I'd also be grateful
      >
      > Cheers
      >
      > JJ
      >
    • Lucas, Simon M
      An alternative approach to achieving the same effect is to use Java Applets instead of JavaScript - Java is much faster than JavaScript, but is installed in
      Message 2 of 23 , May 28 6:35 AM
      • 0 Attachment
        An alternative approach to achieving the same effect

        is to use Java Applets instead of JavaScript - Java is much

        faster than JavaScript, but is installed in fewer browsers.



        Does anyone have any speed / installation-base comparisons

        for the two approaches? Would be interesting to know.



        Best wishes,



        Simon





        From: genetic_programming@yahoogroups.com
        [mailto:genetic_programming@yahoogroups.com] On Behalf Of satya_it10
        Sent: 27 May 2007 07:44
        To: genetic_programming@yahoogroups.com
        Subject: {Disarmed} [GP] javascript Re: Discipulus GP Software
        Recommendations?



        --- In genetic_programming@yahoogroups.com
        <mailto:genetic_programming%40yahoogroups.com> , "jmerelo666"
        <jmerelo@...> wrote:
        >
        > --- In genetic_programming@yahoogroups.com
        <mailto:genetic_programming%40yahoogroups.com> , Lee Spector <lspector@>
        > wrote:
        > >
        > >
        > > A late reply, but for those interested in GP using JavaScript
        I'll be
        > > presenting a paper at GECCO 2007, for which Jon Klein was the
        lead
        > > researcher, called "Unwitting Distributed Genetic Programming
        via
        > > Asynchronous JavaScript and XML". I'll include the abstract
        below.
        > >
        > > -Lee
        > >
        > > thanks u sir ,

        > > \begin{abstract}
        > > The success of a genetic programming system in solving a problem
        is
        > > often a function of the available computational resources. For
        many
        > > problems, the larger the population size and the longer the
        genetic
        > > programming run the more likely the system is to find a
        solution. In
        > > order to increase the probability of success on difficult
        problems,
        > > designers and users of genetic programming systems often desire
        > > access to distributed computation, either locally or across the
        > > internet, to evaluate fitness cases more quickly. Most systems

        thank u sir,please send me some matlab coding for GA
        > > internet-scale distributed computation require a user's
        explicit
        > > participation and the installation of client side software. We
        > > present a proof-of-concept system for distributed computation
        of
        > > genetic programming via asynchronous javascript and XML (AJAX)
        > > techniques which requires no explicit user interaction and no
        > > installation of client side software. Clients automatically
        and
        > > possibly even unknowingly participate in a distributed genetic
        > > programming system simply by visiting a webpage, thereby
        allowing for
        > > the solution of genetic programming problems without running a
        single
        > > local fitness evaluation. The system can be easily introduced
        into
        > > existing webpages to exploit unused client-side computation for
        the
        > > solution of genetic programming and other problems.
        > > \end{abstract}
        > >
        > >
        > >
        > In fact, we'll be publishing a paper on the same subject in one of
        the
        > GECCO workshops (it didn't make it into GECCO proper). A previous
        > version has also been uploaded to ArXiV:
        > http://arxiv.org/abs/cs.DC/0701115
        > Here goes the abstract:
        > The challenge of ad-hoc computing is to find the way of taking
        > advantage of spare cycles in an efficient way that takes into
        account
        > all capabilities of the devices and interconnections available to
        > them. In this paper we explore distributed evolutionary computation
        > based on the Ruby on Rails framework, which overlays a
        > Model-View-Controller on evolutionary computation. It allows
        anybody
        > with a web browser (that is, mostly everybody connected to the
        > Internet) to participate in an evolutionary computation experiment.
        > Using a straightforward farming model, we consider different
        factors,
        > such as the size of the population used. We are mostly interested
        in
        > how they impact on performance, but also the scaling behavior when
        a
        > non-trivial number of computers is applied to the problem.
        Experiments
        > show the impact of different packet sizes on performance, as well
        as a
        > quite limited scaling behavior, due to the characteristics of the
        > server. Several solutions for that problem are proposed.
        > --
        > I would be very interested in having an advance copy of your paper.
        > Can you please email it to me? If you had some time to discuss it,
        > previous or during the conference, I'd also be grateful
        >
        > Cheers
        >
        > JJ
        >





        [Non-text portions of this message have been removed]
      • jmerelo666
        ... In fact, it s not installed by default. And it s not as stealthy. And I m not so sure it would be faster. For simple computations, it would probably be
        Message 3 of 23 , May 28 7:40 AM
        • 0 Attachment
          --- In genetic_programming@yahoogroups.com, "Lucas, Simon M" <sml@...>
          wrote:
          >
          >
          >
          > An alternative approach to achieving the same effect
          >
          > is to use Java Applets instead of JavaScript - Java is much
          >
          > faster than JavaScript, but is installed in fewer browsers.

          In fact, it's not installed by default. And it's not as stealthy. And
          I'm not so sure it would be faster. For simple computations, it would
          probably be more or less the same; take into account that JVMs are not
          specially efficient always.

          > Does anyone have any speed / installation-base comparisons
          >
          > for the two approaches? Would be interesting to know.

          I've done some benchmarks with standalone JavaScript (yep, there's
          such a thing) and it's quite fast, and whatever makes it slower in the
          browser will also make the applet slower. Besides, the whole point is
          to be steatch, and achieve a massive number of customers by using
          something everybody has.

          JJ
        • jmerelo666
          ... I meant _stealthy_ here, not steatch . JJ
          Message 4 of 23 , May 28 8:25 AM
          • 0 Attachment
            --- In genetic_programming@yahoogroups.com, "jmerelo666" <jmerelo@...>
            wrote:

            > browser will also make the applet slower. Besides, the whole point is
            > to be steatch, and achieve a massive number of customers by using

            I meant _stealthy_ here, not "steatch".

            JJ
          • Lucas, Simon M
            Hi JJ, regarding speed - I would expect the difference to be significant - I think client-side JavaScript is interpreted, while Java (even in applets) is
            Message 5 of 23 , May 29 3:12 AM
            • 0 Attachment
              Hi JJ,



              regarding speed - I would expect the difference to be significant -

              I think client-side JavaScript is interpreted, while Java (even in
              applets) is compiled (JIT) -

              - I've benchmarked Java applets doing matrix multiplication and
              they're

              nearly as fast as the equivalent C / C++ program.



              Java applets can be just as stealthy, if that's what you want.



              would be interested to see the JavaScript speed figures.



              cheers,



              Simon



              ps. I didn't realise this, but it seems that server side JavaScript is
              sometimes compiled:



              http://www.jaws.umn.edu/javascript_1.1/intro.htm









              From: genetic_programming@yahoogroups.com
              [mailto:genetic_programming@yahoogroups.com] On Behalf Of jmerelo666
              Sent: 28 May 2007 15:40
              To: genetic_programming@yahoogroups.com
              Subject: {Disarmed} [GP] javascript Re: Discipulus GP Software
              Recommendations?



              --- In genetic_programming@yahoogroups.com
              <mailto:genetic_programming%40yahoogroups.com> , "Lucas, Simon M"
              <sml@...>
              wrote:
              >
              >
              >
              > An alternative approach to achieving the same effect
              >
              > is to use Java Applets instead of JavaScript - Java is much
              >
              > faster than JavaScript, but is installed in fewer browsers.

              In fact, it's not installed by default. And it's not as stealthy. And
              I'm not so sure it would be faster. For simple computations, it would
              probably be more or less the same; take into account that JVMs are not
              specially efficient always.

              > Does anyone have any speed / installation-base comparisons
              >
              > for the two approaches? Would be interesting to know.

              I've done some benchmarks with standalone JavaScript (yep, there's
              such a thing) and it's quite fast, and whatever makes it slower in the
              browser will also make the applet slower. Besides, the whole point is
              to be steatch, and achieve a massive number of customers by using
              something everybody has.

              JJ





              [Non-text portions of this message have been removed]
            • Langdon W B
              The mozilla standalone JavaScript in C (Spidermonkey, JSref) is decribed at http://www.mozilla.org/js/spidermonkey/ They also have an implementation in Java
              Message 6 of 23 , May 29 4:42 AM
              • 0 Attachment
                The mozilla standalone JavaScript in C (Spidermonkey, JSref)
                is decribed at
                http://www.mozilla.org/js/spidermonkey/
                They also have an implementation in Java (Rhino)

                Bill

                W. B. Langdon,
                Mathematical Sciences,
                University of Essex
                Wivenhoe Park,
                Colchester CO4 3SQ, UK
                http://www.essex.ac.uk/maths/staff/langdon/
                Spam blocking gmail
                Foundations of Genetic Programming
                http://www.cs.ucl.ac.uk/staff/W.Langdon/FOGP
                GECCO 2007 http://www.cs.ucl.ac.uk/external/W.Langdon/gecco
                GP EM http://www.springer.com/10710
                GP Bibliography http://www.cs.bham.ac.uk/~wbl/biblio/

                > Hi JJ,
                >
                >
                >
                > regarding speed - I would expect the difference to be significant -
                >
                > I think client-side JavaScript is interpreted, while Java (even in
                > applets) is compiled (JIT) -
                >
                > - I've benchmarked Java applets doing matrix multiplication and
                > they're
                >
                > nearly as fast as the equivalent C / C++ program.
                >
                >
                >
                > Java applets can be just as stealthy, if that's what you want.
                >
                >
                >
                > would be interested to see the JavaScript speed figures.
                >
                >
                >
                > cheers,
                >
                >
                >
                > Simon
                >
                >
                >
                > ps. I didn't realise this, but it seems that server side JavaScript is
                > sometimes compiled:
                >
                >
                >
                > http://www.jaws.umn.edu/javascript_1.1/intro.htm
                >
                >
                >
                >
                >
                >
                >
                >
                >
                > From: genetic_programming@yahoogroups.com
                > [mailto:genetic_programming@yahoogroups.com] On Behalf Of jmerelo666
                > Sent: 28 May 2007 15:40
                > To: genetic_programming@yahoogroups.com
                > Subject: {Disarmed} [GP] javascript Re: Discipulus GP Software
                > Recommendations?
                >
                >
                >
                > --- In genetic_programming@yahoogroups.com
                > <mailto:genetic_programming%40yahoogroups.com> , "Lucas, Simon M"
                > <sml@...>
                > wrote:
                > >
                > >
                > >
                > > An alternative approach to achieving the same effect
                > >
                > > is to use Java Applets instead of JavaScript - Java is much
                > >
                > > faster than JavaScript, but is installed in fewer browsers.
                >
                > In fact, it's not installed by default. And it's not as stealthy. And
                > I'm not so sure it would be faster. For simple computations, it would
                > probably be more or less the same; take into account that JVMs are not
                > specially efficient always.
                >
                > > Does anyone have any speed / installation-base comparisons
                > >
                > > for the two approaches? Would be interesting to know.
                >
                > I've done some benchmarks with standalone JavaScript (yep, there's
                > such a thing) and it's quite fast, and whatever makes it slower in the
                > browser will also make the applet slower. Besides, the whole point is
                > to be steatch, and achieve a massive number of customers by using
                > something everybody has.
                >
                > JJ
                >
                >
                >
                >
                >
              • jmerelo666
                Hi, ... Interpreted JS is not to slow, and, in fact, I would expect some kind of pre-compliation to a bytecode (similar to Java) actually happening in most
                Message 7 of 23 , May 29 5:06 AM
                • 0 Attachment
                  Hi,

                  > I think client-side JavaScript is interpreted, while Java (even in
                  > applets) is compiled (JIT) -
                  >
                  > - I've benchmarked Java applets doing matrix multiplication and
                  > they're
                  >
                  > nearly as fast as the equivalent C / C++ program.

                  Interpreted JS is not to slow, and, in fact, I would expect some kind
                  of pre-compliation to a bytecode (similar to Java) actually happening
                  in most browsers. JIT is a bytecode that runs within a virtual machine
                  that runs within the browser. Of course, that does not mean that JS
                  can be faster, but I wouldn't it expect to be orders of magnitude
                  slower. Factoring in stuff like development time, JS could even be
                  better.

                  > Java applets can be just as stealthy, if that's what you want.

                  Um, not really. Some (modern) browswers will warn you before
                  downloading and running an applet or ActiveX control; in Windows, the
                  Java logo will show up in the apps dock. They will also complain if
                  the JVM is not installed, and offer to install it. In any case, it
                  will be quite clear something is going on. Same goes for Flash
                  ActionScript stuff (and I don't have speed figures here, but they
                  might also be faster -or not- than JS)

                  > would be interested to see the JavaScript speed figures.

                  For standalone Javascript, they are right there on my paper. They are
                  comparable to other interpreted languages (like Perl).

                  JJ
                • Maarten
                  Ah, verbal language shoot-out! ... Not entirely true on the definition of JIT compilers. Java first compiles to bytecode, then the JIT will on the fly compile
                  Message 8 of 23 , May 29 6:30 AM
                  • 0 Attachment
                    Ah, verbal language shoot-out!

                    > Interpreted JS is not to slow, and, in fact, I
                    > would expect some kind of pre-compliation to a
                    > bytecode (similar to Java) actually happening
                    > in most browsers. JIT is a bytecode that runs
                    > within a virtual machine that runs within the
                    > browser. Of course, that does not mean that JS
                    > can be faster, but I wouldn't it expect to be
                    > orders of magnitude slower. Factoring in stuff
                    > like development time, JS could even be better.

                    Not entirely true on the definition of JIT
                    compilers. Java first compiles to bytecode, then
                    the JIT will on the fly compile it to assembler
                    for the platform the JVM is running on. This is
                    very different from running just a bytecode VM as
                    is done in JS. In early days Java ran purely
                    interpreted bytecode, and Java was sloooow.
                    Java's JIT compilation has come a long way, and
                    current Java is indeed very fst.

                    JIT-compiled JS does not exist, and will not exist
                    in the foreseeable future. Even if it gets a
                    Jit-compiler, it will be massively slower than
                    Java. Reason for this is that although both java
                    and JS are strongly typed, JS does duck-typing
                    purely at runtime. I.e., for every method call,
                    it needs to be checked that the underlying object
                    has a method of the specified name. Typically
                    this is done through a hashtable lookup instead
                    of a virtual table dispatch. So, *every* method
                    call involves a hash-lookup. JS is therefore
                    very, very slow. It has this in common with perl,
                    python and ruby.

                    Java is partly compile time typed. Where it is
                    runtime typed (most noteably in the Collections
                    library), it uses casting (a single Runtime
                    check) and virtual table dispatch henceforth.
                    Virtual table dispatch is not more expensive than
                    following a function pointer in C. Compile time
                    typing + use of primitive types + casting logic +
                    virtual table dispatch means that the JIT
                    compiler can make rather strong assumptions on
                    the Java bytecode, and hence compile it to
                    fast/compact code.

                    It might be fun to look at the language shootout
                    at http://shootout.alioth.debian.org/

                    Current status

                    1.0 C gcc
                    1.9 Java JDK-server
                    42 JavaScript SpiderMonkey

                    Giving Java the edge with a factor 20. So yes,
                    it's an order of magnitude.

                    -Maarten-

                    > > Java applets can be just as stealthy, if
                    > > that's what you want.
                    >
                    > Um, not really. Some (modern) browswers will
                    > warn you before downloading and running an
                    > applet or ActiveX control; in Windows, the Java
                    > logo will show up in the apps dock. They will
                    > also complain if the JVM is not installed, and
                    > offer to install it. In any case, it will be
                    > quite clear something is going on. Same goes
                    > for Flash ActionScript stuff (and I don't have
                    > speed figures here, but they might also be
                    > faster -or not- than JS)
                    >
                    > > would be interested to see the JavaScript
                    > > speed figures.
                    >
                    > For standalone Javascript, they are right there
                    > on my paper. They are comparable to other
                    > interpreted languages (like Perl).
                    >
                    > JJ
                  • dgoe@itwebs.com
                    I new to this and have been trying to find some source code or genetic programming pseudocode. Just want better understand how to construct the GP program. Any
                    Message 9 of 23 , May 29 6:39 AM
                    • 0 Attachment
                      I new to this and have been trying to find some
                      source code or genetic programming pseudocode.
                      Just want better understand how to construct the GP program.
                      Any links would be appreciated.
                      D.G.

                      ----------------------------------------------------
                      From : jmerelo666 <jmerelo@...>
                      To : genetic_programming@yahoogroups.com
                      Subject : {Disarmed} [GP] javascript Re: Discipulus GP Software
                      Recommendations?
                      Date : Tue, 29 May 2007 12:06:39 -0000
                      > Hi,
                      >
                      > > I think client-side JavaScript is interpreted, while Java (even in
                      > > applets) is compiled (JIT) -
                      > >
                      > > - I've benchmarked Java applets doing matrix multiplication
                      and
                      > > they're
                      > >
                      > > nearly as fast as the equivalent C / C++ program.
                      >
                      > Interpreted JS is not to slow, and, in fact, I would expect some kind
                      > of pre-compliation to a bytecode (similar to Java) actually happening
                      > in most browsers. JIT is a bytecode that runs within a virtual machine
                      > that runs within the browser. Of course, that does not mean that JS
                      > can be faster, but I wouldn't it expect to be orders of magnitude
                      > slower. Factoring in stuff like development time, JS could even be
                      > better.
                      >
                      > > Java applets can be just as stealthy, if that's what you want.
                      >
                      > Um, not really. Some (modern) browswers will warn you before
                      > downloading and running an applet or ActiveX control; in Windows, the
                      > Java logo will show up in the apps dock. They will also complain if
                      > the JVM is not installed, and offer to install it. In any case, it
                      > will be quite clear something is going on. Same goes for Flash
                      > ActionScript stuff (and I don't have speed figures here, but they
                      > might also be faster -or not- than JS)
                      >
                      > > would be interested to see the JavaScript speed figures.
                      >
                      > For standalone Javascript, they are right there on my paper. They are
                      > comparable to other interpreted languages (like Perl).
                      >
                      > JJ
                    • Jurosz Michal
                      Hi, see http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=javascript&lang2=java and
                      Message 10 of 23 , May 29 6:58 AM
                      • 0 Attachment
                        Hi, see

                        http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=javascript&lang2=java

                        and

                        http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=javascript&lang2=javaclient

                        but I don't know if it helps.

                        * JavaScript is a dynamic and weakly typed.

                        * JIT is amazingly resource-heavy ...
                        http://www.sidhe.org/~dan/blog/archives/000405.html

                        * ...

                        --
                        S pozdravem Michal Jurosz
                        http://pr.perl6.cz/parrot-lgp
                        Linear genetic programming for Parrot VM
                      • Marcus G. Daniels
                        ... Firefox s Spidermonkey does have bytecode representation, but it doesn t have just in time compiler (JIT) as a Java virtual machine will in most cases.
                        Message 11 of 23 , May 29 8:22 AM
                        • 0 Attachment
                          jmerelo666 wrote:
                          >
                          > Interpreted JS is not to slow, and, in fact, I would expect some kind
                          > of pre-compliation to a bytecode (similar to Java) actually happening
                          > in most browsers.
                          >
                          Firefox's Spidermonkey does have bytecode representation, but it doesn't
                          have just in time compiler (JIT) as a Java virtual machine will in most
                          cases.
                          That's what Tamarin is supposed to add to Firefox.

                          Another platform to think about is Silverlight (and Mono's Moonlight).
                          There the bytecode will be JIT'ed CIL with extensions for dynamic languages.
                          http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx
                        • Sean Luke
                          It has been my experience (in various optimized code I write) that compared to Java, and ignoring startup time: - Well-optimized scheme is about 5 times slower
                          Message 12 of 23 , May 29 9:16 AM
                          • 0 Attachment
                            It has been my experience (in various optimized code I write) that
                            compared to Java, and ignoring startup time:

                            - Well-optimized scheme is about 5 times slower at best. Actually
                            I've found hand-hacked Kawa to be fastest for stuff I do (about 2x
                            slower) as it has options to add explicit typing.

                            - Python is almost exactly 10 times slower, except when I customize
                            it for certain applications by dropping down to C (or when Numerical
                            Python is (rarely) helpful). psyco only helps a little bit.

                            - Ruby is 30 about times slower

                            - JavaScript (SpiderMonkey) is often over 50 times slower

                            I still use dynamic languages for lots of stuff. They're extremely
                            convenient tools for the right purposes. But if efficiency is your
                            primary goal (as is often the case in GP evaluations), you might wish
                            to look elsewhere.

                            Sean
                          • Jurosz Michal
                            I still believe in Parrot VM (register-based virtual machine) http://www.parrotcode.org/ http://en.wikipedia.org/wiki/Parrot_virtual_machine It is not
                            Message 13 of 23 , May 30 12:57 AM
                            • 0 Attachment
                              I still believe in Parrot VM (register-based virtual machine)
                              http://www.parrotcode.org/
                              http://en.wikipedia.org/wiki/Parrot_virtual_machine

                              It is not optimized well yet.

                              Some old benchmarks (Parrot 0.4.6, August 9, 2006):
                              http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=parrot&lang2=java

                              parrot-lgp (linear genetic programming implementation for Parrot virtual
                              machine) is optimized for fun (-Ofun) now :-).

                              http://pr.perl6.cz/parrot-lgp


                              Some interesting notes about Parrot VM:
                              * Loadable opcode libraries
                              http://www.sidhe.org/~dan/blog/archives/000409.html
                              * All those opcodes
                              http://www.sidhe.org/~dan/blog/archives/000404.html
                              * Fast interpretation
                              http://www.sidhe.org/~dan/blog/archives/000405.html
                              * another Perl 6 and Parrot links
                              http://perl6.cz/wiki/Perl_6_and_Parrot_links

                              --
                              S pozdravem Michal Jurosz
                            • Marcus G. Daniels
                              Here s a new document on the Tamarin instruction set... http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf
                              Message 14 of 23 , May 30 8:42 AM
                              • 0 Attachment
                                Here's a new document on the Tamarin instruction set...

                                http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf
                              • satya_it10
                                ... plz send me some matlab coding regarding to constrained optimisation using ga satyaveer singh india
                                Message 15 of 23 , May 31 10:10 PM
                                • 0 Attachment
                                  --- In genetic_programming@yahoogroups.com, "Marcus G. Daniels"
                                  <mgd@...> wrote:
                                  >
                                  > Here's a new document on the Tamarin instruction set...
                                  >
                                  > http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf
                                  >plz help me in constrained optimisation using ga
                                  plz send me some matlab coding regarding to constrained optimisation
                                  using ga






                                  satyaveer singh
                                  india
                                Your message has been successfully submitted and would be delivered to recipients shortly.