[sc-dev] Re: Farewell
Hi Niklas, Niklas Nebel schrieb: In case anyone is still reading these lists: Ja, ich habe sie noch abonniert. I have left Oracle and started a new job, not related to OpenOffice.org. Because of this, I won't have enough time for any meaningful participation in the "new" OpenOffice.org at Apache. So it's time for me to say goodbye. OpenOffice.org has always been great fun for me, so I'm happy to see some familiar names in the Apache project, which makes me confident they will be able to continue the success of OpenOffice.org. Thanks everybody for a great time! Niklas Ich wünsche dir alles Gute in deinem neuen Job. Ich hoffe natürlich, dass du nach einer Weile feststellst, dass Teilnahme an der Community auch in der Freizeit möglich ist und wir wieder von dir hören. Alles Gute 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] 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] Internship 2010: Statistical Data Analysis Tool
Hi all, There has been the project 'Internship 2010: Statistical Data Analysis Tool'. On Wiki http://wiki.services.openoffice.org/wiki/OpenOffice.org_Internship/Projects/2010/Statistical_Data_Analysis_Tool I read in 'Project Status' the sentences "The implementation of the data analysis tool project has been completed. The analysis tool has all the above mentioned analysis methods covering variety of statistical aspects." But where can I find the results? 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] Removing ULONG
Hi all, I'm currently looking in ScBinomDist to remove the PushNoValue() cases. I see a lot of ULONG there and as Carsten has announced, that ULONG will be removed, my question now, how I should replace it. The parameters n (total number of independent trials) and x (number of successful trials) are integers in ODF. As we store them in double, they are exact up to 48Bit. The code has some for-loops up to this parameters. What type shall I use for the index i in the loops? 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 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] 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..
Hope you had a nice time in vacation. I'm pleased that you remember,
that I had some questions.
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)
I get
0,-1.#NANE+000 #VALUE! #VALUE!
#NUM! #NUM! #VALUE!
#NUM! #NUM! #VALUE!
I got different results in OOO330m10 and DEV300m85, no error at all, and
even different in one value of the last column, being
OOO330m10 Solaris/x86:
28.1318681319 -3.5164835165 10
-819855292164869000 27328509738829 7.79926253788309E-015
546570194776579000 -182190064925526000 -3.33
DEV300m85 Linux/x86:
28.1318681319 -3.516483516510
-819855292164869000 27328509738829 0
546570194776579000 -182190064925526000 -3.33
Of course both obviously look wrong. Difference of 0 vs.
7.79926253788309E-015 might be because of different compilers'
optimizations, though it looks suspicious. I assume you're working on
Windows. Would be good to know what exactly happens.
I guess, that the wrong notation in upper, left cell is already
tracked in issue 114125.
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 see in Dev300m88.
NaN #VALUE! #VALUE!
#NUM! #NUM! #VALUE!
#NUM! #NUM! #VALUE!
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.
I ran that in a non-product debug build where the LU decomposition is
written to stderr, there was no 0, which explains why singularity was
not detected. The code is in interpr5.cxx at line 767
fprintf( stderr, "\n%s\n", "lcl_LUP_decompose(): LU");
and displayed
9.11827
0.33 0.066 0.099
0.11 0.33 1.8e-18
Can you compare that with your values?
I work on WinXP with cygwin. What do I have to do exactly? I have tried
to build with 'sc> build debug=true' or with 'sc>build dbglevel=2' But I
see no effect.
Then I have removed the 'OSL_DEBUG_LEVEL > 1' condition and called
'scalc.exe 2>&1' from within cygwin I sometimes get an output, sometimes
not. I do not know how to force an output.
The times I get an output it is
9.1 18 27
0.330.066 0.099
0.110.330
My own build is currently based on Dev300m86.
I have added a test to the end of 'static int lcl_LUP_decompose', before
'return nSign;'
bool bSingular=false;
for (SCSIZE i=0; iGetDouble(i,i))==0.0);
if (bSingular)
nSign = 0;
That catches the simple case of exact zero.
In ScInterpreter::ScMatInv() line 924 some possible checks are
documented, of which one is implemented but disabled because
a "reasonably sufficient error margin" would have to be found for
fInvEpsilon. That would then set errIllegalArgument. Maybe going into
detail there could solve the problem for MINVERSE.
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?
Do you have a recipe to detect such cases? An error would be way better
than wrong results..
Not really. It seems to belong to the hard problems.
In case of a matrix and its inverse it is possible to calculate the
condition number of the matrix as ||A||*||A^-1||, where ||.|| denotes
the maximum absolute row sum. Matrices with large condition number are
likely singular or ill-conditioned. But there still is the problem what
is "large".
In the meantime I have worked further on LINEST. I have tried QR
decomposition instead of LU decomposition. I know it is more time
consuming, but the accuracy is far better. For example something like
=LINEST(B11:B16;{100|101|102|103|104|105}^{1;2;3;4}) to get a polynomial
regression give results with 3 digit accuracy where our current version
o
[sc-dev] Empty and missing parameters in LINEST/LOGEST and TREND/GROWTH
Hi all, the draft spec for ODF1.2 allows empty and missing parameters. If I interpret the syntax description correctly, this cases are possible: For LINEST/LOGEST 1 Y ; X ; Const ; Stats 2 Y ; X ; Const 3 Y ; X 4 Y ; ; Const ; Stats 5 Y ; ; Const 6 Y 7 Y ; The syntax variants 8 Y ; X ; ; Stats 9 Y ; ; ; Stats are not possible. There is no way to get Stats without Const. For TREND/GROWTH 10 Y ; X ; newX ; Const 11 Y ; X ; newX 12 Y ; X ; ; Const 13 Y ; X 14 Y ; X ; 15 Y ; ; newX ; Const 16 Y ; ; newX 17 Y ; ; ; Const 18 Y 19 Y ; 20 Y ; ; Not allowed 21 Y ; X ; newX ; 22 Y ; ; newX ; 23 Y ; X ; ; 24 Y ; ; ; There is no way in the syntax pattern to ommit Const and set the ';' at the same time. Excel allows all that variants. Are the missing Const and Stats set to the defaults during import? If not, should they be set there? Do you want to allow all variants too when entering a formula? If yes, which part would be responsible to correct them, at the latest when saving to valid ODF-format? I have no solution for 7, 14, 19, 20 which ends with ';'. Are they really intended? Or need ODF to be changed? I catch missing parameters in-between (4,5,12,15,16,17) with IsMissing(). But it does not work for ending ';'. Perhaps ocMissing is not set for ';' at the end position? 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
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] 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
[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, Jari Kosonen schrieb: Dear Developers Team, I'm no developer. Can you advice how to add bitmap image into openoffice calc cell by using calc-macro (and no uno-type)? You cannot put an image _into_ a Calc cell, Calc cells can only hold strings, values, and formulas. You can only put an image on the associated draw page and anchor it to a cell. 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 Daniel, Regina Henschel schrieb: Hi Daniel, Daniel Rentz schrieb: Am 09.08.2010 11:26, schrieb Regina Henschel: Hi David, 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. No problem in DEV300m86. Building DEV300m86 and testing there will take some time. So back again. I have build DEV300m86 (without binfilter, because build breaks there) and can confirm, that saving works in DEV300m86. 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 Daniel, Daniel Rentz schrieb: Am 09.08.2010 11:26, schrieb Regina Henschel: Hi David, 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. No problem in DEV300m86. Building DEV300m86 and testing there will take some time. Did you try it in a debugger? No, I do not know how to do it :( 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] 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
[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
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,
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
[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,
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
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 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,
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 Eike,
Eike Rathke schrieb:
[..]
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?
Off-head, as pre-3.0 doesn't implement that function and the (upper)
programmatical name is not expected to be encountered in documents
originating from ODF 1.1 and earlier, does
{ "IMCOT", "IMCOT", false, "com.sun.star.sheet.addin.Analysis.getImcot",
"IMCOT" },
already help?
No, it does not help. I had tried it before. In setting "ODF1.0/1.1" the
programmatic "com.sun.star.sheet.addin.Analysis.getImcot" will be shown
in directly reopening and in round trip as well, both for ods and for
sxc format.
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,
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,
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
Hi Daniel, Regina Henschel schrieb: == 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 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? 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
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi all,
Daniel Rentz schrieb:
Regina Henschel schrieb:
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.
Right, fix has been integrated into m77
http://qa.openoffice.org/issues/show_bug.cgi?id=79854
Now I have a build based on m78. I made some import/export tests.
Excel2003 xml is totally broken (issue 94261) and not mentioned below.
== 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.
== 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?
I tried to add them to saFuncTableOdf in oox/source/xls/formulabase.cxx,
but does not know, which values to use for eighth and ninth parameter. I
have tried all combination of {RR},{VR} and FUNCFLAG_EXTERNAL,
FUNCFLAG_MACROCALLODF. But it has no effect on my test results.
The test results are:
== B1 Directly reloading ==
Correct with general setting 'ODF 1.0' in ods, sdc, sxc, and xls
Correct with general setting 'ODF 1.2 extended' in ods, sdc, and xls.
It fails for sxc (issue 95312).
== B2 Opening and resaving in StarOffice8 and Excel2010, reloading in my
build ==
Correct with general setting 'ODF 1.0' in xls, sdc, and sxc.
Correct with general setting 'ODF 1.2 extended' in xls and sdc.
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 have a look at issue 101386. Is it the same problem?
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: 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] 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: 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: 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 copy&paste 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
[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
[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
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 x<134217728. 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 x<134217728 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
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 x<2^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 "x<134217728" 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 Henschel An: Calc dev 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] Copying Conditional Formatting across spreadsheets
Leonard Mada schrieb: Dear Calc Team, I would like to easily copy the *Conditional Formatting* across different sheets. [see issue: http://www.openoffice.org/issues/show_bug.cgi?id=105659] That is possible without problems. 1. Mark the cell in the source spreadsheet. 2. Copy to clipboard. 3. Goto the target spreadsheet. 4. Mark the cells, which should get the conditional formatting. 5. Menu Edit > Paste special 6. Deselect all but "Formats". OK The needed styles are copied too automatically. 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] 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
[sc-dev] What are valid arguments for INDIRECT
Hi,
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?
And same with issue 104969, References to external sheets not allowed or
allowed but still need to be implemented?
And what about all type of names? INDIRECT("name") will fail. I know,
that is mentioned in the help. But must it fail?
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] Question about WEIBULL function
Hi André, André Schnabel schrieb: Hi, I'm about doing the review for our help translations and came across an inconsistency for the WEIBULL function (the parameter C). The new Help for this reads: If C is 0, WEIBULL calculates the cumulative distribution function. If C is 1, WEIBULL calculates the probability density function. this is equivalent to the wiki: http://wiki.services.openoffice.org/wiki/Documentation/How_Tos/Calc:_WEIBULL_function But the function wizard's quick tip is: C: Cumulated. C=0 calculates the density function, C=1 the distribution. What states quite the opposite. Can somebody tell, what is correct here? In the spec it is: WEIBULL Summary: Calculates the Weibull distribution. Syntax: WEIBULL( Number value ; Number alpha ; Number beta ; Logical cumulative ) Returns: Number Constraints: value >= 0; alpha > 0; beta > 0 Semantics: Calculates the Weibull distribution at the position value. If cumulative is false, the probability density function is calculated. If cumulative is true, the cumulative distribution function is calculated. And because 1 is treated as true and 0 is treated as false, 1 is cumulative and 0 is density. It is the same for all kind of distributions. Is the English help the text that I get in DEV300m57? Then the help is wrong. 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
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
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 (N<0 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 (N<0 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(A2<0;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
[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] 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.
That does not work in that way. I have earlier tried with a const
OUString, which doesn't work too. But I have found my error now. You
need not only the parameter for Message, but the parameter for Context
too. So
...Exception(STRFROMASCII("convergence error"),NULL)
compiles.
On the other side, in addincol.cxx, I'm still not able to compare the
strings. I thought something like
if (rWrapped.TargetException.Message.equals("convergence error"))
would work, but it doesn't compile. The version with first declaring
const ::rtl::OUString sMyMessage =
::rtl::OUString::createFromAscii("convergence error");
and then using
if (rWrapped.TargetException.Message.equals(sMyMessage))
doesn't compile too.
But because the solution with a new exception works, I'll not bother you.
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 Niklas, Niklas Nebel schrieb: Regina Henschel wrote: 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? The scaddins module doesn't use the headers from offuh, but creates its own ones. This is done in part to bring it closer to being a pure UNO component (it isn't really one because it depends on tools for the resource files), and in part because it's needed for the own interfaces anyway. The list of types for which headers are made is in UNOTYPES in makefile.mk. Just add the new one there. Here? /scaddins/source/analysis/makefile.mk Shall I remove it from /offapi/com/sun/star/sheet/makefile.mk ? 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
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 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] OOo2.4.2 takes of:=FDIST(a,b,c) as if it is ooc:=FDIST(a,b,c)
Hi Eike, Eike Rathke schrieb: Hi Regina, On Saturday, 2009-07-04 14:53:45 +0200, Regina Henschel wrote: 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. Ouch.. [..] 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. "Content not restored"? What exactly is imported/displayed, and what is missing? I assume it is imported as FDIST instead of FDISTL (UI names), correct? I know, that it cannot be restored, as the OOo2.4.2 has turned of:=FDIST([.B3];[.B1];[.B2]) to oooc:=FDIST([.B3];[.B1];[.B2]) when saving. I mentioned it as contrast to the problem exchanging documents between OOo3.2 and OOo3.1. 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? The erroneous handling of of:FDIST as oooc:FDIST in 2.4.2 could only be fixed with a change in 2.x; however, a correct fix could only be to either make 2.x not load 'of' namespace as formulas at all, or completely implement handling of both namespaces, which would be quite tough, partly the same I did for OOo3.0 I've feared that. An intermediate workaround to not make the function calculate wrong results in 2.4.2 because of of:FDIST vs. oooc:FDIST could be to always forcedly write the 4th parameter, such that 2.4.2 will return an error, which is at least better than a wrong result. More nasty than nice, but ... For the "contents not restored" I'd need more details. If it is the function being imported as oooc:FDIST instead of of:FDIST, we might trick the compiler into translating that to of:FDIST if the function has 4 parameters, given that we wrote always 4 parameters as mentioned above. Again, more nasty than nice, but ... And not a really solution. The draft spec allows three parameters and a OOo2.4.2 version can get a -in this way valid- document from third party. (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 It is not really known, because of:FDISTL doesn't exist. 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? We could introduce an alias handling in the compiler and tie that to the element's value and accept the alias only for documents created by versions OOo3.0 and OOo3.1 The content.xml has the node table:formula="of:=fdistl([.B3];[.B1];[.B2];1)" office:value-type="float" office:value="0"> #NAME? So the table formula exists, besides being in lower case. Perhaps a conversion is not needed in the way, that it is done automatically. As long as the table:formula attribute is preserved with saving, I can also image to implement a "repair"-command, that takes the table:formula attribute and generates a valid formula from that and recalculate the cell then. I think, that a solution is necessary, because there will be similar situations in future, that there are two versions, both working with ODF1.2, where a newer version knows a function that the older does not know. However, given all these quirks I'm hesitating to implement FDISTL at the current stage, especially with regard to the OOo2.4.2 problems. I agree, not to implement FDISTL with OOo3.2. I can send you the code which contains the algorithms, so that you can keep it and the algorithms get not lost. Do you want a patch or the complete interpr3.cxx file? I think, that the FDIST problem has to be solved in OASIS. For CHIDIST it has been solved by introducing the new function name CHISQDIST. The left tailed variant of the F-distribution needs a new name too. At least it should not allow three parameters, so that application can notice the change by counting the parameters. Do you take the problem to the committee? 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: 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. I cannot find such an exception, I only find throw CSS::lang::IllegalArgumentException() and throw CSS::uno::RuntimeException() 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 x>1. 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
[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 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 x<6000 - might be x<1 - 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 x>200*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 x>52 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 x>1. 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 ta
[sc-dev] Problems with BESSELJ
Hi all, looking at issue http://www.openoffice.org/issues/show_bug.cgi?id=40309 I get some problems: The algorithm, which is used for x<=30 is not good. The results become invalid for larger order and for larger x. I guess that this was the reason to switch to the asymptotic formula for x>30. But this formula has the precondition that x is much larger than order^2. My tests show, that for c significant digits, you need x > order^2*13^c (estimation). 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? 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 x>52 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. 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? Or return an error, if neither asymptotic formula results at least 2 digits (How tell the user, that the result is not accurate?) nor Deuflhard's algorithm calculates in reasonable time (where to cut?)? 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
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/22/09 17:10, Regina Henschel wrote: Right. A1+A2 is calculated as A1+A6, which is 2+700, or 702. So OOo drops "=MULTIPLE.OPERATIONS(A3;A6;A4)"? OOo acts as if the formula in A5 is "=A3". All references to A6 in A3's formula are replaced with A4. There are none, so the result is A3, unchanged. thanks for your patiently explaining. It is clear now, which rules OOo follow. 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/22/09 15:11, Regina Henschel wrote: 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. Right. A1+A2 is calculated as A1+A6, which is 2+700, or 702. So OOo drops "=MULTIPLE.OPERATIONS(A3;A6;A4)"? OOo acts as if the formula in A5 is "=A3". [..] 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. OFFSET doesn't mix well with MULTIPLE.OPERATIONS because it's one of the functions that cause the cell to be recalculated on any change, like RAND or NOW. So the changed formula depends on the special "ALWAYS" range, not on A2. That's a matter of implementation, and could probably be changed, but it doesn't look like a high-priority issue. That means, that it is another problem and a real bug and the result should be 18 in both cases? [18= 11 (content of one position after A4)+7 (content of A4)] "OOo Later" would be OK 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] 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
[sc-dev] How should MULTIPLE.OPERATIONS calculate?
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) What do you expect in cell A7? OOo3 calculates the value 702. 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: For =MULTIPLE.OPERATIONS(A5;A2;A6) we have to replace in the content of A5 all references to A2 with A6. So content of A5 becomes =MULTIPLE.OPERATIONS(A3;A6;A4). But A3 is not a finite number but a formula which depends on A1 and A2. Therefore in A3 the reference A2 is also replaced with A6 and the content of A3 becomes =A1+A6. Our new sheet content with replaced references is now: 2 3 =A1+A6 30 =MULTIPLE.OPERATIONS(A3;A6;A4) 700 With this sheet we have to take the value of A5 as result for A7. Calculating the value of A5 we have to execute a MULTIPLE.OPERATION. It says that the reference A6 in the formula in A3 is to be replaced with the reference A4. We get the next temp speat content: 2 3 =A1+A4 30 700 with the inner-outer-order of calculating A3 then A5 then A7. So the shown values are 2 3 32 //result of =A1+A4 30 32 //result of A3 700 32 //result of A5 (2) I replace the reference in the formula expression referenced by FormulaCell and then immediately execute that expression. For =MULTIPLE.OPERATIONS(A5;A2;A6) we have to replace in the content of A5 all reference to A2 with A6. So content of A5 becomes =MULTIPLE.OPERATIONS(A3;A6;A4). This results in the sheet 2 3 =A1+A2 30 =MULTIPLE.OPERATIONS(A3;A6;A4) 700 Calculating the result of A5 we have to replace all references A6 in cell content A3 with A4. This results in the sheet 2 3 =A1+A2 // There is no A6 reference 30 700 We calculate the results in inner-outer-order first A3 then A5 then A7, and get the sheet 2 3 5 //result of A1+A2 30 5 //result of A3 700 5 //result of A5 Mmh, neither (1) nor (2) results in 702. 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
Re: [sc-dev] About Issue 66028's correct behavior.
Hi Maoyg,
maoyg schrieb:
> Hi, all
> I want to discuss this issue's the specification with your.
> If you think it is important, I hope you can vote it.
> As we know, the calc for the merged cell(selection etc) is different from the
> excel,
> I have some advice for the spec, I hope you can discuss and help me to finish
> it. :)
> I have define a corrent behavior about issue 66028, please review it. thanks.
> http://www.openoffice.org/issues/show_bug.cgi?id=66028
The hidden cells can still contain values and can still be used in
references in OOo. You need to say, what happens with the hidden cells:
How their value is considered for the continuing interval of the shown
value, and how the hidden values are continued.
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.
{ } indicates merging
Expample A with varying intervals because of hidden cells
{ 10
hidden 6}
{ 20
hidden 8}
is continued to
{ 11
hidden 7}
{ 21
hidden 9}
Example B with consistent intervals including hidden cells
{ 10
hidden 12}
{ 14
hidden 16}
is continued to
{ 18
hidden 20}
{ 22
hidden 24}
Example C with empty hidden cells
{ 10
empty }
{ 20
empty}
is continued to
{ 30
empty}
{ 40
empty}
Example D with merged cells and single cells mixed
{ 10
empty}
20
is continued to
{ 30
empty}
40
Example E which shows considering in drag direction
{ 10 empty
empty hidden 2}
{ 14 empty
empty hidden 5}
is continued to
{ 18 empty
empty hidden 8}
{ 22 empty
empty hidden 11}
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
[sc-dev] Schedule for CWS odff06
Hi Eike, you have set 2009-07-06 as date for 'ready for QA', but feature freeze for 3.2 is already 2009-06-dd http://wiki.services.openoffice.org/wiki/OOoRelease32 And issue 100119 is a feature, isn't it? 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] Implementation details of POISSON
Hi Eike, Eike Rathke schrieb: Hi Regina, On Wednesday, 2009-04-15 22:35:14 +0200, Regina Henschel wrote: 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. Great! I have attached a patch to the issue. When I have generated the patch with TortoiseSVN, it includes all the other parts, on which I am working in interpr3.cxx. I have deleted them and hope, that the patch will still work for you. I cannot generate test values with MuPad as I did in other cases, because for large lambda or x each value would last some minutes. But you can compare the results with Gnumeric. The values should be the same for about 12 digits. I made some samples with MuPad and have noticed, that sometimes Gnumeric is wrong in the last two digits. (Most time Gnumeric is accurate in all digits.) 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 x<0 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
Re: [sc-dev] Need UI name for new FDIST function
Hi Leonard, Leonard Mada schrieb: Hi Regina, I would suggest DISTF(). It would be short and reflects the change in tail. But I worry, that people will not remember which one is 'right tail' and which one is 'left tail'. Therefore I like Jaron's proposal FDISTL more. . It adds the benefit that all distribution functions could be grouped at some point under a DIST...() name. DISTGAMMA() DISTPOISSON() DISTGAUSS() (reluctantly DISTNORM) It is not possible to rename the existing ones. But such names could be introduced only in addition. That would not only affect Calc's interpreter but all export filters too. I think it is not worth the large effort, because the current naming schema xxxDIST is not really bad. 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 x<1. 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] 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] 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
[sc-dev] Move ERF and ERFC from scaddins to sal
Hi Eike, I have now build CWS odff06. I have regenerated patches to move ERF and ERFC from scaddins to sal, now based on odff06. http://www.openoffice.org/issues/show_bug.cgi?id=97091 Please have a look. 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. 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 Wednesday, 2009-03-18 12:25:32 +0100, Regina Henschel wrote: 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? Best to remove DOS line ends from your sources before creating patches. I have made the patches with TortoiseSVN, (I'm working on WinXP) and it makes the patch between my altered file in the working copy and the file on the repository on http://svn.services.openoffice Which cws/milestone is your patch based on? I use DEV300m42. I have looked at odff06, there are indeed no DOS line ends anymore in that file. I already removed that rubbish in an earlier CWS that was integrated. In CWS odff06 based on m43 there are no DOS line ends at that place. Please work on the odff06 source base, if possible. I don't know, if it is possible to move to odff06, without building it from scratch and want not to try it while I work on NORMDIST. But the issue need not to be finished tomorrow and I know all the places where I have to change something now. So I will give it a try and start a complete new build if necessary. 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,
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
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;
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
