Defect in long map() function?--integer scaling

system · November 8, 2009, 9:43pm

There appears to be a defect, or at least a trap in the long map() function.

From what I read, version 11 introduced a long map function that was based on a float function. The problem I see is the scaling. In the float world, [0.0,7.0]-->[0.0,3.0] is a 3/7 scaling because we are mapping 7 unit intevals to 3 unit intervals. From my perspective, in the digital world, [0,7]-->[0,3] is a 4/8 scaling since it is mapping 8 discrete items to 4 discrete items. The conversion from float to int didn't seem to adjust for the difference in what is being counted.

Using map(i,0,7,0,3) I'd like to see 0,1,2,3,4,5,6,7,... map to a nice evenly partitioned 0,0,1,1,2,2,3,3,... but due to scaling (not truncation), it maps to 0,0,0,1,1,2,2,3,...
To emphasize the scaling issue, 63 in the above scenario maps to 27 instead of the expected 31.

I don't know what I'm talking about, but it seems to me that map() should be corrected as follows:

long map(long x, long in_min, long in_max, long out_min, long out_max)
{
return (x - in_min) * (out_max - out_min + 1) / (in_max - in_min + 1) + out_min;
}

Alternatively, the documentation could warn people that think like me that they really need to supply the first out-of-range integer for the max values. That is, if one wants to map [0-7] to [0,3] as discrete values then they should specify map(i,0,7**+1**,0,3**+1**), but that seems like a workaround.

Am I thinking right?

Afterthought: the mappings appear to be "open interval" mappings. That is [0,7)[7,14)...-->[0,3)[3,6).... Digitally, we are dealing with closed sets eg {0,1,2,3,4,5,6,7}, so if a user wants to use an open-interval-related function on that closed set, they'd have to simulated it with an open interval [0,8) to be successful. I suspect we don't want users to have to convert their closed sets to open intervals, but should provide a closed set mapping

system · November 8, 2009, 10:14pm

I'm not sure why you think an input of 63 to a map function, that maps numbers in the range of 0 to 7 to a range from 0 to 3, should return anything but an error.

system · November 8, 2009, 10:29pm

The documentation states that out of range arguments are allowed.

Does not constrain values to within the range, because out-of-range values are sometimes intended and useful. The constrain() function may be used either before or after this function, if limits to the ranges are desired.

system · November 8, 2009, 10:42pm

Clarification: the 63 wasn't really critical to the discussion, but was used only to put the magnifying glass on the scaling issue, distinguishing it from a truncation issue.

I'm not sure why you think an input of 63 to a map function, that maps numbers in the range of 0 to 7 to a range from 0 to 3, should return anything but an error.

For now, maybe let's just say I don't expect an error because the documentation provides a good reason:

Does not constrain values to within the range, because out-of-range values are sometimes intended and useful.

Respectfully, I don't want to get side-tracked on the valid-range issue--the scaling issue remains even if restricted to in-bounds values, but perhaps not as obvious. If I'm thinking of this function's purpose correctly, incorrect scaling is why 0 is over-represented in the introductory example.

system · November 8, 2009, 11:13pm

It appears to me that the function is behaving correctly.

(3 * 0)/7 = 0
(3 * 1)/7 = 0
(3 * 2)/7 = 0
(3 * 3)/7 = 1
(3 * 4)/7 = 1
(3 * 5)/7 = 2
(3 * 6)/7 = 2
(3 * 7)/7 = 3

If that's not the behavior you want, you can write your own function. The overhead of calling a function is the same, regardless of whether it's your function or someone else's.

system · November 8, 2009, 11:53pm

If that's not the behavior you want, you can write your own function.

Maybe that was snyde, I can't tell. Yes, I can write my own function, and yes, the processor does multiply by 3/7 as instructed. The point is that the processor should probably be instructed to multiply by 4/8 instead of 3/7.

