[sc-dev] Re: Farewell

[Eike Rathke]

Hi Niklas,

On Sunday, 2011-09-04 18:56:17 +0200, Niklas Nebel wrote:

> In case anyone is still reading these lists:

Occasionally..

> Thanks everybody for a great time!

It was a pleasure working with you.

All the best!

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature

Re: [sc-dev] Removing ULONG

[Eike Rathke]

Hi Regina,

On Monday, 2011-01-17 23:12:16 +0100, Regina Henschel wrote:

> I'm currently looking in ScBinomDist to remove the PushNoValue()
> cases. I see a lot of ULONG there and as Carsten has announced, that
> ULONG will be removed, my question now, how I should replace it.
> 
> The parameters n (total number of independent trials) and x (number
> of successful trials) are integers in ODF. As we store them in
> double, they are exact up to 48Bit. The code has some for-loops up
> to this parameters. What type shall I use for the index i in the
> loops?

Such loop variables were intentionally declared as ULONG to use the
maximum size integer a system provides, back in time when ULONG was
typedef'ed to unsigned long. On the other hand, I can hardly imagine
a spreadsheet where more than 2^32 cells are passed as a data range..

A safe approach would be to use sal_uInt32 and introduce a GetuInt32()
method (internally using GetDouble()) to obtain an argument that is to
be converted into a sal_uInt32 and let that set an error if the
approxFloor()'ed argument value is greater than SAL_MAX_UINT32. We may
introduce errNumericOverflow to signal this and distinguish from other
errors.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS


pgpVyS9CgMwHu.pgp
Description: PGP signature

[sc-dev] On the Numerical Accuracy of Spreadsheets

[Eike Rathke]

Hi,

The Journal of Statistical Software, a publication by the American
Statistical Association, last year published a paper

"On the Numerical Accuracy of Spreadsheets"
http://www.jstatsoft.org/v34/i04/

| This paper discusses the numerical precision of five spreadsheets (Calc,
| Excel, Gnumeric, NeoOffice and Oleo) running on two hardware platforms
| (i386 and amd64) and on three operating systems (Windows Vista, Ubuntu
| Intrepid and Mac OS Leopard). The methodology consists of checking the
| number of correct significant digits returned by each spreadsheet when
| computing the sample mean, standard deviation, first-order
| autocorrelation, F statistic in ANOVA tests, linear and nonlinear
| regression and distribution functions. A discussion about the algorithms
| for pseudorandom number generation provided by these platforms is also
| conducted. We conclude that there is no safe choice among the
| spreadsheets here assessed: they all fail in nonlinear regression and
| they are not suited for Monte Carlo experiments.

Example data set available.

Calc releases assessed were 2.4.1 and 3.0.1, so they missed some of
Regina's more recent work on accuracy. Nevertheless, Calc doesn't come
off badly ;-)

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS


pgpU2SU8tqPtS.pgp
Description: PGP signature

Re: [sc-dev] Help with SC wiki template

[Eike Rathke]

Hi Alexandro,

On Saturday, 2010-12-04 09:46:32 -0600, Alexandro Colorado wrote:

> http://wiki.services.openoffice.org/wiki/Template:Calc_Project

Thanks, looks good in general, but some nitpicks:

* For icons please use the OOo3 application icons instead of OOo2 from
  http://ui.openoffice.org/VisualDesign/OOo30MimeType.html
  Here
  
http://ui.openoffice.org/VisualDesign/gifs/Icons/OOo30_final_mimetype/Galaxy_OOo3_calc-app_128.png
  A smaller icon would occupy less space and maybe look better,
  
http://ui.openoffice.org/VisualDesign/gifs/Icons/OOo30_final_mimetype/Galaxy_OOo3_calc-app_48.png
* The menu list is too long.
  - Remove the entire "Projects on this Wiki" section, these are not
related to Calc and can be found on the main page.
  - Shrink "Calc Add-In" section to just display
Constructing_Components, Calc/Add-In and Category:Add-In
* There's no calc.openoffice.org subdomain, it's sc.openoffice.org ;-)

Thanks for the effort

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS


pgpwLzlispc5k.pgp
Description: PGP signature

Re: [sc-dev] Shortcomings in ScInterpreter::CheckMatrix

[Eike Rathke]

Hi Regina,

On Sunday, 2010-08-29 18:33:38 +0200, Regina Henschel wrote:

> [... CheckMatrix ...]
> 
> 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?

Yes, absolutely. I think the method as it is is a result of
a refactoring, combining code of LINEST and LOGEST as it was back then.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpEwuNnsxfx0.pgp
Description: PGP signature

Re: [sc-dev] Calc does not detect singularity

[Eike Rathke]

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)
> 
> I get
> 0,-1.#NANE+000#VALUE! #VALUE!
> #NUM! #NUM!   #VALUE!
> #NUM! #NUM!   #VALUE!

I got different results in OOO330m10 and DEV300m85, no error at all, and
even different in one value of the last column, being 

OOO330m10 Solaris/x86:

28.1318681319 -3.5164835165 10
-819855292164869000  27328509738829  7.79926253788309E-015
546570194776579000  -182190064925526000  -3.33


DEV300m85 Linux/x86:

28.1318681319 -3.516483516510
-819855292164869000  27328509738829 0
546570194776579000  -182190064925526000 -3.33

Of course both obviously look wrong. Difference of 0 vs.
7.79926253788309E-015 might be because of different compilers'
optimizations, though it looks suspicious. I assume you're working on
Windows. Would be good to know what exactly happens.


> I guess, that the wrong notation in upper, left cell is already
> tracked in issue 114125.

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

> But I think, Calc should not return #NUM!
> or #VALUE! at all, but Err:502 (illegal argument), because the
> matrix is singular.
> The LU decomposition has a zero in the diagonal, so it is possible
> to detect this case. Excel and Gnumeric return #NUM! in the whole
> range.

I ran that in a non-product debug build where the LU decomposition is
written to stderr, there was no 0, which explains why singularity was
not detected. The code is in interpr5.cxx at line 767

fprintf( stderr, "\n%s\n", "lcl_LUP_decompose(): LU");

and displayed

 9.11827

0.33 0.066 0.099

0.11  0.33   1.8e-18

Can you compare that with your values?


In ScInterpreter::ScMatInv() line 924 some possible checks are
documented, of which one is implemented but disabled because
a "reasonably sufficient error margin" would have to be found for
fInvEpsilon. That would then set errIllegalArgument. Maybe going into
detail there could solve the problem for MINVERSE.


> If the user sees this result, he will be cautious. But it might be
> hidden as intermediate part of a larger formula. So the user does
> not notice that the result is totally wrong. LINEST needs
> calculating an inverse matrix for the statistics, but does of cause
> do not show the matrix but the statistics, so that the user might
> not detect, that the values are wrong.
> Gnumeric returns #ZAHL! errors and Excel returns the same wrong
> values as Calc.
> 
> Should I test the intermediate results in LINEST to catch this cases
> and return an error?

Do you have a recipe to detect such cases? An error would be way better
than wrong results..

If the problem can be solved it would be worth to factor the code of
MINVERSE out to a general matrix inversion routine that can be used in
LINEST and maybe others.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpgH2dfnPn2K.pgp
Description: PGP signature

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

[Eike Rathke]

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

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpdqxgQl0FBM.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Monday, 2010-08-16 22:40:49 +0200, Regina Henschel wrote:

> > 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().
> 
> Isn't the total length of a formula restricted to 255 characters?

No, the length of one symbol/token was limited to 255 characters,
nowadays is 1024. A token is an operator, a function name, a literal
string, ... Each element of a constant matrix is a token. The maximum
total length of a formula is 512 tokens.

> If so, a constant matrix cannot be huge and cloning is harmless.

An unconditional clone would also clone any range reference that was
converted to a matrix. This is the case we'd like to avoid.

> Does your suggestion mean, that changing the values in the parameter
> matrices in the implementation of the function would then be always
> possible? Or will there be a property of pMatY which I have to test
> inside the implementation for to decide, whether I can change it or have
> to use a clone?

What I have in mind would be a method
ScMatrixRef ScMatrix::CloneIfConst()
that could be called as

ScMatrixRef pNew = pMatY->CloneIfConst();
... modify pNew ...
pMatY = pNew;

If pMatY was mutable, the call wouldn't clone the matrix but just add
a new reference and modifying pNew would actually modify pMatY. The
ScMatrix ctor would always flag a matrix as immutable and only
ScInterpreter::GetNewMat() would set that to mutable, and the final
result matrix would be set to immutable again in case it is used as
input for another expression. However, the case of array context needs
to be evaluated, as multiple calls to a function that expects mixed
scalar and matrix parameters of course should not modify the matrix
multiple times. If there is no easy solution to that I'll refrain from
changing things for OOo3.3 and just clone the matrix.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgptbayagk4j4.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Saturday, 2010-08-14 00:18:38 +0200, Regina Henschel 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().

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgph0PWkOvcYH.pgp
Description: PGP signature

Re: [sc-dev] Formation of Matrix formula

[Eike Rathke]

Hi rashi,

On Friday, 2010-08-13 17:13:56 +0300, rashi dhing wrote:

> Hi !! Can you tell me where exactly is the matrix fomula formed (i.e) where
> are the "curly brackets" added to
> form the matrix formula. Is it done by the edit engine ??

The surrounding '{' and '}' are UI display features and added when the
formula string is reconstructed from the token array and the formula
cell has cMatrixFlag!=0, see ScFormulaCell::GetFormula()

Btw, it is not necessary to Cc us when writing to the list, we do read
the list and just have to delete a copy of your mail..

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpQ9HMQtNZ6M.pgp
Description: PGP signature

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

[Eike Rathke]

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..

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpJuyt4EM9bD.pgp
Description: PGP signature

Re: [sc-dev] Add a new Calc spreadsheet function

[Eike Rathke]

Hi Marina,

On Thursday, 2010-08-12 15:13:24 +0200, Marina Plakalovic wrote:

> Working with ranges inside the functions is not the issue, but registering
> function is.

I'm not sure I understand what you mean with registering. Are you
referring to parclass.cxx?

