Re: [Bug-apl] ⎕RL wrong initial value

Since ⎕RL is defined as starting at a specific value in their language manual, and IBM APL 2 operates that way, I can imagine someone testing that value in a program to see if any random numbers had been generated previously. (I agree it is a stupid and not entirely valid test, but I cannot predic

Re: [Bug-apl] ⎕RL wrong initial value

Because adopting a clearly arbitrary value that provides absolutely no benefit, instead of something slightly more logical while still conforming with the spec is, in my opinion, the better way to go. No one is going to fork the project over this, so this is in the hands of Jürgen. Have have own o

Re: [Bug-apl] ⎕RL wrong initial value

No need to argue. Nowhere is the random number generator algorithm specified, but ⎕RL is. I thought we long ago agreed that, except for extensions, we were attempting to match the IBM APL standard - for better or worse. Additionally, in any area where it is arbitrary or pointless, why not just m

Re: [Bug-apl] )COPY should not copy ⎕PW

As I've stated before, I am not smart enough to understand that spec. IBM's language manual is readable, and it is clear about how it works. Also, I just tested IBM APL 2. It works as I describe. On Tue, Jul 1, 2014 at 9:48 PM, Elias Mårtenson wrote: > The standard spec is not entirely clear

Re: [Bug-apl] ⎕RL wrong initial value

I'd argue because GNU APL uses a different random number generator, so using the same RL value is pointless at best, and can raise unfulfilled expectations and confusion at worst. Regards, Elias On 2 July 2014 10:57, Blake McBride wrote: > As I've stated before, I am not smart enough to unders

Re: [Bug-apl] ⎕RL wrong initial value

As I've stated before, I am not smart enough to understand that spec. IBM's language manual is readable, and the value it is clear about is what I expected. Also, I just tested IBM APL 2. Initial ⎕RL is 16807. If any value is valid, why not match IBM APL 2 and their Language Manual? On Tue, J

Re: [Bug-apl] )COPY should not copy ⎕PW

The standard spec is not entirely clear on this, but the way I read it suggests that everything it supposed to be copied. Regards, Elias On 2 July 2014 09:58, Blake McBride wrote: > According to the IBM APL2 Programming Language Reference (page 423), the > )COPY command should not copy ⎕PW. T

Re: [Bug-apl] ⎕RL wrong initial value

The standard says the following: *"The initial value of random-link in a clear-workspace is that member of the internal-* *value-set for random-link given by the implementation-parameter initial-random-link."* So, setting it to 1 seems to be reasonable enough. Regards, Elias On 2 July 2014 10:

[Bug-apl] ⎕RL wrong initial value

According to the IBM APL2 Language Manual (page 421 AND page 322), ⎕RL initial value, and upon )CLEAR should be 16807. GNU APL seems to be setting it to 1. Thanks. Blake

[Bug-apl] )COPY should not copy ⎕PW

According to the IBM APL2 Programming Language Reference (page 423), the )COPY command should not copy ⎕PW. The manual states: "The only system objects that can be copied are ⎕CT, ⎕FC, ⎕IO, ⎕LX, ⎕PP, ⎕PR, and ⎕RL. Current GNU APL: )CLEAR CLEAR WS ⎕PW←80 )save ws1 2014-07-01 2

[Bug-apl] .apl.history

GNU APL creates a .apl.history in whatever directory APL is started up in. This is unlike all other system I've seen, and a problem when you don't start APL in the same directory each time. I think rather than .apl.history, the system should use ~/.apl.history In other words keep in the home dire

Re: [Bug-apl] Identify function

Further insights here: http://aplwiki.com/Left,%20Right,%20or%20the%20Same%3F BTW, note that ISO APL conjugate returns DOMAIN ERROR for a non-numeric argument. When Dyalog introduced the identity function, they deprecated use of + as identity; perhaps they're attempting to move closer to standar

Re: [Bug-apl] Identify function

Exactly, and since an identity function is useful it makes sense to map it to the same symbol as Dyalog. Regards, Elias On 2 July 2014 00:55, David Lamkins wrote: > Digging further, it's interesting to note that ISO APL defines + as > conjugate, but does not have a binding for the identity fun

Re: [Bug-apl] Identify function

Digging further, it's interesting to note that ISO APL defines + as conjugate, but does not have a binding for the identity function. On Tue, Jul 1, 2014 at 9:42 AM, David Lamkins wrote: > I looked this up yesterday. Dialog version 13 introduced the use of the > tack as identity and repurposed

Re: [Bug-apl] Identify function

I looked this up yesterday. Dialog version 13 introduced the use of the tack as identity and repurposed + as conjugate. (Actually, they bound both left and right tacks identically, even though they call left tack "same" and right tack "identity".) If the argument of conjugate is imaginary, conjugat

