Substitute for posn-match in processing lists with floats

since I’m using mapcar with posn-match in lambda mode (see screenshot) to handle lists, I would like to know what should I use, instead of posn-match, in order to process lists with floats. In fact, if the list is not rounded to integers is not accepted (the message is Error while evaluating the box MAPCAR : Function nthcdr expected a non-negative integer, got 0.0.). So, what is the most appropriate function to handle lists with floats? Thanks for your attention.
Francesco Vitale screenshot.pdf (58.8 KB)

Dear Francesco,
you cannot use floats for positions. It has nothing to do with mapcar.
posn-match second input takes positions. And these should be integers not floats.
You cannot have an 1.333 nth elemt in a list.
Maybe you should clarify what you want to do, before usinf these. i.e mabe you have some data (i am guessing), which gives floats, and you want to use them as positions in a list. If it is so, you chouls consider your algorithm.


Hi Francesco, (whoops Karim was faster as always ! :slight_smile:

This seems normal, the nthcdr is somewhere inside posn-match, whose arguments are :

  1. a list to pick up elements from
  2. a list of indexes or positions in the first list (starting with 0 as first position, 1 as second etc.)

Posn-match is nothing but a glorified nth, that can take a list of positions instead of only one position.
So it’s normal that it doesn’t accept floats, there are no such things as float positions.
what is the 2.3th element in (5 2 6 432 12)?
You need to round it either below — (floor 2.3) => 2th gives 6 —
or above — (ceiling 2.3) => 3th gives 432 — again counting from 0

If you actually want to get something “in between” two elements in the first list — if they are numbers of course and not arbitrary symbols — you need a very different function, with some kind of interpolation inside.

Hope it makes sense !


Hi all,
thanks for having clarified for me the posn-match role once for all: I obviously didn’t recall that it was an enhanced nth. I erroneously assumed that the position in “posn” was coordinate-wise! Since I’m working with two lists of y coordinates, as Julien has remarked, I’d need to use a very different function as lambda: something that works as posn-match but where the position is a real number coordinate. Do you have in mind something that could do this job? Thanks again.
Francesco Vitale

Dear Karim,
here’s what I was trying to do (see the attached patch): is there some suitable alternative to posn-match in order to use coordinate positions and avoid the rounding to integers? Thanks for your attention.
mapcar manipulation of bpf coordinates.omp (102.3 KB)

Hi Francesco. Not too sure what you mean by coordinate system here, but perhaps #'x-transfer or #'y-transfer come close? They accept a bpf and a number (float), and returns the interpolated value looked up from the bpf.

Dear Anders,
thank you for your prompt reply. I don’t know if y-transfer could do this job, but maybe you know something to do with this function that still I’m missing out… As you can see from the patch I attached in my last message what I’m trying to do is to construct a new list of y values by picking elements in the list of the y values of a bpf at positions defined by the y coordinate positions of another bpf.

… to construct a new list of y values by picking elements in the list of the y values of a bpf at positions defined by the y coordinate positions of another bpf…

If i’m not misunderstanding completely, mapping #'x-transfer through these y-values will do just that. Check the attached screenshot. (If this is still wrong, perhaps try to explain in even simpler terms). Anders.

Dear Anders,
you’ve understood perfectly: that’s the solution (I cannot thank you enough for this tip)! I was having some problems because I used the y-transfer function instead of the x-transfer, as you suggested in your example. We can proudly apply the “solved” tag now to this post.
All the best,
Francesco Vitale