> I followed steps described in
> http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions,
> and it seems that some additional changes must be made for functions that
> take range as a parameter.

I just added some details to
http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions#The_not_so_easy_case_of_non-scalar_arguments
and hope that helps. If not, please ask your questions ;-)

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpK3g0Ufjxfh.pgp
Description: PGP signature

Re: [sc-dev] Trouble with ScInterpreter::MFastMult

[Eike Rathke]

Hi Regina,

On Thursday, 2010-08-12 09:24:59 +0200, Regina Henschel wrote:

> 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.

Ah, lovely, comments that describe something different than what the
actual implementation does..

> 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.

Yes, that was the only place using it, currently only the disabled test
code in ScInterpreter::ScMatInv() uses it, but wouldn't differ if the
implementation was changed as it calls with identical quadratic
dimensions.

> So what to do?
> 
> (1) Change the method to work as the comment describes.

Yes, please go ahead.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpLw2aPCOiOD.pgp
Description: PGP signature

Re: [sc-dev] Add a new Calc spreadsheet function

[Eike Rathke]

Hi Marina,

On Monday, 2010-08-09 15:21:39 +0200, Marina Plakalovic wrote:

> I have added new function by following the tutorial:
> http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions
> 
> This works fine when the arguments of the function are scalar, but if I want
> to pass the range of values to the function, additional steps are needed.

You need to differentiate according to the data type that is on the
stack, e.g. svDoubleRef for a range reference. See for example
ScInterpreter::ScMax() how that is handled in a simple case. For your
implementation also ScInterpreter::ScCountIf() and
ScInterpreter::ScSumIf() may be of interest.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpFNaaUSjveN.pgp
Description: PGP signature

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

[Eike Rathke]

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};...)

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

Unfortunately not.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it phased out. Use eike.rat...@oracle.com instead. Thanks.


pgpmvODAqZHIT.pgp
Description: PGP signature

Re: [sc-dev] Get individual cells inside a cell range

[Eike Rathke]

Hi Pivithuru,

On Friday, 2010-08-06 14:01:31 +0530, Pivithuru Wijegunawardana wrote:

> I need to get the individual cells inside a cell range. But I need to do
> this without giving its x and y positions. Is there any method I could get a
> XCell list from a cell range? I am doing this in java.

You can query the XCellRangeAddressable interface and with that use
getRangeAddress() to obtain the CellRangeAddress and calculate the
dimensions
(nCols=cra.EndColumn-cra.StartColumn+1,nRows=cra.EndRow-cra.StartRow+1)
and then loop over all cells of the XCellRange from (0,0) < (nCols,nRows)
using getCellByPosition()

See
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/Spreadsheets/Absolute_Address

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it will phase out shortly. Use eike.rat...@oracle.com instead. Thanks.


pgpy9RPwwVPwR.pgp
Description: PGP signature

Re: [sc-dev] Missing parameter in LINEST

[Eike Rathke]

Hi Regina,

On Thursday, 2010-08-05 15:26:07 +0200, Regina Henschel wrote:

> >The interpreter allows these cases because in Excel the missing
> >parameter is allowed at most places and that's needed for imported
> >documents.
> 
> 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.

Well, yes, of course you're right, in theory ;-)  However, with 2 or
3 import filters just for the different Excel file formats this would be
even more work than keeping the interpreter flexible and assuring
correct syntax for ODFF storage.

Or, Daniel, in case you're reading this, what is your opinion?

It would be an easier step to default missing parameters during formula
compilation, but that would work only for UI, PODF and hopefully OOXML
imports, not for binary file formats.

> 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.

We already do that in some places, see usage of
ScInterpreter::GetDoubleWithDefault(), here it would be
::rtl::math::approxFloor( GetDoubleWithDefault( 1.0))
We should actually introduce a ScInterpreter::GetBoolWithDefault() for
these cases..


> >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?

This is a valid general solution. A missing parameter doesn't have to be
converted, which is handled in the switch case svMissing that follows.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it will phase out shortly. Use eike.rat...@oracle.com instead. Thanks.


pgpt0ZWkzO7GL.pgp
Description: PGP signature

Re: [sc-dev] Missing parameter in LINEST

[Eike Rathke]

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()

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).

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 --
 Please don't send mail to the old e...@sun.com account that I used for mailing
 lists, it will phase out shortly. Use eike.rat...@oracle.com instead. Thanks.


pgpukvFsVzWOB.pgp
Description: PGP signature

Re: [sc-dev] Include file error

[Eike Rathke]

Hi rashi,

On Tuesday, 2010-07-20 20:09:38 +0300, rashi dhing wrote:

> Right now static would be fine but at a later stage I will want them to
> dynamically update when other cells change.

All change notifications of referenced cells to their dependents is done
based on the RPN token array of the referring formula cell, if your
approach doesn't use a ScFormulaCell and its ScTokenArray to hold the
formula it would need yet something different.

I still wonder what exactly you're trying to accomplish. Could you give
an example of how your formulas would look like, and give us details
what the difference is that you can't use the usual interpreter
approach?

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Oracle, it will also phase out
 shortly. Use eike.rat...@oracle.com instead. Thanks.


pgp1d9l33q43k.pgp
Description: PGP signature

Re: [sc-dev] Include file error

[Eike Rathke]

Hi Rashi,

On Wednesday, 2010-07-07 11:09:00 +0200, Niklas Nebel wrote:

> On 07/07/10 10:50, rashi dhing wrote:
>> Wanted to use a certain function of the ScInterpreter class ! Can I give the
>> whole path "sc/source/core/interpre.hxx"  and use it ?
>
> I wouldn't recommend that. If you have a function that can be used  
> without ScInterpreter, you should move it out of interpre.hxx. If you're  
> creating an ScInterpreter instance to call your function, better use  
> ScFormulaCell instead.

The ScInterpreter ctor needs a ScFormulaCell anyway, calling
ScFormulaCell::Interpret() takes care of that. Then use
ScFormulaCell::GetErrCode() to check for error. As it seems you're
expecting a matrix result you may then use ScFormulaCell::GetMatrix(),
note that if the result was not a matrix a NULL pointer is returned and
depending on IsValue() you may use GetValue() or GetString() to obtain
the result.

You'll have to create the ScFormulaCell instance with the ctor that
takes a preconstructed ScTokenArray* and a BYTE as last parameter and
pass the MM_FORMULA constant there, otherwise the matrix result would be
thrown away and only the top left value survived as cell result.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Oracle. Use er...@sun.com 
Thanks.


pgpRXRKlJMOLH.pgp
Description: PGP signature

Re: [sc-dev] Absurd behaviour while displaying values in a range of cells

[Eike Rathke]

Hi rashi,

On Tuesday, 2010-07-06 12:40:35 +0300, rashi dhing wrote:

> So I did pore over the various functions of the ScInterpreter like GetNewMat
> and PushMatrix etc.
> Apart from being extremely complicated, I still really didn't understand
> where the result matrix
> was being set/put into the spreadsheet.

The result matrix is stored at the top left cell of a matrix formula
range, if there is any (e.g. created by having selected an area and
entered the formula using Ctrl+Enter), respectively at the formula cell.
So if the entire matrix result is to be displayed you, or the user, need
to create a matrix formula range of at least the same size. In the UI
that is done automatically if no range was selected, e.g. entering the
formula =MUNIT(2) and terminating the input with Ctrl+Enter instead of
Enter creates a 2x2 matrix formula range.

> I did create a matrix but now I don't know how to print the values
> onto the sheet. PushMatrix pushes the matrix onto the stack but that
> does not serve my purpose !!

What is your purpose then? So far I thought you created a spreadsheet
function that delivers an array/matrix result. If the final result of
a formula was a matrix on the interpreter's stack, that matrix result is
stored at the formula cell for display purposes or further evaluation.
It's nothing you should have to care about.

  Eike

-- 
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Oracle. Use er...@sun.com 
Thanks.


pgpBJ2uBnG08X.pgp
Description: PGP signature

Re: [sc-dev] Patch for issue 49380

[Eike Rathke]

Hi Kirill,

On Monday, 2010-06-21 11:32:08 +0400, Kirill S. Palagin wrote:

> Dear developers,
> the patch allows Find&Replace to search for empty cells.
> This is useful operation, which otherwise requires learning regexes.

Even a regex wouldn't help because only cells with content are
considered.

> Please consider integration of this patch for 3.4.

I grabbed the issue and will take a look.

> Thanks a lot for your attention.

Thanks for kicking my ass ;-)

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpx0tnBpEHs6.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Thursday, 2010-06-17 01:11:40 +0200, Regina Henschel wrote:

