Re: [office-formula] Open ToDos

[Patrick Durusau <patrick@durusau.net>]

Eike,

On 4/7/2010 11:06 AM, Eike Rathke wrote:
> Hi Patrick,
>
> On Tuesday, 2010-04-06 10:41:46 -0400, Patrick Durusau wrote:
>
>    
>> 2.3 Scalar Evaluations
>>
>> TODO: ODF docs are incorrect. artificially limiting matrix to 1x2 or
>> 2x1; already proposed change on the TC list.
>>
>>
>> (That sounds like a part 1 issue, yes?)
>>      
> That was a part 1 issue, the artificial limit isn't present anymore.
> Please remove the TODO.
>
>    
Done.
>> 2.2.1
>>
>> TODO: this is a preliminary observation of how Excel does it, but must
>> not always be necessarily true. If in Excel that formula is entered as a
>> 2 rows array formula the content of A1 in the first row and the content
>> of A2 in the second row is displayed. How does that fit with "the
>> {0;0}th element is used"? It seems more an iteration over the single
>> elements, returning them. Which is different to what Calc does, it sums
>> the elements for each output cell, resulting in A1+A2 for a similar
>> example not using inline arrays, {=SUM(INDIRECT(A5:A6))} with A1 in A5
>> and A2 in A6.
>>
>>
>> (Not sure what we need to do with this todo.)
>>      
> Convert it to an editorial note, using the "Offset Note" paragraph style
> and creating a section hidden with a condition Note==0.
>
>    
Done.
>    
>> 3.3.3 Date and DateTime
>>
>> Note "shall" conflicts with part 1,<table:null-date>, table:date-value,
>> which defaults to 1899-12-30.
>>      
> Isn't that covered by one of the issues?
>
>
>    
Are you thinking of: 
http://tools.oasis-open.org/issues/browse/OFFICE-1505 ??

I think with the rewording that has "may support" for 1899-12-30 that we 
can close this.

I am removing the to-do.

If anyone objects, we can reopen the issue.

>> 5.1 General
>>
>> *TBD:* Re-examine functions' definition for when they are in array
>> formulas, to make sure they are adequately defined.
>>
>> (done?)
>>      
> I don't know why that comment was introduced there in that context,
> remove it. It probably was there before we defined the scalar vs. array
> evaluation (2.3)
>
>
>    
Done.
>> 5.3.6 Conversion to Integer
>>
>> *TODO:* Walk through functions, and change all "Number" in input or
>> result types to Integer where appropriate. Document which integer
>> conversion function is used (usually INT), and include test cases to
>> check that.
>>
>> (done?)
>>      
> I think yes (despite test cases). We may want to check this again for
> functions operating on text positions, and functions that in Constraints
> have INT(N)=N or similar.
>
>    
For constraints INT(N)=N - 13 replacements

For text positions - 3

Question: for Hyperlink 5.11.3 should Number be integer both in syntax 
and return?

And on conversion, BIN2DEC, should number be integer? Haven't changed 
any of those but curious given our discussion of what "number" covers.
>    
>> 5.3.10 Conversion to Complex Number
>>
>> *TODO: *Add ComplexSequence
>>
>> (done?)
>>      
> Wasn't one of the issues about that?
>
>
>    
Yes, http://tools.oasis-open.org/issues/browse/OFFICE-2449

applied, deleting the todo.
>> 5.7.8 SEARCHB
>>
>> *TODO:* provide a section about |table:use-regular-expressions| and
>> |table:use-wildcards| and use reference here.
>> Note that in an OpenDocument table (such as a spreadsheet), this
>> function's search criteria is impacted by
>> |table:use-regular-expressions| or |table:use-wildcards|.
>>
>> (I am not going to repeat this one. It is covered by the outstanding
>> comment on reference to these attributes and that will solve all of
>> these todos.)
>>      
> I think I proposed in an issue to remove that TODO, as the *B() text
> functions IMHO are not affected by wildcards, and even more deprecated.
>
>    
I'm not picking up your proposal on a search but deleting the todo.

