Re: [Bug-apl] Package metadata format

[Juergen Sauermann]

Hi Elias,

I believe so. For my taste there are to many [axes] which should 
be*⎕IO+'*ed to be portable.

How about this instead:

*  { ⊃1**↓**,((⊂⍺)≡¨ ,0 ¯1↓⍵)⌿⍵ }*

/// Jürgen


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

I wrote this function to print the value(s) of a given field:

  { (((⍺[;⎕IO]) ≡¨ ⊂⍵) /[1] ⍺)[;2] }

Could it be improved?

Regards,
Elias


On 3 August 2014 23:45, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Elias,

looks good!

/// Jürgen



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

OK, I changed the SQL.apl file. Looks OK?

https://github.com/lokedhs/apl-sqlite/blob/547c8191021629eb29b0bc141ff206766e1c21d3/SQL.apl#L134


Regards,
Elias


On 3 August 2014 21:29, Juergen Sauermann
mailto:juergen.sauerm...@t-online.de>> wrote:

Hi Elias,

yes, your's looks better, I will change that.
Lets call the function Z←package⍙metadata.

/// Jürgen



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

After implementing the metadata functions nnn⍙Provides,
nnn⍙Requires, etc, I feel that we should change this slightly.

I find the that multitude of functions to support this tend
to pollute the output of )FNS quite a bit. It's also
somewhat inflexible in that it requires you to add even more
functions as new features are added to the package system.

How about we change this so that only one function is used,
for example nnn⍙package_metadata or something like that? The
name matters less, but the point is that it's only a single
function.

I find this to be a lot cleaner.

As an example, for SQL, the content would be:

*  8⎕CR SQL⍙package_metadata*
┌→─┐
↓┌→─┐ ┌→──┐  │
││Author│   │Elias Mårtenson│  │
│└──┘ └───┘  │
│┌→───┐ ┌→──┐  │
││BugEmail│ │bug-apl@gnu.org │  
   │

│└┘ └───┘  │
│┌→───┐ ┌→┐│
││Download│ │https://github.com/lokedhs/apl-sqlite││
│└┘ └─┘│
│┌→──┐  ┌→───┐   │
││License│  │LGPL│   │
│└───┘  └┘   │
│┌→───┐ ┌→──┐  │
││Provides│ │SQL│  │
│└┘ └───┘  │
│┌→──┐  ┌→──┐  │
││Version│  │1.0│  │
│└───┘  └───┘  │
└∊─┘

Regrads,
Elias

[Bug-apl] gnu-apl-mode C-c C-h

[David Lamkins]

Elias, would you be willing to accept a patch to configure the comment
prefix in gnu-apl--find-documentation-for-defined-function? (I prefer ⍝
over ⍝⍝.)

-- 
"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] ERR function in APL2?

[Juergen Sauermann]

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] Another build error on OSX

[Juergen Sauermann]

Hi Elias,

I have changed ./configure to check this. SVN 415.

/// Jürgen


On 08/03/2014 06:01 PM, Elias Mårtenson wrote:
Apple is allergic to GPLv3, and I believe that they are shipping a 
stone-age version of it, just like they do for Emacs.


If these features are required, then I suggest checking for them in 
configure and if they are not there (i.e. the user have no upgraded 
readline manually) then simply disable it.


Regards,
Elias


On 3 August 2014 23:10, Juergen Sauermann 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Elias,

so where are these things defined? I doubt that we can
get readline with ^C working without.

/// Jürgen



On 08/03/2014 04:40 PM, Elias Mårtenson wrote:

Here's another error that prevents building on OSX. Hopefully we
can have this one fixed for 1.4:

g++ -DHAVE_CONFIG_H -I. -I.. -rdynamic   -g -MT NamedObject.o
-MD -MP -MF .deps/NamedObject.Tpo -c -o NamedObject.o NamedObject.cc
clang: warning: argument unused during compilation: '-rdynamic'
Input.cc:124:28: error: use of undeclared identifier 'rl_hook_func_t'
rl_startup_hook = (rl_hook_func_t *)(Input::init_readline_control_C);
   ^
Input.cc:124:44: error: expected expression
rl_startup_hook = (rl_hook_func_t *)(Input::init_readline_control_C);
   ^
Input.cc:409:4: error: use of undeclared identifier 'rl_crlf'
 rl_crlf();
   ^
Input.cc:410:4: error: use of undeclared identifier 'rl_delete_text'
 rl_delete_text(0, rl_end);
   ^
Input.cc:411:4: error: use of undeclared identifier 'rl_done'
 rl_done = 1;
   ^

Regards,
Elias

