Change in core[master]: fdo#56124 add calc functions IFERROR and IFNA as in ODFF1.2

[Winfried Donkers]

This time to the ML as well...



Winfried


> -----Oorspronkelijk bericht-----
> Van: Winfried Donkers
> Verzonden: donderdag 6 december 2012 12:52
> Aan: 'erack at redhat.com'
> Onderwerp: RE: Change in core[master]: fdo#56124 add calc functions
> IFERROR and IFNA as in ODFF1.2
> 
> Hi Eike,
> 
> > Van: Eike Rathke (via Code Review) wrote: donderdag 22 november 2012
> > 23:31
> 
> > I suggest you take a look at the implementation of ocIf and use a
> > similar approach with only one conditional path instead of two, for
> > which the condition is calculated from the expression's result whether
> > it is an error or not and then a jump is executed or not. There is
> > some special code in the compiler to calculate jump paths (lookout for
> > ocIf), and handling is different from normal functions in the
> > interpreter. Feel free to ask for details and pointers on the mailing list.
> 
> I agree that my submitted patch is inefficient when it always calculates both
> arguments.
> The simple examples of the function disfunctioning (I tested lots of
> arguments, but never tried direct calculations as an argument) could be
> remedied, but it would stay an inefficient function (sometimes even less
> efficient than IF(X;X;Y)).
> 
> So I followed your suggestion to work along the lines of ScIfJump/ocIf.
> These last 2 weeks I have not been able to get that working properly.
> To finally find out what goes wrong, I copied the contents of SCIfJump() into
> ScIfError(), made ocIfError do the same as ocIf (except in lotus/excel filter
> files) and gave IFERROR() 3 arguments (just as IF()).
> It still doesn't work: IFERROR(X;Y;Z) always returns Y, regardless of the value
> of X. That is, if X produces an error (or Y, or Z), the error is returned.
> 
> What am I missing/messing up?
> I can upload the diff file to the bug, but possibly you can give some pointers
> without them.
> 
> Winfried