-0 bug

[Rundom]

 If we trying to round a very small negative number using decimal places parameter, we will got a -0 as result. After parsing, autoit interprets  this number as a value, that lesser then zero.

 So I can use this as example:
ConsoleWrite(round(cos(270 * (3.141592653589793 / 180)),4))

We know, that cosine of 270 degrees obviously equals 0, but here we got -0.

In this code you can see, how it can a bit screw up our calculations:

;~ Radius of a circle
$radius = 35


   for $i = 0 to 360
      ;~ Here we found positions on a circle using cosins of an angle for X and sine for Y
      $x = Round((Cos(DTR($i)) * $radius), 4)
      $y = Round((Sin(DTR($i)) * $radius), 4)

;~       Here we output our values of true degrees, X and Y positions.
      ConsoleWrite($i & " " & $x & " / " & $y & " ")
      
;~       Here we trying to ouput degrees using arctangent of Y/X (Which is tangent of our angle)
      ConsoleWrite(Round(RTD(ATan($y / $x),$x,$y)) & @LF)
      
   Next

;~ Degrees to radians
Func DTR($deg)
   Return $deg * (3.141592653589793/180)
EndFunc

;~ Radians to degrees
Func RTD($rad, $x, $y)
   if $x >= 0 and $y >= 0 Then
      Return $rad *(180/3.141592653589793)
   Elseif $x < 0 Then
      Return $rad *(180/3.141592653589793) + 180
   Else
      Return $rad *(180/3.141592653589793) + 360
   EndIf
EndFunc

As you can see, on angles 270 and 360 this code ouputs wrong values of angles.

[jchd]

This is nothing new. Floating point operations very often give inexact results which only surprise beginners. This is due to the limited precision of the binary representation used. For instance as shown below, 0.75 = 0.5 + 0.25 has a bounded representation as fractional binary (1/2 + 1/4). On the contrary, 0.3 doesn't enjoy the same property and it would need an infinite string of decreasing powers of 2 to represent: its floating point representation is inexact.

IEEE754 also specifically allows for two distinct (yet equal) signed representations of zero: +0.0 and -0.0 as shown by the code below

ConsoleWrite(Hex(0.75) & @LF)
ConsoleWrite(Hex(0.3) & @LF)

ConsoleWrite("0.0 = " & Hex(0.0) & @LF)
ConsoleWrite("-0.0 = " & Hex(-0.0) & @LF)
ConsoleWrite("0.0 = -0.0 " & (0.0 = -0.0) & @LF)
ConsoleWrite("-0.0 > 0 " & (-0.0 > 0) & @LF)
ConsoleWrite("-0.0 < 0 " & (-0.0 < 0) & @LF)

[Rundom]

Thanks for help, but I tried to write the same code in java and do not face this trouble.

import static java.lang.Math.*;

public class Main {
    public static void main (String[] args){

        double radius = 35, x, y;

        for (int i = 0; i != 361 ; i++){
            x = (double)round((cos(DTR(i)) * radius)*10000)/10000;
            y = (double)round((sin(DTR(i)) * radius)*10000)/10000;
            long angle = round(RTD(atan(y / x),x,y));
            System.out.println(i + " " + x + " / " + y + " "+angle);
        }

    }
    static double DTR(int deg){
        return deg * (PI/180);
    }
    static double RTD(double rad, double x, double y){
        if (x >= 0 && y >= 0) {
            return rad *(180/PI);}
        else if (x < 0) {
            return rad *(180/PI) + 180;}
        else{
            return rad *(180/PI) + 360;}
    }
}

[jchd]

I don't know what you expect to deduce from such comparison. Java is a very different language and one of its specification is that it provides the same results whatever hardware/software platform a Java program is run on. That by itself puts severe constraints, especially on FP operations. I don't know enough the specifications and internals of Java, but it's likely it uses tha most conservative approach and settings for FP in order to guarantee portability.

At any rate rounding errors, truncation and subtly varying results is what you can reasonnably expect from binary FP.