Could you post the Code you use for the iCompiler so i can check it out, to see where the problem lies?
It’s the one above posted yesterday
Got it, use :
accMin = floor(accSec/60) < 0 ? ceil(accSec/60) : floor(accSec/60);
Instead of only setting it to floor(accSec/60).
That should solve it.
It does work, thanks. Do you know what it is that is keeping iCompiler from working the same way as the IDE with just floor(accSec/60)?
The IDE works the way floor should work, unless you use Integer division. I can only assume how the internal difference is, but maybe something like this :
IDE with Integer Division: (pseudo Code) (there are no different methods, this one is just a representation of what results, not what happens)
void setup() {
floor(-1/10);
}
float floor (float a) {
return removeNumbersAfterPoint(a);
}
Prints :
1.9 = 1
1.1 = 1
1 = 1
0.9 = 0
0 = 0
-0.1 = 0
-0.9 = 0
-1 = -1
-1.1 = -1
-1.9 = 1
ICompiler with Integer Division: (pseudo)
float floor (float a) {
return reduceNumberUntilBecomesInteger(a);
}
1.9 = 1
1.1 = 1
1 = 1
0.9 = 0
0.1 = 0
0 = 0
-0.1 = -1
-0.9 = -1
-1 = -1
-1.1 = -2
-1.9 = -2
The result are what you get if you Test it.
Edit : Both have the same (probably) way to calculate floor, but the iCompiler automatically converts Integer Division, so the actual Input for the method varies depending on which one you use.
1 Like
Floor is the lower / lesser / more negative integer – the “left” value on the number line –
So, floor(0.5) = 0 (left); floor(-0.5) = -1 (left)
-1 ........... 0 ........... 1
| <- -0.5 | <- 0.5 |
… although some languages instead truncate the fractional part, creating an inconsistency in how negative numbers are handled.
The thing that is suspicious to me is that you are using integer division, rather than dividing by 60.0. Is that intentional / necessary? As to why that would give different results in iCompiler, good guess from Lexyth, although it is hard to know if the project is closed source…
We were talking about the IOS version and there isn‘t such a thing as Integer divison (or defined array sizes).
Also, you‘re right, flooring -0.1 and giving 0 is wrong mathematically.
Interesting – is iCompiler in ObjectiveC or Swift? I’m not sure if I have used that app.
I was assuming by “IDE” that you meant the PDE, is that right? If there isn’t such a thing as integer division in iCompiler then that could be exactly why there is a difference between PDE and iCompiler results – as there is such a thing in Java…
Not intentional. I don’t know about necessary, or appropriate. 
I guess I’ll have to look at that some more, and see where my ignorance on that may be causing problems. I seem to remember 60 vs. 60.0 giving me trouble before, but I didn’t really digest the problem.
Is there anything obviously wrong here that you have noticed?
Yes, the PDE.
A key point might be that integer division of a low negative number goes to 0, the floor of 0 is 0. Float division of a low negative number gives a low negative fraction – the floor of that is -1.
println(floor(1/60)); // floor( 0) = 0
println(floor(-1/60.0)); // floor(-0.016) = -1
So if iCompiler is treating accMin/60 like accMin/60.0, then when -1 > accMin > 0 then the code in PDE will return 0, and in iCompiler it will return -1. (untested)
I meant the PDE with IDE. The pseudo Code above was, because if forgot about Integer Division 
I edited my previous post to show a (more) correct version of what would happen, where the difference lies and that this is the case when using Integer Division.