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

Additional properties for describing restrictions on number values #602

Closed
ralfhandl opened this issue Mar 18, 2016 · 6 comments
Closed

Comments

@ralfhandl
Copy link
Contributor

ralfhandl commented Mar 18, 2016

Sometimes the data provided or accepted by an API ultimately resides in a (relational) database, and most databases have a NUMBER type that allows storing numbers with decimal mantissa. The potential values of a NUMBER column are restricted by

  • precision: number of significant decimal digits
  • scale: the place where the decimal point resides, counted from the right

This can of course be expressed with minimum, maximum, and multipleOf, e.g.

minimum: -9999999.999
maximum: 9999999.999
multipleOf: 1e-3

Yet it would be nicer to just say

precision: 10
scale: 3

This could also be used for DECFLOAT values:

precision: 34
# scale is variable

is a long DECFLOAT, the short one would have precision: 16

@mspiegel
Copy link

Request to amend the proposal such that the following formats are valid:

precision: variable
scale: variable

This corresponds to a true arbitrary precision number. This is also a plain old JSON "number" type according to the JSON specification. It is basically equivalent to the java.lang.BigDecimal type with the caveat that BigDecimal supports at most 2,147,483,647 digits to the right of the decimal point.

precision: variable
scale: 5

This corresponds to a FixedPoint number. The Scala Spire library has a FixedPoint type.

CC: @non he has a lot of experience working with weird number types.

@ralfhandl
Copy link
Contributor Author

Would we want to explicitly state variable/unlimited precision or scale, or would this rather be expressed by not stating a finite precision or scale?

The latter would be in style with miminum, maximum, and multipleOf.

@mspiegel
Copy link

I'd like to have a special value ('variable', 'unlimited', not picky on the name) that can be used to explicitly document unlimited precision or scale. Do the fields 'precision' and 'scale' only apply when 'type' is number and 'format' is decimal? Do they also apply when 'type' is number and 'format' is unspecified? I think at one point I understood the difference between (number, decimal) and (number, not specified) but I can't recall now. What is the difference?

@ralfhandl
Copy link
Contributor Author

ralfhandl commented Jul 15, 2016

Good questions! Similar to minimum etc. precision and scale should apply to type:number without requiring a specific format.

Given the issues mentioned in #704 they might also apply to type:string and imply that the string will contain a number.

The intention of format:decimal was to advise storing these numbers with a decimal mantissa to avoid rounding issues. This is similar to the OAS formats double and float which indicate numbers that are stored as binary floating-point numbers on the origin server.

@webron
Copy link
Member

webron commented Jul 21, 2016

Tackling PR: #741

@ralfhandl
Copy link
Contributor Author

ralfhandl commented Jan 25, 2024

We've opted for "vendor-specific" extension keywords x-sap-precision and x-sap-scale and published them under the Apache-2.0 licence, so everyone is free to use them 😉

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

No branches or pull requests

3 participants