Re: [Bug-apl] Scan operator has strange behaviour

2014-03-21 Thread Elias Mårtenson
All right. I think I'm starting to understand the reasoning that went into the spec as written. Thank you for giving me the necessary pointers. Now, that leads me inevitably to the obvious followup question: Is there a way to run "my" version of this operator? Regards, Elias On 21 March 2014 21

Re: [Bug-apl] Scan operator has strange behaviour

2014-03-21 Thread Jay Foad
On 21 March 2014 13:39, Elias Mårtenson wrote: > On 21 March 2014 19:55, Jay Foad wrote: >> Associativity matters because the last item of the result is 3>1>2, >> which means 3>(1>2). But your explanation would lead to (3>1)>2 as the >> last item. > > > You are right, but that can be addressed by

Re: [Bug-apl] Scan operator has strange behaviour

2014-03-21 Thread Elias Mårtenson
On 21 March 2014 19:55, Jay Foad wrote: > >\3 1 2 > 3 1 1 > > I think your explanation of scan would lead to the result 3 1 0. > > Associativity matters because the last item of the result is 3>1>2, > which means 3>(1>2). But your explanation would lead to (3>1)>2 as the > last item. > Yo

Re: [Bug-apl] Scan operator has strange behaviour

2014-03-21 Thread Jay Foad
On 21 March 2014 11:48, Elias Mårtenson wrote: > OK, I understand your explanation, and I have to say that the spec seems to > be a bit over-specified here. My (simplistic?) understanding of the > backslash operator was that it simply applied the given function on the > first two elements, add the

Re: [Bug-apl] Scan operator has strange behaviour

2014-03-21 Thread Elias Mårtenson
On 19 March 2014 22:25, Kacper Gutowski wrote: > On 2014-03-19 21:22:04, Elias Mårtenson wrote: > > This can't possibly be correct? > > But it is! > Let me just quote relevant excerpt of ISO 13751: > OK, I understand your explanation, and I have to say that the spec seems to be a bit over-specif

Re: [Bug-apl] Scan operator has strange behaviour

2014-03-21 Thread Elias Mårtenson
On 20 March 2014 11:31, Kacper Gutowski wrote: > On 2014-03-19 23:16:32, Elias Mårtenson wrote: > > I see. So the way I see it, I should actually use 2 OP/X instead? I > seems to > > actually do what I expected. > > It if does what you need then sure, but it's a very different thing > than scan:

Re: [Bug-apl] Scan operator has strange behaviour

2014-03-19 Thread Kacper Gutowski
On 2014-03-19 23:16:32, Elias Mårtenson wrote: > I see. So the way I see it, I should actually use 2 OP/X instead? I seems to > actually do what I expected. It if does what you need then sure, but it's a very different thing than scan: ,\'abcd' a ab abc abcd 2,/'abcd' ab bc cd -

Re: [Bug-apl] Scan operator has strange behaviour

2014-03-19 Thread Elias Mårtenson
I see. So the way I see it, I should actually use 2 *OP*/X instead? I seems to actually do what I expected. Regards, Elias On 19 March 2014 22:25, Kacper Gutowski wrote: > On 2014-03-19 21:22:04, Elias Mårtenson wrote: > > This can't possibly be correct? > > But it is! > Let me just quote rele

[Bug-apl] Scan operator has strange behaviour

2014-03-19 Thread Elias Mårtenson
The following code returns the expected results: * {⍺+⍵}\⍳10* 1 3 6 10 15 21 28 36 45 55 However, if I also print all the calls, I get a lot more evaluations of the function than expected: *{(⍺+⍵)⊣⎕←('[',(⍕⍺),',',(⍕⍵),']')}\⍳10* [1,2] [2,3] [1,5] [3,4] [2,7] [1,9] [4,5] [3,9] [2,12]