Dealing with NaN for Calculator Tests

[aviL221]

After creating a temporal_freq_tuning_calc object and writing a mock expected document to the disk for 1 test, I ran [b,errormsg,b_expected,doc_output,doc_expected_output] = temporal_freq_tuning_calc.test('standard',1,1); The resulting errormsg claimed that the field fitless.L50 (as well as fit_dog.L50 and fit_spline.L50) did not have the same array size when comparing the output document with the expected output document. Upon further inspection, these fields were NaN in the actual output document (interpreted as a 1x1 array), but 'NaN' in the expected output document (interpreted as a 1x3 array). It seems that writing and loading the expected output document converts NaN to 'NaN'. Is there an existing function to manually convert NaN to 'NaN' so the actual document matches the expected document?
If a field is NaN, should it still be compared between actual and expected document? Or should it be an error on account of being not a number?

[stevevanhooser]

That's interesting. Matlab's JSON decoder usually converts NaN correctly. See below:

mydata.datahere = NaN * ones(3,1)
S = jsonencodenan(mydata)
J = jsondecode(S)

I wonder if the error is ours somewhere, like do we sometimes set one of these equal to 'NaN' instead of NaN in the function?

If you add a document to the database and read it back, do NaN values become 'NaN', for example?

[aviL221]

The expected documents are now displaying NaN and Inf correctly. If a field is NaN or Inf, should the test consider that an error even if that field is the same for both the actual and expected document?

[stevevanhooser]

If it should be NaN or Inf, then that is correct. isequaln treats NaNs as equal. Inf is already treated as equal to Inf by default.

[stevevanhooser]

Usually isequaln is the right thing

[stevevanhooser]

Unless a tolerance is needed

[aviL221]

Thanks!