>> { "IMCOT", "IMCOT", false, "com.sun.star.sheet.addin.Analysis.getImcot",
>> "IMCOT" }
>>
> 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 :(

*sigh*.. ok, seems we'll need yet another mapping at least for new AddIn
functions.

> 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.

Thanks, I'll take a look at the naming stuff in general, as you know we
also have another roundtrip issues with AddIn functions and 2.x
versions, but not before next week.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpm9V4ayxZ9i.pgp
Description: PGP signature

Re: [sc-dev] Absurd behaviour while displaying values in a range of cells

[Eike Rathke]

Hi rashi,

On Friday, 2010-06-04 14:10:31 +0300, rashi dhing wrote:

> Hi Eike, Could you tell me why modifying the spreadsheet while  interpreting
> a function is not the right approach

That could modify cells that are still to be interpreted, even for the
same formula the modifying function is part of, or cells that were
already interpreted for some formula but then would deliver a different
result in another step. It's like biting the hand that feeds you..

> and what is the workaround or the right approach ?

See Niklas' answer about returning an array.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpIdpMfeVFtP.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Thursday, 2010-06-10 00:25:00 +0200, Regina Henschel wrote:

> 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?

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.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgplWtHARCjmT.pgp
Description: PGP signature

Re: [sc-dev] Absurd behaviour while displaying values in a range of cells

[Eike Rathke]

Hi rashi,

On Thursday, 2010-06-03 17:52:10 +0300, rashi dhing wrote:

> I have defined a function in which I take as input,  cell values from a
> range and after doing some calculation
> output them on the spreadsheet using the ScDocument::SetString and
> ScDocument::SetValue functions.

Modifying sheet content while interpreting functions is a big no-no.
Please don't do that.

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpeZKjkBRxYl.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Thursday, 2010-06-03 16:56:56 +0200, Regina Henschel wrote:

>> 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.

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?

Off-head, as pre-3.0 doesn't implement that function and the (upper)
programmatical name is not expected to be encountered in documents
originating from ODF 1.1 and earlier, does

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

already help?

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpWQwGdJn7RK.pgp
Description: PGP signature

Re: [sc-dev] Calc/Chart Project

[Eike Rathke]

Hi Marina,

On Monday, 2010-05-31 16:21:16 +0200, Marina Plakalovic wrote:

> I have heard about the summer student internship and decided to apply for  Add
> new spreadsheet functions and parameters according to ODFF.

Thank you for your interest in the OpenOffice.org internship!

> I am interested to know a little bit more about this project. Where can I
> get some additional documents or links if they exist to get myself more
> familiar with the project.

Please read
http://wiki.services.openoffice.org/wiki/OpenOffice.org_Internship
subscribe to the internship mailing list and fill out the application
form as mentioned there.

General documentation about how spreadsheet functions can be added to
the compiler and interpreter is available at
http://wiki.services.openoffice.org/wiki/Calc/Implementation/Spreadsheet_Functions

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpkuFu42MUlS.pgp
Description: PGP signature

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

[Eike Rathke]

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

> Please have a look at issue 101386. Is it the same problem?

No, that is about the old Add-Ins using the deprecated binary interface.
Though all is related somehow..

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpNQWG40Vpob.pgp
Description: PGP signature

Re: [sc-dev] Decision about Bessel-functions needed

[Eike Rathke]

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.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp40695lqaNo.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

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

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

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

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

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

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

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

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

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

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp7AvObGztvv.pgp
Description: PGP signature

[sc-dev] ViSta (was: [sc-dev] Re: [dev] Debug the Calc Source Code)

[Eike Rathke]

Hi Ruben,

On Thursday, 2010-04-08 10:34:13 -0300, Ruben Ledesma wrote:

> Would anyone be interested in connecting Calc with a data
> visualization  system called ViSta "The Visual Statistics System"?.

Could be interesting, I took a short glance at
http://forrest.psych.unc.edu/research/index.html

> ViSta is free and open software based on LispStat, and there is a
> connection with Excel.

How does it interface with Excel?

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgph7YnYY0fjx.pgp
Description: PGP signature

[sc-dev] Show YOUR code on FOSDEM

[Eike Rathke]

Hi,

If you have written some Calc code you'd like to discuss on FOSDEM
in my "Show me YOUR code" workshop on Saturday, February 6
http://fosdem.org/2010/schedule/events/ooo_workshop
please send mailto:er...@sun.com?subject=fosdem%20code

Of course we can also discuss at other times on FOSDEM, meet me at the
DevRoom or drop a note at the OOo stand.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpFaIm3Kls6v.pgp
Description: PGP signature

Re: [sc-dev] Issues with page formatting in XLS-import

[Eike Rathke]

Hi Cor,

On Friday, 2009-12-18 11:45:39 +0100, Cor Nouws wrote:

> There are some open issues for page formatting in XLS-import.
> 70505, 75787, 72823
> They are a bit different, but related in the sense that opening and  
> printing an .xls is affected.
>
> Are all those three issues complicated, say a can of worms that you'd  
> rather leave until a major make over or so ..., or are there relative  
> easy ones that maybe could be fixed and so better serve (business) users?

I think if they were easy to fix they would had been fixed already..
Part of the problem is that Excel row heights are given in 255th
fractions of a font height. If font metrics differ that is a problem.
That a CJK font was used in issue 70505 probably adds to this.

For a detailed answer you may have to wait until the holiday season is
over and Daniel will be back.

Have peaceful days.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpm4vmzn0ilA.pgp
Description: PGP signature

Re: [sc-dev] Linker error on adding a new module to the sc project

[Eike Rathke]

Hi rashi,

On Tuesday, 2009-12-15 22:49:42 +0300, rashi dhing wrote:

> - Is it possible to build the installation set just for the spreadsheet rather
> than the entire openoffice suite.

No, but you can build only the sc module ( cd sc; build debug=true ) and
copy the resulting libraries from sc/$INPATH/lib/*.so (respectively
sc/$INPATH/bin/*.dll on Windows) to an installation of the full build,
/openoffice.org/basis3.2/program/


> - The "SetTextString" function in "inputwin.cxx" is responsible for setting
> the text in the input-line but only when it is entered from the cells.
> When text is directly entered in the input-line is it the edit engine that
> comes into play ? Can you tell me which function handles this ?

Yes, it is the EditEngine. In this case the raw text string is set in
ScTextWnd::StopEditEngine(), but only after the input was confirmed or
canceled. Key input is handled via ScTextWnd::KeyInput(), which calls
SC_MOD()->InputKeyEvent() that in turn calls ScInputHandler::KeyInput()
and ScInputHandler::DataChanged() where for example also formula mode
status is updated through UpdateFormulaMode() that calls
ScInputWindow::SetFormulaMode(). For cell input key input is also
handled by ScInputHandler::DataChanged() and
ScInputWindow::SetTextString() called from there. So that may seem
a strategic point for you to add new functionality, for example after
UpdateFormulaMode() if bFormulaMode==TRUE.

However, this would not catch the Function Wizard's input, that needs
ScTextWnd::SetTextString() again. The entire string is set with
ScInputWindow::SetFuncString() when closing the dialog.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpwG8z811Mbk.pgp
Description: PGP signature

Re: [sc-dev] Microsoft testing Excel for supercomputers

[Eike Rathke]

Hi Maho,

On Friday, 2009-11-20 12:32:09 +0900, Maho NAKATA wrote:

> My idea is just a not a special and very simple.
> 
> If we do vector-vector, vector-matrix, matrix-matrix multiplication etc, 
> 
> *just call BLAS and LAPACK*

We don't do much of these operations, only in some context of
spreadsheet scientific functions and matrix functions of course.

Most time is spent querying search expressions and accessing cell values
and calculation, these operations and all document accessing functions
that can be called from within the interpreter have to be made reentrant
and thread safe. The mechanism that currently builds the calculation
graph (it isn't really one) on the fly as it encounters the cells to be
calculated will have to be changed to pre-calculate independent branches
within the graph that then can be fed to some threading engine, or later
MPI or some parallelizing framework.


> If you need parallel version, then call PBLAS, BLACS and ScaLAPACK. We may
> also need MPI for that.

> 4. We may need FORTRAN compiler as well :-)

I think you just lined out why we would not start with this approach
first. With general thread-safety we would gain more. My tuppence.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpuQMlyTiptq.pgp
Description: PGP signature

Re: [sc-dev] Issue 5930 - split for better understanding and proceding?

[Eike Rathke]

Hi Cor,

On Tuesday, 2009-09-15 14:47:50 +0200, Cor Nouws wrote:

> In this issue, someone did a proposal to split up things, for better  
> understanding et cetera:
> http://www.openoffice.org/issues/show_bug.cgi?id=5930#desc56
>
> AFAICS, it is a sound proposal.
>
> So if no one objects ... I 'll act as suggested by alastair paton.

Sounds good to me. However, IMHO we should use issue 53587 for SI prefix
formatting instead of 24373.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpXBzsADmX0c.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Leonard,

Just returned from vacation, hence the silence..

On Friday, 2009-09-11 00:43:09 +0200, Leonard Mada wrote:

> I might be too late,

Yes, too late, UI string changes aren't allowed anymore.

> but the following small correction
> sounds slightly better:
> 
> Calculates the probability of observing a z-statistic
> greater than the one computed based on *the* sample.
> 
> > Calculates the probability of observing a z-statistic greater than the one
> > computed based on a sample.

Yes, slightly better. I may change it on the fly for OOo3.3 if
I remember..

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpN3Q1icD4Wd.pgp
Description: PGP signature

Re: [sc-dev] Issue 5658 solved

[Eike Rathke]

Hi Cor,

Sorry for late answer, got drowned in 3.2 CWSs ...

On Thursday, 2009-09-03 09:06:26 +0200, Cor Nouws wrote:

> Good to see you resolved the issue! *
> (I give my question here, in order not to disturb people in issuetracker  
> while giving applause ;-) )

Well, thank you :)

> I more or less expect that our users have their own spreadsheets  
> properly made up, so that there are no migration issues and we don't  
> have to take any special action to inform them. What do you think?
> Or should we ask UX?

For existing OOo documents there may be an issue with formulas that so
far quietly assumed numeric 0 for textual content and now will produce
a #VALUE! error instead, or a different value if interpretable.
Especially the latter my need some extra care. Users of Go-oo and Debian
based distribution's packages are somewhat familiar with this, as those
versions already interpret strings, though implemented differently, i.e.
accepting everything that a cell input would accept as well, including
all locale dependent issues that I explicitly did not implement on
purpose. As long as the change is prominently announced in What's New
(and users read that, but ...) I don't think additional measures must be
taken. We should be prepared though to receive some alleged error
reports and point the submitters to the change announcement. And your
CT2N extension ;-)


> * Also cause it saves me the task of trying to integrate the CT2N
>   extension, which work has various tricky elements (that I will
>   not have much time for anyway) and in the end would only result in
>   a partly solution.

I still would like to have your extension as a companion though, because
- interpreting strings on the fly of course does have some runtime
  penalty, performance wise
- loading such a document in a different application may still yield
  different results
- strings resulting in #VALUE! will still have to be fixed.

So the CT2N extension still has its value. If it could additionally
detect the origin of a #VALUE! error it would be a most useful tool to
fix such broken documents.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp6ZOCWyRceD.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Wednesday, 2009-08-26 18:02:44 +0200, Regina Henschel wrote:

>> "calculates the probability of observing a value as large
>>  or larger for the z-statistic"
>
> 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.)

Translating that I'd get, hopefully correct:

"Calculates the probability of observing a value of the z-statistic
larger than the value of the sample's z-statistic."

Is that what we want to say?

> Describing the function using 'z-statistic' is indeed better than using  
> a description with 'mean', because of the function name ZTEST.

I agree.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpqPiYEWDQt1.pgp
Description: PGP signature

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

[Eike Rathke]

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.

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.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp1GDJ3fpS2g.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Friday, 2009-08-14 21:25:22 +0200, Regina Henschel wrote:

 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 don't think so. Excel allows empty parameters at most places, where
the default usually (exceptions prove the rule) is interpreted as 0.
Just that having an expression CEILING(,value) that calculates always as
0 is pretty senseless, and already the UI should not allow such input.
To my opinion, empty parameters (as opposed to optional parameters)
defaulting to some value should be refused unless the specific
replacement value depends on other arguments, which is the case for only
very few functions.


>> 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.

Which would be useful only for the wicked Excel "round away from 0"
behavior with y!=0, else for the mathematical calculation one could
always write CEILING(x).

> 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.

That would be incompatible with Excel and probably all other
applications that support this two parameters form.


>> 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?

It could be detected, but it's not necessarily reliable, as other
flavors of OOo may write a different generator tag. It would be cleaner
to document the difference between versions.


 == Export ==
>> 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.

In fact it would be _only_ useful in that case. As soon as ODF is to be
written, having CEILING_ADD wouldn't help at all and it should be
converted to ODFF CEILING. In case of roundtrip from/to Excel also the
current approach works fine. It's just with an extra editing where the
user uses the function unaware of the differences between OOo and Excel
we may run into problems when saving to Excel. That probably would not
be solved with an additional CEILING_ADD function.


> 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.

I wouldn't care about that. If it produces a correct result it would be
better than any good looking but error prone approach.


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

We shouldn't overrate that. An expression that always results in
0 probably isn't very widespread..  A bug of earlier versions.


 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 

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

[Eike Rathke]

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.

>> 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..

>> 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?
>
> Understood and agreed. This can be added in the import filters.
> I think it should be then:
> - If 1st param empty, replace with 0
> - If 2nd param empty, replace with 0
> - Add 3rd default param

Sounds good.

I first thought I could withdraw the new proposal I made for ODFF, 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..


>> == 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.

>> 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.

>> 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 the CEILING(-x) and FLOOR(-x) cases other
than writing NA(). We may better convert our CEILING/FLOOR to some
IF(...) construct similar to what Gnumeric does when importing an .ods
file.

Btw, Gnumeric for CEILING(-3.4) calculates -4 as if CEILING(-3.4,-1) was
given, when writing to Excel it stores CEILING(-3.4,) and the result in
Excel is 0.

What a mess. And all this only because some weirdo came up with the idea
that CEILING/FLOOR should do someting different than the mathematical
ceiling/floor functions..

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp6TAlAkDAF9.pgp
Description: PGP signature

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

[Eike Rathke]

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.

> 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.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpsEgz3Swk0W.pgp
Description: PGP signature

Re: [sc-dev] Problems with BESSELJ

[Eike Rathke]

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.

We'd prefer English messages, even if just for debugging/tracing
purposes ;-)

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpCKNvElsKz6.pgp
Description: PGP signature

Re: [sc-dev] Problems with BESSELJ

[Eike Rathke]

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.

In scaddins' bessel.hxx add

#include 

and add ::com::sun::star::sheet::NoConvergenceException to the Bessel*()
functions' throw lists.

As in the analsis.* files the declarations use macros, for consistency
in analysisdefs.hxx add

#define THROWDEF_RTE_IAE_NCE 
throw(CSS::uno::RuntimeException,CSS::lang::IllegalArgumentException,CSS::sheet::NoConvergenceException)

and in analysis.hxx change THROWDEF_RTE_IAE to THROWDEF_RTE_IAE_NCE for
all getBessel*() functions, same in analysis.cxx

In bessel.hxx add ::com::sun::star::sheet::NoConvergenceException to the
throw lists of all Bessel*() functions.

In bessel.cxx add

using ::com::sun::star::sheet::NoConvergenceException;

and NoConvergenceException to the Bessel*() functions' throw lists.

If I didn't forget anything that should do.


> (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. Of course you'll also need to add

#include 

to the file.


> (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

Hope that helps,

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.
diff -Npu DEV300/offapi/com/sun/star/sheet/makefile.mk 
offapi/com/sun/star/sheet/makefile.mk
--- DEV300/offapi/com/sun/star/sheet/makefile.mk2009-04-28 
22:02:10.0 +0200
+++ offapi/com/sun/star/sheet/makefile.mk   2009-07-09 13:35:27.0 
+0200
@@ -166,6 +166,7 @@ IDLFILES=\
NamedRangeFlag.idl\
NamedRanges.idl\
NamedRangesEnumeration.idl\
+   NoConvergenceException.idl\
PasteOperation.idl\
RangeSelectionArguments.idl\
RangeSelectionEvent.idl\
diff -Npu DEV300/offapi/com/sun/star/sheet/NoConvergenceException.idl 
offapi/com/sun/star/sheet/NoConvergenceException.idl
--- DEV300/offapi/com/sun/star/sheet/NoConvergenceException.idl 1970-01-01 
01:00:00.0 +0100
+++ offapi/com/sun/star/sheet/NoConvergenceException.idl2009-07-09 
13:34:35.0 +0200
@@ -0,0 +1,54 @@
+/*
+ *
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ * 
+ * Copyright 2008 by Sun Microsystems, Inc.
+ *
+ * OpenOffice.org - a multi-platform office productivity suite
+ *
+ * This file is part of OpenOffice.org.
+ *
+ * OpenOffice.org is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License version 3
+ * only, as published by the Free Software Foundation.
+ *
+ * OpenOffice.org is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License version 3 for more details
+ * (a copy is included in the LICENSE file that accompanied this code).
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * version 3 along with OpenOffice.org.  If not, see
+ * 
+ * for a copy of the LGPLv3 License.
+ *
+ /
+
+#ifndef __com_sun_star_sheet_NoConvergenceException_idl__
+#define __com_sun_star_sheet_NoConvergenceException_idl__
+
+#ifndef __com_sun_star_uno_Exception_idl__
+#include 
+#endif
+
+//=
+
+module com { module sun { module star { module sheet {
+
+//=
+
+/** Thrown by a Calc Add-In function this exception indicates the 
+function's algorithm did not converge to a meaningful result.
+
+@since OOo 3.2
+ */
+exception NoConvergenceException : ::com::sun::star::uno::Exception
+{
+};
+
+//===

Re: [sc-dev] Problems with BESSELJ

[Eike Rathke]

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?

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpR5Q5WuBwKz.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Monday, 2009-07-06 11:43:23 +0200, Regina Henschel wrote:

> I agree, not to implement FDISTL with OOo3.2. I can send you the code  
> which contains the algorithms, so that you can keep it and the  
> algorithms get not lost. Do you want a patch or the complete  
> interpr3.cxx file?

Patch please, so chances are that it can be applied in future.

> I think, that the FDIST problem has to be solved in OASIS.

Not necessarily.. it's no OASIS' fault that our implementation is as it
is.

> For CHIDIST it has been solved by introducing the new function name
> CHISQDIST.

Only because CHISQDIST is a more logical name for a function that does
some Chi Square computation.

> The  left tailed variant of the F-distribution needs a new name too.
> At least  it should not allow three parameters, so that application
> can notice the change by counting the parameters.

That wouldn't fit with the other functions that have the
distribution/cumulated boolean parameter all optional.

> Do you take the problem to the committee?

I can try, but no guarantee.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpI7Vi8YWt45.pgp
Description: PGP signature

Re: [sc-dev] Problems with BESSELJ

[Eike Rathke]

Hi Daniel,

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

>> Argh, I forgot those are Add-In functions. Bah, other exceptions aren't
>> allowed. Well, use IllegalArgumentException() then. The other
>> possibility would be to move the code into the core, where
>> SetError(errNoConvergence) would be possible, but that would pull in
>> a whole string of changes for the Excel export.
>
> Well. Don't know if there are any preparations to export a built-in  
> function as add-in. Maybe I did something for EUROCONVERT that is  
> useful.

Indeed, you did at least tell Lvyue how to do it ;-)
http://www.openoffice.org/issues/show_bug.cgi?id=93789

