# The MAP function

I am new so wondering if the map() function has a counterpart that does not use integer math with its non-linear limitations.

When you map 0-1023 to 0-255, in say 4 steps, the last step only works on the last number. Attached is a representation I ran across recently. My hope is there is a SUPER map function used to get a lot more accuracy and linearity? What is the workaround for this problem? Thanks again!

Deve:
What is the workaround for this problem?

Scaling using a floating point math expression.

What does that mean? Is there a way to make a function that works the same way only better?

Deve:
What does that mean? Is there a way to make a function that works the same way only better?

Define "better". The map function already maps integer values correctly. 1023/256 does in fact equal 3 in integer math. It is not a flaw, it is the way such numbers behave.

Actually, it is not clear from the image you provided, either the context, or what problem you have that it illustrates. You need to explain further.

Better would be if it worked properly. As the graphic I presented clearly indicates, the last 'group' is defined only by the last number, not the span of numbers it is supposed to represent. I would think that would be unacceptable and someone would have made a better map function. Is it just me? really?

The graphic shows the problem, here is some of the explanation..

Integer math treats remainders a certain way. Any time there is any type of remainder, it’s truncated. It doesn’t get rounded. It just gets cut off.

As a result, the last number of the previousHigh always maps directly to the last value of the newHigh. So for a range that goes from zero to four, the only value that gets mapped to four is 1023 on the old range.

I guess its just something we live with, but I would think someone would have made a better map function by now. Must not be important. Thanks!

Deve:
Is it just me? really?

Just to get to the crux of it while I try to fully absorb your explanation - yes it is.

Statements like, "the last number of the previousHigh always maps directly to the last value of the newHigh" don't make sense. What are you talking about? Examples help sometimes.

Show me that there is a problem.

As far as I can see, it is quite reasonable that only 1023 maps to 4. 4 is a power of two, but 1023 is not. So the transition points for quantization do not occur at values of a power of two. If you want that you say:

``````map(rawdata, 0, 1024, 0, 4)
``````

Then it will return 3 when rawdata == 1023.

Or you can say:
`rawdata/(1024/4)`

I wondered how the map function worked so I looked it up:

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

Z

zhomeslice:
I wondered how the map function worked so I looked it up:

``````long map(long x, long in_min, long in_max, long out_min, long out_max)
``````

{
return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

``````

https://gist.github.com/anubiann00b/14d9a6bbad7edcb2d34b
Z
``````

@Deve
if you replace map by fmap and the type long by float you might have found what you were looking for.

Hi,
Check this post.

Tom…

Yep. For those of us who are trying to learn this stuff, when we come across a function that is broken (and in the context I stated it IS) we search for answers. I wonder why they didn't go to this as a standard after it was known that map() doesn't work all the time? At any rate, it's all about searching for answers. THANK YOU!

when we come across a function that is broken

It is NOT broken. Your expectations are wrong. That is all.

Deve:
Yep. For those of us who are trying to learn this stuff, when we come across a function that is broken (and in the context I stated it IS) we search for answers.

You never stated the context. You only suggested a way that you wanted it to behave, that is inconsistent with fundamental integer math. You never explained why you used 1023 as a map value. That happens to be a common error which results in an incorrect mapping (often found in analog input value scaling).