Rather than snyde, off-the-cuff remarks. Let's seriously consider quality and safety. If the mapping is incorrect by industry standards, then its poison, and who knows how many Mars orbiters will crash.

If the mapping is incorrect in the context of integers, and if intentionally left that way, it's a good reason not to use Arduino for anything important.

Maybe its time to see if there is a standard integer mapping.

system · November 9, 2009, 12:33am

Hi, let me give an example. Suppose we have a 1024-member set {0,1,2,...,1023} that we want to map to a binary set {0,1} for say an if-else decision branch.
I'd think rational users would expect 50% of the values to map to zero and 50% to map to 1. In the current implementation, 99.9% of the set would map to 0 and less than 0.1% of the set would map to 1.

I'd vote to deprecate the function for 'safety' reasons and make a new one with a different name.
What do others think?

system · November 9, 2009, 12:50am

I certainly didn't mean to sound snide. I was pointing out that there is a function provided with a reasonable explanation of how it works. You want a function that behaves differently.

You are certainly free to want a different kind of mapping. You are equally free to develop that function.

All I meant to convey was that there is no real advantage, performance-wise, between using your own function versus using a Arduino-supplied function.

system · November 9, 2009, 1:21am

Thanks for explaining. Peace.

I was pointing out that there is a function provided with a reasonable explanation of how it works. You want a function that behaves differently.

Funny, I looked at the 'reasonable explanation of how it works' and found the definition is vague enough to cover a lot of ground. It pins down the top and bottom values, but its sort of a free-for-all in between.

[...]Re-maps a number from one range to another. That is, a value of fromLow would get mapped to toLow, a value of fromHigh to toHigh, values in-between to values in-between, etc.

My proposal and the actual implementation both satisfy that vague definition of what happens in between, but I think 99% of users would be shocked at the results of say, the Z₁₀₂₄-to-Z₂ case.

Maybe a new function is the answer for types like me, maybe clarifying notes on what happens 'in between' would help too. I can't help but think that users are not getting what they expect.
If an Arduino is ever involved in mapping a roulette game, I'm betting on zero.

edit: ok, technically, and actually, the documentation does show exactly what happens to the values in between by revealing the content of the function. I'm still betting on 'toLow' for the same reasons.

system · November 9, 2009, 2:15am

Are you sure you're implementing it correctly? Can we see which code EXACTLY you're using? (full code please)

I've never had a problem with the map function.. I've used it to set negative numbers as well, works like a champ! And with your example of mapping 1024 to a 0 and 1... works fine... I have a 10k pot hooked up and once it's above ABOUT halfway, the LED will turn on.. else, it's off.

Maybe I'm missing something? I tend to have some horrible ADD.

system · November 9, 2009, 2:18am

I've got to say I'm with OP on this one.

Unless there are any good arguments to keep it as is, that I do not see?

Coding_Badly · November 9, 2009, 2:19am

long map(long x, long in_min, long in_max, long out_min, long out_max)
{
  return (x - in_min) * (out_max - out_min + 1) / (in_max - in_min + 1) + out_min;
}

That's how I've always scaled integer values. That's the way my customers have always expected integer values to be scaled. (And man have I done a lot of that in my previous life!)

Another way to look at it: The current function strips away 1/2 bit of information (truncates instead of rounds). I can't think of any reason to do that.

Coding_Badly · November 9, 2009, 2:32am

I currently don't have access to an Arduino. Someone please run this...

void setup( void )
{
  Serial.begin( 9600 );
  
  long i;
  long m;
  
  for ( i=0; i <=1023; ++i )
  {
    m = map( i, 0, 1023, 0, 1 );
    Serial.print( i );
    Serial.print( "   " );
    Serial.println( m );
  }
}

void loop( void )
{
}

At what value of i does m change to a one?

system · November 9, 2009, 2:58am

This is exactly what it outputs Coding, plus it stops right at 1023.

It starts at 0.. but for some reason, I can't copy that much. (I tried in Serial monitor and Hyperterm, lol.)

