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

WebIDL definition for constant(start, end, step, type) is missing #571

Closed
inexorabletash opened this issue Feb 15, 2024 · 5 comments
Closed

Comments

@inexorabletash
Copy link
Contributor

The range-based constant(start, end, step, type) is defined with an algorithm, but there's no corresponding WebIDL declaration for it.

@inexorabletash
Copy link
Contributor Author

The prose implies it would be:

    // Create an operand for a constant 1-D tensor of the specified type and range.
    MLOperand constant(float start, float end, float step, optional MLOperandDataType type = "float32");

... But I notice that constant(value, type) defines value as double in the IDL but float in the prose (which, as an aside, is a good reason to NOT duplicate definitions manually). I assume it is double so that int32/uint32 can be passed with full fidelity, so maybe this should be:

    // Create an operand for a constant 1-D tensor of the specified type and range.
    MLOperand constant(double start, double end, double step, optional MLOperandDataType type = "float32");

... and then update the prose for this and the other constant() to say double.

@zolkis
Copy link
Collaborator

zolkis commented Feb 16, 2024

SGTM. @huningxin WDYT?

@huningxin
Copy link
Contributor

We may also need to consider the int64 (bigint), as being discussed in #492 (comment).

@inexorabletash
Copy link
Contributor Author

Yeah... we could merge this with #492 (i.e. defer spec changes until the issues over there are sorted) or put in IDL for now and revisit as the API shape and int64 handling is resolved. Whatever the editors want!

@inexorabletash
Copy link
Contributor Author

Marking this as a duplicate of #492

(I had simply missed that other issue when filing this one, and it seems like we have traction there so a "quick fix" of just writing down the current IDL isn't needed.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants