[sc-dev] Re: Internship 2010: Statistical Data Analysis Tool
Hi Niklas, hi Pivithuruw, Niklas Nebel schrieb: On 28.03.2011 10:50, Niklas Nebel wrote: It's in the download section of sc.openoffice.org, the URL is now http://openoffice.org/projects/sc/downloads/directory/Data%20Analysis. But apparently, some of the files were truncated in the Kenai transition. I'll try to get that fixed. I re-uploaded it. final evaluation version is the latest version. Niklas Thanks, I have found it. Installations works fine with DEV300m104. Kind regards Regina -- - To unsubscribe send email to dev-unsubscr...@sc.openoffice.org For additional commands send email to sy...@sc.openoffice.org with Subject: help
[sc-dev] type logical in Excel
Hi, I just noticed, that Excel 2007 and Excel 2010 distinguish between type Logical and type Number. Is this new in Excel 2007/2010 or did Excel had a separate type Logical before? (I haven't got an older version of Excel and therefore cannot examine it by myself.) I came across it, when I looked at the Microsoft test files from http://lists.oasis-open.org/archives/office/201102/msg00032.html Kind regards Regina -- To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: sy...@sc.openoffice.org with Subject: help
[sc-dev] Questions about LINEST implementation
Hi all, I have written issue http://www.openoffice.org/issues/show_bug.cgi?id=115189 for to attach the first draft of my implementation for LINEST. But there are still a lot of questions. So please have a look at that draft. (Checkmatrix has not essentially changed, but you need this version with correct n and m, if you will test my solution.) (A) The algorithm for nCase==2 and nCase==3 are nearly equal besides the fact, that the matrices of X and Y values are transposed. How should I handle this? (1) Write all functions in two variants? Then the functions are small and have only one purpose, but the code becomes very long. (2) Introduce a switch between both cases on every place needed. Then the code will become shorter, but the functions become more complex and during execution the very same case distinction is made a lot of times. (3) Transpose the matrices X and Y and then use only one case. That will give short and good maintainable code. But you need double place in memory. How large are those matrices in reality? Is double place in memory possible? (B) The functions TREND and GROWTH are calculated with the same mathematical solution. Shall I change them in the same way? Then the methods calculate2 and calculate3 would be obsolete. (C) Currently all helper functions are defined as local function and not as methods of ScInterpreter. Do you like to see any of this local functions to become a ScInterpreter method? In the actual implementation the helper functions are all ScInterpreter methods. Why? (D) What kind of boolean type shall I use? I have now used bool locally. But for example in void ScInterpreter::CalulateRGPRKP(BOOL _bRKP) a change to bool_bRKP would change the declaration. I would have to change it in interpr.hxx too. Does that harm? (E) Often it has to be tested, whether a matrix was created properly by calling GetNewMat or when pop from stack. Shall I use if(pMatrix) or if(pMatrix.Is())? Shall I use errStackOverflow, if GetNewMat does not create the matrix? (F) QR-decomposition with Householder transformation is a common mathematical method. But it might be necessary to explain the concrete implementation. Please have a look. Shall I omit such comments and attach a separate, commented version to the issue or even write a full text? (G) My implementation of LINEST uses X-MeansX and Y-MeanY instead of adding a column with 1 to the X values, which you will find in the description in the ODF spec. Does this need a separate documentation? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Calc does not detect singularity
Hi Eike, Eike Rathke schrieb: Hi Regina, I'll try to give some long outstanding answers to questions you asked shortly before I went to OOoCon and then into vacation and then.. On Thursday, 2010-08-26 22:33:20 +0200, Regina Henschel wrote: next problem with matrices :( (All with German local with comma as decimal delimiter) Fill A1:C3 with 1 2 3 3 6 9 9,1 18 27 Calculate =MINVERSE(A1:C3) That looks related, though I don't know at the moment how that should occur in Calc. We usually convert all INF and NAN to errors. Which milestone did you use? I have know installed OOo3.3.0 RC1 on Windows7 and get NaN #VALUE! #VALUE! #NUM! #NUM! #VALUE! #NUM! #NUM! #VALUE! Shall I write an issue? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] TREND/GROWTH in ODF
Hi all, it seems the problem is solved in the way, that ODF will be changed. See http://lists.oasis-open.org/archives/office/201009/msg00356.html and http://tools.oasis-open.org/issues/browse/OFFICE-3437 Kind regards Regina Regina Henschel schrieb: Hi all, in the current implementation some functions are common to TREND/GROWTH and LINEST/LOGEST. So working on LINEST I had a look at TREND too. And I have found some problems. The definition of TREND in ODF1.2 (6.18.79) allows only NumberSequence as parameters and constrains the column, row and overall count of knownY to be equal to knownX. So that definition does not cover multiple linear regression but only simple linear regression. On the outher hand, because of the rules for conversion to NumberSequence (6.3.7), also cells without numbers may be includes in the ranges and will not be considered for the NumberSequence. GNUMERIC calculates as described in ODF: Only simple linear regression, but allow text cells in the range. EXCEL calculates as Calc: Allow multiple regression, but disallow text cells. So what to do? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] TREND/GROWTH in ODF
Hi all, in the current implementation some functions are common to TREND/GROWTH and LINEST/LOGEST. So working on LINEST I had a look at TREND too. And I have found some problems. The definition of TREND in ODF1.2 (6.18.79) allows only NumberSequence as parameters and constrains the column, row and overall count of knownY to be equal to knownX. So that definition does not cover multiple linear regression but only simple linear regression. On the outher hand, because of the rules for conversion to NumberSequence (6.3.7), also cells without numbers may be includes in the ranges and will not be considered for the NumberSequence. GNUMERIC calculates as described in ODF: Only simple linear regression, but allow text cells in the range. EXCEL calculates as Calc: Allow multiple regression, but disallow text cells. So what to do? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Changing values in matrix which is parameter
Hi Eike, Eike Rathke schrieb: Hi Regina, On Monday, 2010-08-16 16:24:23 +0200, Eike Rathke wrote: The problem with constant parameters is already actual :( http://www.openoffice.org/issues/show_bug.cgi?id=113879 Thanks for catching. I'll see if I can easily introduce the mentioned CloneIfConst() approach or have to simply fix this with an unconditional Clone(). You may want to use the changeset fa8436bc0f37 in your further development, that implements the CloneIfConst() approach I mentioned. http://hg.services.openoffice.org/cws/calc58/changeset/fa8436bc0f37 I have applied it to my work now and it works fine :) But I need ScMatrixRef pNewY = pMatY-CloneIfConst(); not only in case _bLOG, so I had to move it to outside the if-statement. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Shortcomings in ScInterpreter::CheckMatrix
Hi all, CheckMatrix is used for LINEST/LOGEST and for TREND/GROWTH. It checks whether the input matrices have correct size and content, generates the default matrix for an empty MatX, changes Y to log(Y) in case LOGEST and GROWTH, determines the size of the input matrices for output parameter nCX, nCY, nRX, nRY, the number of variables for output parameter M, and the number of observations for output parameter N. But this is not done consistent. In case of simple regression (nCase==1) the values M and N are not set correctly, but the initial value 0 is returned. In case of an emtpy MatX the values for nCX and nRX are only set in case of TREND/GROWTH. Currently this gives no error, because the loops do not run over N, M, nCX, or nRX but over nCY and nRY and the value for N is determined in that loops again. I struggle about this, because I want to use N and M in my solution for LINEST, to test, whether there are enough observations at all. I want to change CheckMatrix, so that N, M, nCX, nRX are set correctly in all cases. The parameter 'BOOL _bTrendGrowth' is then no longer needed and can be removed (otherwise it will produce a compiler warning). Do you agree with those changes? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Calc does not detect singularity
Hi all, next problem with matrices :( (All with German local with comma as decimal delimiter) Fill A1:C3 with 1 2 3 3 6 9 9,1 18 27 Calculate =MINVERSE(A1:C3) I get 0,-1.#NANE+000 #VALUE! #VALUE! #NUM! #NUM! #VALUE! #NUM! #NUM! #VALUE! I guess, that the wrong notation in upper, left cell is already tracked in issue 114125. But I think, Calc should not return #NUM! or #VALUE! at all, but Err:502 (illegal argument), because the matrix is singular. The LU decomposition has a zero in the diagonal, so it is possible to detect this case. Excel and Gnumeric return #NUM! in the whole range. Fill A1:D4 with 1 2 3 4 3 6 9 12 9 18,127 36 12,124 36 48 Calculate =MINVERSE(A1:D4) I get in full science notation -6,809917355371900E+001 -1,652892561983470E+001 0,000E+000 1,000E+001 -5,150539867109620E+001 -1,293916112956810E+001 9,860E+000 -5,177106436424810E-014 1,926351720312250E+015 -6,421172401040780E+014 1,670843776116550E-002 -1,408521303258110E+000 -1,444763790234140E+015 4,815879300780690E+014 -5,012531328320800E+000 -1,443609022556390E+000 which is in two decimal place notation -68,10 -16,53 0,0010,00 -51,51 -12,94 10,00 0,00 1926351720312250,00 -642117240104078,00 0,02-1,41 -1444763790234140,00481587930078069,00 -5,01 -1,44 If the user sees this result, he will be cautious. But it might be hidden as intermediate part of a larger formula. So the user does not notice that the result is totally wrong. LINEST needs calculating an inverse matrix for the statistics, but does of cause do not show the matrix but the statistics, so that the user might not detect, that the values are wrong. Gnumeric returns #ZAHL! errors and Excel returns the same wrong values as Calc. Should I test the intermediate results in LINEST to catch this cases and return an error? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Changing values in matrix which is parameter
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Thursday, 2010-08-12 16:38:33 +0200, Regina Henschel wrote:
The current implementation avoids to copy the matrices X or Y,
although that would ease and shorten the code. I thought there must
be a reason for that and tried to avoid it too. I hesitate to copy X
or Y, because they might have a huge number of lines.
Indeed.
I will try only using new matrices for products like X'X as it is
done in the current implementation. That will result in a lot of
nearly identical multiplication methods, but I think, that is better
than copying the matrices.
To avoid both, having overly complicated code and copying large
matrices, we could introduce a const/non-const flag in ScMatrix,
defaulted to const and set to non-const by GetNewMat(), but to const
again when stored in ScFormulaResult. The usual case is that a matrix
was constructed from a range reference by the interpreter and not as
a const array or formula cell result. Then having
a ScMatrix::CloneIfConst() method could just return the current matrix
if non-const and would have to actually clone only in rare const cases.
Just an idea..
The problem with constant parameters is already actual :(
http://www.openoffice.org/issues/show_bug.cgi?id=113879
Enter the formula
=LOGEST({2|3|5|8|13};{2|4|6|8|10})
Set the cursor into the formula range to see the formula in the input line.
Recalculate some times.
Notice, that the values in the first parameter changes.
This is done in the method ScInterpreter::CheckMatrix in the statement
if ( _bLOG )
{
for (SCSIZE nElem = 0; nElem nCountY; nElem++)
{
const double fVal = pMatY-GetDouble(nElem);
if (fVal = 0.0)
{
PushIllegalArgument();
return false;
}
else
pMatY-PutDouble(log(fVal), nElem); here
} // for (nElem = 0; nElem nCountY; nElem++)
} // if ( _bRKP )
Kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Trouble with ScInterpreter::MFastMult
Hi all, in interpr5.cxx you find void ScInterpreter::MFastMult(ScMatrix* pA, ScMatrix* pB, ScMatrix* pR, SCSIZE n, SCSIZE m, SCSIZE l) // Multipliziert n x m Mat a mit m x l Mat b nach Mat r But actually it calculates R = B * A and A has size m x n and B has size l x m. I need a helper method for multiplying two matrices, so I used it as the comment describes. It took me some time to recognize that this method was the reason for the dimension errors I get. Searching with OpenGrok I find no place, where the method MFastMult is actually used. As far as I see it had been used in the old version of LUP decomposition which was changed with CWS dr37. So what to do? (1) Change the method to work as the comment describes. or (2) Change the comment to describe, what the method actually does. or (3) Delete the method totally and write my own local routine. or (4) Ignore the method and write my own local routine. or something else? I prefer (1). Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] OpenOffice 3.2 Calc adding bitmap image to a cell
Hi Jari, this is the wrong list for your questions. Macros belong to the udk or the api project and images belong to the graphics project. Kind regards Regina Jari Kosonen schrieb: Can you advice how to change the pivot point in the calc -macro? oLinked.RotateAngle=rot oLinked.Position=aPos oLinked.Pivot=aPos ?? Does not work, since I don't know the internal structure's name... oLinked.Size=aSize oLinked.Name=sDie oDrawPage.add(oLinked) -- Jari - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Changing values in matrix which is parameter
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Sunday, 2010-08-08 20:38:21 +0200, Regina Henschel wrote:
in method LINEST I get pMatX from the stack. That is a reference to
the matrix MatX. I calculate the means column wise getting a matrix
MeanX with associated reference pMeanX. In next step I calculate
pMatX-GetDouble(i,j) - pMeanX-GetDouble(i,0)
Can I overwrite the values in matrix MatX with this results? Or must
the values of the matrix MatX remain unchanged by the method LINEST?
Use a new matrix created with ScInterpreter::GetNewMat(), a matrix
argument may be a matrix constant as in LINEST(...;{1|2|3|4};...)
I have not considered that in my tests, fortunately I ask here.
When X and Y are the given matrices and deltaX and deltaY those matrices
where the means are subtracted, then the needed calculation for the
coefficients B (in column arrangement) is in case of with constant
B = (deltaX' * deltaX)^{-1} * deltaX' * deltaY
and in case of without constant
B = (X' * X)^{-1} * X' * Y
where A' means transpose(A) and A^{-1} means inverse(A). So using deltaX
instead of X would have been handy.
The current implementation avoids to copy the matrices X or Y, although
that would ease and shorten the code. I thought there must be a reason
for that and tried to avoid it too. I hesitate to copy X or Y, because
they might have a huge number of lines. Statistical investigations with
more then 1000 samples are commonly. The number of variables (=columns
of X) is often 1 or at least under 10. So products as X'X are much smaller.
I will try only using new matrices for products like X'X as it is done
in the current implementation. That will result in a lot of nearly
identical multiplication methods, but I think, that is better than
copying the matrices.
Kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] DEV300m84 hangs when saving from Calc
Hi David, David Tardon schrieb: On Mon, Aug 09, 2010 at 10:20:11AM +0200, Daniel Rentz wrote: Hi Regina, Am 08.08.2010 19:12, schrieb Regina Henschel: I have build DEV300m84 on WinXP. That works so far, but saving a spreadsheet document from Calc gives always the Debug Output: Error: wrong NameAccess From File C:/DEV300m84my/xmloff/source/core/SettingsExportHelper.cxx at Line 406 If I ignore it, the file is saved, but OOo does not react on mouse or key. I have to kill it with task manager. Is this a special problem of my build? Is there something to avoid the problem? It is very annoying when testing my changes. I'll have a look. Hi, see http://qa.openoffice.org/issues/show_bug.cgi?id=113737 for the assertion. I have applied the patch. Now I get no longer a Debug Output, but OOo still hangs after saving. Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] DEV300m84 hangs when saving from Calc
Hi all, I have build DEV300m84 on WinXP. That works so far, but saving a spreadsheet document from Calc gives always the Debug Output: Error: wrong NameAccess From File C:/DEV300m84my/xmloff/source/core/SettingsExportHelper.cxx at Line 406 If I ignore it, the file is saved, but OOo does not react on mouse or key. I have to kill it with task manager. Is this a special problem of my build? Is there something to avoid the problem? It is very annoying when testing my changes. Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Changing values in matrix which is parameter
Hi all, in method LINEST I get pMatX from the stack. That is a reference to the matrix MatX. I calculate the means column wise getting a matrix MeanX with associated reference pMeanX. In next step I calculate pMatX-GetDouble(i,j) - pMeanX-GetDouble(i,0) Can I overwrite the values in matrix MatX with this results? Or must the values of the matrix MatX remain unchanged by the method LINEST? Does there exist a guide for handling of matrices in the interpreter? Kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Missing parameter in LINEST
Hello Eike,
Eike Rathke schrieb:
Hi Regina,
Sorry for not having answered your previous mail about whether someone
was already working on LINEST. No one is. Thanks for taking that.
On Tuesday, 2010-08-03 20:27:56 +0200, Regina Henschel wrote:
the draft ODF1.2 spec defines the syntax
LINEST( Array knownY [ ; [ Array knownX ] [ ; Logical Const = TRUE()
[ ; Logical Stats = FALSE() ] ] ] )
With this syntax the formula
=LINEST(B2:B6;A2:A6;;TRUE())
is not allowed, but currently it gives no error (That is issue106118).
The interpreter allows these cases because in Excel the missing
parameter is allowed at most places and that's needed for imported
documents. When writing to ODFF we'd need to handle that in
formula/source/core/api/token.cxx methods
MissingConvention::isRewriteNeeded() and
FormulaMissingContext::AddMissing()
I think, that the interpreter should not allow invalid (in respect to
ODF) formulas, but complain about wrong syntax. Instead the import
filter should add the missing parameter. The third parameter has an ODF
default value true and Excel calculates with this missing parameter as
if it is true. Therefore the Excel import filter should add a true.
Issue 106118 is about the fact, that our interpreter does not default to
true but to false. From a technical view it is no problem to set it
to true in the LINEST method, but I think it would be the wrong way.
For ODFF there may be a general approach necessary that normally
rewrites a missing parameter and allows missing parameters only for
specific functions and parameters. Best approach probably would be to
have a table of OpCodes and parameters. This should not be your concern
now, we'll have to do that later though.
And the formula
=LINEST(B2:B6;;TRUE();TRUE())
is allowed, but currently gives an error.
I have tried to detect this cases using the method IsMissing():
In interpr5.cxx
[...]
if (nParamCount= 2)
{// In ODF1.2 empty second parameter is allowed
if (IsMissing())
{
Pop();
pMatX = NULL;
}
else
pMatX = GetMatrix();
}
The method IsMissing() works so far, that the then-case is reached.
But I get an error popup
ConvertMatrixParameters: not a push
From File C:/DEV300m84my/sc/source/core/tool/interpr4.cxx at Line 1444
ConvertMatrixParameters() isn't prepared for missings.. at line 1442
change
if ( p-GetOpCode() != ocPush )
to
if ( p-GetOpCode() != ocPush p-GetOpCode() != ocMissing )
that should do (untested).
I have changed it and it works for the LINEST method. Is this a valid
solution or might it breaks something in other places?
Kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Missing parameter in LINEST
Hi all,
the draft ODF1.2 spec defines the syntax
LINEST( Array knownY [ ; [ Array knownX ] [ ; Logical Const = TRUE() [ ;
Logical Stats = FALSE() ] ] ] )
With this syntax the formula
=LINEST(B2:B6;A2:A6;;TRUE())
is not allowed, but currently it gives no error (That is issue106118).
And the formula
=LINEST(B2:B6;;TRUE();TRUE())
is allowed, but currently gives an error.
I have tried to detect this cases using the method IsMissing():
In interpr5.cxx
void ScInterpreter::CalulateRGPRKP(BOOL _bRKP)
{
RTL_LOGFILE_CONTEXT_AUTHOR( aLogger, sc, er,
ScInterpreter::CheckMatrix );
BYTE nParamCount = GetByte();
if ( !MustHaveParamCount( nParamCount, 1, 4 ) )
return;
BOOL bConstant, bStats;
if (nParamCount == 4)
bStats = GetBool();
else
bStats = FALSE;
if (nParamCount = 3)
{
if (IsMissing()) // empty third parameter is not allowed
{
PushIllegalParameter();
return;
}
else
bConstant = GetBool();
}
else
bConstant = TRUE;
ScMatrixRef pMatX;
ScMatrixRef pMatY;
if (nParamCount = 2)
{// In ODF1.2 empty second parameter is allowed
if (IsMissing())
{
Pop();
pMatX = NULL;
}
else
pMatX = GetMatrix();
}
The method IsMissing() works so far, that the then-case is reached. But
I get an error popup
ConvertMatrixParameters: not a push
From File C:/DEV300m84my/sc/source/core/tool/interpr4.cxx at Line 1444
If I insert a DBG_ERRORFILE() as first statement in the then-case, then
I notice that first the popup not a push comes and after it, when I
ignore it, my own message comes up.
If I ignore the messages, the calculation finishes correctly.
Can you please teach me what to do?
Kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Issues with LINEST
Hello all, I have started to work on LINEST. Is there anybody out there, who is looking at LINEST already? My current state is, that I have studied the concerning mathematics and the existing code, so that I know what to do in principle. The work is about issues Incorrect LINEST calculation http://www.openoffice.org/issues/show_bug.cgi?id=112324 LINEST reports incorrect DF for intercept = 0 http://www.openoffice.org/issues/show_bug.cgi?id=112447 which are both errors in the case of regression through origin Unexpected #VALUE! error in LINEST http://www.openoffice.org/issues/show_bug.cgi?id=109264 which describes an accuracy problem LINEST uses incorrect default parameter http://www.openoffice.org/issues/show_bug.cgi?id=106118 which is about missing parameters. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Decision about Bessel-functions needed
Hi Eike, Eike Rathke schrieb: Hi Regina, On Thursday, 2010-05-20 21:40:02 +0200, Regina Henschel wrote: the Bessel-functions have some accuracy problems, see issues 31656, 40309, and 43040. I have written patches to fix these bugs. They have lain about for nearly 10 month now. I suggest to integrate them, because any other solution using the boost library is not in sight. Right. I've taken the issues and will apply the patches to CWS calc55. Mmh, I see no change in Issue 43040. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
That's odd. I'd have to take a deeper look at that. I expected that with
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
IMCOT },
the last IMCOT would had setup the map for FormulaGrammar::GRAM_PODF to
be used in 'oooc:' namespace import, see ScCompiler::fillFromAddInMap().
Using FindFunction() may be a workaround, but I'd rather find the real
cause and a different solution without looking through all AddIns.
I have tested it once again. And you are right, using
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
IMCOT }
works indeed. It was my fault, nothing to do for you. I'll will change
the file in this way.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] character set is not UTF-8 in analysis_deffuncnames.src
Hi all, I see ANSI character set and not UTF-8 in scaddins/source/analysis/analysis_deffuncnames.src. Is that an error or purpose? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Regina Henschel schrieb:
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
That's odd. I'd have to take a deeper look at that. I expected that with
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot, IMCOT },
the last IMCOT would had setup the map for FormulaGrammar::GRAM_PODF to
be used in 'oooc:' namespace import, see ScCompiler::fillFromAddInMap().
Using FindFunction() may be a workaround, but I'd rather find the real
cause and a different solution without looking through all AddIns.
I have tested it once again. And you are right, using
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
IMCOT }
works indeed. It was my fault, nothing to do for you. I'll will change
the file in this way.
The round trip ODF1.2 - OOo2.4.3 - ODF1.2 for sxc file format is OK
with that setting, but now sxc files fail both for reopen and for round
trip through OOo2.4.3 if load/save setting is ODF1.0 with an entry of
kind =com.sun.star.addin.analysis.getimcot :(
I have attached a summary of my tests and the current version of my work
(based on DEV300m78) to issue 111609. Perhaps you can find the cause of
the Addin troubles.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Thursday, 2010-06-03 16:56:56 +0200, Regina Henschel wrote:
[..]
Using in odffmap.cxx the entry
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
results in the correct attribute in the file.
Thanks for clarifying, I already started to wonder ;-)
That the round trip though OOo2.4.3 does not work for sxc file format
can be solved be forcing OOo3 to setting ODF 1.0/1.1 when saving in
sxc, as already suggested in issue 95312. So the remaining problem would
be the round trip of an ods document produced with ODF 1.2 setting. Do
you can give me a hint, how I can tell OOo3 to translate
oooc:=IMCOT(z) to a valid function call when opening such document
coming from OOo2.4.3? Or do you know a way to get the correct attribute
in the file format, when using the IMCOT entry in odffmap.cxx?
I have now looked at ScCompiler::IsOpCode. You have added a comment
(line 2520)
// If that isn't found we might continue with rName lookup as a
// last resort by just falling through to FindFunction(), but
// it shouldn't happen if the map was setup correctly. Don't
// waste time and bail out.
I have now added this FindFunction()
if (!aIntName.Len())
{
aIntName = ScGlobal::GetAddInCollection()-FindFunction(
rName, !mxSymbols-isEnglish());
}
And now all new AddIn-Functions are found when reloading and after
roundtrip through OOo2.4.3, both in setting ODF 1.0 and 1.2, and both in
ods and sxc format. So there might be something wrong with the map?
Kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
same additional information:
I use the odffmap entry
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT }
(1) Save document in setting ODF 1.2.
(2) Open it in OOo2.4.3 and save there. That results in document version
ODF1.1 and file attribute oooc=IMCOT.
(3) Open in my Build results in shown value #NAME? and cell content =imcot.
(4) Now save as in setting ODF 1.2 and reload. The function IMCOT is
detected correctly.
Is there perhaps some recompiling missing, when first opening in step (3)?
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel,
Daniel Rentz schrieb:
Hi Regina,
Regina Henschel schrieb:
If I use ocExternal the prefix is set, but the functions are not
distinct, only one name is written and on import the whole function
name is stripped, so only =(z) remains from =_xlfnodf.IMSECH(z).
I see no way to add the imaginary functions to list saFuncTable_Odf,
because they have no op-code.
Do I understand you right, that I should try to add the prefix in
function GetExcelName in /sc/.../addincol.cxx?
Yes, that was the idea, sort of. Sorry, I was not clear enough about
this. In my eyes, the solution is to not touch the _Odf table, but to
add the functions into the resource files in scaddins that are used for
the XCompatibilityNames implementation. This would be in
scaddins/source/analysis/analysis_deffuncnames.src. These strings are
returned by the GetExcelName() functions of the addin collection.
I have now used in analysis_deffuncnames.src an entry:
StringArray ANALYSIS_DEFFUNCNAME_Imcot
{
ItemList =
{
_xlfnodf.IMCOT; ;
_xlfnodf.IMCOT; ;
};
};
And for comparison an entry
StringArray ANALYSIS_DEFFUNCNAME_Imcsc
{
ItemList =
{
IMCSC; ;
IMCSC; ;
};
};
This are the results, all in setting ODF 1.2 and always saving to xls
format:
As far as I can see in the binary of the file, the function name is
stored as _xlfnodf.IMCOT and IMCSC respectively. The order of that
function names is: addin functions, named references, core functions.
(1) Opening and saving in Excel, then reopening in my build: All
functions are recognized correctly. It makes no difference using prefix
_xlfnodf. or not.
(2) Opening and saving in OOo2.4.3, then reopening in my build: In
OOo2.4.3 the unknown core functions are marked as #MACRO?, the unknown
addin functions as #ADDIN? Reopening in my build the core functions are
recognized, the addin functions are not recognizes and marked as #MACRO?
Here too, it makes no difference using prefix _xlfnodf. or not.
(3) Opening and saving in Gnumeric, then reopening in my build: All
functions with prefix _xlfnodf are not recognized, the addin functions
without prefix are recognized. Reopening in my build all core functions
are recognized, the addin functions without prefix are recognized, the
addin functions with prefix are not recognized.
So for the round trip through
Excel: It makes no difference whether use prefix or not; works always,
OOo2.4.3: It makes no difference whether use prefix or not; works never,
Gnumeric: Works without prefix, fails with prefix.
Should I use the prefix as described above?
Do you know, why reopen result from OOo243 fails?
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
HI Eike,
Regina Henschel schrieb:
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Sunday, 2010-05-30 22:44:06 +0200, Regina Henschel wrote:
In the cases
'ODF 1.0' with ods and
'ODF 1.2 extended' with sxc and ods,
the new functions are reloaded with #NAME?, but the cells contain the
formulas like '=imsech(z)'.
In contrast to issue 95312 the old imaginary functions are handled
correctly in this round trip through StarOffice8 and Excel2010
respectively.
Do I miss something, or is that a general error with 'new'
addin-functions?
Please add the new function names to sc/source/core/tool/odffmap.cxx
that should fix ODF 1.0/1.1 and ODF 1.2 .ods
They are already in the list
ScCompiler::AddInMap ScCompiler::maAddInMap[]
For example
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
I have mimic the entries of the existing ones.
If I set load/save to ODF 1.0/1.1 before saving, the round trip
mybuild - OOo2.4.3 - mybuild is OK for file format ods, sxc and sdc.
If I set load/save to ODF 1.2 before saving, the round trip mybuild
-OOo2.4.3 - mybuild is correct for file format sdc. But in file format
ods and sxc the new addin-functions are marked with #NAME?, although the
cell entries show the correct formula.
I have now changed the entries to the form, for example
{ IMCOT, IMCOT, false, IMCOT, IMCOT },
Now I can use setting ODF 1.2 or ODF 1.0/1.1, file format ods, sxc,
or sdc, reopen directly or round trip through SO8 with keeping file
format. All cases work well. So I thing, that the OOo import/export part
is solved.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Regina Henschel schrieb:
HI Eike,
Regina Henschel schrieb:
I have now changed the entries to the form, for example
{ IMCOT, IMCOT, false, IMCOT, IMCOT },
Now I can use setting ODF 1.2 or ODF 1.0/1.1, file format ods, sxc,
or sdc, reopen directly or round trip through SO8 with keeping file
format. All cases work well. So I thing, that the OOo import/export part
is solved.
I have to take back the solved. In the file format the attribute then is
table:formula=of:=COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT(z)
but it should be
table:formula=of:=IMCOT(z)
because IMCOT is defined in ODFF. So Gnumeric cannot open the file
correctly although Gnumeric knows the function IMCOT.
Using in odffmap.cxx the entry
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
results in the correct attribute in the file.
That the round trip though OOo2.4.3 does not work for sxc file format
can be solved be forcing OOo3 to setting ODF 1.0/1.1 when saving in
sxc, as already suggested in issue 95312. So the remaining problem would
be the round trip of an ods document produced with ODF 1.2 setting. Do
you can give me a hint, how I can tell OOo3 to translate
oooc:=IMCOT(z) to a valid function call when opening such document
coming from OOo2.4.3? Or do you know a way to get the correct attribute
in the file format, when using the IMCOT entry in odffmap.cxx?
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Sunday, 2010-05-30 22:44:06 +0200, Regina Henschel wrote:
In the cases
'ODF 1.0' with ods and
'ODF 1.2 extended' with sxc and ods,
the new functions are reloaded with #NAME?, but the cells contain the
formulas like '=imsech(z)'.
In contrast to issue 95312 the old imaginary functions are handled
correctly in this round trip through StarOffice8 and Excel2010
respectively.
Do I miss something, or is that a general error with 'new' addin-functions?
Please add the new function names to sc/source/core/tool/odffmap.cxx
that should fix ODF 1.0/1.1 and ODF 1.2 .ods
They are already in the list
ScCompiler::AddInMap ScCompiler::maAddInMap[]
For example
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
I have mimic the entries of the existing ones.
If I set load/save to ODF 1.0/1.1 before saving, the round trip
mybuild - OOo2.4.3 - mybuild is OK for file format ods, sxc and sdc.
If I set load/save to ODF 1.2 before saving, the round trip mybuild
-OOo2.4.3 - mybuild is correct for file format sdc. But in file format
ods and sxc the new addin-functions are marked with #NAME?, although the
cell entries show the correct formula.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hallo Daniel, Daniel Rentz schrieb: Hello, Regina Henschel schrieb: == A == I have added SEC, CSC, SECH, and CSCH, to saFuncTable_Odf. All four new functions have op-codes. Tests look good: Reloading directly is correct for ods, xls, sdc, and sxc. Loading and resaving with StarOffice8 (for ods, sdc, and sxc) and Excel2010 (for xls) and then loading in my build is correct too. Good! Did you add them to the sc and oox modules? I have added them only to saFuncTable_Odf in sc/.../xlformula.cxx. They get the prefix _xlfnodf., I see it in the xls file. == B == But I have still questions concerning the new imaginary functions. Those functions have no op-code. Need I to add them to saFuncTable_Odf? If yes, how can I do it? Yes, the filters in sc are used for import/export of the XLS format. On export, the current behaviour is: If the function is an add-in function, the XCompatibilityNames interface is used to retrieve its name used in the XLS file format (see in file sc/source/filter/excel/xeformula.cxx, in function XclExpFmlaCompImpl::AppendAddInCallToken(), call to GetExcelName()). So I would suggest that this interface returns the _xlfnodf.XYZ function names, to not get any name clashes with existing functions in Excel. The import filter will try to convert these function names back to add-in functions, again with the mentioned interface. But I do not know if this will work out of the box. In file sc/source/filter/excel/xiroot.cxx, there is a function XclImpRoot::GetScAddInName() that calls GetCalcName() if you want to debug it. I have added the imaginary functions to saFuncTable_Odf with opcode ocNoName now. The prefix _xlfnodf. is not set. It does not work out of the box. You do not notice the missing prefix in the test results, when testing the round trip mybuild - Excel - mybuild. There the cell entries are OK. But you see it in the round trip in xls format mybuild - OOo243 - mybuild, which results in #MACRO?, and if you look into the xls file with an editor. if you want to debug it There is no hurry to implement the new functions. So I will try to make it correct and learn a little bit about the filters. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Decision about Bessel-functions needed
Hi all, the Bessel-functions have some accuracy problems, see issues 31656, 40309, and 43040. I have written patches to fix these bugs. They have lain about for nearly 10 month now. I suggest to integrate them, because any other solution using the boost library is not in sight. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] EUROCONVERT() in the wrong category
Hi Alexandro, Alexandro Colorado schrieb: Hi today I found this formula as part of Math as opposed to Financial or something else. I think this is a bug, want confirmation that this is replicated. in ODF Open Formula draft spec, section 5.16.29 EUROCONVERT is in the section 'Mathematical Functions'. If you think that is wrong, you should start with a comment to OASIS. If we will follow the categories in the spec, it would be no bug now. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel, Daniel Rentz schrieb: Hi regina, Regina Henschel schrieb: the file oox/source/xls/formulabase.cxx has a section /** Functions defined by OpenFormula, but not supported by Calc or by Excel. */ Does this refer to the draft ODF 1.2 formula spec? No. I just scanned the function op-codes defined by sc (nowadays formula/inc/formula/opcode.hxx). Which functions are listed there? For example, why are the imaginary functions and the secant functions not listed there? This list in oox is not used anywhere. So I need not worry about that file? I added it to have the entries available for copypaste once Calc and Excel will support the functions... Which functions are we talking about exactly? I'm working on SEC, CSC, SECH and CSCH (issue 111413) and on IMCOSH, IMCOT, IMCSC, IMCSCH, IMSEC, IMSECH, IMSINH, IMTAN (issue 111609). The code is nearly ready, but for filters. For filters I would need some advise, what to change and add. SEC, CSC, SECH and CSCH are normal functions in the Math-group and the IMxxx-functions belong to scadddins/analysis. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel, Daniel Rentz schrieb: scadddins/analysis should contain only these functions that Excel offers in its Analysis add-in. New functions should go into the Calc core IMHO. (Anyway, starting from Excel 2007, all Analysis functions are built-in in Excel.) I'm not sure if the filters are prepared to handle functions from the Calc Analysis add-in that do not exist in Excel. Will think about that tomorrow :) I have collected the function names including the used categories [1]. This might help to decide, whether those functions, which are part of ODFF, should be moved to somewhere else. [1] http://wiki.services.openoffice.org/wiki/File:Compare_Function_Category_Excel_ODF_OOo.ods kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel, Daniel Rentz schrieb: Regina Henschel schrieb: Hi Daniel, Daniel Rentz schrieb: Hi regina, Regina Henschel schrieb: the file oox/source/xls/formulabase.cxx has a section /** Functions defined by OpenFormula, but not supported by Calc or by Excel. */ Does this refer to the draft ODF 1.2 formula spec? No. I just scanned the function op-codes defined by sc (nowadays formula/inc/formula/opcode.hxx). Which functions are listed there? For example, why are the imaginary functions and the secant functions not listed there? This list in oox is not used anywhere. So I need not worry about that file? Sorry, just have taken a closer look. This table *is* used to preserve Calc-only functions in roundtrip (save to Excel, load from Excel). When reloading into my patched DEV300m76 I get this up to now, without any entry in the files formulabase.cxx: save in .sxc: All addin functions, including the existing ones, result in #Name?, but the cell content contains the correct formula. save in .xls: All addin functions are correct including the new ones, all other functions unknown to Excel are shown with #MACRO?, but the cell content contains the correct formula. For the Addin functions the information in analysis_deffuncnames.src is used. save in .xml: All functions have an additional of:]. Excel cannot read the file. But that is not my fault, that is already broken in OOo3.2. So I think, that using new Addin functions works well. Gnumeric can read the ods file with all new functions, the normal and the Addin function. Same for the equivalent table saFuncTable_Odf in sc/source/filter/excel/xlformula.cxx. [..] Just add the new functions to the tables. As Excel does not know them (right?), the entries are used to create a unique function name in the Excel file format (e.g. _xlfnodf.SEC), and the import filter will restore the function known by Calc. Will try the filter files tomorrow. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel, Daniel Rentz schrieb: Same for the equivalent table saFuncTable_Odf in sc/source/filter/excel/xlformula.cxx. It seems, that I have to wait till m78, because m76 does not contain saFuncTable_Odf and m77 does not build for me. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] constraint of x in sin(x) in scaddins
Hi Eike, Eike Rathke schrieb: Hi Regina, On Saturday, 2010-05-08 21:02:45 +0200, Regina Henschel wrote: I have notice a constraint SinOverflow (which is x=134217728) in analysishelper.cxx in scaddins. What is the special reason for it? Having tried I confirm that Excel has that constraint, or more specific x134217728. I don't know adhoc why it is 2^27 though. In other places with sin() the version ::rt::math::sin() is used to get a guard for overflow. That would result in constraint x=9,22337203685478E+018, which is much larger. See comment in sal/inc/rtl/math.hxx for isValidArcArg(). We rely on the trigonometric functions being implemented such that radians up to 2^64 (=1.844e19) are supported. Re-thinking that, also per the comments Leonarda gave, we should lower the limit to a value representable in a double's (binary64) mantissa of 53 bits. For consistency with the approx functions I suggest a constraint x=2^48 I have scanned that area a little bit, using some integral numbers. The accuracy is about 7-8 digits for x near to 2^48. For larger values, the accuracy decreases dramatically to 0-1 digit. The accuracy for integral numbers is 14-15 digits till 2^27. But for non-integral numbers the situation is not so good. The function sin() reacts very sensitive on rounding errors. Although the arguments only differ in that digit, which is not displayed, the result might be very different. This error is greater for large values and values near multiples of PI. Some examples: near 2^48, near multiple of PI sin(281474976710656 + 0.1) = 2.52110962285532E-001 sin(281474976710656 + 0.4) = 4.83685841828820E-001 near 2^26 sin(109951164.00440 + 0,01) = 9.9998707539E-001 sin(109951164.00440 + 0,04) = 9.9998550774E-001 near 2^36 sin(109951164005.920 + 0.0001) = 9,9640813644E-001 sin(109951164005.920 + 0.0004) = 9.9844512272E-001 near 2^45 sin(49951164005923.8 + 0.01) = -9.94815019880560E-001 sin(49951164005923.8 + 0.04) = -9.97506946246269E-001 About the IEEE 754 specification mentioned there: Unfortunately I can't find that 2^64 requirement, apparently the standard itself does not say so, just checked. Maybe it did in an older public draft, as a recommendation. Apparently C math libraries implement it such. If there is no special reason, should I replace it, while I work on the missing complex trigonometric functions? Note that this SinOverflow() of the Analysis Add-In is used with IMSIN() and IMCOS() only. However, in Excel also the SIN(), COS() and TAN() functions are affected by the x134217728 constraint, which we handle using the ::rtl::math approach. I think we can safely replace SinOverflow() with ::rtl::math::isValidArcArg() if we chose a better limit for that. I have written all imaginary functions now in a way that ::rtl::math::isValidArcArg() is used. Doing that the imaginary functions will give the same result as the normal real functions, when called with a real argument. Concerning the limit in ::rtl::math::isValidArcArg() I'm not sure, what is the right way. Gnumeric does not limit the argument of sine and results wrong values. I too tend to use 2^48 as limit. Beyond that limit the result are unusable. But in addition the descriptions in the Wiki should mention, that the accuracy will only be good (= 9 to 15 digits) if the argument is smaller than 2^27. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] HelpID for imaginary trigonometric functions
Hi, next question with my imaginary functions task: I have found helpid definitions for imaginary functions in sc/inc/sc.hrc. Shall I add definitions for the new imaginary functions there? And then in sc/source/core/tool/addinhelpid.cxx and sc/util/hidother.src too? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi, the file oox/source/xls/formulabase.cxx has a section /** Functions defined by OpenFormula, but not supported by Calc or by Excel. */ Does this refer to the draft ODF 1.2 formula spec? Which functions are listed there? For example, why are the imaginary functions and the secant functions not listed there? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] constraint of x in sin(x) in scaddins
Hi Niklas, Niklas Nebel schrieb: On 05/08/10 21:02, Regina Henschel wrote: I have notice a constraint SinOverflow (which is x=134217728) in analysishelper.cxx in scaddins. What is the special reason for it? In other places with sin() the version ::rt::math::sin() is used to get a guard for overflow. That would result in constraint x=9,22337203685478E+018, which is much larger. If there is no special reason, should I replace it, while I work on the missing complex trigonometric functions? The 2^63 limit is there to prevent invalid results (outside of the range from -1 to 1). I have guessed from the comment in the source, that there are problems. The 2^27 limit also prevents inaccurate results, like Leonard described. Both can be justified. The pragmatic solution, to avoid breaking any existing usage, might be to keep the separate limit for the scaddins complex number functions, at least for now. to avoid breaking any existing usage is a good argument to not change anything in IMSIN or IMCOS. But what limit shall I use in the other complex trigonometric functions? (IMTAN, IMCOT, IMCSC, IMSEC, IMCOSH, IMSINH, IMCSCH, IMSECH). I personally think, that huge arguments are not needed. For those, who really need them, a spreadsheet application is likely the wrong program. On the other hand this is the only place, where there is such a limit to sin(), afaik. Please decide. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] constraint of x in sin(x) in scaddins
Hi Leonard, it seems, that I have not been clear enough. sin() is a function in the math library of C and C++ compilers and is nowadays accurate in double precision up to x2^64. To prevent larger arguments the special implementation ::rtl::math::sin() is used in OOo. But inside the implementation of IMSIN() in the module scaddins a constraint x134217728 is used. I only want to know, why this has been introduced. I doubt, that this restriction is still necessary. I know, that a lot of binary values give different results for sin(), although they are shown with the same decimal values in 15 digit precision (the highest precision Calc UI has). But that is not central point of my question. kind regards Regina Leonard Mada schrieb: Dear Regina, I believe that sin() should have as constraint the largest float (or integer) that fulfills the following condition: sin(max) = correct result + epsilon sin(max + lambda) = correct result + epsilon , where lambda is a float in the interval (0, pi/2). Let me explain this a little bit. sin: [any float] - [-1, 1] sin(pi/2) = 1 sin(pi/2 + pi/2) = 0 So basically, if we want to compute sin() at some precision, we have to guarantee that the number we compute the sinus of, can be accurately represented. Else, we risk a total fiasco, because sin(a_very_big_number) may correspond to any value in [-1, +1], as the last digits in a_very_big_number are not accurate. So, big_number +/- pi/2 may be represented as big_number, although the sinus would have different signs for those theoretically different numbers. Therefore, the number which still makes sense to compute the sinus off, should fulfill the requirements set above. We still need to determine what values lambda and epsilon take, but I hope that the general idea is clear. Basically, this also depends on the implementation of general numbers in the particular software (Calc in this example). Some may store 16 decimal digits, so 1.xxx * 10^16 is still ok to compute the sin() (or marginally so), some may store 32 digits, so 1.xxx * 10^32 would be fine in that case. I believe that lambda should be not bigger than pi/4, while epsilon is flexible in this case (e.g. 10^-6 is probably sufficient). Sincerely, Leonard Mada Original-Nachricht Datum: Sat, 08 May 2010 21:02:45 +0200 Von: Regina Henschelrb.hensc...@t-online.de An: Calc devdev@sc.openoffice.org Betreff: [sc-dev] constraint of x in sin(x) in scaddins Hi all, I have notice a constraint SinOverflow (which is x=134217728) in analysishelper.cxx in scaddins. What is the special reason for it? In other places with sin() the version ::rt::math::sin() is used to get a guard for overflow. That would result in constraint x=9,22337203685478E+018, which is much larger. If there is no special reason, should I replace it, while I work on the missing complex trigonometric functions? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] constraint of x in sin(x) in scaddins
Hi all, I have notice a constraint SinOverflow (which is x=134217728) in analysishelper.cxx in scaddins. What is the special reason for it? In other places with sin() the version ::rt::math::sin() is used to get a guard for overflow. That would result in constraint x=9,22337203685478E+018, which is much larger. If there is no special reason, should I replace it, while I work on the missing complex trigonometric functions? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Functions in Excel 2010
Hi Niklas, Niklas Nebel schrieb: On 04/02/10 21:49, Regina Henschel wrote: Excel 2010 has some significant changes for statistical functions, see [1][2]. Are there any plans to adapt the import filter and to implement further functions? Has work on this already started? At the moment there are no plans to add the new functions to Calc. They can probably be handled in the import filter, but nothing has been started yet. A good first step would be to make an overview which new Excel functions have to be mapped to which existing functions. If someone wants to do this step, that would be great. I have started a new Wiki page http://wiki.services.openoffice.org/wiki/Calc/Drafts/Treatment_of_new_Excel_2010_functions to gather all the information. It lists the new Excel functions alphabetically. So I can add pieces of information when it is possible in my spare time; or other helpers :) will do. In addition the associated discussion page can be used to discuss details. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Functions in Excel 2010
Hi all, Excel 2010 has some significant changes for statistical functions, see [1][2]. Are there any plans to adapt the import filter and to implement further functions? Has work on this already started? kind regards Regina [1] http://blogs.msdn.com/excel/attachment/9905140.ashx or search for Function Improvements in Microsoft Office Excel 2010 [2] http://office2010.microsoft.com/en-us/excel-help/what-s-new-changes-made-to-excel-functions-HA010355760.aspx?CTT=1 or search for What's New: Changes made to Excel functions inside http://office2010.microsoft.com - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] What are valid arguments for INDIRECT
Hi Niklas, Niklas Nebel schrieb: On 09/19/09 22:15, Regina Henschel wrote: the submitter of issue 105182 closed the issue, because he find a way to solve his problem. But for me the situation is not clear. =ISREF(D1:D3!C2:E2) returns TRUE but =ISREF(INDIRECT(D1:D3!C2:E2)) returns FALSE =ISREF(A1~B1) returns TRUE but =ISREF(INDIRECT(A1~B1)) returns FALSE And INDIRECT((A1:C3):(B2:D4)) fails too. Are expressions as text not allowed for INDIRECT or are they allowed but not implemented yet? INDIRECT is supposed to parse a reference, not any more complex expression. So what is a 'reference'? For ISREF the help say, Tests if the argument is a reference. Returns TRUE if the argument is a reference, returns FALSE otherwise. Taking that, D1:D3!C2:E2 is a 'reference'. I know that INDIRECT cannot work with this sort of 'reference' up to know. My question is, whether this is because of definition in ODF or not. If the definition allows it, then we can enhance INDIRECT (if we want). And what about all type of names? INDIRECT(name) will fail. I know, that is mentioned in the help. But must it fail? The help is outdated here. Support for named ranges was added some time ago (issue 4695). Indeed, that works now. :) kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Re: [Issue 90759] ZTEST not same as Excel
Hi Eike, hi Leonard, Eike Rathke schrieb: Hi Leonard, On Tuesday, 2009-08-25 15:45:42 +0200, Leonard Mada wrote: I would therefore stick with the one sample definition, and adapt only the text to correspond to what actually the function computes. The p-value is the probability, under the null hypothesis, of observing a value as extreme or more extreme of the z-statistic Probably too long, taking localizations into account. or shortened: calculates the probability of observing a value as extreme or more extreme of the z-statistic and (possibly) correcting for the wrong implementation: calculates the probability of observing a value as large or larger for the z-statistic Not being a native speaker the difference isn't clear to me. extreme can be very small or very large. But our ZTEST only calculates the larger case. To have this changed we need a decision real soon now. So far then I'd go for calculates the probability of observing a value as large or larger for the z-statistic Any objections? Adding that to i90759 to have it documented. There is a comparison observing a value larger but it does not contain, to what it is compared. There must be something like observing a value larger than I think as large as... can be dropped, it makes no difference for a continuous distribution and the text becomes shorter. Is for the z-statistic an attribute to a value? I understand it so. Is it a typical sentence order in English to put it at the end? In German I would say Berechnet die Wahrscheinlichkeit einen Wert der Gauß-Statistik zu beobachten, der größer ist als der Wert der Gauß-Statistik der Stichprobe. But I'm not sure, Leonardo wants to say this. (Z-Statistik does not exist in German.) Describing the function using 'z-statistic' is indeed better than using a description with 'mean', because of the function name ZTEST. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Re: [Issue 90759] ZTEST not same as Excel
Hi Leonard, Leonard Mada schrieb: Dear Calc team, the following wording is ambiguous and it may be wrong altogether: function description: calculates the probability of a *sample* mean greater than the mean of the given *sample*. [EMPHASIS ADDED] A long phrase for the application help would be: For a given random sample of size n, drawn from a normally distributed population with a known mean µ and standard deviation sigma, ZTEST calculates the probability that another sample of the same size would have a mean greater than the mean m of the given sample. ZTEST calculates 1-NORMSDIST(z) where z = (m-µ)/(sigma/sqrt(n)). The function ZTEST is not a Z-test, but you can calculate a value by ZTEST, which you can use to perform a Z-test. Do you know a better phrase, that *does not exceed two lines* for the function wizard? We can explain the function in detail on the Wiki, where you already find the formula and nice diagramms. The problem is, to get a very short description, without given such useless phrases like for TTest, where you find Calculates the T test in the function wizard and Returns the probability associated with a Student's t-Test. in the application help. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Missing second parameter in CEILING
Hi Eike, hi Daniel, Eike Rathke schrieb: Hi Daniel, Regina, On Wednesday, 2009-08-12 10:15:43 +0200, Daniel Rentz wrote: Regina Henschel schrieb: == Import == Importing an Excel-file with =CEILING(-3.4;) for example gives the cellcontent =CEILING(-3.4;;1), because in the current import filter the third parameter 1 is added to get Excels rounding away from zero behavior. This will be a valid formula in ODF1.2 and calculated as CEILING(-3.4;-1;1)= -4. But the formula =CEILING(-3.4;) gives the result 0 in Excel. Therefore I think, that it would be better, to import the formula as =CEILING(-3.4;0;1) which gives 0 in OOo too according to spec ODF1.2. So, actually CEILING(x,) in Excel always returns 0 for any x. Yes, at least in my Excel2007. The other problematic import case is Excels formula =CEILING(;value). In this case it becomes =CEILING(;value;1), which is an invalid formula in ODF1.2. Here too the result in Excel is 0, and an import as =CEILING(0;value;1) would give the same result as in Excel. Why Excel even allows such crap is beyond my scope.. I guess, it is a bug in Excel. [..] I first thought I could withdraw the new proposal I made for ODFF, Please do not withdraw it. If CEILING will be defined with three parameters, it is meaningful to allow CEILING(x;;y). It makes it easy to drag-copy in the case the user wants a rounding to integer. Otherwise he needs something like CEILING(x;if(x=0;1;-1);y), because the first and second parameter must have the same sign. Or the spec is changed in a way, that the second parameter is always not negative and the sign is set automatically according to the first parameter. but there may be documents in the wild that have the missing parameter written. These currently calculate 0 for any CEILING(x;;y), but will have to calculate according to the spec then, which is to use -1 or +1 for the missing parameter. It was an error in OOo to allow the missing parameter and interpret it as 0 in first place, just to be Excel compatible.. Yes, I too think it as a fault in OOo and I see additional trouble with handling of ods-documents saved with OOo3.0 to OOo3.2. Is there a way to distinguish, whether a document was saved in a version with the 'wrong' handling? I mean for example, if the method with missing = +-1 would be used in OOo3.3, can a OOo3.3 detect, that a document was saved in OOo3.2, which uses the old method with missing = 0? == Export == When the formula in OOo is =CEILING(3.4;;Mode) it is exported to =CEILING(3.4;) which results in 0 in Excel. But in OOo the formula results in 4. Currently it does not. It should.. but it does this Excel compatibility stuff. Yes. I described the problems we get, when we implement CEILING according to spec. If the formula is exported as =CEILING(3.4;1) it would give the correct result in EXCEL. But for =CEILING(-3.4;;0) in OOo, which results in -3, Also here, it should, but currently doesn't.. the current export is =CEILING(-3.4;) which result in 0 in Excel which is wrong, but the export to =CEILING(-3.4;1) gives an invalid formula and =CEILING(-3.4;-1) would result in -4 in Excel, which is wrong too. Basically we can't export any function with Mode=0 (or omitted) to Excel where FLOOR(-x) or CEILING(-x) are rounded mathematically, because Excel has them wrong. IMHO, the best would be to write an NA() as second parameter in these cases, so the result in Excel will be an error instead of a different value. Concerning import/export with Excel, another -radical, but clean- solution might be to implement CEILING_ADD, and export the regular CEILING function to an error value in all cases. It would support an Excel - OOo - Excel work flow, especially if the user sets xls as default format. For OOo - Excel the user would be responsible to use Excel compatible functions. The formulas are better readable than using an if construct (I read your description below already). Especially, when a user sets xls as default format, he might wonder, that his expression changed to an if-construct, when he reopens his document. But unfortunately this does not solve the change of meaning in ods-documents. When the formula in OOo is =CEILING(3.4) it is calculated as CEILING(3.4;1;0)=4. An export as =CEILING(3.4;1) would give correct values in Excel. But =CEILING(-3.4) is calculated as CEILING(-3.4;-1;0)=-3 and CEILING(-3.4;1) is invalid again and CEILING(-3.4;-1) result in -4 in Excel, which is wrong. I see no way to make a general export, that gives the same value in Excel as in OOo by simply setting or dropping parameters. So what to do in export? Hmm, I see. So the second parameter has to be set according to the current value of the first. No idea how to fix this easily... No easy fix. We might track the calculation in the interpreter and store the replacement parameter at the ocCeil/ocFloor tokens if needed, but that still wouldn't resolve
Re: [sc-dev] Missing second parameter in CEILING
Hi Daniel, I do not answer directly, because it seems that I described my concern not good enough. Next try: == Import == Importing an Excel-file with =CEILING(-3.4;) for example gives the cellcontent =CEILING(-3.4;;1), because in the current import filter the third parameter 1 is added to get Excels rounding away from zero behavior. This will be a valid formula in ODF1.2 and calculated as CEILING(-3.4;-1;1)= -4. But the formula =CEILING(-3.4;) gives the result 0 in Excel. Therefore I think, that it would be better, to import the formula as =CEILING(-3.4;0;1) which gives 0 in OOo too according to spec ODF1.2. The other problematic import case is Excels formula =CEILING(;value). In this case it becomes =CEILING(;value;1), which is an invalid formula in ODF1.2. Here too the result in Excel is 0, and an import as =CEILING(0;value;1) would give the same result as in Excel. This is true for the Excel formats xls, xlsx and xlsb. The import filter for xml does not alter the Excel formulas and so the formulas in the cells are invalid according to ODF1.2. But it could be solved the same way with =CEILING(0;value;1) and =CEILING(value;0;1) respectively. Change the import filter? == Export == When the formula in OOo is =CEILING(3.4;;Mode) it is exported to =CEILING(3.4;) which results in 0 in Excel. But in OOo the formula results in 4. If the formula is exported as =CEILING(3.4;1) it would give the correct result in EXCEL. But for =CEILING(-3.4;;0) in OOo, which results in -3, the current export is =CEILING(-3.4;) which result in 0 in Excel which is wrong, but the export to =CEILING(-3.4;1) gives an invalid formula and =CEILING(-3.4;-1) would result in -4 in Excel, which is wrong too. When the formula in OOo is =CEILING(3.4) it is calculated as CEILING(3.4;1;0)=4. An export as =CEILING(3.4;1) would give correct values in Excel. But =CEILING(-3.4) is calculated as CEILING(-3.4;-1;0)=-3 and CEILING(-3.4;1) is invalid again and CEILING(-3.4;-1) result in -4 in Excel, which is wrong. I see no way to make a general export, that gives the same value in Excel as in OOo by simply setting or dropping parameters. So what to do in export? - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Missing second parameter in CEILING
Hi, I'am currently looking at issue 102957 ODFF: FLOOR and CEILING should work with a single argument. Now OOo allows CEILING(N;Significance;Mode) and CEILING(N;Significance). I have made some changes to allow CEILING(N) too. Thereby I noticed the following problem: OOo allows CEILING(N;;Mode) where the second parameter is missing. It does this already in version OOo2.4.2 But that is not allowed in spec (chapter 6.16.1). Unfortunately I can not do anything in ScCeil, because in this case nParamCount is already 3 and it seems that the missing parameter is set to 0. Besides the fact, that a missing second parameter is not allowed, the default for the second parameter has to be +1 or -1 depending on the sign of N. I would expect, that the case CEILING(N;;Mode) raises a Variable missing error. But I don't now, where this should happen. Could you please point me to that place? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Missing second parameter in CEILING
Hi Eike, Eike Rathke schrieb: Hi Regina, On Wednesday, 2009-08-05 16:06:45 +0200, Regina Henschel wrote: I'am currently looking at issue 102957 ODFF: FLOOR and CEILING should work with a single argument. Now OOo allows CEILING(N;Significance;Mode) and CEILING(N;Significance). I have made some changes to allow CEILING(N) too. Thereby I noticed the following problem: OOo allows CEILING(N;;Mode) where the second parameter is missing. It does this already in version OOo2.4.2 Presumably for Excel interoperability because there the functions have only 2 parameters, but Excel allows CEILING(value,) and during import we have to add the 3rd parameter to indicate the mode. Problems see below. But that is not allowed in spec (chapter 6.16.1). We'll have to change the spec for interoperability, I created issue http://tools.oasis-open.org/issues/browse/OFFICE-2006 Unfortunately I can not do anything in ScCeil, because in this case nParamCount is already 3 and it seems that the missing parameter is set to 0. Besides the fact, that a missing second parameter is not allowed, the default for the second parameter has to be +1 or -1 depending on the sign of N. After the 3rd argument was popped from the stack you can check with IsMissing() whether the 2nd argument is of type svMissing, then pop the value with GetDouble() as usual, and after having obtained the 1st argument change the value of the 2nd argument accordingly to +1 or -1 if it was missing. Ah, IsMissing() is new to me. I can now set the missing second parameter to +1 or -1 depending on N. That works at least for CEILING on which I'm currently working. But Excel Import and Export is confusing. (1) Import: In cases CEILING(value;) and CEILING(;value) the result in Excel2007 is always 0. On import of CEILING(value;) OOo does this: .xlsturn to CEILING(value;;1) and show cell content 0. .xlsx turn to CEILING(value;;1) too, but show cell content Err:511 .xmlturn to CEILING(value;) and show cell content Err:511 On import of CEILING(;value) OOo does this: .xlsturn to CEILING(;value;1) and show cell content 0. .xlsx turn to CEILING(;value;1) too, but show cell content Err:511 .xmlturn to CEILING(;value) and show cell content Err:511 The errors are shown left as if they are text. The cell content is only recalculated, if you edit the cell, but that is another issue. Because Excel returns 0 in this cases, I think an import to CEILING(value;0) and CEILING(0;value) would be a better solution. Although I not yet know how to do it. (2) Export: Currently OOo drops the third parameter. So the value differs from Excel in the cases of (N0 and Mode=0). When now the second parameter it optional too, how should it be exported? Using +1 gives the same result as in OOo for all cases but (N0 and Mode=0). So I would prefer that. Gnumeric goes a total different way. It generates a new expression to simulate the behavior with it's two parameter version of CEILING. You can see it, when you open an ods-file in Gnumeric. For example CEILING(A2;B2;C2) becomes =if(0=C2;if(A20;floor(A2;B2);ceiling(A2;B2));ceiling(A2;B2)) What is the desired behavior on import from Excel and export to Excel? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Problems with BESSELJ
Hi Eike, Eike Rathke schrieb: Hi Regina, On Thursday, 2009-07-09 15:47:06 +0200, Regina Henschel wrote: (3) I have tried to use the Message of the exception. But there I fail already in the syntax. The original exception's Message should be available as rWrapped.TargetException.Message I fail before that place. I do not no, how to write the throw command. A simple throw ::com::sun::star::uno::RuntimeException(Konvergenzfehler); does not compile. Ah, no, there's no automatic conversion from string literals to OUString. For ASCII strings you may use the module's STRFROMASCII(s) that is defined in analysisdefs.hxx, so ...Exception(STRFROMASCII(convergence error)) should do. I will test it after finishing the solution with the new exception. We'd prefer English messages, even if just for debugging/tracing purposes ;-) Yes, I know; it was only German here in the mail. The solution with the new exception works now. So I will first generate the according patches. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Problems with BESSELJ
Hi Eike,
Eike Rathke schrieb:
Hi Daniel,
On Wednesday, 2009-07-08 18:37:59 +0200, Daniel Rentz wrote:
Anyway, I would volunteer to do these changes. :)
Roll back! ;-)
That would complicate things even further because the addin.Analysis
name is used in API calls, moving implementation to the core would make
it necessary to compensate for in the compiler.
As the Add-In interfaces are not exported, the easiest solution would be
to introduce a new exception, let's say NoConvergenceException, and set
errNoConvergence accordingly in ScUnoAddInCall::ExecuteCallWithArgs().
Regina, do you need help with that?
Yes, I need a lot of help with that.
(1) How do I introduce a new exception?
(2) I have tried the following too. Instead of my provisional
return 888.88;
I write
throw ::com::sun::star::uno::RuntimeException();
Now the spreadsheet shows
#VALUE!
in cell and
Error: Wrong data type
in status bar in that cases.
But it shows this, whatever I write in
ScUnoAddInCall::ExecuteCallWithArgs(). I have tried it there with
catch(uno::RuntimeException)
{
nErrCode = errNoConvergence;
}
and (only for testing) with
catch(uno::Exception)
{
//nErrCode = errNoValue;
nErrCode = errDivisionByZero;
}
Where comes the #VALUE! from?
(3) I have tried to use the Message of the exception. But there I fail
already in the syntax.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Problems with BESSELJ
Hi Eike, hi Niklas, Eike Rathke schrieb: Hi Regina, On Thursday, 2009-07-09 12:17:43 +0200, Regina Henschel wrote: (1) How do I introduce a new exception? The attached (hopefully not stripped by the mailing list software)patch I've received it. adds the ::com::sun::star::sheet::NoConvergenceException to the offapi module. After having applied the patch [..] It will take a while to do that all. Thank for your advise. (2) ScUnoAddInCall::ExecuteCallWithArgs() See also Niklas' reply. Adding a condition else if ( rWrapped.TargetException.getValueType().equals( getCppuType( (sheet::NoConvergenceException*)0 ) ) ) nErrCode = errNoConvergence; to the catch(reflection::InvocationTargetException rWrapped) block should do. I've tried Niklas' hint using 'RuntimeException' and got the desired error message in the cell. :) So I think, that part will work. (3) I have tried to use the Message of the exception. But there I fail already in the syntax. The original exception's Message should be available as rWrapped.TargetException.Message I fail before that place. I do not no, how to write the throw command. A simple throw ::com::sun::star::uno::RuntimeException(Konvergenzfehler); does not compile. Hope that helps, I'm confident. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Problems with BESSELJ
Hi Eike, Eike Rathke schrieb: Hi Regina, On Thursday, 2009-07-09 12:17:43 +0200, Regina Henschel wrote: (1) How do I introduce a new exception? The attached (hopefully not stripped by the mailing list software) patch adds the ::com::sun::star::sheet::NoConvergenceException to the offapi module. After having applied the patch, build and deliver the offapi module, then build and deliver the offuh module that creates the C++ header files. I could not apply the patch with TortoiseSVN automatically. I hope I got it right, when applying it manually. I've done all the changes. But I get a build error. Just to be sure, I start then a build --all, but get the same error: c:\softwarearchiv2\odff06\scaddins\source\analysis\analysis.hxx(149) : error C2039: 'NoConvergenceException' : is not a member of 'com::sun::star::sheet' and c:\softwarearchiv2\odff06\scaddins\source\analysis\bessel.hxx(35) : fatal error C1083: Cannot open include file: 'com/sun/star/sheet/NoConvergenceException.hpp': No such file or directory I see the file NoConvergenceException.hpp in C:\SoftwareArchiv2\odff06\solver\300\wntmsci12.pro\inc\offuh\com\sun\star\sheet and in C:\SoftwareArchiv2\odff06\offuh\wntmsci12.pro\inc\offuh\com\sun\star\sheet What goes wrong here? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] OOo2.4.2 takes of:=FDIST(a,b,c) as if it is ooc:=FDIST(a,b,c)
Hello all, during my implementation of FDISTL I saw the following problems. (1) I generate a file with a formula =FDISTL(a,b,c) and store it in version ODF1.2. Unzipping the file I find of:=FDIST(a,b,c), which is correct. Now I open the file in OOo2.4.2. I get the version warning to upgrade. (BTW, you get the warning only for first opening.) Then it opens and the cell with of:=FDIST(a,b,c) is calculated with cell content =FDIST(a,b,c) instead of showing a #NAME? error. This must not happen, because =FDIST in OOo2.4.2 means the right tail, which is internally of:=LEGACY.FDIST. The user does not know, that the result is wrong. Similar for the four parameter form. of:=FDIST(a,b,c,d) results in cell content =FDIST(a,b,c,d). The user gets an Err:504 here, because of the forth parameter. If you now save the file in OOo2.4.2 and reopen it in OOo3.2, then the original =fdistl() cell contents are not restored. We have data loss. Is there any place in source of OOo3.2 where I can avoid that error? Or can it only be solved in OOo2.4.x? (2) Another problem is the following scenario. Save in OOo3.2 with version ODF1.0. Open in OOo3.1.1. In cells with content =FDISTL() you get correctly content =fdistl() and #NAME? error, because this function is unknown to OOo3.1.1. Now save the file in OOo3.1.1 with version ODF1.2. and open it in OOo3.2. The cell content is shown as =fdistl(), but the now known function is not identified and the cells show a #NAME? error. Unzipping the file you see a of:=fdistl(), which small instead of capital letters. Even a hard recalculate does not help. Any solution for this? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Problems with BESSELJ
Hi Eike, Eike Rathke schrieb: Hi Regina, On Tuesday, 2009-06-30 23:34:27 +0200, Regina Henschel wrote: What is large and what is long lasting? I would have to implement it in C++ to see how long it really lasts. The Basic macro lasts several seconds for x1. The effort is linear in x. Basic of course is some orders of magnitude slower than C++. I have attached a draft patch to issue 40309. You can use it to test the performance. On my PC a single calculation with x=500 lasts about 1 second. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Problems with BESSELJ
Hi Eike, Eike Rathke schrieb: Hi Regina, On Sunday, 2009-06-28 20:20:17 +0200, Regina Henschel wrote: Searching around I come across an iterative solution from Peter Deuflhard [1] (German). My tests as Basic macro results in an accuracy of at least 12 digits. But it needs approximately order+x*1.1+30 iterations. [1] http://www.mathematik.uni-dortmund.de/ieem/BzMU/BzMU2007/Deuflhard.pdf So the question is, how much iterations are acceptable? Depends of course on the cost per iteration. Hard to say. How much time is a user willing to wait for an accurate result? Which still doesn't say anything about a series of values to be calculated. But, since a non-accurate solution wouldn't help much, I guess having to wait a little isn't too much.. so I just throw a number and say 1. Does that help anything? With 1 iterations you get convergence for x6000 - might be x1 - depending on order N. When I calculate the asymptotic formula with MuPad in high precision, then I get only 2 to 3 (estimated in the mean) accurate digits even for x200*N^2. From point of accuracy this asymptotic formula is unusable. For example BESSELJ(3000;200) results in -7,79235815417491E-003 with the current implementation with asymptotic formula, but the true value is -1.186524260848996e-2. Gnumeric results -1.186524260848841E-002, my Basic version of Deuflhard's algorithm results -1,18652426084901E-002. But calculating this needs 3147 iterations. For order 200 you would need x52 to result in at least 1 digit accuracy with the asymptotic formula. Second problem: The current implementation restricts the order to integer values. In mathematic the order need not to be integer. ODF1.2 also allows non-integer order. Are there plans to implement a solution in OOo with non-integer orders? I personally have no idea how to do it. No plans. Is there any practical benefit in calculating non-integer orders? I don't know. The Bessel-functions are used in technical tasks. I also don't know, which ranges are really necessary for x and for order N. Does any spreadsheet application do it? Excel rounds down to integer. The comment in ODF spec 16.15.11 says that Gnumeric allow fractional N, but my Gnumeric 1.6.3 rounds down too. In the comment Kspread is said to allow fractional N, but I haven't got that program. So the question is, shall I implement Deuflhard's algorithm nevertheless? Perhaps warn the user in the help, that large input values results in long lasting calculations? What is large and what is long lasting? I would have to implement it in C++ to see how long it really lasts. The Basic macro lasts several seconds for x1. The effort is linear in x. Or return an error, if neither asymptotic formula results at least 2 digits (How tell the user, that the result is not accurate?) A few functions set errNoConvergence if a function can't determine a result. That would be better than returning a result, which has no correct digit, as the current solution does. nor Deuflhard's algorithm calculates in reasonable time (where to cut?)? reasonable time depends on user perspective and intention. I don't think there is a general reasonable timeout. So I would prefer to implement an iterative solution and drop the inaccurate asymptotic part. The algorithm should converge, but I hesitate to use a while-loop without any cut. I need to test, for which x I can get a result in 1 second. Of cause the help should warn the user about high x-values. The asymptotic formula can be mentioned in the help in Wiki. It is not long and the user can write it directly as spreadsheet formula, if he needs huge x-values. That way he is aware of the accuracy problem. Btw, newer g++ compilers (= 4.3) have some bessel functions built-in, as part of the TR1 extensions, see http://en.wikipedia.org/wiki/C%2B%2B_Technical_Report_1, it appears that MSVC does not have them though. The MSVC Express edition has not any of that functions. Also the Boost library provides bessel functions, I don't know off-hand which library version introduced them and if it is in the one OOo uses. Maybe time to finally upgrade ;-) You are right to remember me to Boost, I have overlooked it. I had a look at Boost now. The Bessel functions (and a lot of others) are included in library Math Toolkit since version 1.35.0. I see version 1.34.0 in OOo. There is a description in http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/bessel/bessel.html. Having an actual version of the Boost library would solve a lot of other accuracy problems too. I would prefer upgrading Boost library. When can the upgrade be done? Using it then would mean to rewrite most of interpr3, interpr6 and analysis part of scaddin, which might take a while. I guess rewrite can be done step by step. In the long run we need no longer to struggle with accuracy of special functions
Re: [sc-dev] Build problems
Hi Eike, Eike Rathke schrieb: Hi Regina, On Saturday, 2009-06-20 13:26:08 +0200, Regina Henschel wrote: dmake: Error: -- `../inc/store/object.hxx' not found, and can't be made /cygdrive/c/SoftwareArchiv2/odff06/store/source Did Frank's hint in d...@ooo to regenerate the dependency files with dmake depend=t help? No :( But perhaps we should continue on d...@ooo. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How should MULTIPLE.OPERATIONS calculate?
Hi Niklas, Niklas Nebel schrieb: On 06/21/09 22:57, Regina Henschel wrote: In ODF1.2 draft spec I read, MULTIPLE.OPERATIONS executes the formula expression pointed to by FormulaCell and _all_ formula expressions it depends on while replacing _all_ references to RowCell with references to RowReplacement respectively all references to ColumnCell with references to ColumnReplacement. I think that the terms execute formula expression and while replacing is not exact enough. (1) I interpret it in the way, that I first replace all references, generating intermediate, temp sheets, and then evaluate that sheet. I get the following: The references are replaced dynamically during calculation, not in a separate step up front. The implementation uses a list of active replacements in the document (aTableOpList), no modified copies of the formulas are made. That makes it not clearer and I do not see by which rules OOo results in 702. Would you be so kind to give a step by step calculation? And besides the question what OOo does, there is the question whether that conforms to the spec. Calculation starts in (A7=)MULTIPLE.OPERATIONS(A5;A2;A6). This means, Take the formula in A5, replace all occurrence of A2 with A6 and calculate the formula then. Right? So instead of calculating (A5=)MULTIPLE.OPERATIONS(A3;A2;A4) OOo calculates =MULTIPLE.OPERATIONS(A3;A6;A4). And now? If I understand the spec correct, then OOo has to go to A3 and look whether it depends on A2 and replace A2 with A6 if so. If the formula on which a cell depends is a simple operation like + or * (as in the examples in the spec), then it makes no difference, when the replacement is done. In addition, it makes no difference whether you use the reference or use already the value to which the reference points. But here it is more complex and need to be defined. Another example, again enter in column A. 2 3 5 7 11 13 17 19 =OFFSET(A2;1;0) =A9+A2 =MULTIPLE.OPERATIONS(A10;A2;A4) Try the same with =OFFSET(A2;1;0)+A2 in cell A10 instead of =A9+A2 I would expect the same result, but it isn't. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How should MULTIPLE.OPERATIONS calculate?
Hi all, Regina Henschel schrieb: Hi all, thinking about issue 102980 and 102981 I found, that it is not clear to me, how to calculate MULTIPLE.OPERATIONS at all. Take a spreadsheet and enter the following numbers and formulas into column A, beginning in cell A1 with number 2. 2 3 =A1+A2 30 =MULTIPLE.OPERATIONS(A3;A2;A4) 700 =MULTIPLE.OPERATIONS(A5;A2;A6) I forgot to say, that the above mentioned values for A3 and A5 are only internal, temporary. The real sheet shows in A3 the value 5 and in A5 the value 32. There is no doubt about it. Only the value in A7 is in question. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Build problems (was: Rebasing CWS odff06 to m50)
Hi Eike, Eike Rathke schrieb: Hi dev, On Wednesday, 2009-06-17 11:24:36 +0200, Eike Rathke wrote: [... assertions in a Linux non-pro build ...] Applying the patch from http://qa.openoffice.org/issues/show_bug.cgi?id=102806 helped. Not committed to the CWS branch. I get the build errors: ERROR: error 65280 occurred while making /cygdrive/c/SoftwareArchiv2/odff06/autodoc/source/ary/cpp ERROR: error 65280 occurred while making /cygdrive/c/SoftwareArchiv2/odff06/store/source Details below (I hope I get the right part from the log.) kind regards Regina Compiling: autodoc/source/ary/cpp/c_osigna.cxx c:/PROGRA~1/MICROS~1.0/VC/bin/cl.exe -Zm500 -Zc:forScope,wchar_t- -GR -c -nologo -Gs -Gy -Ob1 -Oxs -Oy- -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -Gd -GR -I. -I../../../wntmsci12.pro/inc/ary_cpp -I../inc -I../../../source/inc -I../../../inc/pch -I../../../inc -I../../../WIN/inc -I../../../wntmsci12.pro/inc -I. -Ic:/SoftwareArchiv2/odff06/solver/300/wntmsci12.pro/inc/stl -Ic:/SoftwareArchiv2/odff06/solver/300/wntmsci12.pro/inc/external -Ic:/SoftwareArchiv2/odff06/solver/300/wntmsci12.pro/inc -Ic:/SoftwareArchiv2/odff06/solenv/wntmsci12/inc -Ic:/SoftwareArchiv2/odff06/solenv/inc -Ic:/SoftwareArchiv2/odff06/res -Ic:/SoftwareArchiv2/odff06/solver/300/wntmsci12.pro/inc/stl -Ic:/PROGRA~1/Java/JDK16~1.0_0/include/win32 -Ic:/PROGRA~1/Java/JDK16~1.0_0/include -Ic:/PROGRA~1/MI2578~1/Windows/v6.1/include -Ic:/PROGRA~1/MICROS~1.0/VC/include -Ic:/SoftwareArchiv2/odff06/solver/300/wntmsci12.pro/inc/offuh -I. -I../../../res -I. -Wall -wd4061 -wd4127 -wd4191 -wd4217 -wd4250 -wd4251 -wd4275 -wd4290 -wd4294 -wd4355 -wd4511 -wd4512 -wd4514 -wd4611 -wd4625 -wd4626 -wd4640 -wd4675 -wd4710 -wd4711 -wd4786 -wd4800 -wd4820 -wd4503 -wd4619 -wd4365 -wd4668 -wd4738 -wd4826 -wd4350 -wd4505 -wd4692 -wd4189 -wd4005 -DWNT -DWNT -DNT351 -DMSC -DM1500 -DINTEL -D_X86_=1 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DFULL_DESK -DSTLPORT_VERSION=400 -D_MT -DWINVER=0x0500 -D_WIN32_IE=0x0500 -DCPPU_ENV=msci -DSUPD=300 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA-DWIN32 -D_MT -D_DLL -DWIN32 -D_MT -D_DLL -EHa -DEXCEPTIONS_ON -Fo../../../wntmsci12.pro/obj/c_osigna.obj c:/SoftwareArchiv2/odff06/autodoc/source/ary/cpp/c_osigna.cxx c_osigna.cxx c:/SoftwareArchiv2/odff06/solver/300/wntmsci12.pro/bin/makedepend @C:/cygwin/tmp/mkj4cCEK ../../../wntmsci12.pro/misc/o_c_osigna.dpcc dmake: Error: -- `../inc/nametree.hxx' not found, and can't be made Running processes: 2 /cygdrive/c/SoftwareArchiv2/odff06/autodoc/source/ary/cpp dmake: Error: -- `../inc/nametree.hxx' not found, and can't be made = Building module store transform.c Running processes: 2 /cygdrive/c/SoftwareArchiv2/odff06/store/inc variables.c xslt.c xsltutils.c - Running processes: 1 Running processes: 2 /cygdrive/c/SoftwareArchiv2/odff06/store/source ..\libxslt\xsltutils.c(715) : warning C4996: 'vsnprintf': This function or variable may be unsafe. Consider using vsnprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:/PROGRA~1/MICROS~1.0/VC/include\stdio.h(350) : see declaration of 'vsnprintf' ..\libxslt\xsltutils.c(2049) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:/PROGRA~1/MICROS~1.0/VC/include\stdio.h(366) : see declaration of 'sprintf' ..\libxslt\xsltutils.c(2055) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:/PROGRA~1/MICROS~1.0/VC/include\stdio.h(366) : see declaration of 'sprintf' ..\libxslt\xsltutils.c(2058) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:/PROGRA~1/MICROS~1.0/VC/include\stdio.h(366) : see declaration of 'sprintf' ..\libxslt\xsltutils.c(2061) : warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:/PROGRA~1/MICROS~1.0/VC/include\stdio.h(366) : see declaration of 'sprintf' attrvt.c Generating Code... dmake: Error: -- `../inc/store/object.hxx' not found, and can't be made /cygdrive/c/SoftwareArchiv2/odff06/store/source - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Re: [ux-discuss] About Issue 66028's correct behavior.
Hi maoyg, maoyg schrieb: Hi,all I have updated the specification for issue 66028, if you don't object it, according to the specification I will start to implement it. I have made same changes and annotations. The file is attached to the issue. Are you going to put your description into the official spec template? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] About Issue 66028's correct behavior.
Hi Niklas, Niklas Nebel schrieb: On 05/25/09 05:33, maoyg wrote: I suggest the following behavior: For calculating the continuing interval, not-empty hidden cells are treated as if they were not hidden, and empty hidden cell are treated as if they do not exist. The hidden cell are only considered in drag direction. The target area gets the same merge pattern than the source range. Dragfilling overwrites all existing values. My idea is all hidden cells are treated as if they do not exist, but I need still to ask ux-discuss's and Niklas's advice. Non-empty overlapped cells are quite rare, but if they occur, we shouldn't ignore them. But perhaps we should extend Regina's suggestion to all empty cells, even if not overlapped (hidden) by merged cells, so any sequence of 10,empty,20,empty would be continued with 30,empty,40,empty. That is a great idea and will be a good extension. User would still get the current behavior, if he only marks the sequence '20 empty' and he gets the extended behavior, when he marks a longer sequence. And besides the fact, that merging is copied to source area, dragfill for merged and unmerged cells would behave the same, which is more friendly in using. Such changes in dragfill will need a full spec, which mentioned all this cases. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Implementation details of POISSON
Hi all,
I have a look at the function POISSON for issue
http://www.openoffice.org/issues/show_bug.cgi?id=69069
The bug is easy to fix, I have tested my solution already and it work so
far, but I have some questions.
(1)
In draft spec of ODF the function POISSON has a constraint lambda 0.
But in the code there is the part
if (lambda == 0.0)
PushInt(0);
Shall I drop that case?
If not, PushInt(0) looks strangely. Shouldn't it be PushDouble as for
other arguments too?
(2)
The code has two for-loops. One seems to be very old (A), one newer (B).
What is the right way for such loops? What type should the index have,
and if necessary, how has the cast to be done? Is there any advantage of
an integer type over double?
(A)
ULONG nEnd = (ULONG) x;
for (ULONG i = 1; i = nEnd; i++)
{
fFak *= (double)i;
sum += pow( lambda, (double)i ) / fFak;
}
(B)
for ( double f = 0.0; f x; ++f )
fPoissonVar *= lambda / ( f + 1.0 );
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Implementation details for FDIST
Hi, besides the UI-name problem I come across two other questions. (1) If the numerator degrees of freedom (r1) is 1, then the density function has a pole at x=0. The draft spec does not define the return value in that case. For x0 it defines that the return value is 0. For x=0 it defines it with a term which has a subterm x^(r1/2-1). And x^(-1/2) is not defined for x=0. I can set the result to 0 or set illegal argument or perhaps set infinity. Please decide. (2) The algorithm is not stable for large values of the degrees of freedom. There are some critical parts in the term, for example BETA(r1/2;r2/2) in the denominator which is near 0 then, and x^(r1/2-1) which will overflow or underflow. I can of cause alter the way the term is calculated, but I found, that there are always critical subterms. The problem is, that the calculating as a whole does not abort with an error, but returns some values which are wrong. You see that they are wrong, if you calculate a series of values, but you do not notice it, when you calculate a single value. I notice such problems, when I create large tables of example values. Therefore I would like to restrict the degrees of freedom to be lower than 1.0E15, where I do not saw any problems. The current implementation (=cumulative right tail) has a restriction of 1.0E10. Excel and Gnumeric have restriction to about 1.0E10 too. Are larger values really needed in real live? Please decide about a restriction. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Need UI name for new FDIST function
Hi all, (CC dev@sc.openoffice.org) with OpenFormula v1.2 we will get a new FDIST function. The current FDIST function calculates the _right_ tail cumulative distribution function of the F-distribution. The new function will calculate the _left_ tail cumulative distribution function and the density function in addition and will have an optional parameter to distinguish between cumulative and density. The old function is called LEGACY.FDIST and the new one is called FDIST internally. I'm going to implement the new function and need an UI-name for the new function. I think, it would be very confusing to use the internal names in the UI too, because than we would have different meanings of FDIST in OOo3.1 and OOo3.2. I suggest to use FDISTLEFT. But perhaps there is a spreadsheet application that has got this left tailed version already? EXCEL 2007 and Gnumeric 1.6.3 do not know this function. Any suggestions? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] signaling domain error in acosh
Hi all,
I'm working to increase accuracy of ScArcCosHyp(). The function acosh is
part of C99 but not provided by MSVC. Therefore I have written the
ersatz in sal\rtl\source\math.cxx
double SAL_CALL rtl_math_acosh( double fX ) SAL_THROW_EXTERN_C()
{
double fZ = fX - 1.0;
if ( fX == 1.0)
return 0.0;
else if (fX 1.1)
return rtl_math_log1p(fZ+sqrt(fZ*fZ+2.0*fZ));
else if ( fX 1.25e7)
return log(fX+sqrt(fX*fX-1.0));
else
return log(2.0*fX);
}
The function acosh is not defined for x1. The function ScArcCosHyp()
pushes an IllegalArgument and do not call acosh in that cases.
Do I need any kind of error handling in my rtl_math_acosh? The function
acosh might be called from somewhere else, not only from ScArcCosHyp.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Move ERF and ERFC from scaddins to sal
Hi Eike, Eike Rathke schrieb: Hi Regina, On Sunday, 2009-03-22 22:31:08 +0100, Regina Henschel wrote: May I ask you to fix that issue, so that I can update my working copy? My changes for NORMDIST and LOGNORMDIST include a fix for the NORMDIST part of http://www.openoffice.org/issues/show_bug.cgi?id=69069, which depends on ERFC. Just done, please svn update your cws workspace. Thanks. I have updated my working copy using TortoiseSVN and hope that all is OK. You will tell me, if something is wrong with my next patches. :) kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] TortoiseSVN and CrLf
Hi Eike, Eike Rathke schrieb: Hi Regina, On Wednesday, 2009-03-25 14:22:17 +0100, Regina Henschel wrote: Thanks. I have updated my working copy using TortoiseSVN and hope that all is OK. You will tell me, if something is wrong with my next patches. :) Sure :) btw, which reminds me that I saw TortoiseSVN added a ^M carriage return in the status lines (Index, file names, line numbers), it didn't touch the code lines themself. I can see the different line ends in a hex editor. The GNU patch utility neatly skipped over that, mumbling something like extraneous CRs ignored or some such, but inferior tools may not, or on Windows be lead again to convert all line ends to CrLf, I don't know. Is there an option in TortoiseSVN to tell it to always produce sane LF line feeds only? I have looked around in the settings, but do not see such an option. It seems to be possible to set a property to each single file, so that the line end it forced to LF when committing the file. It does not cover the use case of generating a patch for a folder. That setting is not possible for a folder. But I'm not familiar with TortoiseSVN, so I don't know whether such setting is possible somewhere. I can try to convert the line ends with an editor. Shall I attach such converted patches to issue 100119, so that you can compare them and test if it works? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How to export expanded LOGNORMDIST to Excel
Hi Eike, hi Daniel, Regina Henschel schrieb: No more questions for now, I'll continue my tests. Thanks for your help. Now all works as it should and I'm going to create patches. And have got the next problem. For the file token.cxx in formula/source/core/api I get an odd patch. The patch includes the function FormulaMissingContext::AddMissingExternal( FormulaTokenArray *pNewArr ) although there is nothing changed. (starting around line 1007) As far as I see, there are DOS line ends in that part. My editor PSPad autodetects DOS mode for this file. Having only UNIX line ends, it autodetects UNIX correctly. What to do? Remove the lines from the patch? Or use the patch as it is generated? kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How to export expanded LOGNORMDIST to Excel
Hi Eike, hi Daniel,
I delete the old mail-texts, because it becomes to long and confusing.
There are still problems.
First the Excel part:
Exporting to xls is OK now. I get #NV for four parameters and for
parameter count 3 the missing parameters are added.
But export to Microsoft Excel 2003 XML (.xml) is problematic.
If OOo is set to save in odf1.2, the file opens with errors in Excel.
All formulae are stripped. The error log says for example
GRUND: Ungültiger Wert
WERT: of:=LOGNORMDIST(0.6;[.B12];[.B11])
I think, there should not be this kind of WERT, because that form was
unkown 2003.
If OOo is set to save in odf1.1, the cases with parameter count = 3
are opened with formulas, only the cases with parameter count=4 give an
error and the formulas are stripped. The error log says for example
GRUND: Ungültiger Wert
WERT: =LOGNORMDIST(0.6,R[-1]C,R[-2]C,R[-3]C)
I think that is the correct behaviour.
Now the OOo-part:
I have added in FormulaMissingContext::AddMoreArgs() the lines
code
case ocLogNormDist:
if (mnCurArg == 0)
{
pNewArr-AddOpCode (ocSep );
pNewArr-AddDouble( 0.0 ); // 2nd, mean = 0.0
}
if (mnCurArg == 1)
{
pNewArr-AddOpCode (ocSep );
pNewArr-AddDouble( 1.0 ); // 3rd, standard
deviatioen = 1.0
}
break;
/code
If OOo is set to save to odf1.2, then I get the transformation
=LOGNORMDIST(0,6;3) -- =LOGNORMDIST(0,6;3;1)
That is undesirable. It is contrary to the new feature, that the
parameter is optional.
And I get the transformation
=LOGNORMDIST(0,6) -- =LOGNORMDIST(0,6;0)
It shouldn't be transformed at all (see above). But when it is
transformed, why is the third parameter missing? It is not missing, when
using odf1.1, see below.
If OOo is set to save to odf1.1, then I get the transformations
=LOGNORMDIST(0,6;3) -- =LOGNORMDIST(0,6;3;1)
=LOGNORMDIST(0,6) -- =LOGNORMDIST(0,6;0;1)
I think, those transformations are OK.
It is more complicate than I thought. I hope you are not annoyed, that I
need to ask so much.
Kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How to export expanded LOGNORMDIST to Excel
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Tuesday, 2009-03-17 18:04:12 +0100, Regina Henschel wrote:
But export to Microsoft Excel 2003 XML (.xml) is problematic.
If OOo is set to save in odf1.2, the file opens with errors in Excel.
All formulae are stripped. The error log says for example
GRUND: Ungültiger Wert
WERT: of:=LOGNORMDIST(0.6;[.B12];[.B11])
I think, there should not be this kind of WERT, because that form was
unkown 2003.
That's http://qa.openoffice.org/issues/show_bug.cgi?id=96018
OK, so i don't worry, it is outside my scope.
If OOo is set to save in odf1.1, the cases with parameter count = 3
are opened with formulas, only the cases with parameter count=4 give an
error and the formulas are stripped. The error log says for example
GRUND: Ungültiger Wert
WERT: =LOGNORMDIST(0.6,R[-1]C,R[-2]C,R[-3]C)
I think that is the correct behaviour.
Yes, it is.
Now the OOo-part:
I have added in FormulaMissingContext::AddMoreArgs() the lines
code
case ocLogNormDist:
if (mnCurArg == 0)
{
pNewArr-AddOpCode (ocSep );
pNewArr-AddDouble( 0.0 ); // 2nd, mean = 0.0
}
if (mnCurArg == 1)
That should be if (mnCurArg = 1) instead. The AddMoreArgs() method is
called once for each function, both arguments have to be added if only
one was present.
I found it in the meantime too. Using a switch as Daniel has shown me
for Excel export works as well.
{
pNewArr-AddOpCode (ocSep );
pNewArr-AddDouble( 1.0 ); // 3rd, standard
deviatioen = 1.0
}
break;
/code
If OOo is set to save to odf1.2, then I get the transformation
=LOGNORMDIST(0,6;3) -- =LOGNORMDIST(0,6;3;1)
That is undesirable. It is contrary to the new feature, that the
parameter is optional.
We want to add the parameters in any case because otherwise OOo3.0/3.1
wouldn't be able to interpret the formula, as they expect 3 parameters.
This is perfectly well. While 3.2 will be able to read without arguments
for the optional parameters, it will write something that can be read by
any 3.x release.
OK, a kind of 'political' decision. I'll implement it that way.
And I get the transformation
=LOGNORMDIST(0,6) -- =LOGNORMDIST(0,6;0)
It shouldn't be transformed at all (see above). But when it is
transformed, why is the third parameter missing?
See above, mnCurArg==0 in this case.
It is not missing, when
using odf1.1, see below.
If OOo is set to save to odf1.1, then I get the transformations
=LOGNORMDIST(0,6;3) -- =LOGNORMDIST(0,6;3;1)
=LOGNORMDIST(0,6) -- =LOGNORMDIST(0,6;0;1)
I think, those transformations are OK.
Huh? That would be strange for the second case. Are you sure it was
produced using the code you posted above? Seems more you fixed already
what I lined out ;-)
You are right, it works now as it should.
No more questions for now, I'll continue my tests. Thanks for your help.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] How to export expanded LOGNORMDIST to Excel
Hi Daniel,
Daniel Rentz schrieb:
Regina Henschel schrieb:
Hi,
I'm expanding LOGNORMDIST to the form it has in ODF spec. There it is
LOGNORMDIST( Number x [ ; Number m = 0 [ ; Number s = 1 [ ; Logical
Cumulative = TRUE() ] ] ] )
Inside OOo it is no problem. But how to export it to Excel? Excel has
3 Parameters, no one optional.
For expanding NORMDIST I had only to set the last parameter to optional.
I found in xeformula.cxx how to add the last parameter, if missing. I
have used
case ocNormDist:
if( nParamCount == 3 )
{
// NORMDIST function needs 4 parameters in Excel
PrepareParam( rFuncData );
AppendBoolToken( true );
FinishParam( rFuncData );
}
break;
and that seems to work.
But for LOGNORMDIST there are different cases, for example
LOGNORMDIST(x;m;s;TRUE()) must become LOGNORMDIST(x;m;s). A parameter
has to be removed.
LOGNORMDIST(x;m;s;FALSE()) does not exist in Excel.
LOGNORMDIST(x;m;s) Nothing to do, same as in Excel.
LOGNORMDIST(x;m) must become LOGNORMDIST(x;m;1).
LOGNORMDIST(x) must become LOGNORMDIST(x;0;1).
To increase the number of parameters, you can do something similar in
XclExpFmlaCompImpl::AppendTrailingParam (untested code!):
case ocLogNormDist:
// LOGNORMDIST function needs 3 parameters in Excel
switch( nParamCount )
{
case 1:
PrepareParam( rFuncData );
AppendIntToken( 0 );
FinishParam( rFuncData );
// do not break, add next default parameter
case 2:
PrepareParam( rFuncData );
AppendIntToken( 1 );
FinishParam( rFuncData );
break;
}
break;
That works. When exporting to xls, I get the correct function structure,
if there are one, two or three parameters in OOo. If there are four
parameters in OOo, I get a =#NV entry in German Excel 2007. I think, the
error message is correct, because the user has to know, that there has
been something, which is unknown to Excel.
It is a concession that the missing parameters are added, although the
user who will export to Excel-format should know, that Excel expects
three parameters. Shouldn't we do the same for saving in old OOo
formats, especially, when OOo3.0 is set in general to use ODF1.0-format?
If you agree, that in cases saving to old OOo-formats the missing second
and third parameters should be added, where is the place to do it?
To delete the 4th parameter, you can change the function info of this
function. Go to xlformula.cxx and look for ocLogNormDist, change the
line from
{ ocLogNormDist,290,3, 3, V, { V }, 0, 0 },
to
{ ocLogNormDist,290,3, 3, V, { V, V, V, C, I }, 0, 0 },
The C means that the 4th parameter is Calc-only and will be stripped
on export. The trailing I is needed for some internal resons.
I have done first the changes in formulabase.cxx. That gives no error,
but I see no effect, so I cannot say if it really works. Then I changed
xlformula.cxx. That works, now the entry in the xls-file has three
parameters in all cases.
I have rethought the problem. It seems no good idea to strip the fourth
parameter. If it is stripped, there are no errors in Excel, but the
cells might have different values than OOo, because in OOo you calculate
the density function and in Excel the cumulative function is calculated.
The user cannot notice, that the values are wrong, because there are no
warnings. That is not good and we should not do it. There is no way to
determine whether the forth parameter is true or false, because it might
be no constant but a reference.
The same problem is, when saving to old OOo-formats. Using four
parameters should give an error, when opening in old versions.
What do you think?
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] How to export expanded LOGNORMDIST to Excel
Hi,
I'm expanding LOGNORMDIST to the form it has in ODF spec. There it is
LOGNORMDIST( Number x [ ; Number m = 0 [ ; Number s = 1 [ ; Logical
Cumulative = TRUE() ] ] ] )
Inside OOo it is no problem. But how to export it to Excel? Excel has 3
Parameters, no one optional.
For expanding NORMDIST I had only to set the last parameter to optional.
I found in xeformula.cxx how to add the last parameter, if missing. I
have used
case ocNormDist:
if( nParamCount == 3 )
{
// NORMDIST function needs 4 parameters in Excel
PrepareParam( rFuncData );
AppendBoolToken( true );
FinishParam( rFuncData );
}
break;
and that seems to work.
But for LOGNORMDIST there are different cases, for example
LOGNORMDIST(x;m;s;TRUE()) must become LOGNORMDIST(x;m;s). A parameter
has to be removed.
LOGNORMDIST(x;m;s;FALSE()) does not exist in Excel.
LOGNORMDIST(x;m;s) Nothing to do, same as in Excel.
LOGNORMDIST(x;m) must become LOGNORMDIST(x;m;1).
LOGNORMDIST(x) must become LOGNORMDIST(x;0;1).
Can you help me?
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Decision needed for FISHERINV and ATANH
Hi Eike, Merry Christmas and a happy New Year to you. Eike Rathke schrieb: Hi Regina, On Wednesday, 2008-12-17 16:22:09 +0100, Regina Henschel wrote: Mathematically FISHER(x)=atanh(x). But the OOo function ATANH() uses the same insufficient algorithm as FISHER. Therefore ATANH() has to be changed too. The best solution, using a build-in function, is not available: atanh() is a C99 function and therefore not available in MSVC compiler. The code itself is rather simple, there are two possible methods: (1) atanh(x)=0.5*log1p(2*x/(1-x)) (2) Use the first five summands of the power series for |x|0.01, which would be atanh(x)=x(1+x²*(1/3+x²*(1/5+x²*(1/7+x²*1/9 and use atanh(x)=0.5*ln((1+x)/(1-x)) in the other cases. I trust you that the results would be identical ;-) In general they are, but to test, which cut value to use and how many summands are needed, is tedious. If there will be a reason for to make the solution independed of log1p, the algorithm can be changed. I think #1 would be best, for simplicity. I have used (1) You could also profile some ten thousand calls or so with a sample range of values to determine if any of the two approaches would have significant performance benefits over the other. I found no difference in performance. 1. Should atanh be implemented to ::rtl::math like it has been done for log1p and expm1? Yes, that would be cleanest. Please file an issue similar to i97091 It is issue 97467. Although I do not really understand the things you have done for expm1 and log1p, I have tried to mimic them. Perhaps when code freeze is over, you have some time to explain it? The related changes for ATANH, FISHER and FISHERINV are in issue 97468. A quick look at ASINH shows, that it has similar deficiencies. But that will be a new project. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Decision needed for FISHERINV and ATANH
Hi, I have examined FISHER and FISHERINV and thereby struggle about some problems. FISHERINV(x) is not accurate for x very near to zero. For example FISHERINV(1E-15)=1.1387379200E-015, but should result in 1E-15. That can be easily fixed by calling tanh() instead of the current (exp(2x)-1)/(exp(2x)+1). FISHER has the same problem for x near zero. For example FISHER(0.1)=1.002953E-005, but should return 1.00E-005. The fix is easy but needs some decisions. Mathematically FISHER(x)=atanh(x). But the OOo function ATANH() uses the same insufficient algorithm as FISHER. Therefore ATANH() has to be changed too. The best solution, using a build-in function, is not available: atanh() is a C99 function and therefore not available in MSVC compiler. The code itself is rather simple, there are two possible methods: (1) atanh(x)=0.5*log1p(2*x/(1-x)) (2) Use the first five summands of the power series for |x|0.01, which would be atanh(x)=x(1+x²*(1/3+x²*(1/5+x²*(1/7+x²*1/9 and use atanh(x)=0.5*ln((1+x)/(1-x)) in the other cases. Two decisions are needed 1. Should atanh be implemented to ::rtl::math like it has been done for log1p and expm1? 2. Which of the two methods should be used. Please instruct me. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Implement expm1 and log1p
Hi Eike, I've attached it in patch form to issue 91602 kind regards Regina Eike Rathke schrieb: Hi Regina, On Monday, 2008-12-01 16:06:53 +0100, Regina Henschel wrote: I've got a build of odff05 now and want to continue work. I need expm1 and log1p (issue 91602). I can put the following code into sal\inc\rtl\math.hxx, so I can use the functions with ::rtl::math::expm1 and ::rtl::math::log1p in interpr*.cxx Yes, that should do. I'll also add the already existing patch of i94555 to CWS odff05 today. Is it necessary to have a solution, which switches, dependent on the compiler? If yes, how can I do it? I don't think that's necessary. We can always use our own expm1 and log1p, regardless of whether the compiler provides its own. Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] How to continue after issue 94555 (CHISQDIST)
Hi Eike, Eike Rathke schrieb: Hi Regina, On Tuesday, 2008-12-02 18:34:25 +0100, Regina Henschel wrote: I have updated the patches in issue 94555. The work in that area is finished. Please have a look. Thanks a lot! I now want to go further on to BETADIST. Should I make the necessary changes based on the original odff05 or on the version, which contains already the changes from issue 94555? Please base on the already existing changes, so that it will apply seamlessly once CWS odff05 is integrated. I have to get that CWS rfQA until tomorrow evening, feature/UI freeze is approaching. I have attached the new BETADIST patches to issue 91547. The work in that area is finished too. I have added a FIXME in places, where I do not know better algorithm. I think, that the patches should be applied although the solutions are sometimes less accurate than Gnumeric. But it is a large improvement compared to the current values. If you have any questions concerning my patches, drop me a mail. I'll answer as soon as I'm back from school. The patches are based on my odff05 version after i94555 and i91602. My wording in i91547 is a little bit mistakable. kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] The default parameter of formula LOG() and POISSON().
Hi Yue, I've added the issues numbers to http://wiki.services.openoffice.org/wiki/Calc/ODFF_Implementation/Examine_functions kind regards Regina lvyue schrieb: Hi Eike, I also finished the changes to the default parameter of formula LOG() and POISSON() in these two days. I know that odff05 is going to to be freezed soon, do you still need patches of the changes? If you want me to submit, where should I put them in? shall I create new issues first? It is another weekend, wish you a happy weekend! Best regards Yue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] Implement expm1 and log1p
Hi,
I've got a build of odff05 now and want to continue work. I need expm1
and log1p (issue 91602). I can put the following code into
sal\inc\rtl\math.hxx, so I can use the functions with ::rtl::math::expm1
and ::rtl::math::log1p in interpr*.cxx
Is it necessary to have a solution, which switches, dependent on the
compiler? If yes, how can I do it?
kind regards
Regina
/** The MSVC compilers do not provide expm1 and log1p. The following
functions are an ersatz for them.
*/
inline double expm1(double x)
{
double u = exp(x);
if (u == 1.0)
return x;
if (u-1. == -1.0)
return -1.0;
return (u-1.0)*x/log(u);
}
inline double log1p(double fX)
{
double fU = 1.0+fX;
if (fU == 1.0)
return fX;
else
return log(fU)*fX/(fU-1.0);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Rebasing CWS odff05
Hi Eike, Eike Rathke schrieb: Hi, On Tuesday, 2008-11-18 17:31:03 +0100, Eike Rathke wrote: I started migrating CWS odff05 from CVS (currently resynced to m31 there) to SVN, and then will rebase it to m36 when available. I'll give you a heads up when the CWS will be ready for further development. m36 took longer than I thought it would, but now it's ready and CWS odff05 is rebased to m36. Compiled fine on Linux/x86 and Solaris/SPARC, Daniel is currently building Windows. Compiling with MSVC 9 express on WinXP has finished now. There where no problems. kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] Examine changes for ODFv1.2
Hi all, in discussion with Eike the idea has come up, to examine which changes are necessary to adapt the functions to ODF1.2, especially examine the distributions. First I thought to write a document, but now I have the idea to track it in the Wiki. My plan is a page like http://wiki.services.openoffice.org/wiki/User:Regina/MyDrafts So everyone can see what is already done, in progress, or need to be done, and the examination can be done successively as time is available. Do you agree? If yes, please tell me a place, to put it. If yes, do you have any suggestion for improvement? Kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Examine changes for ODFv1.2
Hi all, Niklas Nebel schrieb: On 10/10/08 02:44 PM, Regina Henschel wrote: in discussion with Eike the idea has come up, to examine which changes are necessary to adapt the functions to ODF1.2, especially examine the distributions. First I thought to write a document, but now I have the idea to track it in the Wiki. My plan is a page like http://wiki.services.openoffice.org/wiki/User:Regina/MyDrafts So everyone can see what is already done, in progress, or need to be done, and the examination can be done successively as time is available. Do you agree? If yes, please tell me a place, to put it. If yes, do you have any suggestion for improvement? Is it limited to ODFF? Then it would fit nicely below http://wiki.services.openoffice.org/wiki/Calc/ODFF_Implementation. Yes, it is about the changes, which are needed for ODFv1.2 I put it to http://wiki.services.openoffice.org/wiki/Calc/ODFF_Implementation/Examine_functions and linked it from the see also section. If you have a better place for the link, feel free to change it. Kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Congratulations, Regina! Gold Award winner of the Community Innovation Program.
Hi Eike, Eike Rathke schrieb: Congratulations, Regina! I feel honored, that my contribution was found worth an award, and I will surely add some more pieces to OpenOffice.org. Thanks to you and all others, answering my questions and helping me in all those things I stumble on. Kind regards Regina OpenOffice.org announced the winners of the Community Innovation Program, http://development.openoffice.org/awardees-2008.html I'm especially pleased that the Calc project is represented by Regina Henschel who is one of the Gold award winners for her work on improvements of the numerical stability of several statistical spreadsheet functions. Visit Sun Microsystem's featured article and listen to the podcast with Regina and others talking about their contributions, http://www.sun.com/aboutsun/media/features/2008-0924/ Thank you, Regina! Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] Cannot use LEGACY.xxx style of functions in OOo3
Hi, reading the ODFF draft spec I have assumed, that it is possible to access the functions which have LEGACY.xxx names in exact this way. But it doesn't work. This might not be a problem with CHIDIST, because it is clear, that this is the old, right tailed form, because CHISQDIST is the new left tailed form. But for FDIST and FINV there are no new names planed. So what will happen, if you open an old document? You cannot show the name FDIST, because it will have a different meaning. I would expect, that when opened, it is changed to LEGACY.FINV. But that can I not use in OOo3. How will it be possible to use both meanings parallel? It seems that there is something missing/wrong? Kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] How to handle ODFF constrain number must be integer?
Hi Niklas, Niklas Nebel schrieb: On 09/27/08 20:06, Regina Henschel wrote: In the ODFF draft spec of CHISQDIST is a constraint for the parameter 'degrees of freedom' to be integer. Shouldn't the argument type be integer instead? It seems to be an open ToDo, see remark at the end of part 6.2.5. Should I implement it: (1) break with an illegal argument error, if the value is not an integer or (2) round the value to an integer. The current implementation of the complement function CHIDIST rounds the incoming value, but the spec has the same constraint for LEGACY.CHIDIST. I would prefer version (2) to make it consistent with existing CHIDIST. And changing CHIDIST too, I consider to dangerous, because existing documents might no longer work. Yes, for the implementation, let's stay consistent with the other functions, that is, truncate (not round) the value. Current implementation of CHIDIST has ::rtl::math::approxFloor(GetDouble()); I'll copy it in that way in CHISQDIST in CHISQINV. The current implementations of CHIDIST and CHIINV have a constraint 'degrees of freedom 1.0E5'. The spec don't have such restriction nor mention that they might be necessary. The code has no comment, why this constraint has been introduced. Can you tell me? Huge values might overflow oder underflow somewhere, but is that reason enough to reject them from the beginning? The old implementation (before issue 90703) looks like it couldn't handle large values. If you're confident that the current implementation is better, I think that constraint can be removed. When degrees of freedom is large and x-values is a little bit smaller than degrees of freedom, you get a no convergence error. When x-value is a little bit greater you get a value, but that is less accurate than for small values of degrees of freedom (but more accurate than the old implementation for largest possible values). That would be something to be mentioned in the Wiki. If x-value is not so near to degrees of freedom, you will get 0 or 1, which are correct values in that cases. So I see now reason, not to remove the constraint. kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Which category for GAMMA and GAMMALN?
Hi Eike, thanks for your answer. Next step to finish :) kind regards Regina Eike Rathke schrieb: Hi Regina, replying after vacation gap.. On Sunday, 2008-09-21 19:26:04 +0200, Regina Henschel wrote: GAMMALN is currently in Category 'Statistical'. But in OpenFormula-v1.2-draft9.odt (which is the most current) it is in chapter '6.15 Mathematical Functions'. GAMMA is an expansion of factorials to real numbers. Shall I (1) Put GAMMA into 'Statistical' too or (2) Put GAMMA into 'Mathematical' and leave GAMMALN unchanged or (3) PUT GAMMA and GAMMALN both into 'Mathematical'? (3) wouldn't be an option as long as we don't decide to reorganize the categorization, which David also mentioned. The current categorization lists functions for Excel compatibility, so people find the functions where they are used to. I think (1) would be best as all 4 GAMMA* functions would be grouped together, pointing the user to the existence of the new GAMMA function. Even if that would add to the improper categorization. Putting only GAMMA into Mathematical and leaving GAMMALN in Statistical could be somewhat confusing, I guess. Does the GAMMA function need a name in Resource RID_SC_FUNCTION_NAMES_ENGLISH? Yes, as those names are used to store in ODF 1.2 format. Also the XFunctionAccess API still uses them for compatibility. If yes, which name should be used? In general, where can I find which names are the correct ones for ODF v1? For new functions simply use the name as defined in ODFF. Older OOo versions not knowing a function wouldn't be able to compile and interpret the formula anyway. Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Style of strings in sc/source/ui/src/scfuncs.src
Hi Niklas, thanks for your quick answer. I'll follow your remarks. kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] Style of strings in sc/source/ui/src/scfuncs.src
Hello, I'll introduce new functions and I'm uncertain, how I should write the strings in the mentioned resource file. (1) Upper or lower case? If I give the type of the parameter, should I use lower or upper case, for example Number or number? Same if I give the name of the parameter, for example alpha or Alpha? (2) Excel shows a tooltip when you enter a function, for example (German) 'GAMMAVERT(x;Alpha;Beta;Kumuliert)'. Will there be a similar feature in OOo? If yes, will the tooltip be generated from the part 'Name of Parameter' of the resource file? (3) Should the type be combined with the name? For example Cumulative (logical) or only the type Logical or name Cumulative and the other information in the description? (4) Are there any restrictions in the length of the strings 'Description', 'Name of Parameter' and 'Description of Parameter'? Kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] Which category for GAMMA and GAMMALN?
Hi, I want to bring the GAMMA function to UI, which works in general. But I have some questions for details. GAMMALN is currently in Category 'Statistical'. But in OpenFormula-v1.2-draft9.odt (which is the most current) it is in chapter '6.15 Mathematical Functions'. GAMMA is an expansion of factorials to real numbers. Shall I (1) Put GAMMA into 'Statistical' too or (2) Put GAMMA into 'Mathematical' and leave GAMMALN unchanged or (3) PUT GAMMA and GAMMALN both into 'Mathematical'? Does the GAMMA function need a name in Resource RID_SC_FUNCTION_NAMES_ENGLISH? If yes, which name should be used? In general, where can I find which names are the correct ones for ODF v1? kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Some details of EUROCONVERT() specification.
Hi Lvyue, do you know the description from Microsoft? http://office.microsoft.com/en-us/excel/HP100624761033.aspx kind regards Regina lvyue schrieb: Hi, all I'm working on EUROCONVERT(), while implementing it, I found some details unmentioned in specifies. the format of the formula is EUROCONVERT( Number; TextFrom; TextTo; [FullPrecision [; TriangulationPrecision]] ). Comparing with Excel, I find following things: 1. if TextFrom equals TextTo, the result is completely the same as Number, no matter what the following two parms are; 2.if TextFrom=EUR and TextTo is other, TriangulationPrecision has no influence to the result; 3.if TextFrom=other and TextTo=EUR, the result seems to be rounded exactly to TriangulationPrecision; 4.TriangulationPrecision's rang is 3~32767, this is not an important thing, just mention to let know. somewhere I used seem to, because I didn't find any more detailed specifices of Excel's EUROCONVERT(), so I can only guess from the result it gives. and I want to implement our EUROCONVERT() the same way. if any one has questions and suggestions, please let me know. :) Thanks Lvyue - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] What source for implementation of spreadsheet functions?
Hi, I want to bring GAMMA and CHISQDIST to UI. I've tried the guide in http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions for GAMMA and it works as described. But the build I used is rather old, a DEV300m20. Therefore I think I need a new build. Am I right? Which source should I use? kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] development status of BETADIST
Hi Eike, Eike Rathke schrieb: Hi Regina, On Tuesday, 2008-08-05 22:17:56 +0200, Regina Henschel wrote: MuPad, the CAS I have got at home, overflows for large parameters. Of cause high end programs like Mathematica have no problems there (You can use it online for single function calls). Call me blind, I didn't find that. Do you have an URL? Start with the alphabetic list http://functions.wolfram.com/alphabeticalIndex.html Click on the requested function, for example on BetaRegularized[z,a,b] (173 formulas) which opens http://functions.wolfram.com/GammaBetaErf/BetaRegularized/ In the second group you find the entries Plotting Evaluation The link Evaluation opens the input form. Kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] development status of BETADIST
Eike Rathke schrieb: Hi Regina, I postponed this reply far too many times.. sorry. Too many questions at once ;-) It seems to be one of the most difficult functions. To get an idea of that function, have a look at the file toms708.c of the R-project. On Saturday, 2008-07-19 00:35:29 +0200, Regina Henschel wrote: (2) Nearly all terms inside have parts like (1-x)^r. When the x argument is close to 1, approximately x 0., then the term (1-x)^r has large cancellation errors. I know no way to avoid it. Switching to power series 1+x^2+x^3+... is no solution, because it nearly do not converge for x near 1. That leads to the question: Which accuracy should the function have in which part of the domain? My suggestion would be, in case x 0. not to try to get more accuracy but document the loss of accuracy in the application help. Do you think this is a general problem for this particular function, or is it related to the algorithm used? Would there be not overly sophisticated algorithms that eliminated the accuracy loss? Please take a spreadsheet and enter x1=0.99+6.1E-016 and x2=0.99-4.9E-016 and then calculate 1-x1 an 1-x2. That is the range, which is possible for an input, that gives 0.99 in the 15-digit format, Calc uses. So I think in the meantime, that it cannot be solved with a program that is bound to double. The beta distribution is affected by cancellation errors more than other functions, because in its definition you have x as well as 1-x. If I understand the Gnumeric code correct, they use long double values where possible. But MSVC Express doesn't have long double, but maps it to double. I would like to compare Calc with a Gnumeric, which is compiled without support of long double. If not, and it is a general problem, we could state that in the ODFF spec as well. Stating it in the application help of course would be good anyway. I think it is a general problem, but I'm no expert in number formats. (3) For x near alpha/(alpha+beta), which is mean p, the loops need huge amount of iterations. I cound more than 5 in some cases. Currently the algorithm allows this 5 iterations, the accuracy reaches up to 12 digits. Limit the number of iterations to a reasonable value looses accuracy in that cases. The normal amount of iterations is below 50. That sounds reasonable enough for normal usage, doesn't it? How likely would the condition x near alpha/(alpha+beta) occur in real data? I don't know, but it is a usual question, to calculate the value at mean. It is surely more realistic than values near 1, which will be simple treated as 1. I tried to shift up and down - like I_x(alpha+1,b) -, but then the accuracy decreases. The problem gets worse when alpha is large and beta small, which gives a mean near 1 and the problem (2) hits in addition. If someone knows a solution that gives more accuracy with less iterations, please let me know. I failed with the algorithm BASYM from Didonato likely because of the needed erfc function. It seems, that I can solve the erfc problem :) I need to learn about static methods (see other thread). So again MSVC seems to be lacking a C99 mathematical function. Given an erfc() function the BASYM algorithm would do fine? I have implemented BASYM directly into ScTTT now. The accuracy is over 10 digits, sometimes up to 15 digits, same as the continued fraction. It calculates with less then 1000 iteration. So the accuracy is about the same as continued fraction, but with less iterations. I have to figure out for which domain it can be used savely, because outside, for example for alpha1, it gives wrong results. Didonato uses it for 0.97*px and 100alphabeta. In a test as BASIC macro I got only 6 digit accuracy. That doesn't seem to be sufficient if other algorithms would give much better accuracy. I have used implementation tricks, which are mentioned in the article, and use the beta-function directly, which is not possible in Basic. In C++ the accuracy is better know. There will be a new book [1] about the numeric of special functions end of July, and I hope to find some solutions there. But till I get the book via public library, and read it, and test algorithms, it will be to late to get a solution into OOo3.1. What to do? Setting a lower limit? We could do with a lower limit for OOo3.1 if indeed the 5 iterations are hit too many times and turn out to be a bottleneck, and once you read the book ;) improve on the algorithm for OOo3.2 Using the function in a spreadsheet, I notice no performance problems with that limit of iterations. But a real performance test would be necessary to find an acceptable limit. I'll try to finish it in a way, that BASYM is used where needed. Unfortunately summer holidays are over and my vocation ends. Implement some shifting, which will decrease the iterations in many cases, but give less accuracy
Re: [sc-dev] How to use erfc() or getErfc() from scaddins in sc ?
Hi Daniel, Daniel Rentz schrieb: Hi Regina, Regina Henschel schrieb: [..] But the next part, which I want to modularize, is the algoritm known as BASYM (Didonato/Morris algoritm 708). It is a part of about 90 lines. Unfortunately it needs the private functions double ScInterpreter::GetUpRegIGamma( double fA, double fX ) and double ScInterpreter::GetLogBeta(double fAlpha, double fBeta) How to solve this? I know, if I would make it a private function of ScInterpreter too, I can access GetUpRegIGamma and GetLogBeta. But is that the structure you want? Are there other, better ways to get access to that functions? Are ScInterpreter::GetUpRegIGamma() and ScInterpreter::GetLogBeta() static (A), can they be static (B), or do they actually use members or other non-static functions of ScInterpreter (C)? (A) remove them from ScInterpreter and make them local functions. (B) same as (A) (C) it does not help, BASYM has to be a private member of ScInterpreter. Non of the functions that do mathematical calculation is static and they call one another across the files. But as you might have noticed I'm a very beginner and cannot decide yet. I'll come back, when I have learned about Static method. kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] development status of BETADIST
abgeschickt ohne Begrüßung, tut mir leid. Bitte hinzufügen: Hi Eike, :) Bis dann Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] development status of BETADIST
Hello all, this mail is about BETADIST(x,alpha,beta,lower bound, upper bound, cumulative) I have attached the actual stage of my work to issue 91547. The patch has already a status that it could be used, but there are still problems. I have attached it anyway, so that you can have a look at it, test it and report defects. Perhaps someone has a good idea to solve one of the problems. Anyway, the algorithms are better than the current implementation in normal cases. Problems: (1) The definition in OpenDocument-formula-20080618.odt in 6.17.7 has errors in the density case. Eike, in addition to the document I already sent to you: The definition does not state, what result should give BETADIST(1,1,beta,0,1,false()) for beta 1 BETADIST(0,alpha,1,0,1,false()) for alpha 1 In both cases there is a pole. I set illegal argument now. (2) Nearly all terms inside have parts like (1-x)^r. When the x argument is close to 1, approximately x 0., then the term (1-x)^r has large cancellation errors. I know no way to avoid it. Switching to power series 1+x^2+x^3+... is no solution, because it nearly do not converge for x near 1. That leads to the question: Which accuracy should the function have in which part of the domain? My suggestion would be, in case x 0. not to try to get more accuracy but document the loss of accuracy in the application help. (3) For x near alpha/(alpha+beta), which is mean p, the loops need huge amount of iterations. I cound more than 5 in some cases. Currently the algorithm allows this 5 iterations, the accuracy reaches up to 12 digits. Limit the number of iterations to a reasonable value looses accuracy in that cases. The normal amount of iterations is below 50. I tried to shift up and down - like I_x(alpha+1,b) -, but then the accuracy decreases. The problem gets worse when alpha is large and beta small, which gives a mean near 1 and the problem (2) hits in addition. If someone knows a solution that gives more accuracy with less iterations, please let me know. I failed with the algorithm BASYM from Didonato likely because of the needed erfc function. In a test as BASIC macro I got only 6 digit accuracy. There will be a new book [1] about the numeric of special functions end of July, and I hope to find some solutions there. But till I get the book via public library, and read it, and test algorithms, it will be to late to get a solution into OOo3.1. What to do? Setting a lower limit? Implement some shifting, which will decrease the iterations in many cases, but give less accuracy? Return the reached values although they are not as accurate as others, or set a no convergence error? (4) Which values of alpha and beta should be supported? The larger they are the smaller is the range in which the result goes from near 0 to near 1. So one machine number for x would cover a large range of correct results. I have no experience in using BETADIST in real life, but I doubt that something like alpha=2 is really needed. (5) The spec says that the Cumulative parameter has type logical. In which type is it pushed to the stack? How shall I get it from the stack? No problems, but ToDo's: (6) Adapt the algorithms to the solution concerning expm1 and log1p. (7) Remove the part with ScTTT, which I have included for testing. (8) Write a spec, and change UI and application help for the sixth parameter. (9) The patch contains algorithms for the Beta function in normal and logarithmic version. They are needed for BETADIST. If there will be a spec, both functions can be brought to UI easily. Currently they are only mentioned in the huge group in OpenDocument-formula-20080618.odt. kind regards Regina [1] http://www.amazon.de/Numerical-Methods-for-Special-Functions/dp/0898716349/ref=sr_1_2?ie=UTF8s=books-intl-deqid=1216406061sr=1-2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] missing function log1p and expm1
Hi Eike, in addition: Regina Henschel schrieb: which I found as tip on http://www.plunk.org/~hatch/rightway.php. He gives also a version from which he says, it is from Kahan, but I have not tested the other. In the meantime I tested that version, and it works as well. I have submit http://www.openoffice.org/issues/show_bug.cgi?id=91602 for the problem. kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] wrong display for special function result near 1
Hello all, I'm working on BETADIST. For certain inputs my version of that function returns a value, which is near to 1. The formula in the cell is =BETADIST(B$3;$B$1;$A8) with B3=0,999 and B1=1e-9 and A8=1,5. The result should be shown as 1,00E+000 but it is shown as 10,00E+000. It is really a display problem and not a problem of my function, because the result of the formula =BETADIST(B$3;$B$1;$A8)+1 is correctly shown as 2,00E+000. To see the problem, you need my interpr3.cxx and the interpr6.cxx from cws DEV300/odff04. You cannot use the normal version, because there the function is not accurate enough to get that problem. I have simulate the algorithm with MuPad, a high precision CAS. There I get the value 0.9993332933300668465 (first digits) for my result. But I don't know which value OOo has internally. Does anyone know the reason or like to have a look at it or show me a way to get the root of the problem? Kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
