Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add more Float16Array cases, and tests for Math.f16round #4017

Merged
merged 5 commits into from
Mar 25, 2024

Conversation

bakkot
Copy link
Contributor

@bakkot bakkot commented Mar 12, 2024

Followup to #3849. Fixes #3828. (Edit: actually I need the dataview methods also, which I'll try to get to soon. Doesn't invalidate these, it's just that more tests are needed. Done.)

The structure of the TypedArray tests is such that you can't easily add tests for just one kind of typed array, so the values I'm adding need to be included in the "expected" lists for each of the typed array types. I automated that rather than doing all those by hand, but I did confirm the three major browser engines all agree (for the non-float16 cases; for the float16 ones I used conversion code I wrote and checked against other sources).

For the get/setFloat16 tests, I just copied the get/setFloat32 tests and modified as appropriate.

@bakkot bakkot requested review from a team as code owners March 12, 2024 18:42
@bakkot bakkot force-pushed the more-float16-cases branch 2 times, most recently from 6233b23 to 0175d96 Compare March 13, 2024 06:32
Copy link
Contributor

@ptomato ptomato left a comment

Choose a reason for hiding this comment

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

I started reviewing this but didn't finish. Here's what I have so far.

Comment on lines -142 to +187
0
0, // 0
1, // 2049
3, // 2051
0, // 0.00006103515625
0, // 0.00006097555160522461
0, // 5.960464477539063e-8
0, // 2.9802322387695312e-8
0, // 2.980232238769532e-8
0, // 8.940696716308594e-8
0, // 1.4901161193847656e-7
0, // 1.490116119384766e-7
224, // 65504
240, // 65520
239, // 65519.99999999999
0, // 0.000061005353927612305
0 // 0.0000610053539276123
Copy link
Contributor

Choose a reason for hiding this comment

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

I didn't check how this is specified, but presumably these are equal to truncate(value) modulo 256, with the appropriate sign modifications for signed int8?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup (though as I say in the OP the values for the non-float16 cases are derived by doing the conversions on existing engines on the assumption they're correct, rather than by hand).

Comment on lines 12 to 16
assert.sameValue(DataView.prototype.getFloat16.length, 1);

verifyNotEnumerable(DataView.prototype.getFloat16, "length");
verifyNotWritable(DataView.prototype.getFloat16, "length");
verifyConfigurable(DataView.prototype.getFloat16, "length");
Copy link
Contributor

Choose a reason for hiding this comment

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

We're trying to prefer verifyProperty over the individual functions in new tests (command applies to other tests of property descriptors as well)

Suggested change
assert.sameValue(DataView.prototype.getFloat16.length, 1);
verifyNotEnumerable(DataView.prototype.getFloat16, "length");
verifyNotWritable(DataView.prototype.getFloat16, "length");
verifyConfigurable(DataView.prototype.getFloat16, "length");
verifyProperty(DataView.prototype.getFloat16, "length", {
value: 1,
enumerable: false,
writable: false,
configurable: true,
});

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just copied these over from getFloat32. Would you prefer to use verifyProperty even if it means inconsistency between getFloat16 and all the other dataview methods? Or I can update the other dataview methods as part of this PR and achieve consistency that way, alternatively.

Copy link
Contributor

Choose a reason for hiding this comment

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

I mean, if you feel like doing the extra cleanup work to update the other dataview methods, great! That would be very kind of you and much appreciated. But it's not a requirement as far as I'm concerned.

I do prefer that we don't introduce new tests using APIs that we're trying to phase out, even if it means temporary inconsistency. If we preferred consistency, it'd mean more and more work for the person eventually doing the cleanup.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Opened #4023. I'll update whichever PR lands second to match the other.


assert.throws(TypeError, () => {
let dv = new DataView(new ArrayBuffer(16)); new dv.getFloat16(0, 0);
}, '`let dv = new DataView(new ArrayBuffer(16)); new dv.getFloat16(0, 0)` throws TypeError');
Copy link
Contributor

Choose a reason for hiding this comment

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

Nitpick: I know the other not-a-constructor tests have these autogenerated assert messages, but let's not add more 😝
Could I suggest "DataView.prototype.getFloat16 should not be a constructor" and "Constructing DataView.prototype.getFloat16 should throw TypeError"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure. Would you also like me to update the tests I copied this from?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Opened #4024.

Comment on lines +9 to +13
assert.sameValue(
typeof ArrayBuffer.prototype.resize,
'function',
'implements ArrayBuffer.prototype.resize'
);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this necessary if we have the feature flag?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just copied this from the existing getFloat32 test. I don't think it's necessary but I would prefer the new tests match existing ones.

Copy link
Contributor

@syg syg left a comment

Choose a reason for hiding this comment

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

Correctness lgtm. I don't have much of an opinion on the style of these tests.

Copy link
Contributor

@ptomato ptomato left a comment

Choose a reason for hiding this comment

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

I finished the rest of the review. All good with me, and many thanks for doing this. As for verifyProperty, I'd prefer if we could use verifyProperty in the new tests but I wouldn't block on it.

Comment on lines +13 to +29
assert.throws(TypeError, function() {
getFloat16.call({});
}, "{}");

assert.throws(TypeError, function() {
getFloat16.call([]);
}, "[]");

var ab = new ArrayBuffer(1);
assert.throws(TypeError, function() {
getFloat16.call(ab);
}, "ArrayBuffer");

var ta = new Int8Array();
assert.throws(TypeError, function() {
getFloat16.call(ta);
}, "TypedArray");
Copy link
Contributor

Choose a reason for hiding this comment

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

Just as a note to myself on future reads of this file and the following one, it's OK that the .call() calls don't have plausible arguments because ToIndex(undefined) is 0.

(It's a common pattern elsewhere in the test corpus that these kinds of tests for RequireInternalSlot throwing forget to provide arguments, and in some of those cases the TypeArray might be coming from the missing argument if the implementation fails to include the test for the wrong receiver. That's not the case here. If you feel like adding them for readability, that's fine with me; also fine if you don't.)

var result;

result = sample.setFloat16(0, 42, true); // 01010001 01000000
assert.sameValue(result, undefined, "returns undefined #1");
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems sufficient to test that the return value is undefined in the following test, which is specifically for that purpose. (However, fine to just leave this in. Not a blocker.)

@ptomato
Copy link
Contributor

ptomato commented Mar 25, 2024

@bakkot Many thanks for #4023 and #4024. I guess this is ready to land after rebasing, then?

@bakkot
Copy link
Contributor Author

bakkot commented Mar 25, 2024

@ptomato Should be. I rebased and re-ran my scripts from those PRs to make the same changes here.

Copy link
Contributor

@ptomato ptomato left a comment

Choose a reason for hiding this comment

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

It's time then! Really appreciate the extra cleanup work as well.

@ptomato ptomato merged commit decf9f2 into main Mar 25, 2024
9 checks passed
@ptomato ptomato deleted the more-float16-cases branch March 25, 2024 22:22
ljharb added a commit to es-shims/Math.f16round that referenced this pull request Mar 27, 2024
harness/byteConversionValues.js Show resolved Hide resolved
harness/byteConversionValues.js Show resolved Hide resolved
harness/byteConversionValues.js Show resolved Hide resolved
harness/byteConversionValues.js Show resolved Hide resolved
ljharb added a commit to es-shims/Math.f16round that referenced this pull request Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tests for Float16Array
4 participants