Re: [Bug-apl] Keymap and underlined ⍺ and ⍵

[Elias Mårtenson]

Well, there is a very specific case that is exposed when trying to build up large arrays. That specific case has been discussed here a few times. It's underlying cause is that GNU APL proactively copies the array it's working on in case the user (i.e. the function that performs work on the data) of that array modifies it.

I have had a few stabs at solving this one, but none of my solutions have been good enough yet. My experiments have, however, shown the potential for improvement. For example, in the program below, the time taken to load a 10k-line file was reduced from several munites to a fraction of a second:

https://github.com/lokedhs/apl-tools/blob/master/io.apl#L8

Regards,

Elias

On 28 June 2014 21:44, Blake McBride <address@hidden> wrote:

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 <address@hidden> 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" <address@hidden> 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 <address@hidden> 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 <address@hidden> 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