Menu

#2174 functions not evaluated correctly if "angles degrees" is on

None
closed-rejected
nobody
2019-05-26
2019-05-22
hidetzugu
No

Hey, I just notticed some unexpected behavior when I plot some functions with "set angles degrees". I made a small demonstration script in which I compare the "degree version" of the plot to a "convert to radians and then plot" version (which behaves correctly).

I'm on ubuntu 18, using version 5.2 patch 2

best regards,
hide

Edit:
to simplify the problem I'll use a simpler function than the original ones:

plot [-pi:pi] sin(x)/x

and

set angles degrees 
plot [-180:180] sin(x)/x

should both present the max at (0,1), while for the second case the max is at (0,~0.017)

3 Attachments

Discussion

  • hidetzugu

    hidetzugu - 2019-05-22
    • summary: functions not evaluated correctly it "angles degrees" is on --> functions not evaluated correctly if "angles degrees" is on
    • Group: -->
    • Priority: -->
     
  • Hans-Bernhard Broeker

    The effect you see is because your test case is wrong. To get what you wanted to, the correct version of the last line of the script is:

    plot [-30:30] (x-sin(d2r(x)))/x lw 2 t "(x-sin(x))/x",(x-tan(d2r(x)))/x lw 2 t "(x-tan(x))/x"
    

    There's no reason to apply that d2r() transformation to xes that are not arguments to angular functions.

     
    • hidetzugu

      hidetzugu - 2019-05-22

      I'm not sure I understand your point since I am giving an argument in degrees when that plot operates in radians, I do need to convert the unit in the entire expression.

      regardless, you are correcting the expression that is behaving correctly to match the one that is not. I could also have just presented the results of the second plot in radians, the point I'm trying to make is that Lim{x->0}{(x-sin(x))/x}==0 (similarly to my other expression), which is presented correctly if gnuplot is set to radians but not if it's set to degrees.

      Your example does show where the problem lies: when angles are set to degrees and a variable is used in a trignometric function the variable is, by definition, an angle and must therefore be converted in the entire expression, not just inside the trignometric functions

       
  • Hans-Bernhard Broeker

    • status: open --> closed-not-a-bug
     
    • hidetzugu

      hidetzugu - 2019-05-22
       

      Last edit: hidetzugu 2019-05-22
  • hidetzugu

    hidetzugu - 2019-05-22
    • status: closed-not-a-bug --> open
     
    • hidetzugu

      hidetzugu - 2019-05-22

      to simplify the problem:

      plot [-pi:pi] sin(x)/x
      

      and

      set angles degrees 
      plot [-180:180] sin(x)/x
      

      should both present the max at (0,1), while for the second case the max is at (0,~0.017)

       

      Last edit: hidetzugu 2019-05-22
      • Hans-Bernhard Broeker

        No, they should not, because they're really different functions. The result that

        lim(x-->0, sin(x)/x) = 1.0
        

        holds only for the analytical definition of sin(), which has its argument in radians. That's effectively because the slope of that sin(x) approaches 1.0 as x approaches 0.

        None of that is correct if angles are expressed in degrees. The slope of sin(x), x in degrees, is not 1.0 anywhere. At its steepest, i.e. for x==0, the slope is actually pi/180, so your result has to be pi/180. And that's what the ~0.017 you found is.

        To sum this up: gnuplot's implementation is correct, your reasoning isn't.

         
        • hidetzugu

          hidetzugu - 2019-05-23

          holds only for the analytical definition of sin(), which has its argument in radians

          as oposed to which definition?

          we seem to be odds in our expectations:
          you expect "set angles degrees" to change the trignometic functions so that sin(x)->sinº(x), where sinº(x)=sin(x pi/180). I'm sorry if I'm mistaken (I'm a physicist, not a mathematician) but you did not manage to convince me this is correct (a quick google search shows that we are not the only ones having this argument).

          I would argue that, as you said, sin() has is arguments in radians, only in radians. So I would want "set angles degrees" to update the unit of the variable sin(x)->sin(xº), where xº=x pi/180. to do this gnuplot would have to, while parsing an expression, check if there is a trignometric identy in the expression and the update the variable if there was. So I would want x->xº. notice that I wrote

          set angles degrees; plot sin(x)/x
          

          which in that order reads "have my angles be input in degrees, plot sin(x)/x". if the parser allowed for

          plot sin(xº)/x
          

          or

          plot sind(x)/x
          

          I would expect the same behviour as you.

          Anyway, I'm not involved in the project so now what this devolved into a discussion about mathematics and semathics I won't bother you anymore. I'd say pole a few users on it.

           

          Last edit: hidetzugu 2019-05-23
          • Hans-Bernhard Broeker

            as oposed to which definition?

            As opposed to the one in gnuplot's degrees mode.

            you expect "set angles degrees" to change the trignometic functions so that sin(x)->sinº(x), where sinº(x)=sin(x pi/180).

            Of course I do. Because that's (part of) how set angles degrees is defined to behave. It's all right there in the documentation, if you just care to look.

            a quick google search shows that we are not the only ones having this argument

            Care pointing to some examples of such discussions? I've been with this project since before Google even existed, and I'm pretty sure nobody brought up this particular issue where it would actually make sense to do so: in the mailing list, newsgroup or any other support medium of the actual gnuplot project.

            check if there is a trignometric identy in the expression and the update the variable if there was.

            Are you really not aware how completely impossible that goal is?

             

            Last edit: Hans-Bernhard Broeker 2019-05-23
  • Ethan Merritt

    Ethan Merritt - 2019-05-26
    • status: open --> closed-rejected
     

Log in to post a comment.