A valid use case for flow style

[leni536]

Maybe I shouldn't use strictyaml for linear algebra heavy stuff.

matrix: [
  [ 2., 5., 1.],
  [ 3., 2., 3.],
  [ 4., 1., 2.],
  ]
matrix_strict:
  -
    - 2.
    - 5.
    - 1.
  -
    - 3.
    - 2.
    - 3.
  -
    - 4.
    - 1.
    - 2.

[crdoconnor]

I can make it do something like this, which is terser than both, if you like:

matrix: |
  2 5 1
  3 2 3
  4 1 2

Python::

load(matrix_yaml, Map({"matrix": Matrix(Int(), 3, 3)}) == {"matrix": [[2, 5, 1], [3, 2, 3], [4, 1, 2]]}

How does that sound?

[leni536]

To be clear, I raised this issue as a criticism of the stricyaml specification, not the library.

As for your proposal to represent a matrix in a strictyaml stream, that's just a string. Not a matrix, not a list of lists of floats, etc.... No other yaml parser would parse it as a matrix. You state that strictyaml is a subset of the yaml spec, but this would break it.

As for your python API proposal, that looks fine (as long as specifying the number of rows and columns are optional independently to each other).

[crdoconnor]

As for your proposal to represent a matrix in a strictyaml stream, that's just a string.

Yes, which would be my preferred way of representing a matrix of integers in YAML whether I was using strictyaml or not. There's nothing intrinsically wrong with parsing as a string and then passing that on to another more specialized parser.

Is your argument against the spec is that it doesn't let you represent a matrix in a way that's almost 50%** noisier than necessary?

You state that strictyaml is a subset of the yaml spec, but this would break it.

Right, because it's a subset. Not all valid YAML is valid strictyaml (e.g. flow style is not), but all valid strictyaml is valid YAML (space delimited matrices held as strings are valid).

** Flow version: 65 characters long, string version: 34 characters long.

[leni536]

Flow version: 65 characters long, string version: 34 characters long.

Two can play at that game.

matrix:
- [2, 5, 1]
- [3, 2, 3]
- [4, 1, 2]

It's only 44 characters, 10 characters longer, Those 10 characters add enough semantics that all yaml parsers can parse these into native data structures without a specialized parser. And I think it is fairly easy to parse for humans too.

I don't have any more arguments, I think we can agree to disagree.

[shoogle]

Consider the diff that is created when you edit a matrix in flow-style YAML:

 matrix_flow:
 - [2, 5, 1]
-- [3, 2, 3]
+- [3, 4, 3]
 - [4, 1, 2]

Only one digit actually changed, yet it appears from the diff that the entire line has changed. Imagine having to search for the changed digit in a much larger matrix...

Here is the equivalent in block-style array as used by StrictYAML:

 matrix_block:
 -
   - 2
   - 5
   - 1
 -
   - 3
-  - 2
+  - 4
   - 3
 -
   - 4
   - 1
   - 2

Now it is easy to see what has changed, and it would remain this easy regardless of the size of the matrix. Smaller diffs also mean smaller repository size and less data transferred on git push/pull.

Flow style only makes sense for a 2D matrix. It has no advantage for a 1D matrix (i.e. an array), nor with 3 or more dimensions. However, the diff problem would be enough for me to stop using flow-style YAML even for a 2D matrix.

[ghost]

@shoogle Sorry to bump an old thread, but that's a shortcoming of GitHub or whatever you're using for diffing. It would be perfectly possible for it to indicate what actually changed within the line.

[shoogle]

@nyuszika7h, true, but we work with the tools we have. GitHub does actually show changes within a line, but git diff on the command line does not, at least not by default.

But the diff highlight thing is just a side point. The main reason for disallowing flow-style is that is makes the specification (and parsers) more complicated because now there are two ways to show the same thing.