Compile `DeleteCases`












5














How is the function DeleteCases compilable if Compile does not support patterns?



My question refers to this thread here where I want to use an If statement without the third argument required. Since my output of the If statement within compile always gives a positive real number, I'd like to get rid of the numbers which I invoke with a negative third argument in the If statement (the third arguments seems to be necessary so that the If statement is compiled at all).



Maybe there now might be even a better solution than this workaround provided by @Mr.Wizard but I do not really understand his suggestion (or is it meant to use DeleteCases outside of Compile?).










share|improve this question


















  • 6




    Only a restricted set of forms is supported in Compile. You can e.g. DeleteCases[list, 123]. I think only literal values can be used as the second argument.
    – Szabolcs
    Nov 21 '18 at 11:03










  • Yes, thank you for pointing it out. I think that is what I encountered here. So it is not usable for my purpose, unfortunately. But I like Henrik's way of avoiding this problem in the first place.
    – Display Name
    Nov 21 '18 at 15:29
















5














How is the function DeleteCases compilable if Compile does not support patterns?



My question refers to this thread here where I want to use an If statement without the third argument required. Since my output of the If statement within compile always gives a positive real number, I'd like to get rid of the numbers which I invoke with a negative third argument in the If statement (the third arguments seems to be necessary so that the If statement is compiled at all).



Maybe there now might be even a better solution than this workaround provided by @Mr.Wizard but I do not really understand his suggestion (or is it meant to use DeleteCases outside of Compile?).










share|improve this question


















  • 6




    Only a restricted set of forms is supported in Compile. You can e.g. DeleteCases[list, 123]. I think only literal values can be used as the second argument.
    – Szabolcs
    Nov 21 '18 at 11:03










  • Yes, thank you for pointing it out. I think that is what I encountered here. So it is not usable for my purpose, unfortunately. But I like Henrik's way of avoiding this problem in the first place.
    – Display Name
    Nov 21 '18 at 15:29














5












5








5


1





How is the function DeleteCases compilable if Compile does not support patterns?



My question refers to this thread here where I want to use an If statement without the third argument required. Since my output of the If statement within compile always gives a positive real number, I'd like to get rid of the numbers which I invoke with a negative third argument in the If statement (the third arguments seems to be necessary so that the If statement is compiled at all).



Maybe there now might be even a better solution than this workaround provided by @Mr.Wizard but I do not really understand his suggestion (or is it meant to use DeleteCases outside of Compile?).










share|improve this question













How is the function DeleteCases compilable if Compile does not support patterns?



My question refers to this thread here where I want to use an If statement without the third argument required. Since my output of the If statement within compile always gives a positive real number, I'd like to get rid of the numbers which I invoke with a negative third argument in the If statement (the third arguments seems to be necessary so that the If statement is compiled at all).



Maybe there now might be even a better solution than this workaround provided by @Mr.Wizard but I do not really understand his suggestion (or is it meant to use DeleteCases outside of Compile?).







compile






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 21 '18 at 10:47









Display NameDisplay Name

55738




55738








  • 6




    Only a restricted set of forms is supported in Compile. You can e.g. DeleteCases[list, 123]. I think only literal values can be used as the second argument.
    – Szabolcs
    Nov 21 '18 at 11:03










  • Yes, thank you for pointing it out. I think that is what I encountered here. So it is not usable for my purpose, unfortunately. But I like Henrik's way of avoiding this problem in the first place.
    – Display Name
    Nov 21 '18 at 15:29














  • 6




    Only a restricted set of forms is supported in Compile. You can e.g. DeleteCases[list, 123]. I think only literal values can be used as the second argument.
    – Szabolcs
    Nov 21 '18 at 11:03










  • Yes, thank you for pointing it out. I think that is what I encountered here. So it is not usable for my purpose, unfortunately. But I like Henrik's way of avoiding this problem in the first place.
    – Display Name
    Nov 21 '18 at 15:29








6




6




Only a restricted set of forms is supported in Compile. You can e.g. DeleteCases[list, 123]. I think only literal values can be used as the second argument.
– Szabolcs
Nov 21 '18 at 11:03




Only a restricted set of forms is supported in Compile. You can e.g. DeleteCases[list, 123]. I think only literal values can be used as the second argument.
– Szabolcs
Nov 21 '18 at 11:03












Yes, thank you for pointing it out. I think that is what I encountered here. So it is not usable for my purpose, unfortunately. But I like Henrik's way of avoiding this problem in the first place.
– Display Name
Nov 21 '18 at 15:29




