[SPARK-23329][SQL] Fix documentation of trigonometric functions #20618

misutoth · 2018-02-15T09:04:38Z

What changes were proposed in this pull request?

Provide more details in trigonometric function documentations. Referenced java.lang.Math for further details in the descriptions.

How was this patch tested?

Ran full build, checked generated documentation manually

srowen · 2018-02-15T15:12:08Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

consine -> cosine
For the hyperbolic functions, you can just describe the argument as a "hyperbolic angle". This description is redundant with the "Returns ..." description above.

I was not very familiar with hyperbolic functions so I followed the way this is described in java.lang.Math. But hyperbolic angle is really what this parameter actually is.

srowen · 2018-02-15T15:29:21Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

It looks like the declaration of atan2 should group with the trig functions. I think that's OK to fix here.

I believe this should still be moved with this change.

Now I got it. Sorry, earlier I just misunderstood it. Are you proposing to move this case class inside the file to be next to the other trigonometric function? Based on the comments it seems the functions are group based on the number of arguments. This function has 2 arguments that is why it is under // Binary math functions section. Even though this does not seem to create big cohesion inside such a group I guess we do not want to reorganize the file now?

Oh, I get it now, that's my mistake. "Binary" means "two arg" and not perhaps "bitwise" or something. Leave it then.

srowen · 2018-02-15T15:30:11Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

I'd revert the whitespace changes here, or at least only make changes that make the spacing consistent.

srowen · 2018-02-15T15:32:09Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

I'd use the same description here as above, for all of these functions. The one above looks better to me. Up to you whether you want to talk about the range of the return value or leave that to the Math.acos docs; it should just be consistent.

Also "cosine inverse" -> "inverse cosine", and make it clear as you do above that it's a synonym for arc cosine.

~~Ok.~~

~~Then I will cut the part about the domains and ranges.~~

I am not sure what you mean on above. Do you mean reverting this part of the change?

How about simply @return the angle whose cosine is 'e' and refer to java.lang.Math for further details?

srowen · 2018-02-15T15:32:44Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

Why change columnName -> colName? doesn't seem to matter, so I'd avoid changing it if so.

columnName was too long and it ran into the description in the generated doc.

I don't think we should change the name for that reason ..

srowen · 2018-02-15T15:33:57Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

Here and below -- it's not clear how ordinate and abscissa relate to the function's description. Above it's described more simply as the coordinates of a point in the plane, and I think that's more recognizable than these terms.

Sure, I will fix that. I borrowed that from java.lang.Math ... which sometimes is more complicated than it should be.

srowen · 2018-02-15T15:34:14Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

This should be reverted.

HyukjinKwon · 2018-02-16T03:41:55Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

Could we just save one line and stick to the same indentation?

arguments = """ Arguments: * expr - number whose arc tangent is to be returned. """, examples = """ ...

HyukjinKwon · 2018-02-16T03:51:43Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

I think we can just do as below:

... usage = """ _FUNC_(expr) - Returns hyperbolic sine of `expr`, as if computed by `java.lang.Math._FUNC_`. """, ...

srowen · 2018-02-19T14:11:27Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

I believe this should still be moved with this change.

srowen · 2018-02-19T14:11:58Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

   */
  def acos(e: Column): Column = withExpr { Acos(e.expr) }

+  // scalastyle:off line.size.limit


You should be able to just wrap comments rather than disable this?

srowen · 2018-02-19T14:12:45Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

  /**
-   * Computes the cosine inverse of the given column; the returned angle is in the range
-   * 0.0 through pi.
+   * @return angle in radians whose cosine is `columnName` as if computed by [[java.lang.Math#acos]]


It's not a big deal, but this change also makes the way this inverse function is described inconsistent with how it's described above. I think it's best to make them the same.

srowen · 2018-02-19T14:12:56Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

  /**
-   * Returns the angle theta from the conversion of rectangular coordinates (x, y) to
-   * polar coordinates (r, theta). Units in radians.
+   *


Tiny nit: remove this first blank line.

srowen · 2018-02-19T14:13:28Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

  /**
-   * Computes the cosine of the given column.
+   * @param columnName angle in radians
+   * @return           cosine of the angle, as if computed by [[java.lang.Math#cos]]


You don't need to line these up, especially if it makes it extend past the line limit or wrap.

…ctions

misutoth · 2018-02-19T15:37:11Z

Thanks @srowen and @HyukjinKwon for your comments so far ...

HyukjinKwon · 2018-02-19T22:22:29Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

  """)
 case class Sin(child: Expression) extends UnaryMathExpression(math.sin, "SIN")