> Import needs to be changed too. Anyway, I would volunteer to do  
> these changes. :)

Great! When done, can you please describe the necessary steps in the
wiki? Probably best as a separate subpage under
http://wiki.services.openoffice.org/wiki/Calc/Implementation/

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp4Av4lcplnP.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Leonard,

On Saturday, 2009-07-04 19:53:56 +0200, Leonard Mada wrote:

> this brings me to an older issue:
> http://www.openoffice.org/issues/show_bug.cgi?id=85328

Which is completely unrelated to the problem we're talking about, you
hijacked the thread.

Input to a cell that is formatted as text is always treated as text and
never parsed as another data type or formula. This is on purpose, and
Excel does it the same. Usually used to pre-format cells and paste data
from the clipboard or enter text that otherwise would get parsed.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpbVmEP12TOP.pgp
Description: PGP signature

Re: [sc-dev] Problems with BESSELJ

[Eike Rathke]

Hi Regina,

On Saturday, 2009-07-04 23:52:18 +0200, Regina Henschel wrote:

>>> Or return an error, if neither asymptotic  formula results at least 2 
>>> digits (How tell the user, that the result is  not accurate?)
>>
>> A few functions set errNoConvergence if a function can't determine
>> a result.
>
> I cannot find such an exception, I only find
> throw CSS::lang::IllegalArgumentException()
> and
> throw CSS::uno::RuntimeException()

Argh, I forgot those are Add-In functions. Bah, other exceptions aren't
allowed. Well, use IllegalArgumentException() then. The other
possibility would be to move the code into the core, where
SetError(errNoConvergence) would be possible, but that would pull in
a whole string of changes for the Excel export.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpGht3L8Oegh.pgp
Description: PGP signature

Re: [sc-dev] Problems with BESSELJ

[Eike Rathke]

Hi Regina,

On Saturday, 2009-07-04 23:44:36 +0200, Regina Henschel wrote:

> I have attached a draft patch to issue 40309. You can use it to test the  
> performance.

Unfortunately I currently have no time to test things.

> On my PC a single calculation with x=500 lasts about 1  
> second.

To identify whether performance would hurt it would be good to have some
real world usage examples of BESSELJ. Without, 500 is just a number
as any other, and for smaller values it would be faster ;-)  I tend to
integrate your work and see if anyone complains.. the old implementation
isn't as accurate as it should be.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp7FQWL39akv.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Saturday, 2009-07-04 14:53:45 +0200, Regina Henschel wrote:

> I generate a file with a formula =FDISTL(a,b,c) and store it in
> version ODF1.2. Unzipping the file I find "of:=FDIST(a,b,c)", which
> is correct.
> 
> Now I open the file in OOo2.4.2. I get the version warning to
> upgrade. (BTW, you get the warning only for first opening.) Then it
> opens and the cell with "of:=FDIST(a,b,c)" is calculated with cell
> content =FDIST(a,b,c) instead of showing a #NAME? error. This must
> not happen, because =FDIST in OOo2.4.2 means the right tail, which
> is internally "of:=LEGACY.FDIST". The user does not know, that the
> result is wrong.

Ouch..

> 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.

Apart from the of:FDIST vs. oooc:FDIST problem this is just normal for
functions that get new parameters added. Features not understood by
older versions can't be correctly handled by them. If that results in an
error it's ok.

> If you now save the file in OOo2.4.2 and reopen it in OOo3.2, then
> the original =fdistl() cell contents are not restored. We have data
> loss.

"Content not restored"? What exactly is imported/displayed, and what is
missing? I assume it is imported as FDIST instead of FDISTL (UI names),
correct?

> Is there any place in source of OOo3.2 where I can avoid that error?
> Or can it only be solved in OOo2.4.x?

The erroneous handling of of:FDIST as oooc:FDIST in 2.4.2 could only be
fixed with a change in 2.x; however, a correct fix could only be to
either make 2.x not load 'of' namespace as formulas at all, or
completely implement handling of both namespaces, which would be quite
tough, partly the same I did for OOo3.0

An intermediate workaround to not make the function calculate wrong
results in 2.4.2 because of of:FDIST vs. oooc:FDIST could be to always
forcedly write the 4th parameter, such that 2.4.2 will return an error,
which is at least better than a wrong result. More nasty than nice, but ...

For the "contents not restored" I'd need more details. If it is the
function being imported as oooc:FDIST instead of of:FDIST, we might
trick the compiler into translating that to of:FDIST if the function has
4 parameters, given that we wrote always 4 parameters as mentioned
above. Again, more nasty than nice, but ...


> (2)
> Another problem is the following scenario. Save in OOo3.2 with
> version ODF1.0. Open in OOo3.1.1. In cells with content "=FDISTL()"
> you get correctly content "=fdistl()" and #NAME? error, because this
> function is unknown to OOo3.1.1. Now save the file in OOo3.1.1 with
> version ODF1.2. and open it in OOo3.2. The cell content is shown as
> "=fdistl()", but the now known function

It is not really known, because of:FDISTL doesn't exist.

> is not identified and the
> cells show a #NAME? error. Unzipping the file you see a
> "of:=fdistl()", which small instead of capital letters. Even a hard
> recalculate does not help.
> 
> Any solution for this?

We could introduce an alias handling in the compiler and tie that to the
 element's value and accept the alias only for documents
created by versions OOo3.0 and OOo3.1

However, given all these quirks I'm hesitating to implement FDISTL at
the current stage, especially with regard to the OOo2.4.2 problems.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpDSrWMtXM9p.pgp
Description: PGP signature

Re: [sc-dev] Problems with BESSELJ

[Eike Rathke]

Hi Regina,

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

> 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.

Just tried with KSpread 2.0rc1, it returns an error for fractional N.

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

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


> 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.

Seems really the best option.

> When can the upgrade be done?

Don't know. I don't have time for it until OOo3.2, I'll try to ping
Thorsten to see if he's willing, he already did the upgrade to 1.34;
I just know he'll be on vaction soon, so it would take its time anyway.

> Nevertheless, I can provide a patch with the Deuflhard algorithm likely  
> in time for OOo3.2 when give me a "go".

Yes, of course, that would be nice.

> BTW, I still need a decision on the UI name of the left tailed  
> F-distribution to finish that work. I have FDISTL in mind.

Ah, I thought we already agreed on that, yes, I think FDISTL is fine.

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpOjGJBDx3di.pgp
Description: PGP signature

Re: [sc-dev] Problems with BESSELJ

[Eike Rathke]

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?

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

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

No plans. Is there any practical benefit in calculating non-integer
orders? Does any spreadsheet application do it?

> So the question is, shall I implement Deuflhard's algorithm nevertheless?
>
> Perhaps warn the user in the help, that large input values results in  
> long lasting calculations?

What is "large" and what is "long lasting"?

> 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.

> 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.

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. 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 ;-)

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpFUd7hwuOqw.pgp
Description: PGP signature

Re: [sc-dev] Build problems

[Eike Rathke]

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?

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpLTvcl9ecff.pgp
Description: PGP signature

Re: [sc-dev] Rebasing CWS odff06 to m50

[Eike Rathke]

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.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpV42tF6Ov01.pgp
Description: PGP signature

Re: [sc-dev] Rebasing CWS odff06 to m50

[Eike Rathke]

Hi dev,

On Thursday, 2009-06-11 15:33:02 +0200, Eike Rathke wrote:

> I'm currently rebasing CWS odff06 to DEV300_m50, I'll give a note when
> done.

Rebasing is done, also applied the patch from
http://qa.openoffice.org/issues/show_bug.cgi?id=102701
to prevent accidental data loss.

When using a Linux non-pro build (configure --enable-dbgutil), in my
build as soon as the mouse is clicked anywhere, including the window
decoration, an assertion about operator delete mismatch pops up, and
after closing it it coms up again and this goes on and on forever. I'm
not sure yet if this a general failure or something went wrong in my
build. If this happens to you, kill the office with the Cancel or Abort
button, and upon next restart press Shift+Ctrl+Alt+D that pops up the
debug utilities' window and set Error output to None.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpqZIFnitvFg.pgp
Description: PGP signature

[sc-dev] Rebasing CWS odff06 to m50

[Eike Rathke]

Hi,

I'm currently rebasing CWS odff06 to DEV300_m50, I'll give a note when
done.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpf4heIQ2I7l.pgp
Description: PGP signature

Re: [sc-dev] specifications

[Eike Rathke]

Hi Ain,

On Friday, 2009-06-05 14:51:12 +0300, Ain Vagula wrote:

> Seems to me that there is a lot to do to make feature changes more
> collected and visible...

It was collected in
http://development.openoffice.org/releases/3.0.0.html
(unfortunately with a completely messed up layout ignoring all line
feeds and spaces).
Visibility apparently is a problem.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpwI8XZzgMlD.pgp
Description: PGP signature

Re: [sc-dev] specifications

[Eike Rathke]

Hi Ain,

On Friday, 2009-06-05 13:52:50 +0300, Ain Vagula wrote:

> I'm more interested about changes handling empty cells in various calc
> functions, made before 3.0. Ok, I can digg in allfeatures list
> archives ;)

Seems you're looking for
http://sc.openoffice.org/servlets/ReadMsg?list=features&msgNo=263
implented for
http://qa.openoffice.org/issues/show_bug.cgi?id=32340

Unfortunately the coresponding issue is omitted in older feature mails
(which is fixed for newer mails), but can be retrieved via EIS "Changes
mails" -> "Feature list" once you know the date a feature was posted..
http://tools.services.openoffice.org/EIS2/changesmails.EditFeature?Id=4166

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgptDkxAsatCV.pgp
Description: PGP signature

Re: [sc-dev] Hi, could some developer answer some questions?

[Eike Rathke]

Hi Isaac,

On Sunday, 2009-05-10 04:15:44 -0400, Isaac M. Marcos wrote:

> I need to solve some bugs in OOfice.
> 
> I am willing to code if you could point me in the right direction.
> 
> Let's assume I am a complete *newb*, Could you guide me to start?

Niklas pointed you to how to build the code. If you're still on board
(hopefully not scared away ;) my personal work flow might be of interest
to you: http://wiki.services.openoffice.org/wiki/User:ErAck/WorkFlow

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpMb4AiH9Mi6.pgp
Description: PGP signature

[sc-dev] CWS odff06, please svn update

[Eike Rathke]

Hi,

I applied several pending patches to CWS odff06, please svn update for
further development on interpreter functionality and patches to be
created. Modules to be rebuilt and delivered are sal, formula, sc and
scaddins.

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp7oMzXhQOnA.pgp
Description: PGP signature

Re: [sc-dev] Schedule for CWS odff06

[Eike Rathke]

Hi Regina,

On Sunday, 2009-04-26 23:44:03 +0200, Regina Henschel wrote:

> 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?

The page got just updated today ;-)  Freeze for OOo3.2 will get shifted,
otherwise time between 3.1 and 3.2 releases would be just too narrow.
3.2 will be branched off in September, and there won't be distinct
feature freeze and code freeze, just one freeze and branch off, every
other change will have to go in as showstopper. See also release status
meeting and minutes,
http://wiki.services.openoffice.org/wiki/ReleaseStatus_Minutes#2009-04-27

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpV1gGpEPCwk.pgp
Description: PGP signature

Re: [sc-dev] Implementation details of POISSON

[Eike Rathke]

Hi Regina,

On Tuesday, 2009-04-21 22:39:06 +0200, Regina Henschel wrote:

> I have attached a patch to the issue. When I have generated the patch  
> with TortoiseSVN, it includes all the other parts, on which I am working  
> in interpr3.cxx. I have deleted them and hope, that the patch will still  
> work for you.

Should do, as only the one block is needed. Thanks!

> I cannot generate test values with MuPad as I did in other cases,  
> because for large lambda or x each value would last some minutes. But  
> you can compare the results with Gnumeric. The values should be the same  
> for about 12 digits. I made some samples with MuPad and have noticed,  
> that sometimes Gnumeric is wrong in the last two digits. (Most time  
> Gnumeric is accurate in all digits.)