Re: [Bug-apl] Can't break out of the middle on a display operation

[Juergen Sauermann]

Hi Elias,

I have changed the max. interval from 500ms to 1 second. SVN 415.

I believe changing to single ^C via configuration would be more confusing
than helpful because the behavior under emacs (i.e. INTERRUPT = 
ATTENTION) would deviate

from the behavior outside emacs (INTERRUPT ≠ ATTENTION).

/// Jürgen


On 08/03/2014 03:48 PM, Elias Mårtenson wrote:


Control-C is a general prefix character in Emacs. In other words, you 
press C-c followed by another keypress to execute a given function. 
C-c C-c (i.e.  Control-C twice) is defined to send a single control-c 
to an underlying process (it's part of the framework that manages 
external programs, of which apl is one).


Of course, nothing prevents me from adding other keypresses that are 
mapped to, say, sending a double C-c to the underlying process, but it 
wouldn't really mesh very well with how embedded programs usually works.


That said, it's possible to send four C-c's in half a second. All I 
have to do is to hold C-c for a while and let the operating system's 
key repeat do its job. So, in a worst case scenario I just won't 
change anything at all. ☺


On 3 Aug 2014 21:19, "Juergen Sauermann" 
mailto:juergen.sauerm...@t-online.de>> 
wrote:


Hi Elias,

mapping two ^C to one is maybe not so good an idea.

IBM APL2 distinguishes between interrupt and attention and they have
different keys for that. interrupt interrupts execution
immediately while
attention interrupts execution at the end of the statement.

Currently GNU APL is behaving slightly differently, but the plan
is to align that long term.

Instead of two keys for interrupt and attention I found it more
convenient to have single ^C for attention
and double ^C for interrupt.

This is also why two ^C are needed to abort the display of results.

If you eat single ^C in emacs then this would prevent attention
from being signaled.
I would propose instead that every ^C is simply passed on to GNU APL.

/// Jürgen


On 08/02/2014 06:29 PM, Elias Mårtenson wrote:

Do you think there is a way to configure that? Perhaps disable
the double-thing when in Emacs mode? The reason is that in Emacs
mode you already have to press C-c twice to send a sinvlde C-c to
the underlying process. That means that in order to interrupt
right now I need to press it 4 times within 500 ms, which is very
difficult.

Regards,
Elias


On 3 August 2014 00:27, Juergen Sauermann
mailto:juergen.sauerm...@t-online.de>> wrote:

Hi Blake,

good. The double ^C is on purpose to avoid accidentally
hitting ^C.

Its actually two ^C within 500 ms.

/// Jürgen

[Bug-apl] build warning on OSX

[Peter Teeson]

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

[Bug-apl] gnu-apl-mode, Unix domain socket, and process buffer?

[David Lamkins]

Elias,

When running gnu-apl-mode with a Unix domain socket for connection to
libemacs, does there really need to be a buffer (*gnu-apl-connection*) for
the process? There isn't a buffer if the connection is via TCP.

-- 
"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] Can't break out of the middle on a display operation

[Elias Mårtenson]

Thank you. I think this will work better.

Regards,
Elias
On 5 Aug 2014 01:50, "Juergen Sauermann" 
wrote:

>  Hi Elias,
>
> I have changed the max. interval from 500ms to 1 second. SVN 415.
>
> I believe changing to single ^C via configuration would be more confusing
> than helpful because the behavior under emacs (i.e. INTERRUPT = ATTENTION)
> would deviate
> from the behavior outside emacs (INTERRUPT ≠ ATTENTION).
>
> /// Jürgen
>
>
> On 08/03/2014 03:48 PM, Elias Mårtenson wrote:
>
> Control-C is a general prefix character in Emacs. In other words, you
> press C-c followed by another keypress to execute a given function. C-c C-c
> (i.e.  Control-C twice) is defined to send a single control-c to an
> underlying process (it's part of the framework that manages external
> programs, of which apl is one).
>
> Of course, nothing prevents me from adding other keypresses that are
> mapped to, say, sending a double C-c to the underlying process, but it
> wouldn't really mesh very well with how embedded programs usually works.
>
> That said, it's possible to send four C-c's in half a second. All I have
> to do is to hold C-c for a while and let the operating system's key repeat
> do its job. So, in a worst case scenario I just won't change anything at
> all. ☺
> On 3 Aug 2014 21:19, "Juergen Sauermann" 
> wrote:
>
>>  Hi Elias,
>>
>> mapping two ^C to one is maybe not so good an idea.
>>
>> IBM APL2 distinguishes between interrupt and attention and they have
>> different keys for that. interrupt interrupts execution immediately while
>> attention interrupts execution at the end of the statement.
>>
>> Currently GNU APL is behaving slightly differently, but the plan is to
>> align that long term.
>>
>> Instead of two keys for interrupt and attention I found it more
>> convenient to have single ^C for attention
>> and double ^C for interrupt.
>>
>> This is also why two ^C are needed to abort the display of results.
>>
>> If you eat single ^C in emacs then this would prevent attention from
>> being signaled.
>> I would propose instead that every ^C is simply passed on to GNU APL.
>>
>> /// Jürgen
>>
>>
>> On 08/02/2014 06:29 PM, Elias Mårtenson wrote:
>>
>> Do you think there is a way to configure that? Perhaps disable the
>> double-thing when in Emacs mode? The reason is that in Emacs mode you
>> already have to press C-c twice to send a sinvlde C-c to the underlying
>> process. That means that in order to interrupt right now I need to press it
>> 4 times within 500 ms, which is very difficult.
>>
>>  Regards,
>> Elias
>>
>>
>> On 3 August 2014 00:27, Juergen Sauermann 
>> wrote:
>>
>>>  Hi Blake,
>>>
>>> good. The double ^C is on purpose to avoid accidentally hitting ^C.
>>>
>>> Its actually two ^C within 500 ms.
>>>
>>> /// Jürgen
>>>
>>>
>>>
>>
>>
>

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

