Angle.f parameters always in radians

Psychophanta · Post by **Psychophanta** » Fri Jun 24, 2005 4:44 pm

Please, for consistence and elegance consider Angle.f parameter value given as radians, not as degrees, for all the functions

Blade · Post by **Blade** » Fri Jun 24, 2005 5:47 pm

Why not all degrees? Despite I know what radiants are, degrees are much more easy to handle...

Kale · Post by **Kale** » Fri Jun 24, 2005 5:53 pm

What about adding a flag to support each?

Code: Select all

SomeProcedure(Angle.f, #PB_Radians)
SomeProcedure(Angle.f, #PB_Degrees)

Post by **Polo** » Fri Jun 24, 2005 7:29 pm

Well, it's so much easier to use degrees for that kind of stuff

MikeB · Post by **MikeB** » Fri Jun 24, 2005 7:39 pm

I feel that being able to use either is the obviously preferrable way, some mathmatics require the use of radians if you want to make things simpler, but I would say that while nearly everybody can visualise an angle expressed in degrees, they would have no idea what the same angle in radians meant. Likewise describing a circle and plotting the points is much simpler working with 360° than with 2*PI. If I could only have one way I would go for degrees.

MikeB

Psychophanta · Post by **Psychophanta** » Fri Jun 24, 2005 7:54 pm

Angles in degrees couldn't be done. One of the reasons is that Intel FPUs work with radians (and of course all well done FPUs), and to do a programming language that use degrees would be slower for calculations.
So, i request to use radians for all, for RotateSprite3D(), etc...
matter of consistence

Blade · Post by **Blade** » Fri Jun 24, 2005 9:37 pm

So there IS a reason to use radiants... at last

Still don't know why a "well done FPU" has to use them...

I remember when 8bit computer games used "8bit Degrees", ranging from 0 to 255 ... for optimization purposes... Programmes have always to use annoying things instead of easy ones, for optimization purposes

fweil · Post by **fweil** » Fri Jun 24, 2005 9:43 pm

The reason why radians is the base is easy to understand :

all trigonoetrics are radians based, and all degrees parametering is Pi / 180 based (which is more costy).

Definitely, you have to agree that radians should be the fastest way to compute any trigonometrical value.

But maybe some commands would take some benefit in providing a Radian / Degree flag, except that it would cost a test sequence.

Well, I guess that this post has its roots in that PureBasic provides some (or maybe less than some) instructions with a Degree definition. It should be a Radian float.

But with some use of the language, I did not notice even that, just reading the documentation gives information.

Psychophanta · Post by **Psychophanta** » Fri Jun 24, 2005 9:46 pm

Blade wrote:Still don't know why a "well done FPU" has to use them...

Yeah! that's because you are not in use with geometry, trigonometry or general calculations
In the past i said just same as you about degrees, but it is no good for heavy and/or light calculations, trust me

Blade · Post by **Blade** » Fri Jun 24, 2005 10:00 pm

Have to admit I've never used trigonometry a lot. I had many times, but just for small calculations, never coded something mainly based on trigonometry and such...
Ok, I thrust you...

fweil · Post by **fweil** » Fri Jun 24, 2005 10:09 pm

Just a point messing with Degree instructions in PureBasic : remember that when you think in degrees, you maybe want to STEP by one... which means integers.

But if you want to step by a float value, it is no more of interest to work in degrees because behind the FPU will translate it in radians.

Just with this, try to think all angles in radians and last do a Degree_Angle.l (or .f) = Radian_Angle * Pi / 180

It is generally not slower and makes all trigonometrics more clear.

Psychophanta · Post by **Psychophanta** » Sat Jun 25, 2005 9:28 am

fweil wrote:Just with this, try to think all angles in radians and last do a Degree_Angle.l (or .f) = Radian_Angle * Pi / 180
It is generally not slower and makes all trigonometrics more clear.

hah! You see?, just for explaining, and you had one mistake:

Degree_Angle.l (or .f) = Radian_Angle * Pi / 180

And yes, this takes too much CPU time when operation time is critical.

fweil · Post by **fweil** » Sat Jun 25, 2005 2:37 pm

When it is time critical and just want to use degrees, I usually create arrays for Sin, Cos and Tan, ie, that allow to write MySinus(Degree)

It saves much CPU time

Psychophanta · Post by **Psychophanta** » Sat Jun 25, 2005 2:40 pm

fweil wrote:When it is time critical and just want to use degrees, I usually create arrays for Sin, Cos and Tan, ie, that allow to write MySinus(Degree)

It saves much CPU time

Strange and inefficent way to save CPU time

fweil · Post by **fweil** » Sat Jun 25, 2005 8:19 pm

Did you really have a look ?

Code: Select all

Dim Sinus.f(359)
Dim Cosinus.f(359)
Dim Tangente.f(359)

  Pi.f = 3.14159265
  For i = 0 To 359
    Sinus(i) = Sin(i * Pi / 180)
    Cosinus(i) = Cos(i * Pi / 180)
    Tangente(i) = Tan(i * Pi / 180)
  Next
  
  NTimes = 10000000
  OpenConsole()
    
    tz = ElapsedMilliseconds()
    For i = 1 To NTimes
      Angle.l = Random(359)
      s.f = Sin(Angle * Pi / 180)
      c.f = Cos(Angle * Pi / 180)
      t.f = Tan(Angle * Pi / 180)
    Next
    PrintN(Str(ElapsedMilliseconds() - tz) + " " + StrF(Sin(45 * Pi / 180)))
    
    tz = ElapsedMilliseconds()
    For i = 1 To NTimes
      Angle.l = Random(359)
      s.f = Sinus(Angle)
      c.f = Cosinus(Angle)
      t.f = Tangente(Angle)
    Next
    PrintN(Str(ElapsedMilliseconds() - tz) + " " + StrF(Sinus(45)))
    
    While Inkey() = ""
    Wend
    
  CloseConsole()
  
End