Re: [Bug-apl] Identify function

Well, + used to be the identify function before the introduction of complex numbers. Now + is the conjugate function (conjugate is equal to identity for reals). I believe the identity function is useful when you have an operator where you want the passed-in function to do nothing. A somewhat contr

Re: [Bug-apl] Identify function

Hi Elias, I looked in "Mastering APL" from Dyalog and could not find it. They call + the identity function. And what would be the use of it? /// Jürgen On 06/30/2014 06:24 AM, Elias Mårtenson wrote: I was looking at the Dyalog reference manual and realised that they support monadic ⊢ (right)

Re: [Bug-apl] Some thoughts regarding optimization of memory allocation

I agree with the general point, but is it really executed that often? (good) APL code tends to do a lot with few operations. It would perhaps make sense to benchmark how many comma functions are called in a typical program? Regards, Elias On 1 Jul 2014 21:25, "Juergen Sauermann" wrote: > Hi Davi

Re: [Bug-apl] Some thoughts regarding optimization of memory allocation

The solution is to use a copy-on-write mechanism (instead of the current "copy always" solution which works beautifully, but can be very slow). That is a fairly large change, and I've had a few stabs at it and failed. That said, I probably failed because I don't understand the code well enough. R

Re: [Bug-apl] Some thoughts regarding optimization of memory allocation

I agree with the above, but I feel strongly that eliminating the proactive copying should be a higher priority. Is it agreed that the proactive copying is a more immediate and significant problem? Thanks. Blake On Tue, Jul 1, 2014 at 1:22 AM, Elias Mårtenson wrote: > This is an interesting

Re: [Bug-apl] Some thoughts regarding optimization of memory allocation

Hi David, I agree to your analysis below. The problem with "in place" modification like A←A,x is another one: the ownership of A may be unknown. Some time ago we had an optimization of A⍴B modifying B in place when A was ≤⍴B. That looked good initially but fired back when static APL values (l

Re: [Bug-apl] Mastering Dyalog APL - link outdated

Hi David, thanks, updated in SVN 353. /// Jürgen On 06/30/2014 11:05 PM, David Lamkins wrote: In README-7-more-info, the link to Mastering Dyalog APL now redirects to the Dyalog home page. Use this link instead: http://www.dyalog.com/mastering-dyalog-apl.htm -- "The secret to creativity is

Re: [Bug-apl] Patch to show directories in )LIB and ]LIB

Hi David, thanks, included in SVN 353. /// Jürgen On 06/30/2014 08:38 PM, David Lamkins wrote: Here's an improved patch that also sorts ]LIB output. On Sun, Jun 29, 2014 at 7:34 PM, David B. Lamkins > wrote: Since )LIB and ]LIB will accept path names, I tho

Re: [Bug-apl] [bug-apl] SVN 346 APserver error on startup

Hi, I guess I found the fault. Missing MSG_WAITALL flag in APserver. Fixed in SVN 353. /// Jürgen

Re: [Bug-apl] [bug-apl] SVN 346 APserver error on startup

My apl is 64-bit though. Both on Arch where it fails and on Ubuntu where it works. Also, remember that it only happens when run inside of Emacs. I still think it's the timing issue. Regards, Elias On 1 July 2014 19:12, Juergen Sauermann wrote: > Hi, > > there seems to be some type size confu

Re: [Bug-apl] [bug-apl] SVN 346 APserver error on startup

Hi, there seems to be some type size confusion on 32-bit machines. The code runs on my 64-bit linux but not on my 32-bit linux. I'll look into this. /// Jürgen On 07/01/2014 12:31 PM, Elias Mårtenson wrote: This is weird. I only get the error when starting GNU APL from within Emacs. When I

Re: [Bug-apl] [bug-apl] SVN 346 APserver error on startup

Oh, and here's the log from a failed session (without external APserver). I forgot to include it in my previous email: Reading config file /home/emartenson/src/apl/dist/etc/gnu-apl.d/preferences ... config file /home/emartenson/.config/gnu-apl/preferences is not present/readable Network listener s

Re: [Bug-apl] [bug-apl] SVN 346 APserver error on startup

This is weird. I only get the error when starting GNU APL from within Emacs. When I start it manually, using exactly the same arguments (including the --emacs part) it doesn't fail. If I manually start APserver and run apl from Emacs it also works correctly. When I *do* get the error, the APserve

Re: [Bug-apl] [bug-apl] SVN 346 APserver error on startup

Hi ELias, sorry, my fault. Should have been -l 37 On 07/01/2014 08:41 AM, Elias Mårtenson wrote: Thank you. I tried to use the -l flag for apl, but it says the argument is not accepted. $ dist/bin/apl -l37 unknown option '-l37' Regards, Elias