[Bug-apl] This looks wrong

[David B. Lamkins]

Maybe I've misunderstood some APL2 corner case, but the behavior of the
attached program seems wrong.

⍝!

∇z←false
  z←0
∇

∇test1
  →(false)/0
  'foo'
  →false/0
  'bar'
∇

test1

∇test2
  'check1' (0≡false)
  'check2' (0≡(false))
  'case 1' (0/0)
  'case 2' (false/0)
  'case 3' ((false)/0)
∇

test2

Re: [Bug-apl] ERR function in APL2?

[Juergen Sauermann]

Hi Elias,

it was available ,but behaves differently. ⎕ES stops execution
while the ERR function only displays an error if it occurs.

/// Jürgen



On 08/05/2014 06:42 AM, Elias Mårtenson wrote:
Thank you. I see now how it works. Personally, I'd use Quad-ES to set 
an error state instead. Was Quad-ES available on APL2?


Regards,
Elias


On 5 August 2014 01:42, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Elias,

ERR is indeed a function, defined on page 49 of that document.

/// Jürgen



On 08/04/2014 08:13 AM, Elias Mårtenson wrote:

I was browsing the APL2 documentation, and came across the
following code (page 56, on the PDF here
):

[0]  Z←NAME GETW N
[1] ⍝GET ITEMS N FROM THE TABLE NAMED NAME
[2]  Z←''
[3]  →('NOT A VALID TABLE NAME' *ERR*~(⊂NAME)∊TABLES)/0
[4]  TAB←⍎NAME
[5]  B←N∊TAB[;1]
[6]  →0ρ('ITEM(S)'((~B)/N)'NOT FOUND')*ERR*~^/B
[7]  →(~∨/B)/0 ⍝ EXIT IF NONE FOUND
[8]  Z←(TAB[;1]∊N)⌿›TAB

What is ERR here?  It seems like a function that sets some error
state? It certainly looks like something useful to have. I can't
think of any way I could build this myself though.

Regards,
Elias

Re: [Bug-apl] This looks wrong

[Elias Mårtenson]

The issue here seems to be that since test is a nihilic function returning
0, the following call:

  test/0

Is equivalent to the following:

  {0⊣⍵}/0

which returns a single 0, since the /-reduction on a scalar is the value
itself.

However, the following:

  (test)/0

is equivalent to:

  0/0

because (test) evaluates before /, resulting in ⍬.

Regards,
Elias



On 5 August 2014 15:39, David B. Lamkins  wrote:

> Maybe I've misunderstood some APL2 corner case, but the behavior of the
> attached program seems wrong.
>
>

Re: [Bug-apl] ERR function in APL2?

[Elias Mårtenson]

Yes. It seems the APL2 example code is not very good. If an error occurs,
you really don't want to just continue running. :-)

Regards,
Elias


On 5 August 2014 18:23, Juergen Sauermann 
wrote:

>  Hi Elias,
>
> it was available ,but behaves differently. ⎕ES stops execution
> while the ERR function only displays an error if it occurs.
>
> /// Jürgen
>
>
>
>
> On 08/05/2014 06:42 AM, Elias Mårtenson wrote:
>
> Thank you. I see now how it works. Personally, I'd use Quad-ES to set an
> error state instead. Was Quad-ES available on APL2?
>
>  Regards,
> Elias
>
>
> On 5 August 2014 01:42, Juergen Sauermann 
> wrote:
>
>>  Hi Elias,
>>
>> ERR is indeed a function, defined on page 49 of that document.
>>
>> /// Jürgen
>>
>>
>>
>> On 08/04/2014 08:13 AM, Elias Mårtenson wrote:
>>
>> I was browsing the APL2 documentation, and came across the following code
>> (page 56, on the PDF here
>> ):
>>
>>  [0]  Z←NAME GETW N
>> [1] ⍝ GET ITEMS N FROM THE TABLE NAMED NAME
>> [2]  Z←''
>> [3]  →('NOT A VALID TABLE NAME' *ERR*~(⊂NAME)∊TABLES)/0
>> [4]  TAB←⍎NAME
>> [5]  B←N∊TAB[;1]
>> [6]  →0ρ('ITEM(S)'((~B)/N)'NOT FOUND')*ERR*~^/B
>> [7]  →(~∨/B)/0  ⍝ EXIT IF NONE FOUND
>> [8]  Z←(TAB[;1]∊N)⌿›TAB
>>
>>  What is ERR here?  It seems like a function that sets some error state?
>> It certainly looks like something useful to have. I can't think of any way
>> I could build this myself though.
>>
>>  Regards,
>> Elias
>>
>>
>>
>
>

Re: [Bug-apl] build warning on OSX

[Juergen Sauermann]

Hi Peter,

I guess you accidentally deleted the file or did the 'svn update' from 
the src subdir?


/// Jürgen


On 08/04/2014 09:51 PM, Peter Teeson wrote:

I did a brand new SVN co and then did ./configure and got this warning

file://localhost/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl:
 warning: Missing file: 
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl is 
missing from working copy.


Peter

Re: [Bug-apl] build warning on OSX

[Peter Teeson]

