Hi Regina, On Sunday, 2008-02-03 01:27:55 +0100, Regina Henschel wrote:
> a remark on the ODFF-spec:
> The parameter 'PaymentType' has got type 'number'. In the description only
> the values 0 and 1 are mentioned. But there is no constraint to {0;1}. The
> description doesn't say what to do with other values. The parameter
> 'PaymentType' in the equation can be interpreted as constant offset to the
> regular date of payment. So other values are meaningful too. Therefore the
> description should explicitly allow or forbid values others than {0;1}.
> The current implementation in OOo uses silently the value 1 for all values
> but 0, but makes no use from it in the Newton-algorithm. I'll not change
> that.
Thanks for the comment. Yes, this indeed is an open question and should
be clarified in ODFF, just wrote a mail to the committee's list. Looks
like implementations constrain the parameter to {0;<>0} because that's
what "the other spreadsheet application" documented to do. However, what
it docuemented is not what it does. It seems to interpret the value as
an offset (in periods) to the end date of the payment period instead.
Would it be feasible to add that to our implementation?
However, the PayType corresponds with FV, NPER, PMT and PV so should be
treated consistent.
>> Btw, in CWS odff I changed (and will change) a lot of things and diffs
>> created against earlier code respectively current milestones probably
>> won't apply anymore without adapting them. If possible I would
>> appreciate patches based on that CWS. This would require though that you
>> build a CWS version for your changes, not a master milestone. Would that
>> be feasible for you?
>
> I have not done it yet. Now I have installed WinCvs and have been able to
> check out the sc modul with the tag cws_src680_odff. Therefore I think,
> that it will be feasible for me in principle. If I get problems, I will
> surely get help on the German mailing list.
Or here or on [EMAIL PROTECTED]
> EIS says the current milestone of that cws is m243, but I find no download
> for it. Do I need to get the whole source via check out? Is it right, that
> I had to use that milestone for the cws odff?
Yes, that's correct, and to get the source you'd need the commands
cvs co -P -rSRC680_m243 OpenOffice2
cd sc
cvs update -dP -rcws_src680_odff
But I'll resync the CWS to m244 soon (this week) because some things
don't work in m243 and Lvyue would also benefit from being able to use
m244 after Chinese New Year break, so you should wait before checking
out and building m243 if you didn't do it yet. I'll give a heads up when
the CWS will be resynced.
>>> (2)
>>> The parameter Nper has the type 'number'. May it be non integer?
>>> [...]
> I would say, that non-integer Nper values are questionable. You can use
> such non-integer Nper values in the given equation and the Newton-algorithm
> will work and the results will be valid roots. But the term
> '((1+x)^Nper-1)/x' is a shortened result of the underlaying sum 'sum from
> i=0 to (Nper-1) (1+x)^i' and therein a non-integer Nper value makes no
> sense.
That sounds like it would be a good strategy to have an integer
constraint on the Nper parameter.
> If
>> the implementation works correctly for both, integer and non-integer,
>> I'd say support also non-integers. In case we'll define integers only
>> should be supported it should be fairly easy to restrict implementation
>> accordingly.
>
> The right side of the equation has a domain of [-1;infinity[ for
> non-integer Nper values. If Nper is an integer value, one can use a domain
> including values <-1, for a pure mathematical view. For "real live" use
> cases, I think, that mathematical solutions <-1 are senseless. That claims
> the reporter of the issue too. Therefore I like to set such "solutions" to
> invalid, if you agree. Doing that, it would make no difference in the
> central algorithm whether you use only integer values or not.
Sounds good to me.
>>> (3)
>>> „RATE solves the equitation...“
[...]
> Yes, the results are correct in a pure mathematical view.
>
> Leaves the question to define a limit
>> for "far away" ...
>
> That's the problem. I like to set results <-1 to invalid, whether they are
> mathematically correct or not, see above.
I think that's ok in this context.
>>> (4)
>>> What role should GUESS have? "start the iterative computation" makes not
>>> sure, that different implementations will return the same value.
>>
>> Unfortunately algorithm and implementation are not defined, also
>> ECMA/MOOXML doesn't tell anything, as usual. Do you know algorithms that
>> would yield better results than others? Maybe we can define them in
>> ODFF.
>
> The now used Newton-algorithm works fine in most cases and is very fast
> (quadratic). Another one is "Regula falsi". The latter requires a second
> initial value, so that the function has a change of sign in between.
> Depending on the way how this value is determined, the solution from Regula
> falsi might differ from that of the Newton-algorithm.
"better" than that of the Newton algorithm? If Newton is sufficient (in
terms of correctness and Excel compatibility) and does have a more
straight-forward implementation because it doesn't need a second initial
value I think that's the one to point to then.
>>> (5)
>>> What should RATE return, if solutions exist, but values are far away from
>>> 0?
[...]
> I looked at the example Nper=4; Pv=-1; Payment=0.82; Fv=2 again. The error
> in Excel arises because the algorithm converges to the "wrong" root. If you
> start with an adapted GUESS, for example 100%, you get the solution value
> '90%' in Excel.
> Therefore I think now, that on the positive side no general limit is
> possible.
Seconded.
> I'll come back with a draft version in a while.
The attachment to the issue now is already the draft? You're fast :-)
I'll take a look.
Thanks
Eike
--
OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't send personal mail to the [EMAIL PROTECTED] account, which I use
for
mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED]
Thanks.
pgpLH8NRAol4d.pgp
Description: PGP signature
