The values are currently float values in the form of X.X and will always be 1 single digit with 1 decimal place. I suppose I could store them and manipulate them as I return them if it makes a difference.
With the values on an 8-bit cpu with no fpu you have the option to count in tenths where 3.4 would be 34.
If I want to work meters to 3 places my working unit may be micrometers so that round-offs and dropped digits are below my 3 places, my variables would be type long which is good to 9 places. Call it fixed point if you want, it’s integer working-units to me. I can use type int to store 4 place trig values and divide by 10000 if need be later.
X.X only varies from 0.0 to 9.9, a single byte could store any of those.
Edit= Errrr — this part is for data you know before runtime.
On an Uno you have whatever of the 32K flash the bootloader and your sketch don’t fill to store constant data; prompts, labels, values, tables, etc. It would take a big sketch to leave < 20K for const data, be sure! A table of 4000 bytes… you could go more data points and higher precision and likely not run out of space.
What you want to learn about is PROGMEM. Bytes from flash take 3 cycles to fetch, only 1 more than bytes from RAM.
Here is what’s at the heart of the Arduino compiler: AVR Libc Home Page
Here is the program space library: avr-libc: <avr/pgmspace.h>: Program Space Utilities
With that an a good forum thread on PROGMEM you should have enough to get there from here.
Pre-calculation tables can speed the heck outta calculation-heavy code.
Bigger data, look to SD (which you do not treat like a HD unless you like to wear SD cards out early) or bigger AVR chips like the 1284P with 16K RAM, 128K flash, 4K EEPROM or the mega2560 board that can take external RAM.
If you want to do floats, get an ARM chip board. They’re 32-bit and maybe allow 64-bit floats while for AVR-duinos the floats are 32-bit (6 places) only. The Teensy 3.6 has an M4F chip with an FPU and 256K RAM for starts.