FIT Write Bug

> NaN is really just a floating point construct to handle strange edge cases, I think

Yes, but the point is that the bit representation of NaN is 0xFFFFFFFF, which is what is the FIT specification says to use for "invalid value" (for 32-bit floats). If you try to convert the integer 0xFFFFFFFF to a floating point value, you will get -1 (float), which is does not have a bit pattern of 0xFFFFFFFF (as demonstrated in a previous comment.)

> I'm not sure any more that it worked. 

That's a shame :(.

Obviously native apps have the ability to "write gaps" (aka "write nothing"), so it's a real shame if 3rd-party apps don't.

Thanks! I won't give up yet :-) I really appreciate your time to test this. It would make the presentation of data much more consumable to be able to represent no/bad data as a gap.

I'm not sure any more that it worked. I recorded HR data, so it comes from the sensor as unsigned "byte", but now I don't find any activity where I can see a gap. It's 0. But I'll try it again with my current code in a few days and report back if it works.

Good thinking! Except, no joy. I was able to use NaN in setData for a *float*. No error. I write NaN in initialize and I write it until and if my metric has valid data. 

Two issues.

First, NaN didn't give us the desired "empty" gap in the line graph.

Second - the web-based view retroactively applied the first valid data point back to time = 0. But the smartphone mobile app applied a "-1" to NaN.

Ugh. flocsy🤠 posted that he had success with 8bit data types. For those data types I should be able to setData(0xFF) [unsigned] and setData(0x7F) [signed], correct? NaN is really just a floating point construct to handle strange edge cases, I think. I did try those "invalid" values and didn't see line graph gaps. But I'll try again.

IIRC, in the linked post, Gavriel tried 255 for a UINT8 and it worked.

If you're literally writing code like this...

var floatVal = 0.0f;
...
floatVal = 0xffffffff;

...it's not doing what you think. It doesn't give you a float with all bits 1, it gives you the equivalent float for the integer with all bits 1, which is not what you want. (In monkey C, a Number with all bits 1 is numerically equal to -1.) In other words, assigning an integer constant to a float doesn't preserve the bit pattern, it preserves the numerical value (since the numerical value is what people care about 99.99% of the time.)

For example, consider the following C program:

#include <stdio.h>

int main() {
  float f = (int)0xffffffff;
  int *x = &f;

  printf("%f\n", f);
  printf("%lx\n", *x);
}

This prints:

-1.000000
bf800000

OTOH:

#include <stdio.h>

int main() {
  int x = 0xffffffff;
  float *f = &x;

  printf("%f\n", *f);
  printf("%lx\n", x);
}

prints:

nan
0xffffffff

This tells me that the IEEE floating point standard uses all bits 1 to represent NaN.

So how do we represent this in Monkey C? Try this:

field.setData(NaN);