I'm trying to create a speed scaling function based on a cubic regression but it seems that firstly the data type double does not exist but none of the other data types are large enough to hold the numbers. On top of that the provided data types are not what a C or C++ programmer knows them to be and this is not explictly stated. Indeed type int should be large enough to hold the numbers I'm working with but it appears not to be.

Is there a way around this or a way to redefine the size of the data types?

ROBOTC supports the following standard C data types:
char
short
int
long
float

ROBOTC deviates from standard C in that all variables are signed. Unsigned types are currently not supported. ROBOTC will accept the "unsigned" keyword but should generate a compiler warning message indicating that it is ignored.

In the C language, the size of an "int" is implementation specific. In the case of ROBOTC, "int" variables are 16-bits. I realize that this may not be the best choice for the NXT which has a native 32-bit CPU. But ROBOTC runs on many platforms / CPUs, most of which are 8-bit hardware CPUs, and 16-bit was used. Use of 16-bit "int" is farily common on embedded systems; for example, an "int" on the VEX CPU is 16-bits. "int" on Atmel AVR, Microchip PICs, Renesas H8 series, Zilog Z8 series are all 16-bits.

A float is 32-bits total. 8-bit exponent and 24-bit mantissa. Doubles are not supported in ROBOTC.

Hope above helps. Perhaps "long" or "float" will meet your needs.

That I'm afraid is part of the problem. Even though I'm using float there seems to be cutting off the calculation. Is there a limit on the size of the calculations possible. For example the function is supposed to cube the value from the joysticks but the number returned is far less than it should be (I tried this with just a stand alone varriable and calculation) even when stored in a float varriable.

You may want to point out in the documentation which data types are supported and state their limits. Also if I may add, you may want to consider adding a virtual testing platform in future versions so that programmers can test code without a robot present.

I suggest using longs which are 32bit integers. You will need to be careful to perform your math opporations in an order that will avoid overflow but 32 bits integers are capable of handling 128^3.

Feel free to post your current code if you would like help.

I think RobotC has to be customized to the 32 bit ARM7 processor.
It is not suitable to use a 8 bit compiler model for a 32 bit processor.
Get rid of the old stuff.

It's like if I drove my 911 always in the first gear - with tightened handbrake.

I am not aware of any problems with ROBOTC's "number precision". I just tried the following test program and examined the output in the debugger window to confirm this.

There may be a bug in ROBOTC's expression calculation / compiler. BUt I suspect what you've encountered is a simplification that ROBOTC does in the debugger display of float numbers. For very small numbers in the range 0.000001 to 0.001 it will display as zero rather than in "scientific notation". The rationale behind this was to limit display precision to four or five decimal digits and avoid having to explain scientific notation to novices.

If you run the above program and look at the results in the debugger window, you'll see the display for "fTestSmall" as values:
1
0.1
0.01
0.001
0.0001
0
0
1.0000e-006
1.0000e-007
1.0000e-008
. . .
If you use the "nxtDisplayTextLine( xx, "%f", variable):" to display a value on the NXT LCD you'll see that the internal results are what's expected. Or you can use the Debugger "Hexadecimal display" to get the variables displayed in hex.

If you still think there are errors in calculations, then please post again.