An update on the Jig visuals

A couple of changes based on valuable feedback by Raul Miller and David Leibs and a quick note based on a comment by John Baker.

First the note: I should be clear that Jig at this point is not a working prototype but is in a design phase. It seems to me that there are three distinct aspects to this development. The design of the output is what I have focussed on here, but as well there is the generation of the information to create that output and the actual execution that will display the output. I am using Keynote in this design phase and will be moving back into the other two phases when I feel that the output is adequately defined. The next step will be using J to create the information needed using display foreigns 5!:1 and 5!: 6 for order of execution and and container level as well as type foreigns to indicate the appropriate colouring and shading of the nodes/containers. The second step will be to convert this information into an SVG element that will display the visual within a JHS environment.

JigContainerAmbiPrevious visual display of ambivalent verb in Jig

 

Screen Shot 2014-08-09 at 10.55.55 AMNew visual display of ambivalent verb in Jig

Based on the feedback of Raul and David, it became clear that although the topographic version would contain the necessary information, it may not display in as accessible a manner (specifically the fact that it was colour driven and that it is difficult to accommodate shading differences on that scale). David suggested more inline on the set container and by reducing the sizes I can still retain the correspondence with the sentence. Longer sentences would need to be accommodated by sliders to move the window or by zooming. That is in the display execution layer, but I think it is achievable.

For now I am happier with the results and look forward to more comments for further refinement.

An Update on Display Shapes and Types on JHS

Based on some consistent and clear comments from a number of J’ers I respect greatly, I have made some adjustments to the way that the HTML and CSS affect the display on JHS. Primarily I am not showing atoms as enclosed except for the case of literals where the blank spaces are important to the array display in ways that the numeric types are not. I instead use colour and font to distinguish between the types. In the case of shapes I really now only display the single and zero dimensions as a visible envelope around the atoms. This results in a much less noisy display.

I went into these changes thinking that this might be difficult to do, but found instead that by using CSS that a lot of the display changes are isolated from the structure that I have built using J to form the HTML. The script is available as an attachment to the page:

http://www.jsoftware.com/jwiki/BobTherriault/Visualize

under the name vlitejwiki.ijs

and below is a 3 minute video giving you an idea what to expect

Using CSS and HTML to display the shapes of arrays on the JHS platform

The following video will provide an idea of how HTML and CSS can be used to more clearly show the shapes of arrays on the JHS platform. This includes arrays with zero valued dimensions and arrays with single valued dimensions that would be displayed ambiguously in the text based format.

If you have not already viewed the preceding blog post on displaying different types of J variable, it may be worthwhile to take a look at it here. There is a brief review of types in this shape video but it does not cover the information in any great detail.

Using HTML and CSS to view Types in the JHS platform of J

Time flies when you are having fun, or maybe just time flies as I look back to how long it is since I have posted here. In any case I am back and ready to explore some new developments in the way that I am using the JHS platform of J.

One of the things that has frustrated me with J is that at times I spend a lot of time trying to figure out problems based on simple (and incorrect) assumptions I have about the information that I am being shown. J has an elegantly minimalistic way of showing the results of operations in its interactive environment. Unfortunately, it does not always distinguish between certain key qualities when it displays its results. It becomes my job as a programmer to confirm what I am seeing as what is really being presented and this is especially true for type information. With modern web browsers it has become possible to provide this additional information as part of the results and this is explored in the following video.

Since there was not enough time to go into all the details the screens below provide some of the background to the css and elements of html that are created in order to provide the new html based display. I provide this information for all to use and only ask that if you use it that in your best judgement you use it in a mindfully positive way.

Types

I hope to follow up in a week with the HTML and CSS approaches I have explored to display differently shaped arrays unambiguously, but last time I said that resulted in almost two years between posts. 🙂

Augmented View of Arrays (Redux)

Follow-up:

After looking back at the previous post I did notice one mistake. The shape for the following diagram should have been 1 2 3 instead of 2 3. If the shape had been 2 3 then the diagram would have had a plane rather than a cube as the ‘shape structure’.

 1 2 3 $ 0

Augmenting Frank’s Dual-View Representation by Simplifying:

After several weeks of reflection, I realized that the previous solution to visualizing Frank’s Dual-View could be made simpler  by displaying the absence of edges when there are zero valued dimensions in the shape. The following post will compare the two options with a following critique of the differences.

