Force a function to report argument type mismatches

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
3
down vote

favorite












As a relative newcomer to Mathematica, I am still frequently caught out by coding errors that, at least by default, MMA does not indicate to the front end, in particular when I define a function and the argument types and then accidentally pass an argument of the wrong type.



For example, if I define



f[x_Integer] := x + 1;



and then call



f[1]



it is returned unevaluated because 1 has Head "List" and "Integer" is required.



This sort of thing tends to happen to me when I first test a larger and more complex function where other errors are to be expected, in which case my attention usually goes directly to the code.



Question: How can I write functions and declare the argument types on which the rest of the code may depend and let MMA tell me when I have passed an argument of the wrong kind?










share|improve this question























  • Compile your function, and you will get what you want, I suppose.
    – Î‘λέξανδρος Ζεγγ
    7 hours ago














up vote
3
down vote

favorite












As a relative newcomer to Mathematica, I am still frequently caught out by coding errors that, at least by default, MMA does not indicate to the front end, in particular when I define a function and the argument types and then accidentally pass an argument of the wrong type.



For example, if I define



f[x_Integer] := x + 1;



and then call



f[1]



it is returned unevaluated because 1 has Head "List" and "Integer" is required.



This sort of thing tends to happen to me when I first test a larger and more complex function where other errors are to be expected, in which case my attention usually goes directly to the code.



Question: How can I write functions and declare the argument types on which the rest of the code may depend and let MMA tell me when I have passed an argument of the wrong kind?










share|improve this question























  • Compile your function, and you will get what you want, I suppose.
    – Î‘λέξανδρος Ζεγγ
    7 hours ago












up vote
3
down vote

favorite









up vote
3
down vote

favorite











As a relative newcomer to Mathematica, I am still frequently caught out by coding errors that, at least by default, MMA does not indicate to the front end, in particular when I define a function and the argument types and then accidentally pass an argument of the wrong type.



For example, if I define



f[x_Integer] := x + 1;



and then call



f[1]



it is returned unevaluated because 1 has Head "List" and "Integer" is required.



This sort of thing tends to happen to me when I first test a larger and more complex function where other errors are to be expected, in which case my attention usually goes directly to the code.



Question: How can I write functions and declare the argument types on which the rest of the code may depend and let MMA tell me when I have passed an argument of the wrong kind?










share|improve this question















As a relative newcomer to Mathematica, I am still frequently caught out by coding errors that, at least by default, MMA does not indicate to the front end, in particular when I define a function and the argument types and then accidentally pass an argument of the wrong type.



For example, if I define



f[x_Integer] := x + 1;



and then call



f[1]



it is returned unevaluated because 1 has Head "List" and "Integer" is required.



This sort of thing tends to happen to me when I first test a larger and more complex function where other errors are to be expected, in which case my attention usually goes directly to the code.



Question: How can I write functions and declare the argument types on which the rest of the code may depend and let MMA tell me when I have passed an argument of the wrong kind?







function-construction error syntax debugging






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 8 mins ago









m_goldberg

82.3k869190




82.3k869190










asked 7 hours ago









Julian Moore

6911413




6911413











  • Compile your function, and you will get what you want, I suppose.
    – Î‘λέξανδρος Ζεγγ
    7 hours ago
















  • Compile your function, and you will get what you want, I suppose.
    – Î‘λέξανδρος Ζεγγ
    7 hours ago















Compile your function, and you will get what you want, I suppose.
– Î‘λέξανδρος Ζεγγ
7 hours ago




Compile your function, and you will get what you want, I suppose.
– Î‘λέξανδρος Ζεγγ
7 hours ago










1 Answer
1






active

oldest

votes

















up vote
5
down vote













One way to write a function with argument checking is to write subroutines for your function f that handles the actual calculation, and then do the argument checking in the main routine for f.



As a highly simplified example, let's call the subroutines for f intF:



intF[x_Integer] := x + 1
intF[x_ /; ArrayQ[x, _, IntegerQ]] := x + 1


so that f should only work for an integer or an array of integers.



We can then define error messages that f can emit:



f::nlst = "The argument `1` is not an integer or an array of integers.";