Yes, thank you for pointing it out. I think that is what I encountered here. So it is not usable for my purpose, unfortunately. But I like Henrik's way of avoiding this problem in the first place.
– Display Name
Nov 21 '18 at 15:29










1 Answer
1






active

oldest

votes


















9














In code for Compile, it might be a better idea not to delete bad cases but to collect only the good ones with Internal`Bag.



If you have a certain but reasonably sized upper bound for the number od items to collect, you can also employ this less expensive way, using a packed array instead of a expandable data structure such as Internal`Bag:



First, preallocate an array a of sufficient size and a counter c, initialized by 0. Then fill the array in a Do or While loop: Each time your If statement evaluates to True, increase the counter c and write the "good" item into a[[c]]. After having collected all items, truncate the array with a[[1;;c]].



Example



Here are two functions that search the first n positive integers for multiples of 3 or 5:



Internal`Bag-based version (using the Most[{0}] hack to initiaize with an empty bag capable of collecting for integers):



cfBag = Compile[{{n, _Integer}},
Block[{bag},
bag = Internal`Bag[Most[{0}]];

Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
Internal`StuffBag[bag, i];
],
{i, 1, n}];
Internal`BagPart[bag, All]
],
CompilationTarget -> "C"
];


And here is the array-based version:



cfArray = Compile[{{n, _Integer}},
Block[{a, c = 0},
a = Table[0, {n}];
c = 0;
Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
c++;
a[[c]] = i;
],
{i, 1, n}];
If[c > 0, a[[1 ;; c]], {}]
],
CompilationTarget -> "C"
];


Comparison:



r1 = cfBag[10000000]; // RepeatedTiming // First
r2 = cfArray[10000000]; // RepeatedTiming // First
r1 == r2



0.288



0.313



True




To my own surprise, Internal`Bag is faster. Probably because the task is memory bound and because a is much larger than needed in the end (so, too much memory allocation and a potentially superfluous copy operation in the end). The reason seems to be that a call like a[[c]] = i; always checks whether c is within the bounds of a. Deactivating that with RuntimeOptions -> "Speed" makes the two methods equally fast.






share|improve this answer























  • Thank you for your answer. Can you maybe provide me with a minimal working example to see how that works out in practice? I only superficially read sth about InternalBag` so far, but it sounded interesting to me.
    – Display Name
    Nov 21 '18 at 12:03










  • Thank you very much. I will take a look at it as soon as I can :)
    – Display Name
    Nov 21 '18 at 13:17






  • 1




    For some reason the example code with Internal`Bag always seems to be slightly faster than the array based solution. Even with the specification of RuntimeOptions->"Speed". At least on my machine. The difference is about 17% of time.
    – Display Name
    Nov 21 '18 at 15:23








  • 1




    Yes, sry I thought that minor question isn't worth a new question. I also figured out my mistake with the help of your comment. I sloppily used Compiled`GetElement in the a[[c]] += 1 step, instead of using Part. I guess there is no equivalent to Compiled`GetElement for writing operations. As the name suggests Compiled`GetElement can of course only be used for read operations.
    – Display Name
    Nov 22 '18 at 13:18








  • 1




    Just need to be careful when you use the With construct and replace everything with part=Compile`GetElement as you once suggested to me and then not remember the difference between part and Part :D
    – Display Name
    Nov 22 '18 at 13:34











Your Answer





StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "387"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmathematica.stackexchange.com%2fquestions%2f186416%2fcompile-deletecases%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









9














In code for Compile, it might be a better idea not to delete bad cases but to collect only the good ones with Internal`Bag.



If you have a certain but reasonably sized upper bound for the number od items to collect, you can also employ this less expensive way, using a packed array instead of a expandable data structure such as Internal`Bag:



First, preallocate an array a of sufficient size and a counter c, initialized by 0. Then fill the array in a Do or While loop: Each time your If statement evaluates to True, increase the counter c and write the "good" item into a[[c]]. After having collected all items, truncate the array with a[[1;;c]].



Example



Here are two functions that search the first n positive integers for multiples of 3 or 5:



Internal`Bag-based version (using the Most[{0}] hack to initiaize with an empty bag capable of collecting for integers):



cfBag = Compile[{{n, _Integer}},
Block[{bag},
bag = Internal`Bag[Most[{0}]];

Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
Internal`StuffBag[bag, i];
],
{i, 1, n}];
Internal`BagPart[bag, All]
],
CompilationTarget -> "C"
];


And here is the array-based version:



cfArray = Compile[{{n, _Integer}},
Block[{a, c = 0},
a = Table[0, {n}];
c = 0;
Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
c++;
a[[c]] = i;
],
{i, 1, n}];
If[c > 0, a[[1 ;; c]], {}]
],
CompilationTarget -> "C"
];


Comparison:



r1 = cfBag[10000000]; // RepeatedTiming // First
r2 = cfArray[10000000]; // RepeatedTiming // First
r1 == r2



0.288



0.313



True




To my own surprise, Internal`Bag is faster. Probably because the task is memory bound and because a is much larger than needed in the end (so, too much memory allocation and a potentially superfluous copy operation in the end). The reason seems to be that a call like a[[c]] = i; always checks whether c is within the bounds of a. Deactivating that with RuntimeOptions -> "Speed" makes the two methods equally fast.






share|improve this answer























  • Thank you for your answer. Can you maybe provide me with a minimal working example to see how that works out in practice? I only superficially read sth about InternalBag` so far, but it sounded interesting to me.
    – Display Name
    Nov 21 '18 at 12:03










  • Thank you very much. I will take a look at it as soon as I can :)
    – Display Name
    Nov 21 '18 at 13:17






  • 1




    For some reason the example code with Internal`Bag always seems to be slightly faster than the array based solution. Even with the specification of RuntimeOptions->"Speed". At least on my machine. The difference is about 17% of time.
    – Display Name
    Nov 21 '18 at 15:23








  • 1




    Yes, sry I thought that minor question isn't worth a new question. I also figured out my mistake with the help of your comment. I sloppily used Compiled`GetElement in the a[[c]] += 1 step, instead of using Part. I guess there is no equivalent to Compiled`GetElement for writing operations. As the name suggests Compiled`GetElement can of course only be used for read operations.
    – Display Name
    Nov 22 '18 at 13:18








  • 1




    Just need to be careful when you use the With construct and replace everything with part=Compile`GetElement as you once suggested to me and then not remember the difference between part and Part :D
    – Display Name
    Nov 22 '18 at 13:34
















9














In code for Compile, it might be a better idea not to delete bad cases but to collect only the good ones with Internal`Bag.



If you have a certain but reasonably sized upper bound for the number od items to collect, you can also employ this less expensive way, using a packed array instead of a expandable data structure such as Internal`Bag:



First, preallocate an array a of sufficient size and a counter c, initialized by 0. Then fill the array in a Do or While loop: Each time your If statement evaluates to True, increase the counter c and write the "good" item into a[[c]]. After having collected all items, truncate the array with a[[1;;c]].



Example



Here are two functions that search the first n positive integers for multiples of 3 or 5:



Internal`Bag-based version (using the Most[{0}] hack to initiaize with an empty bag capable of collecting for integers):



cfBag = Compile[{{n, _Integer}},
Block[{bag},
bag = Internal`Bag[Most[{0}]];

Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
Internal`StuffBag[bag, i];
],
{i, 1, n}];
Internal`BagPart[bag, All]
],
CompilationTarget -> "C"
];


And here is the array-based version:



cfArray = Compile[{{n, _Integer}},
Block[{a, c = 0},
a = Table[0, {n}];
c = 0;
Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
c++;
a[[c]] = i;
],
{i, 1, n}];
If[c > 0, a[[1 ;; c]], {}]
],
CompilationTarget -> "C"
];


Comparison:



r1 = cfBag[10000000]; // RepeatedTiming // First
r2 = cfArray[10000000]; // RepeatedTiming // First
r1 == r2



0.288



0.313



True




To my own surprise, Internal`Bag is faster. Probably because the task is memory bound and because a is much larger than needed in the end (so, too much memory allocation and a potentially superfluous copy operation in the end). The reason seems to be that a call like a[[c]] = i; always checks whether c is within the bounds of a. Deactivating that with RuntimeOptions -> "Speed" makes the two methods equally fast.






share|improve this answer























  • Thank you for your answer. Can you maybe provide me with a minimal working example to see how that works out in practice? I only superficially read sth about InternalBag` so far, but it sounded interesting to me.
    – Display Name
    Nov 21 '18 at 12:03










  • Thank you very much. I will take a look at it as soon as I can :)
    – Display Name
    Nov 21 '18 at 13:17






  • 1




    For some reason the example code with Internal`Bag always seems to be slightly faster than the array based solution. Even with the specification of RuntimeOptions->"Speed". At least on my machine. The difference is about 17% of time.
    – Display Name
    Nov 21 '18 at 15:23








  • 1




    Yes, sry I thought that minor question isn't worth a new question. I also figured out my mistake with the help of your comment. I sloppily used Compiled`GetElement in the a[[c]] += 1 step, instead of using Part. I guess there is no equivalent to Compiled`GetElement for writing operations. As the name suggests Compiled`GetElement can of course only be used for read operations.
    – Display Name
    Nov 22 '18 at 13:18








  • 1




    Just need to be careful when you use the With construct and replace everything with part=Compile`GetElement as you once suggested to me and then not remember the difference between part and Part :D
    – Display Name
    Nov 22 '18 at 13:34














9












9








9






In code for Compile, it might be a better idea not to delete bad cases but to collect only the good ones with Internal`Bag.



