Fraction as array

[rpatters1]

I am a little puzzled why fractions are defined as arrays and not objects. Enforcing an array of exactly 2 elements seems like what objects are designed for.

[adrianholovaty]

Objects felt a bit too heavyweight for this. The approach would be something like {"numerator": 1, "denominator": 2}, and it felt significantly nicer to use [1, 2]. Easier on the eyes, takes up less space and hopefully is intuitive to understand.

Is there a specific problem you've encountered with the array approach?

[rpatters1]

No, no problem. I just think it is a potential source of errors. I am just getting around to testing if the schema enforces exactly 2 array elements. (If it doesn't that's a source of errors.) Interpreting which is num and which is den is another potential source of errors. Can the schema throw an error if f[1] == 0? Because that's an illegal value. I'm just thinking the schema might be able prevent these kinds of errors easier if it were an object.

[rpatters1]

As a followup: I just tried creating a fraction with 3 elements and it validated against the schema without error. This strikes me as a significant weakness of using an array for the fraction object.

[adrianholovaty]

Upon a quick glance, it appears JSON Schema has a way to enforce this. See "Tuple validation" here. I'll look into tightening the schema to use this!

[mscuthbert]

I think it's far-fetched to think someone will see [3, 4] and be confused about whether this means 3/4 or 4/3.

If we're looking for music representation precedents for storing fractions this way, it's all over the Vexflow code.

[davemacdo]

It's just semantically incorrect to treat a time signature as a fraction. 4/4 and 2/2 have different meanings, but evaluate to the same number when treated as fractions. Time signatures are not fractions, even though they bear some resemblance.

[mscuthbert]

this is not what is being discussed. Time signatures are stored in other ways.

[rpatters1]

I was writing about the fraction object, which describes a musical location or duration. Time signatures (as you rightly point out) are different, and they are implemented as objects in the current spec.

[adrianholovaty]

@davemacdo Time signatures do indeed use two separate keys of an object, "count" and "unit". Here are the docs: https://w3c.github.io/mnx/docs/mnx-reference/objects/time/

[rpatters1]

It is quite easy to imagine that a program bug might cause them to be written backwards. How a human would interpret them seems irrelevant. Once they are used for real, many files will have no indentation, and these will be opaque to humans. The goal here is early failure, which means schema validation should catch as many errors as possible.

I'm cool with the tuplet validation described above. Then the only thing being given up is named access for each field. It seems as though the array can be validated

• to have exactly 2 elements
• the second element (denominator) is greater than zero

That seems like a reasonable tradeoff.