Force a function to report argument type mismatches
Clash 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?
function-construction error syntax debugging
add a comment |Â
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?
function-construction error syntax debugging
Compile
your function, and you will get what you want, I suppose.
â ÃÂûÃÂþñýôÃÂÿàÃÂõóó
7 hours ago
add a comment |Â
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?
function-construction error syntax debugging
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
function-construction error syntax debugging
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
add a comment |Â
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
add a comment |Â
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
.
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 thef
example, if I add a third definition forintF
that covers input not covered by the previous definitions, thenf
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 theintF
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
add a comment |Â
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
.
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 thef
example, if I add a third definition forintF
that covers input not covered by the previous definitions, thenf
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 theintF
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
add a comment |Â
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
.
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 thef
example, if I add a third definition forintF
that covers input not covered by the previous definitions, thenf
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 theintF
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
add a comment |Â
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
.
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
.
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 thef
example, if I add a third definition forintF
that covers input not covered by the previous definitions, thenf
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 theintF
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
add a comment |Â
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 thef
example, if I add a third definition forintF
that covers input not covered by the previous definitions, thenf
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 theintF
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
add a comment |Â
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
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
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
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
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
Compile
your function, and you will get what you want, I suppose.â ÃÂûÃÂþñýôÃÂÿàÃÂõóó
7 hours ago