Removed some completely off-topic posts. Please keep this thread uncluttered. There's no lack of other threads that are more suited for banter
- Xander
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
task main()
{
int remainder;
remainder=mod(5.7);
//remainder should be 0.7
}
Also would it be possible to fill a polygon when creating a 3d shape?
The default would be transparent, because you can see lines behind lines.
The filled would be like this:
What about a mod function?
It would return the remainder of the input float.
I guess what you mean is a frac function, not modulo.
Modulo is the integer division remainder, (C function symbol: "%")
what you mean are the numbers behind the decimal point.
In ANSI-C I don't know a frac function (CMIIW), but you can build it by
could we possibly have a
"fast i2c mode" (i2c Highspeed Mode)
the way e.g. RobotC has got?
Some i2c devices then could be possibly driven at a higher i2c speed with faster i2c calls...!
Adding support for a double type is not something I foresee ever happening. The existing firmware passes variables around as generic 4 byte types in a lot of places. Since a float is 4 bytes and you can store any of the smaller integer types within the 4 byte LONG used in the firmware then everything works okay. But if you tried to add support for a double which is greater than 4 bytes long then you would have to change all of that code. It would be a lot of work in the firmware and then I would have to do a lot of work in the compiler to handle a new type. Lots of work for not a whole lot of benefit.