From that, you can write f like this:



f[x__] := Module[nargs, res,
nargs = Length[x];
res /; If[nargs == 1,
If[Head[res = intF[x]] =!= intF,
True,
Message[f::nlst, x]; False],
Message[f::argx, f, nargs]; False]]


The main point here is the use of Condition (/;) to do the argument checking; recall that in the expression expr /; test, test should be something that evaluates to True or False, and expr will only then be evaluated.



In this example, the first check is a simple argument count, done by checking if x has length 1 (i.e. f was only passed one argument). If the test fails, then the part Message[f::argx, f, nargs]; False gets evaluated, and since the last result is False, we get no evaluation of res.



Note, however, that I did not define the message f::argx. In this case, the message text is taken from General::argx.



If the check of the argument count is passed, we get to the inner conditional. In there, we evaluate Head[res = intF[x]] =!= intF. Two things are done here: the result of the subroutine intF[x] is assigned to res, after which it is checked if evaluation occurred (i.e. the head of res is no longer intF). If this test is passed, we get the ultimate result True for the condition, and thus the previously evaluated res is returned. Otherwise, Message[f::nlst, x]; False gets evaluated.



With this, f[3] and f[1, 2] will evaluate as usual, but f[2.] and f[5, 6, 4] will throw the message f::nlst, while f[1, 9] will throw the message f::argx.






share|improve this answer




















  • Very nice & clear exposition, thx! Question though: the head check tests evaluation so doesn't say anything specific (just like seeing the fn unevaluated in output) & the message f::nlst seems to assume that evaluation did not occur because of the mismatch - but what if evaluation failed because of a coding error rather than an argument mismatch? I don't know MMA well enough to know whether that is actually possible, but I think I recall function definitions that seem to be OK (the symbol gets defined on shift-return) but don't evaluate even with correct arguments. Or am I mis-remembering?
    – Julian Moore
    5 hours ago










  • PS Part of my Q is really - when MMA checks arguments and finds a mismatch, why doesn't it report that itself?
    – Julian Moore
    5 hours ago






  • 1




    I'll try to write additional details later, but to quickly answer your second question: Mathematica is allowing for the possibility that you might write additional definitions later. Using the f example, if I add a third definition for intF that covers input not covered by the previous definitions, then f gets to use that definition as well.
    – J. M. is somewhat okay.♦
    4 hours ago










  • You are most kind; but if MMA is checking against all symbols is an unevaluated output defined to mean no matching symbol definition - and any other error in e.g. code is always indicated some other way?
    – Julian Moore
    4 hours ago










  • "...if Mathematica is checking against all symbols, is an unevaluated output defined to mean no matching symbol definition" - it is, first and foremost, a pattern-matching language; it will do something only if it has been explicitly told how to handle objects that match a defined pattern. So, in the intF case, I told Mathematica how it should deal with integer input in one definition, and how to handle an array of integers in a second definition. Any other thing not matching those two defined patterns is left unevaluated.
    – J. M. is somewhat okay.♦
    3 hours ago










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',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
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%2f182812%2fforce-a-function-to-report-argument-type-mismatches%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
5
down vote













One way to write a function with argument checking is to write subroutines for your function f that handles the actual calculation, and then do the argument checking in the main routine for f.



As a highly simplified example, let's call the subroutines for f intF:



intF[x_Integer] := x + 1
intF[x_ /; ArrayQ[x, _, IntegerQ]] := x + 1


so that f should only work for an integer or an array of integers.



We can then define error messages that f can emit:



f::nlst = "The argument `1` is not an integer or an array of integers.";


From that, you can write f like this:



f[x__] := Module[nargs, res,
nargs = Length[x];
res /; If[nargs == 1,
If[Head[res = intF[x]] =!= intF,
True,
Message[f::nlst, x]; False],
Message[f::argx, f, nargs]; False]]


The main point here is the use of Condition (/;) to do the argument checking; recall that in the expression expr /; test, test should be something that evaluates to True or False, and expr will only then be evaluated.



In this example, the first check is a simple argument count, done by checking if x has length 1 (i.e. f was only passed one argument). If the test fails, then the part Message[f::argx, f, nargs]; False gets evaluated, and since the last result is False, we get no evaluation of res.



