Hi Eike,
Eike Rathke schrieb:
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?
Yes, it is very easy. You can use the Newton algorithm with other values
for PaymentType than 0 or 1 without problem. Another way is, to convert
the offset payment into a normal payment. You have only to substitute Fv
with (Fv-Payment*PaymentType) and Pv with (Pv+Payment*PaymentType).
Going the latter way would even simplify the terms in the Newton algorithm.
Up to now I have chosen the way, that you can drop the statement, where
PaymentType is set to 1. But implementing the other way, would be no
great effort.
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]
I know :)
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.
Then I'll wait. Generating a whole build is a long lasting process on my
computer :( and I do not want to do that twice in a short time.
[..]
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.
The algorithm are slightly different, because pow(<negative
number>,Nper) fails with non-integer Nper. If you restrict Nper to
integer, you can solve additional cases; therefore the two draft versions.
(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?
No, it is slower. There are a few special cases, where one of them works
and the other not. The Newton algorithm can go into a kind of hysteresis
with an endless loop, where Regula falsi can provide an result (if
change of sign is given). On the other hand, Regula falsi cannot find
results, which are extrema.
Newton algorithm is good. If the users encounters a loop, where he knows
a solution exists, he can vary the Guess value to get the solution.
You can extend the algorithm to find that solution which is nearest to
the Guess; therefore my question about the role of Guess. On the other
hand, implementing such ability is very costly and I think it should be
done only, if there is an insistent claim for it. If the spec doesn't
claim it, I'm happy with that.
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.
Yes, it is. I guess the other programs will use a kind of Newton
algorithm too.
I'll come back with a draft version in a while.
The attachment to the issue now is already the draft?
Yes.
You're fast :-)
It was a rainy weekend. ;)
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