Case 0 – Empty shape for scalar value – Shape ’empty’

 

Old version

New version

Critique: The only difference here is colour to distinguish the two approaches as we move forward. Remember that scalar values in J do not have a shape of 0, but instead have a shape that is an empty list. Since there is no 0 in an empty list there is no change in representation of scalars.

Case 1 – A list of zero items – Shape 0

 

Old version

New version

Critique: Both versions have the axle indicating that this is a list and that items can be added. Both versions are also greyed out as a visual cue that this is an empty list. The new version shows that the dimension that is zero is along the x axis (the only axis, as indicated by the axle) and so this is an empty list, as opposed to an empty matrix or cube which we will see later. Even though this adds an element in the visualization of an empty array, it will provide a more simple representation of non-empty arrays.

Case 2 – A list of one item – Shape 1

 

Old version

New version

Critique: This is where the advantage of the new approach starts to appear. Instead of the extra horizontal line, only the line presenting the one dimensional shape is included. The colour indicates that the shape is non-zero immediately.

Case 3 – A matrix of one item – Shape 1 1

 

Old version

New version

Critique: The advantage continues as the plane immediately indicates the two dimensional shape and the single sphere indicates only one item. No extra lines required for the vast majority of arrays which are non-empty.

Case 4 – A cube of one item – Shape 1 1 1

 

Old version

New version

Critique: Again we have a single atom and the surrounding cube indicates three dimensions. The extra edges in the previous version are not required which really cleans up the display

Case 5 – A matrix of one item – Shape 0, Shape 0 1, and Shape 1, 0

 

Shape 0

Shape 0 1

Shape 1 0

Critique: The displays of these three empty arrays show that the one dimensional and two dimensional are clearly distinguishable, as is the difference between Shape 0 1 and Shape 1 0 matrices.

Case 6 – A cube of shape 1 2 3

 

Old version

New version

Critique: The spacing of the spheres easily shows the shape of the array and the enclosing cube outline immediately shows that the array has a three dimensional shape. If it were two dimensions the spheres would be embedded in a two dimensional plane. Again no more and no less than what is required to differentiate and describe the shape.

Case 7 – A cube of shape 0 2 3

Critique: This one was thrown in to show how a zero value in the leading axis of a three dimensional array would look. There are two rows and three columns of zero items which is why the spheres are greyed out with a front facing zero mark on the z axis. Contrast this with the 1 2 3 shape described in the preceding example.

Case 8 – A cube of shape 2 2 3

 

Old version

New version

Critique: I think that I may want to play around with the spacing on this one as this is one case where the new representation actually seems more confusing than the old version. Part of it may be the inherent structure that the extra edges provide, but I think this can be made up by using the spacing to reveal the relationships between the spheres as rows and columns. The text version of J uses this spacing to great effect, so I feel I am moving the right direction even though this version feels relatively unorganized.

In closing:

This time I promise; the next post will look at the representation of higher ranked arrays. I was happy to spend the extra time revising the display, as the higher dimensional representations really benefit from the cleaner look.  Until next time, I look forward to any feedback you may have.

Augmenting the Dual-View Array Representation

Follow Up:

My previous post included a verb to facilitate visualization of the Dual-View representation by returning coefficients representing array components:

   arrayCoeff =: +//.@(*/)/@,.&1

Unfortunately, this verb fails for scalars because it can’t deal with the empty list shape of rank 0 arrays.

   arrayCoeff ''
|domain error: arrayCoeff
|       arrayCoeff ''

A better solution has the array itself as the argument, then determines its shape and triggers an exception when dealing with scalars.

   arrayCoeffS =: +//.@(*/)/@,.&1`1:@.(''&-:)@$

where

 (''&-: )@$

returns 1 for a scalar argument.

   arrayCoeffS 4  NB. Scalar, array rank 0, shape ''
1
   arrayCoeffS 3 $ 4 NB. Vector, array rank 1, shape 3
3 1
   arrayCoeffS 2 3 $ 4 NB. Matrix, array rank 2, shape 2 3
6 5 1

Augmenting Frank’s Dual-View Representation:

This will allow arrays of shape 0 and shape 0 1 to be shown as distinct.
The Dual-View shows these shapes as identical because rank 2 can’t be represented by a single edge.

   arrayCoeffS 0$0 NB. Empty list of rank 1
0 1 

   arrayCoeffS 0 1$0 NB. No list of length 1 (rank 2)
0 1 1

Clearly they differ in the rank 2 array’s planar component, and changing the orientation of the single edge to indicate the plane is identical to the result of:

   arrayCoeffS 1 0$0 NB. One list of length 0 (rank 2)
0 1 1 

The way forward is to display the rank of the array even when the zero valued axes are not present. With distinguishable ranks, rank 1 and 2 arrays will be distinct. For rank 0 (scalar), the representation is the disk alone.

   arrayCoeffS 2 NB. Scalar value of 2 (rank 0)
1 

Arrays of rank 1 have a horizontal line through the disk indicating that the list can add items either before or after the value. If the shape is 0, only this rank line is shown with an empty value – a greyed out disk.

A non-zero axis uses thicker edges with rank line extended.

Rank 2 arrays indicate rank as an x-y plane encompassing the disk, allowing axes indication without affecting rank representation.

With rank 3 the embedding structure is a cube, with potential axes in three dimensions.

By including the rank information the augmented Dual-View shows previously indistinguishable arrays distinctly:

   0$0 

   0 1 $ 0 

   1 0 $ 0 

While typical arrays display as expected.

   2 3 $ 0 

   2 2 3 $ 0 

In the next post I will look at the representation of higher ranked arrays. Until then, I look forward to any feedback you may have.

The ‘Dual-View’ approach to array visualization

Previously, we found the J text representation revealed values of individual atoms, but could not distinguish singleton arrays of different shapes, or empty arrays. Ron Frank in his paper, “A New “Dual-View” Diagram of Array Structure” (Frank, 2003) describes “Dual-View”, applying combinatorics to enumerate the atoms, lists, planes and cubes and representing them with dots and edges.

For example, an array of shape 2 3 4 has 2 * 3 * 4 = 24 atoms (T00); (2*3)+(3*4)+(2*4)=26 edges (T01); 2 + 3 + 4 = 9 planes (T02); and 1 cube (T03).

Edges and dots indicate planes and cubes by sketching the array in three dimensions. Collinear segments count as only one edge, so the diagram above has 24 dots for atoms, 26 edges for lists (12 aligned vertically, eight horizontally, and six along the z axis), nine planes (two parallel to the x-z plane, four parallel to the x-y plane and three parallel to the y-z plane), in a three dimensional brick.

This monadic J verb produces these coefficients given the shape of the array by stitching 1 to items of the shape, then cross multiplying (2 1) ⊗ (3 1) ⊗ (4 1) to produce coefficients.

   arrayCoeff =: (+//.@(*/))/@,.&1 
   arrayCoeff 2 3 4
24 26 9 1

For single valued arrays the added edges create distinct representations.

   arrayCoeff 1
1 1

   arrayCoeff 1 1
1 2 1

   arrayCoeff 1 1 1
1 3 3 1

Empty arrays have at least one zero in their shape. The list with shape zero is represented by a single edge with no dot as predicted.

   arrayCoeff 0
0 1


For higher ranked arrays, edges indicate placement of planes and cubes.

   arrayCoeff 2 3 0
0 6 5 1

Above we see an array of shape 2 3 0 with two planes parallel to the z-x plane (two pairs of three edges) and three planes parallel to the z-y plane (three groups of two).This representation conveys the empty array of shape 2 3 0 distinctly. A previous post illustrated that distinct orientations can represent shape permutations.

When more than one item in the shape is zero, for example shape 0 2 0, difficulties with the “Dual-View” crop up.

   arrayCoeff 0 2 0
0 0 2 1

As before we have zero atoms, but we also have zero edges – an invisible representation, making it impossible to distinguish arrays with more than one zero in their shape. In the next blog post I’ll introduce augmentations to the “Dual-View”, and although this improves the representation of array shapes, I must say the J text representation remains best for showing values of atoms.

References:

Frank, Ronald I. (2003). A New ‘Dual View’ Diagram of Array Structure,
Proceedings of the ACM APL (SIGAPL), Federated Computer Research Conference (October 2003). ISBN 1 58113 668 4.

Singletons and Wide Open Spaces

In good representations, similar things will look alike and distinct things will look different. In great representations, good representations combine with metaphor to create meaning. The metaphor used in J is the array. If you are not sure of J’s approach to rank, shape, or item then take a look at the previous post, otherwise let’s dive right into the spot that the J text representation breaks down. If we have an array with rank 1 and shape 1, it would look like this:

   A1=: 1 $ 4
   A1

4

And if we had an array with rank 2 and shape 1 1:

   A11=: 1 1 $ 4
   A11

4

And if we had an array with rank 3 and shape 1 1 1, it would look like this:

   A111=: 1 1 1 $ 4
   A111

4

Now using the “Shape Of” monadic verb ($) it is easy to get the shape information we want:

   $ A1

1
   $ A11

1 1
   $ A111

1 1 1

But if we only consider the representation, we find that things that are different look the same, which is a problem. Taking it one step further, let’s look at an atom. This particular atom is an integer:

   A=: 4
   A

4
   $ A



Atoms are arrays with an empty shape, and in this representation they look like other singleton arrays. The empty line represents the atom’s empty shape, but as innovative as this approach is, we still can’t discern single value arrays from atoms or one another.

To be fair, it is not only the J representation that has this problem. Looking at the block representation:

Single lego block

We notice that a single block could be a list of shape 1, or a table of shape 1 1, or a brick of shape 1 1 1. In fact, we are even at a bigger disadvantage with the block representation because an atom such as A would look like this:

No lego blocks

Or maybe perhaps the atom would be colour without the block, since the block has an empty shape. At least J can show us the value of the atom.

The second area where the J representation breaks down is how it shows empty arrays. An empty array is an array that has a zero (sometimes more than one) within its shape. If we create an empty array of shape 0 we’ll see the challenge of representation:

   A0=: 0 $ 2
   A0


   $ A0

0

which means that A0 displays as an empty line (a list with 0 length), and the shape of A0 is 0. This is a good representation as far as it goes, but it gets complicated with rank 2 arrays:

   A00=: 0 0 $ 2
   A00
   $ A00

0 0

Here, the shape 0 0 means no lists of length 0 and the empty line disappears. This suggests a difference between arrays of shape 0 and shape 0 0 which is good, but when we look at an array of shape 1 0, our one empty line returns:

   A10=: 1 0 $ 2
   A10

   $ A10

1 0

But an array of shape 0 1 looks identical to an array of shape 0 0:

   A01=: 0 1 $ 2
   A01
   $ A01

0 1

And if we think the problem is with J’s text limitations, with physical objects, representing empty arrays becomes quite impossible. We could make a zen koan about showing the shapes of things that are not there, but it would still not make the representation any clearer.

No lego blocks

In the last two blog posts we have developed language to describe arrays, and used that language to show the problems with both J’s text representation and a block representation. The next post will be about a visualization method which solves some of these array representation problems. In the meantime, any response that you have is welcome; either about the presentation style for these ideas or regarding the ideas themselves.

Looking at Arrays

In good representations, similar things will look alike and distinct things will look different. In great representations, good representations combine with metaphor to create meaning. The metaphor used in J is the array. If you are aware of J’s approach to rank, shape, or item then skip ahead to the next blog entry, otherwise read on.

Row of three lego blocks

Here we have three blocks in a row. This array has three items and its shape is 3.

Using the J text representation we’d show it this way:

   A3=: 3 $ 5 6 7

where $ is the dyadic verb “Shape” that takes the right argument and makes it into the shape specified by the left argument. The =: is the assignment operator that assigns the result to the variable we have called A3:

   A3

5 6 7

We have A3 representing three numbers in an array (list) of shape 3. J can tell us this using the monadic form of $ known as “Shape Of”:

   $ A3

3

Two rows of three lego blocks

This one has two rows of three blocks suggesting that the shape is 2 3. We could also think of this array as two items, where each item is a row of three blocks. The same array in J would look like this:

   A23=: 2 3 $ 5 6 7 8 9 10
   A23
 
5 6 7
 
8 9 10
   $ A23

2 3

In J is the number of items in an array is the first item in the shape (yes the shape is an array as well and it has items). J uses the monadic verb “Tally” (#) to return the number of items in an array:

   $ A3

3
   # A3

3
   $ A23

2 3
   # A23

2

A big difference between the shapes of A3 and A23 is that the shape of A3 has 1 item and the shape of A23 has 2 items. This idea of the number of items in the shape is interesting enough that we give it its own name: rank. So A3 has rank 1 and A23 has rank 2. In J we can find this by using the monadic verb # “Tally” to find the number of items in the shape, like this:

   # $ A3

1
   # $ A23

2

Two planes each with two rows of three lego blocks

Above, we have a brick of 2 tables, each table with 2 lists, and each list with length 3. Using J we get:

   A223=: 2 2 3 $ 5 6 7 8 9 10 11 12 13 14 15 16
   A223
 
5  6  7
 
8  9 10


11 12 13

14 15 16

and:

   $ A223

2 2 3
   # $ a223

3 

Using the empty line to separate each item in the array is a particularly clever approach that J uses to display higher rank arrays. In fact, J adds an extra line as the rank increases, so that the items in rank 4 arrays are separated by 2 empty lines.

To sum up: (1) arrays have shapes, (2) the first number in the shape is the number of items, (3) the rank of an array is the length of its shape. If this isn’t clear, go back and review the examples above or take a look at Chapter 5 in Henry Rich’s excellent “J for C Programmers”. In the next blog entry we’ll explore why the J representation for arrays is not as clear as it could be.

Block Representations of J’s arrays

When I moved to a house on the edge of a forest I enjoyed many hours exploring the trails, but when maps placed at strategic points consistently sent me in the wrong direction, I thought years away from the world of compass points and orienteering had finally caught up with me. It was not until I stood looking at a map in front of Enos Lake that I discovered the real reason. The map suggested that the lake, which was clearly before me, should in fact be located behind; the map had been mounted backwards with respect to the surrounding terrain. As I saw more maps on the trails, I found that they had all been placed with a similar aspect; even more misleading because they were usually in the middle of the forest, away from prominent features that allowed reorientation.

And the point of this story? Well for the last couple of years I have considered translating the textual form of the J computer language into a visual one, and it has become clear that visual interpretation requires coordination with the structure of the language on a fundamental level. As with my experiences on the trail, it is vital that the map (visual interface) fit the terrain (the structure of the language), or at every step along the way we risk losing our users due to unnecessary mental effort.

So let’s look at the J’s terrain before we position our map. J uses a text based representation to expresse values and structures of its arrays to the programmer. While this style is very good at showing the values of the arrays, it is less effective in conveying their shape and structure (particularly in the case of singletons or arrays with zero valued indices in their shape). For now let’s look at how an array of 2 numbers would be shown.

       2 $ 1 2
1 2

To explain, the top line is the instruction to create the array and the second line is the representation. On the top line, the 2 in front of the $ means that the 2 items after the $ will be used to make an array of length 2.

If we represented the numbers as children’s blocks it might look like this:

Similarly a two-dimensional array would be represented with rows and columns. In the example below there are now two numbers before the $. The first number, 3, gives the number of rows and the second number, 2, gives the number of items in each row.

      3 2 $ 1 2 3 4 5 6
1 2
3 4
5 6

And in block notation we could stack the blocks as follows:

When we move to three dimensions it gets a bit more complicated. There are now three numbers before the $, and the first number, 3, indicates the number of 3 X 2 planes that we will have. J uses the linefeed to insert an empty line between the planes and separate them in a very effective way.

     3 3 2 $ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
 1  2 
 3  4
 5  6 

 7  8
 9 10
11 12 

13 14
15 16
17 18

If we use the blocks, the situation presents a choice that was not present in our first two examples. Do we stack the planes with the first plane at the back or at the front? Here is an example of the two approaches:

Either choice could work but I prefer having the planes stack like the pages of a book, with the ones closest being the ones that are listed first. This also allows the position in the upper left front corner to be an anchor easily located by the viewer. If instead the planes were added moving forward toward the viewer, then the visible corner value would change as every plane is added. There are enough challenges in understanding array languages without having the positions in the array dance before your eyes.

And it is at this point, gentle reader, that you come in. My perception is but one data point in creating representations for a much wider audience. I welcome feedback about the suitability of the ‘book pages’ approach to three-dimensional arrays, but concerns about the row and plane representations in the case of two-dimensional arrays are important as well in revealing even deeper fundamental differences in visualization. Don’t worry about the fact that J’s text approach and my block visualizations do a poor job of distinguishing between atoms, lists, or matrices of only one value, I will be addressing that in a future post. For now, just let me know if the direction my map is pointed makes sense to you.

Thanks in advance for your help.