Exponentiation Operator draft tests by rwaldron · Pull Request #96 · tc39/test262

rwaldron · 2014-09-23T18:36:53Z

This is not expected to land any time soon. It's really just for show.

arv · 2014-09-23T18:50:43Z

👍

domenic · 2014-09-23T18:51:42Z

We don't use runTestCase anymore.

domenic · 2014-09-23T19:00:34Z

LGTM!

rwaldron · 2014-09-23T19:00:49Z

How would >1 author be identified in the author: ... space below?

bterlson · 2014-09-23T19:07:25Z

I think you should remove the ES7 file path.
Also will have to figure out how feature flags are going to work.

bterlson · 2014-12-11T01:42:44Z

At some point this should be updated based on the new file paths (tests would go under language/expressions/exponentiation).

rwaldron · 2014-12-11T17:23:15Z

@bterlson will do, thanks for the ping :)

rwaldron · 2014-12-14T00:05:24Z

@bterlson updated.

Yaffle · 2015-02-28T07:08:14Z

Should the result be exact, if both operands are integers and that result can be exactly represented ?

Yaffle · 2015-03-03T05:52:55Z

Math.pow(3, 1) === 2.999999999999999;
Math.pow(3, 3) === 26.999999999999993;
Math.pow(3, 4) === 80.99999999999997;
in some versions of Opera Classic on Android.
And specification does not have any word about exactness of "Math.pow" for integer ** integer case
Although, other browsers give exact values (when result can be represented exactly).

rwaldron · 2015-03-03T13:57:20Z

@Yaffle I'm going to bring this up at the next TC39 meeting

Yaffle · 2015-06-20T07:54:43Z

 * Accuracy:
 *  pow(x,y) returns x**y nearly rounded. In particular
 *          pow(integer,integer)
 *  always returns the correct integer provided it is 
 *  representable.

source : http://www.netlib.org/fdlibm/e_pow.c

Firefox and Chrome use "exponentiation by squaring" when second arg is a "small" integer, so integer**integer == should be exact

rwaldron · 2016-01-22T22:51:10Z

@bterlson updated with latest tests

leobalter · 2016-01-24T04:52:51Z

this o.p.q test seems more appropriated in a syntax test file, where it gets the value from the lefthandexpression.

goyakin · 2016-01-25T19:50:42Z

Can we add tests for edge cases in the Applying the ** operator section of the proposal?

goyakin · 2016-01-25T19:52:49Z

Since we're testing operator precedence here, shouldn't these be in test/language/expressions/exponentiation/operator-precedence.js instead?

rwaldron · 2016-01-28T18:33:54Z

@goyakin "Applying the ** Operator" is just Math.pow definition, which is tested here: https://github.com/tc39/test262/tree/master/test/built-ins/Math/pow

domenic · 2016-01-28T18:35:29Z

I think you need to actually test that implementations follow the same rules. The spec states they should, but the whole point of test262 is to make sure people are following the spec.

This is similar to how you can't just test a given abstract operation once and assume everywhere that is specced to call it, calls it in implementations. You have to test each call site.

rwaldron · 2016-01-28T18:48:40Z

I think you need to actually test that implementations follow the same rules. The spec states they should, but the whole point of test262 is to make sure people are following the spec.

Are you saying that the same tests should just be duplicated? The spec normatively defines that both ** and Math.pow do the same thing—there's only one definition of the exponentiation operation, and that's defined in the section titled "Applying the ** Operator"

domenic · 2016-01-28T18:49:30Z

Yeah, I think they definitely need to be duplicated. If we had a test-gen framework we would be in better shape. But not duplicating them would be like only testing destructuring assignment, not destructuring binding. The spec says they use the same rules, but we clearly need tests for both.

goyakin · 2016-02-12T18:57:16Z

+assert.sameValue(capture[0], "left");
+assert.sameValue(capture[1], "right");
+assert.sameValue(capture[2], "leftValue");
+assert.sameValue(capture[3], "rightValue");


These need assertion messages.

goyakin · 2016-02-12T19:23:04Z

@rwaldron, things LGTM except a few minor comments I left inline.

rwaldron · 2016-02-15T21:39:35Z

@goyakin I'm pushing a bunch of updates

matched all the descriptions to the text found in the spec, for both Math.pow and Exp Op
made updates according to your feedback points
added a new test for Math.pow (a property verification)
cleaned up descriptions
fixed all ids

rwaldron · 2016-02-22T04:58:05Z

I guess I need to update "id" to "esid"...?

leobalter · 2016-02-22T14:49:20Z

#516 will confirm this, the answer is probably yes.

goyakin · 2016-02-22T17:57:38Z

@rwaldron FYI, I just merged #516.

rwaldron · 2016-02-22T19:47:57Z