Note, however, that I did not define the message f::argx. In this case, the message text is taken from General::argx.



If the check of the argument count is passed, we get to the inner conditional. In there, we evaluate Head[res = intF[x]] =!= intF. Two things are done here: the result of the subroutine intF[x] is assigned to res, after which it is checked if evaluation occurred (i.e. the head of res is no longer intF). If this test is passed, we get the ultimate result True for the condition, and thus the previously evaluated res is returned. Otherwise, Message[f::nlst, x]; False gets evaluated.



With this, f[3] and f[1, 2] will evaluate as usual, but f[2.] and f[5, 6, 4] will throw the message f::nlst, while f[1, 9] will throw the message f::argx.






share|improve this answer




















  • Very nice & clear exposition, thx! Question though: the head check tests evaluation so doesn't say anything specific (just like seeing the fn unevaluated in output) & the message f::nlst seems to assume that evaluation did not occur because of the mismatch - but what if evaluation failed because of a coding error rather than an argument mismatch? I don't know MMA well enough to know whether that is actually possible, but I think I recall function definitions that seem to be OK (the symbol gets defined on shift-return) but don't evaluate even with correct arguments. Or am I mis-remembering?
    – Julian Moore
    5 hours ago










  • PS Part of my Q is really - when MMA checks arguments and finds a mismatch, why doesn't it report that itself?
    – Julian Moore
    5 hours ago






  • 1




    I'll try to write additional details later, but to quickly answer your second question: Mathematica is allowing for the possibility that you might write additional definitions later. Using the f example, if I add a third definition for intF that covers input not covered by the previous definitions, then f gets to use that definition as well.
    – J. M. is somewhat okay.♦
    4 hours ago










  • You are most kind; but if MMA is checking against all symbols is an unevaluated output defined to mean no matching symbol definition - and any other error in e.g. code is always indicated some other way?
    – Julian Moore
    4 hours ago










  • "...if Mathematica is checking against all symbols, is an unevaluated output defined to mean no matching symbol definition" - it is, first and foremost, a pattern-matching language; it will do something only if it has been explicitly told how to handle objects that match a defined pattern. So, in the intF case, I told Mathematica how it should deal with integer input in one definition, and how to handle an array of integers in a second definition. Any other thing not matching those two defined patterns is left unevaluated.
    – J. M. is somewhat okay.♦
    3 hours ago














up vote
5
down vote













One way to write a function with argument checking is to write subroutines for your function f that handles the actual calculation, and then do the argument checking in the main routine for f.



As a highly simplified example, let's call the subroutines for f intF:



intF[x_Integer] := x + 1
intF[x_ /; ArrayQ[x, _, IntegerQ]] := x + 1


so that f should only work for an integer or an array of integers.



We can then define error messages that f can emit:



f::nlst = "The argument `1` is not an integer or an array of integers.";


From that, you can write f like this:



f[x__] := Module[nargs, res,
nargs = Length[x];
res /; If[nargs == 1,
If[Head[res = intF[x]] =!= intF,
True,
Message[f::nlst, x]; False],
Message[f::argx, f, nargs]; False]]


The main point here is the use of Condition (/;) to do the argument checking; recall that in the expression expr /; test, test should be something that evaluates to True or False, and expr will only then be evaluated.



In this example, the first check is a simple argument count, done by checking if x has length 1 (i.e. f was only passed one argument). If the test fails, then the part Message[f::argx, f, nargs]; False gets evaluated, and since the last result is False, we get no evaluation of res.



Note, however, that I did not define the message f::argx. In this case, the message text is taken from General::argx.



If the check of the argument count is passed, we get to the inner conditional. In there, we evaluate Head[res = intF[x]] =!= intF. Two things are done here: the result of the subroutine intF[x] is assigned to res, after which it is checked if evaluation occurred (i.e. the head of res is no longer intF). If this test is passed, we get the ultimate result True for the condition, and thus the previously evaluated res is returned. Otherwise, Message[f::nlst, x]; False gets evaluated.



