I wonder... why is the map() function setup to use long ints?
I hacked mine (changed all the longs to floats) and it works the same.... except that it also now produces fractional results when necessary. Why would it be written with such a limitation?
In case anyone is interested is using this, edit the following files:
And the speed penalty of using floating point math if integer math can do the job required. So yes to and thank you for the fmap() function, but it should never replace the existing map() function.
Krupski:
Why would it be written with such a limitation?
Bear in mind the memory limitations of the original Arduino.
And the speed penalty of using floating point math if integer math can do the job required. So yes to and thank you for the fmap() function, but it should never replace the existing map() function.
Lefty
[/quote]
I know... "speed penalty"... "code size penalty".... but have you ever written a program that just barely squeaked into the available memory? I haven't... and I've written a LOT of stuff in C and assembler (68HC11 assembler).
Have you ever had a program slow to a crawl because it had a floating point number in it? I have not.
I know "speed" and "code size" are stock arguments, but is there any reality to them?
I think the ONLY time that I ever explicitly used integer math in a function was implementing a special version of Bresenham's line draw algorithm (I modified it to generate points in the same direction as they are specified, rather than always from bottom to top or vice-versa). Since I needed to calculate many X-Y points in runtime, I used integers.
Other than that, I really don't care if my code takes a few more clock cycles to run.
I know "speed" and "code size" are stock arguments, but is there any reality to them?
Certainly at time there is. Say when writing a ISR function where you need to make the interrupt take as little time as possible so as not to possibly miss any other interrupts until my ISR completes and re-enables interrupts.
The point is not that a fmap() function is not useful, just that it should never lead to the elimination of the exiting integer map() function, especially on a 8 bit microcontroller. There is room for both functions to exist. Which by the way, not being a C++ expert by any means, isn't there a way for a function to be written in C++ where it will work correctly no matter what variable type you call it with (or even variable number of arguments passed)? I seem to recall that such a C++ function would 'mangle' it's name into separate functions to handle each different argument case? Sounds like magic to me, I'll stick to as close to simple C as I can, thank you.
template <typename T> T map(T x, T x1, T x2, T y1, T y2);
template <typename T> T map(T x, T x1, T x2, T y1, T y2)
{
return (x - x1) * (y2 - y1) / (x2 - x1) + y1;
}
I just started learning about templates and overloaded functions, they are cool :D...But typeless languages are even better!
isn't there a way for a function to be written in C++ where it will work correctly no matter what variable type you call it with (or even variable number of arguments passed)?
Yeah it's called function overload. If you think about it, what does identify a function ? Not only its name, but its argument list too, both type and number of them. So if you write two functions with the same name but different argument list the compiler can select the correct one based on the actual parameters (i.e. the parameter list you specify when you call the function).
Look a Print::print() and Print::println() in hardware/arduino/cores/arduino.
isn't there a way for a function to be written in C++ where it will work correctly no matter what variable type you call it with (or even variable number of arguments passed)?
Since abandoning #define NAMED_CONSTANT literal in favor of const datatype NAMED_CONSTANT = literal I tend to avoid macros whenever possibile. I like to give the compiler as much hints as possible about what my code actually means, to help it catch as many errors as possible.
