use of vector-map is not srfi-43 compatible?
Linas Vepstas
(08 Aug 2020 17:44 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Wolfgang Corcoran-Mathe
(08 Aug 2020 17:53 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Linas Vepstas
(08 Aug 2020 18:26 UTC)
|
Re: use of vector-map is not srfi-43 compatible? Marc Nieper-Wißkirchen (08 Aug 2020 18:34 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Linas Vepstas
(08 Aug 2020 19:05 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Shiro Kawai
(08 Aug 2020 19:23 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Wolfgang Corcoran-Mathe
(08 Aug 2020 19:21 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Marc Nieper-Wißkirchen
(08 Aug 2020 19:40 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Shiro Kawai
(08 Aug 2020 20:09 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
John Cowan
(09 Aug 2020 00:27 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Marc Nieper-Wißkirchen
(09 Aug 2020 09:08 UTC)
|
Re: use of vector-map is not srfi-43 compatible?
Alex Shinn
(11 Aug 2020 01:14 UTC)
|
The root of the problem does not lie in SRFI 133. Already in R7RS-small, the procedure "vector-map" is incompatible to SRFI 43. The SRFI 43 procedure is certainly much more useful than the R7RS/SRFI 133 procedure. On the other hand, the R7RS/SRFI 133 procedure does seem to follow the general shape of the XXX-map procedures where XXX is some type of collection (object). In any case, the name "vector" for the Scheme data structure is not a very good one (but we cannot change this anymore) because it does not have to have anything to do with vectors in a typical mathematical vector space. The name "array" would have been a better fit. Marc Am Sa., 8. Aug. 2020 um 20:26 Uhr schrieb Linas Vepstas <xxxxxx@gmail.com>: > > Eh!? > > So I'm looking at srfi-133 and it appears to be broken in two ways. First, its not compatible with srfi-43 by using the same name with different signatures, which (to me) is a fundamental design error (yes, of course, in C++ this is an "overloaded function w/ different type signatures", etc. and is indeed useful in certain cases, but still is often a pitfall for novice programmers. This is one reason why C++ gets a bad rap; it's easy to mis-use by novices.) To encounter this in a srfi is 100% unacceptable. This is deeply just-plain wrong, for what I would hope are obvious reasons known to all programmers? Wtf? How did this pass review? > > Issue two is that by omitting the index of the vector in the argument, this assumes that the vectors always live in a space that is symmetric under the special orthogonal group. How often does that occur? Sure, in high-school physics, where you learn that space is Euclidean and you learn about orthogonal transformations and sine and cosine, OK, but if you go to college, you learn about symmetries other than the special orthogonal group, and the index on the vector plays an important role. > > For example: in probability, the space is NOT euclidean, it's a simplex, and the symmetry group of probability theory are the Markov matrices, and not the orthogonal group! Things like dot-products are NOT meaningful for probabilities, you have to use fisher information, instead, (which is "euclidean" projective under the square root, e.g. quantum wave functions, etc.) > > My knee-jerk reaction is to throw srfi-133 in the trash-can as fast as possible. It's broken. > > --linas > > > On Sat, Aug 8, 2020 at 12:53 PM Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> wrote: >> >> On 2020-08-08 12:43 -0500, Linas Vepstas wrote: >> > Where is this other vector-map coming from? Why is it colliding with the >> > one defined by srfi-43? >> >> It was changed in SRFI 133, which is now part of R7RS-large. >> >> https://srfi.schemers.org/srfi-133/srfi-133.html#Iteration >> >> -- >> Wolfgang Corcoran-Mathe <xxxxxx@sigwinch.xyz> >> >> "Quantum mechanics can be understood as the discovery that information >> in nature is always finite." --Carlo Rovelli > > > > -- > Verbogeny is one of the pleasurettes of a creatific thinkerizer. > --Peter da Silva >