@leobalter @goyakin updated and rebased

leobalter · 2016-02-22T20:05:28Z

 description: >
  Math.pow.name is "pow".
-info: >
-  Math.pow ( x, y )


You should keep the info tag here.

leobalter · 2016-02-22T21:51:55Z

LGTM

leobalter · 2016-02-22T21:54:41Z

+
+var capture = [];
+
+(capture.push("left"), leftValue) ** +(capture.push("right"), rightValue);


oops, missing quotes on leftValue and rightValue

No, I accidentally deleted the definitions of those objects. Check the test just before this one

leobalter · 2016-02-22T21:56:06Z

as I mentioned, it LGTM, there's just a minor thing missing (see comment above), preventing the tests to pass.

rwaldron · 2016-02-23T00:18:51Z

@leobalter all set, I fixed that missing object definition

leobalter · 2016-02-23T15:46:37Z

rwaldron · 2016-02-23T17:42:36Z

@goyakin your review points have been addressed. This is all set to go whenever you're ready

goyakin · 2016-02-23T22:31:27Z

@rwaldron Just FYI, I converted info back to description in test/language/expressions/exponentiation/exp-operator.js before merging this PR.

This was referenced Sep 23, 2014

Stage 3 tc39/proposal-exponentiation-operator#3

Closed

Stage 4 tc39/proposal-exponentiation-operator#4

Closed

domenic reviewed Sep 23, 2014
View reviewed changes

Comment thread test/suite/es7/ExponentiationOperator/ExponentiationOperator.js Outdated

domenic Sep 23, 2014

Copy link
Copy Markdown

Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't use runTestCase anymore.

rwaldron reviewed Sep 23, 2014
View reviewed changes

bterlson added the coverage label Oct 24, 2014

bterlson added the future label Dec 10, 2014

rwaldron force-pushed the exponentiation-operator branch 2 times, most recently from f217123 to b544af5 Compare December 14, 2014 00:04

rwaldron force-pushed the exponentiation-operator branch from b544af5 to 8711bcd Compare January 22, 2016 22:50

leobalter reviewed Jan 24, 2016
View reviewed changes

goyakin reviewed Jan 25, 2016
View reviewed changes

goyakin reviewed Feb 12, 2016
View reviewed changes

rwaldron force-pushed the exponentiation-operator branch from 90c1c96 to 36764f0 Compare February 15, 2016 21:40

rwaldron added 2 commits February 22, 2016 14:47

Exponentiation Operator tests

2a112a3

id => esid

2a962f7

rwaldron force-pushed the exponentiation-operator branch from 4c97f1b to 2a962f7 Compare February 22, 2016 19:47

leobalter reviewed Feb 22, 2016
View reviewed changes

rwaldron added 2 commits February 22, 2016 16:41

restore "info"

104a134

improved info and description

b92e686

leobalter reviewed Feb 22, 2016
View reviewed changes

Restore missing object definitions

79dfcf3

descriptions and info

e0afd42

goyakin merged commit e0afd42 into tc39:master Feb 23, 2016


		var capture = [];

		(capture.push("left"), leftValue) ** +(capture.push("right"), rightValue);

Conversation

rwaldron commented Sep 23, 2014

Uh oh!

arv commented Sep 23, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

domenic commented Sep 23, 2014

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bterlson commented Sep 23, 2014

Uh oh!

bterlson commented Dec 11, 2014

Uh oh!

rwaldron commented Dec 11, 2014

Uh oh!

rwaldron commented Dec 14, 2014

Uh oh!

Yaffle commented Feb 28, 2015

Uh oh!

Yaffle commented Mar 3, 2015

Uh oh!

rwaldron commented Mar 3, 2015

Uh oh!

Yaffle commented Jun 20, 2015

Uh oh!

rwaldron commented Jan 22, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

goyakin commented Jan 25, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rwaldron commented Jan 28, 2016

Uh oh!

domenic commented Jan 28, 2016

Uh oh!

rwaldron commented Jan 28, 2016

Uh oh!

domenic commented Jan 28, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

goyakin commented Feb 12, 2016

Uh oh!

rwaldron commented Feb 15, 2016

Uh oh!

rwaldron commented Feb 22, 2016

Uh oh!

leobalter commented Feb 22, 2016

Uh oh!

goyakin commented Feb 22, 2016

Uh oh!

rwaldron commented Feb 22, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

leobalter commented Feb 22, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

leobalter commented Feb 22, 2016

Uh oh!

rwaldron commented Feb 23, 2016

Uh oh!

leobalter commented Feb 23, 2016

Uh oh!

rwaldron commented Feb 23, 2016

Uh oh!

goyakin commented Feb 23, 2016

Uh oh!

Reviewers

Assignees

Labels