Partition behaviour in GNU APL and Dyalog APL
In Dyalog APL there is ⎕ML
which changes how partition operates.
When ⎕ML←0
(5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
┌→─────────────────────┐
│ ┌→────┐ ┌→────┐ ┌→─┐ │
│ ↓ 1 2│ ↓ 3 4│ ↓ 5│ │
│ │ 6 7│ │ 8 9│ │10│ │
│ │11 12│ │13 14│ │15│ │
│ │16 17│ │18 19│ │20│ │
│ │21 22│ │23 24│ │25│ │
│ └~────┘ └~────┘ └~─┘ │
└∊─────────────────────┘
For the same statement (5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
in GNU APL
┏→━━━━━━━━━━━━━┓
↓┏→┓ ┏→┓ ┏→┓ ┃
┃┃1┃ ┃3┃ ┃5┃ ┃
┃┗━┛ ┗━┛ ┗━┛ ┃
┃┏→┓ ┏→┓ ┏→━┓┃
┃┃6┃ ┃8┃ ┃10┃┃
┃┗━┛ ┗━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃11┃ ┃13┃ ┃15┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃16┃ ┃18┃ ┃20┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃21┃ ┃23┃ ┃25┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┗∊━━━━━━━━━━━━━┛
Dyalog APL also does this when ⎕ML←3
Is there a way to alter how GNU APL behaves to obtain the same behaviour?
arrays split apl dyalog gnu-apl
add a comment |
In Dyalog APL there is ⎕ML
which changes how partition operates.
When ⎕ML←0
(5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
┌→─────────────────────┐
│ ┌→────┐ ┌→────┐ ┌→─┐ │
│ ↓ 1 2│ ↓ 3 4│ ↓ 5│ │
│ │ 6 7│ │ 8 9│ │10│ │
│ │11 12│ │13 14│ │15│ │
│ │16 17│ │18 19│ │20│ │
│ │21 22│ │23 24│ │25│ │
│ └~────┘ └~────┘ └~─┘ │
└∊─────────────────────┘
For the same statement (5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
in GNU APL
┏→━━━━━━━━━━━━━┓
↓┏→┓ ┏→┓ ┏→┓ ┃
┃┃1┃ ┃3┃ ┃5┃ ┃
┃┗━┛ ┗━┛ ┗━┛ ┃
┃┏→┓ ┏→┓ ┏→━┓┃
┃┃6┃ ┃8┃ ┃10┃┃
┃┗━┛ ┗━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃11┃ ┃13┃ ┃15┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃16┃ ┃18┃ ┃20┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃21┃ ┃23┃ ┃25┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┗∊━━━━━━━━━━━━━┛
Dyalog APL also does this when ⎕ML←3
Is there a way to alter how GNU APL behaves to obtain the same behaviour?
arrays split apl dyalog gnu-apl
add a comment |
In Dyalog APL there is ⎕ML
which changes how partition operates.
When ⎕ML←0
(5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
┌→─────────────────────┐
│ ┌→────┐ ┌→────┐ ┌→─┐ │
│ ↓ 1 2│ ↓ 3 4│ ↓ 5│ │
│ │ 6 7│ │ 8 9│ │10│ │
│ │11 12│ │13 14│ │15│ │
│ │16 17│ │18 19│ │20│ │
│ │21 22│ │23 24│ │25│ │
│ └~────┘ └~────┘ └~─┘ │
└∊─────────────────────┘
For the same statement (5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
in GNU APL
┏→━━━━━━━━━━━━━┓
↓┏→┓ ┏→┓ ┏→┓ ┃
┃┃1┃ ┃3┃ ┃5┃ ┃
┃┗━┛ ┗━┛ ┗━┛ ┃
┃┏→┓ ┏→┓ ┏→━┓┃
┃┃6┃ ┃8┃ ┃10┃┃
┃┗━┛ ┗━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃11┃ ┃13┃ ┃15┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃16┃ ┃18┃ ┃20┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃21┃ ┃23┃ ┃25┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┗∊━━━━━━━━━━━━━┛
Dyalog APL also does this when ⎕ML←3
Is there a way to alter how GNU APL behaves to obtain the same behaviour?
arrays split apl dyalog gnu-apl
In Dyalog APL there is ⎕ML
which changes how partition operates.
When ⎕ML←0
(5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
┌→─────────────────────┐
│ ┌→────┐ ┌→────┐ ┌→─┐ │
│ ↓ 1 2│ ↓ 3 4│ ↓ 5│ │
│ │ 6 7│ │ 8 9│ │10│ │
│ │11 12│ │13 14│ │15│ │
│ │16 17│ │18 19│ │20│ │
│ │21 22│ │23 24│ │25│ │
│ └~────┘ └~────┘ └~─┘ │
└∊─────────────────────┘
For the same statement (5 ⍴ 1 0) ⊂ 5 5 ⍴ ⍳25
in GNU APL
┏→━━━━━━━━━━━━━┓
↓┏→┓ ┏→┓ ┏→┓ ┃
┃┃1┃ ┃3┃ ┃5┃ ┃
┃┗━┛ ┗━┛ ┗━┛ ┃
┃┏→┓ ┏→┓ ┏→━┓┃
┃┃6┃ ┃8┃ ┃10┃┃
┃┗━┛ ┗━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃11┃ ┃13┃ ┃15┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃16┃ ┃18┃ ┃20┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┃┏→━┓ ┏→━┓ ┏→━┓┃
┃┃21┃ ┃23┃ ┃25┃┃
┃┗━━┛ ┗━━┛ ┗━━┛┃
┗∊━━━━━━━━━━━━━┛
Dyalog APL also does this when ⎕ML←3
Is there a way to alter how GNU APL behaves to obtain the same behaviour?
arrays split apl dyalog gnu-apl
arrays split apl dyalog gnu-apl
edited Nov 25 '18 at 14:52
Adám
1,314718
1,314718
asked Jan 14 '15 at 5:20
alexweineralexweiner
364
364
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The short answer is no, because GNU APL follows IBM APL2 language conventions.
The core APL language was developed and perfected by the mid 1970s. However, Nested Arrays started coming a bit later, perhaps the first preliminary sneak peek implementations came out starting around 1980.
The major players at the time were IBM, I. P. Sharp Associates, STSC, and Dyalog, a relative newcomer. All nested array implementations differed in one detail or another, arguably the biggest such difference was the implementation of boxed arrays by Sharp which were the basis of the boxed array implementation found today in J.
Arguably, at the time, Mainframe IBM APL2 probably had the largest market share.
STSC would later change its name to Manugistics and the implementation would evolve into APL2000's APL+ product suite.
Both STSC and Dyalog provided some compatibility mode around the various nested array subspecies, STSC's was the )EVLEVEL system command, evolution level, and Dyalog's was ML, migration level.
In a nutshell, Dyalog's ML can be set to 0, 1, 2, or 3. From Dyalog's documentation,
ML 0
is the default native Dyalog nested array implementation
ML 1
changes the definition of monadic epsilon to be the "enlist" function, a kind of super-ravel
ML 2
swaps the definitions of the symbols used for the "first" and "mix" functions, plus presents an alternate definition of the "depth" function
ML 3
provides IBM APL2 compatibility.
Personally, I use ML 3 almost exclusively, as I programmed heavily in APL2 when mainframes were still around.
Again, GNU APL follows IBM APL2 language compatibility. One way to achieve alternate enclose behaviours is to write cover functions to emulate the specialities of other implementations.
Thanks! Maybe I should just build ⎕ML into gnuapl!
– alexweiner
Jan 15 '15 at 0:41
One of the countless religious discussion points is whether it is a Good Thing to be able to change language features on the fly. With such awesome power comes awesome responsibility and all that.
– Lobachevsky
Jan 15 '15 at 8:01
1
I would like to add that a few years ago a number of experts made a great effort to analyze the behaviour of existing APL interpreters and distilled the state of the art into the ISO/IEC 13751:2001 "Extended APL" standard, which is what GNU APL strives to follow.
– Tobia
Jan 17 '15 at 14:58
Dyalog APL's default has lately been changed to⎕ML 1
, and all new code developed by Dyalog adheres to this. Source: I work there.
– Adám
Dec 31 '15 at 19:00
From version 16.0, Dyalog APL will have both partitioning primitives available simultaneously when⎕ML←1
:⊂
is the Dyalog definition (partitioned enclose) while⊆
is the APL2 definition (partition).
– Adám
Jan 16 '17 at 19:22
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f27936301%2fpartition-behaviour-in-gnu-apl-and-dyalog-apl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The short answer is no, because GNU APL follows IBM APL2 language conventions.
The core APL language was developed and perfected by the mid 1970s. However, Nested Arrays started coming a bit later, perhaps the first preliminary sneak peek implementations came out starting around 1980.
The major players at the time were IBM, I. P. Sharp Associates, STSC, and Dyalog, a relative newcomer. All nested array implementations differed in one detail or another, arguably the biggest such difference was the implementation of boxed arrays by Sharp which were the basis of the boxed array implementation found today in J.
Arguably, at the time, Mainframe IBM APL2 probably had the largest market share.
STSC would later change its name to Manugistics and the implementation would evolve into APL2000's APL+ product suite.
Both STSC and Dyalog provided some compatibility mode around the various nested array subspecies, STSC's was the )EVLEVEL system command, evolution level, and Dyalog's was ML, migration level.
In a nutshell, Dyalog's ML can be set to 0, 1, 2, or 3. From Dyalog's documentation,
ML 0
is the default native Dyalog nested array implementation
ML 1
changes the definition of monadic epsilon to be the "enlist" function, a kind of super-ravel
ML 2
swaps the definitions of the symbols used for the "first" and "mix" functions, plus presents an alternate definition of the "depth" function
ML 3
provides IBM APL2 compatibility.
Personally, I use ML 3 almost exclusively, as I programmed heavily in APL2 when mainframes were still around.
Again, GNU APL follows IBM APL2 language compatibility. One way to achieve alternate enclose behaviours is to write cover functions to emulate the specialities of other implementations.
Thanks! Maybe I should just build ⎕ML into gnuapl!
– alexweiner
Jan 15 '15 at 0:41
One of the countless religious discussion points is whether it is a Good Thing to be able to change language features on the fly. With such awesome power comes awesome responsibility and all that.
– Lobachevsky
Jan 15 '15 at 8:01
1
I would like to add that a few years ago a number of experts made a great effort to analyze the behaviour of existing APL interpreters and distilled the state of the art into the ISO/IEC 13751:2001 "Extended APL" standard, which is what GNU APL strives to follow.
– Tobia
Jan 17 '15 at 14:58
Dyalog APL's default has lately been changed to⎕ML 1
, and all new code developed by Dyalog adheres to this. Source: I work there.
– Adám
Dec 31 '15 at 19:00
From version 16.0, Dyalog APL will have both partitioning primitives available simultaneously when⎕ML←1
:⊂
is the Dyalog definition (partitioned enclose) while⊆
is the APL2 definition (partition).
– Adám
Jan 16 '17 at 19:22
add a comment |
The short answer is no, because GNU APL follows IBM APL2 language conventions.
The core APL language was developed and perfected by the mid 1970s. However, Nested Arrays started coming a bit later, perhaps the first preliminary sneak peek implementations came out starting around 1980.
The major players at the time were IBM, I. P. Sharp Associates, STSC, and Dyalog, a relative newcomer. All nested array implementations differed in one detail or another, arguably the biggest such difference was the implementation of boxed arrays by Sharp which were the basis of the boxed array implementation found today in J.
Arguably, at the time, Mainframe IBM APL2 probably had the largest market share.
STSC would later change its name to Manugistics and the implementation would evolve into APL2000's APL+ product suite.
Both STSC and Dyalog provided some compatibility mode around the various nested array subspecies, STSC's was the )EVLEVEL system command, evolution level, and Dyalog's was ML, migration level.
In a nutshell, Dyalog's ML can be set to 0, 1, 2, or 3. From Dyalog's documentation,
ML 0
is the default native Dyalog nested array implementation
ML 1
changes the definition of monadic epsilon to be the "enlist" function, a kind of super-ravel
ML 2
swaps the definitions of the symbols used for the "first" and "mix" functions, plus presents an alternate definition of the "depth" function
ML 3
provides IBM APL2 compatibility.
Personally, I use ML 3 almost exclusively, as I programmed heavily in APL2 when mainframes were still around.
Again, GNU APL follows IBM APL2 language compatibility. One way to achieve alternate enclose behaviours is to write cover functions to emulate the specialities of other implementations.
Thanks! Maybe I should just build ⎕ML into gnuapl!
– alexweiner
Jan 15 '15 at 0:41
One of the countless religious discussion points is whether it is a Good Thing to be able to change language features on the fly. With such awesome power comes awesome responsibility and all that.
– Lobachevsky
Jan 15 '15 at 8:01
1
I would like to add that a few years ago a number of experts made a great effort to analyze the behaviour of existing APL interpreters and distilled the state of the art into the ISO/IEC 13751:2001 "Extended APL" standard, which is what GNU APL strives to follow.
– Tobia
Jan 17 '15 at 14:58
Dyalog APL's default has lately been changed to⎕ML 1
, and all new code developed by Dyalog adheres to this. Source: I work there.
– Adám
Dec 31 '15 at 19:00
From version 16.0, Dyalog APL will have both partitioning primitives available simultaneously when⎕ML←1
:⊂
is the Dyalog definition (partitioned enclose) while⊆
is the APL2 definition (partition).
– Adám
Jan 16 '17 at 19:22
add a comment |
The short answer is no, because GNU APL follows IBM APL2 language conventions.
The core APL language was developed and perfected by the mid 1970s. However, Nested Arrays started coming a bit later, perhaps the first preliminary sneak peek implementations came out starting around 1980.
The major players at the time were IBM, I. P. Sharp Associates, STSC, and Dyalog, a relative newcomer. All nested array implementations differed in one detail or another, arguably the biggest such difference was the implementation of boxed arrays by Sharp which were the basis of the boxed array implementation found today in J.
Arguably, at the time, Mainframe IBM APL2 probably had the largest market share.
STSC would later change its name to Manugistics and the implementation would evolve into APL2000's APL+ product suite.
Both STSC and Dyalog provided some compatibility mode around the various nested array subspecies, STSC's was the )EVLEVEL system command, evolution level, and Dyalog's was ML, migration level.
In a nutshell, Dyalog's ML can be set to 0, 1, 2, or 3. From Dyalog's documentation,
ML 0
is the default native Dyalog nested array implementation
ML 1
changes the definition of monadic epsilon to be the "enlist" function, a kind of super-ravel
ML 2
swaps the definitions of the symbols used for the "first" and "mix" functions, plus presents an alternate definition of the "depth" function
ML 3
provides IBM APL2 compatibility.
Personally, I use ML 3 almost exclusively, as I programmed heavily in APL2 when mainframes were still around.
Again, GNU APL follows IBM APL2 language compatibility. One way to achieve alternate enclose behaviours is to write cover functions to emulate the specialities of other implementations.
The short answer is no, because GNU APL follows IBM APL2 language conventions.
The core APL language was developed and perfected by the mid 1970s. However, Nested Arrays started coming a bit later, perhaps the first preliminary sneak peek implementations came out starting around 1980.
The major players at the time were IBM, I. P. Sharp Associates, STSC, and Dyalog, a relative newcomer. All nested array implementations differed in one detail or another, arguably the biggest such difference was the implementation of boxed arrays by Sharp which were the basis of the boxed array implementation found today in J.
Arguably, at the time, Mainframe IBM APL2 probably had the largest market share.
STSC would later change its name to Manugistics and the implementation would evolve into APL2000's APL+ product suite.
Both STSC and Dyalog provided some compatibility mode around the various nested array subspecies, STSC's was the )EVLEVEL system command, evolution level, and Dyalog's was ML, migration level.
In a nutshell, Dyalog's ML can be set to 0, 1, 2, or 3. From Dyalog's documentation,
ML 0
is the default native Dyalog nested array implementation
ML 1
changes the definition of monadic epsilon to be the "enlist" function, a kind of super-ravel
ML 2
swaps the definitions of the symbols used for the "first" and "mix" functions, plus presents an alternate definition of the "depth" function
ML 3
provides IBM APL2 compatibility.
Personally, I use ML 3 almost exclusively, as I programmed heavily in APL2 when mainframes were still around.
Again, GNU APL follows IBM APL2 language compatibility. One way to achieve alternate enclose behaviours is to write cover functions to emulate the specialities of other implementations.
edited Jan 14 '15 at 13:00
answered Jan 14 '15 at 11:04
LobachevskyLobachevsky
942615
942615
Thanks! Maybe I should just build ⎕ML into gnuapl!
– alexweiner
Jan 15 '15 at 0:41
One of the countless religious discussion points is whether it is a Good Thing to be able to change language features on the fly. With such awesome power comes awesome responsibility and all that.
– Lobachevsky
Jan 15 '15 at 8:01
1
I would like to add that a few years ago a number of experts made a great effort to analyze the behaviour of existing APL interpreters and distilled the state of the art into the ISO/IEC 13751:2001 "Extended APL" standard, which is what GNU APL strives to follow.
– Tobia
Jan 17 '15 at 14:58
Dyalog APL's default has lately been changed to⎕ML 1
, and all new code developed by Dyalog adheres to this. Source: I work there.
– Adám
Dec 31 '15 at 19:00
From version 16.0, Dyalog APL will have both partitioning primitives available simultaneously when⎕ML←1
:⊂
is the Dyalog definition (partitioned enclose) while⊆
is the APL2 definition (partition).
– Adám
Jan 16 '17 at 19:22
add a comment |
Thanks! Maybe I should just build ⎕ML into gnuapl!
– alexweiner
Jan 15 '15 at 0:41
One of the countless religious discussion points is whether it is a Good Thing to be able to change language features on the fly. With such awesome power comes awesome responsibility and all that.
– Lobachevsky
Jan 15 '15 at 8:01
1
I would like to add that a few years ago a number of experts made a great effort to analyze the behaviour of existing APL interpreters and distilled the state of the art into the ISO/IEC 13751:2001 "Extended APL" standard, which is what GNU APL strives to follow.
– Tobia
Jan 17 '15 at 14:58
Dyalog APL's default has lately been changed to⎕ML 1
, and all new code developed by Dyalog adheres to this. Source: I work there.
– Adám
Dec 31 '15 at 19:00
From version 16.0, Dyalog APL will have both partitioning primitives available simultaneously when⎕ML←1
:⊂
is the Dyalog definition (partitioned enclose) while⊆
is the APL2 definition (partition).
– Adám
Jan 16 '17 at 19:22
Thanks! Maybe I should just build ⎕ML into gnuapl!
– alexweiner
Jan 15 '15 at 0:41
Thanks! Maybe I should just build ⎕ML into gnuapl!
– alexweiner
Jan 15 '15 at 0:41
One of the countless religious discussion points is whether it is a Good Thing to be able to change language features on the fly. With such awesome power comes awesome responsibility and all that.
– Lobachevsky
Jan 15 '15 at 8:01
One of the countless religious discussion points is whether it is a Good Thing to be able to change language features on the fly. With such awesome power comes awesome responsibility and all that.
– Lobachevsky
Jan 15 '15 at 8:01
1
1
I would like to add that a few years ago a number of experts made a great effort to analyze the behaviour of existing APL interpreters and distilled the state of the art into the ISO/IEC 13751:2001 "Extended APL" standard, which is what GNU APL strives to follow.
– Tobia
Jan 17 '15 at 14:58
I would like to add that a few years ago a number of experts made a great effort to analyze the behaviour of existing APL interpreters and distilled the state of the art into the ISO/IEC 13751:2001 "Extended APL" standard, which is what GNU APL strives to follow.
– Tobia
Jan 17 '15 at 14:58
Dyalog APL's default has lately been changed to
⎕ML 1
, and all new code developed by Dyalog adheres to this. Source: I work there.– Adám
Dec 31 '15 at 19:00
Dyalog APL's default has lately been changed to
⎕ML 1
, and all new code developed by Dyalog adheres to this. Source: I work there.– Adám
Dec 31 '15 at 19:00
From version 16.0, Dyalog APL will have both partitioning primitives available simultaneously when
⎕ML←1
: ⊂
is the Dyalog definition (partitioned enclose) while ⊆
is the APL2 definition (partition).– Adám
Jan 16 '17 at 19:22
From version 16.0, Dyalog APL will have both partitioning primitives available simultaneously when
⎕ML←1
: ⊂
is the Dyalog definition (partitioned enclose) while ⊆
is the APL2 definition (partition).– Adám
Jan 16 '17 at 19:22
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f27936301%2fpartition-behaviour-in-gnu-apl-and-dyalog-apl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown