Is there a way to force more strict variable types

Here is some example code:
testinteger1 <- 1;
testinteger3 <-3;
testdecimal3 <- 3.0;

myresult <- testinteger1/testinteger3;

server.log(myresult1); //0
1.00000001); //0

server.log(testinteger1/testinteger31.01); //0
server.log(testinteger1/testdecimal3); //0.333333


Sunday, March 03, 2013 1:37:31 PM: 0
Sunday, March 03, 2013 1:37:31 PM: 0
Sunday, March 03, 2013 1:37:31 PM: 0
Sunday, March 03, 2013 1:37:31 PM: 0.330033
Sunday, March 03, 2013 1:37:31 PM: 0.333333

It is not obvious how to control the variable type.

This has been causing me some frustration because values I am calculating are sometimes lost. If I were in straight C I could logically set up the variable types and figure out exactly what is going on. (even if I need help from the forums).

In Squirrel-Language I gather it is considered some advantage to have dynamic typing but I find it hard to get used to.

any advice or comment?


Expressions work just the same way as “straight C”: if either operand is float, the result is float, otherwise it’s integer. In your example, testinteger1, testinteger3, and myresult are therefore integers, and testdecimal3 is a float. Your log messages are an integer zero, a float zero, a second float zero, and then two float nonzeroes.

The expression testinteger1/testinteger3*1.01 is evaluated left-to-right: the result of the division is integer zero, and multiplying that by float 1.01 results in float zero. Just like in C (though some compilers will issue a warning on that code: “narrower precision in wider context” or suchlike).

You can use Squirrel’s “typeof” operator to give you hints about what’s going on.


This function returns 20
although the answer is really 20.25

What would be a good practice to return 20.25 from this function?

`function getTempinC(){

    local tempC = 0.0;
    tempC =  ((CurrentTemp)/SCALE)
    return tempC;

SCALE <- 65536;
CurrentTemp <- 1327104

server.log (getTempinC());

It seems to me that setting
SCALE <- 65536.0
CurrentTemp <- 1327104.0
would return your desired value. (I did not test this, however…)

yes that should work. I have been trying to do all the math for my code in integers. Maybe just for my relatively infrequent reporting function I can find a way to get one of the values to floating point before doing the calculation.

Floats are not that slow in squirrel - this isn’t an atmega :slight_smile: