Interestingly, I think performance could be the real ticket to a large resurgence of APL. The world has moved from faster processors to more processors (and threads). APL is unique in its ability for the programmer to express operations that can be parallelized. Ultimately, APL's ability to translate array operations into parallel operations will determine its success. As a first step, taking advantage of multiple cores is critical. Ultimately adding support for things like Nvidia Cuda would propel GNU APL into a leading language!
I know Juergen has worked on getting GNU APL to effectively use multiple cores. I really didn't follow that much because, at the time, I was just looking for it to work. Currently, there are no open items I am aware of in terms of getting GNU APL to "work". I'm sure I and others will find more things as we use the system, but I am also confident that this is a significantly decreasing number. I am excited about all of this. In terms of your million row table, now that we've gotten as far as we have, I strongly encourage you to create a simple example of the speed issue you encountered for Juergen's evaluation. Thanks. Blake On Sat, Jun 28, 2014 at 8:18 AM, Elias Mårtenson <[email protected]> wrote: > I agree with the suggestion to implement more extensions. There are a few > really interesting ones such as the power operator. > > However, performance is something that needs to be worked on as well. > Right now there are cases where performance deteriorates very quickly, such > as when constructing and working with large arrays. Right now GNU APL is > pretty much impossible to work with for 2D arrays of ten thousand rows or > more. > > I had to work with a million row table once, and I very quickly gave up > the idea of using APL for it. > > Regards, > Elias > On 28 Jun 2014 21:10, "Blake McBride" <[email protected]> wrote: > >> Dear Juergen, >> >> Thanks. If you are using the Dyalog standard then you should match my >> (WASD custom) keyboard, so I'll be interested in the layout once you >> correct ]KEYBOARD. >> >> I am hoping you can included my WASD keyboard design and setup file with >> GNU APL. This would make a high quality GNU APL keyboard available to >> everyone. >> >> Lastly, as a tangent, I hoped that down the road, once GNU APL is very >> stable with respect to the IBM standard, you may start to add operators >> provided by other APL vendors - so long as they don't conflict with the IBM >> standard. If you did this, you would slowly start making use of more of >> the currently unused APL characters. >> >> Thanks for everything. Your system is very usable now. I really like >> it. GNU APL contained the critical mass needed to get me back into APL >> after a 30 year hiatus. I have spent a bunch of time getting my old tools >> up and running on your system from old printouts I had. I pretty much have >> that going now. I am looking forward to making real use of GNU APL and my >> old framework again. Thanks a lot!! >> >> Blake >> >> >> >> On Sat, Jun 28, 2014 at 7:33 AM, Juergen Sauermann < >> [email protected]> wrote: >> >>> Hi Blake, >>> >>> these days GNU APL is following Dyalog APL because they are selling >>> their keyboards (and >>> I bought one). I just had forgotten to update the ]KEYBOARD command; the >>> config files shipped >>> with GNU APL should already reflect the Dyalog layout. >>> >>> IBM seems to offer only APL keycaps, and Unicomp did not even bother to >>> answer an inquiry >>> that I sent them. >>> >>> /// Jürgen >>> >>> >>> >>> On 06/27/2014 07:41 PM, Blake McBride wrote: >>> >>> I noticed that for the ]KEYBOARD command, the comment symbol ⍝ appears >>> in two places; on the C key, and on the \ key. I think, perhaps, that >>> keeping it on the \ key and removing it from the C key makes sense for the >>> following reason. The Z, X, C, and V keys are often mapped to the very >>> convenient four characters each with a quad and one of the four arrow keys >>> (up, down, right, left) which are very useful for keyed or component file >>> IO. >>> >>> I also, regretfully, noticed that I created my custom keyboard using >>> the Dyalog standard rather than the standard used by GNU APL. Apparently, >>> both the Dyalog standard, and the GNU APL standard differ from the IBM >>> standard. Perhaps Standard is a poor word... >>> >>> >>> Thanks. >>> >>> Blake >>> >>> >>> >>> On Fri, Jun 27, 2014 at 10:54 AM, Juergen Sauermann < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> Fred is correct. I have updated the ]KEYBOARD command to show >>>> the new layout (as for dyalog keyboards). ⍙ is Alt-shift-. (two keys >>>> right from M). SVN 345. >>>> >>>> /// Jürgen >>>> >>>> >>>> >>>> On 06/27/2014 05:15 PM, Frederick H. Pitts wrote: >>>> >>>>> Elias, >>>>> >>>>> My keyboard is configured to have ⍶, ⍹, and ⍷ above ⍺, ⍵ and ∊, >>>>> respectively, so that their locations are easy to remember. I would >>>>> have >>>>> liked to placed ⍙ above ∆ but that location was already occupied by ⍋, >>>>> so I placed ⍙ above ⌊ on the 'd' key. >>>>> >>>>> Regards >>>>> >>>>> Fred >>>>> >>>>> On Fri, 2014-06-27 at 22:44 +0800, Elias Mårtenson wrote: >>>>> >>>>>> Any suggestions where I should put the ⍶ and ⍹ symbols on the Emacs >>>>>> keymap? The ]KEYB command doesn't display a mapping for them. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Elias >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>
