vector-unzip | Michael Burschik | 10 Apr 2003 08:40 UTC |

Re: vector-unzip | Taylor Campbell | 18 Apr 2003 03:37 UTC |

AW: vector-unzip | Michael Burschik | 22 Apr 2003 05:22 UTC |

Re: AW: vector-unzip | Taylor Campbell | 22 Apr 2003 16:12 UTC |

Re: vector-unzip

*Taylor Campbell*18 Apr 2003 03:37 UTCOn Thursday, April 10, 2003, at 04:40 AM, Michael Burschik wrote: > In addition to vector-unzip, SRFI-43 defines several "common > unzippers", but > fails to specify how their names relate to vector-unzip's argument n. > As far > as I can tell from the reference implementation, the following holds: > (vector-unzipn vec) == (vector-unzip vec (- n 1)). If this is true, > however, > then the reference implementation incorrectly defines vector-unzip5 as > (vector-unzip vec 5). I've added specification for how the N in VECTOR-UNZIPn relates to how it unzips. And actually, the statement: (vector-unzipN vec) == (vector-unzip vec (- N 1)) is false. If you notice in the reference implementation, plain VECTOR-UNZIP already subtracts one from N to get the highest index to get a value from -- (define (vector-unzip vec i) (let loop ((vecs '()) (i (- i 1))) ;; ^^^^^^^^^^^ (if (negative? i) (apply values vecs) (loop (cons (vector-map (cut vector-ref <> i) vec)) vecs) (- i 1))))) Therefore, VECTOR-UNZIP1 would start getting stuff at index -1, but that's negative, so VECTOR-UNZIP1 would always return zero values. That isn't exactly what you'd want. > Regards > > Michael Burschik