[sc-dev] Re: Internship 2010: Statistical Data Analysis Tool

2011-03-28 Thread Regina Henschel

Hi Niklas, hi Pivithuruw,

Niklas Nebel schrieb:

On 28.03.2011 10:50, Niklas Nebel wrote:

It's in the download section of sc.openoffice.org, the URL is now
http://openoffice.org/projects/sc/downloads/directory/Data%20Analysis.
But apparently, some of the files were truncated in the Kenai
transition. I'll try to get that fixed.


I re-uploaded it. final evaluation version is the latest version.

Niklas


Thanks, I have found it. Installations works fine with DEV300m104.

Kind regards
Regina
--
-
To unsubscribe send email to dev-unsubscr...@sc.openoffice.org
For additional commands send email to sy...@sc.openoffice.org
with Subject: help


[sc-dev] type logical in Excel

2011-02-28 Thread Regina Henschel

Hi,

I just noticed, that Excel 2007 and Excel 2010 distinguish between type 
Logical and type Number. Is this new in Excel 2007/2010 or did Excel had 
a separate type Logical before? (I haven't got an older version of Excel 
and therefore cannot examine it by myself.)


I came across it, when I looked at the Microsoft test files from 
http://lists.oasis-open.org/archives/office/201102/msg00032.html


Kind regards
Regina
--

To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: sy...@sc.openoffice.org with Subject: help


[sc-dev] Questions about LINEST implementation

2010-10-21 Thread Regina Henschel

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

2010-10-19 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

I'll try to give some long outstanding answers to questions you asked
shortly before I went to OOoCon and then into vacation and then..

On Thursday, 2010-08-26 22:33:20 +0200, Regina Henschel wrote:


next problem with matrices :(

(All with German local with comma as decimal delimiter)

Fill A1:C3 with
1   2   3
3   6   9
9,1 18  27
Calculate =MINVERSE(A1:C3)





That looks related, though I don't know at the moment how that should
occur in Calc. We usually convert all INF and NAN to errors. Which
milestone did you use?



I have know installed OOo3.3.0 RC1 on Windows7 and get
NaN #VALUE! #VALUE!
#NUM!   #NUM!   #VALUE!
#NUM!   #NUM!   #VALUE!

Shall I write an issue?

Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] TREND/GROWTH in ODF

2010-09-25 Thread Regina Henschel

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

2010-09-18 Thread Regina Henschel

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

2010-09-01 Thread Regina Henschel

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

2010-08-29 Thread Regina Henschel

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

2010-08-26 Thread Regina Henschel

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

2010-08-13 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Thursday, 2010-08-12 16:38:33 +0200, Regina Henschel wrote:


The current implementation avoids to copy the matrices X or Y,
although that would ease and shorten the code. I thought there must
be a reason for that and tried to avoid it too. I hesitate to copy X
or Y, because they might have a huge number of lines.


Indeed.


I will try only using new matrices for products like X'X as it is
done in the current implementation. That will result in a lot of
nearly identical multiplication methods, but I think, that is better
than copying the matrices.


To avoid both, having overly complicated code and copying large
matrices, we could introduce a const/non-const flag in ScMatrix,
defaulted to const and set to non-const by GetNewMat(), but to const
again when stored in ScFormulaResult. The usual case is that a matrix
was constructed from a range reference by the interpreter and not as
a const array or formula cell result. Then having
a ScMatrix::CloneIfConst() method could just return the current matrix
if non-const and would have to actually clone only in rare const cases.

Just an idea..


The problem with constant parameters is already actual :(
http://www.openoffice.org/issues/show_bug.cgi?id=113879

Enter the formula
=LOGEST({2|3|5|8|13};{2|4|6|8|10})
Set the cursor into the formula range to see the formula in the input line.
Recalculate some times.
Notice, that the values in the first parameter changes.

This is done in the method ScInterpreter::CheckMatrix in the statement
if ( _bLOG )
{
for (SCSIZE nElem = 0; nElem  nCountY; nElem++)
{
const double fVal = pMatY-GetDouble(nElem);
if (fVal = 0.0)
{
PushIllegalArgument();
return false;
}
else
pMatY-PutDouble(log(fVal), nElem);    here
} // for (nElem = 0; nElem  nCountY; nElem++)
} // if ( _bRKP )

Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] Trouble with ScInterpreter::MFastMult

2010-08-12 Thread Regina Henschel

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

2010-08-12 Thread Regina Henschel

Hi Jari,

this is the wrong list for your questions. Macros belong to the udk or 
the api project and images belong to the graphics project.


Kind regards
Regina

Jari Kosonen schrieb:

Can you advice how to change the pivot point in the calc -macro?

oLinked.RotateAngle=rot
oLinked.Position=aPos
oLinked.Pivot=aPos ?? Does not work, since I don't know the internal
structure's name...
oLinked.Size=aSize
oLinked.Name=sDie
oDrawPage.add(oLinked)
--
Jari




-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Changing values in matrix which is parameter

2010-08-12 Thread Regina Henschel

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

2010-08-11 Thread Regina Henschel

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

2010-08-09 Thread Regina Henschel

Hi David,

David Tardon schrieb:

On Mon, Aug 09, 2010 at 10:20:11AM +0200, Daniel Rentz wrote:

Hi Regina,

Am 08.08.2010 19:12, schrieb Regina Henschel:


I have build DEV300m84 on WinXP. That works so far, but saving a
spreadsheet document from Calc gives always the Debug Output:

Error: wrong NameAccess
 From File C:/DEV300m84my/xmloff/source/core/SettingsExportHelper.cxx at
Line 406

If I ignore it, the file is saved, but OOo does not react on mouse or
key. I have to kill it with task manager.

Is this a special problem of my build? Is there something to avoid the
problem? It is very annoying when testing my changes.


I'll have a look.



Hi,

see http://qa.openoffice.org/issues/show_bug.cgi?id=113737 for the
assertion.



I have applied the patch. Now I get no longer a Debug Output, but OOo 
still hangs after saving.


Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] DEV300m84 hangs when saving from Calc

2010-08-08 Thread Regina Henschel

Hi all,

I have build DEV300m84 on WinXP. That works so far, but saving a 
spreadsheet document from Calc gives always the Debug Output:


Error: wrong NameAccess
From File C:/DEV300m84my/xmloff/source/core/SettingsExportHelper.cxx at 
Line 406


If I ignore it, the file is saved, but OOo does not react on mouse or 
key. I have to kill it with task manager.


Is this a special problem of my build? Is there something to avoid the 
problem? It is very annoying when testing my changes.


Kind regards
Regina



-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] Changing values in matrix which is parameter

2010-08-08 Thread Regina Henschel

Hi all,

in method LINEST I get pMatX from the stack. That is a reference to the 
matrix MatX. I calculate the means column wise getting a matrix MeanX 
with associated reference pMeanX. In next step I calculate

pMatX-GetDouble(i,j) - pMeanX-GetDouble(i,0)

Can I overwrite the values in matrix MatX with this results? Or must the 
values of the matrix MatX remain unchanged by the method LINEST?


Does there exist a guide for handling of matrices in the interpreter?

Kind regards
Regina







-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Missing parameter in LINEST

2010-08-05 Thread Regina Henschel

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

2010-08-03 Thread Regina Henschel

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

2010-07-21 Thread Regina Henschel

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

2010-07-19 Thread Regina Henschel

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

2010-06-16 Thread Regina Henschel

Hi Eike,
Eike Rathke schrieb:

Hi Regina,



That's odd. I'd have to take a deeper look at that. I expected that with

{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot, 
IMCOT },

the last IMCOT would had setup the map for FormulaGrammar::GRAM_PODF to
be used in 'oooc:' namespace import, see ScCompiler::fillFromAddInMap().

Using FindFunction() may be a workaround, but I'd rather find the real
cause and a different solution without looking through all AddIns.


I have tested it once again. And you are right, using
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot, 
IMCOT }


works indeed. It was my fault, nothing to do for you. I'll will change 
the file in this way.


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] character set is not UTF-8 in analysis_deffuncnames.src

2010-06-16 Thread Regina Henschel

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

2010-06-16 Thread Regina Henschel

Hi Eike,

Regina Henschel schrieb:

Hi Eike,
Eike Rathke schrieb:

Hi Regina,



That's odd. I'd have to take a deeper look at that. I expected that with

{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot, IMCOT },

the last IMCOT would had setup the map for FormulaGrammar::GRAM_PODF to
be used in 'oooc:' namespace import, see ScCompiler::fillFromAddInMap().

Using FindFunction() may be a workaround, but I'd rather find the real
cause and a different solution without looking through all AddIns.


I have tested it once again. And you are right, using
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
IMCOT }

works indeed. It was my fault, nothing to do for you. I'll will change
the file in this way.


