OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-formula message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office-formula] 6.3.4 Infix Operator "/"


David A. Wheeler wrote:
>> First, we already define implicit conversion so the first sentence is 
>> repetition.
> Yes, it is.   At the time, I thought it was important to re-emphasize this in
> the basic operators, but if people think that's obvious, we can remove it.
>> Third, the syntax says: Number Left / Number Right.
>> If implicit conversion is in place, then why the Number Left / Number 
>> Right? Oh, is that to signal the outcome of conversion?
> Again, to emphasize the conversion.
OK, so let me confirm: Automatic conversion is a fact as defined by 
OpenFormula. That is it works automatically. Yes?

So...., once we define the conversions, either the conversions take 
place as specified or an error in produced. Yes?

But cf. the issue that it isn't clear that a function must return an 
error if it takes an error as an input.
>> BTW, I am not sure about "fraction support" = "1/2 must produce 0.5, not 
>> 0." I would think fraction support means it supports operations on 
>> fractions, not conversion to decimal values.
>> Or is that a specialized usage in spreadsheet circles?
> It's a clarification issue.  In many languages (e.g. Python 2),
> "/" is INTEGER division, so "1/2" produces "0".
> That is NOT what is intended, instead, a fractional result should
> be returned (e.g., Python 3).  It's not necessarily
> conversion to decimal; a fractional representation would be okay.
> Any suggestions for clearer wording?
Well, that depends.

I would say that the inputs to the "/" operator are "real numbers" and 
so that removes the possibility of the Python 2 solution. Assuming that 
division of "real numbers" is properly implemented, something 
OpenFormula cannot guarantee.

BTW, in 4.2 defining a number as a "numeric value" isn't helpful.

That in part results in the ambiguity that is then explained here in a 
note about supporting division of "real numbers."

I really think we all need to think very carefully about the definitions 
of types as inputs into the various functions. I suspect that can remove 
a lot of potentially nasty issues.

Aside to Andreas: Is the automatic conversion an issue?

Hope you are having a great day!


> --- David A. Wheeler
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

Patrick Durusau
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)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]