First I deleted the previous folder (directory) and then did a brand new svn co 
of the trunk followed by the usual ./configure and make.

There is a script.apl file in /workspaces but not a SCRIPT.apl one.
Even my backup does not have one.

Other than documentation it appears in the /workspaces Makefile and Makefile.am

I'm confused….

Peter

On 2014-08-05, at 6:41 AM, Juergen Sauermann  
wrote:

> Hi Peter,
> 
> I guess you accidentally deleted the file or did the 'svn update' from the 
> src subdir?
> 
> /// Jürgen
> 
> 
> On 08/04/2014 09:51 PM, Peter Teeson wrote:
>> I did a brand new SVN co and then did ./configure and got this warning
>> 
>> file://localhost/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl:
>>  warning: Missing file: 
>> /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl is 
>> missing from working copy.
>> 
>> 
>> Peter
>> 
>> 
> 

Re: [Bug-apl] build warning on OSX

[Elias Mårtenson]

I believe I know what's going on.

OSX is case insignificant, but case-preserving. This means that the files
foo and FOO are actually the same file. This is usually not a problem, but
it's completely opposite to how Unix is supposed to work, and is caused by
backward compatibility with OS9.

I think what happens is that the repository has a historical file called
script.apl and a newer revision containing SCRIPT.apl. This seems to
confuse the OSX svn since it believes these are the same file.

I'll test this later on my own mac once I've had my dinner. :-)

Regards,
Elias


On 5 Aug 2014 19:53, "Peter Teeson"  wrote:

> First I deleted the previous folder (directory) and then did a brand new
> svn co of the trunk followed by the usual ./configure and make.
>
> There is a script.apl file in /workspaces but not a SCRIPT.apl one.
> Even my backup does not have one.
>
> Other than documentation it appears in the /workspaces Makefile and
> Makefile.am
>
> I'm confused….
>
> Peter
>
> On 2014-08-05, at 6:41 AM, Juergen Sauermann <
> juergen.sauerm...@t-online.de> wrote:
>
> > Hi Peter,
> >
> > I guess you accidentally deleted the file or did the 'svn update' from
> the src subdir?
> >
> > /// Jürgen
> >
> >
> > On 08/04/2014 09:51 PM, Peter Teeson wrote:
> >> I did a brand new SVN co and then did ./configure and got this warning
> >>
> >>
> file://localhost/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl:
> warning: Missing file:
> /Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl
> is missing from working copy.
> >>
> >>
> >> Peter
> >>
> >>
> >
>
>
>

Re: [Bug-apl] build warning on OSX

[Juergen Sauermann]

Hi Peter,

ah, your talking of the installation directory. There was a fault in 
Makefile.am

that installed that file in some doc directory. Fixed in SVN 416.

/// Jürgen


On 08/05/2014 01:52 PM, Peter Teeson wrote:

First I deleted the previous folder (directory) and then did a brand new svn co 
of the trunk followed by the usual ./configure and make.

There is a script.apl file in /workspaces but not a SCRIPT.apl one.
Even my backup does not have one.

Other than documentation it appears in the /workspaces Makefile and Makefile.am

I'm confused….

Peter

On 2014-08-05, at 6:41 AM, Juergen Sauermann  
wrote:


Hi Peter,

I guess you accidentally deleted the file or did the 'svn update' from the src 
subdir?

/// Jürgen


On 08/04/2014 09:51 PM, Peter Teeson wrote:

I did a brand new SVN co and then did ./configure and got this warning

file://localhost/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl:
 warning: Missing file: 
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/workspaces/SCRIPT.apl is 
missing from working copy.


Peter

Re: [Bug-apl] Useful range of decode function is limited.

[Juergen Sauermann]

Hi,

I have changed the decode function to stay longer in the integer domain, 
SVN 416,


Not sure what is wrong with 2⋆63 - looks OK to me.

Note also that the largest integer in GNU APL (see ⎕SYL[20;]) is 
920
and not 9223372036854775808 (and therefore 2⋆63 is outside that range). 
The reason
for that is that in order to detect integer overflow the check for 
overflow itself is performed in
double arithmetic (and subject to rounding errors). I therefore made the 
integer range slightly

smaller.

The accuracy of ! is a matter of an accuracy-speed trade-off. Computing 
N! in 64-bit integer can

take up to 20 multiplications while the float variant is probably faster.

/// Jürgen


On 08/05/2014 06:45 AM, Frederick H. Pitts wrote:

Hello Elias,

1) "MOST-NEGATIVE-FIXNUM" and "largest negative integer" are much closer
in connotation to each other than either is to "smallest (negative)
integer".  "smallest" and "largest" are generally used when comparing
the magnitudes (or absolute values) of numbers irrespective of the signs
of those numbers.  So I think we are in agreement the label needs to
change.

2) 2*63 does not produce the right answer but 2*62 does.  So GNU-APL is
capable of doing integer arithmetic well outside the 53-bit integer
range of double precision floating point.  Unfortunately, that
capability is not fully utilized.  It's disingenuous to claim GNU-APL
supports 64-bit integer arithmetic when primitive operations like ⊥
(decode) and ! (binomial) yield results of accuracy limited by the
53-bit integer range of floating point when they do not have to be.
There are ways to force the use of the use of the APL_Integer!  It's a
simple matter of programming.  If you are
interested I can supply you with defined functions that work around
the ! (binomial) accuracy limitation. (Jim Weigang presented the
functions in comp.lang.apl years ago). I wonder how much faster the
functions would be if they were implemented in C++.