If you have a certain but reasonably sized upper bound for the number od items to collect, you can also employ this less expensive way, using a packed array instead of a expandable data structure such as Internal`Bag:



First, preallocate an array a of sufficient size and a counter c, initialized by 0. Then fill the array in a Do or While loop: Each time your If statement evaluates to True, increase the counter c and write the "good" item into a[[c]]. After having collected all items, truncate the array with a[[1;;c]].



Example



Here are two functions that search the first n positive integers for multiples of 3 or 5:



Internal`Bag-based version (using the Most[{0}] hack to initiaize with an empty bag capable of collecting for integers):



cfBag = Compile[{{n, _Integer}},
Block[{bag},
bag = Internal`Bag[Most[{0}]];

Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
Internal`StuffBag[bag, i];
],
{i, 1, n}];
Internal`BagPart[bag, All]
],
CompilationTarget -> "C"
];


And here is the array-based version:



cfArray = Compile[{{n, _Integer}},
Block[{a, c = 0},
a = Table[0, {n}];
c = 0;
Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
c++;
a[[c]] = i;
],
{i, 1, n}];
If[c > 0, a[[1 ;; c]], {}]
],
CompilationTarget -> "C"
];


Comparison:



r1 = cfBag[10000000]; // RepeatedTiming // First
r2 = cfArray[10000000]; // RepeatedTiming // First
r1 == r2



0.288



0.313



True




To my own surprise, Internal`Bag is faster. Probably because the task is memory bound and because a is much larger than needed in the end (so, too much memory allocation and a potentially superfluous copy operation in the end). The reason seems to be that a call like a[[c]] = i; always checks whether c is within the bounds of a. Deactivating that with RuntimeOptions -> "Speed" makes the two methods equally fast.






share|improve this answer














In code for Compile, it might be a better idea not to delete bad cases but to collect only the good ones with Internal`Bag.



If you have a certain but reasonably sized upper bound for the number od items to collect, you can also employ this less expensive way, using a packed array instead of a expandable data structure such as Internal`Bag:



First, preallocate an array a of sufficient size and a counter c, initialized by 0. Then fill the array in a Do or While loop: Each time your If statement evaluates to True, increase the counter c and write the "good" item into a[[c]]. After having collected all items, truncate the array with a[[1;;c]].



Example



Here are two functions that search the first n positive integers for multiples of 3 or 5:



Internal`Bag-based version (using the Most[{0}] hack to initiaize with an empty bag capable of collecting for integers):



cfBag = Compile[{{n, _Integer}},
Block[{bag},
bag = Internal`Bag[Most[{0}]];

Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
Internal`StuffBag[bag, i];
],
{i, 1, n}];
Internal`BagPart[bag, All]
],
CompilationTarget -> "C"
];


And here is the array-based version:



cfArray = Compile[{{n, _Integer}},
Block[{a, c = 0},
a = Table[0, {n}];
c = 0;
Do[
If[Mod[i, 3] == 0 || Mod[i, 5] == 0,
c++;
a[[c]] = i;
],
{i, 1, n}];
If[c > 0, a[[1 ;; c]], {}]
],
CompilationTarget -> "C"
];


Comparison:



r1 = cfBag[10000000]; // RepeatedTiming // First
r2 = cfArray[10000000]; // RepeatedTiming // First
r1 == r2



0.288



0.313



True