But everythings 0 until 1023.

When I change it to
m = map( i, 0, 1023, 0, 2 );

It changes halfway, at 512.. I expected that with 0,1.. but then it stays 1 until 1023, then it turns to 2. So yeah.. that's not cool, lol

retrolefty · November 9, 2009, 4:02am

Very interesting. My software skills still suck but I find these things fascinating. Is the problem just a case of a data 'edge' failure that were not tested for, or is the basic formula flawed? An output range of 0-1 is kind of an unusual application that might not have been considered or tested for?

Unrelated, but in this application does the function have to be defined as returning a long when the output range would fit in a byte (0-1)? It would seem a waste of SRAM space.

Lefty

Coding_Badly · November 9, 2009, 6:28am

retrolefty:

Is the problem just a case of a data 'edge' failure that were not tested for, or is the basic formula flawed?

It is not a case of lack of testing. It either works the way it was intended to work (but I doubt that) or it's a basic formula flaw.

An output range of 0-1 is kind of an unusual application that might not have been considered or tested for?

IDoSoLikeGreenEggsAndHam's logical argument and example also illustrate the problem just not as dramatically.

Unrelated, but in this application does the function have to be defined as returning a long when the output range would fit in a byte (0-1)?

For this application, the function could easily have been defined to return a byte. It would have saved three (or two) machine instructions (assuming my brain is working correctly).

CaptainObvious:

So yeah.. that's not cool, lol

I agree!

system · November 9, 2009, 10:47am

I think the whole issue is really one of semantics. The map function converts numbers in one range to another. The arguments are, effectively, the number of intervals in each range. The OP wants the input to be the number of values in each range.

The 0->1023 range defines 1024 intervals. The 0->1 range defines 1 interval. So, the mapping, with integer results, of most input values in the 0->1023 range to 0 is not surprising.

It's similar to the random function that takes 2 arguments - the min and max values. The documentation there clearly states that max will never be one of the returned values. Calling random(1,6) and expecting a uniform distribution of 1s, 2s, 3s, 4s, 5s, and 6s will result in disappointment.

I think that OP can achieve the results he desires by adding 1 to each range. The rest of us can get the results we expect by using the function as-is.

Perhaps more detail in the documentation is required.

Even better, in my opinion, would be to have map return a float. Then, the caller could truncate or round as required.

system · November 9, 2009, 10:49am

/me voted 'other' as in 'fixed'.

This is one of those functions I would expect to be template.

Coding_Badly · November 9, 2009, 11:26pm

PaulS:

The 0->1023 range defines 1024 intervals. The 0->1 range defines 1 interval.

There are 1023 intervals in the first range; 1024 discrete values.

So, the mapping, with integer results, of most input values in the 0->1023 range to 0 is not surprising.

It is to me. It's also useless.

The rest of us can get the results we expect by using the function as-is.

The rest of who? At this point, you're the only one participating in this discussion who wants map to work the way it does.

Why do you want it to work the way it does? What is the benefit?

system · November 9, 2009, 11:42pm

I don't really care. I've never actually used the function. I simply thought that there was a reasonable explanation for the way that it works, and that the way that it works is documented.

If the function is changed, the documentation needs to be changed, too. There may be many users who's code will change behavior when they next make an unrelated change.

Generally, that is not a good thing to do to users.

Fixing it if it does not work as advertised is one thing. "Fixing" it when it does work as advertised is another matter entirely.

Topic		Replies	Views
How come map() function is proper and correct? What is the idea behind it? Programming	56	18053	May 5, 2021
How map() loses precision and how to fix it Libraries	5	3678	May 6, 2021
An ideal but slow map() ... needs optimization Libraries	2	1441	May 6, 2021
NewMap() - map revisited Development	8	7155	May 6, 2021
map() function equation wrong Suggestions for the Arduino Project	6	7531	May 6, 2021

Defect in long map() function?--integer scaling

Related topics