Wow, nice testcase, thanks again!

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpKvOmXqYb8p.pgp
Description: PGP signature

Re: [sc-dev] Implementation details of POISSON

[Eike Rathke]

Hi Regina,

On Wednesday, 2009-04-15 22:35:14 +0200, Regina Henschel wrote:

> I have a look at the function POISSON for issue  
> http://www.openoffice.org/issues/show_bug.cgi?id=69069
>
> The bug is easy to fix, I have tested my solution already and it work so  
> far,
> but I have some questions.

Great!

> (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?

Isn't mathematically for lambda==0 the result 0?

> If not, "PushInt(0)" looks strangely. Shouldn't it be PushDouble as for  
> other arguments too?

It doesn't really matter. Below PushInt(), the integer is converted to
a double token. It did matter back in WIN16 times with older processors,
when pushing a double required more instructions and stack operations.
It's fine to use PushInt() for integer numbers.


> (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?

Argh.. yes, incrementing a double in a loop may be inaccurate. It may
not matter in this specific case, but in general it is unsafe. So if
possible (A) should be preferred. Casts should be C++ casts, that would
be static_cast(i), to be able to grep for them more easily. All
old code doesn't use them though.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpttoTOaNY7O.pgp
Description: PGP signature

Re: [sc-dev] Implementation details for FDIST

[Eike Rathke]

Hi,

On Sunday, 2009-04-19 20:35:09 +0200, Eike Rathke wrote:

> > I can set the result to 0 or set "illegal argument" or perhaps set  
> > "infinity". Please decide.
> 
> I think letting the calculation just run into an error the same as
> occurs for the expression =0^-1 in ScInterpreter::ScExp() is fine, which
> should result in #NUM! being displayed.

Blah, that's of course ScPow() and not ScExp().

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgp441LJXtqRg.pgp
Description: PGP signature

Re: [sc-dev] Implementation details for FDIST

[Eike Rathke]

Hi Regina,

On Monday, 2009-04-13 22:42:07 +0200, Regina Henschel wrote:

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

For clarification: we're talking about ODF FDIST here, as opposed to
LEGACY.FDIST

> (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.

So it should mention to return an error in that case.

> For x<0 it defines that the return value is 0. For x>=0 it  
> defines it with a term which has a subterm x^(r1/2-1). And x^(-1/2) is  
> not defined for x=0.
> I can set the result to 0 or set "illegal argument" or perhaps set  
> "infinity". Please decide.

I think letting the calculation just run into an error the same as
occurs for the expression =0^-1 in ScInterpreter::ScExp() is fine, which
should result in #NUM! being displayed.


> (2)
> The algorithm is not stable for large values of the degrees of freedom.  
> [...]
> 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"?

No idea.

> Please decide about a restriction.

I will bring that to the attention of the OASIS committee. I'm all for
introducing the restriction.

Thanks
  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpArdsRJU7Sk.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

chiming in late on this..

On Wednesday, 2009-04-08 16:02:31 +0200, Regina Henschel wrote:

> Leonard Mada schrieb:
>> I would suggest DISTF().
>
> It would be short and reflects the change in tail. But I worry, that  
> people will not remember which one is 'right tail' and which one is  
> 'left tail'. Therefore I like Jaron's proposal FDISTL more.

Which also gives the user a hint when looking at the list of functions
that there are two functions, FDIST and FDISTL, where maybe one may fit
purpose better than the other.

>  It adds the benefit that all distribution
>> functions could be grouped at some point under a DIST...() name.
>>
>> DISTGAMMA()
>> DISTPOISSON()
>> DISTGAUSS() (reluctantly DISTNORM)
>
> It is not possible to rename the existing ones.

Actually it would be possible to rename functions in the UI to whatever
we liked. However, users are used to certain names, especially for
functions that exist in other products as well.

> But such names could be  
> introduced only in addition. That would not only affect Calc's  
> interpreter but all export filters too.

Only filters that export textual function names like the SYLK file
format. ODF and MOOXML function names are already defined separately.
Having additional alias names for certain functions would be possible,
needed some work to display those in the function wizard, but after
having entered a formula expression or when loading or importing
a document of course only one name per function could be displayed.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgp3al8d4BiPc.pgp
Description: PGP signature

Re: [sc-dev] signaling domain error in acosh

[Eike Rathke]

Hi Regina,

On Monday, 2009-04-06 10:11:43 +0200, Regina Henschel wrote:

> 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

Nice.

> double SAL_CALL rtl_math_acosh( double fX ) SAL_THROW_EXTERN_C()
> {
> double fZ = fX - 1.0;

It might be necessary to declare fZ as volatile here. We already had
such a case that the gcc compiler attempted to overoptimize things, see
comments in rtl_math_log1p().

> if ( fX == 1.0)
> return 0.0;
> else if (fX < 1.1)
> return rtl_math_log1p(fZ+sqrt(fZ*fZ+2.0*fZ));
> else if ( fX < 1.25e7)
> return log(fX+sqrt(fX*fX-1.0));
> else
> return log(2.0*fX);
> }
>
> The function acosh is not defined for x<1. The function ScArcCosHyp()  
> pushes an IllegalArgument and do not call acosh in that cases.
>
> Do I need any kind of error handling in my rtl_math_acosh? The function  
> acosh might be called from somewhere else, not only from ScArcCosHyp.

Yes, please return a NaN in that case:

double fResult;
rtl::math::setNan( &fResult );
return fResult;

Calc's interpreter will handle a NaN result automatically.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpTIquIQWL72.pgp
Description: PGP signature

Re: [sc-dev] TortoiseSVN and CrLf

[Eike Rathke]

Hi Regina,

On Wednesday, 2009-03-25 21:58:46 +0100, Regina Henschel wrote:

> 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.

That would be only for the file's content, which if your editor doesn't
fiddle around with line ends isn't necessary.

> 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?

No, don't bother. Applying such a patch as is doesn't give me problems.
It might when using other tools and/or Windows, but I don't, so ...

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp9km3lnnyKH.pgp
Description: PGP signature

[sc-dev] TortoiseSVN and CrLf (was: Move ERF and ERFC from scaddins to sal)

[Eike Rathke]

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. 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?

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpQy9U8ZDKTY.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Sunday, 2009-03-22 22:31:08 +0100, Regina Henschel wrote:

> I have now build CWS odff06. I have regenerated patches to move ERF and  
> ERFC from scaddins to sal, now based on odff06.  
> http://www.openoffice.org/issues/show_bug.cgi?id=97091
> Please have a look.

Much appreciated.

> 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
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpFFwRnKolIZ.pgp
Description: PGP signature

Re: [sc-dev] Excel 2003 XML export

[Eike Rathke]

Hi Niklas,

On Wednesday, 2009-03-18 14:05:45 +0100, Niklas Nebel wrote:

 That's http://qa.openoffice.org/issues/show_bug.cgi?id=96018
>>> We should consider to drop that filter completely...
>>
>> +1
>>
>> Objections, anyone?
>
> We'd still have the same kind of issues with any user-defined XSLT  
> filters. We just wouldn't know it.

True. A good approach IMHO would be to have the "Save in ODF
1.0/1.1/1.2/..." option available in the Save dialog, additionally to
Tools->Options->Load/Save, and have it defaulted to certain values for
registered filters.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgphUxeVdEreP.pgp
Description: PGP signature

Re: [sc-dev] Issue #5930 - Engineering notation

[Eike Rathke]

Hi Frédéric,

On Tuesday, 2009-03-17 20:07:46 -0400, Frédéric Courchesne wrote:

> I am looking for engineering notation in Calc for about 5 years!!!
> Issue 5930 has been opened in 2002 and is not closed yet:
> http://www.openoffice.org/issues/show_bug.cgi?id=5930
> 
> I would like to participate and do my best to implement this feature.

Welcome! Scratching the own itch is the best one can do :-)

> I am actually reading the developer's guide to help me get started.

The Developer's Guide might be overkill for implementing this feature ...

> If
> you have any advice where I should look first (in source code), feel
> free to respond!

The number formatter source is in svtools/source/numbers/
The format code scanner (zforscan.cxx) would had to detect the special
usage of leading # characters in scientific format codes, and the
formatter (zformat.cxx) create the display string accordingly.

However, there's one obstacle: the property couldn't be stored in the
current ODF file format, if I'm not mistaken. That would need an
accepted proposal for one of the next OASIS committee drafts, but the TC
is busy with getting ODF 1.2 ready.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpVDOm2yHUuQ.pgp
Description: PGP signature

[sc-dev] Excel 2003 XML export (was: [sc-dev] How to export expanded LOGNORMDIST to Excel)

[Eike Rathke]

Hi Daniel,

On Wednesday, 2009-03-18 09:39:51 +0100, Daniel Rentz wrote:

>> That's http://qa.openoffice.org/issues/show_bug.cgi?id=96018
>
> We should consider to drop that filter completely...

+1

Objections, anyone?

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpfUK9af7E6v.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Wednesday, 2009-03-18 12:25:32 +0100, Regina Henschel wrote:

> For the file token.cxx in formula/source/core/api I get an odd patch.  
> The patch includes the function  
> FormulaMissingContext::AddMissingExternal( FormulaTokenArray *pNewArr )  
> although there is nothing changed. (starting around line 1007)
>
> As far as I see, there are DOS line ends in that part. My editor PSPad  
> autodetects DOS mode for this file. Having only UNIX line ends, it  
> autodetects UNIX correctly.
>
> What to do? Remove the lines from the patch? Or use the patch as it is  
> generated?

Best to remove DOS line ends from your sources before creating patches.

Which cws/milestone is your patch based on? I already removed that
rubbish in an earlier CWS that was integrated. In CWS odff06 based on
m43 there are no DOS line ends at that place. Please work on the odff06
source base, if possible.

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpVQwJeF0vHi.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Tuesday, 2009-03-17 22:15:48 +0100, Regina Henschel wrote:

>> 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.

More a kind of backwards-compatibility decision.. you would file a "my
3.0 can't read 3.2 document" issue, wouldn't you? ;-)

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpfiETutUQJ5.pgp
Description: PGP signature

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

[Eike Rathke]

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


> If OOo is set to save in "odf1.1", the cases with parameter count <= 3  
> are opened with formulas, only the cases with parameter count=4 give an  
> error and the formulas are stripped. The error log says for example
> GRUND: Ungültiger Wert
> WERT: =LOGNORMDIST(0.6,R[-1]C,R[-2]C,R[-3]C)
> I think that is the correct behaviour.

Yes, it is.


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

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

> {
> pNewArr->AddOpCode (ocSep );
> pNewArr->AddDouble( 1.0 );  // 3rd, standard  
> deviatioen = 1.0
> }
> break;
> 
>
> If OOo is set to save to odf1.2, then I get the transformation
> =LOGNORMDIST(0,6;3) --> =LOGNORMDIST(0,6;3;1)
> That is undesirable. It is contrary to the new feature, that the  
> parameter is optional.

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

> 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 ;-)

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpJ1ExIAIpWV.pgp
Description: PGP signature

Re: [sc-dev] About compile's error.

[Eike Rathke]

Hi maoyg,

On Sunday, 2009-03-15 02:30:48 +0800, maoyg wrote:

> "build debug=t"
> [... multiple definitions of symbol ...]

See Oliver's answer on the d...@ooo list.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpu8LYTPr7QT.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Friday, 2009-03-13 22:20:35 +0100, Regina Henschel wrote:

> 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.

Not necessarily. They might use OOo and just have to export to Excel for
some poor business partner or school teacher ... ;)  Besides that, do
you remember every function you used in a complex spreadsheet you built
over the last 3 years?

> 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?  

Yes, should be done for backward compatibility.

> If you agree, that in cases saving to old OOo-formats the missing second  
> and third parameters should be added,

Not only the old 1.0/1.1 format, but also the new 1.2 format using ODFF,
so that a 3.0/3.1 will be able to read it.

> where is the place to do it?

That's now in formula/source/core/api/token.cxx
Take a look at these methods:

1. MissingConvention::isRewriteNeeded()
   Add the OpCode to the unconditional switch case.

2. FormulaMissingContext::AddMoreArgs()
   Add a new case for the OpCode to the switch. Note that mnCurArg is
   0-based and indexes the last argument passed to the function.

FormulaMissingContext::AddMissing() is only needed if a new version
allows missing arguments between arguments, such as in FOO(1;;3) where
the second parameter's argument is missing.


>> [... Excel export ...]
>> 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.

Yes, that's true for OOo and hopefully others interpreting the ODF
formulas, so when writing ODF all parameters should be preserved.

However, when writing Excel file formats we have to keep in mind that
- for binary file formats Excel simply crashes if a function has more
  arguments than parameters expected
- for XML file formats Excel in such cases strips away the formula and
  writes only the result to the cell, which when changing values the
  formula depended on will give a wrong result again.

Both cases IMHO can be resolved satisfactorily only if the function's
expression is replaced with a NA() call that generates an error in the
target.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpXACp10wVID.pgp
Description: PGP signature

[sc-dev] CWS odff06 for ODFF related work

[Eike Rathke]

Hi,

I created CWS odff06 based on DEV300_m43 for work related to the ODF
formula specification, targeted to OOo3.2, see
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fodff06

Please develop new patches for the spreadheet functions' interpreter
area in an up-to-date tree of that CWS.

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpKolj1Widvq.pgp
Description: PGP signature

Re: [sc-dev] Multiline formulae support

[Eike Rathke]

Hi William,

On Thursday, 2009-03-05 23:47:49 +, William S Fulton wrote:

> Well, I finally found some time to get back to this

Good news! :)

> Is now the right  time to set up a CWS as mentioned above or are there
> any more  suggestions for improvement?

I just created CWS calcmultiline based on m42 and will apply the patch
and build install sets, stay tuned.

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpHTlZs6zjku.pgp
Description: PGP signature

Re: [sc-dev] OpenFormula Implementation: UNICODE(Text T) and UNICHAR(Number N)

[Eike Rathke]

Hi,

On Thursday, 2009-02-26 12:39:47 +0100, Eike Rathke wrote:

> For UNICHAR() a conversion from Unicode point to UTF-16 is needed, for
> this use the OUString ctor
> 
> OUString( const sal_Char * value, sal_Int32 length, rtl_TextEncoding 
> encoding,
>   sal_uInt32 convertFlags = OSTRING_TO_OUSTRING_CVTFLAGS );

Oops, sorry, this is nonsense. Instead, use

OUString( sal_uInt32 const * codePoints, sal_Int32 codePointCount );

with a codePointCount of 1.

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpYTpNGjSWmr.pgp
Description: PGP signature

Re: [sc-dev] OpenFormula Implementation: UNICODE(Text T) and UNICHAR(Number N)

[Eike Rathke]

Hi Chengbiao,

On Thursday, 2009-02-26 17:21:45 +0800, Chengbiao Tan wrote:

> These days I am trying to implementate two related OpenFormula 
> UNICODE(Text T) and UNICHAR(Number N).

Nice to hear, welcome!

> According to the OOo native String class is implementated in UNICODE, 
> so I can use the String class's utilities to complete these functions.

Well, yes and no ;-)  While the current internal representation uses
class String (which actually is a define for class UniString), it uses
UTF-16 encoding. To implement the UNICODE() function for all required
Unicode points up to U+10, a method of class OUString comes handy:

sal_uInt32 iterateCodePoints( sal_Int32 * indexUtf16,
  sal_Int32 incrementCodePoints = 1 ) const;

For a description of this method see rtl/ustring.hxx

class String and OUString have conversion ctors for each other and use
the same underlying data structure, so there's no problem using them.

For UNICHAR() a conversion from Unicode point to UTF-16 is needed, for
this use the OUString ctor

OUString( const sal_Char * value, sal_Int32 length, rtl_TextEncoding 
encoding,
  sal_uInt32 convertFlags = OSTRING_TO_OUSTRING_CVTFLAGS );

Use rtl_TextEncoding RTL_TEXTENCODING_UCS4 with a value buffer of one
sal_uInt32 casted down to sal_Char*, length sizeof(sal_uInt32).

> Would any one gives me some ideas about the implementation of these 
> functions. thanks! 

Hope that helps.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpTnVKbMNvbm.pgp
Description: PGP signature

Re: [sc-dev] Open Office

[Eike Rathke]

Hi Romke,

On Saturday, 2009-01-31 10:29:15 +, Romke jan Prins wrote:

> I've just downloaded open office from your website. Last week i did
> the same. The installation program asked for an installation-code.
> I've send a text message to the right number. I got a few text
> messages back, but still no installation code.

It seems you didn't download the original OpenOffice.org suite. The
original download does not ask for an installation code and you don't
have to send messages to whatever numbers. OOo is free and open source
software.

> What to do next?
> I don't know what i have to do. 

Surf to http://download.openoffice.org/ and download the original.

  Eike

P.S.: As you're not subscribed to the mailing list you were posting to,
you will miss replies that are directed to the list only. When answering,
please reply only to the list (Reply-To header is set), not to my
personal account. Thanks.

Btw, this mailing list is the OOoCalc spreadsheet developers' mailing
list, general discussion is better suited on the disc...@openoffice.org
mailing list, see also http://www.openoffice.org/mail_list.html

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpRn5oHXrLlS.pgp
Description: PGP signature

Re: [sc-dev] [almost] Crasher is alive for > 3 years - issue 55266

[Eike Rathke]

Hi Kirill,

On Tuesday, 2009-01-27 22:13:50 +0300, Kirill Palagin wrote:

> Please see http://www.openoffice.org/issues/show_bug.cgi?id=55266 - Calc  
> allocates 1.1GB of RAM for 81kb file with DataPilot..

That may be fixed with
http://qa.openoffice.org/issues/show_bug.cgi?id=93998
in CWS koheidatapilot02 integrated to DEV300_m37, please check.

> Strictly speaking  
> this is not a crash, but in order to complete the task user needs to  
> have at least 1.5GB of RAM, otherwise machine (not just Office) will  
> appear unresponsive, forcing user to power it off and loose data in all  
> applications.

Having to power off the machine under such circumstances I'd consider an
issue of the operating system though..

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpxkSGQVpwtJ.pgp
Description: PGP signature

Re: [sc-dev] OpenFormula Implementation: numbervalue(Text X; Text DecimalPoint)

[Eike Rathke]

Hi,

On Friday, 2009-01-09 15:31:38 +0800, ��?�??�?? wrote:

> I am trying to implementate OpenFormula 
> NUMBERVALUE(Text X; Text DecimalPoint).

Nice :)  Lvyue already said there's someone who wanted to work on that.

> 1) According to the OpenFormula specification, 
> formula NUMBERVALUE similar to formula VALUE,
> formula NUMBERVALUE is locale independat, and 
> formula VALUE is locale dependant. 
> I can reuse much of the formula VALUE 
> source code, with little changes. I have only a 
> little knowleges about locale, so i need some help.
> 
> 2) OpenFormula specification and mailing list discusion
> http://lists.oasisopenorg/archives/office-formula/200703/msg00104.html

[btw, do you re-type URLs instead of copying? that actually is
http://lists.oasis-open.org/archives/office-formula/200703/msg00104.html ]

> have some different arguments, and i think
> the mailing list discusion is more correct.

Me too.. seems there was never a conclusion drawn in the discussion, the
latest mail I sent was
http://lists.oasis-open.org/archives/office-formula/200704/msg0.html

The definition currently given in the draft is not correct.

> Would some
> one gives some advices. thanks! : )

Well, as that isn't clarified the function should not be implemented
right now. Thanks for the heads-up. Maybe you could find something
different to work on?

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgph4xg3XKCr1.pgp
Description: PGP signature

[sc-dev] Would you like to be a FOSDEM 2009 speaker for Calc?

[Eike Rathke]

Hi,

Yes, this is on short notice. In case you haven't seen it already on
d...@ooo or other mailing lists:

OOo has a DevRoom and stand on FOSDEM 2009, the Free and Open Source
Software Developers' European Meeting, February 7+8, which is
approaching sooner than it appears.. see http://fosdem.org/2009/ and
http://wiki.services.openoffice.org/wiki/Conferences/FOSDEM/2009

This is a chance for someone deeply involved with Calc development to
hold a speach or presentation, do some hands-on hacking or whatever
comes to mind with a technically developer-oriented audience.

The DevRoom gives us (the OOo team) the opportunity to setup our own
schedule, but of course we need to do this ASAP, to get listed on the
official schedule we would need a first proposal for your talk until
_Saturday_, send it to Juergen, for details see below.

Thanks
  Eike

Juergen Schmidt sent out a call for papers, I'm including it here:

FOSDEM - the Free and Open Source Developer's European Meeting - is 
nearly upon us. FOSDEM is the most developer-focused FOSS conference, 
and will take place in Brussels, Belgium on 6th/7th February (not 
forgetting the FOSDEM beer event on the Friday night  :) . Geeks from 
all the major FOSS projects are expected to be there - including 
OpenOffice.org.

If you are an experienced OpenOffice.org developer, we need your help!

OpenOffice.org will have again a DevRoom at FOSDEM. The main goal of the 
DevRoom is to attract developers to work on and with OpenOffice.org. We 
want to show developers that there is nothing magic about OpenOffice.org 
development, and that our active and enthusiastic developer community is 
keen to help newcomers.

We want to help developers get started on the code - by explaining how 
the source code is structured and how our build environment works. We're 
also keen to show developers how to integrate OpenOffice.org in their 
own applications, using interfaces, APIs, components, etc. We want to 
encourage developers to produce exciting new extensions for OpenOffice.org.

If you are able to share your in-depth technical knowledge and 
enthusiasm then please get in touch without delay. We are looking for 
people who can:

- give a 45 minute talk; or
- run 90 or 120 minute workshops

Please send your proposals (see below) to juergen.schmidt (at) sun.com 
as soon as possible - by the end of this week (latest Saturday 10th).

Make it your New Year's Resolution to recruit a new developer in 2009 - 
and help us start the ball rolling at FOSDEM in February.

Proposals
=
Your proposal should include
- a title
- a short abstract
- your full name
- a short bio of you and ideally your role in the OpenOffice.org project
- request for sponsorship (travel, lodging)

We know that we are again a little bit late this year and that it is 
short-time. But we promise to improve it next year ;-)


Thanks in advance

Juergen


pgpfWcfTd77vI.pgp
Description: PGP signature

Re: [sc-dev] accuracy of ASINH and ACOSH

[Eike Rathke]

Hi Regina,

Happy New Year!

On Saturday, 2008-12-27 23:11:26 +0100, Regina Henschel wrote:

> please see issue 97605 and decide, where you want to have the changes.

Same as for atanh() and those, a C99 replacement function in rtl::math
would do fine.

Thanks
  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgp78uQHrOan7.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Monday, 2008-12-22 00:09:02 +0100, Regina Henschel wrote:

> Merry Christmas and a happy New Year to you.

Well, yes, same to you!

>>> (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.

Of course. The "test, which cut value to use and how many summands are
needed, is tedious" however really makes me believe we should go for #1.

>   I think #1
>> would be best, for simplicity.
>
> I have used (1)

Fine.

>  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.

Great. If simplicity doesn't have drawbacks this is the way to go.

>>> 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,

No magic involved..  Having added them as rtl_math_...() functions
exported as "C" makes them usable also in plain C programs (remember,
sal is part of the UDK/SDK). The inlines in math.hxx add namespace for
C++. The .map entries specify the functions are to be exported from the
sal library, making them available for linkage with other modules. The
section UDK_3.9 is for symbol versioning, as the UDK may be used
independently of OOo or with different releases of OOo it might happen
that different versions of libsal are around, this tells the runtime
linker what to look for. Well, certainly not an accurate description,
but basically that's what it is about.

> I have tried to mimic them.

Looks good from a first glance.

> Perhaps when  
> code freeze is over, you have some time to explain it?

The benefits of vacation are that one can do whatever one pleases :-)

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

Thanks, I'll schedule them for OOo3.1 and add a dependency to the
changes in sal.

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

Never ending these things..

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpfxYybleOWW.pgp
Description: PGP signature

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

[Eike Rathke]

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 ;-)  I think #1
would be best, for simplicity. 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.

> 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

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the e...@sun.com account, which I use for
 mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.


pgpOwu9P8kXCK.pgp
Description: PGP signature

Re: [sc-dev] strange formula Err:504 with oo 3.x

[Eike Rathke]

Hi Oliver,

On Sunday, 2008-12-14 09:07:49 +0100, Oliver Brinzing wrote:

> I used Vista with oo 3.1 DEV300m37 Build 9371 and oo 3.0.1 DEV300m12 Build 
> 9368
> 'Feiertage' point to $Input.$D$6:$E$21 if i open F3 on sheet 'Input', but 
> points to
> $Input.$D$6:Calendar.$E$21 if i open on sheet 'Calendar' !

That's http://qa.openoffice.org/issues/show_bug.cgi?id=96529 and fixed
in OOO300_m13, clone will be integrated to DEV300_m38:
https://tools.services.openoffice.org/EIS2/cws.ShowCWS?Id=7697

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgppCavBj4Eop.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Tuesday, 2008-12-09 20:07:53 +0100, Eike Rathke wrote:

> > 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?
> 
> No, I simply was busy with getting a few CWSs rfQA, and that made my
> schedule slip. I'll see if I can include it tomorrow. If any problem
> would show up we'll have to postpone that though, the feature freeze
> probably will not be prolongued and the CWS will have to be ready by
> Thursday.

Just a status update: in CWS odff05 I included the patch and necessary
changes to write the optional parameter of GAMMADIST to file if omitted,
so that earlier releases can interpret it properly. Also did the same
for Excel export, as that expects all parameters being specified.

For further formula work I suggest you update your CWS odff05 to the
current revision and base future patches on that, until after
integration we'll have a new CWS opened.

Thanks
  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpymK6sMYvy2.pgp
Description: PGP signature

Re: [sc-dev] strange formula Err:504 with oo 3.x

[Eike Rathke]

Hi Oliver,

On Saturday, 2008-12-13 11:38:07 +0100, Oliver Brinzing wrote:

> i created an issue with attachment
> http://www.openoffice.org/issues/show_bug.cgi?id=97225

Didn't encounter any problem here, see issue.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpq8GcBEKuV1.pgp
Description: PGP signature

Re: [sc-dev] Re: [allsvn] r265030 - cws/ooxml02/offapi/com/sun/star/sheet

[Eike Rathke]

Hi Kohei,

On Tuesday, 2008-12-09 13:20:48 -0500, Kohei Yoshida wrote:

> > >> Again, modularization. We want to separate the Excel filter from the 
> > >> "sc" module, and opcode mapping is part of it.
> > > 
> > > But VBA is not part of the filter, and we need that for VBA.  The filter
> > > is merely re-using it.
> > > 
> > > There is a fine line between modularization and reusability.
> > 
> > To share something between the filter and VBA, it doesn't have to become 
> > part of the Calc core.
> 
> On the contrary, I believe this opcode map does belong in the core.
> Doing it any other way, especially a duplication of opcode in various
> places, is a kludge.

The new mapping actually would duplicate things once the resource
strings differed from the Calc English ones, if I understood that
correctly. So far the core did not need to know any Excel specific name
mappings, those were setup by the filter using the token API. I'm
probably repeating things, but we spent quite some effort to separate
that.

Btw, in the code committed, ScCompiler::InitSymbolsEnglishXL() uses
ScGrammar::GRAM_ENGLISH, I think that should had been
ScGrammar::GRAM_ENGLISH_XL_A1 instead.

> While it's important to separate out things from
> the core, there are still things that *do* belong in the core.
> 
> > This is now the second change surfacing from ooxml02 which runs contrary 
> > to the separation of filter and core. 
> 
> Once again, VBA is not a filter, and I don't see how that would
> contradicts the separation of filter and core.

Wouldn't it be possible to let VBA create a mapping similar to how the
filter does it, by using ScCompiler::CreateOpCodeMap() and
ScCompiler::SetFormulaLanguage()? Btw, where is the difference between
names VBA uses and names Excel uses in MOOXML? If there isn't any,
wouldn't it be "natural" to share the filter's name mapping with VBA?

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgpipRKamWw5y.pgp
Description: PGP signature

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

[Eike Rathke]

Hi Regina,

On Tuesday, 2008-12-09 16:33:01 +0100, Regina Henschel wrote:

> 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?

No, I simply was busy with getting a few CWSs rfQA, and that made my
schedule slip. I'll see if I can include it tomorrow. If any problem
would show up we'll have to postpone that though, the feature freeze
probably will not be prolongued and the CWS will have to be ready by
Thursday.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


pgp6abZZ9NQ1S.pgp
Description: PGP signature

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

[Eike Rathke]

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.

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the [EMAIL PROTECTED] account, which I use 
for
 mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] 
Thanks.


pgpRUEzqbiPOn.pgp
Description: PGP signature

Re: [sc-dev] Implement expm1 and log1p

[Eike Rathke]

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

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the [EMAIL PROTECTED] account, which I use 
for
 mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] 
Thanks.


pgpNDF07zKR1x.pgp
Description: PGP signature

[sc-dev] Performance (was: [sc-dev] Informing users about ODFF)

[Eike Rathke]

Hi Leonard,

On Friday, 2008-11-28 01:25:25 +0200, Leonard Mada wrote:

>> I can't give a timeline for further work on ODFF implementation.
>> I myself will focus on performance.
>
> Does this mean that issue 89976 gets addressed?
> http://www.openoffice.org/issues/show_bug.cgi?id=89976

Yes.

> I noticed some time ago that you started profiling. Did you reach any  
> conclusions?

At least some starting point, see
http://wiki.services.openoffice.org/wiki/Calc/To-Dos/Performance/Specific_Bottlenecks#Sorting_values_within_functions

;-)

  Eike

-- 
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the [EMAIL PROTECTED] account, which I use 
for
 mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] 
Thanks.


pgpM5Af1ZsXeO.pgp
Description: PGP signature