KDP_book

Mathematica: Functional and procedural programming

functions in block, function, and module headers that will use factual argument values that relate to other formal arguments as the following simple fragment rather visually illustrates.

In[7]:= V[x_ /; IntegerQ[x], y_ /; EvenQ[x] && IntegerQ[y]] := x/y In[8]:= V[42, 77]

Out[8]= V[42, 77]

In the example shown, the testing function assigned to the second formal argument y cannot include the value passed to the first formal argument x, otherwise by causing the return of V function call unevaluated. We will offer here one interesting reception, allowing to solve similar and some other problems. Consider it with a rather simple example.

In[2296]:= V[x_ /; {Save3["j", x], IntegerQ[x]}[[–1]],

y_ /; {If[Get["j"]*y > 100, True, False], DeleteFile["j"]}[[1]]] := x*y In[2297]:= V[42, 77]

Out[2297]= 3234

In[2298]:= V[7, 8]

Out[2298]= V[7, 8]

In order to pass an actual value (passed to the x argument when the V function is called) to a testing function of another y argument, by the function Save3 the value is stored in a сertain temporary j file. Then call Get[j] allows to read the stored value from the file j in the required point of the testing function of any formal argument of the header, after necessity deleting file j. To solve such problems, a Save3 function is of interest – a version of the built-in Save function whose Save3[f, x] call saves in the f of the txt–format an expression x without returning anything.

In[2310]:= Save3[f_, x_] := {Write[f, x], Close[f]}[[1]]

In[2311]:= Save3["###", b*S + c*V + G*x]

In[2312]:= Get["##"]

Out[2312]= b*S + c*V + G*x

After calling Save3[f, x], the file with expression x remains closed and is loaded into the current session by function Get[f], returning the x value. Note that the Write function used by the Save3 has a number of features discussed in detail in [8]. In the first place, this refers to preserving the sequence of expressions.

51

V.Z. Aladjev, M.L. Shishakov, V.A. Vaganov

The following procedure serves as an useful enough tool at manipulating with functions and procedures, its call HeadPF[x] returns heading in string format of a block, module or function with a x name activated in the current session, i.e. the function in its traditional understanding with heading. Whereas on other values of the x argument the call is returned unevaluated. At the same time, the problem of definition of headings is actual also in a case of the objects of the above type of the same name which have more than one heading. In this case the procedure call HeadPF[w] returns the list of headings in string format of the subobjects composing a w object as a whole. The following fragment represents the source code of the HeadPF procedure along with a typical example of its application.

In[2225]:= M[x_ /; x == "avzagn"] := Module[{a}, a*x];

M[x_, y_, z_] := x*y*z; M[x_String] := x;

M[x_ /; IntegerQ[x], y_String] := Module[{a, b, c}, x]; M[x_, y_] := Module[{a, b, c}, "abc"; x + y]

In[2226]:= HeadPF[x_ /; BlockFuncModQ[x]] := Module[{b,

c= ToString[x], a = Select[Flatten[{PureDefinition[x]}],

!SuffPref[#, "Default[", 1] &]}, b = Map[StringTake[#, {1, Flatten[StringPosition[#, {" := ", " = "}]][[1]] – 1}] &, a];

If[Length[b] == 1, b[[1]], b]]

In[2227]:= HeadPF[M]

Out[2227]= {"M[x_ /; x == \"avzagn\"]", "M[x_, y_, z_]",

"M[x_ /; IntegerQ[x], y_String]", "M[x_String]", "M[x_, y_]"}

Here, it is necessary to make one essential enough remark concerning the means dealing with the headings of procedures and functions. The matter is that as it was shown earlier, the testing tools ascribed to the formal arguments, as a rule, consist of the earlier defined testing functions or the reserved keywords defining the type, for example, Integer. While as a side effect the built–in Math–language allows to use the constructions that can contain definitions of the testing tools, directly in the headings of procedures and functions. Certain interesting examples of that have been represented above. Meanwhile, despite of such opportunity, the programmed means are oriented, as a rule, on

52

Mathematica: Functional and procedural programming

use for testing of admissibility of the factual arguments or the predefined means, or including the testing algorithms in the body of the procedures and functions. For this reason, HeadPF procedure presented above in such cases can return incorrect results. Whereas the HeadPFU procedure covers such peculiar cases. The procedure call HeadPFU[x] correctly returns the heading in string format of a block, module or function with a name x activated in the current session regardless of a way of definition of testing of factual arguments. The fragment below presents the source code of the HeadPFU procedure along with typical examples of its application.

In[2230]:= P[x_, y_ /; {IntOddQ[t_] := IntegerQ[t] && OddQ[t], IntOddQ[y]}[[–1]]] := x*y

In[2231]:= HeadPF[P]

Out[2231]= "P[x_, y_ /; {IntOddQ[t_]"

In[2232]:= HeadPFU[x_ /; BlockFuncModQ[x]] :=

Module[{a = Flatten[{PureDefinition[x]}], b = {}, c, g},

Do[c = Map[#[[1]] – 1 &, StringPosition[a[[j]], " := "]]; Do[If[SyntaxQ[Set[g, StringTake[a[[j]], {1, c[[k]]}]]],

AppendTo[b, g]; Break[], Null], {k, Length[c]}], {j, Length[a]}];

If[Length[b] == 1, b[[1]], b]]

In[2233]:= HeadPFU[P]

Out[2233]= "P[x_, y_ /; {IntOddQ[t_] := IntegerQ[t] && OddQ[t], IntOddQ[y]}[[–1]]]"

In[2234]:= V[x_ /; {Save3["#", x], IntegerQ[x]}[[–1]],

y_ /; {If[Get["#"]*y > 77, True, False], DeleteFile["#"]}[[1]]] := x*y In[2235]:= HeadPFU[V]

Out[2235]= "V[x_ /; {Save3[\"#\", x], IntegerQ[x]}[[–1]],

y_ /; {If[Get[\"#\"]*y > 77, True, False], DeleteFile[\"#\"]}[[1]]]"

In this regard the testing of a x object regarding to be of the same name is enough actually; the QmultiplePF procedure [16] solves the problem whose call QmultiplePF[x] returns True, if x is an object of the same name (Function, Block, Module), and False otherwise. Whereas the procedure call QmultiplePF[x, y] with the second optional y argument – an indefinite variable – through y returns the list of definitions of all sub–objects with a name x.

Right there pertinently to note some more tools linked with

53

V.Z. Aladjev, M.L. Shishakov, V.A. Vaganov

the HeadPF procedure. So, the Headings procedure is a rather useful expansion of the HeadPF procedure in a case of blocks, functions and modules of the same name but with the different headings. Generally, the call Headings[x] returns the nested list whose elements are the sub–lists which determine respectively headings of sub-objects composing an object x; the first elements of such sub-lists defines the types of sub-objects, whereas others define the headings corresponding to them. In a number of the appendices that widely use procedural programming, a rather useful is the HeadingsPF procedure that is an expansion of the previous procedure. Generally, the call HeadingsPF[] returns the nested list, whose elements are sub–lists that respectively define the headings of functions, blocks and modules, whose definitions have been evaluated in the current session; the first element of each such sub–list determines an object type in the context {"Block", "Module", "Function"} while the others define the headings corresponding to it. The procedure call returns a simple list if any of sub–lists does not contain headings; at that, if in the current session the evaluations of definitions of objects of the specified three types weren't made, the call returns empty list. The call with any arguments is returned unevaluated. The following fragment represents source code of the HeadingsPF procedure along with an example of its typical application.

In[2310]:= HeadingsPF[x___ /; SameQ[x, {}]] := Module[{a = {}, d = {}, k = 1, b, c = {{"Block"}, {"Function"}, {"Module"}}, t},

Map[If[Quiet[Check[BlockFuncModQ[#], False]], AppendTo[a, #], Null] &, Names["`*"]]; b = Map[Headings[#] &, a]; While[k <= Length[b], t = b[[k]];

If[NestListQ[t], d = Join[d, t], AppendTo[d, t]]; k++]; Map[If[#[[1]] == "Block", c[[1]] = Join[c[[1]], #[[2 ;; –1]]], If[#[[1]] == "Function", c[[2]] = Join[c[[2]], #[[2 ;; –1]]], c[[3]] = Join[c[[3]], #[[2 ;; –1]]]]] &, d]; c = Select[c, Length[#] > 1 &]; If[Length[c] == 1, c[[1]], c]]

In[2311]:= M[x_ /; SameQ[x, "avz"], y_] := Module[{a, b, c}, y];

L1[x_] := x; M[x_, y_, z_] := x + y + z; L[x_, y_] := x + y; M[x_ /; x == "avz"] := Module[{a, b, c}, x];

M[x_ /; IntegerQ[x], y_String] := Module[{a, b, c}, x];

54

Mathematica: Functional and procedural programming

M[x_, y_] := Module[{a, b, c}, "agn"; x + y]; M[x_String] := x; M[x_ /; ListQ[x], y_] := Block[{a, b, c}, "agn"; Length[x] + y]; F[x_ /; SameQ[x, "avz"], y_] := {x, y}; F[x_ /; x == "avz"] := x

In[2312]:= HeadingsPF[]

Out[2312]= {{"Block", "M[x_ /; ListQ[x], y_]"},

{"Function", "F[x_ /; x === \"avz\", y_]", "F[x_ /; x == \"avz\"]", "L[x_, y_]", "L1[x_]", "M[x_, y_, z_]", "M[x_String]"},

{"Module", "M[x_ /; x === \"avz\", y_]", "M[x_, y_]", "M[x_ /; x == \"avz\"]", "M[x_ /; IntegerQ[x], y_String]"}}

In the light of possibility of existence in the current session of procedures and functions of the same name with different headings the problem of removal from the session of an object with the concrete heading is of a certain interest; this problem is solved by the procedure RemProcOnHead, whose the source code with an example of its application is represented below.

In[7]:= RemProcOnHead[x_ /; HeadingQ[x]||HeadingQ1[x]||

ListQ[x] && AllTrue[Map[HeadingQ[#] &, x], TrueQ]] := Module[{b, c, d, p, a = HeadName[If[ListQ[x], x[[1]], x]]},

If[! MemberQ[Names["`*"] || ! HowAct[a], a], $Failed, b = Definition2[a]; c = b[[1 ;; –2]]; d = b[[–1]]; ToExpression["ClearAttributes["<>a<> ","<>ToString[d]<>"]"]; y = Map[StandHead, Flatten[{x}]]; p = Select[c, ! SuffPref[#, x, 1] &]; ToExpression["Clear[" <> a <> "]"]; If[p == {}, "Done", ToExpression[p];

ToExpression["SetAttributes["<>a <> "," <> ToString[d] <> "]"]; "Done"]]]

In[8]:= V[x_] := Module[{}, x^6]; V[x_Integer] := x^2 In[9]:= {RemProcOnHead["V[x_Integer]"],

RemProcOnHead["V[x_]"]}

Out[9]= {"Done", "Done"}

In[10]:= Definition[V]

Out[10]= Null

The call RemProcOnHead[x] returns "Done" with removing from the current session a procedure, function or their list with heading or with list of x headings that are given in string format; headings in call RemProcOnHead[x] is coded according to the format ToString1[x].

55

V.Z. Aladjev, M.L. Shishakov, V.A. Vaganov

The task, closely adjacent to the headings, is to determine the arity of objects. For this purpose, we have created a number of means [8,9]. In particular, the ArityBFM1 procedure defining arity of objects of the type {module, classical function, block} serves as quite useful addition to the procedure Arity and some others.

The procedure call ArityBFM1[x] returns the arity (number of the formal arguments) of a block, function or module x in the format of 4–element list whose the 1st, the 2nd, the 3rd elements define quantity of formal arguments with the patterns "_", "__" and "___" accordingly. While the 4th element defines common quantity of formal arguments which can be different from the quantity of actual arguments. In addition, the x heading should has classical type, i.e. it should not include non–standard, but acceptable methods of headings definition. The unsuccessful procedure call returns $Failed.

The following procedure serves for definition of arity of system functions. The procedure call AritySystemFunction[x] returns the 2– element list whose 1st element defines number of formal arguments, while the second element – quantity of admissible actual arguments. The call with the second optional y argument – an indefinite variable – thru it returns the generalized template of formal arguments.

In[3341]:= AritySystemFunction[x_, y___] := Module[{a, b, c, d, g, p},

If[! SysFunctionQ[x], $Failed, a = SyntaxInformation[x]; If[a == {}, $Failed, c = {0, 0, 0, 0}; b = Map[ToString, a[[1]][[2]]]; b = Map[If[SuffPref[#, "{", 1], "_", If[SuffPref[#, {"Optional", "OptionsPattern"}, 1], "_.", #]] &, b]; If[{y} != {} && ! HowAct[y],

y = Map[ToExpression[ToString[Unique["x"]] <> #] &, b], 77]; Map[If[# == "_", c[[1]]++, If[# == "_.", c[[2]]++, If[# == "__", c[[3]]++, c[[4]]++]]] &, b]; {p, c, d, g} = c;

d = DeleteDuplicates[{p + d, If[d != 0||g != 0, Infinity, p + c]}]; If[d != {0, Infinity}, d, Quiet[x[Null]]; If[Set[p, Messages[x]] == {}, d, p = Select[Map[ToString, Map[Part[#, 2] &, p]], ! StringFreeQ[#, " expected"] &]; p = Map[StringTake[#, {Flatten[StringPosition[#, ";"]][[1]] + 1, –2}] &, p];

p = ToExpression[Flatten[StringCases[p, DigitCharacter ..]]];

If[p == {}, {1}, If[Length[p] > 1, {Min[p], Max[p]}, p]]]]]]]

In[3342]:= {AritySystemFunction[If, g72], g72}

Out[3342]= {{2, 4}, {x16_, x17_, x18_., x19_.}}

56

Mathematica: Functional and procedural programming

2.3. Optional arguments of procedures and functions

When programming procedures and functions often there is an expediency to define some of their formal arguments as optional. In addition, in case of explicit lack of such arguments by a call of tools, they receive values by default. System built–in Mathematica functions use two basic methods for dealing with optional arguments that are suitable for the user tools too. The first method consists in that that a value of each argument x that is coded by pattern "_:" in the form x_:b should be replaced by b, if the argument omitted. Almost all built–in system functions that use this method, omit arguments since the end of the list of formal arguments. So, simple function G[x_:5, y_:7] := {x, y} two optional arguments have, for which values by default – 5 and 7 respectively. As Mathematica system assumes that arguments are omitted since end of the list of formal arguments then we have not a possibility by positionally (in general selectively) do an argument as optional.

In[3376]:= G[x_: 5, y_: 6] := {x, y}

In[3377]:= {G[], G[42, 77], G[42]}

Out[3377]= {{5, 6}, {42, 77}, {42, 6}}

So, from a simple example follows that for function G from two optional arguments the call G[42] refers value by default to the second argument, but not to the first. Therefore this method has a rather limited field of application.

The second method of organization of optional arguments consists in use of explicit names for the optional arguments by allowing to give them values using transformation rules. This method is particularly convenient for means like Plot function which have a rather large number of optional arguments, only a few of which usually need to be set in a particular example. The typical method is that values for so–called named optional arguments can be specified by including the appropriate rules at the end of the arguments at a function call. At determining of the named optional arguments for a procedure or function g, it is conventional to store the default values for these arguments

57

V.Z. Aladjev, M.L. Shishakov, V.A. Vaganov

as a list of transformation rules assigned to Options[g]. So, as a typical example of definition for a tool with zero or more named optional arguments can be:

g[x_, y_, OptionsPattern[]] := Module[{}, x*y]

Then for this means a list of transformation rules assigned to Options[g] is determined

Options[g] = {val1 –> a, val2 –> b}

Whereas expression OptionValue[w] for a named optional argument w has to be included to the body of the tool, in order that this mechanism worked. Below is presented the definition of a function g that allows up to 2 named optional arguments:

In[2114]:= g[x_, y_, OptionsPattern[]] := (OptionValue[val1]*x + OptionValue[val2]*y)/

(OptionValue[val1]*OptionValue[val2]) In[2115]:= Options[g] = {val1 –> 42, val2 –> 47} Out[2115]= {val1 –> 42, val2 –> 47}

In[2116]:= g[90, 500]

Out[2116]= 13640/987 In[2117]:= g[90, 500, val1 –> 77]

Out[2117]= 30430/3619

In[2118]:= g[90, 500, val1 –> 10, val2 –> 100]

Out[2118]= 509/10

From the represented example the second method of work with named optional arguments is rather transparent. You can to familiarize with optional arguments in more detail in [22].

Other way of definition of optional arguments of functions and procedures consists in use of the template "_.", representing an optional argument with a default value specified by built–in Default function – Default[w] = Value. Let's note, the necessary values for call Default[w] for a tool w must always precede an optional argument of the w tool. Values defined for Default[w] are saved in DefaultValues[w]. Fragment below illustrates told:

In[1346]:= Default[w] = 5;

In[1347]:= w[x_., y_., z_.] := {x, y, z}; {w[], w[42, 47], w[42]} Out[1347]= {{5, 5, 5}, {42, 47, 5}, {42, 5, 5}}

58

Mathematica: Functional and procedural programming

More detailed information on this way can be found in [15] and by a call ?Default in the current session of Mathematica. At the same time all considered approaches to the organization of work with optional arguments do not give the chance to define values by default for an arbitrary tuple of formal arguments.

The reception described below on a simple example can be for this purpose used. Definition of a procedure G for which we going to make all three formal arguments x, y and z optional, is made out as follows: Res defines the list of formal arguments in string format, Def determines the list of values by default for all formal arguments, the procedure body is made out in the form "{Body}", moreover, of the G definition is complemented with an obligatory argument Opt which represents the binary list of signs whose elements correspond to Res list elements. The zero element of the Opt list determines non-obligation of the Res list element corresponding to it, and vice versa. After the specified definition of the procedure body (d) the StringReplaceVars [16] procedure which provides substitution in the procedure body of the actual arguments (sign 1) or their values by default (sign 0) is applied to it. So, the procedure call G[x, y, z, Opt] returns the simplified value of the source procedure body on the arguments transferred to it. The simple example visually illustrates told.

In[7]:= G[x_., y_., z_., Opt_] := Module[{Res = {"x", "y", "z"}, Def = Map[ToString1[#] &, {42, 47, 67}], args = Map[ToString1[#] &, {x, y, z}], b, c, d},

d = "Simplify[{b = (x + y)/(x + z); c = b*x*y*z; (b + c)^2}]";

d= StringReplaceVars[d, Map[If[Opt[[#]] == 0, Res[[#]] –> Def[[#]], Res[[#]] –> args[[#]]] &, Range[Length[Res]]]];

ToExpression[d][[1]]]

In[8]:= G[a, s, t, {0, 1, 1}]

Out[8]= ((42 + s)^2*(1 + 42*s*t)^2)/(42 + t)^2 In[9]:= G[a, s, t, {1, 1, 1}]

Out[9]= ((a + s)^2*(1 + a*s*t)^2)/(a + t)^2 In[10]:= G[a, s, t, {0, 0, 0}]

Out[10]= 138557641644601/11881

In certain cases the above reception can be rather useful.

59

V.Z. Aladjev, M.L. Shishakov, V.A. Vaganov

The problem for testing of correctness of the tuple of formal arguments in the user modules, blocks or functions can be solved by procedure whose call CorrTupleArgs[x] returns True if tuple of formal arguments of a procedure or a function x is correct in the sense stated above, and False otherwise [8,16].

On the other hand, the problem of preliminary definition of correctness of the factual arguments passing to a procedure or a function is of a rather interesting. If tool has no mechanisms of testing of actual arguments passing to it at a call, then the call on incorrect actual arguments as a rule is returned unevaluated. The procedure TestActArgs is one of variants of solution of the problem, whose call TestActArgs[x, y] returns empty list if tuple of actual arguments meets the tuple of testing functions of the corresponding formal arguments of x, otherwise the procedure call trough y returns the integer list of numbers of the formal arguments to which inadmissible actual arguments are supposed to be passed [1-16].

Meantime, use of the above procedure assumes that testing for correctness of actual arguments for formal arguments with patterns {"__", "___"} is carried out only for the first elements of tuples of actual arguments passing to formal arguments with the appropriate patterns. Whereas further development of the procedure is left to the interested reader as an useful exercise. In addition, it should be noted the important circumstance. If in the traditional programming languages the identification of an arbitrary procedure or function is made according to its name, in case of Math–language the identification is made according to its heading. This circumstance is caused by that the definition of a procedure or function in the Math-language is made by the manner different from traditional [1]. Simultaneous existence of procedures of the same name with different headings in such situation is admissible as it illustrates a simple fragment:

In[2434]:= M[x_, y_] := Module[{}, x + y];

M[x_] := Module[{}, x^2]; M[y_] := Module[{}, y^3]; M[x___] := Module[{}, {x}]

In[2435]:= Definition[M]

60