See also: http://tools.oasis-open.org/issues/browse/OFFICE-2216

Done.

>    
>> 5.8.24 IMSUM
>>
>> *TODO:* .B4 and .B5 actually DO NOT contain the numbers claimed, and
>> therefore these tests will always fail. Need to allocate cells with
>> complex numbers, and then fix the test cases.
>>
>> Clearly not part of the standard but falls outside the test case
>> section. Don't know if it hides or not.
>>      
> If it is in a section that is hidden with condition Note==0, then yes.
> I think that is covered by a test case issue as well.
>
>
>    
Checked, it hides (or should).
>> 5.9.4 DCOUNTA
>>
>> *TBD:* KSpread 1.4.2 DCOUNTA does not work if the Criteria are Logical
>> values. E.G., you can't say "Correct?" with a boolean value below, and
>> expect it to match boolean values in the records. If you change them all
>> to Numbers (e.g., 0 or 1), so that the Criteria to match is a number and
>> the True/False computed values become 1 or 0, KSpread works fine.
>>
>> Also, if KSpread's DCOUNTA has as a Criteria that it must match "1", for
>> some odd reason it also matches 1/0 (Infinity). Note that in KSpread,
>> 1/0 is not the same as MOD(3;0); the former is "Infinity", while the
>> latter is #DIV/0! (other spreadsheets consider them the same error).
>>      
> This should not be a TODO, but an editorial offset note instead, in
> a hidden section.
>
>    
Err, ok.

Converting to an editorial offset not but *leaving* it in the hidden 
section.
>    
>> 5.12.1 General
>>
>> *TODO:* Define common terms here.
>>
>> The following snippet provided by Robert was deleted by Patrick on
>> 2009-12-21, Eike reactivated it on 2009-12-22 in this TODO section so it
>> doesn't get lost:
>> An annuity is a recurring series of payments. A "simple annuity" is one
>> where equal payments are made at equal intervals, and the compounding of
>> interest occurs at those same intervals. The time between payments is
>> called the "payment interval". Where payments are made at the end of the
>> payment interval, it is called an "ordinary annuity". Where payments are
>> made at the beginning of the payment interval, it is called an "annuity
>> due". Periods are numbered starting at 1.
>>
>>
>> OK, I'll concede. Now back to text body, todo deleted!
>>      
> Good :-)
>
>    
It is my contribution to solving the global financial crisis. Perhaps 
having defined formulas would help. Perhaps not but at least the effort 
should be made. ;-)
>    
>> 5.12.15 DDB
>>
>> *TODO*: For some combinations of lifeTime (5) and declinationFactor
>> (2,3) the overall allowance exceeds the difference between cost and
>> salvage or some of the values (the last one) becomes negative in
>> Gnumeric and Kspread. Excel and OOo Calc do it right. I don't know how
>> to put this into the equations.
>>      
> IIRC that was covered by one of the issues.
>
>    
Got it, http://tools.oasis-open.org/issues/browse/OFFICE-2222
>    
>> 5.12.32 ODDFPRICE
>>
>> TODO: To add the formula definition. Excel has two formula definitions
>> respective to short and long first coupon.
>>
>>
>>
>> 5.12.38 PPMT
>>
>> TODO: To add the formula definition. Excel has two formula definitions
>> respective to short and long first coupon.
>>      
> Can't say anything about these. If we don't have a math formula then we
> don't have one. Remove the TODOs.
>
>
>    
Done.
>> 5.13.5 Columns
>>
>> *TBD:* Need to recheck type given here. It's really "Reference or
>> Array"; we probably need to define a type that means that.
>>      
> Remove. We don't need yet another type.
>
>
>    
Done.
>> 5.14.7
>>
>> TODO: Should we discuss external files? Here Excel and OOo differ. It's
>> probably perfectly reasonable to have a function that can accept
>> /either/ format, which would be more general.
>>      
> Keep. This is about INDIRECT(), we may want to define how textual
> references to external files are to be treated that do not follow the
> OpenFormula syntax.
>
>
>    