[Frederick H. Pitts]

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] Useful range of decode function is limited.

[Elias Mårtenson]

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] gnu-apl-mode, Unix domain socket, and process buffer?

[Elias Mårtenson]

Of course. I'm using make-network-process to open the Unix Domain socket
connection, and I had just casually passed in the name of a buffer,
thinking that it was required. Of course it isn't (as I figured out reading
the documentation a bit more), so I've fixed it.

Thanks.

Regards,
Elias


On 5 August 2014 07:22, David Lamkins  wrote:

> Elias,
>
> When running gnu-apl-mode with a Unix domain socket for connection to
> libemacs, does there really need to be a buffer (*gnu-apl-connection*) for
> the process? There isn't a buffer if the connection is via TCP.
>
> --
> "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] gnu-apl-mode, Unix domain socket, and process buffer?

[David Lamkins]

Only reason I noticed it is because the extra buffer interfered with
tab-completion for *gnu-apl*...


Thanks!


On Mon, Aug 4, 2014 at 8:41 PM, Elias Mårtenson  wrote:

> Of course. I'm using make-network-process to open the Unix Domain socket
> connection, and I had just casually passed in the name of a buffer,
> thinking that it was required. Of course it isn't (as I figured out reading
> the documentation a bit more), so I've fixed it.
>
> Thanks.
>
> Regards,
> Elias
>
>
> On 5 August 2014 07:22, David Lamkins  wrote:
>
>> Elias,
>>
>> When running gnu-apl-mode with a Unix domain socket for connection to
>> libemacs, does there really need to be a buffer (*gnu-apl-connection*) for
>> the process? There isn't a buffer if the connection is via TCP.
>>
>> --
>> "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/
>>
>
>


-- 
"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] gnu-apl-mode, Unix domain socket, and process buffer?

[Elias Mårtenson]

Just bind a key to the function gnu-apl. If there is already a session
open, it will switch to that one. :-)

Regards,
Elias


On 5 August 2014 12:26, David Lamkins  wrote:

> Only reason I noticed it is because the extra buffer interfered with
> tab-completion for *gnu-apl*...
>
>
> Thanks!
>
>
> On Mon, Aug 4, 2014 at 8:41 PM, Elias Mårtenson  wrote:
>
>> Of course. I'm using make-network-process to open the Unix Domain socket
>> connection, and I had just casually passed in the name of a buffer,
>> thinking that it was required. Of course it isn't (as I figured out reading
>> the documentation a bit more), so I've fixed it.
>>
>> Thanks.
>>
>> Regards,
>> Elias
>>
>>
>> On 5 August 2014 07:22, David Lamkins  wrote:
>>
>>> Elias,
>>>
>>> When running gnu-apl-mode with a Unix domain socket for connection to
>>> libemacs, does there really need to be a buffer (*gnu-apl-connection*) for
>>> the process? There isn't a buffer if the connection is via TCP.
>>>
>>> --
>>> "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/
>>>
>>
>>
>
>
> --
> "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] gnu-apl-mode C-c C-h

[Elias Mårtenson]

Actually, not really. The choice of prefix character has been discussed in
a few separate threads here, and we finally seems to have settled on the
use of two lamps at the beginning for the function to indicate Doxygen
documentation.