The round trip ODF1.2 - OOo2.4.3 - ODF1.2 for sxc file format is OK 
with that setting, but now sxc files fail both for reopen and for round 
trip through OOo2.4.3 if load/save setting is ODF1.0 with an entry of 
kind =com.sun.star.addin.analysis.getimcot :(


I have attached a summary of my tests and the current version of my work 
(based on DEV300m78) to issue 111609. Perhaps you can find the cause of 
the Addin troubles.


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx

2010-06-09 Thread Regina Henschel

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

2010-06-04 Thread Regina Henschel

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

2010-06-04 Thread Regina Henschel

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

2010-06-03 Thread Regina Henschel

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

2010-06-03 Thread Regina Henschel

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

2010-06-01 Thread Regina Henschel

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

2010-05-31 Thread Regina Henschel

Hallo Daniel,

Daniel Rentz schrieb:

Hello,

Regina Henschel schrieb:


== A ==

I have added SEC, CSC, SECH, and CSCH, to saFuncTable_Odf. All four
new functions have op-codes. Tests look good:

Reloading directly is correct for ods, xls, sdc, and sxc.
Loading and resaving with StarOffice8 (for ods, sdc, and sxc) and
Excel2010 (for xls) and then loading in my build is correct too.


Good! Did you add them to the sc and oox modules?


I have added them only to saFuncTable_Odf in sc/.../xlformula.cxx. They 
get the prefix _xlfnodf., I see it in the xls file.






== B ==

But I have still questions concerning the new imaginary functions.
Those functions have no op-code. Need I to add them to
saFuncTable_Odf? If yes, how can I do it?


Yes, the filters in sc are used for import/export of the XLS format. On
export, the current behaviour is:
If the function is an add-in function, the XCompatibilityNames interface
is used to retrieve its name used in the XLS file format (see in file
sc/source/filter/excel/xeformula.cxx, in function
XclExpFmlaCompImpl::AppendAddInCallToken(), call to GetExcelName()). So
I would suggest that this interface returns the _xlfnodf.XYZ function
names, to not get any name clashes with existing functions in Excel. The
import filter will try to convert these function names back to add-in
functions, again with the mentioned interface. But I do not know if this
will work out of the box. In file sc/source/filter/excel/xiroot.cxx,
there is a function XclImpRoot::GetScAddInName() that calls
GetCalcName() if you want to debug it.


I have added the imaginary functions to saFuncTable_Odf with opcode 
ocNoName now. The prefix _xlfnodf. is not set. It does not work out 
of the box. You do not notice the missing prefix in the test results, 
when testing the round trip mybuild - Excel - mybuild. There the cell 
entries are OK. But you see it in the round trip in xls format mybuild 
- OOo243 - mybuild, which results in #MACRO?, and if you look into the 
xls file with an editor.



 if you want to debug it


There is no hurry to implement the new functions. So I will try to make 
it correct and learn a little bit about the filters.


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] Decision about Bessel-functions needed

2010-05-20 Thread Regina Henschel

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

2010-05-17 Thread Regina Henschel

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

2010-05-16 Thread Regina Henschel

Hi Daniel,

Daniel Rentz schrieb:

Hi regina,

Regina Henschel schrieb:


the file oox/source/xls/formulabase.cxx has a section /** Functions
defined by OpenFormula, but not supported by Calc or by Excel. */

Does this refer to the draft ODF 1.2 formula spec?


No. I just scanned the function op-codes defined by sc (nowadays
formula/inc/formula/opcode.hxx).


Which functions are listed there? For example, why are the imaginary
functions and the secant functions not listed there?


This list in oox is not used anywhere.


So I need not worry about that file?

 I added it to have the entries

available for copypaste once Calc and Excel will support the
functions... Which functions are we talking about exactly?


I'm working on SEC, CSC, SECH and CSCH (issue 111413) and on IMCOSH, 
IMCOT, IMCSC, IMCSCH, IMSEC, IMSECH, IMSINH, IMTAN (issue 111609). The 
code is nearly ready, but for filters. For filters I would need some 
advise, what to change and add. SEC, CSC, SECH and CSCH are normal 
functions in the Math-group and the IMxxx-functions belong to 
scadddins/analysis.


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx

2010-05-16 Thread Regina Henschel

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

2010-05-16 Thread Regina Henschel

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

2010-05-16 Thread Regina Henschel

Hi Daniel,

Daniel Rentz schrieb:



Same for the equivalent table saFuncTable_Odf in
sc/source/filter/excel/xlformula.cxx.


It seems, that I have to wait till m78, because m76 does not contain 
saFuncTable_Odf and m77 does not build for me.


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] constraint of x in sin(x) in scaddins

2010-05-15 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Saturday, 2010-05-08 21:02:45 +0200, Regina Henschel wrote:


I have notice a constraint SinOverflow (which is x=134217728) in
analysishelper.cxx in scaddins. What is the special reason for it?


Having tried I confirm that Excel has that constraint, or more specific
x134217728. I don't know adhoc why it is 2^27 though.


In other places with sin() the version ::rt::math::sin() is used to get
a guard for overflow. That would result in constraint
x=9,22337203685478E+018, which is much larger.


See comment in sal/inc/rtl/math.hxx for isValidArcArg(). We rely on the
trigonometric functions being implemented such that radians up to 2^64
(=1.844e19) are supported. Re-thinking that, also per the comments
Leonarda gave, we should lower the limit to a value representable in
a double's (binary64) mantissa of 53 bits. For consistency with the
approx functions I suggest a constraint x=2^48


I have scanned that area a little bit, using some integral numbers. The 
accuracy is about 7-8 digits for x near to 2^48. For larger values, the 
accuracy decreases dramatically to 0-1 digit. The accuracy for integral 
numbers is 14-15 digits till 2^27.


But for non-integral numbers the situation is not so good. The function 
sin() reacts very sensitive on rounding errors. Although the arguments 
only differ in that digit, which is not displayed, the result might be 
very different. This error is greater for large values and values near 
multiples of PI. Some examples:

near 2^48, near multiple of PI
sin(281474976710656 + 0.1) = 2.52110962285532E-001
sin(281474976710656 + 0.4) = 4.83685841828820E-001
near 2^26
sin(109951164.00440 + 0,01) = 9.9998707539E-001
sin(109951164.00440 + 0,04) = 9.9998550774E-001
near 2^36
sin(109951164005.920 + 0.0001) = 9,9640813644E-001
sin(109951164005.920 + 0.0004) = 9.9844512272E-001
near 2^45
sin(49951164005923.8 + 0.01) = -9.94815019880560E-001
sin(49951164005923.8 + 0.04) = -9.97506946246269E-001



About the IEEE 754 specification mentioned there: Unfortunately I can't
find that 2^64 requirement, apparently the standard itself does not say
so, just checked. Maybe it did in an older public draft, as
a recommendation. Apparently C math libraries implement it such.


If there is no special reason, should I replace it, while I work on the
missing complex trigonometric functions?


Note that this SinOverflow() of the Analysis Add-In is used with IMSIN()
and IMCOS() only. However, in Excel also the SIN(), COS() and TAN()
functions are affected by the x134217728 constraint, which we handle
using the ::rtl::math approach.

I think we can safely replace SinOverflow() with
::rtl::math::isValidArcArg() if we chose a better limit for that.


I have written all imaginary functions now in a way that 
::rtl::math::isValidArcArg() is used. Doing that the imaginary functions 
will give the same result as the normal real functions, when called with 
a real argument.


Concerning the limit in ::rtl::math::isValidArcArg() I'm not sure, what 
is the right way. Gnumeric does not limit the argument of sine and 
results wrong values.


I too tend to use 2^48 as limit. Beyond that limit the result are 
unusable. But in addition the descriptions in the Wiki should mention, 
that the accuracy will only be good (= 9 to 15 digits) if the argument 
is smaller than 2^27.


kind regards
Regina


-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] HelpID for imaginary trigonometric functions

2010-05-15 Thread Regina Henschel

Hi,

next question with my imaginary functions task: I have found helpid 
definitions for imaginary functions in sc/inc/sc.hrc. Shall I add 
definitions for the new imaginary functions there? And then in 
sc/source/core/tool/addinhelpid.cxx and sc/util/hidother.src too?


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] Questions about oox/source/xls/formulabase.cxx

2010-05-15 Thread Regina Henschel

Hi,

the file  oox/source/xls/formulabase.cxx has a section /** Functions 
defined by OpenFormula, but not supported by Calc or by Excel. */


Does this refer to the draft ODF 1.2 formula spec?
Which functions are listed there? For example, why are the imaginary 
functions and the secant functions not listed there?


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] constraint of x in sin(x) in scaddins

2010-05-10 Thread Regina Henschel

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

2010-05-09 Thread Regina Henschel

Hi Leonard,

it seems, that I have not been clear enough. sin() is a function in the 
math library of C and C++ compilers and is nowadays accurate in double 
precision up to x2^64. To prevent larger arguments the special 
implementation ::rtl::math::sin() is used in OOo. But inside the 
implementation of IMSIN() in the module scaddins a constraint 
x134217728 is used. I only want to know, why this has been 
introduced. I doubt, that this restriction is still necessary.


I know, that a lot of binary values give different results for sin(), 
although they are shown with the same decimal values in 15 digit 
precision (the highest precision Calc UI has). But that is not central 
point of my question.


kind regards
Regina


Leonard Mada schrieb:

Dear Regina,

I believe that sin() should have as constraint the largest float
(or integer) that fulfills the following condition:
sin(max) = correct result + epsilon
sin(max + lambda) = correct result + epsilon ,
where lambda is a float in the interval (0, pi/2).

Let me explain this a little bit.

sin: [any float] -  [-1, 1]

sin(pi/2) = 1
sin(pi/2 + pi/2) = 0

So basically, if we want to compute sin() at some precision,
we have to guarantee that the number we compute the sinus of,
can be accurately represented. Else, we risk a total fiasco, because
sin(a_very_big_number) may correspond to any value in [-1, +1],
as the last digits in a_very_big_number are not accurate.

So, big_number +/- pi/2 may be represented as big_number,
although the sinus would have different signs for those
theoretically different numbers.

Therefore, the number which still makes sense to compute the sinus off,
should fulfill the requirements set above.

We still need to determine what values lambda and epsilon take,
but I hope that the general idea is clear.

Basically, this also depends on the implementation of general numbers
in the particular software (Calc in this example).

Some may store 16 decimal digits, so 1.xxx * 10^16 is still ok
to compute the sin() (or marginally so), some may store 32 digits,
so 1.xxx * 10^32 would be fine in that case.

I believe that lambda should be not bigger than pi/4,
while epsilon is flexible in this case (e.g. 10^-6 is probably
sufficient).

Sincerely,

Leonard Mada



 Original-Nachricht 

Datum: Sat, 08 May 2010 21:02:45 +0200
Von: Regina Henschelrb.hensc...@t-online.de
An: Calc devdev@sc.openoffice.org
Betreff: [sc-dev] constraint of x in sin(x) in scaddins



Hi all,

I have notice a constraint SinOverflow (which is x=134217728) in
analysishelper.cxx in scaddins. What is the special reason for it?

In other places with sin() the version ::rt::math::sin() is used to get
a guard for overflow. That would result in constraint
x=9,22337203685478E+018, which is much larger.

If there is no special reason, should I replace it, while I work on the
missing complex trigonometric functions?

kind regards
Regina


-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org





-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] constraint of x in sin(x) in scaddins

2010-05-08 Thread Regina Henschel

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

2010-04-06 Thread Regina Henschel

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

2010-04-02 Thread Regina Henschel

Hi all,

Excel 2010 has some significant changes for statistical functions, see 
[1][2]. Are there any plans to adapt the import filter and to implement 
further functions? Has work on this already started?


kind regards
Regina


[1] http://blogs.msdn.com/excel/attachment/9905140.ashx
or search for Function Improvements in Microsoft Office Excel 2010

[2] 
http://office2010.microsoft.com/en-us/excel-help/what-s-new-changes-made-to-excel-functions-HA010355760.aspx?CTT=1
or search for What's New: Changes made to Excel functions inside 
http://office2010.microsoft.com


-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] What are valid arguments for INDIRECT

2009-09-21 Thread Regina Henschel

Hi Niklas,

Niklas Nebel schrieb:

On 09/19/09 22:15, Regina Henschel wrote:
the submitter of issue 105182 closed the issue, because he find a way 
to solve his problem. But for me the situation is not clear.


=ISREF(D1:D3!C2:E2) returns TRUE
but
=ISREF(INDIRECT(D1:D3!C2:E2)) returns FALSE

=ISREF(A1~B1) returns TRUE
but
=ISREF(INDIRECT(A1~B1)) returns FALSE

And INDIRECT((A1:C3):(B2:D4)) fails too.

Are expressions as text not allowed for INDIRECT or are they allowed 
but not implemented yet?


INDIRECT is supposed to parse a reference, not any more complex expression.


So what is a 'reference'? For ISREF the help say, Tests if the argument 
is a reference. Returns TRUE if the argument is a reference, returns 
FALSE otherwise. Taking that, D1:D3!C2:E2 is a 'reference'.


I know that INDIRECT cannot work with this sort of 'reference' up to 
know. My question is, whether this is because of definition in ODF or 
not. If the definition allows it, then we can enhance INDIRECT (if we want).




And what about all type of names? INDIRECT(name) will fail. I know, 
that is mentioned in the help. But must it fail?


The help is outdated here. Support for named ranges was added some time 
ago (issue 4695).


Indeed, that works now. :)

kind regards
Regina



-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Re: [Issue 90759] ZTEST not same as Excel

2009-08-26 Thread Regina Henschel

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

2009-08-25 Thread Regina Henschel

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

2009-08-14 Thread Regina Henschel

Hi Eike, hi Daniel,

Eike Rathke schrieb:

Hi Daniel, Regina,

On Wednesday, 2009-08-12 10:15:43 +0200, Daniel Rentz wrote:


Regina Henschel schrieb:

== Import ==

Importing an Excel-file with =CEILING(-3.4;) for example gives the  
cellcontent =CEILING(-3.4;;1), because in the current import filter the 
third parameter 1 is added to get Excels rounding away from zero  
behavior. This will be a valid formula in ODF1.2 and calculated as  
CEILING(-3.4;-1;1)= -4. But the formula =CEILING(-3.4;) gives the 
result 0 in Excel. Therefore I think, that it would be better, to 
import the formula as =CEILING(-3.4;0;1) which gives 0 in OOo too 
according to spec ODF1.2.


So, actually CEILING(x,) in Excel always returns 0 for any x.


Yes, at least in my Excel2007.



The other problematic import case is Excels formula =CEILING(;value). 
In this case it becomes =CEILING(;value;1), which is an invalid formula 
in ODF1.2. Here too the result in Excel is 0, and an import as  
=CEILING(0;value;1) would give the same result as in Excel.


Why Excel even allows such crap is beyond my scope..


I guess, it is a bug in Excel.

[..]


I first thought I could withdraw the new proposal I made for ODFF,


Please do not withdraw it. If CEILING will be defined with three 
parameters, it is meaningful to allow CEILING(x;;y). It makes it easy to 
drag-copy in the case the user wants a rounding to integer. Otherwise he 
needs something like CEILING(x;if(x=0;1;-1);y), because the first and 
second parameter must have the same sign. Or the spec is changed in a 
way, that the second parameter is always not negative and the sign is 
set automatically according to the first parameter.




but there may be documents in the wild that have the missing parameter
written. These currently calculate 0 for any CEILING(x;;y), but will
have to calculate according to the spec then, which is to use -1 or +1
for the missing parameter. It was an error in OOo to allow the missing
parameter and interpret it as 0 in first place, just to be Excel
compatible..


Yes, I too think it as a fault in OOo and I see additional trouble with 
 handling of ods-documents saved with OOo3.0 to OOo3.2.


Is there a way to distinguish, whether a document was saved in a version
with the 'wrong' handling? I mean for example, if the method with 
missing = +-1 would be used in OOo3.3, can a OOo3.3 detect, that a 
document was saved in OOo3.2, which uses the old method with missing = 0?





== Export ==

When the formula in OOo is =CEILING(3.4;;Mode) it is exported to  
=CEILING(3.4;) which results in 0 in Excel. But in OOo the formula  
results in 4.


Currently it does not. It should.. but it does this Excel compatibility
stuff.


Yes. I described the problems we get, when we implement CEILING
according to spec.



If the formula is exported as =CEILING(3.4;1) it would  
give the correct result in EXCEL.

But for =CEILING(-3.4;;0) in OOo, which results in -3,


Also here, it should, but currently doesn't..

the current  
export is =CEILING(-3.4;) which result in 0 in Excel which is wrong, 
but the export to =CEILING(-3.4;1) gives an invalid formula and  
=CEILING(-3.4;-1) would result in -4 in Excel, which is wrong too.


Basically we can't export any function with Mode=0 (or omitted) to Excel
where FLOOR(-x) or CEILING(-x) are rounded mathematically, because Excel
has them wrong. IMHO, the best would be to write an NA() as second
parameter in these cases, so the result in Excel will be an error
instead of a different value.


Concerning import/export with Excel, another -radical, but clean- 
solution might be to implement CEILING_ADD, and export the regular 
CEILING function to an error value in all cases. It would support an 
Excel - OOo - Excel work flow, especially if the user sets xls as 
default format.


For OOo - Excel the user would be responsible to use Excel
compatible functions. The formulas are better readable than using an if
construct (I read your description below already). Especially, when a
user sets xls as default format, he might wonder, that his expression
changed to an if-construct, when he reopens his document.

But unfortunately this does not solve the change of meaning in
ods-documents.



When the formula in OOo is =CEILING(3.4) it is calculated as  
CEILING(3.4;1;0)=4. An export as =CEILING(3.4;1) would give correct  
values in Excel.
But =CEILING(-3.4) is calculated as CEILING(-3.4;-1;0)=-3 and  
CEILING(-3.4;1) is invalid again and CEILING(-3.4;-1) result in -4 in  
Excel, which is wrong.


I see no way to make a general export, that gives the same value in  
Excel as in OOo by simply setting or dropping parameters. So what to do 
in export?
Hmm, I see. So the second parameter has to be set according to the  
current value of the first. No idea how to fix this easily...


No easy fix. We might track the calculation in the interpreter and store
the replacement parameter at the ocCeil/ocFloor tokens if needed, but
that still wouldn't resolve

Re: [sc-dev] Missing second parameter in CEILING

2009-08-07 Thread Regina Henschel

Hi Daniel,

I do not answer directly, because it seems that I described my concern 
not good enough. Next try:


== Import ==

Importing an Excel-file with =CEILING(-3.4;) for example gives the 
cellcontent =CEILING(-3.4;;1), because in the current import filter the 
third parameter 1 is added to get Excels rounding away from zero 
behavior. This will be a valid formula in ODF1.2 and calculated as 
CEILING(-3.4;-1;1)= -4. But the formula =CEILING(-3.4;) gives the result 
0 in Excel. Therefore I think, that it would be better, to import the 
formula as =CEILING(-3.4;0;1) which gives 0 in OOo too according to spec 
ODF1.2.


The other problematic import case is Excels formula =CEILING(;value). In 
this case it becomes =CEILING(;value;1), which is an invalid formula in 
ODF1.2. Here too the result in Excel is 0, and an import as 
=CEILING(0;value;1) would give the same result as in Excel.


This is true for the Excel formats xls, xlsx and xlsb. The import filter 
for xml does not alter the Excel formulas and so the formulas in the 
cells are invalid according to ODF1.2. But it could be solved the same 
way with =CEILING(0;value;1) and =CEILING(value;0;1) respectively.


Change the import filter?

== Export ==

When the formula in OOo is =CEILING(3.4;;Mode) it is exported to 
=CEILING(3.4;) which results in 0 in Excel. But in OOo the formula 
results in 4. If the formula is exported as =CEILING(3.4;1) it would 
give the correct result in EXCEL.
But for =CEILING(-3.4;;0) in OOo, which results in -3, the current 
export is =CEILING(-3.4;) which result in 0 in Excel which is wrong, but 
the export to =CEILING(-3.4;1) gives an invalid formula and 
=CEILING(-3.4;-1) would result in -4 in Excel, which is wrong too.


When the formula in OOo is =CEILING(3.4) it is calculated as 
CEILING(3.4;1;0)=4. An export as =CEILING(3.4;1) would give correct 
values in Excel.
But =CEILING(-3.4) is calculated as CEILING(-3.4;-1;0)=-3 and 
CEILING(-3.4;1) is invalid again and CEILING(-3.4;-1) result in -4 in 
Excel, which is wrong.


I see no way to make a general export, that gives the same value in 
Excel as in OOo by simply setting or dropping parameters. So what to do 
in export?


-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] Missing second parameter in CEILING

2009-08-05 Thread Regina Henschel

Hi,

I'am currently looking at issue 102957 ODFF: FLOOR and CEILING should 
work with a single argument.
Now OOo allows CEILING(N;Significance;Mode) and CEILING(N;Significance). 
 I have made some changes to allow CEILING(N) too. Thereby I noticed 
the following problem:


OOo allows CEILING(N;;Mode) where the second parameter is missing. It 
does this already in version OOo2.4.2 But that is not allowed in spec 
(chapter 6.16.1). Unfortunately I can not do anything in ScCeil, because 
in this case nParamCount is already 3 and it seems that the missing 
parameter is set to 0. Besides the fact, that a missing second parameter 
is not allowed, the default for the second parameter has to be +1 or -1 
depending on the sign of N.


I would expect, that the case CEILING(N;;Mode) raises a Variable 
missing error. But I don't now, where this should happen. Could you 
please point me to that place?


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Missing second parameter in CEILING

2009-08-05 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Wednesday, 2009-08-05 16:06:45 +0200, Regina Henschel wrote:

I'am currently looking at issue 102957 ODFF: FLOOR and CEILING should  
work with a single argument.
Now OOo allows CEILING(N;Significance;Mode) and CEILING(N;Significance).  
 I have made some changes to allow CEILING(N) too. Thereby I noticed the 
following problem:


OOo allows CEILING(N;;Mode) where the second parameter is missing. It  
does this already in version OOo2.4.2


Presumably for Excel interoperability because there the functions have
only 2 parameters, but Excel allows CEILING(value,) and during import we
have to add the 3rd parameter to indicate the mode.


Problems see below.




But that is not allowed in spec (chapter 6.16.1).


We'll have to change the spec for interoperability, I created issue
http://tools.oasis-open.org/issues/browse/OFFICE-2006

Unfortunately I can not do anything in ScCeil, because  
in this case nParamCount is already 3 and it seems that the missing  
parameter is set to 0. Besides the fact, that a missing second parameter  
is not allowed, the default for the second parameter has to be +1 or -1  
depending on the sign of N.


After the 3rd argument was popped from the stack you can check with
IsMissing() whether the 2nd argument is of type svMissing, then pop the
value with GetDouble() as usual, and after having obtained the 1st
argument change the value of the 2nd argument accordingly to +1 or -1 if
it was missing.


Ah, IsMissing() is new to me. I can now set the missing second parameter 
to +1 or -1 depending on N. That works at least for CEILING on which I'm 
currently working.


But Excel Import and Export is confusing.
(1) Import:
In cases CEILING(value;) and CEILING(;value) the result in Excel2007 is 
always 0.

On import of CEILING(value;) OOo does this:
.xlsturn to CEILING(value;;1) and show cell content 0.
.xlsx   turn to CEILING(value;;1) too, but show cell content Err:511
.xmlturn to CEILING(value;) and show cell content Err:511

On import of CEILING(;value) OOo does this:
.xlsturn to CEILING(;value;1) and show cell content 0.
.xlsx   turn to CEILING(;value;1) too, but show cell content Err:511
.xmlturn to CEILING(;value) and show cell content Err:511

The errors are shown left as if they are text. The cell content is only 
recalculated, if you edit the cell, but that is another issue.


Because Excel returns 0 in this cases, I think an import to 
CEILING(value;0) and CEILING(0;value) would be a better solution. 
Although I not yet know how to do it.


(2) Export:
Currently OOo drops the third parameter. So the value differs from Excel 
in the cases of (N0 and Mode=0).


When now the second parameter it optional too, how should it be 
exported? Using +1 gives the same result as in OOo for all cases but 
(N0 and Mode=0). So I would prefer that.


Gnumeric goes a total different way. It generates a new expression to 
simulate the behavior with it's two parameter version of CEILING. You 
can see it, when you open an ods-file in Gnumeric. For example 
CEILING(A2;B2;C2) becomes 
=if(0=C2;if(A20;floor(A2;B2);ceiling(A2;B2));ceiling(A2;B2))


What is the desired behavior on import from Excel and export to Excel?

kind regards
Regina









-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Problems with BESSELJ

2009-07-10 Thread Regina Henschel

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

2009-07-09 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Daniel,

On Wednesday, 2009-07-08 18:37:59 +0200, Daniel Rentz wrote:


Anyway, I would volunteer to do these changes. :)


Roll back! ;-)

That would complicate things even further because the addin.Analysis
name is used in API calls, moving implementation to the core would make
it necessary to compensate for in the compiler.

As the Add-In interfaces are not exported, the easiest solution would be
to introduce a new exception, let's say NoConvergenceException, and set
errNoConvergence accordingly in ScUnoAddInCall::ExecuteCallWithArgs().

Regina, do you need help with that?


Yes, I need a lot of help with that.

(1) How do I introduce a new exception?


(2) I have tried the following too. Instead of my provisional
return 888.88;
I write
throw ::com::sun::star::uno::RuntimeException();
Now the spreadsheet shows
#VALUE!
in cell and
Error: Wrong data type
in status bar in that cases.

But it shows this, whatever I write in 
ScUnoAddInCall::ExecuteCallWithArgs(). I have tried it there with


catch(uno::RuntimeException)
{
  nErrCode = errNoConvergence;
}

and (only for testing) with

catch(uno::Exception)
{
//nErrCode = errNoValue;
nErrCode = errDivisionByZero;
}

Where comes the #VALUE! from?

(3) I have tried to use the Message of the exception. But there I fail 
already in the syntax.


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Problems with BESSELJ

2009-07-09 Thread Regina Henschel

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

2009-07-09 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Thursday, 2009-07-09 12:17:43 +0200, Regina Henschel wrote:


(1) How do I introduce a new exception?


The attached (hopefully not stripped by the mailing list software) patch
adds the ::com::sun::star::sheet::NoConvergenceException to the offapi
module. After having applied the patch, build and deliver the offapi
module, then build and deliver the offuh module that creates the C++
header files.


I could not apply the patch with TortoiseSVN automatically. I hope I got 
it right, when applying it manually.


I've done all the changes. But I get a build error. Just to be sure, I 
start then a build --all, but get the same error:


c:\softwarearchiv2\odff06\scaddins\source\analysis\analysis.hxx(149) : 
error C2039: 'NoConvergenceException' : is not a member of 
'com::sun::star::sheet'


and

c:\softwarearchiv2\odff06\scaddins\source\analysis\bessel.hxx(35) : 
fatal error C1083: Cannot open include file: 
'com/sun/star/sheet/NoConvergenceException.hpp': No such file or directory


I see the file NoConvergenceException.hpp in 
C:\SoftwareArchiv2\odff06\solver\300\wntmsci12.pro\inc\offuh\com\sun\star\sheet

and in
C:\SoftwareArchiv2\odff06\offuh\wntmsci12.pro\inc\offuh\com\sun\star\sheet

What goes wrong here?

kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] OOo2.4.2 takes of:=FDIST(a,b,c) as if it is ooc:=FDIST(a,b,c)

2009-07-04 Thread Regina Henschel

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

2009-07-04 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Tuesday, 2009-06-30 23:34:27 +0200, Regina Henschel wrote:



What is large and what is long lasting?
I would have to implement it in C++ to see how long it really lasts. The  
Basic macro lasts several seconds for x1. The effort is linear in x.


Basic of course is some orders of magnitude slower than C++.


I have attached a draft patch to issue 40309. You can use it to test the 
performance. On my PC a single calculation with x=500 lasts about 1 
second.


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Problems with BESSELJ

2009-06-30 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Sunday, 2009-06-28 20:20:17 +0200, Regina Henschel wrote:

Searching around I come across an iterative solution from Peter  
Deuflhard [1] (German). My tests as Basic macro results in an accuracy  
of at least 12 digits. But it needs approximately order+x*1.1+30 
iterations.

[1] http://www.mathematik.uni-dortmund.de/ieem/BzMU/BzMU2007/Deuflhard.pdf

So the question is, how much iterations are acceptable?


Depends of course on the cost per iteration. Hard to say. How much time
is a user willing to wait for an accurate result? Which still doesn't
say anything about a series of values to be calculated. But, since
a non-accurate solution wouldn't help much, I guess having to wait
a little isn't too much.. so I just throw a number and say 1. Does
that help anything?


With 1 iterations you get convergence for x6000 - might be x1 
- depending on order N. When I calculate the asymptotic formula with 
MuPad in high precision, then I get only 2 to 3 (estimated in the mean) 
accurate digits even for x200*N^2. From point of accuracy this 
asymptotic formula is unusable.




For example BESSELJ(3000;200) results in -7,79235815417491E-003 with the  
current implementation with asymptotic formula, but the true value is  
-1.186524260848996e-2. Gnumeric results -1.186524260848841E-002, my  
Basic version of Deuflhard's algorithm results -1,18652426084901E-002.  
But calculating this needs 3147 iterations. For order 200 you would need  
x52 to result in at least 1 digit accuracy with the asymptotic 
formula.