Keeping the TODO in this version.
>> 5.15.1 (logical functions)
>>
>> *TBD:* Should minimum/maximum number of parameters be specified?
>>      
> Remove. No, or if so, it's done at the functions.
>
>    
Done.

>> *TBD:* Should we specify that "If an error value is computed for an
>> expression, then the first error is the result of the logical
>> operation."? Is this widely done ("first error is the result")? Or is
>> there sometimes a pecking order for errors, or is sometimes "last error
>> is the result" the rule?
>>      
> Remove. That's covered elsewhere.
>
>
>    
Done.
>> 5.16.10 ATAN2
>>
>> *TBD:* Should ATAN2(-1;0) result to PI() or -PI()? Gnumeric and Excel
>> 2002 gives +PI().
>>      
> Remove.
>
> Change Summary from
> Return the arc tangent given a coordinate of two numbers.
>
> to
> Returns the principal value of the arc tangent given a coordinate of two numbers.
>
> Add to Semantics:
> Returns a principal value -PI<  result ≤ PI
>
>    
Done.

>> *TBD:* Should ATAN2(0;0) result in 0, Error, or something else? OOo2 and
>> Gnumeric return 0. Excel 2002 produces #DIV/0! For the moment, left
>> unspecified.
>>      
> Remove.
>
> Change Semantics from
> It is unspecified what ATAN2(0;0) returns.
>
> to
> ATAN2(0;0) is implementation-defined, evaluators may return 0 or an error.
>
>    
Done.
>> *TBD:* KSpread 1.4.2 does not include a working version of ATAN2, though
>> it's documented. Should ATAN2 be moved to level 2? Or do later versions
>> include it?
>>      
> Remove.
>
>    
Done.
>> 5.18.1 (statistical functions)
>>
>> TODO: The LEGACY.* functions haven't grown an equivalent function name..
>> drop the prefix?
>>      
> ?? Remove.
>
>
>    
Done.
>> 5.18.78 TINV
>>
>> *TODO*: Insert algorithm description or reference.
>>      
> Remove. This is not the only function without an algorithm description.
>
>    
Done.
>    
>> 5.18.82 VAR
>>
>> *TBD:* Should we specify what happens with non-numbers? In Excel 2002,
>> it produces an error.
>>      
> Remove. This is not specific to VAR, but an aspect of the NumberSequence
> parameter.
>
>
>    
Done.
>> 5.18.84 VARP
>>
>> *TBD:* VARP(1) shouldn't be required to be an error. Excel, at least,
>> accepts it.
>>      
> Remove.
>
> Change Constraints from
> At least two numbers shall be included; it is unspecified what is
> returned with only one number. Returns an error if less than two numbers
> are provided.
>
> to
> COUNT(N)>=1
>
> Add to Semantics: If only one number is provided, returns 0.
>
> Rationale: this is obvious, following the math formula given.
>
>
>    
Done.
>> 5.18.87 ZTEST
>>
>> *TODO*: OOo Calc and Gnumeric produce the same results. Excel (2007
>> beta) claims to calculate the one-tailed test.
>> All produce different results than expected! What OOo Calc and Gnumeric
>> calculate is out of my scope. Excel tries to calculate the probability
>> by integrating from minus infinity to z and substracts this from one.
>> That would only be right, if the absolute value of z is taken, not the
>> signed z! (I speak already of the one-tailed results for this case, so
>> no confusion here.)
>> So, either I made a mistake/misinterpretation or all three apps don't
>> get it right(TM).
>>      
> Remove. That is covered by some issue.
>
>
>    
Done.
>> 6.1 General
>>
>> TODO: Place test cases for arrays here. Note that the definition of
>> array /processing/ goes earlier, in the processing model section, along
>> with a note that not all implementations support arrays.
>>      
> Keep. We might want to do that later.
>
>    
Will keep. Hidden section anyway.

Hope you are looking forward to a great weekend!

Patrick


>    Eike
>
>    

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