"Aborting launch due to failed build. "

I seem to remember reporting something like this with an old version of the ConnectIQ SDK. I have not been able to reproduce the error you mention given the following code and the 2.1.3 SDK.

using Toybox.Application as App;
using Toybox.WatchUi as Ui;

class Time {

static const MILLISECONDS_PER_MINUTE = 6000.0;
static const MILLISECONDS_PER_SECOND = 1000.0d;
static const SECONDS_PER_MINUTE = 60.0d;
static const SECONDS_PER_HOUR = 3600.0d;

}

class MyView extends Ui.View
{
function initialize() {
View.initialize();
}
}

class MyApp extends App.AppBase
{
function initialize() {
AppBase.initialize();
}

function getInitialView() {
return [ new MyView() ];
}
}


Out of curiosity, is there a reason you're doing double precision? Are you dealing with really big time intervals?

Travis,

The reason for the double precision is that I was inexplicably getting a result of zero in an operation, unless I used double precision. That was months ago. I switched back to float to give it a try and it seems to be working now.

By the way, the issue I described above is with the latest SDK.


Thanks
Jesus

I'm not sure how much programming you do, but you can often get truncated results with integer division if you are not careful about how you arrange your arithmetic expressions. I've not tested with ConnectIQ, but on most hardware there is a cost associated with using floating point, and double-precision is worse. If you'd like me to take a look at the problem code to see about avoiding use of floating-point, feel free to send me a snippet.

Did you try the above code in your environment? Did it work without problem? If it works, could you take the time to try to boil down a test case that demonstrates the problem or give me some direction so that I may be able to do so? If we can produce a test case it will improve the chance that the folks at Garmin will be able to make a fix.

Hi Travis,

Here is why I ended using double precision. I need to convert timestamps returned by ToyboxTime.now().value() from seconds to minutes. Even though I don't need a lot of precision, I need something better than rounding to the nearest integer. If I divide the timestamp by 60.0 it gets rounded to the nearest integer. But if I devide it by 60.0d it doesn't get rounded. Here is an example.

Sys.println(1474788956/60.00) = 24579816.000000;
Sys.println(1474788956/60.00d) = 24579815.933333;

Can you explain this behavior? These numbers do not seem too large for single-precision floating points.

Thanks
Jesus

I got a PM with this same text. I responded with the following...

Single precision floating point (float) is really only accurate to 7 digits of precision. A double is accurate out to 15.

If you divide a timestamp by 60.0, it is subject to floating point error of single precision. If, instead, you divide by an integer you will get an exact value without the overhead of using floating point. The following code does exactly what you want without floating point at all.

var h, m, s;

var x = 1474788956;
m = x / 60;
s = x % 60;
Sys.println(Lang.format("$1$ minutes $2$ seconds", [ m, s ]));

h = x / 3600;
m = (x / 60) % 60;
s = (x % 60);

Sys.println(Lang.format("$1$ hours $2$ minutes $3$ seconds", [ h, m, s ]));


Things do get a bit trickier if the value you want to do arithmetic on is too large to fit into a Lang.Number or a Lang.Long. As long as you aren't dealing with values greater than 9223372036854775807, you should be okay.

Travis