Second problem: The current implementation restricts the order to  
integer values. In mathematic the order need not to be integer. ODF1.2  
also allows non-integer order. Are there plans to implement a solution  
in OOo with non-integer orders? I personally have no idea how to do it.


No plans. Is there any practical benefit in calculating non-integer
orders?


I don't know. The Bessel-functions are used in technical tasks. I also 
don't know, which ranges are really necessary for x and for order N.


 Does any spreadsheet application do it?
Excel rounds down to integer. The comment in ODF spec 16.15.11 says that 
Gnumeric allow fractional N, but my Gnumeric 1.6.3 rounds down too. In 
the comment Kspread is said to allow fractional N, but I haven't got 
that program.





So the question is, shall I implement Deuflhard's algorithm nevertheless?

Perhaps warn the user in the help, that large input values results in  
long lasting calculations?


What is large and what is long lasting?


I would have to implement it in C++ to see how long it really lasts. The 
Basic macro lasts several seconds for x1. The effort is linear in x.




Or return an error, if neither asymptotic  
formula results at least 2 digits (How tell the user, that the result is  
not accurate?)


A few functions set errNoConvergence if a function can't determine
a result.


That would be better than returning a result, which has no correct 
digit, as the current solution does.




nor Deuflhard's algorithm calculates in reasonable time  
(where to cut?)?


reasonable time depends on user perspective and intention. I don't
think there is a general reasonable timeout.


So I would prefer to implement an iterative solution and drop the 
inaccurate asymptotic part. The algorithm should converge, but I 
hesitate to use a while-loop without any cut. I need to test, for which 
x I can get a result in 1 second. Of cause the help should warn the user 
about high x-values. The asymptotic formula can be mentioned in the help 
in Wiki. It is not long and the user can write it directly as 
spreadsheet formula, if he needs huge x-values. That way he is aware of 
the accuracy problem.




Btw, newer g++ compilers (= 4.3) have some bessel functions built-in,
as part of the TR1 extensions, see
http://en.wikipedia.org/wiki/C%2B%2B_Technical_Report_1, it appears that
MSVC does not have them though.


The MSVC Express edition has not any of that functions.

 Also the Boost library provides bessel

functions, I don't know off-hand which library version introduced them
and if it is in the one OOo uses. Maybe time to finally upgrade ;-)


You are right to remember me to Boost, I have overlooked it. I had a 
look at Boost now. The Bessel functions (and a lot of others) are 
included in library Math Toolkit since version 1.35.0. I see version 
1.34.0 in OOo. There is a description in 
http://www.boost.org/doc/libs/1_35_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/bessel/bessel.html. 



Having an actual version of the Boost library would solve a lot of other 
accuracy problems too. I would prefer upgrading Boost library. When can 
the upgrade be done? Using it then would mean to rewrite most of 
interpr3, interpr6 and analysis part of scaddin, which might take a 
while. I guess rewrite can be done step by step. In the long run we need 
no longer to struggle with accuracy of special functions

Re: [sc-dev] Build problems

2009-06-23 Thread Regina Henschel

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?

2009-06-22 Thread Regina Henschel

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?

2009-06-22 Thread Regina Henschel

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?

2009-06-22 Thread Regina Henschel

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



[sc-dev] How should MULTIPLE.OPERATIONS calculate?

2009-06-21 Thread Regina Henschel

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
result of A5

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
result of A3
700
result of A5

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
result of A5

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
result of A3
700
result of A5

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] How should MULTIPLE.OPERATIONS calculate?

2009-06-21 Thread Regina Henschel

Hi all,

Regina Henschel schrieb:

Hi all,

thinking about issue 102980 and 102981 I found, that it is not clear to 
me, how to calculate MULTIPLE.OPERATIONS at all.


Take a spreadsheet and enter the following numbers and formulas into 
column A, beginning in cell A1 with number 2.


2
3
=A1+A2
30
=MULTIPLE.OPERATIONS(A3;A2;A4)
700
=MULTIPLE.OPERATIONS(A5;A2;A6)



I forgot to say, that the above mentioned values for A3 and A5 are only 
internal, temporary. The real sheet shows in A3 the value 5 and in A5 
the  value 32. There is no doubt about it. Only the value in A7 is in 
question.


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Build problems (was: Rebasing CWS odff06 to m50)

2009-06-20 Thread Regina Henschel

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.

2009-06-01 Thread Regina Henschel
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.

2009-05-26 Thread Regina Henschel
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.

2009-05-22 Thread Regina Henschel
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

2009-04-26 Thread Regina Henschel

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



[sc-dev] Implementation details of POISSON

2009-04-15 Thread Regina Henschel

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

2009-04-13 Thread Regina Henschel

Hi,

besides the UI-name problem I come across two other questions.

(1)
If the numerator degrees of freedom (r1) is 1, then the density function 
has a pole at x=0. The draft spec does not define the return value in 
that case. For x0 it defines that the return value is 0. For x=0 it 
defines it with a term which has a subterm x^(r1/2-1). And x^(-1/2) is 
not defined for x=0.
I can set the result to 0 or set illegal argument or perhaps set 
infinity. Please decide.


(2)
The algorithm is not stable for large values of the degrees of freedom. 
There are some critical parts in the term, for example BETA(r1/2;r2/2) 
in the denominator which is near 0 then, and x^(r1/2-1) which will 
overflow or underflow. I can of cause alter the way the term is 
calculated, but I found, that there are always critical subterms. The 
problem is, that the calculating as a whole does not abort with an 
error, but returns some values which are wrong. You see that they are 
wrong, if you calculate a series of values, but you do not notice it, 
when you calculate a single value. I notice such problems, when I create 
large tables of example values.


Therefore I would like to restrict the degrees of freedom to be lower 
than 1.0E15, where I do not saw any problems. The current implementation 
(=cumulative right tail) has a restriction of 1.0E10. Excel and 
Gnumeric have restriction to about 1.0E10 too. Are larger values really 
needed in real live? Please decide about a restriction.


kind regards
Regina


-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] Need UI name for new FDIST function

2009-04-07 Thread Regina Henschel

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

2009-04-06 Thread Regina Henschel

Hi all,

I'm working to increase accuracy of ScArcCosHyp(). The function acosh is 
part of C99 but not provided by MSVC. Therefore I have written the 
ersatz in sal\rtl\source\math.cxx


double SAL_CALL rtl_math_acosh( double fX ) SAL_THROW_EXTERN_C()
{
double fZ = fX - 1.0;
if ( fX == 1.0)
return 0.0;
else if (fX  1.1)
return rtl_math_log1p(fZ+sqrt(fZ*fZ+2.0*fZ));
else if ( fX  1.25e7)
return log(fX+sqrt(fX*fX-1.0));
else
return log(2.0*fX);
}

The function acosh is not defined for x1. The function ScArcCosHyp() 
pushes an IllegalArgument and do not call acosh in that cases.


Do I need any kind of error handling in my rtl_math_acosh? The function 
acosh might be called from somewhere else, not only from ScArcCosHyp.


kind regards
Regina


-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Move ERF and ERFC from scaddins to sal

2009-03-25 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Sunday, 2009-03-22 22:31:08 +0100, Regina Henschel wrote:
May I ask you to fix that issue, so that I can update my working copy?  
My changes for NORMDIST and LOGNORMDIST include a fix for the NORMDIST  
part of http://www.openoffice.org/issues/show_bug.cgi?id=69069, which  
depends on ERFC.


Just done, please svn update your cws workspace.



Thanks. I have updated my working copy using TortoiseSVN and hope that 
all is OK. You will tell me, if something is wrong with my next patches. :)


kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] TortoiseSVN and CrLf

2009-03-25 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Wednesday, 2009-03-25 14:22:17 +0100, Regina Henschel wrote:

Thanks. I have updated my working copy using TortoiseSVN and hope that  
all is OK. You will tell me, if something is wrong with my next patches. 
:)


Sure :)  btw, which reminds me that I saw TortoiseSVN added a ^M
carriage return in the status lines (Index, file names, line numbers),
it didn't touch the code lines themself.


I can see the different line ends in a hex editor.

 The GNU patch utility neatly

skipped over that, mumbling something like extraneous CRs ignored or
some such, but inferior tools may not, or on Windows be lead again to
convert all line ends to CrLf, I don't know.

Is there an option in TortoiseSVN to tell it to always produce sane LF
line feeds only?


I have looked around in the settings, but do not see such an option. It 
seems to be possible to set a property to each single file, so that the 
line end it forced to LF when committing the file. It does not cover the 
use case of generating a patch for a folder. That setting is not 
possible for a folder. But I'm not familiar with TortoiseSVN, so I don't 
know whether such setting is possible somewhere.


I can try to convert the line ends with an editor. Shall I attach such 
converted patches to issue 100119, so that you can compare them and test 
if it works?


kind regards
Regina




-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] How to export expanded LOGNORMDIST to Excel

2009-03-18 Thread Regina Henschel

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

2009-03-17 Thread Regina Henschel

Hi Eike, hi Daniel,

I delete the old mail-texts, because it becomes to long and confusing.

There are still problems.

First the Excel part:

Exporting to xls is OK now. I get #NV for four parameters and for 
parameter count 3 the missing parameters are added.


But export to Microsoft Excel 2003 XML (.xml) is problematic.
If OOo is set to save in odf1.2, the file opens with errors in Excel. 
All formulae are stripped. The error log says for example

GRUND: Ungültiger Wert
WERT:   of:=LOGNORMDIST(0.6;[.B12];[.B11])
I think, there should not be this kind of WERT, because that form was 
unkown 2003.


If OOo is set to save in odf1.1, the cases with parameter count = 3 
are opened with formulas, only the cases with parameter count=4 give an 
error and the formulas are stripped. The error log says for example

