-nan export - page 3

New comment
 
Lorentzos Roussos #:

I suppose there is no way to "catch" the negative nan or nan without converting to string 

Why do you need that ?

It's your calculations, isn't better to check for valid conditions beforehand ?

Seems to me checking the result is only needed when you have to deal with "foreign" values.

 
Fernando Carreiro #:

You can also use a union between a double and a long and compare the long value of a nan, -nan, inf and -inf for testing equality.

i forgot -inf ... thanks . is that possible ? i were dividing by the mathAbs and checking for the sign but it always were false

 
Alain Verleyen #:

Why do you need that ?

It's your calculations, isn't better to check for valid conditions beforehand ?

Seems to me checking the result is only needed when you have to deal with "foreign" values.

If i establish the limits (the "logical" ones) of each measurement then i can decide if its a small positive , small negative , big positive , big negative to carry the calculation forward

Although the issue is coming from multiplying very tiny numbers i suspect

To explain it a bit further , let's say i have identified 2 properties and i want to see how the price reacts per property a per property b . That is 2 divisions.

Then to create a "forecast" i multiply current property a with current property b by the number above .

 
Lorentzos Roussos #: If i establish the limits (the "logical" ones) of each measurement then i can decide if its a small positive , small negative , big positive , big negative to carry the calculation forward

Although the issue is coming from multiplying very tiny numbers i suspect

I agree with Alain. You should be finding and fixing the "cause" and not trying to resolve the "result".

Even if the product of multiple tiny numbers results in a zero, you can still test that condition before using it in a division.

However, a "-nan" is not caused by division, so you should be searching for a negative number in a square root or log operation.

 
Lorentzos Roussos #:

If i establish the limits (the "logical" ones) of each measurement then i can decide if its a small positive , small negative , big positive , big negative to carry the calculation forward

Although the issue is coming from multiplying very tiny numbers i suspect

No it's not ! At least it should not according to the standard (you should read the link I provided ;-) ).

 
Alain Verleyen #:

No it's not ! At least it should not according to the standard (you should read the link I provided ;-) ).

That would narrow it down to the standard deviations and correlation . I'll check again . 

Fernando Carreiro #:

I agree with Alain. You should be finding and fixing the "cause" and not trying to resolve the "result".

Even if the product of multiple tiny numbers results in a zero, you can still test that condition before using it in a division.

However, a "-nan" is not caused by division, so you should be searching for a negative number in a square root or log operation.

Yeah

 
Fernando Carreiro #:

I agree with Alain. You should be finding and fixing the "cause" and not trying to resolve the "result".

Even if the product of multiple tiny numbers results in a zero, you can still test that condition before using it in a division.

However, a "-nan" is not caused by division, so you should be searching for a negative number in a square root or log operation.

Actually I am thinking, maybe, for performance reason, there could be cases where it's better to check the result. But it depends of the specific logic.

As a general rule though I would check for the "cause".

 
Fernando Carreiro #:

You can also use a union between a double and a long and compare the long value of a nan, -nan, inf and -inf for testing equality.

This catches them , faster than strings i assume . thanks the replacement #'s were for show

#define INFNAN_INF_LONG_SIGNATURE 9218868437227405312
#define INFNAN_NEGATIVE_INF_LONG_SIGNATURE -4503599627370496
#define INFNAN_NAN_LONG_SIGNATURE 9221120237041090560
#define INFNAN_NEGATIVE_NAN_LONG_SIGNATURE -2251799813685248
#define INF_REPLACEMENT 60.0
#define NEGATIVE_INF_REPLACEMENT -60.0
#define NAN_REPLACEMENT 0.0001
#define NEGATIVE_NAN_REPLACEMENT -0.0001
union infnan_signature{
double d;
long l;
};
  double number_gate(double value,
                     double inf_replacement=INF_REPLACEMENT,
                     double negative_inf_replacement=NEGATIVE_INF_REPLACEMENT,
                     double nan_replacement=NAN_REPLACEMENT,
                     double negative_nan_replacement=NEGATIVE_NAN_REPLACEMENT){
  if(!MathIsValidNumber(value)){
  infnan_signature v;
  v.d=value;
  if(v.l==INFNAN_INF_LONG_SIGNATURE){return(inf_replacement);}
  if(v.l==INFNAN_NEGATIVE_INF_LONG_SIGNATURE){return(negative_inf_replacement);}
  if(v.l==INFNAN_NAN_LONG_SIGNATURE){return(nan_replacement);}
  if(v.l==INFNAN_NEGATIVE_NAN_LONG_SIGNATURE){return(negative_nan_replacement);}
  }
  return(value);
  }
 
Lorentzos Roussos #: This catches them , faster than strings i assume . thanks the replacement #'s were for show
👍
 
Alain Verleyen #:

Actually I am thinking, maybe, for performance reason, there could be cases where it's better to check the result. But it depends of the specific logic.

As a general rule though I would check for the "cause".

yeah , the question then is do i trust the forecast if i have been containing the values 

There is also the choice of "Irregular Forecast" and passing that to the user
123
New comment