tweak explanation of numeric "snapshots"; add abs/0

[pkoppstein]

Clarify and expand explanation of the snapshots that are taken of some numbers.

abs/0 is defined without reference to type.

jq.test now includes tests for abs and fabs, and includes tests for length@number

[wader]

Should say "1.000000000000000000000000000000000000000000000000000002"?

[pkoppstein]

Tx. Done.

[itchyny]

The value needs to be quoted.

[pkoppstein]

Whoops. Done.

[itchyny]

Please add more 4 spaces indentation to make them look like code.

[pkoppstein]

Tx. Done.

[itchyny]

How should it work against null and booleans? Emits error in the current implementation but should be as it is?

[nicowilliams]

And how should it work with strings, arrays, and objects as inputs? Currently it passes them through. That's very strange, but it's an artifact of strings, arrays, and objects sorting after numbers in jq, so this abs/0 doesn't want to negate them, so there's no error, but null, false, and true sort ahead of numbers, so abs/0 does want to negate them, and that then raises an error.

We have some options

• leave as-is
• the abs of all non-number values should be the identity
• the abs of all non-number values should be an error

[pkoppstein]

As @nicowilliams wrote:

We have some options

• leave as-is
• the abs of all non-number values should be the identity
• the abs of all non-number values should be an error

In case it's not obvious, the main reason I went with a simple implementation is speed, but the other reason is that jq often eschews type-checking in favor of having a simple definition that can serve both as "specification" and "implementation". Since manual.yml makes that point by including a copy of the def, I did the same for abs.

And speaking of map, although the analogy is obviously not perfect, the fact is that map could have been written to issue a map-specific error if its input would raise an error, but it wasn't, even though one can easily adduce arguments to the contrary.

Admittedly, in this case, these considerations (of speed, brevity, and my interpretation of "the jq way") are not so weighty, so if the current implementation is deemed unacceptable, I'd go with insisting on type == "number", since that is probably expected, and since it allows future constraint relaxation.

[pkoppstein]

This PR is superseded by #2767