+// scalastyle:off line.size.limit


I think we should turn this on again

HyukjinKwon · 2018-02-19T22:23:20Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

-  usage = "_FUNC_(expr) - Returns the sine of `expr`.",
+  usage = "_FUNC_(expr) - Returns the sine of `expr`, as if computed by `java.lang.Math._FUNC_`.",
+  arguments =
+    """


Can we have the same format for it and the same instances - #20618 (comment)?

Yes, I applied to all places in scope.

HyukjinKwon · 2018-02-19T22:25:28Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

  """)
 case class Sqrt(child: Expression) extends UnaryMathExpression(math.sqrt, "SQRT")

+// scalastyle:off line.size.limit


Ditto for turning it on

Turned it on for all trigonometric functions.

HyukjinKwon · 2018-02-19T22:25:40Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala


 @ExpressionDescription(
-  usage = "_FUNC_(expr) - Returns the cotangent of `expr`.",
+  usage = "_FUNC_(expr) - Returns the cotangent of `expr` ," +


Ditto for formatting

HyukjinKwon · 2018-02-19T22:26:20Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala


 @ExpressionDescription(
-  usage = "_FUNC_(expr) - Returns the hyperbolic tangent of `expr`.",
+  usage = "_FUNC_(expr) - Returns the hyperbolic tangent of `expr`, as if computed by `java.lang.Math._FUNC_`.",


Seems line limit is reached here.

HyukjinKwon · 2018-02-19T22:26:56Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

  }
 }

-


Seems unrelated change. Could we just revert this back?

HyukjinKwon · 2018-02-19T22:27:05Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

 case class Hypot(left: Expression, right: Expression)
  extends BinaryMathExpression(math.hypot, "HYPOT")

-


Ditto for revert

HyukjinKwon · 2018-02-19T22:28:22Z

ok to test

…k removals

SparkQA · 2018-02-20T01:48:15Z

Test build #87546 has finished for PR 20618 at commit 168d7b3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

SparkQA · 2018-02-20T02:26:48Z

Test build #87547 has finished for PR 20618 at commit 2586b0f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

