Hi Regina, On Thursday, 2008-01-31 12:57:35 +0100, Regina Henschel wrote:
> I'm working on issue 15090 Yes, I received a mail from IZ on your comment saying so, thank you! > (1) > The error result for Nper<=0 is not implemented yet. I have seen > SetError(errIllegalArgument), SetIllegalArgument(), SetIllegalParameter(), > and SetError(errIllegalParameter). > What is the right one in this case? Depends on.. as this is about generating an error in the case that an argument had a "bad" value, it is one of the IllegalArgument values (yes, this is inconsistently handled throughout all functions, I'm about changing that). SetError( errIllegalArgument) and SetIllegalArgument() differ in that SetError(...) only sets the error, while SetIllegalArgument() also pushes a value to the stack. Yes, bad naming, I already changed that in CWS odff to PushIllegalArgument(). So, if the code will reach a place where some value is pushed using one of the other Push...() methods, SetError( errIllegalArgument) is appropriate, else SetIllegalArgument() if bailing out of the function early is required. 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? > (2) > The parameter Nper has the type 'number'. May it be non integer? For non > integer Nper there must be RATE>=-1 because of (1+Rate)^Nper. Should > RATE<-1 be excluded in all cases or only if Nper isn't integer? The ODFF draft working document has a comment about this: | TBD: In Gnumeric, Nper seems to be truncated if it is not an integer. In | OOo2, Nper seems not to be truncated if it is not an integer and the | fractional part is included in the calculation. What does excel do? We | should include a test for this, but what is the right thing to do? For | example, in Gnumeric, RATE(12.9,-100,1000) is 2.92% but in OOo2 | RATE(12.9,-100,1000) is 3.88%. It wasn't decided yet whether it should be required to truncate Nper to integer. Usually, if there is no mathematical requirement to do so, so far we did not put constraints on argument values. From your view as a mathematician, does it make sense to allow non-integer Nper values? 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. > (3) > „RATE solves the equitation...“ > In many cases there is not only one solution but there are two, sometimes > three. Currently OOo returns solutions, which are far away from 0, Excel > doesn't, what the issue is about. But what to do, if the user starts with a > GUESS that will lead to such a solution and the user sets GUESS to that > value with the intention to get such solution? Would the result be correct then? Even if far away from 0? If not, we should generate an error, I think. Leaves the question to define a limit for "far away" ... > (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. > (5) > What should RATE return, if solutions exist, but values are far away from > 0? Example: Nper=4; Pv=-1; Payment=0.82; Fv=2. It has one solution round > RATE=100% and another one round RATE=-215%. Excel gives an error in this > special case. If you can detect that, I think generating an error is appropriate. > (6) > Technical questions: > > Should I use tabs or spaces for indent? Spaces please for new code. Shift width / indenting is 4 spaces, if you also set your editor's tabs to stop at multiples of 4, code will be legible. > The current text has German identifiers and parameters and German comments, > for example fBw (which means 'Barwert') instead of fPv, which would fit to > the specification. Change it? Yes, please. Doing so will clarify the code for other developers. 'fSchaetzwert' and the like look ugly anyway, I guess some other German mathematician introduced them ;-) > The internal function 'GetZinsIterationEps' returns fEps, the last > difference between neighbored values. That is used to determine whether the > result is valid or not. This will fail, if you decide, that resolutions far > away from 0 should not be valid although they solve the equation. May I > change it to boolean in that case? Sure, if it serves your purpose. > Which boolean type has it to be, if I change it? Use C++ bool type instead of the old BOOL typedef. > Does a document exist for conventions for source text? Actually we have two. One is quite old and more documents how things started and how to start working on old code, focussing on portability to even obscure platforms like SCO and old Mac, but also HP-UX; in the meantime compilers did change though and most should accept proper C++ code. See http://tools.openoffice.org/coding.html The other one is a "how we would like good code to be in future" guide line: http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards Best is to use common sense and adapt somewhat to the style of the project you're working on, but introduce better habits for new code ;-) 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.
pgpEIZAMQLKpM.pgp
Description: PGP signature
