range/3 behaviour when $init and $upto arguments are not numbers

[wader]

• range(0;[];1) keeps outputting increasingly forever (also with {} because how < work i guess)
• range([];0;1) outputs nothing.

gojq errors for both, jaq behave the same as jq it seems. Think i would expect it to thrown some kind of error on non-number arguments, same as range/1 and range/2 do already.

[emanuele6]

(Repost from discord: I didn't notice there was an issue for this)

$ jq -cn 'range([];["a","a","a","a"];["a"])'
[]
["a"]
["a","a"]
["a","a","a"]

range($A; $B; $C) is literally equivalent to ($A | while(. < $B; . + $C)). ^^

$ jq -cn '[] | while(. < ["a","a","a","a"]; . + ["a"])'
[]
["a"]
["a","a"]
["a","a","a"]

[wader]

Had a deeper look at this. TIL range/2 is implemented as op code block literal in C

jq/src/builtin.c

Lines 1858 to 1873 in c127616

	// Note that we can now define `range` as a jq-coded function
	block rangevar = gen_op_var_fresh(STOREV, "rangevar");
	block rangestart = gen_op_var_fresh(STOREV, "rangestart");
	block range = BLOCK(gen_op_simple(DUP),
	gen_call("start", gen_noop()),
	rangestart,
	gen_call("end", gen_noop()),
	gen_op_simple(DUP),
	gen_op_bound(LOADV, rangestart),
	// Reset rangevar for every value generated by "end"
	rangevar,
	gen_op_bound(RANGE, rangevar));
	builtins = BLOCK(builtins, gen_function("range",
	BLOCK(gen_param("start"), gen_param("end")),
	range));
	}

and a RANGE op code

jq/src/execute.c

Lines 515 to 545 in c127616

	case ON_BACKTRACK(RANGE):
	case RANGE: {
	uint16_t level = *pc++;
	uint16_t v = *pc++;
	jv* var = frame_local_var(jq, v, level);
	jv max = stack_pop(jq);
	if (raising) {
	jv_free(max);
	goto do_backtrack;
	}
	if (jv_get_kind(*var) != JV_KIND_NUMBER ||
	jv_get_kind(max) != JV_KIND_NUMBER) {
	set_error(jq, jv_invalid_with_msg(jv_string_fmt("Range bounds must be numeric")));
	jv_free(max);
	goto do_backtrack;
	} else if (jv_number_value(*var) >= jv_number_value(max)) {
	/* finished iterating */
	jv_free(max);
	goto do_backtrack;
	} else {
	jv curr = *var;
	*var = jv_number(jv_number_value(*var) + 1);
	struct stack_pos spos = stack_get_pos(jq);
	stack_push(jq, max);
	stack_save(jq, pc - 3, spos);
	stack_push(jq, curr);
	}
	break;
	}

and implementing it in pure jq would probably have quite a performance degradation:

# range/2 (uses RANGE opcode)
# vs
# range/3 (uses while function written in jq)
$ hyperfine "jq -n 'range(5000000) | empty'" "jq -n 'range(0;5000000;1) | empty'"
Benchmark 1: jq -n 'range(5000000) | empty'
  Time (mean ± σ):     543.0 ms ±   8.0 ms    [User: 537.1 ms, System: 1.0 ms]
  Range (min … max):   532.0 ms … 557.7 ms    10 runs

Benchmark 2: jq -n 'range(0;5000000;1) | empty'
  Time (mean ± σ):      2.005 s ±  0.017 s    [User: 1.993 s, System: 0.002 s]
  Range (min … max):    1.974 s …  2.039 s    10 runs

Summary
  jq -n 'range(5000000) | empty' ran
    3.69 ± 0.06 times faster than jq -n 'range(0;5000000;1) | empty'

[itchyny]

Yeah, defining range/2 by jq-coded (#1960) was rejected previously due to an objection about performance and type validation.

[wader]

@itchyny Ah i see, thanks for referencing your PR.

Wonder how much work it would be to make the current range/2 in C take a step arg and then use that for range/1/range/2 and that way fix the arg type inconsistency between them?