Re: converting Calc functions to jump functions

2016-06-06 Thread Eike Rathke
Hi Winfried, On Monday, 2016-06-06 10:30:25 +0200, Winfried Donkers wrote: > > Apart from that, aCode.Jump( pJump[ nIdx ], pJump[ pJump[ 0 ] ] ) looks > > wrong to me, pJump[0] returns an offset into the RPN array, which can't be > > used as an index for another pJump. > > I changed the code in

RE: converting Calc functions to jump functions

2016-06-06 Thread Winfried Donkers
Hi Eike, > > And that is where I get stuck. > > I can imagine.. I wasn't surprised either ;-) > > > The first argument is on the stack, i.e. GetStackType() returns a type > and ScInterpreter::sp is 1. > > When I jump to the next argument to be evaluated, with aCode.Jump( > pJump[ nIdx ], pJump

Re: converting Calc functions to jump functions

2016-06-03 Thread Eike Rathke
Hi Winfried, On Thursday, 2016-06-02 09:18:51 +0200, Winfried Donkers wrote: > I started converting the new Calc functions IFS and SWITCH to jump functions. > I experience a problem where the functions IFS and SWITCH differ from the > other jump functions (IF, CHOOSE, IFERROR, IFNA). > The other

converting Calc functions to jump functions

2016-06-02 Thread Winfried Donkers
Hi Eike, I started converting the new Calc functions IFS and SWITCH to jump functions. So far, the general part has been done. I experience a problem where the functions IFS and SWITCH differ from the other jump functions (IF, CHOOSE, IFERROR, IFNA). The other jump functions do 1 evaluation (of