If you want to use a different style for your own code, I'd suggest that
you take the existing code, modify it under a different name and use that
one instead. This is in order to avoid further incompatibilities when/if
markdown support is added for the documentation blocks.

Regards,
Elias


On 5 August 2014 01:02, David Lamkins  wrote:

> Elias, would you be willing to accept a patch to configure the comment
> prefix in gnu-apl--find-documentation-for-defined-function? (I prefer ⍝
> over ⍝⍝.)
>
> --
> "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] VAX APL at Bitsavers

[Elias Mårtenson]

I was casually browsing the Bitsavers archive and I came across these two
manuals for VAX APL. There is some interesting information in there,
especially relating to how a user session was conducted in 1991 using the
DEVwindows client.

https://archive.org/details/bitsavers_decvaxlangsersGuideJun91_22812555
https://archive.org/details/bitsavers_decvaxlangnstallationGuideJan90_3170871

Regards,
Elias

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

[Elias Mårtenson]

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] Useful range of decode function is limited.

[Frederick H. Pitts]

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] gnu-apl-mode C-c C-h

[David Lamkins]

OK. No worries. That's why I asked first. :)


On Mon, Aug 4, 2014 at 9:30 PM, Elias Mårtenson  wrote:

> Actually, not really. The choice of prefix character has been discussed in
> a few separate threads here, and we finally seems to have settled on the
> use of two lamps at the beginning for the function to indicate Doxygen
> documentation.
>
> If you want to use a different style for your own code, I'd suggest that
> you take the existing code, modify it under a different name and use that
> one instead. This is in order to avoid further incompatibilities when/if
> markdown support is added for the documentation blocks.
>
> Regards,
> Elias
>
>
> On 5 August 2014 01:02, David Lamkins  wrote:
>
>> Elias, would you be willing to accept a patch to configure the comment
>> prefix in gnu-apl--find-documentation-for-defined-function? (I prefer ⍝
>> over ⍝⍝.)
>>
>> --
>> "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/
>>
>
>


-- 
"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] Useful range of decode function is limited.

[Elias Mårtenson]

Your observations are all correct. The behaviour you see are because GNU
APL values can be either integers (backed by a 64-bit integral value) or
floating point (backed by a C++ double value). Conversions between these
two underlying storage formats are transparent to the user most of the time.

*I know you are probably aware of most of the following, but I'm just
summarising to ensure that we're all on the same page:*

This conversion can come back and bite you when you are doing arithmetic in
the border region between 2^53 and 2^63. Look at this somewhat unexpected
behaviour for example:

*  y ← 2⋆62*
*  y*
4611686018427387904
*  y+1*
4611686018427387905  *⍝ OK, accurate*
*  y+1.1*
4611686018427387904  *⍝ Add a larger value but get a smaller result?*
*  y+10.1*
4611686018427387904  *⍝ OK, this seems really weird*

The reason for this is of course that as soon as you introduce non-integral
numbers, the implementation falls back to floating point. Common Lisp does
exactly the same thing for this example by the way.

Now, as for the actual issue you are observing, I believe I have a good
explanation of what you are seeing. Let's look at the implementation of
decode.

We can see in the code that the actual computation is being done with
values of type APL_Complex. This type has the following definition:

typedef std::complex APL_Complex;

Thus, the actual calculation is being performed with C++ double values.

After the computation is done, the value is converted back to either an
APL_Float or APL_Integer depending on the magnitude of the value.

Finally, here's the code for the decode function for reference:

Bif_F12_DECODE::decode(Cell * cZ, ShapeItem len_A, const Cell * cA,
   ShapeItem len_B, const Cell * cB, ShapeItem dB,
   double qct)
{
APL_Complex value(0.0, 0.0);
APL_Complex weight(1.0, 0.0);
uint32_t len = len_A == 1 ? len_B : len_A;

   cA += len_A - 1; // point to the lowest item in A
   cB += dB*(len_B - 1);// point to the lowest item in B
   loop(l, len)
  {
value += weight*cB[0].get_complex_value();
weight *= cA[0].get_complex_value();
if (len_A != 1)   --cA;
if (len_B != 1)   cB -= dB;
  }

   if (value.imag() > qct)
  new (cZ)   ComplexCell(value);
   else if (value.imag() < -qct)
  new (cZ)   ComplexCell(value);
   else if (Cell::is_near_int(value.real(), qct))
  new (cZ)   IntCell(value.real(), qct);
   else
  new (cZ)   FloatCell(value.real());
}

Regards,
Elias


On 5 August 2014 12:45, 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
> >