Regards,

Fred

On Tue, 2014-08-05 at 11:34 +0800, Elias Mårtenson wrote:

Mathematically, the term "small" is ambiguous. Perhaps that's why
Common Lisp names its corresponding value MOST-NEGATIVE-FIXNUM.


That said, in GNU APL, these numbers are somewhat bogus anyway. In
particular, the actual maximum number that can be stored without loss
of precision depends on the underlying data type of the value.


For real numbers, this data type can be either APL_Integer in which
the largest number is 9223372036854775808 (2^63), but if you try to
create this number in GNU APL using the expression 2⋆63, you will get
an APL_Float back, which has a smaller maximum precise value
of 9007199254740992 (2^53).


So, in summary. You can never rely on integral numbers being precise
to more than 53 bits of precision unless there is a way to force the
use of APL_Integer which I don't believe there is.


It would be nice to have support for bignums in GNU APL. It wouldn't
be overly difficult to implement I think. Perhaps I'll try that one
day unless Jürgen is completely against the idea.


Regards,
Elias


On 5 August 2014 09:37, Frederick H. Pitts 
wrote:
 Juergen,
 
 Please consider the following:
 
   ( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 53 ⍴ 1

 9007199254740991
 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
 1 1 1 1 1
 1 1 1 1
   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
   ( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 54 ⍴ 1
 18014398509481984
 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0
 0 0 0 0
   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 
 Between 53 bits and 54 bits, decode starts returning

 an incorrect
 result (the reported value is even when it should be odd).
  Presumably
 floating point numbers start creeping in at that point.
 Is it possible to tweak the decode code so that at
 least 62 bits of a
 64-bit integer are usable with encode and decode?  I'd really
 like to
 use 9 7-bit fields (63 bit total) to track powers of
 dimensions in
 unit-of-measure calculations but I'm confident that is asking
 for too
 much. I can cut the range of one of the dimensions in half.
 
 BTW, the "smallest (negative) integer" label of the

 ⎕SYL output would
 read better as "largest negative integer".
  ¯920 is not
 small.
 ¯1, 0, and 1 are small.
 
 Regards,
 
 Fred

 Retired Chemical Engineer
 
 

Re: [Bug-apl] This looks wrong

[Juergen Sauermann]

Hi David,

thanks, fixed in SVN 417. Unfortunately, as a consequence, it is no
longer possible to pass a niladic function to an operator.

/// Jürgen


On 08/05/2014 09:39 AM, David B. Lamkins wrote:

Maybe I've misunderstood some APL2 corner case, but the behavior of the
attached program seems wrong.

Re: [Bug-apl] apl.xkb

[Juergen Sauermann]

Hi Blake,

I have copied your apl.wasd.kbd to the Dyalog keyboard folder, SVN 418.
The file is now called apl.kbd everywhere and the folder tells which 
keyboard is meant.



/// Jürgen


On 08/01/2014 05:57 PM, Blake McBride wrote:
GNU APL comes with a file named apl.xkb under the support-files 
directory.  I just did some testing of it with a normal (non-apl) 
keyboard.  The mappings in that file are way out-of-date and do not 
match ]keyb output.  That would also be true of the compiled version 
of that file - apl.xkm.


I then tested my WASD map file - apl.wasd.xkb.  That file correctly 
maps a non-apl keyboard to map correctly with ]keyb output.


Although my WASD config file was made for my WASD keyboard design, it 
also completely correctly maps to non-APL keyboards too.


I suggest that:

1.  support-files/apl.wasd.kbd be copied to apl.xkb

2.  remove apl.xkm

