Question about inClosedInterval, greaterThanOrEqualTo, and lessThanOrEqualTo in FloatPropositionInput

[StephenCzarnecki]

I am not sure if I am quite understanding some of the elements of FloatPropositionInput correctly.

It seems to me that inClosedInterval may be unnecessary given the ability to define greaterThanOrEqualTo and lessThanOrEqualTo

For example consider the following:

nearnormalHemisphericalVisibleTransmittance: {
  inClosedInterval: { lowerBound: 0.2, upperBound: 0.8 }
}

and

nearnormalHemisphericalVisibleTransmittance: {
  greaterThanOrEqualTo: 0.2, lessThanOrEqualTo: 0.8 
}

Do both of those queries evaluate to filtering for visible transmittance in [0.2, 0.8]? In the database.graphql document there is the comment on FloatPropositionInput that "Multiple sub-propositions are combined conjunctively" which seems to indicate this to be the case.

If this is not the case could you clarify about what ranges of visible transmittances each of the above would return?

Also if there are other reasons for providing inClosedInterval in addition to greaterThanOrEqualTo and lessThanOrEqualTo could you elaborate on them a little? There's a chance they could be useful or important in terms of the IGSDB implementation.

[christoph-maurer]

I agree with you, @StephenCzarnecki . @simon-wacker : Shall we remove inClosedInterval?

[simon-wacker]

Yes, the two queries mean the same. It's there for convenience of the user writing the query (though one may argue that the added convenience is minimal) and because some databases support interval or range types which would make the usage of inClosedInterval more efficient (though one may argue that the implementation should anyway check for the existence of both greaterThanOrEqualTo and lessThanOrEqualTo and if both exist turn it into a interval or range type for the database query). I don't care much about the existence of inClosedInterval --- we may just drop it from the API specification.