| Ticket UUID: | 999b6966b29915bf9e3754969e5521e7573dc667 | ||
| Title: | lseq has incorrect results in edge cases | ||
| Type: | Bug | Created on: | 2025-11-27 16:34:31 |
| Submitter: | juliannoble2 | Assigned to: | griffin |
| Subsystem: | 17. Commands I-L | Severity: | Minor |
| Priority: | 5 Medium | Last modified: | 2026-03-09 07:37:59 |
| Status: | Closed | Closed by: | jan.nijtmans |
| Resolution: | Fixed | Closed on: | 2026-03-09 07:37:59 |
| Version: | |||
| Description: | ||||
Documentation states: If a step vale is included, it's sign should agree with the direction of the sequence (descending → negative and ascending → positive), otherwise an empty list is returned The behaviour of lseq only matches this statement for step sizes up to the length of the sequence. %lseq 1 to 10 by -9 %lseq 1 to 10 by -10 1 %lseq 10 to 1 by 9 %lseq 10 to 1 by 10 10 It should return start element independent of step, doc mismatch for sign not agreeing with seq direction. | ||||
| User Comments: | ||||
juliannoble2 added on 2025-11-27 17:01:50:
There is also consistency with a directionless sequence to be considered %lseq 10 10 $x returns 10 for any value of $x except zero - which seems reasonable. My feeling is that lseq should return the first element even when the sign doesn't match as that (to me anyway) seems the most logically consistent. As it stands, with the possibility to use basic integer expressions for start and and step - the behaviour feels surprising, even though these are somewhat edge cases. oehhar added on 2025-11-28 09:32:42:
Changed the ticket title to also describe the bug, that the start element is not returned on some step values. It might be better, if the start element is always returned. A step value of 0 leads theoretically to an endles sequence. It might lead to an error or return the empty list in all cases. And documentation can always be improved... Thanks, Harald cdubois added on 2026-01-12 03:32:17:
+1 on Harald's suggestion. It seems more consistent if `lseq` always returns the start element, independent of the step sign, and only the generation of subsequent elements is affected by direction/sign. If that is the intended behavior, I can draft a small regression-test patch covering the reported cases (sign mismatch with large `by`, and the `start==end` “directionless” case). We may also want to decide and document what should happen for `by 0` (error vs empty list). griffin added on 2026-01-14 16:09:40:
Errors are reserved for any arguments that are invalid, e.g. a numeric argument is not a number. Otherwise, a sequence is created. A sequence is defined as a mathematic expression: Y = mX + b The list also has a size (length) limit based on the arguments (start, end, step): If the count is 0 or negative, the sequence is considered empty, and an empty set is a valid result. The sequence can be the empty set when a terminating boundary is met, and there are no prior results, or if the direction of the sequence is inconsistent. For example, the sequence from 1 to 10 by -1 will produce the empty set since the direction of the range is opposite of the increment. With that being said, there are bugs in the algorithm that need to be addressed. griffin added on 2026-02-07 03:04:17:
Fix branch - wip: [https://core.tcl-lang.org/tcl/timeline?r=lseq_bug_fixes] resolves this bug, bug [8d1fc7099570], and TIP [https://core.tcl-lang.org/tips/doc/trunk/tip/746.md] oehhar added on 2026-02-07 11:04:23:
Thanks, Brian. Empy list feels right. Sorry for my wrong contribution. Thanks for all, Harald jan.nijtmans added on 2026-03-09 07:37:59:
Since the fix branch is now merged to both 9.0 and trunk, closing! Thanks, Brian (and others)! | ||||