3.  Update the docs to use apl.xkb rather than apl.xkm (just 
substitute apl.xkm with apl.xkb in README-3-keyboard


Thanks.

Blake

Re: [Bug-apl] This looks wrong

[Elias Mårtenson]

Are you sure we want to fix that though? Things like the power operator
(once we have it) will not work right (since it's seems to be often used to
execute a niladic function a certain number of times.

The SQL∆WithTransaction will have the same problem.

The workaround seems to be a bit ugly, like prefixing the lambda function
with ⍵⊢

Regards,
Elias


On 5 August 2014 22:07, Juergen Sauermann 
wrote:

> Hi David,
>
> thanks, fixed in SVN 417. Unfortunately, as a consequence, it is no
> longer possible to pass a niladic function to an operator.
>
> /// Jürgen
>
>
>
> On 08/05/2014 09:39 AM, David B. Lamkins wrote:
>
>> Maybe I've misunderstood some APL2 corner case, but the behavior of the
>> attached program seems wrong.
>>
>>
>
>

Re: [Bug-apl] apl.xkb

[Blake McBride]

Great. Thanks!


On Tue, Aug 5, 2014 at 9:23 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:

> Hi Blake,
>
> I have copied your apl.wasd.kbd to the Dyalog keyboard folder, SVN 418.
> The file is now called apl.kbd everywhere and the folder tells which
> keyboard is meant.
>
>
> /// Jürgen
>
>
>
> On 08/01/2014 05:57 PM, Blake McBride wrote:
>
>> GNU APL comes with a file named apl.xkb under the support-files
>> directory.  I just did some testing of it with a normal (non-apl) keyboard.
>>  The mappings in that file are way out-of-date and do not match ]keyb
>> output.  That would also be true of the compiled version of that file -
>> apl.xkm.
>>
>> I then tested my WASD map file - apl.wasd.xkb.  That file correctly maps
>> a non-apl keyboard to map correctly with ]keyb output.
>>
>> Although my WASD config file was made for my WASD keyboard design, it
>> also completely correctly maps to non-APL keyboards too.
>>
>> I suggest that:
>>
>> 1.  support-files/apl.wasd.kbd be copied to apl.xkb
>>
>> 2.  remove apl.xkm
>>
>> 3.  Update the docs to use apl.xkb rather than apl.xkm (just substitute
>> apl.xkm with apl.xkb in README-3-keyboard
>>
>> Thanks.
>>
>> Blake
>>
>>
>

[Bug-apl] How to evaluate a block of source like a file?

[Elias Mårtenson]

Hello Jürgen,

What I mean by the somewhat mysterious subject is that I have had a request
to implement (or rather, improve) a feature in the Emacs Mode that allows a
user to evaluate all or part of a file.

Specifically, what is needed is a way for me to take a set of source lines
(usually a portion of a source .apl file) and pass it to some function that
will load execute those lines in exactly the same manner as if the content
had been saved to a file and then loaded using )COPY.

Ideally, I would also need the ability to specify the name of the file and
starting line number. This is so that the symbol metadata (filename and
line number) are correct in functions that are defined in this manner.

Would it be possible for you to implement a function that provides such
interface?

Regards,
Elias

[Bug-apl] Creating a new release

[Blake McBride]

Greetings,

Just a thought - it seems that Juergen is trying to create a new release of
GNU APL.  I think this is very important given the vast and critical
improvements since the last release.  i.e. people who just download the
last release rather than build from SVN are trying something that has way
too many problems.  They may leave new users of GNU APL with the wrong
impression.

I think it is to all our advantages to get a good release out.  To this
end, I propose we table many of the current discussions and focus only on
issues necessary for the new release.  Once the release is out, we can
re-visit all of these other great ideas.  Coming together to get the new
release out is important.

Just a respectful opinion.

Thanks.

Blake

Re: [Bug-apl] This looks wrong

[Juergen Sauermann]

Hi,

this is how I read the ISO standard. If a statement that is valid per 
ISO returns

a wrong result then I consider that a fault that should be (and was) fixed.

If that conflicts with an intended use of a non-standard extension like 
the ⍣ operator then I

would rate that as simply bad luck (as opposed to a fault).

/// Jürgen


On 08/05/2014 04:40 PM, Elias Mårtenson wrote:
Are you sure we want to fix that though? Things like the power 
operator (once we have it) will not work right (since it's seems to be 
often used to execute a niladic function a certain number of times.


The SQL∆WithTransaction will have the same problem.

The workaround seems to be a bit ugly, like prefixing the lambda 
function with ⍵⊢


Regards,
Elias


On 5 August 2014 22:07, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi David,

thanks, fixed in SVN 417. Unfortunately, as a consequence, it is no
longer possible to pass a niladic function to an operator.

/// Jürgen



On 08/05/2014 09:39 AM, David B. Lamkins wrote:

Maybe I've misunderstood some APL2 corner case, but the
behavior of the
attached program seems wrong.

Re: [Bug-apl] How to evaluate a block of source like a file?

[Juergen Sauermann]

Hi Elias,

I guess something like that exists already. Have look at
how *)LOAD***works for .*apl *files. There is a stack of file descriptors
for the files read by *Input* and you can push an open file descriptor 
onto it. The
only thing that doesn't work is to stop in the middle of a file (unless 
you insert

a *]NEXTFILE* command at that point.

/// Jürgen


On 08/05/2014 05:39 PM, Elias Mårtenson wrote:

Hello Jürgen,

What I mean by the somewhat mysterious subject is that I have had a 
request to implement (or rather, improve) a feature in the Emacs Mode 
that allows a user to evaluate all or part of a file.


Specifically, what is needed is a way for me to take a set of source 
lines (usually a portion of a source .apl file) and pass it to some 
function that will load execute those lines in exactly the same manner 
as if the content had been saved to a file and then loaded using )COPY.


Ideally, I would also need the ability to specify the name of the file 
and starting line number. This is so that the symbol metadata 
(filename and line number) are correct in functions that are defined 
in this manner.


Would it be possible for you to implement a function that provides 
such interface?


Regards,
Elias

Re: [Bug-apl] Creating a new release

[Juergen Sauermann]

Hi Blake, all,

thanks. I am almost ready with the *GNU APL 1.4* release.

I have updated the latest *SVN 420 *to be a *pre-1.4 release*.
Please have a look if it builds and installs on your platforms.