HyukjinKwon · 2018-02-20T03:59:31Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

 @ExpressionDescription(
  usage = "_FUNC_(expr) - Returns the hyperbolic cosine of `expr`.",
+  arguments =
+    """


I mean ...

arguments = """ Arguments: * expr - hyperbolic angle. """,

to be consistent other styles here. For example:

spark/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/regexpExpressions.scala

Lines 156 to 168 in 5683984

arguments = """

Arguments:

* str - a string expression

* regexp - a string expression. The pattern string should be a Java regular expression.

Since Spark 2.0, string literals (including regex patterns) are unescaped in our SQL

parser. For example, to match "\abc", a regular expression for `regexp` can be

"^\\abc$".

There is a SQL config 'spark.sql.parser.escapedStringLiterals' that can be used to

fallback to the Spark 1.6 behavior regarding string literal parsing. For example,

if the config is enabled, the `regexp` that can match "\abc" is "^\abc$".

""",

You are right, I will fix this.

HyukjinKwon · 2018-02-20T04:00:21Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

 @ExpressionDescription(
-  usage = "_FUNC_(expr) - Returns the hyperbolic sine of `expr`.",
+  usage = """
+  _FUNC_(expr) - Returns hyperbolic sine of `expr`, as if computed by


I think we need double spaces ahead - I think the key is consistency but less invasive / targeted change.

HyukjinKwon · 2018-02-20T04:02:54Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala


  /**
-   * Computes the cosine inverse of the given value; the returned angle is in the range
-   * 0.0 through pi.


I am sorry if I missed a discussion about this. Why don't we keep this simple description for this method rather than removing out?

If we go this way, we should update both functions.py and functions.R. If you strongly prefer this, I would like to suggest to do this separately in another PR for both places together.

Seems like a valid point and I tend to agree with the conclusion to create a separate Jira for this. So far the discussion was about {{functions.scala}} but other languages should offer similar descriptions for the same thing. @srowen, can you please comment on this? I will take {{functions.scala}} out for now.

…ed functions.scala changes because it should be updated with functions.py and functions.R

HyukjinKwon

LGTM otherwise

HyukjinKwon · 2018-02-20T12:09:24Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala


  /**
-   * @param e hyperbolic angle
-   * @return hyperbolic tangent of the given value, as if computed by [[java.lang.Math#tanh]]


Oh, but the @param and @return were fine .. I thought a doc like:

* Computes the hyperbolic tangent of the given value. * * @param e hyperbolic angle * @return hyperbolic tangent computed by [[java.lang.Math#tanh]]

This way the description and the return value text would be redundant. For this reason it was proposed during the discussion of the issue to keep only the @return part.

HyukjinKwon · 2018-02-20T12:11:31Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

+  arguments = """
+    Arguments:
+      * expr - angle in radians
+    """,


Let's remote two spaces ->

* expr - angle in radians """,

yes, indeed that is used elsewhere

HyukjinKwon · 2018-02-20T12:14:13Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

  usage = "_FUNC_(expr) - Returns the hyperbolic cosine of `expr`.",
+  arguments = """
+    Arguments:
+      * expr - hyperbolic angle.


not a big deal but let's remove the trailing . for consistency.

HyukjinKwon · 2018-02-20T12:39:17Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

 case class Cos(child: Expression) extends UnaryMathExpression(math.cos, "COS")

 @ExpressionDescription(
  usage = "_FUNC_(expr) - Returns the hyperbolic cosine of `expr`.",


Shall we add java.lang.Math. _FUNC_ here too?

Yes, we should

HyukjinKwon · 2018-02-20T12:40:07Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

-  usage = "_FUNC_(expr) - Returns the tangent of `expr`.",
+  usage = """
+    _FUNC_(expr) - Returns the tangent of `expr`, as if computed by
+      `java.lang.Math._FUNC_`.


Seems the two lines above could fix in one line.

HyukjinKwon · 2018-02-20T12:40:31Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala

-  usage = "_FUNC_(expr) - Returns the cotangent of `expr`.",
+  usage = """
+    _FUNC_(expr) - Returns the cotangent of `expr`, as if computed by
+      `1/java.lang.Math._FUNC_`.


ditto for one line

HyukjinKwon · 2018-02-20T13:53:44Z

@misutoth, I am sorry. I missed #20618 (comment) and discussion in the JIRA.

@srowen, I was thinking about having the same description part in other languages for now. For example,

  * Computes the hyperbolic tangent of the given value.

->

  * Computes the hyperbolic tangent of the given value.  
  *
  * @param e hyperbolic angle
  * @return hyperbolic tangent computed by [[java.lang.Math#tanh]]

What do you think about not touching functions.py and functions.R with the format above even though it might duplicate a bit for now?

My only concern is to have different descriptions in other languages APIs and I am a little bit worried of when we come to fix Python's and R's.

SparkQA · 2018-02-20T14:54:22Z

Test build #87551 has finished for PR 20618 at commit 8550a27.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

srowen · 2018-02-20T14:55:12Z

Consistency is good. You're suggesting updating Python, R separately? If it's a big change, I could see breaking it up, but could also imagine adjusting that here. I am OK with getting this in first as I know we've iterated on this a lot.

HyukjinKwon · 2018-02-20T15:32:39Z

Maybe I am too much caring about this and It guess it wouldn't be a big change; however, I was thinking there might be subtle nits, like, referring java.lang.Math* in Python side and R side which is not preferred up to my knowledge.

Just wanted to avoid another iteration for finding a better description for both Python and R again here. (Just noticed it's his very first contribution to Spark too.).

Seems fine for SQL / Scala / Java as they already use a (fully qualified) class name, for example, in case of SQL:

spark-sql> DESCRIBE FUNCTION EXTENDED cos;
...
Function: cos
Class: org.apache.spark.sql.catalyst.expressions.Cos
...

SparkQA · 2018-02-20T16:25:01Z

Test build #87554 has finished for PR 20618 at commit 40da998.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

misutoth · 2018-02-20T16:36:37Z

Looking back I guess we can expect a couple of comments on R and Python side too, though I will target a lower number of them. :) So I am a little bit favoring moving functions.* update into a separate ticket.

srowen · 2018-02-20T16:45:18Z

@HyukjinKwon I think it's fine to refer to java.lang.Math even from Python, R documents. It's just expressing the API's behavior, and that contract is the same regardless of the language. (Or is there a subtlety I'm missing, like, it's computed different in Python or the behavior of things like NaN isn't the same?) (Or is your point just that you can't easily write hyperlinks to the JDK docs in Python? that's fine, no need for a link.)

HyukjinKwon · 2018-02-20T22:45:15Z

I just thought about this again and yup I am fine. @misutoth shall we just fix R and Python ones too here? I think we could just target to fix the trigonometric functions consistently in other language's APIs too.

misutoth · 2018-02-20T23:00:18Z

Sure, lets do that, no problem.

srowen · 2018-02-22T14:32:29Z

Was the result to add more changes to this PR or add them in another PR?

HyukjinKwon · 2018-02-26T07:15:10Z

cc @felixcheung (I saw you and Felix in dev mailing list). So, https://github.com/apache/spark/tree/master/R#generating-documentation does not work?

felixcheung · 2018-02-27T01:49:24Z

@misutoth what exactly is the problem you are running into?

misutoth · 2018-02-27T17:41:56Z

@felixcheung, I have started a mail thread on [email protected] with title Help needed in R documentation generation because I did not feel it is directly related to this PR. Thanks for your reply on this thread already.

misutoth · 2018-02-27T20:00:22Z

As discussed in email R documentation is reorganized and math functions are grouped as part of SPARK-20889. Because of this grouping I dont think this change is really applicable on R. @srowen, @HyukjinKwon, @felixcheung what do you think about it?

felixcheung · 2018-02-28T08:12:47Z

sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/mathExpressions.scala


 @ExpressionDescription(
-  usage = "_FUNC_(expr) - Returns the sine of `expr`.",
+  usage = "_FUNC_(expr) - Returns the sine of `expr`, as if computed by `java.lang.Math._FUNC_`.",


I don't know the history of why the text is different here vs python/R https://github.com/apache/spark/blob/master/R/pkg/R/functions.R#L1466

I don't think the doc grouping in R is relevant - the text is there. Generally we try to match the text in scala but I don't feel strongly either way in this case.

As far as the trigonometric functions concerned they should be now in sync I think.

… functions.py

SparkQA · 2018-02-28T17:55:13Z

Test build #87796 has finished for PR 20618 at commit 0e4e15a.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

misutoth · 2018-02-28T18:06:56Z

I included java.lang.Math references in functions.R

SparkQA · 2018-02-28T18:10:04Z

Test build #87798 has finished for PR 20618 at commit fcf1338.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

SparkQA · 2018-02-28T21:46:04Z

Test build #87803 has finished for PR 20618 at commit 2ea1f18.

This patch fails Python style tests.
This patch merges cleanly.
This patch adds no public classes.

SparkQA · 2018-03-02T01:41:09Z

Test build #87860 has finished for PR 20618 at commit 10afda5.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

HyukjinKwon · 2018-03-02T11:47:41Z

retest this please

HyukjinKwon · 2018-03-02T11:56:35Z

python/pyspark/sql/functions.py

-    'radians': 'Converts an angle measured in degrees to an approximately equivalent angle ' +
-               'measured in radians.',
+    'degrees': """Converts an angle measured in radians to an approximately equivalent angle
+               measured in degrees.


Let's add a newline here. Seems doc could be broken.

HyukjinKwon

LGTM otherwise.

HyukjinKwon · 2018-03-02T11:57:28Z

python/pyspark/sql/functions.py

+               measured in degrees.
+               :param col: angle in radians
+               :return: angle in degrees, as if computed by `java.lang.Math.toDegrees()`""",
+    'radians': """Converts an angle measured in degrees to an approximately equivalent angle measured in radians.


Seems this hits the line length limit.

Yes. I wrapped the text.

HyukjinKwon · 2018-03-02T12:25:53Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

  /**
-   * Computes the cosine of the given value. Units in radians.
+   * @param e angle in radians
+   * @return cosine of the angle, as if computed by [[java.lang.Math#cos]]


Seems this link is broken in Scaladoc. Let's just use `java.lang.Math.cos` in this file.

Replaced all of them as suggested.

HyukjinKwon · 2018-03-02T12:37:10Z

sql/core/src/main/scala/org/apache/spark/sql/functions.scala

+   * @param yValue coordinate on y-axis
+   * @param xName coordinate on x-axis
+   * @return the <i>theta</i> component of the point
+   *         (<i>r</i>,&nbsp;<i>theta</i>)


nit   -> . Seems broken in Javadoc.

Ok. I have removed the non breaking spaces.

SparkQA · 2018-03-02T15:34:38Z

Test build #87883 has finished for PR 20618 at commit 10afda5.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

SparkQA · 2018-03-03T03:10:08Z

Test build #87914 has finished for PR 20618 at commit 627e204.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

## What changes were proposed in this pull request? Provide more details in trigonometric function documentations. Referenced `java.lang.Math` for further details in the descriptions. ## How was this patch tested? Ran full build, checked generated documentation manually Author: Mihaly Toth <[email protected]> Closes #20618 from misutoth/trigonometric-doc. (cherry picked from commit a366b95) Signed-off-by: hyukjinkwon <[email protected]>

HyukjinKwon · 2018-03-05T14:47:48Z

Merged to master and branch-2.3.

## What changes were proposed in this pull request? Provide more details in trigonometric function documentations. Referenced `java.lang.Math` for further details in the descriptions. ## How was this patch tested? Ran full build, checked generated documentation manually Author: Mihaly Toth <[email protected]> Closes apache#20618 from misutoth/trigonometric-doc.

## What changes were proposed in this pull request? Provide more details in trigonometric function documentations. Referenced `java.lang.Math` for further details in the descriptions. ## How was this patch tested? Ran full build, checked generated documentation manually Author: Mihaly Toth <[email protected]> Closes apache#20618 from misutoth/trigonometric-doc. (cherry picked from commit a366b95) Signed-off-by: hyukjinkwon <[email protected]>

srowen requested changes Feb 15, 2018

View reviewed changes

HyukjinKwon reviewed Feb 16, 2018

View reviewed changes

[SPARK-23329][SQL] Fix documentation of trigonometric functions

0a0c4ae

misutoth force-pushed the trigonometric-doc branch from 25c329b to 0a0c4ae Compare February 16, 2018 15:48

srowen requested changes Feb 19, 2018

View reviewed changes

[SPARK-23329][SQL] Removed unnecessary aligning, reworded inverse fun…

168d7b3

…ctions

srowen approved these changes Feb 19, 2018

View reviewed changes

HyukjinKwon reviewed Feb 19, 2018

View reviewed changes

[SPARK-23329][SQL] Fixed formatting of long lines, reverted line brea…

2586b0f

…k removals

HyukjinKwon reviewed Feb 20, 2018

View reviewed changes

[SPARK-23329][SQL] Make usage text consistent with other docs, revert…

8550a27

…ed functions.scala changes because it should be updated with functions.py and functions.R

HyukjinKwon reviewed Feb 20, 2018

View reviewed changes

[SPARK-23329][SQL] Formatting finetunings

40da998

felixcheung reviewed Feb 28, 2018

View reviewed changes

[SPARK-23329][SQL] Fix documentation of functions.R, functions.scala,…

0e4e15a

… functions.py

[SPARK-23329][SQL] Fixed line length

fcf1338

[SPARK-23329][SQL] Fixed line length of functions.py

2ea1f18

[SPARK-23329][SQL] Fixed python style problem

10afda5

HyukjinKwon reviewed Mar 2, 2018

View reviewed changes

HyukjinKwon approved these changes Mar 2, 2018

View reviewed changes

HyukjinKwon reviewed Mar 2, 2018

View reviewed changes

[SPARK-23329][SQL] Formatting fixes, changed scaladoc references

627e204

srowen approved these changes Mar 3, 2018

View reviewed changes

asfgit closed this in a366b95 Mar 5, 2018

		case class Hypot(left: Expression, right: Expression)
		extends BinaryMathExpression(math.hypot, "HYPOT")

	arguments = """
	Arguments:
	* str - a string expression
	* regexp - a string expression. The pattern string should be a Java regular expression.

	Since Spark 2.0, string literals (including regex patterns) are unescaped in our SQL
	parser. For example, to match "\abc", a regular expression for `regexp` can be
	"^\\abc$".

	There is a SQL config 'spark.sql.parser.escapedStringLiterals' that can be used to
	fallback to the Spark 1.6 behavior regarding string literal parsing. For example,
	if the config is enabled, the `regexp` that can match "\abc" is "^\abc$".
	""",

[SPARK-23329][SQL] Fix documentation of trigonometric functions #20618

[SPARK-23329][SQL] Fix documentation of trigonometric functions #20618

Uh oh!

Conversation

misutoth commented Feb 15, 2018

What changes were proposed in this pull request?

How was this patch tested?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

misutoth Feb 15, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

misutoth commented Feb 19, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HyukjinKwon commented Feb 19, 2018

Uh oh!

misutoth Feb 15, 2018 •

edited

Loading

HyukjinKwon Feb 20, 2018 •

edited

Loading

HyukjinKwon Feb 20, 2018 •

edited

Loading

HyukjinKwon Feb 20, 2018 •

edited

Loading