GRUND: Ungültiger Wert
WERT:   =LOGNORMDIST(0.6,R[-1]C,R[-2]C,R[-3]C)
I think that is the correct behaviour.

Now the OOo-part:

I have added in FormulaMissingContext::AddMoreArgs() the lines
code
case ocLogNormDist:
if (mnCurArg == 0)
{
pNewArr-AddOpCode (ocSep );
pNewArr-AddDouble( 0.0 );  // 2nd, mean = 0.0
}
if (mnCurArg == 1)
{
pNewArr-AddOpCode (ocSep );
pNewArr-AddDouble( 1.0 );  // 3rd, standard 
deviatioen = 1.0

}
break;
/code

If OOo is set to save to odf1.2, then I get the transformation
=LOGNORMDIST(0,6;3) -- =LOGNORMDIST(0,6;3;1)
That is undesirable. It is contrary to the new feature, that the 
parameter is optional.

And I get the transformation
=LOGNORMDIST(0,6) -- =LOGNORMDIST(0,6;0)
It shouldn't be transformed at all (see above). But when it is 
transformed, why is the third parameter missing? It is not missing, when 
using odf1.1, see below.


If OOo is set to save to odf1.1, then I get the transformations
=LOGNORMDIST(0,6;3) -- =LOGNORMDIST(0,6;3;1)
=LOGNORMDIST(0,6) -- =LOGNORMDIST(0,6;0;1)
I think, those transformations are OK.

It is more complicate than I thought. I hope you are not annoyed, that I 
need to ask so much.


Kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] How to export expanded LOGNORMDIST to Excel

2009-03-17 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Tuesday, 2009-03-17 18:04:12 +0100, Regina Henschel wrote:


But export to Microsoft Excel 2003 XML (.xml) is problematic.
If OOo is set to save in odf1.2, the file opens with errors in Excel.  
All formulae are stripped. The error log says for example

GRUND: Ungültiger Wert
WERT:   of:=LOGNORMDIST(0.6;[.B12];[.B11])
I think, there should not be this kind of WERT, because that form was  
unkown 2003.


That's http://qa.openoffice.org/issues/show_bug.cgi?id=96018


OK, so i don't worry, it is outside my scope.




If OOo is set to save in odf1.1, the cases with parameter count = 3  
are opened with formulas, only the cases with parameter count=4 give an  
error and the formulas are stripped. The error log says for example

GRUND: Ungültiger Wert
WERT:   =LOGNORMDIST(0.6,R[-1]C,R[-2]C,R[-3]C)
I think that is the correct behaviour.


Yes, it is.



Now the OOo-part:

I have added in FormulaMissingContext::AddMoreArgs() the lines
code
case ocLogNormDist:
if (mnCurArg == 0)
{
pNewArr-AddOpCode (ocSep );
pNewArr-AddDouble( 0.0 );  // 2nd, mean = 0.0
}
if (mnCurArg == 1)


That should be  if (mnCurArg = 1)  instead. The AddMoreArgs() method is
called once for each function, both arguments have to be added if only
one was present.


I found it in the meantime too. Using a switch as Daniel has shown me 
for Excel export works as well.





{
pNewArr-AddOpCode (ocSep );
pNewArr-AddDouble( 1.0 );  // 3rd, standard  
deviatioen = 1.0

}
break;
/code

If OOo is set to save to odf1.2, then I get the transformation
=LOGNORMDIST(0,6;3) -- =LOGNORMDIST(0,6;3;1)
That is undesirable. It is contrary to the new feature, that the  
parameter is optional.


We want to add the parameters in any case because otherwise OOo3.0/3.1
wouldn't be able to interpret the formula, as they expect 3 parameters.
This is perfectly well. While 3.2 will be able to read without arguments
for the optional parameters, it will write something that can be read by
any 3.x release.


OK, a kind of 'political' decision. I'll implement it that way.




And I get the transformation
=LOGNORMDIST(0,6) -- =LOGNORMDIST(0,6;0)
It shouldn't be transformed at all (see above). But when it is  
transformed, why is the third parameter missing?


See above, mnCurArg==0 in this case.

It is not missing, when  
using odf1.1, see below.


If OOo is set to save to odf1.1, then I get the transformations
=LOGNORMDIST(0,6;3) -- =LOGNORMDIST(0,6;3;1)
=LOGNORMDIST(0,6) -- =LOGNORMDIST(0,6;0;1)
I think, those transformations are OK.


Huh? That would be strange for the second case. Are you sure it was
produced using the code you posted above? Seems more you fixed already
what I lined out ;-)


You are right, it works now as it should.

No more questions for now, I'll continue my tests. Thanks for your help.

kind regards
Regina


-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] How to export expanded LOGNORMDIST to Excel

2009-03-13 Thread Regina Henschel

Hi Daniel,

Daniel Rentz schrieb:

Regina Henschel schrieb:

Hi,

I'm expanding LOGNORMDIST to the form it has in ODF spec. There it is
LOGNORMDIST( Number x [ ; Number m = 0 [ ; Number s = 1 [ ; Logical 
Cumulative = TRUE() ] ] ] )


Inside OOo it is no problem. But how to export it to Excel? Excel has 
3 Parameters, no one optional.


For expanding NORMDIST I had only to set the last parameter to optional.
I found in xeformula.cxx how to add the last parameter, if missing. I 
have used

case ocNormDist:
if( nParamCount == 3 )
{
// NORMDIST function needs 4 parameters in Excel
PrepareParam( rFuncData );
AppendBoolToken( true );
FinishParam( rFuncData );
}
break;
and that seems to work.

But for LOGNORMDIST there are different cases, for example

LOGNORMDIST(x;m;s;TRUE()) must become LOGNORMDIST(x;m;s). A parameter 
has to be removed.

LOGNORMDIST(x;m;s;FALSE()) does not exist in Excel.
LOGNORMDIST(x;m;s) Nothing to do, same as in Excel.
LOGNORMDIST(x;m) must become LOGNORMDIST(x;m;1).
LOGNORMDIST(x) must become LOGNORMDIST(x;0;1).


To increase the number of parameters, you can do something similar in 
XclExpFmlaCompImpl::AppendTrailingParam (untested code!):



 case ocLogNormDist:
 // LOGNORMDIST function needs 3 parameters in Excel
 switch( nParamCount )
 {
 case 1:
 PrepareParam( rFuncData );
 AppendIntToken( 0 );
 FinishParam( rFuncData );
 // do not break, add next default parameter
 case 2:
 PrepareParam( rFuncData );
 AppendIntToken( 1 );
 FinishParam( rFuncData );
 break;
 }
 break;




That works. When exporting to xls, I get the correct function structure, 
if there are one, two or three parameters in OOo. If there are four 
parameters in OOo, I get a =#NV entry in German Excel 2007. I think, the 
error message is correct, because the user has to know, that there has 
been something, which is unknown to Excel.


It is a concession that the missing parameters are added, although the 
user who will export to Excel-format should know, that Excel expects 
three parameters. Shouldn't we do the same for saving in old OOo 
formats, especially, when OOo3.0 is set in general to use ODF1.0-format? 
If you agree, that in cases saving to old OOo-formats the missing second 
and third parameters should be added, where is the place to do it?


To delete the 4th parameter, you can change the function info of this 
function. Go to xlformula.cxx and look for ocLogNormDist, change the 
line from


{ ocLogNormDist,290,3,  3,  V, { V }, 0, 0 },

to

{ ocLogNormDist,290,3,  3,  V, { V, V, V, C, I }, 0, 0 },


The C means that the 4th parameter is Calc-only and will be stripped 
on export. The trailing I is needed for some internal resons.


I have done first the changes in formulabase.cxx. That gives no error, 
but I see no effect, so I cannot say if it really works. Then I changed 
xlformula.cxx. That works, now the entry in the xls-file has three 
parameters in all cases.


I have rethought the problem. It seems no good idea to strip the fourth 
parameter. If it is stripped, there are no errors in Excel, but the 
cells might have different values than OOo, because in OOo you calculate 
the density function and in Excel the cumulative function is calculated. 
The user cannot notice, that the values are wrong, because there are no 
warnings. That is not good and we should not do it. There is no way to 
determine whether the forth parameter is true or false, because it might 
be no constant but a reference.


The same problem is, when saving to old OOo-formats. Using four 
parameters should give an error, when opening in old versions.


What do you think?

kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] How to export expanded LOGNORMDIST to Excel

2009-03-11 Thread Regina Henschel

Hi,

I'm expanding LOGNORMDIST to the form it has in ODF spec. There it is
LOGNORMDIST( Number x [ ; Number m = 0 [ ; Number s = 1 [ ; Logical 
Cumulative = TRUE() ] ] ] )


Inside OOo it is no problem. But how to export it to Excel? Excel has 3 
Parameters, no one optional.


For expanding NORMDIST I had only to set the last parameter to optional.
I found in xeformula.cxx how to add the last parameter, if missing. I 
have used

case ocNormDist:
if( nParamCount == 3 )
{
// NORMDIST function needs 4 parameters in Excel
PrepareParam( rFuncData );
AppendBoolToken( true );
FinishParam( rFuncData );
}
break;
and that seems to work.

But for LOGNORMDIST there are different cases, for example

LOGNORMDIST(x;m;s;TRUE()) must become LOGNORMDIST(x;m;s). A parameter 
has to be removed.

LOGNORMDIST(x;m;s;FALSE()) does not exist in Excel.
LOGNORMDIST(x;m;s) Nothing to do, same as in Excel.
LOGNORMDIST(x;m) must become LOGNORMDIST(x;m;1).
LOGNORMDIST(x) must become LOGNORMDIST(x;0;1).

Can you help me?

kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] Decision needed for FISHERINV and ATANH

2008-12-21 Thread Regina Henschel

Hi Eike,

Merry Christmas and a happy New Year to you.

Eike Rathke schrieb:

Hi Regina,

On Wednesday, 2008-12-17 16:22:09 +0100, Regina Henschel wrote:

Mathematically FISHER(x)=atanh(x). But the OOo function ATANH() uses the  
same insufficient algorithm as FISHER. Therefore ATANH() has to be  
changed too. The best solution, using a build-in function, is not  
available: atanh() is a C99 function and therefore not available in MSVC  
compiler. The code itself is rather simple, there are two possible 
methods:

(1) atanh(x)=0.5*log1p(2*x/(1-x))
(2) Use the first five summands of the power series for |x|0.01, which  
would be atanh(x)=x(1+x²*(1/3+x²*(1/5+x²*(1/7+x²*1/9 and use  
atanh(x)=0.5*ln((1+x)/(1-x)) in the other cases.


I trust you that the results would be identical ;-)


In general they are, but to test, which cut value to use and how many 
summands are needed, is tedious. If there will be a reason for to make 
the solution independed of log1p, the algorithm can be changed.


  I think #1

would be best, for simplicity.


I have used (1)

 You could also profile some ten thousand

calls or so with a sample range of values to determine if any of the two
approaches would have significant performance benefits over the other.


I found no difference in performance.



1. Should atanh be implemented to ::rtl::math like it has been done for  
log1p and expm1?


Yes, that would be cleanest. Please file an issue similar to i97091


It is issue 97467. Although I do not really understand the things you 
have done for expm1 and log1p, I have tried to mimic them. Perhaps when 
code freeze is over, you have some time to explain it?


The related changes for ATANH, FISHER and FISHERINV are in issue 97468.

A quick look at ASINH shows, that it has similar deficiencies. But that 
will be a new project.


kind regards
Regina


-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



[sc-dev] Decision needed for FISHERINV and ATANH

2008-12-17 Thread Regina Henschel

Hi,

I have examined FISHER and FISHERINV and thereby struggle about some 
problems.


FISHERINV(x) is not accurate for x very near to zero. For example 
FISHERINV(1E-15)=1.1387379200E-015, but should result in 1E-15. That 
can be easily fixed by calling tanh() instead of the current 
(exp(2x)-1)/(exp(2x)+1).


FISHER has the same problem for x near zero. For example 
FISHER(0.1)=1.002953E-005, but should return 
1.00E-005. The fix is easy but needs some decisions.


Mathematically FISHER(x)=atanh(x). But the OOo function ATANH() uses the 
same insufficient algorithm as FISHER. Therefore ATANH() has to be 
changed too. The best solution, using a build-in function, is not 
available: atanh() is a C99 function and therefore not available in MSVC 
compiler. The code itself is rather simple, there are two possible methods:

(1) atanh(x)=0.5*log1p(2*x/(1-x))
(2) Use the first five summands of the power series for |x|0.01, which 
would be atanh(x)=x(1+x²*(1/3+x²*(1/5+x²*(1/7+x²*1/9 and use 
atanh(x)=0.5*ln((1+x)/(1-x)) in the other cases.


Two decisions are needed
1. Should atanh be implemented to ::rtl::math like it has been done for 
log1p and expm1?

2. Which of the two methods should be used.

Please instruct me.

kind regards
Regina

-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org



Re: [sc-dev] How to continue after issue 94555 (CHISQDIST)

2008-12-09 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Tuesday, 2008-12-02 18:34:25 +0100, Regina Henschel wrote:

I have updated the patches in issue 94555. The work in that area is  
finished. Please have a look.


Thanks a lot!



I've hoped that the patch in 94555 (CHISQDIST) will get into odff05 and 
that the feature will be in OOo3.1. Will that happen or is something 
wrong with that patch?


kind regards
Regina

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Implement expm1 and log1p

2008-12-03 Thread Regina Henschel

Hi Eike,

I've attached it in patch form to issue 91602

kind regards
Regina

Eike Rathke schrieb:

Hi Regina,

On Monday, 2008-12-01 16:06:53 +0100, Regina Henschel wrote:

I've got a build of odff05 now and want to continue work. I need expm1  
and log1p (issue 91602). I can put the following code into
sal\inc\rtl\math.hxx, so I can use the functions with ::rtl::math::expm1  
and ::rtl::math::log1p in interpr*.cxx


Yes, that should do. I'll also add the already existing patch of i94555
to CWS odff05 today.

Is it necessary to have a solution, which switches, dependent on the  
compiler? If yes, how can I do it?


I don't think that's necessary. We can always use our own expm1 and
log1p, regardless of whether the compiler provides its own.

  Eike




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] How to continue after issue 94555 (CHISQDIST)

2008-12-03 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi Regina,

On Tuesday, 2008-12-02 18:34:25 +0100, Regina Henschel wrote:

I have updated the patches in issue 94555. The work in that area is  
finished. Please have a look.


Thanks a lot!

I now want to go further on to BETADIST. Should I make the necessary  
changes based on the original odff05 or on the version, which contains  
already the changes from issue 94555?


Please base on the already existing changes, so that it will apply
seamlessly once CWS odff05 is integrated. I have to get that CWS rfQA
until tomorrow evening, feature/UI freeze is approaching.


I have attached the new BETADIST patches to issue 91547. The work in 
that area is finished too. I have added a FIXME in places, where I do 
not know better algorithm. I think, that the patches should be applied 
although the solutions are sometimes less accurate than Gnumeric. But it 
is a large improvement compared to the current values.


If you have any questions concerning my patches, drop me a mail. I'll 
answer as soon as I'm back from school. The patches are based on my 
odff05 version after i94555 and i91602. My wording in i91547 is a little 
bit mistakable.


kind regards
Regina

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] The default parameter of formula LOG() and POISSON().

2008-12-03 Thread Regina Henschel
Hi Yue,

I've added the issues numbers to
http://wiki.services.openoffice.org/wiki/Calc/ODFF_Implementation/Examine_functions

kind regards
Regina

lvyue schrieb:
 Hi Eike,
 
 I also finished the changes to the default parameter
 of formula LOG() and POISSON() in these two days.
 I know that odff05 is going to to be freezed soon,
 do you still need patches of the changes?
 If you want me to submit, where should I put them in?
 shall I create new issues first?
 
 It is another weekend, wish you a happy weekend!
 
 Best regards
Yue
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[sc-dev] Implement expm1 and log1p

2008-12-01 Thread Regina Henschel

Hi,

I've got a build of odff05 now and want to continue work. I need expm1 
and log1p (issue 91602). I can put the following code into
sal\inc\rtl\math.hxx, so I can use the functions with ::rtl::math::expm1 
and ::rtl::math::log1p in interpr*.cxx


Is it necessary to have a solution, which switches, dependent on the 
compiler? If yes, how can I do it?


kind regards
Regina


/** The MSVC compilers do not provide expm1 and log1p. The following 
functions are an ersatz for them.

*/

inline double expm1(double x)
{
double u = exp(x);
if (u == 1.0)
return x;
if (u-1. == -1.0)
return -1.0;
return (u-1.0)*x/log(u);
}

inline double log1p(double fX)
{
double fU = 1.0+fX;
if (fU == 1.0)
return fX;
else
return log(fU)*fX/(fU-1.0);
}

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Rebasing CWS odff05

2008-11-29 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Hi,

On Tuesday, 2008-11-18 17:31:03 +0100, Eike Rathke wrote:


I started migrating CWS odff05 from CVS (currently resynced to m31
there) to SVN, and then will rebase it to m36 when available. I'll give
you a heads up when the CWS will be ready for further development.


m36 took longer than I thought it would, but now it's ready and CWS
odff05 is rebased to m36. Compiled fine on Linux/x86 and Solaris/SPARC,
Daniel is currently building Windows.


Compiling with MSVC 9 express on WinXP has finished now. There where no 
problems.


kind regards
Regina

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[sc-dev] Examine changes for ODFv1.2

2008-10-10 Thread Regina Henschel

Hi all,

in discussion with Eike the idea has come up, to examine which changes 
are necessary to adapt the functions to ODF1.2, especially examine the 
distributions. First I thought to write a document, but now I have the 
idea to track it in the Wiki. My plan is a page like

http://wiki.services.openoffice.org/wiki/User:Regina/MyDrafts
So everyone can see what is already done, in progress, or need to be 
done, and the examination can be done successively as time is available.


Do you agree?
If yes, please tell me a place, to put it.
If yes, do you have any suggestion for improvement?

Kind regards
Regina


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Examine changes for ODFv1.2

2008-10-10 Thread Regina Henschel

Hi all,

Niklas Nebel schrieb:

On 10/10/08 02:44 PM, Regina Henschel wrote:
in discussion with Eike the idea has come up, to examine which changes 
are necessary to adapt the functions to ODF1.2, especially examine the 
distributions. First I thought to write a document, but now I have the 
idea to track it in the Wiki. My plan is a page like

http://wiki.services.openoffice.org/wiki/User:Regina/MyDrafts
So everyone can see what is already done, in progress, or need to be 
done, and the examination can be done successively as time is available.


Do you agree?
If yes, please tell me a place, to put it.
If yes, do you have any suggestion for improvement?


Is it limited to ODFF? Then it would fit nicely below 
http://wiki.services.openoffice.org/wiki/Calc/ODFF_Implementation.


Yes, it is about the changes, which are needed for ODFv1.2

I put it to
http://wiki.services.openoffice.org/wiki/Calc/ODFF_Implementation/Examine_functions

and linked it from the see also section. If you have a better place 
for the link, feel free to change it.


Kind regards
Regina


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Congratulations, Regina! Gold Award winner of the Community Innovation Program.

2008-10-07 Thread Regina Henschel

Hi Eike,

Eike Rathke schrieb:

Congratulations, Regina!


I feel honored, that my contribution was found worth an award, and I 
will surely add some more pieces to OpenOffice.org. Thanks to you and 
all others, answering my questions and helping me in all those things I 
stumble on.


Kind regards
Regina



OpenOffice.org announced the winners of the Community Innovation
Program, http://development.openoffice.org/awardees-2008.html

I'm especially pleased that the Calc project is represented by Regina
Henschel who is one of the Gold award winners for her work on
improvements of the numerical stability of several statistical
spreadsheet functions.

Visit Sun Microsystem's featured article and listen to the podcast with
Regina and others talking about their contributions,
http://www.sun.com/aboutsun/media/features/2008-0924/

Thank you, Regina!

  Eike




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[sc-dev] Cannot use LEGACY.xxx style of functions in OOo3

2008-10-02 Thread Regina Henschel

Hi,

reading the ODFF draft spec I have assumed, that it is possible to 
access the functions which have LEGACY.xxx names in exact this way. But 
it doesn't work. This might not be a problem with CHIDIST, because it is 
clear, that this is the old, right tailed form, because CHISQDIST is the 
new left tailed form.


But for FDIST and FINV there are no new names planed. So what will 
happen, if you open an old document? You cannot show the name FDIST, 
because it will have a different meaning. I would expect, that when 
opened, it is changed to LEGACY.FINV. But that can I not use in OOo3. 
How will it be possible to use both meanings parallel?


It seems that there is something missing/wrong?

Kind regards
Regina



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] How to handle ODFF constrain number must be integer?

2008-10-01 Thread Regina Henschel

Hi Niklas,

Niklas Nebel schrieb:

On 09/27/08 20:06, Regina Henschel wrote:
In the ODFF draft spec of CHISQDIST is a constraint for the parameter 
'degrees of freedom' to be integer.


Shouldn't the argument type be integer instead?


It seems to be an open ToDo, see remark at the end of part 6.2.5.




Should I implement it:
(1) break with an illegal argument error, if the value is not an 
integer

or
(2) round the value to an integer.

The current implementation of the complement function CHIDIST rounds 
the incoming value, but the spec has the same constraint for 
LEGACY.CHIDIST.


I would prefer version (2) to make it consistent with existing 
CHIDIST. And changing CHIDIST too, I consider to dangerous, because 
existing documents might no longer work.


Yes, for the implementation, let's stay consistent with the other 
functions, that is, truncate (not round) the value.


Current implementation of CHIDIST has 
::rtl::math::approxFloor(GetDouble());

I'll copy it in that way in CHISQDIST in CHISQINV.



The current implementations of CHIDIST and CHIINV have a constraint 
'degrees of freedom  1.0E5'. The spec don't have such restriction nor 
mention that they might be necessary. The code has no comment, why 
this constraint has been introduced. Can you tell me? Huge values 
might overflow oder underflow somewhere, but is that reason enough to 
reject them from the beginning?


The old implementation (before issue 90703) looks like it couldn't 
handle large values. If you're confident that the current implementation 
is better, I think that constraint can be removed.


When degrees of freedom is large and x-values is a little bit smaller 
than degrees of freedom, you get a no convergence error. When x-value 
is a little bit greater you get a value, but that is less accurate than 
for small values of degrees of freedom (but more accurate than the old 
implementation for largest possible values). That would be something to 
be mentioned in the Wiki. If x-value is not so near to degrees of 
freedom, you will get 0 or 1, which are correct values in that cases. So 
I see now reason, not to remove the constraint.


kind regards
Regina


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Which category for GAMMA and GAMMALN?

2008-10-01 Thread Regina Henschel

Hi Eike,

thanks for your answer. Next step to finish :)

kind regards
Regina

Eike Rathke schrieb:

Hi Regina,

replying after vacation gap..

On Sunday, 2008-09-21 19:26:04 +0200, Regina Henschel wrote:

GAMMALN is currently in Category 'Statistical'. But in  
OpenFormula-v1.2-draft9.odt (which is the most current) it is in chapter  
'6.15 Mathematical Functions'. GAMMA is an expansion of factorials to  
real numbers.


Shall I
(1) Put GAMMA into 'Statistical' too
or
(2) Put GAMMA into 'Mathematical' and leave GAMMALN unchanged
or
(3) PUT GAMMA and GAMMALN both into 'Mathematical'?


(3) wouldn't be an option as long as we don't decide to reorganize the
categorization, which David also mentioned. The current categorization
lists functions for Excel compatibility, so people find the functions
where they are used to.

I think (1) would be best as all 4 GAMMA* functions would be grouped
together, pointing the user to the existence of the new GAMMA function.
Even if that would add to the improper categorization. Putting only
GAMMA into Mathematical and leaving GAMMALN in Statistical could be
somewhat confusing, I guess.


Does the GAMMA function need a name in Resource  
RID_SC_FUNCTION_NAMES_ENGLISH?


Yes, as those names are used to store in ODF 1.2 format. Also the
XFunctionAccess API still uses them for compatibility.

If yes, which name should be used? In  
general, where can I find which names are the correct ones for ODF v1?


For new functions simply use the name as defined in ODFF. Older OOo
versions not knowing a function wouldn't be able to compile and
interpret the formula anyway.

  Eike




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Style of strings in sc/source/ui/src/scfuncs.src

2008-09-27 Thread Regina Henschel

Hi Niklas,

thanks for your quick answer. I'll follow your remarks.

kind regards
Regina

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[sc-dev] How to handle ODFF constrain number must be integer?

2008-09-27 Thread Regina Henschel

Hello,

and another questions, but I'm confident to finish this project next week ;)

In the ODFF draft spec of CHISQDIST is a constraint for the parameter 
'degrees of freedom' to be integer.


Should I implement it:
(1) break with an illegal argument error, if the value is not an integer
or
(2) round the value to an integer.

The current implementation of the complement function CHIDIST rounds the 
incoming value, but the spec has the same constraint for LEGACY.CHIDIST.


I would prefer version (2) to make it consistent with existing CHIDIST. 
And changing CHIDIST too, I consider to dangerous, because existing 
documents might no longer work.



The current implementations of CHIDIST and CHIINV have a constraint 
'degrees of freedom  1.0E5'. The spec don't have such restriction nor 
mention that they might be necessary. The code has no comment, why this 
constraint has been introduced. Can you tell me? Huge values might 
overflow oder underflow somewhere, but is that reason enough to reject 
them from the beginning?


kind regards
Regina


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[sc-dev] Style of strings in sc/source/ui/src/scfuncs.src

2008-09-26 Thread Regina Henschel

Hello,

I'll introduce new functions and I'm uncertain, how I should write the 
strings in the mentioned resource file.


(1) Upper or lower case? If I give the type of the parameter, should I 
use lower or upper case, for example Number or number? Same if I 
give the name of the parameter, for example alpha or Alpha?


(2) Excel shows a tooltip when you enter a function, for example 
(German) 'GAMMAVERT(x;Alpha;Beta;Kumuliert)'. Will there be a similar 
feature in OOo? If yes, will the tooltip be generated from the part 
'Name of Parameter' of the resource file?


(3) Should the type be combined with the name? For example Cumulative 
(logical) or only the type Logical or name Cumulative and the other 
information in the description?


(4) Are there any restrictions in the length of the strings 
'Description', 'Name of Parameter' and 'Description of Parameter'?


Kind regards
Regina

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[sc-dev] Which category for GAMMA and GAMMALN?

2008-09-21 Thread Regina Henschel

Hi,

I want to bring the GAMMA function to UI, which works in general. But I 
have some questions for details.


GAMMALN is currently in Category 'Statistical'. But in 
OpenFormula-v1.2-draft9.odt (which is the most current) it is in chapter 
'6.15 Mathematical Functions'. GAMMA is an expansion of factorials to 
real numbers.


Shall I
(1) Put GAMMA into 'Statistical' too
or
(2) Put GAMMA into 'Mathematical' and leave GAMMALN unchanged
or
(3) PUT GAMMA and GAMMALN both into 'Mathematical'?


Does the GAMMA function need a name in Resource 
RID_SC_FUNCTION_NAMES_ENGLISH? If yes, which name should be used? In 
general, where can I find which names are the correct ones for ODF v1?


kind regards
Regina

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [sc-dev] Some details of EUROCONVERT() specification.

2008-09-19 Thread Regina Henschel
Hi Lvyue,

do you know the description from Microsoft?
http://office.microsoft.com/en-us/excel/HP100624761033.aspx

kind regards
Regina


lvyue schrieb:
 Hi, all
 I'm working on EUROCONVERT(), while implementing it,
 I found some details unmentioned in specifies.
 
 the format of the formula is EUROCONVERT( Number; TextFrom; TextTo;
 [FullPrecision [; TriangulationPrecision]] ).
 Comparing with Excel, I find following things:
 1. if TextFrom equals TextTo, the result is completely the same as Number,
 no matter what the following two parms are;
 2.if TextFrom=EUR and TextTo is other, TriangulationPrecision has no
 influence to the result;
 3.if TextFrom=other and TextTo=EUR, the result seems to be rounded
 exactly to TriangulationPrecision;
 4.TriangulationPrecision's rang is 3~32767, this is not an important
 thing, just mention to let know.
 
 somewhere I used seem to, because I didn't find any more detailed
 specifices of Excel's EUROCONVERT(), so I can only guess from the result
 it gives.
 
 and I want to implement our EUROCONVERT() the same way.
 if any one has questions and suggestions, please let me know. :)
 
 
 Thanks
 Lvyue
 
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  1   2   >