*SVN 420 *is not yet the official *1.4* GNU package, so build errors can 
still be fixed

before the official package is pushed to *ftp.gnu.org/gnu/apl/*

/// Jürgen


On 08/05/2014 05:47 PM, Blake McBride wrote:

Greetings,

Just a thought - it seems that Juergen is trying to create a new 
release of GNU APL.  I think this is very important given the vast and 
critical improvements since the last release.  i.e. people who just 
download the last release rather than build from SVN are trying 
something that has way too many problems.  They may leave new users of 
GNU APL with the wrong impression.


I think it is to all our advantages to get a good release out.  To 
this end, I propose we table many of the current discussions and focus 
only on issues necessary for the new release.  Once the release is 
out, we can re-visit all of these other great ideas.  Coming together 
to get the new release out is important.


Just a respectful opinion.

Thanks.

Blake

Re: [Bug-apl] Creating a new release

[David Lamkins]

Tested on one of my Fedora 20 systems, both by an update to my existing
work dir and a fresh SVN checkout. The build and install finished properly
in both cases. No surprises. :)

-- 
"The secret to creativity is knowing how to hide your sources."
   Albert Einstein


http://soundcloud.com/davidlamkins
http://reverbnation.com/lamkins
http://reverbnation.com/lcw
http://lamkins-guitar.com/
http://lamkins.net/
http://successful-lisp.com/

Re: [Bug-apl] Creating a new release

[Peter Teeson]

Checked out , built and tested on both OS X 10.8.5 and 10.9.4 with no errors or 
warnings (except that I do not have Postgres on 10.9.4).

On 2014-08-05, at 3:16 PM, David Lamkins  wrote:

> Tested on one of my Fedora 20 systems, both by an update to my existing work 
> dir and a fresh SVN checkout. The build and install finished properly in both 
> cases. No surprises. :)
> 
> -- 
> "The secret to creativity is knowing how to hide your sources."
>Albert Einstein
> 
> 
> http://soundcloud.com/davidlamkins
> http://reverbnation.com/lamkins
> http://reverbnation.com/lcw
> http://lamkins-guitar.com/
> http://lamkins.net/
> http://successful-lisp.com/

[Bug-apl] Remaining keyboard issues

[Blake McBride]

Greetings,

Looking at SVN 420, I question the following keyboard issues:

1.  with respect to support-files/Dyalog-keyboard

apl.xmodmap is missing mapping for the following characters:

χ
⍹
⍶
⍷
⍨
¥
⍸
⍣
⌷
⍥
¢
£
⍙

there may be others.

Please tell me if you would like me to fix this.

2.  The files in the support-files seem to be the old layout.  I thought
you were going to get rid of the files in that directory and use the
specific sub-directories instead.  Given the output of ]keyb and the docs
(README-3-keyboard), using the keyboard files in that directory will be
maximally confusing.

i.e. the docs say:

$ xmodmap support-files/apl.xmodmap

which provides the OLD layout.  The docs then say it will look like the NEW
layout.  They don't match at all.

I'd either get rid of the files in that directory or default them to what
is in the Dylog-keyboard directory.

Thanks.

Blake

Re: [Bug-apl] Remaining keyboard issues

[Blake McBride]

Attempting to fix apl.xmodmap, I discovered that the mapping for χ seems to
be correct, it just doesn't work for some reason.  Strange that just those
new characters give me a problem.  I don't get it.  Does anyone else?

Thanks.

Blake


On Tue, Aug 5, 2014 at 3:34 PM, Blake McBride  wrote:

> Greetings,
>
> Looking at SVN 420, I question the following keyboard issues:
>
> 1.  with respect to support-files/Dyalog-keyboard
>
> apl.xmodmap is missing mapping for the following characters:
>
> χ
> ⍹
> ⍶
> ⍷
> ⍨
> ¥
> ⍸
> ⍣
> ⌷
> ⍥
> ¢
> £
> ⍙
>
> there may be others.
>
> Please tell me if you would like me to fix this.
>
> 2.  The files in the support-files seem to be the old layout.  I thought
> you were going to get rid of the files in that directory and use the
> specific sub-directories instead.  Given the output of ]keyb and the docs
> (README-3-keyboard), using the keyboard files in that directory will be
> maximally confusing.
>
> i.e. the docs say:
>
> $ xmodmap support-files/apl.xmodmap
>
> which provides the OLD layout.  The docs then say it will look like the
> NEW layout.  They don't match at all.
>
> I'd either get rid of the files in that directory or default them to what
> is in the Dylog-keyboard directory.
>
> Thanks.
>
> Blake
>
>

[Bug-apl] Very small typo

[Blake McBride]

In apl.html, section 5.2, about SQL interface:  "nad" should be "and".

Re: [Bug-apl] Useful range of decode function is limited.

[Frederick H. Pitts]

Hello Juergen,

Thanks for the tweak to the decode function.  Preliminary testing
indicates that 63 bits of a 64-bit integer are usable.  For example

128 128 128 128 128 128 128 128 128 ⊤ ⎕ ← 128 ⊥ 127 127 127 127 127 127
127 127 127

yields

9223372036954775807 ⍝ NOTE this is greater than 920
127 127 127 127 127 127 127 127 127

Is this consistent with your expectations?

Regards

Fred

P.S.  I will send the binomial coefficient APL code in a separate email
and subject line for anyone that may have use for it.  Timing tests
indicate the code is 100 times slower than the primitive !, but then it
is correct up to the 920 limit.  Is it possible to speed
up the code by a factor 100 by re-implementing in C++ in the
interpreter?


On Tue, 2014-08-05 at 15:16 +0200, Juergen Sauermann wrote:
> Hi,
> 
> I have changed the decode function to stay longer in the integer domain, 
> SVN 416,
> 
> Not sure what is wrong with 2⋆63 - looks OK to me.
> 
> Note also that the largest integer in GNU APL (see ⎕SYL[20;]) is 
> 920
> and not 9223372036854775808 (and therefore 2⋆63 is outside that range). 
> The reason
> for that is that in order to detect integer overflow the check for 
> overflow itself is performed in
> double arithmetic (and subject to rounding errors). I therefore made the 
> integer range slightly
> smaller.
> 
> The accuracy of ! is a matter of an accuracy-speed trade-off. Computing 
> N! in 64-bit integer can
> take up to 20 multiplications while the float variant is probably faster.
> 
> /// Jürgen
> 
> 
> On 08/05/2014 06:45 AM, Frederick H. Pitts wrote:
> > Hello Elias,
> >
> > 1) "MOST-NEGATIVE-FIXNUM" and "largest negative integer" are much closer
> > in connotation to each other than either is to "smallest (negative)
> > integer".  "smallest" and "largest" are generally used when comparing
> > the magnitudes (or absolute values) of numbers irrespective of the signs
> > of those numbers.  So I think we are in agreement the label needs to
> > change.
> >
> > 2) 2*63 does not produce the right answer but 2*62 does.  So GNU-APL is
> > capable of doing integer arithmetic well outside the 53-bit integer
> > range of double precision floating point.  Unfortunately, that
> > capability is not fully utilized.  It's disingenuous to claim GNU-APL
> > supports 64-bit integer arithmetic when primitive operations like ⊥
> > (decode) and ! (binomial) yield results of accuracy limited by the
> > 53-bit integer range of floating point when they do not have to be.
> > There are ways to force the use of the use of the APL_Integer!  It's a
> > simple matter of programming.  If you are
> > interested I can supply you with defined functions that work around
> > the ! (binomial) accuracy limitation. (Jim Weigang presented the
> > functions in comp.lang.apl years ago). I wonder how much faster the
> > functions would be if they were implemented in C++.
> >
> > Regards,
> >
> > Fred
> >
> > On Tue, 2014-08-05 at 11:34 +0800, Elias Mårtenson wrote:
> >> Mathematically, the term "small" is ambiguous. Perhaps that's why
> >> Common Lisp names its corresponding value MOST-NEGATIVE-FIXNUM.
> >>
> >>
> >> That said, in GNU APL, these numbers are somewhat bogus anyway. In
> >> particular, the actual maximum number that can be stored without loss
> >> of precision depends on the underlying data type of the value.
> >>
> >>
> >> For real numbers, this data type can be either APL_Integer in which
> >> the largest number is 9223372036854775808 (2^63), but if you try to
> >> create this number in GNU APL using the expression 2⋆63, you will get
> >> an APL_Float back, which has a smaller maximum precise value
> >> of 9007199254740992 (2^53).
> >>
> >>
> >> So, in summary. You can never rely on integral numbers being precise
> >> to more than 53 bits of precision unless there is a way to force the
> >> use of APL_Integer which I don't believe there is.
> >>
> >>
> >> It would be nice to have support for bignums in GNU APL. It wouldn't
> >> be overly difficult to implement I think. Perhaps I'll try that one
> >> day unless Jürgen is completely against the idea.
> >>
> >>
> >> Regards,
> >> Elias
> >>
> >>
> >> On 5 August 2014 09:37, Frederick H. Pitts 
> >> wrote:
> >>  Juergen,
> >>  
> >>  Please consider the following:
> >>  
> >>( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 53 ⍴ 1
> >>  9007199254740991
> >>  0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> >>  1 1 1 1 1
> >>  1 1 1 1
> >>1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> >>( 62 ⍴ 2 ) ⊤ ⎕ ← 2 ⊥ 54 ⍴ 1
> >>  18014398509481984
> >>  0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >>  0 0 0 0 0
> >>  0 0 0 0
> >>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> >>  
> >>  Between 53 bits and 54 bits, decode starts returning
> >>

Re: [Bug-apl] Creating a new release

[Elias Mårtenson]

I would like to make a change to the Emacs communication protocol before
release, so if you could hold back for a day or so and then merge the
latest version of the native module that would be great.

Regards,
Elias
On 6 Aug 2014 00:44, "Juergen Sauermann" 
wrote:

>  Hi Blake, all,
>
> thanks. I am almost ready with the *GNU APL 1.4* release.
>
> I have updated the latest *SVN 420 *to be a *pre-1.4 release*.
> Please have a look if it builds and installs on your platforms.
>
> *SVN 420 *is not yet the official *1.4* GNU package, so build errors can
> still be fixed
> before the official package is pushed to *ftp.gnu.org/gnu/apl/
> *
>
> /// Jürgen
>
>
> On 08/05/2014 05:47 PM, Blake McBride wrote:
>
> Greetings,
>
>  Just a thought - it seems that Juergen is trying to create a new release
> of GNU APL.  I think this is very important given the vast and critical
> improvements since the last release.  i.e. people who just download the
> last release rather than build from SVN are trying something that has way
> too many problems.  They may leave new users of GNU APL with the wrong
> impression.
>
>  I think it is to all our advantages to get a good release out.  To this
> end, I propose we table many of the current discussions and focus only on
> issues necessary for the new release.  Once the release is out, we can
> re-visit all of these other great ideas.  Coming together to get the new
> release out is important.
>
>  Just a respectful opinion.
>
>  Thanks.
>
>  Blake
>
>
>

[Bug-apl] Binomial function with extended exact result range beyond that of primitive function

[Frederick H. Pitts]

Gentle people,

Please find attached binom.apl.tgz.  It contains the source for BINOM,
a defined function does what the primitive dyadic ! function does but
produces exact results over a larger range.

BINOM produces 1) the same results as ! over the range where !
produces exact integers, 2) exact integer results in range above that
produced by the ! but below the 920 upper limit of GNU
64-bit integers and 3) floating point results that match those of !
above the 64-bit integer upper limit.

In the interest of full disclosure:
1) The code is slow; 100 times slower than the primitive dyadic !.  But
then BINOM is interpreted while ! is compiled in to the interpreter.
2) The code was presented in 1996 on comp.lang.apl by Jim Weigang and
others.

Enjoy,

Fred
Retired Chemical Engineer


binom.apl.tgz
Description: application/compressed-tar

[Bug-apl] gnu-apl-mode: find-tag-marker-ring

[David B. Lamkins]

Elias,

This just started happening when using M-. :

let: Symbol's value as variable is void: find-tag-marker-ring

Result of (emacs-version) :

"GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.10.9)
 of 2014-05-20 on buildvm-07.phx2.fedoraproject.org"

Re: [Bug-apl] gnu-apl-mode: find-tag-marker-ring

[Elias Mårtenson]

Thanks. A fix has been comitted.

Regards,
Elias


On 6 August 2014 10:09, David B. Lamkins  wrote:

> Elias,
>
> This just started happening when using M-. :
>
> let: Symbol's value as variable is void: find-tag-marker-ring
>
> Result of (emacs-version) :
>
> "GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.10.9)
>  of 2014-05-20 on buildvm-07.phx2.fedoraproject.org"
>
>
>

Re: [Bug-apl] gnu-apl-mode: find-tag-marker-ring

[David B. Lamkins]

Thank you.

Confirmed working.

On Wed, 2014-08-06 at 10:11 +0800, Elias Mårtenson wrote:
> Thanks. A fix has been comitted.
> 
> 
> Regards,
> Elias
> 
> 
> On 6 August 2014 10:09, David B. Lamkins  wrote:
> Elias,
> 
> This just started happening when using M-. :
> 
> let: Symbol's value as variable is void: find-tag-marker-ring
> 
> Result of (emacs-version) :
> 
> "GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version
> 3.10.9)
>  of 2014-05-20 on buildvm-07.phx2.fedoraproject.org"
> 
> 
> 
> 

Re: [Bug-apl] gnu-apl-mode: find-tag-marker-ring

[Elias Mårtenson]

Thanks. Glad to have an issue reported to confirmed in about 5 minutes. :-)

Regards,
Elias


On 6 August 2014 10:14, David B. Lamkins  wrote:

> Thank you.
>
> Confirmed working.
>
> On Wed, 2014-08-06 at 10:11 +0800, Elias Mårtenson wrote:
> > Thanks. A fix has been comitted.
> >
> >
> > Regards,
> > Elias
> >
> >
> > On 6 August 2014 10:09, David B. Lamkins  wrote:
> > Elias,
> >
> > This just started happening when using M-. :
> >
> > let: Symbol's value as variable is void: find-tag-marker-ring
> >
> > Result of (emacs-version) :
> >
> > "GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+ Version
> > 3.10.9)
> >  of 2014-05-20 on buildvm-07.phx2.fedoraproject.org"
> >
> >
> >
> >
>
>
>

Re: [Bug-apl] gnu-apl-mode: find-tag-marker-ring

[David B. Lamkins]

I *was* gonna ask what took you so long... ;)

On Wed, 2014-08-06 at 10:16 +0800, Elias Mårtenson wrote:
> Thanks. Glad to have an issue reported to confirmed in about 5
> minutes. :-)
> 
> 
> Regards,
> Elias
> 
> 
> On 6 August 2014 10:14, David B. Lamkins  wrote:
> Thank you.
> 
> Confirmed working.
> 
> On Wed, 2014-08-06 at 10:11 +0800, Elias Mårtenson wrote:
> > Thanks. A fix has been comitted.
> >
> >
> > Regards,
> > Elias
> >
> >
> > On 6 August 2014 10:09, David B. Lamkins
>  wrote:
> > Elias,
> >
> > This just started happening when using M-. :
> >
> > let: Symbol's value as variable is void:
> find-tag-marker-ring
> >
> > Result of (emacs-version) :
> >
> > "GNU Emacs 24.3.1 (x86_64-redhat-linux-gnu, GTK+
> Version
> > 3.10.9)
> >  of 2014-05-20 on buildvm-07.phx2.fedoraproject.org"
> >
> >
> >
> >
> 
> 
> 
> 
> 

[Bug-apl] gnu-apl-mode: minor M-. issue

[David B. Lamkins]

This one probably doesn't affect many people.

If you define a function using ⎕FX without using the GNU APL extension
to store location metadata, a M-. on that function's name will complain:

if: Unexpected tag format: "⎕FX"

It might be nice if this said something like:

"This function was defined using ⎕FX; location information is
unavailable."

Re: [Bug-apl] gnu-apl-mode: minor M-. issue

[Elias Mårtenson]

Interesting. It seems that the tag gets set to ⎕FX when the function is
defined that way. I would have expected the tag to be blank.

Of course I can fix this on my end, but I'd like to know if this is
expected behaviour. Jürgen, do you have any input?

Regards,
Elias


On 6 August 2014 10:28, David B. Lamkins  wrote:

> This one probably doesn't affect many people.
>
> If you define a function using ⎕FX without using the GNU APL extension
> to store location metadata, a M-. on that function's name will complain:
>
> if: Unexpected tag format: "⎕FX"
>
> It might be nice if this said something like:
>
> "This function was defined using ⎕FX; location information is
> unavailable."
>
>

Re: [Bug-apl] gnu-apl-mode: minor M-. issue

[David B. Lamkins]

Take a look at Quad_FX.cc.

On Wed, 2014-08-06 at 10:36 +0800, Elias Mårtenson wrote:
> Interesting. It seems that the tag gets set to ⎕FX when the function
> is defined that way. I would have expected the tag to be blank.
> 
> 
> Of course I can fix this on my end, but I'd like to know if this is
> expected behaviour. Jürgen, do you have any input?
> 
> 
> Regards,
> Elias
> 
> 
> On 6 August 2014 10:28, David B. Lamkins  wrote:
> This one probably doesn't affect many people.
> 
> If you define a function using ⎕FX without using the GNU APL
> extension
> to store location metadata, a M-. on that function's name will
> complain:
> 
> if: Unexpected tag format: "⎕FX"
> 
> It might be nice if this said something like:
> 
> "This function was defined using ⎕FX; location information is
> unavailable."
> 
> 
> 

Re: [Bug-apl] Remaining keyboard issues

[Chris Jones]

On Tue, Aug 05, 2014 at 05:20:29PM EDT, Blake McBride wrote:

> Attempting to fix apl.xmodmap, I discovered that the mapping for
> χ seems to be correct, it just doesn't work for some reason.  Strange
> that just those new characters give me a problem.  I don't get it.
> Does anyone else?

I assume that "doesn't work" means that the χ is not echoed to the
terminal... AND that the cursor does not move to the right?

What happens when you temporarily remap χ (Chi/x03c7) to a different key
combo - one that is known to work..?  

... or conversely map a different character to the key combo you have
assigned to χ..?

CJ

Re: [Bug-apl] How to evaluate a block of source like a file?

[Elias Mårtenson]

Thanks, I've tried this and I'm having some problems. I'm probably not
doing things right.

I'm doing something similar to:

string filename = "/tmp/xyz";
int fd = open( filename.c_str(), O_RDONLY );
Workspace::load_DUMP( COUT, UTF8_string( filename ), handle, false );

The load seems to succeed, but none of the code in the file seems to be
executed.

What am I doing wrong here?

Or, should I be using InputFile directly?

Regards,
Elias


On 5 August 2014 23:57, Juergen Sauermann 
wrote:

>  Hi Elias,
>
> I guess something like that exists already. Have look at
> how *)LOAD* works for .*apl *files. There is a stack of file descriptors
> for the files read by *Input* and you can push an open file descriptor
> onto it. The
> only thing that doesn't work is to stop in the middle of a file (unless
> you insert
> a *]NEXTFILE* command at that point.
>
> /// Jürgen
>
>
>
> On 08/05/2014 05:39 PM, Elias Mårtenson wrote:
>
> Hello Jürgen,
>
>  What I mean by the somewhat mysterious subject is that I have had a
> request to implement (or rather, improve) a feature in the Emacs Mode that
> allows a user to evaluate all or part of a file.
>
>  Specifically, what is needed is a way for me to take a set of source
> lines (usually a portion of a source .apl file) and pass it to some
> function that will load execute those lines in exactly the same manner as
> if the content had been saved to a file and then loaded using )COPY.
>
>  Ideally, I would also need the ability to specify the name of the file
> and starting line number. This is so that the symbol metadata (filename and
> line number) are correct in functions that are defined in this manner.
>
>  Would it be possible for you to implement a function that provides such
> interface?
>
>  Regards,
> Elias
>
>
>