[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Formatting of large arrays

From: Juergen Sauermann
Subject: Re: [Bug-apl] Formatting of large arrays
Date: Wed, 1 Feb 2017 13:56:55 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0


done in SVN 873.

/// Jürgen

On 02/01/2017 01:25 PM, Juergen Sauermann wrote:
Hi Elias,

first of all, ⎕CR cannot possibly know what ⎕PW means. It produces an APL text matrix from an APL value.
The rules for doing this were basically fixed by IBM through a workspace called DISPLAY which is shipped
with the IBM interpreter. I found that workspace quite handy and wanted it to be a built-in function rather than
a workspace that you need to )COPY before using it. But I would not like to make it too different from the
original DISPLAY workspace for compatibility reasons. As you know, IBM compatibility rules for GNU APL.

But the proposal for limiting ]BOXING sounds feasible. In order to not create incompatibilities with previous
versions of GNU APL I would like to propose that we use negative ]BOXING numbers for not-boxing large arrays
and positive ones for the current way of printing the output.

I will look into this.

/// Jürgen

On 02/01/2017 10:16 AM, Elias Mårtenson wrote:
On 1 February 2017 at 03:22, Juergen Sauermann <address@hidden> wrote:

actually ⎕PW is considered after ⎕CR. ⎕CR of a single line creates a 3 line APL matrix:

OK, that explains the behaviour.

So the problem is that ⎕CR doesn't pay attention to ⎕PW at all.
The problem with this is that it is not properly working recursively. If a sub-item is also a large matrix and
wrapped at ⎕PW then it wont fit into the containing matrix. An boxed output is normally only used when
you have problems with nested values, so the sub-items are almost always nested.

Sure, that would be a problem if the rendering of an inner cell works completely independently of the outer content which seems to be how the current version is implemented.

I guess fixing this would require rewriting all of the ⎕CR rendering in order to create something similar to the table layout engine in a browser. That sounds like lots of work and also very complex.

As an alternative, I'd be happy if, when using ]BOXING, the output function could notice that the output from ⎕CR was wider than ⎕PW and if so, simply disable the boxed output and fall back to the default which is at least usable.

This proposal would at least make ]BOXING more useful since boxed output that overflows ⎕PW is almost completely useless (for example, try 29⎕CR ⍳1000), while the non-boxed output is perfectly usable.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]