To my own surprise, Internal`Bag is faster. Probably because the task is memory bound and because a is much larger than needed in the end (so, too much memory allocation and a potentially superfluous copy operation in the end). The reason seems to be that a call like a[[c]] = i; always checks whether c is within the bounds of a. Deactivating that with RuntimeOptions -> "Speed" makes the two methods equally fast.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 21 '18 at 12:27

























answered Nov 21 '18 at 11:54









Henrik SchumacherHenrik Schumacher

49.8k469142




49.8k469142












  • Thank you for your answer. Can you maybe provide me with a minimal working example to see how that works out in practice? I only superficially read sth about InternalBag` so far, but it sounded interesting to me.
    – Display Name
    Nov 21 '18 at 12:03










  • Thank you very much. I will take a look at it as soon as I can :)
    – Display Name
    Nov 21 '18 at 13:17






  • 1




    For some reason the example code with Internal`Bag always seems to be slightly faster than the array based solution. Even with the specification of RuntimeOptions->"Speed". At least on my machine. The difference is about 17% of time.
    – Display Name
    Nov 21 '18 at 15:23








  • 1




    Yes, sry I thought that minor question isn't worth a new question. I also figured out my mistake with the help of your comment. I sloppily used Compiled`GetElement in the a[[c]] += 1 step, instead of using Part. I guess there is no equivalent to Compiled`GetElement for writing operations. As the name suggests Compiled`GetElement can of course only be used for read operations.
    – Display Name
    Nov 22 '18 at 13:18








  • 1




    Just need to be careful when you use the With construct and replace everything with part=Compile`GetElement as you once suggested to me and then not remember the difference between part and Part :D
    – Display Name
    Nov 22 '18 at 13:34


















  • Thank you for your answer. Can you maybe provide me with a minimal working example to see how that works out in practice? I only superficially read sth about InternalBag` so far, but it sounded interesting to me.
    – Display Name
    Nov 21 '18 at 12:03










  • Thank you very much. I will take a look at it as soon as I can :)
    – Display Name
    Nov 21 '18 at 13:17






  • 1




    For some reason the example code with Internal`Bag always seems to be slightly faster than the array based solution. Even with the specification of RuntimeOptions->"Speed". At least on my machine. The difference is about 17% of time.
    – Display Name
    Nov 21 '18 at 15:23








  • 1




    Yes, sry I thought that minor question isn't worth a new question. I also figured out my mistake with the help of your comment. I sloppily used Compiled`GetElement in the a[[c]] += 1 step, instead of using Part. I guess there is no equivalent to Compiled`GetElement for writing operations. As the name suggests Compiled`GetElement can of course only be used for read operations.
    – Display Name
    Nov 22 '18 at 13:18








  • 1




    Just need to be careful when you use the With construct and replace everything with part=Compile`GetElement as you once suggested to me and then not remember the difference between part and Part :D
    – Display Name
    Nov 22 '18 at 13:34
















Thank you for your answer. Can you maybe provide me with a minimal working example to see how that works out in practice? I only superficially read sth about InternalBag` so far, but it sounded interesting to me.
– Display Name
Nov 21 '18 at 12:03




Thank you for your answer. Can you maybe provide me with a minimal working example to see how that works out in practice? I only superficially read sth about InternalBag` so far, but it sounded interesting to me.
– Display Name
Nov 21 '18 at 12:03












Thank you very much. I will take a look at it as soon as I can :)
– Display Name
Nov 21 '18 at 13:17




Thank you very much. I will take a look at it as soon as I can :)
– Display Name
Nov 21 '18 at 13:17




1




1




For some reason the example code with Internal`Bag always seems to be slightly faster than the array based solution. Even with the specification of RuntimeOptions->"Speed". At least on my machine. The difference is about 17% of time.
– Display Name
Nov 21 '18 at 15:23






For some reason the example code with Internal`Bag always seems to be slightly faster than the array based solution. Even with the specification of RuntimeOptions->"Speed". At least on my machine. The difference is about 17% of time.
– Display Name
Nov 21 '18 at 15:23






1




1




Yes, sry I thought that minor question isn't worth a new question. I also figured out my mistake with the help of your comment. I sloppily used Compiled`GetElement in the a[[c]] += 1 step, instead of using Part. I guess there is no equivalent to Compiled`GetElement for writing operations. As the name suggests Compiled`GetElement can of course only be used for read operations.
– Display Name
Nov 22 '18 at 13:18






Yes, sry I thought that minor question isn't worth a new question. I also figured out my mistake with the help of your comment. I sloppily used Compiled`GetElement in the a[[c]] += 1 step, instead of using Part. I guess there is no equivalent to Compiled`GetElement for writing operations. As the name suggests Compiled`GetElement can of course only be used for read operations.
– Display Name
Nov 22 '18 at 13:18






1




1




Just need to be careful when you use the With construct and replace everything with part=Compile`GetElement as you once suggested to me and then not remember the difference between part and Part :D
– Display Name
Nov 22 '18 at 13:34




Just need to be careful when you use the With construct and replace everything with part=Compile`GetElement as you once suggested to me and then not remember the difference between part and Part :D
– Display Name
Nov 22 '18 at 13:34


















draft saved

draft discarded




















































Thanks for contributing an answer to Mathematica Stack Exchange!


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


Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


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




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmathematica.stackexchange.com%2fquestions%2f186416%2fcompile-deletecases%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

Wiesbaden

Marschland

Dieringhausen