More on 6.3.4 Infix "/"

[Patrick Durusau <patrick@durusau.net>]

Greetings,

I am still trying to work out what are/are not legitimate inputs for the 
infix "/".

Reading the syntax:

*Syntax:* /Number/ /Left/ / /Number/ /Right/

6.1 says that "Number" is a type or pseudo-type, but Number (4.2) says:

> A number is simply a numeric value such as 0, -4.5, or $1000. Numbers 
> *shall* be able to represent fractional values (they *shall not** *be 
> limited to only integers). The "number" type *may* be displayed in 
> many different formats, including date, time, percentage, and currency.
>
So does "number" include all those formats or are they "types?"

Moreover, when I read Complex Number (4.3) I read:

> It is the explicit intent of this specification to /permit/ 
> applications to support complex numbers using the traditional infix 
> operators ("+", "-", "*", "/", and "^"), even for comparison operators 
> such as = (equal to) and <> (not equal to).
>
Maybe we are approaching this from completely different perspectives. ;-)

Let me say what I think my perspective requires for this case and then 
someone can offer theirs and we can see where we wind up.

To define a function it is necessary to:

1. Specify the inputs by type

2. Specify the mathematical operation

3. Specify the output of the function by type

4. Define what error conditions, if any, may exist and what happens in 
those cases. Such as input is of an incorrect type. (Output being of the 
wrong type is simply non-conformance.)

It is entirely possible to define the infix "/" operator for inputs that 
include real numbers, complex numbers or even polynomials.

Ah, question: Is the reason for saying things are permitted to get 
around the notion that if it isn't explicitly permitted then it is 
forbidden?

Well, I think that is a tough choice we have to make in order to have 
real interoperability.

For example, if we define the infix "/" operator to require real numbers 
for input and to produce a real number for output, then any time I get a 
formula that claims adherence to OpenFormula, I have some assurance that 
I can process every instance of the infix "/" operator, assuming the 
formula does adhere to that OpenFormula definition.

If on the other hand, we make the same definition and then we say, a 
file format or application may also use the infix "/" to represent 
division of complex numbers or polynomials, then my assurance that I can 
reliably interchange information has taken a real hit.

True, we could make those separate levels of conformance, 1st level - 
real numbers only, 2nd level - real numbers + complex numbers, 3rd level 
- real numbers + complex numbers + polynomials, and have a mechanism to 
signal which one I am encountering but we would have to do that 
*explicitly* within the standard.

The point being that in order to facilitate interoperability standards 
must make choices about what can or cannot appear in a format or 
formula. The best we can do is to try to be clear about the choices we 
did make.

Closer/farer away?

Hope everyone is having a great day!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)