Why there is no safe version of subseq that with string would return
an empty string when outside the string boundaries?
I have tried following code with strings. Is it correct?
(defun subseq-safe (sequence start &optional end)
"Safe subseq SEQUENCE START END makes sure we stay within sequence boundaries"
(let ((ls (length sequence)))
(subseq sequence
(max 0
(min start
ls))
(when end
(min end
ls)))))
On Friday, February 4, 2022 at 5:49:47 AM UTC-8, Spiros Bousbouras wrote:
On Fri, 4 Feb 2022 02:28:34 -0800 (PST)
Bigos <ruby....@googlemail.com> wrote:
Why there is no safe version of subseq that with string would return
an empty string when outside the string boundaries?
I have tried following code with strings. Is it correct?
(defun subseq-safe (sequence start &optional end)
"Safe subseq SEQUENCE START END makes sure we stay within sequence boundaries"
(let ((ls (length sequence)))
(subseq sequence
(max 0
(min start
ls))
(when end
(min end
ls)))))
Some other observations.
* This function will still fail, for example with (SUBSEQ-SAFE "0123456789" 5 3).
* The regular SUBSEQ has the invariant that it *always* returns a sequence of length (end - start)
* When applied to lists, determining the length of the sequence is an O(n) operation, so a call like
(SUBSEQ very-long-list 0 5) would have worse performance.
* +1 to Spiro's observation about the dangers of silently discarding negative indices.
On Fri, 4 Feb 2022 02:28:34 -0800 (PST)
Bigos <ruby....@googlemail.com> wrote:
Why there is no safe version of subseq that with string would return
an empty string when outside the string boundaries?
I have tried following code with strings. Is it correct?
(defun subseq-safe (sequence start &optional end)
"Safe subseq SEQUENCE START END makes sure we stay within sequence boundaries"
(let ((ls (length sequence)))
(subseq sequence
(max 0
(min start
ls))
(when end
(min end
ls)))))
On 2/4/2022 11:47 AM, Tom Russ wrote:^^^^^^^^^^^^^^^^^^^^^^
Some other observations.
* This function will still fail, for example with (SUBSEQ-SAFE "0123456789" 5 3).
* The regular SUBSEQ has the invariant that it *always* returns a
sequence of length (end - start)
* When applied to lists, determining the length of the sequence is an
O(n) operation, so a call like
(SUBSEQ very-long-list 0 5) would have worse performance.
Is length really an order n operation in most Lisps? I think strings are stored as arrays and arrays have headers with length information.
On Fri, 4 Feb 2022 12:12:28 -0700
Jeff Barnett <jbb@notatt.com> wrote:
On 2/4/2022 11:47 AM, Tom Russ wrote:^^^^^^^^^^^^^^^^^^^^^^
Some other observations.
* This function will still fail, for example with (SUBSEQ-SAFE "0123456789" 5 3).
* The regular SUBSEQ has the invariant that it *always* returns a
sequence of length (end - start)
* When applied to lists, determining the length of the sequence is an
O(n) operation, so a call like
(SUBSEQ very-long-list 0 5) would have worse performance.
[...]
Is length really an order n operation in most Lisps? I think strings are
stored as arrays and arrays have headers with length information.
* Bigos <ehol.bowrpg@tbbtyrznvy.pbz> [2022-02-04 02:28:34 -0800]:
Why there is no safe version of subseq that with string would return an empty string when outside the string boundaries?
I have tried following code with strings. Is it correct?
(defun subseq-safe (sequence start &optional end)
"Safe subseq SEQUENCE START END makes sure we stay within sequence boundaries"
(let ((ls (length sequence)))
(subseq sequence
(max 0
(min start
ls))
(when end
(min end
ls)))))
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 299 |
Nodes: | 16 (2 / 14) |
Uptime: | 28:23:15 |
Calls: | 6,681 |
Calls today: | 4 |
Files: | 12,222 |
Messages: | 5,342,514 |
Posted today: | 2 |