With this, f[3] and f[1, 2] will evaluate as usual, but f[2.] and f[5, 6, 4] will throw the message f::nlst, while f[1, 9] will throw the message f::argx.






share|improve this answer




















  • Very nice & clear exposition, thx! Question though: the head check tests evaluation so doesn't say anything specific (just like seeing the fn unevaluated in output) & the message f::nlst seems to assume that evaluation did not occur because of the mismatch - but what if evaluation failed because of a coding error rather than an argument mismatch? I don't know MMA well enough to know whether that is actually possible, but I think I recall function definitions that seem to be OK (the symbol gets defined on shift-return) but don't evaluate even with correct arguments. Or am I mis-remembering?
    – Julian Moore
    5 hours ago










  • PS Part of my Q is really - when MMA checks arguments and finds a mismatch, why doesn't it report that itself?
    – Julian Moore
    5 hours ago






  • 1




    I'll try to write additional details later, but to quickly answer your second question: Mathematica is allowing for the possibility that you might write additional definitions later. Using the f example, if I add a third definition for intF that covers input not covered by the previous definitions, then f gets to use that definition as well.
    – J. M. is somewhat okay.♦
    4 hours ago










  • You are most kind; but if MMA is checking against all symbols is an unevaluated output defined to mean no matching symbol definition - and any other error in e.g. code is always indicated some other way?
    – Julian Moore
    4 hours ago










  • "...if Mathematica is checking against all symbols, is an unevaluated output defined to mean no matching symbol definition" - it is, first and foremost, a pattern-matching language; it will do something only if it has been explicitly told how to handle objects that match a defined pattern. So, in the intF case, I told Mathematica how it should deal with integer input in one definition, and how to handle an array of integers in a second definition. Any other thing not matching those two defined patterns is left unevaluated.
    – J. M. is somewhat okay.♦
    3 hours ago












up vote
5
down vote










up vote
5
down vote









One way to write a function with argument checking is to write subroutines for your function f that handles the actual calculation, and then do the argument checking in the main routine for f.



As a highly simplified example, let's call the subroutines for f intF:



intF[x_Integer] := x + 1
intF[x_ /; ArrayQ[x, _, IntegerQ]] := x + 1


so that f should only work for an integer or an array of integers.



We can then define error messages that f can emit:



f::nlst = "The argument `1` is not an integer or an array of integers.";


From that, you can write f like this:



f[x__] := Module[nargs, res,
nargs = Length[x];
res /; If[nargs == 1,
If[Head[res = intF[x]] =!= intF,
True,
Message[f::nlst, x]; False],
Message[f::argx, f, nargs]; False]]


The main point here is the use of Condition (/;) to do the argument checking; recall that in the expression expr /; test, test should be something that evaluates to True or False, and expr will only then be evaluated.



In this example, the first check is a simple argument count, done by checking if x has length 1 (i.e. f was only passed one argument). If the test fails, then the part Message[f::argx, f, nargs]; False gets evaluated, and since the last result is False, we get no evaluation of res.



Note, however, that I did not define the message f::argx. In this case, the message text is taken from General::argx.



If the check of the argument count is passed, we get to the inner conditional. In there, we evaluate Head[res = intF[x]] =!= intF. Two things are done here: the result of the subroutine intF[x] is assigned to res, after which it is checked if evaluation occurred (i.e. the head of res is no longer intF). If this test is passed, we get the ultimate result True for the condition, and thus the previously evaluated res is returned. Otherwise, Message[f::nlst, x]; False gets evaluated.



With this, f[3] and f[1, 2] will evaluate as usual, but f[2.] and f[5, 6, 4] will throw the message f::nlst, while f[1, 9] will throw the message f::argx.






share|improve this answer












One way to write a function with argument checking is to write subroutines for your function f that handles the actual calculation, and then do the argument checking in the main routine for f.



As a highly simplified example, let's call the subroutines for f intF:



intF[x_Integer] := x + 1
intF[x_ /; ArrayQ[x, _, IntegerQ]] := x + 1


so that f should only work for an integer or an array of integers.



We can then define error messages that f can emit:



f::nlst = "The argument `1` is not an integer or an array of integers.";


