As long as the two amounts are equal, any one of them is a valid minimum. Consider MathMin(1, 1), it does not differ if the function returns the first (1) or second (1).
So, returning 0.0 is not different from -0.0.
Edit: by the way, the two highlighted expressions are NOT identical.
I think I agree with my colleague amrali. I would also add that there is a native function MathMin(). It also thinks that zeros with different signs are equal. As far as I understand, its algorithm is quite simple. I duplicated it in my CustomMathMin() function.
//+------------------------------------------------------------------+//| Script program start function |//+------------------------------------------------------------------+voidOnStart()
{
double positive_zero_val, negative_zero_val;
positive_zero_val = 0.0;
negative_zero_val = -0.0;
// 1) -0.0 / 0.0double native_min_val, custom_min_val;
native_min_val = ::MathMin(negative_zero_val, positive_zero_val);
custom_min_val = CustomMathMin(negative_zero_val, positive_zero_val);
::Print("\nArguments: -0.0, 0.0");
::PrintFormat("Native min value = %0.2f", native_min_val);
::PrintFormat("Custom min value = %0.2f", custom_min_val);
// 2) 0.0 / -0.0
native_min_val = ::MathMin(positive_zero_val, negative_zero_val);
custom_min_val = CustomMathMin(positive_zero_val, negative_zero_val);
::Print("\nArguments: 0.0, -0.0");
::PrintFormat("Native min value = %0.2f", native_min_val);
::PrintFormat("Custom min value = %0.2f", custom_min_val);
}
//+------------------------------------------------------------------+//| Custom MathMin |//+------------------------------------------------------------------+double CustomMathMin(double value1, double value2)
{
if(value1 < value2)
return value1;
return value2;
}
//+------------------------------------------------------------------+
We have it in the log:
2024.01.2923:49:46.351 c11 (EURUSD,H1) Arguments: -0.0, 0.02024.01.2923:49:46.351 c11 (EURUSD,H1) Native min value = 0.002024.01.2923:49:46.351 c11 (EURUSD,H1) Custom min value = 0.002024.01.2923:49:46.351 c11 (EURUSD,H1)
2024.01.2923:49:46.351 c11 (EURUSD,H1) Arguments: 0.0, -0.02024.01.2923:49:46.351 c11 (EURUSD,H1) Native min value = -0.002024.01.2923:49:46.351 c11 (EURUSD,H1) Custom min value = -0.00
It is easy to see that from two equal numbers, the algorithm will take the second number as the minimum value of...
I know the question very well, so I wrote both variants of MathMin to show that mathematically identical functions in programming languages produce different results.
template <typename T>
T ToType( constdouble Num )
{
union UNION
{
T Num1;
double Num2;
} Union;
Union.Num2 = Num;
return(Union.Num1);
}
voidOnStart()
{
Print(ToType<long>(MathMin(-0.0, 0.0))); // 0Print(ToType<long>(MathMin(0.0, -0.0))); // -9223372036854775808
}
I have an excellent understanding of the question, so I wrote both versions of MathMin to show that mathematically identical functions in programming languages produce different results.
template <typename T>
T ToType( constdouble Num )
{
union UNION
{
T Num1;
double Num2;
} Union;
Union.Num2 = Num;
return(Union.Num1);
}
voidOnStart()
{
Print(ToType<long>(MathMin(-0.0, 0.0))); // 0Print(ToType<long>(MathMin(0.0, -0.0))); // -9223372036854775808
}
So what is unusual? The fact that in the numbers 0.0 and -0.0 not all 64 bits are the same is obvious:
So what is unusual? The fact that in the numbers 0.0 and -0.0 not all 64 bits are the same is obvious:
It expects MathMin() to be deterministic. So to always give the same result when the two arguments are the same. And not a different result depending on which argument is first or second.
It expects the MathMin() function to be deterministic. So to always give the same result when the two arguments are the same. And not a different result depending on which argument is first or second....
And it is. When 2 numbers are equal, the second one is returned. I have shown above with an example...
It expects the MathMin() function to be deterministic. So to always give the same result when the two arguments are the same. And not a different result depending on which argument is first or second.
fxsaber is right, this is a problem.
You've got my point right. You can run into the hard-to-find issue of getting different results in large code. That's why I notified the community in this thread.
It expects the MathMin() function to be deterministic. So to always give the same result when the two arguments are the same. And not a different result depending on which argument is first or second.
fxsaber is right, this is a problem.
ahhh..., then why was it so confusing about " Mathematically the same expression (highlighted) " and union was enough:
As long as the two amounts are equal, any one of them is a valid minimum. Consider MathMin(1, 1), it does not differ if the function returns the first (1) or second (1).
So, returning 0.0 is not different from -0.0.
Edit: by the way, the two highlighted expressions are NOT identical.I think I agree with my colleague amrali. I would also add that there is a native function MathMin(). It also thinks that zeros with different signs are equal. As far as I understand, its algorithm is quite simple. I duplicated it in my CustomMathMin() function.
We have it in the log:
It is easy to see that from two equal numbers, the algorithm will take the second number as the minimum value of...
You refuse to understand.
it's nothing special. Just -0.0==0.0.
nothing special. Just -0.0==0.0
I know the question very well, so I wrote both variants of MathMin to show that mathematically identical functions in programming languages produce different results.
I have an excellent understanding of the question, so I wrote both versions of MathMin to show that mathematically identical functions in programming languages produce different results.
So what is unusual?
The fact that in the numbers 0.0 and -0.0 not all 64 bits are the same is obvious:
but still 0.0 == -0.0
The < and <= signs seem to be different.....
agree
So what is unusual?
The fact that in the numbers 0.0 and -0.0 not all 64 bits are the same is obvious:
It expects MathMin() to be deterministic. So to always give the same result when the two arguments are the same. And not a different result depending on which argument is first or second.
fxsaber is right, this is a problem.
It expects the MathMin() function to be deterministic. So to always give the same result when the two arguments are the same. And not a different result depending on which argument is first or second....
And it is. When 2 numbers are equal, the second one is returned. I have shown above with an example...
and there's nothing wrong with that.
It expects the MathMin() function to be deterministic. So to always give the same result when the two arguments are the same. And not a different result depending on which argument is first or second.
fxsaber is right, this is a problem.
You've got my point right. You can run into the hard-to-find issue of getting different results in large code. That's why I notified the community in this thread.
It expects the MathMin() function to be deterministic. So to always give the same result when the two arguments are the same. And not a different result depending on which argument is first or second.
fxsaber is right, this is a problem.
ahhh..., then why was it so confusing about " Mathematically the same expression (highlighted) " and union
was enough:
but since 0.0 == -0.0, then I can't imagine a situation where this could be a problem and, affect anything at all