Ragged Structures

[bob-carpenter]

Ragged structures

[syclik]

@bob-carpenter, I just looked at the ragged structures (and not the closures) doc.

It looks great! Really great.

One question: will we continue to have arrays be declared the way it currently is? As a concrete example:

real x[2, 3];

and

real[{ {3}, {3} }] x;

should be equivalent. It seems like we'd want to keep the old syntax because it makes rectangular things pretty easy, but I can see how we might want to move the brackets before the variable instead of its current position.

[bob-carpenter]

Yes, I still want to keep rectangular declarations for convenience. I want to deprecate

real x[2, 3];

and replace with

real[2, 3] x;

so that the character sequence for the type is contiguous, i.e., real[2, 3]. We already have that without the sizes for function argument types.

[jgabry]

This looks great. Thanks for writing this up @bob-carpenter!

[bob-carpenter]

Definitely want to keep rectangular definitions. I'll make that clearer. Specifically, I want to deprecate real x[2, 3]; in favor of keeping the types/sizes contiguous: real[2, 3] x; We're going to need this for tuples/structs anyway. - Bob

…

On Aug 7, 2019, at 6:49 AM, Daniel Lee ***@***.***> wrote: @bob-carpenter, I just looked at the ragged structures (and not the closures) doc. It looks great! Really great. One question: will we continue to have arrays be declared the way it currently is? As a concrete example: real x[2, 3]; and real[{ {3}, {3} }] x; should be equivalent. It seems like we'd want to keep the old syntax because it makes rectangular things pretty easy, but I can see how we might want to move the brackets before the variable instead of its current position. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[wds15]

This looks great. Two questions:

• How do you envision to declare regular arrays of matrices/vectors in the future?
• Will it be possible to declare a ragged array dimensions using another ragged array of ints?

Sebastian

[rok-cesnovar]

A couple of questions and suggestions to update the doc now that we support the array[] T syntax.

[rok-cesnovar]

Suggested change

	real[{3, 4}] x = {{a, b, c}, {d, e, f, g}};
	array[{3, 4}] real x = {{a, b, c}, {d, e, f, g}};

[rok-cesnovar]

Suggested change

	x : real[ , ]
	x : array[ , ] T

[rok-cesnovar]

Suggested change

	elements. Declaring `x` of type and size `real[{3, 4}]` declares `x`
	elements. Declaring `x` of type and size `array[{3, 4}] real` declares `x`

[rok-cesnovar]

Suggested change

	real[{ {2, 3}, { 1, 2, 3 } }] y
	array[{ {2, 3}, { 1, 2, 3 } }] real y

[rok-cesnovar]

Suggested change

	The type of both `y[1]` and `y[2]` is `real[, ]`, the type of a
	The type of both `y[1]` and `y[2]` is `array[, ] real`, the type of a

[rok-cesnovar]

Suggested change

	real<lower = 0, upper = 1>[{3, 4}] x = {{a, b, c}, {d, e, f, g}};
	array[{3,4}] real<lower = 0, upper = 1> x = {{a, b, c}, {d, e, f, g}};

[rok-cesnovar]

Suggested change

	simplex[{3, 2, 2}] theta
	array[3] simplex[{3, 2, 2}] theta

[rok-cesnovar]

This was implemented in Stan 2.25 where we now have array[...] real x, array[...] vector[N] a, etc. so we can remove the text below.

[rok-cesnovar]

Suggested change

	cov_matrix[2][3] x
	= { [[1, 0], [0, 1]],
	[[3.1, -0.2], [-0.2, 3.1]],
	[[15.2, 0.1], [0.1, 15.2]] };
	array[3] cov_matrix[2] x
	= { [[1, 0], [0, 1]],
	[[3.1, -0.2], [-0.2, 3.1]],
	[[15.2, 0.1], [0.1, 15.2]] };

[rok-cesnovar]

Question:

Do we also want to support

array[2] cov_matrix[{2, 2, 3}] x
  = { [[1, 0], [0, 1]],
      [[3.1, -0.2], [-0.2, 3.1]],
      [[15.2, 0.1, 0.1], [0.1, 15.2, 0.1], [0.1, 0.1, 15.2]] };

[rok-cesnovar]

This wasnt intended for this PR I guess?

[rok-cesnovar]

I also dont see any mention if Stan Math functions should support ragged arrays?
For example

array[{3, 4}] real x = {{a, b, c}, {d, e, f, g}};
array[{3, 4}] real y = sin(x);

Should this work? If yes then I think adding tests for this in Stan Math should be mentioned somewhere in the docs.

[bob-carpenter]

I also dont see any mention if Stan Math functions should support ragged arrays?

I think that's an independent question. It'd be great if we could extend unary function vectorization to them. I would not try to do arithmetic, but reductions like sum() might make sense. The trickier thing will be structured operations like append_row, which should work, but append_col, which wouldn't make sense.

[rok-cesnovar]

Ok, that does make stuff a bit easier then for Stan Math, but a bit more for stanc as we need to keep track at whats ragged and whats not. Thanks.

[WardBrian]

@bob-carpenter and I just discussed this and I'd like to suggest an alternate syntax that makes the dimensionality of the final array much clearer. Based on how we do function argument typing, I think we could have a syntax like:

array[3] int sizes = {3, 2, 3};

array[ , sizes] real = ...;

We could even optionally allow array[3, sizes], with the 3 obviously being redundant.

Why? Because if I show you, array[sizes], you have no idea how many dimensions this array has without chasing down where sizes comes from, which might not always be right there. By contrast, array[,sizes] tells you immediately that the array has 2 dimensions but is ragged. In general this would also work for things like array[,,,sizes_3d] real four_D_ragged;

[bob-carpenter]

I'd like to change the spec to work like @WardBrian suggests.

[nhuurre]

@WardBrian I like that idea. It also clarifies the situation with array[] vector[sizes] (array is mandatory)

And since we're likely to get tuples before ragged arrays I suggest matrix dimensions are given as 2-tuples and not two-element arrays.

-matrix[{ {2, 3}, {3, 2}, {1, 2} }] v
+matrix[{ (2, 3), (3, 2), (1, 2) }] v
 = { [[a, b, c], [d, e, f]],
     [[g, h], [i, j], [k, l]],
     [[m, n]] };