From that, you can write f like this:



f[x__] := Module[nargs, res,
nargs = Length[x];
res /; If[nargs == 1,
If[Head[res = intF[x]] =!= intF,
True,
Message[f::nlst, x]; False],
Message[f::argx, f, nargs]; False]]


The main point here is the use of Condition (/;) to do the argument checking; recall that in the expression expr /; test, test should be something that evaluates to True or False, and expr will only then be evaluated.



In this example, the first check is a simple argument count, done by checking if x has length 1 (i.e. f was only passed one argument). If the test fails, then the part Message[f::argx, f, nargs]; False gets evaluated, and since the last result is False, we get no evaluation of res.



Note, however, that I did not define the message f::argx. In this case, the message text is taken from General::argx.



If the check of the argument count is passed, we get to the inner conditional. In there, we evaluate Head[res = intF[x]] =!= intF. Two things are done here: the result of the subroutine intF[x] is assigned to res, after which it is checked if evaluation occurred (i.e. the head of res is no longer intF). If this test is passed, we get the ultimate result True for the condition, and thus the previously evaluated res is returned. Otherwise, Message[f::nlst, x]; False gets evaluated.



With this, f[3] and f[1, 2] will evaluate as usual, but f[2.] and f[5, 6, 4] will throw the message f::nlst, while f[1, 9] will throw the message f::argx.







share|improve this answer












share|improve this answer



share|improve this answer










answered 6 hours ago









J. M. is somewhat okay.♦

93.4k10289445




93.4k10289445











  • Very nice & clear exposition, thx! Question though: the head check tests evaluation so doesn't say anything specific (just like seeing the fn unevaluated in output) & the message f::nlst seems to assume that evaluation did not occur because of the mismatch - but what if evaluation failed because of a coding error rather than an argument mismatch? I don't know MMA well enough to know whether that is actually possible, but I think I recall function definitions that seem to be OK (the symbol gets defined on shift-return) but don't evaluate even with correct arguments. Or am I mis-remembering?
    – Julian Moore
    5 hours ago










  • PS Part of my Q is really - when MMA checks arguments and finds a mismatch, why doesn't it report that itself?
    – Julian Moore
    5 hours ago






  • 1




    I'll try to write additional details later, but to quickly answer your second question: Mathematica is allowing for the possibility that you might write additional definitions later. Using the f example, if I add a third definition for intF that covers input not covered by the previous definitions, then f gets to use that definition as well.
    – J. M. is somewhat okay.♦
    4 hours ago










  • You are most kind; but if MMA is checking against all symbols is an unevaluated output defined to mean no matching symbol definition - and any other error in e.g. code is always indicated some other way?
    – Julian Moore
    4 hours ago










  • "...if Mathematica is checking against all symbols, is an unevaluated output defined to mean no matching symbol definition" - it is, first and foremost, a pattern-matching language; it will do something only if it has been explicitly told how to handle objects that match a defined pattern. So, in the intF case, I told Mathematica how it should deal with integer input in one definition, and how to handle an array of integers in a second definition. Any other thing not matching those two defined patterns is left unevaluated.
    – J. M. is somewhat okay.♦
    3 hours ago
















  • Very nice & clear exposition, thx! Question though: the head check tests evaluation so doesn't say anything specific (just like seeing the fn unevaluated in output) & the message f::nlst seems to assume that evaluation did not occur because of the mismatch - but what if evaluation failed because of a coding error rather than an argument mismatch? I don't know MMA well enough to know whether that is actually possible, but I think I recall function definitions that seem to be OK (the symbol gets defined on shift-return) but don't evaluate even with correct arguments. Or am I mis-remembering?
    – Julian Moore
    5 hours ago










  • PS Part of my Q is really - when MMA checks arguments and finds a mismatch, why doesn't it report that itself?
    – Julian Moore
    5 hours ago






  • 1




    I'll try to write additional details later, but to quickly answer your second question: Mathematica is allowing for the possibility that you might write additional definitions later. Using the f example, if I add a third definition for intF that covers input not covered by the previous definitions, then f gets to use that definition as well.
    – J. M. is somewhat okay.♦
    4 hours ago










  • You are most kind; but if MMA is checking against all symbols is an unevaluated output defined to mean no matching symbol definition - and any other error in e.g. code is always indicated some other way?
    – Julian Moore
    4 hours ago










  • "...if Mathematica is checking against all symbols, is an unevaluated output defined to mean no matching symbol definition" - it is, first and foremost, a pattern-matching language; it will do something only if it has been explicitly told how to handle objects that match a defined pattern. So, in the intF case, I told Mathematica how it should deal with integer input in one definition, and how to handle an array of integers in a second definition. Any other thing not matching those two defined patterns is left unevaluated.
    – J. M. is somewhat okay.♦
    3 hours ago















Very nice & clear exposition, thx! Question though: the head check tests evaluation so doesn't say anything specific (just like seeing the fn unevaluated in output) & the message f::nlst seems to assume that evaluation did not occur because of the mismatch - but what if evaluation failed because of a coding error rather than an argument mismatch? I don't know MMA well enough to know whether that is actually possible, but I think I recall function definitions that seem to be OK (the symbol gets defined on shift-return) but don't evaluate even with correct arguments. Or am I mis-remembering?
– Julian Moore
5 hours ago




Very nice & clear exposition, thx! Question though: the head check tests evaluation so doesn't say anything specific (just like seeing the fn unevaluated in output) & the message f::nlst seems to assume that evaluation did not occur because of the mismatch - but what if evaluation failed because of a coding error rather than an argument mismatch? I don't know MMA well enough to know whether that is actually possible, but I think I recall function definitions that seem to be OK (the symbol gets defined on shift-return) but don't evaluate even with correct arguments. Or am I mis-remembering?
– Julian Moore
5 hours ago












PS Part of my Q is really - when MMA checks arguments and finds a mismatch, why doesn't it report that itself?
– Julian Moore
5 hours ago




PS Part of my Q is really - when MMA checks arguments and finds a mismatch, why doesn't it report that itself?
– Julian Moore
5 hours ago




1




1




I'll try to write additional details later, but to quickly answer your second question: Mathematica is allowing for the possibility that you might write additional definitions later. Using the f example, if I add a third definition for intF that covers input not covered by the previous definitions, then f gets to use that definition as well.
– J. M. is somewhat okay.♦
4 hours ago




I'll try to write additional details later, but to quickly answer your second question: Mathematica is allowing for the possibility that you might write additional definitions later. Using the f example, if I add a third definition for intF that covers input not covered by the previous definitions, then f gets to use that definition as well.
– J. M. is somewhat okay.♦
4 hours ago












You are most kind; but if MMA is checking against all symbols is an unevaluated output defined to mean no matching symbol definition - and any other error in e.g. code is always indicated some other way?
– Julian Moore
4 hours ago




You are most kind; but if MMA is checking against all symbols is an unevaluated output defined to mean no matching symbol definition - and any other error in e.g. code is always indicated some other way?
– Julian Moore
4 hours ago












"...if Mathematica is checking against all symbols, is an unevaluated output defined to mean no matching symbol definition" - it is, first and foremost, a pattern-matching language; it will do something only if it has been explicitly told how to handle objects that match a defined pattern. So, in the intF case, I told Mathematica how it should deal with integer input in one definition, and how to handle an array of integers in a second definition. Any other thing not matching those two defined patterns is left unevaluated.
– J. M. is somewhat okay.♦
3 hours ago




"...if Mathematica is checking against all symbols, is an unevaluated output defined to mean no matching symbol definition" - it is, first and foremost, a pattern-matching language; it will do something only if it has been explicitly told how to handle objects that match a defined pattern. So, in the intF case, I told Mathematica how it should deal with integer input in one definition, and how to handle an array of integers in a second definition. Any other thing not matching those two defined patterns is left unevaluated.
– J. M. is somewhat okay.♦
3 hours ago

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmathematica.stackexchange.com%2fquestions%2f182812%2fforce-a-function-to-report-argument-type-mismatches%23new-answer', 'question_page');

);

Post as a guest













































































Comments

Popular posts from this blog

Long meetings (6-7 hours a day): Being “babysat” by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery