Following is the change from calc version 2.10.3t5.38 to date:

    Fixed a bug discovered by Ernest Bowen related to matrix-to-matrix copies.

    Bitwise operations on integers have been extended so that negative
    integers are treated in the same way as the integer types in C.

    Some changes have been made to lib/regress.cal and lib/natnumset.cal.

    Removed V_STRLITERAL and V_STRALLOC string type constants and
    renumbered the V_protection types.

    Added popcnt(x, bitval) builtin which counts the number of
    bits in x that match bitval.

    Misc compiler warning fixes.

    Fixed improper use of putchar() and printf() when printing rationals
    (inside qio.c).

    Fixed previously reported bug in popcnt() in relation to . values.

    Calc man page changes per suggestion from Martin Buck
    <Martin-2.Buck@student.uni-ulm.de>.  The calc man page is
    edited with a few more parameters from the Makefile.

    Misc Makefile changes per Martin Buck <Martin-2.Buck@student.uni-ulm.de>.

    Removed trailing blanks from files.

    Consolidated in the Makefile, where the debug and check rules are found.
    Fixed the regress.cal dependency list.

    Make chk and check will exit with an error if check.awk detects
    a problem in the regression output.  (Martin Buck)

    Fixed print line for test #4404.

    Moved custom.c and custom.h to the upper level to fix unresolved symbols.

    Moved help function processing into help.c.

    Moved nearly everything into libcalc.a to allow programs access to
    higher level calc objects (e.g., list, assoc, matrix, block, ...).

    Renamed PATCH_LEVEL to MAJOR_PATCH and SUB_PATCH_LEVEL to MINOR_PATCH.
    Added integers calc_major_ver, calc_minor_ver, calc_major_patch
    and string calc_minor_patch to libcalc.a.  Added CALC_TITLE to hold
    the "C-style arbitrary precision calculator" string.

    The function version(), now returns a malloced version string
    without the title.

    Consolidated multiple SGI IRIX -n32 sections (for r4k, r5k and r10k)
    into a single section.


Following is the change from calc version 2.10.3t5.34 to 2.10.3t5.37:

    Per request from David I Bell, the README line:

      I am allowing this calculator to be freely distributed for personal uses

    to:

      I am allowing this calculator to be freely distributed for your enjoyment

    Added help files for:

	address agd arrow dereference free freeglobals freeredc freestatics
	gd isptr mattrace oldvalue saveval & * -> and .

    Fixed blkcpy() and copy() arg order and processing.  Now:

	A = blk() = {1,2,3,4}
	B = blk()
	blkcpy(B,A)
	blkcpy(B,A)

    will result in B being twice as long as A.

    Since "make chk" pipes the regression output to awk, we cannot
    assume that stdout and stderr are ttys.  Tests #5985 and #5986
    have been removed for this reason.  (thanks to Martin Buck
    <Martin-2.Buck@student.uni-ulm.de> for this report)

    Fixed the order of prints in regress.cal.  By convention, a print
    of a test line happens after the test.  This is because function
    parsed messages occur after the function is parsed.  Also the
    boolean tesrt of vrfy happens before any print statement.
    Therefore a non-test line is tested and printed as follows:

	y = sha();
	print '7125: y = sha()';

    The perm(a,b) and comb(a,b) have been extented to arbitrary real a and
    integer b.

    Fixed a bug in minv().

    Moved string.c into libcalc.a.

    The NUMBER union was converted back into a flat structure.  Changes
    where 'num' and 'next' symbols were changed to avoid #define conflicts
    were reverse since the #define's needed to support the union went away.

    Removed trailing blanks from files.

    Ernest Bowen <ernie@turing.une.edu.au> sent in the following patch
    which is described in the next 34 points:

    (0) In the past:

		    A = B = strcat("abc", "def");

	would store "abc" and "def" as literal strings never to be freed, and
	store "abcdef" once each for both A and  B.  Now the "abc" and "bcd"
	are freed immediately after they are concatenated and "abcdef" is stored
	only once, just as the number 47 would be stored only once for

		    A = B = 47;

	The new STRING structure that achieves this stores not only the
	address of the first character in the string, but also the "length"
	with which the string was created, the current "links" count, and
	when links == 0 (which indicates the string has been freed) the
	address of the next freed STRING.  Except for the null string "",
	all string values are "allocated"; the concept of literal string
	remains for names of variables, object types and elements, etc.

    (1) strings may now include '\0', as in A = "abc\0def".  In normal printing
	this prints as "abc" and strlen(A) returns 3, but its "real" length
	of 7 is given by size(A). (As before there is an 8th zero character
	and sizeof(A) returns 8.)

    (2) If A is an lvalue whose current value is a string of size n, then
	for 0 <= i < n, A[i] returns the character with index i as an addressed
	octet using the same structure as for blocks, i.e. there is no
	distinction between a string-octet and a block-octet.  The same
	operations and functions can be used for both, and as before, an octet
	is in some respects a number in [0,256) and in others a one-character
	string.  For example, for A = "abc\0def" one will have both A[0] == "a"
	and A[0] == 97.  Assignments to octets can be used to change
	characters in the string, e.g. A[0] = "A", A[1] = 0, A[2] -= 32,
	A[3] = " " will change the above A to "A\0C def".

    (3) "show strings" now displays the indices, links, length, and some or all
	of the early and late characters in all unfreed strings which are values
	of lvalues or occur as "constants" in function definitions,
	using "\n", "\t", "\0", "\252", etc. when appropriate.  For example,
	the string A in (1) would be displayed as in the definition there.
	Only one line is used for each string.  I've also changed the
	analogous "show numbers" so that only some digits of numbers that
	would require more than one line are displayed.

    (4) "show literals" is analogous to "show constants" for number "constants"
	in that it displays only the strings that have been introduced by
	literal strings as in A = "abc".  There is a major difference between
	strings and numbers in that there are operations by which characters
	in any string may be changed.  For example, after A = "abc",
	A[0] = "X" changes A to "Xbc".  It follows that if a literal string
	is to be constant in the sense of never changing, such a character-
	changing operation should never be applied to that string.

	In this connection, it should be noted that if B is string-valued, then

			    A = B

	results in A referring to exactly the same string as B rather than to
	a copy of what is in B.  Thie is like the use of character-pointers in
	C, as in

			    char *s1, *s2;
			    s1 = "abc";
			    s2 = s1;

	To achieve the effect of

			    s2 = (char *) malloc(4);
			    strcpy(s2, s1);

	I have extended the str() function to accept a string as argument.  Then

			    A = str(B);

	will create a new string at a different location from that of B but
	with the same length and characters.  One will then have A == B,
	*A == *B, but &*A != &*B, &A[0] != &B[0].

	To assist in analyzing this sort of thing, I have defined a links()
	function which for number or string valued argument returns the number
	of links to the occurrence of that argument that is being referred to.
	For example, supposing "abc" has not been used earlier:

			    > A = "abc"
			    > links(A)
				    2
			    > links(A)
				    1

	The two links in the first call are to A and the current "oldvalue";
	in the second call, the only link is to A, the oldvalue now being 2.


    (5) strcat(S1, S2, ...) works as before; contribution of a string stops when
	'\0' is encountered.  E.g.

		    strcat("abc\0def", "ghi")

	will return "abcghi".

    (6) For concatenation of full strings I have chosen to follow
	some other languages (like Java, but not Mathematica which uses "<>")
	and use "+" so that, e.g.

		    "abc\0def" + "ghi"

	returns the string "abc\0defghi".  This immediately gives obvious
	meanings to multiplication by positive integers as in

		    2 * "abc" = "abc" + "abc" = "abcabc",

	to negation to reverse as string as in

		    - "abc" = "cba",

	to multiplication by fractions as in

		    0.5 * "abcd" = "ab",

	(where the length is int(0.5 * size("abcd")), and finally, by combining
	these to

		     k * A    and      A * k

	for any real number k and any string A.   In the case of k == 1, these
	return a new string rather than A itself.  (This differs from
	"" + A and A + "" which return A.)

    (7) char(x) has been changed so that it will accept any integer x or octet
	as argument and return a string of size one with character value
	x % 256.  In the past calc has required 0 <= x < 256; now negative
	x is acceptable; for example, 1000 * char(-1) will now produce the
	same as 1000 * "\377" or 1000 * "\xff".

    (8) For a string s, test(s) now returns zero not only for the null string
	"" but also for a string all of whose characters are '\0'.

    (9) Similarly <, <=, etc. now compare all characters including occurrences
	of '\0' until a difference is encountered or the end of a string is
	reached.  If no difference is encountered but one string is longer than
	the other, the longer string is considered as greater even if the
	remaining characters are all '\0'.

    (10) To retain the C sense of comparison of null-terminated strings I have
	 defined strcmp(S1, S2), and then, for completeness, strncmp(S1, S2, n).
	 For similar reasons, strcpy(S1, S2) and strncpy(S1, S2, n) have been
	 defined.

    (11) For strings, I have defined | and & as bitwise "or" and "and"
	 functions, with S1 | S2 having the size of the larger of S1 and S2,
	 S1 & S2 having the size of the smaller of S1 and S2.  By using, say,
	 4-character strings, one can simulate a C integral type so far as the
	 | and & operations are concerned.   It then seemed appropriate to
	 use the operator ~ for a "bitwise complement" as in C.  Thus I have
	 defined ~s for a string s to be the string of the same size as s
	 with each character being complemented by the C ~ operation.

    (12) For boolean algebra work on strings it is convenient also to have
	 the bitwise xor and setminus binary operations.  Using C's '^' for xor
	 would be confusing when this is used elsewhere for powers, so I
	 decided to use ~.  For setminus, I adopted the commonly used '\'.
	 Strings of fixed size n can now be used for a boolean algebra
	 structure with 8 * n elements.  The zero element is n * char(0),
	 the unity is n * char(-1), and one have all of the usual laws like
	 A & (B | C) == A & B | A * C,  A \ B = A & ~B, etc.

    (13) Having extended the bitwise operations for strings, it was appropriate
	 to do the same for integers.  Definitions of the binary ~ and \
	 operations for non-negative integers are straightforward.  For
	 the unary ~ operation, I decided to do what C does with integer
	 types, and defined ~N to be -N - 1.  With the appropriate extensions of
	 |, &, \ and the binary ~, one gets in effect the boolean algebra of
	 finite sets of natural numbers and their complements, by identifying
	 the set with distinct integer elements i_1, i_2, ... with the integer

		    2^i_1 + 2^i_2 + ...

	 For ~N for non-integer real N, I have simply used -N.  There is some
	 logic in this and it is certainly better than an error value.
	 I have not defined the binary operations |, &, ~, \ for non-integral
	 arguments.

	 The use of ~N in this way conflicts with calc's method of displaying
	 a number when it has to be rounded to config("display") decimals.
	 To resolve this, my preference would be to replace the printing of
	 "~" as a prefix by a trailing ellipsis "...", the rounding always
	 being towards zero.  E.g. with config("display", 5), 1/7 would print
	 as ".14285..." rather than "~.14285".   The config("outround")
	 parameter would determine the type of rounding only for the
	 equivalent of config("tilde", 0).

    (14) For objects, users may create their own definitions for binary |,
	 &, ~ and \ with xx_or, xx_and, xx_xor, xx_setminus functions.
	 For unary ~ and \ operations, I have used the names xx_comp and
	 xx_backslash.

    (15) For the obviously useful feature corresponding to cardinality of a
	 set, I have defined #S for a string S to be the number of nonzero bits
	 in S.   For a degree of consistency, it was then appropriate to
	 define #N for a nonnegative integer N to be the number of nonzero bits
	 in the binary representation of N.  I've extended this to arbitrary
	 real N by using in effect #(abs(num(N))).  I feel it is better to make
	 this available to users rather than having #N invoke an error message
	 or return an error value.  For defining #X for an xx-object X, I
	 have used the name xx_content to suggest that it is appropriate for
	 something which has the sense of a content (like number of members of,
	 area, etc.).

    (16) Having recognized # as a token, it seemed appropriate to permit its
	 use for a binary operation.  For real numbers x and y I have defined
	 x # y to be abs(x - y).  (This is often symbolized by x ~ y, but it
	 would be confusing to have x ~ y meaning xor(x,y) for strings and
	 abs(x-y) for numbers.)  Because '#' is commonly called the hash symbol,
	 I have used xx_hashop to permit definition of x # y for xx-objects.

    (17) For a similar reason I've added one line of code to codegen.c so that
	 /A returns the inverse of A.

    (18) Also for a list L, +L now returns the sum of the elements of L.  For
	 an xx object A, +A requires and uses the definition of xx_plus.

    (19) I have given the unary operators ~, #, /, \, and except at the
	 beginning of an expression + and -, the same precedence with
	 right-to-left associativity.  This precedence is now weaker than
	 unary * and &, but stronger than binary & and the shift and power
	 operators.  One difference from before is that now

			    a ^ - b ^ c

	 evaluates as a ^ (- (b ^ c)) rather than a ^ ((- b) ^ c).


    (20) For octets o1, o2, I've defined o1 | o2, o1 & o2, o1 ~ o2, ~o1 so
	 that they return 1-character strings.  #o for an octet o returns the
	 number of nonzero bits in o.

    (21) For substrings I've left substr() essentially as before, but
	 for consistency with the normal block/matrix indexing, I've extended
	 the segment function to accept a string as first argument.  Then

		    segment(A, m, n)

	 returns essentially the string formed from the character with index m
	 to the character with index n, ignoring indices < 0 and indices >=
	 len(A); thus, if m and n are both in [0, size(A))
	 the string is of length abs(m - n) + 1, the order of the characters
	 being reversed if n < m.  Here the indices for a list of size len are
	 0, 1, ..., len - 1.  As it makes some sense, if 0 <= n < size(A),

		    segment(A, n)

	 now returns the one-character string with its character being that with
	 index n in A.  (I've made a corresponding modification to the segment
	 function for lists.)  Some examples, if A = "abcdef",

		    segment(A,2,4) = "cde",

		    segment(A,4,2) = "edc",

		    segment(A,3) = "d",

		    segment(A, -2, 8) = "abcdef",

		    segment(A,7,8) = "".

    (22) As essentially particular cases of segment(), I've defined
	 head(A, n) and tail(A, n) to be the strings formed by the first
	 or last abs(n) characters of A, the strings being4]5O~? reversed '
	 if n is negative.   I've changed the definitions of head and tail for
	 lists to be consistent with this interpretation of negative n.

    (23) Similarly I've left strpos ezsentially as at present, but search
	 and rsearch have been extended to strings.  For example,

		    search(A, B, m, n)

	 returns the index i of the first occurrence of the string B in A
	 if m <= i < n, or the null value if there is no such occurrence.
	 As for other uses of search, negative m is interpreted as
	 size(A) + m, negative n as size(A) + n.  For a match in this
	 search, all size(B) characters, including occurrences of '\0',
	 in B must match successive characters in A.

	 The function rsearch() behaves similarly but searches in reverse order
	 of the indices.

    (24) A string A of length N determines in obvious ways arrays of M = 8 * N
	 bits.  If the characters in increasing index order are c_0, c_1, ...
	 and the bits in increasing order in c_i are b_j, b_j+1, ..., b_j+7
	 where j = 8 * i, I've taken the array of bits determined by A to be

		    b_0, b_1, ..., b_M-1

	 For example, since "a" = char(97) and 97 = 0b01100001, and
	 "b" = char(98) = 0b01100010, the string "ab" determines the 16-bit
	 array

		    1000011001000110

	 in which the bits in the binary representations of "a" and "b" have
	 been reversed.

	 bit with index n in this array.   This is consistent with the use of
	 bit for a number ch in [0,256), i.e. bit(char(ch), n) = bit(ch, n).
	 For n < 0 or n >= size(A), bit(A,n) returns the null value.

    (25) For assigning values to specified bits in a string, I've defined
	 setbit(A, n) and setbit(A, n, v).  The first assigns the value 1 to
	 bit(A, n), the second assigns test(v) to bit(A, n).

    (26) For consistency with the corresponding number operations, the shift
	 operations A << n and A >> n have been defined to give what look
	 like right- and left-shifts, respectively.  For example, "ab" << 2
	 returns the 16-bit array

		    0010000110010001

	 in which the array for "ab" has been moved 2 bits to the right.

    (27) To achieve much the same as the C strcpy and strncpy functions for
	 null-terminated strings, strcpy(S1, S2) and strncpy(S1, S2, n) have
	 been defined.  Unlike the blkcpy() and copy() functions, the copying
	 for these is only from the beginning of the strings.  Also, unlike C,
	 no memory overflow can occur as the copying ceases when size(S1) is
	 reached.  Note that these overwrite the content of S1 (which affects
	 all strings linked to it) as well as returning S1.  Examples:

	    S = strcpy(6 * "x", "abc")      <=>  S = "abc\0xx"

	    S = strcpy(3 * "x", "abcdef")   <=>  S = "abc"

	    S = strncpy(6 * "x", "abcd", 2) <=>  S = "ab\0xxx"

	    S = strncpy(6 * "x", "ab", 4)   <=>  S = "ab\0\0xx"

	    S = strncpy(6 * "x", "ab", 20)  <=>  S = "ab\0\0\0\0"

	 If a new string S not linked to S1 is to be created, this can be
	 achieved by using str(S1) in place of S1.  For example, the strcpy in

	    A = "xxxxxx"
	    S = strcpy(str("xxxxxx"), "abc")

	 would not change the value of A.

    (28) I've extended the definitions of copy(A, B, ssi, num, dsi) and
	 blkcpy(B, A, num, ssi, dsi) to allow for string-to-string copying
	 and block-to-string copying, but num is now an upper bound for the
	 number of characters to be copied - copying will cease before num
	 characters are copied if the end of the data in the source A or the
	 end of the destination B is reached.  As with other character-changing
	 operations, copying to a string B will not change the locations of
	 B[0], B[1], ... or the size of B.

	 In the case of copying a string to itself, characters are copied in
	 order of increasing index, which is different from block-to-block
	 copying where a memmove is used.  This affects only copy from a
	 string to itself.  For example,

		    A = "abcdefg";
		    copy(A, A, , , 2);

	 will result in A == "abababa".  If the overwriting that occurs here
	 is not wanted, one may use

		    A = "abcdefg";
		    copy(str(A), A, , , 2);

	  which results in A == "ababcde".

    (29) perm(a,b) and comb(a,b) have been extended to accept any real a and
	 any integer b except for perm(a, b) with integer a such that b <= a < 0
	 which gives a "division by zero" error.  For positive b, both functions
	 are polynomials in a of degree b;  for negative b, perm(a,b) is a
	 rational function (1/((a + 1) * (a+2) ...) with abs(b) factors in the
	 denominator), and comb(a,b) = 0.  (An obvious "todo" is to extend this
	 to complex or other types of a.)

    (30) Although it is not illegal, it seems pointless to use a comma operator
	 with a constant or simple variable as in

		    > 2 * 3,14159
			    14159
		    > a = 4; b = 5;
		    > A = (a , b + 2);
		    > A
			    7

	 I have added a few lines to addop.c so that when this occurs a
	 "unused value ignored" message and the relevant line number are
	 displayed.  I have found this useful as I occasionally type ','
	 when I mean '.'.

	 There may be one or two other changes resulting from the way I have
	 rewritten the optimization code in addop.c.  I think there was a bug
	 that assumed that PTR_SIZE would be the same as sizeof(long).  By
	 the way, the new OP_STRING is now of index rather than pointer type.
	 It follows that pointers are now used in opcodes only for global
	 variables.  By introducing a table of addresses of global variables
	 like those used for "constants" and "literal strings", the use of
	 pointers in opcodes could be eliminated.

    (31) When calc has executed a quit (or exit) statement in a function or
	 eval evaluation, it has invoked a call to math_error() which causes
	 a long jump to an initial state without freeing any data on the
	 stack, etc.  Maybe more detail should be added to math_error(), but
	 to achieve the freeing of memory for a quit statement and at the same
	 time give more information about its occurrence I have changed the
	 way opcodes.c handles OP_QUIT.  Now it should free the local variables
	 and whatever is on the stack, and display the name and line-number,
	 for each of the functions currently being evaluated.  The last
	 function listed should be the "top-level" one with name "*".
	 Strings being eval-ed will have name "**".

	 Here is a demo:

	    > global a;
	    >
	    > define f(x) {local i = x^2; a++;
	    >> if (x > 5) quit "Too large!"; return i;}
	    f() defined
	    > define g(x) = f(x) + f(2*x);
	    g() defined
	    > g(2)
		    20
	    > g(3)
	    Too large!
		    "f": line 3
		    "g": line 0
		    "*": line 6
	    > eval("g(3)")
	    Too large!
		    "f": line 3
		    "g": line 0
		    "**": line 1
		    "*": line 7
	    > a
		    6

    (32) I've made several small changes like removing

		    if (vp->v_type == V_NUM) {
			    q = qinv(vp->v_num);
			    if (stack->v_type == V_NUM)
				    qfree(stack->v_num);
			    stack->v_num = q;
			    stack->v_type = V_NUM;
			    return;
		    }

	 from the definition of o_invert.  Presumably these lines were intended
	 to speed up execution for the common case of numerical argument.
	 Comparing the runtimes with and without these lines for inverting
	 thousands of large random numbers in a matrix suggest that execution
	 for real numbers is slightly faster without these lines.

	 Maybe this and other similar treatment of "special cases" should be
	 looked at more closely.

    (33) The new lib script lib/natnumset.cal demonstrates how the new
	 string operators and functions may be used for defining and
	 working with sets of natural numbers not exceeding a
	 user-specified bound.


Following is the change from calc version 2.10.3t5.28 to 2.10.3t5.33:

    Added hnrmod(v, h, n, r) builtin to compute:

	v % (h * 2^n + r), h>0, n>0, r = -1, 0 or 1

    Changed lucas.cal and mersenne.cal to make use of hnrmod().

    A number of changes from Ernest Bowen:

	(1) introduction of unary & and * analogous to those in C;

	    For an lvalue var, &var returns what I call a
	    value-pointer; this is a constant which may be assigned to
	    a variable as in p = &var, and then *p in expressions has
	    the same effect as var.  Here is a simple example of their use:

		> define s(L) {local v=0; while (size(L)) v+= *pop(L);return v;}
		s() defined
		> global a = 1, b = 2;
		> L = list(&a, &b);
		> print s(L)
		3
		> b = 3;
		> print s(L)
		4

	    Octet-pointers, number-pointers, and string-pointers in
	    much the same way, but have not attempted to do much with
	    the latter two.

	    To print a pointer, use the "%p" specifier.

	    Some arithmetic operations has been defined for corresponding
	    C operations.  For example:

		> A = mat[4];
		> p = &A[0];
		> *(p+2) == A[2]
		> ++p
		> *p == A[1]

	    There is at present no protection against "illegal" use of &
	    and *, e.g. if one attempts here to assign a value to *(p+5),
	    or to use p after assigning another value to A.

	    NOTE: Unlike C, in calc &A[0] and A are quite different things.

	    NOTE: If the current value of a variable X is an octet,
	    number or string, *X may be used to to return the value of
	    X; in effect X is an address and *X is the value at X.

	    Added isptr(p) builtin to return 0 is p is not a pointer,
	    >0 if it is a pointer.  The value of isptr(p) comes from the
	    V_XYZ #define (see the top of value.h) of the value to which
	    p points.

	    To allow & to be used as a C-like address operator, use of it
	    has been dropped in calls to user-defined functions.  For the
	    time being I have replaced it by the back-quote `.  For example:

		> global a
		> define f(a,b) = a = b
		> f(&a,5)
		> print a
		0
		> f(`a,5)
		> print a
		5

	   However, one may use & in a similar way as in:

		> define g(a,b) = *a = b
		> g(&a, 7)
		> print a
		7

	   There is no hashvalue for pointers. Thus, like error values,
	   they cannot be used as indices in an association.

	   The -> also works in calc. For example:

		> obj xy {x,y}
		> obj uvw {u, v, w}
		> obj xy A = {1,2}
		> obj uvw B = {3,4,5}
		> p = &A
		> q = &B
		> p->x
			1
		> p->y = 6
		> A
			obj xy {1, 6}
		> q -> u
			3
		> p->y = q
		> A
			obj xy {1, v-ptr: 1400474c0}
		> p->y->u
			3
		> p->y->u = 7
		> B
			obj uvw {7, 4, 5}
		> p -> y = p
		> A
			obj xy {1, v-ptr: 140047490}
		> p -> y -> x
			1
		> p->y->y
			v-ptr: 140047490
		> p->y->y-> x
			1
		> p->y->y->x = 8
		> A
			obj xy {8, v-ptr: 140047490}


	(2) a method of "protecting" variables;

	    For the various kinds of "protection", of an l_value var,
	    bits of var->v_subtype, of which only bits 0 and 1 have been
	    used in the past to indicate literal and allocated strings.
	    This has meant initialization of var->v_subtype when a new var
	    is introduced, and for assignments, etc., examination of the
	    appropriate bits to confirm that the operation is to be permitted.

	    See help/protect for details.

	(3) automatic "freeing" of constants that are no longer required.

	    For the "freeing" of constants, the definition of a NUMBER
	    structure so that a NUMBER * q could be regarded as a
	    pointing to a "freed number" if q->links = 0.

	    The old q->num was changed to a union q->nu which had a pointer
	    to the old q->num if q->links > 0 and to the next freed number
	    if q->links = 0.  The old "num" is #defined to "nu->n_num".

	    The prior method calc has used for handling "constants" amounted
	    to leakage.  After:

		> define f(x) = 27 + x;
		> a = 27;

	    It is of course necessary for the constant 27 to be stored, but
	    if one now redefines f and a by:

		> define f(x) = 45 + x;
		> a = 45;

	    There seems little point in retaining 27 as a constant and
	    therefore using up memory.  If this example seems trivial,
	    replace 27 with a few larger numbers like 2e12345, or better,
	    -2e12345, for which calc needs memory for both 2e12345 and
	    -2e12345!

	    Constants are automatically freed a definition when a
	    function is re- or un-defined.

	    The qalloc(q) and qfree(q) functions have been changed so
	    that that q->links = 0 is permitted and indicates that q
	    has been freed.  If a number has been introduced as a
	    constant, i.e. by a literal numeral as in the above
	    examples, its links becoming zero indicates that it is no
	    longer required and its position in the table of constants
	    becomes available for a later new constant.

	(4) extension of transcendental functions like tan, tanh, etc.
	    to complex arguments

	(5) definition of gd(z) and agd(z), i.e. the gudermannian and
	    inverse gudermannian

	(6) introduction of show options for displaying information about
	    current constants, global variables, static variables, and cached
	    redc moduli.

	    To help you follow what is going on, the following show
	    items have been introduced:

		show constants ==> display the currently stored constants
		show numbers   ==> display the currently stored numbers
		show redcdata  ==> display the currently stored redc moduli
		show statics   ==> display info about static variables
		show real      ==> display only real-valued variables

	    The constants are automatically initialized as constants and
	    should always appear, with links >= 1, in in the list of constants.

	    The show command:

		show globals

	    has been redefined so that it gives information about all
	    current global and still active static variables.

	(7) definition of functions for freeing globals, statics, redc values

	    To free memory used by different kinds of variable, the following
	    builtins have been added:

		freeglobals();		/* free all globals */
		freestatics();		/* free all statics */
		freeredc();		/* free redc moduli */
		free(a, b, ...);	/* free specific variables */

	   NOTE: These functions do not "undefine" the variables, but
	   have the effect of assigning the null value to them, and so
	   frees the memory used for elements of a list, matrix or object.

	   See 10) below for info about "undefine *".

	(8) enhancement of handling of "old value": having it return an
	    lvalue and giving option of disabling updating.

	    Now, by default, "." return an lvalue with the appropriate
	    value instead of copying the old value.

	    So that a string of commands may be given without changing
	    the "oldvalue", the new builtin:

		saveval(0)

	    function simply disables the updating of the "." value.
	    The default updating can be resumed by calling:

		saveval(1)

	    The "." value:

		> 2 + 2
		4
		> .
		4

	    can now be treated as an unnamed variable.  For example:

		> mat x[3,3]={1,2,3,4,5,6,7,8,9}
		> x
		> print .[1,2]
		6

	(9) for a list L defining L[i] to be same as L[[i]]

	(10) extending undefine to permit its application to all user-defined
	     functions by using "undefine *".

	     The command:

		undefine *

	     undefines all current user-defined functions.  After
	     executing all the above freeing functions (and if
	     necessary free(.) to free the current "old value"), the
	     only remaining numbers as displayed by:

		show numbers

	     should be those associated with epsilon(), and if it has been
	     called, qpi().

	(11) storing the most recently calculated value of qpi(epsilon)i and
	     epsilon so that when called again with the same epsilon it
	     is copied rather than recalculateed.

	(12) defining trace() for square matrices

	(13) expression in parentheses may now be followed by a qualifier
	     computible with its type

	     When an expression in parentheses evaluates to an lvalue
	     whose current value is a matrix, list or object, it may
	     now be followed by a qualifier computible with its type.

	     For example:

		> A = list(1,2,4);
		> B = mat[2,2] = {5,6,7,8};
		> define f(x) = (x ? A : B)[[1]];
		> print f(1), f(0)
		2 6

		> obj xy {x,y}
		> C = obj xy = {4,5}
		> p = &C
		> *p.x
		Not indexing matrix or object
		> (*p).x
		4

	(14) swap(a,b) now permits swapping of octets in the same or different
	     blocks.

	     For example:

		> A = blk() = {1,2,3}
		> B = blk() = {4,5,6}
		> swap(A[0], B[2])
		> A
			chunksize = 256, maxsize = 256, datalen = 3
			060203

    A few bug fixes from Ernest Bowen:

	B1: qcmpi(q, n) in qmath.c sometimes gave the wrong result if
		LONG_BITS > BASEB, len = 1 and nf = 0, since it then
		reduces to the value of (nf != q->num.v[1]) in which
		q->num.v[1] is not part of the size-1 array of HALFs for
		q->num.  At present this is used only for changing opcodes
		for ^2 and ^4 from sequences involving OP_POWER to
		sequences using OP_SQUARE, which has no effect on the
		results of calculations.

	B2: in matdet(m) in matfunc.c, a copy of the matrix m was not freed
		when the determinant turned out have zero value.

	B3: in f_search() in func.c, a qlinking of the NUMBER * storing the
		the size of a file was not qfreed.

	B4: in comalloc() in commath.c the initial zero values for real and
		imag parts are qlinked but not qfreed when nonzero values are
		assigned to them.  Rather than changing
		the definition of comalloc(), I have included any relevant
		qfrees with the calls to comalloc() as in
			c = comalloc();
			qfree(c->real);
			c->real = ...

	B5: in calls to matsum(), zeros are qlinked but not qfreed.  Rather
		than changing addnumeric(), I have changed the definition
		of matsum(m) so that it simply adds the components of m,
		which requires only that the relevant additions be defined,
		not that all components of m be numbers.


    Simple arithmetic expressions with literal numbers are evaluated
    during compilation rather than   The val representations of "a" and "b" have
	 been reversed.

	 bit with index n in this array.   This is consistent with the use of
	 bit for a number ch in [0,256), i.e. bit(char(ch), n) = bit(ch, n).
	 For n < 0 or n >= size(A), bit(A,n) returns the null value.

    (25) For assigning values to specified bits in a string, I've defined
	 setbit(A, n) and setbit(A, n, v).  The first assigns the value 1 to
	 bit(A, n), the second assigns test(v) to bit(A, n).

    (26) For consistency with the corresponding number operations, the shift
	 operations A << n and A >> n have been defined to give what look
	 like right- and left-shifts, respectively.  For example, "ab" << 2
	 returns the 16-bit array

		    0010000110010001

	 in which the array for "ab" has been moved 2 bits to the right.

    (27) To achieve much the same as the C strcpy and strncpy functions for
	 null-terminated strings, strcpy(S1, S2) and strncpy(S1, S2, n) have
	 been defined.  Unlike the blkcpy() and copy() functions, the copying
	 for these is only from the beginning of the strings.  Also, unlike C,
	 no memory overflow can occur as the copying ceases when size(S1) is
	 reached.  Note that these overwrite the content of S1 (which affects
	 all strings linked to it) as well as returning S1.  Examples:

	    S = strcpy(6 * "x", "abc")      <=>  S = "abc\0xx"

	    S = strcpy(3 * "x", "abcdef")   <=>  S = "abc"

	    S = strncpy(6 * "x", "abcd", 2) <=>  S = "ab\0xxx"

	    S = strncpy(6 * "x", "ab", 4)   <=>  S = "ab\0\0xx"

	    S = strncpy(6 * "x", "ab", 20)  <=>  S = "ab\0\0\0\0"

	 If a new string S not linked to S1 is to be created, this can be
	 achieved by using str(S1) in place of S1.  For example, the strcpy in

	    A = "xxxxxx"
	    S = strcpy(str("xxxxxx"), "abc")

	 would not change the value of A.

    (28) I've extended the definitions of copy(A, B, ssi, num, dsi) and
	 blkcpy(B, A, num, ssi, dsi) to allow for string-to-string copying
	 and block-to-string copying, but num is now an upper bound for the
	 number of characters to be copied - copying will cease before num
	 characters are copied if the end of the data in the source A or the
	 end of the destination B is reached.  As with other character-changing
	 operations, copying to a string B will not change the locations of
	 B[0], B[1], ... or the size of B.

	 In the case of copying a string to itself, characters are copied in
	 order of increasing index, which is different from block-to-block
	 copying where a memmove is used.  This affects only copy from a
	 string to itself.  For example,

		    A = "abcdefg";
		    copy(A, A, , , 2);

	 will result in A == "abababa".  If the overwriting that occurs here
	 is not wanted, one may use

		    A = "abcdefg";
		    copy(str(A), A, , , 2);

	  which results in A == "ababcde".

    (29) perm(a,b) and comb(a,b) have been extended to accept any real a and
	 any integer b except for perm(a, b) with integer a such that b <= a < 0
	 which gives a "division by zero" error.  For positive b, both functions
	 are polynomials in a of degree b;  for negative b, perm(a,b) is a
	 rational function (1/((a + 1) * (a+2) ...) with abs(b) factors in the
	 denominator), and comb(a,b) = 0.  (An obvious "todo" is to extend this
	 to complex or other types of a.)

    (30) Although it is not illegal, it seems pointless to use a comma operator
	 with a constant or simple variable as in

		    > 2 * 3,14159
			    14159
		    > a = 4; b = 5;
		    > A = (a , b + 2);
		    > A
			    7

	 I have added a few lines to addop.c so that when this occurs a
	 "unused value ignored" message and the relevant line number are
	 displayed.  I have found this useful as I occasionally type ','
	 when I mean '.'.

	 There may be one or two other changes resulting from the way I have
	 rewritten the optimization code in addop.c.  I think there was a bug
	 that assumed that PTR_SIZE would be the same as sizeof(long).  By
	 the way, the new OP_STRING is now of index rather than pointer type.
	 It follows that pointers are now used in opcodes only for global
	 variables.  By introducing a table of addresses of global variables
	 like those used for "constants" and "literal strings", the use of
	 pointers in opcodes could be eliminated.

    (31) When calc has executed a quit (or exit) statement in a function or
	 eval evaluation, it has invoked a call to math_error() which causes
	 a long jump to an initial state without freeing any data on the
	 stack, etc.  Maybe more detail should be added to math_error(), but
	 to achieve the freeing of memory for a quit statement and at the same
	 time give more information about its occurrence I have changed the
	 way opcodes.c handles OP_QUIT.  Now it should free the local variables
	 and whatever is on the stack, and display the name and line-number,
	 for each of the functions currently being evaluated.  The last
	 function listed should be the "top-level" one with name "*".
	 Strings being eval-ed will have name "**".

	 Here is a demo:

	    > global a;
	    >
	    > define f(x) {local i = x^2; a++;
	    >> if (x > 5) quit "Too large!"; return i;}
	    f() defined
	    > define g(x) = f(x) + f(2*x);
	    g() defined
	    > g(2)
		    20
	    > g(3)
	    Too large!
		    "f": line 3
		    "g": line 0
		    "*": line 6
	    > eval("g(3)")
	    Too large!
		    "f": line 3
		    "g": line 0
		    "**": line 1
		    "*": line 7
	    > a
		    6

    (32) I've made several small changes like removing

		    if (vp->v_type == V_NUM) {
			    q = qinv(vp->v_num);
			    if (stack->v_type == V_NUM)
				    qfree(stack->v_num);
			    stack->v_num = q;
			    stack->v_type = V_NUM;
			    return;
		    }

	 from the definition of o_invert.  Presumably these lines were intended
	 to speed up execution for the common case of numerical argument.
	 Comparing the runtimes with and without these lines for inverting
	 thousands of large random numbers in a matrix suggest that execution
	 for real numbers is slightly faster without these lines.

	 Maybe this and other similar treatment of "special cases" should be
	 looked at more closely.

    (33) The new lib script lib/natnumset.cal demonstrates how the new
	 string operators and functions may be used for defining and
	 working with sets of natural numbers not exceeding a
	 user-specified bound.


Following is the change from calc version 2.10.3t5.28 to 2.10.3t5.33:

    Added hnrmod(v, h, n, r) builtin to compute:

	v % (h * 2^n + r), h>0, n>0, r = -1, 0 or 1

    Changed lucas.cal and mersenne.cal to make use of hnrmod().

    A number of changes from Ernest Bowen:

	(1) introduction of unary & and * analogous to those in C;

	    For an lvalue var, &var returns what I call a
	    value-pointer; this is a constant which may be assigned to
	    a variable as in p = &var, and then *p in expressions has
	    the same effect as var.  Here is a simple example of their use:

		> define s(L) {local v=0; while (size(L)) v+= *pop(L);return v;}
		s() defined
		> global a = 1, b = 2;
		> L = list(&a, &b);
		> print s(L)
		3
		> b = 3;
		> print s(L)
		4

	    Octet-pointers, number-pointers, and string-pointers in
	    much the same way, but have not attempted to do much with
	    the latter two.

	    To print a pointer, use the "%p" specifier.

	    Some arithmetic operations has been defined for corresponding
	    C operations.  For example:

		> A = mat[4];
		> p = &A[0];
		> *(p+2) == A[2]
		> ++p
		> *p == A[1]

	    There is at present no protection against "illegal" use of &
	    and *, e.g. if one attempts here to assign a value to *(p+5),
	    or to use p after assigning another value to A.

	    NOTE: Unlike C, in calc &A[0] and A are quite different things.

	    NOTE: If the current value of a variable X is an octet,
	    number or string, *X may be used to to return the value of
	    X; in effect X is an address and *X is the value at X.

	    Added isptr(p) builtin to return 0 is p is not a pointer,
	    >0 if it is a pointer.  The value of isptr(p) comes from the
	    V_XYZ #define (see the top of value.h) of the value to which
	    p points.

	    To allow & to be used as a C-like address operator, use of it
	    has been dropped in calls to user-defined functions.  For the
	    time being I have replaced it by the back-quote `.  For example:

		> global a
		> define f(a,b) = a = b
		> f(&a,5)
		> print a
		0
		> f(`a,5)
		> print a
		5

	   However, one may use & in a similar way as in:

		> define g(a,b) = *a = b
		> g(&a, 7)
		> print a
		7

	   There is no hashvalue for pointers. Thus, like error values,
	   they cannot be used as indices in an association.

	   The -> also works in calc. For example:

		> obj xy {x,y}
		> obj uvw {u, v, w}
		> obj xy A = {1,2}
		> obj uvw B = {3,4,5}
		> p = &A
		> q = &B
		> p->x
			1
		> p->y = 6
		> A
			obj xy {1, 6}
		> q -> u
			3
		> p->y = q
		> A
			obj xy {1, v-ptr: 1400474c0}
		> p->y->u
			3
		> p->y->u = 7
		> B
			obj uvw {7, 4, 5}
		> p -> y = p
		> A
			obj xy {1, v-ptr: 140047490}
		> p -> y -> x
			1
		> p->y->y
			v-ptr: 140047490
		> p->y->y-> x
			1
		> p->y->y->x = 8
		> A
			obj xy {8, v-ptr: 140047490}


	(2) a method of "protecting" variables;

	    For the various kinds of "protection", of an l_value var,
	    bits of var->v_subtype, of which only bits 0 and 1 have been
	    used in the past to indicate literal and allocated strings.
	    This has meant initialization of var->v_subtype when a new var
	    is introduced, and for assignments, etc., examination of the
	    appropriate bits to confirm that the operation is to be permitted.

	    See help/protect for details.

	(3) automatic "freeing" of constants that are no longer required.

	    For the "freeing" of constants, the definition of a NUMBER
	    structure so that a NUMBER * q could be regarded as a
	    pointing to a "freed number" if q->links = 0.

	    The old q->num was changed to a union q->nu which had a pointer
	    to the old q->num if q->links > 0 and to the next freed number
	    if q->links = 0.  The old "num" is #defined to "nu->n_num".

	    The prior method calc has used for handling "constants" amounted
	    to leakage.  After:

		> define f(x) = 27 + x;
		> a = 27;

	    It is of course necessary for the constant 27 to be stored, but
	    if one now redefines f and a by:

		> define f(x) = 45 + x;
		> a = 45;

	    There seems little point in retaining 27 as a constant and
	    therefore using up memory.  If this example seems trivial,
	    replace 27 with a few larger numbers like 2e12345, or better,
	    -2e12345, for which calc needs memory for both 2e12345 and
	    -2e12345!

	    Constants are automatically freed a definition when a
	    function is re- or un-defined.

	    The qalloc(q) and qfree(q) functions have been changed so
	    that that q->links = 0 is permitted and indicates that q
	    has been freed.  If a number has been introduced as a
	    constant, i.e. by a literal numeral as in the above
	    examples, its links becoming zero indicates that it is no
	    longer required and its position in the table of constants
	    becomes available for a later new constant.

	(4) extension of transcendental functions like tan, tanh, etc.
	    to complex arguments

	(5) definition of gd(z) and agd(z), i.e. the gudermannian and
	    inverse gudermannian

	(6) introduction of show options for displaying information about
	    current constants, global variables, static variables, and cached
	    redc moduli.

	    To help you follow what is going on, the following show
	    items have been introduced:

		show constants ==> display the currently stored constants
		show numbers   ==> display the currently stored numbers
		show redcdata  ==> display the currently stored redc moduli
		show statics   ==> display info about static variables
		show real      ==> display only real-valued variables

	    The constants are automatically initialized as constants and
	    should always appear, with links >= 1, in in the list of constants.

	    The show command:

		show globals

	    has been redefined so that it gives information about all
	    current global and still active static variables.

	(7) definition of functions for freeing globals, statics, redc values

	    To free memory used by different kinds of variable, the following
	    builtins have been added:

		freeglobals();		/* free all globals */
		freestatics();		/* free all statics */
		freeredc();		/* free redc moduli */
		free(a, b, ...);	/* free specific variables */

	   NOTE: These functions do not "undefine" the variables, but
	   have the effect of assigning the null value to them, and so
	   frees the memory used for elements of a list, matrix or object.

	   See 10) below for info about "undefine *".

	(8) enhancement of handling of "old value": having it return an
	    lvalue and giving option of disabling updating.

	    Now, by default, "." return an lvalue with the appropriate
	    value instead of copying the old value.

	    So that a string of commands may be given without changing
	    the "oldvalue", the new builtin:

		saveval(0)

	    function simply disables the updating of the "." value.
	    The default updating can be resumed by calling:

		saveval(1)

	    The "." value:

		> 2 + 2
		4
		> .
		4

	    can now be treated as an unnamed variable.  For example:

		> mat x[3,3]={1,2,3,4,5,6,7,8,9}
		> x
		> print .[1,2]
		6

	(9) for a list L defining L[i] to be same as L[[i]]

	(10) extending undefine to permit its application to all user-defined
	     functions by using "undefine *".

	     The command:

		undefine *

	     undefines all current user-defined functions.  After
	     executing all the above freeing functions (and if
	     necessary free(.) to free the current "old value"), the
	     only remaining numbers as displayed by:

		show numbers

	     should be those associated with epsilon(), and if it has been
	     called, qpi().

	(11) storing the most recently calculated value of qpi(epsilon)i and
	     epsilon so that when called again with the same epsilon it
	     is copied rather than recalculateed.

	(12) defining trace() for square matrices

	(13) expression in parentheses may now be followed by a qualifier
	     computible with its type

	     When an expression in parentheses evaluates to an lvalue
	     whose current value is a matrix, list or object, it may
	     now be followed by a qualifier computible with its type.

	     For example:

		> A = list(1,2,4);
		> B = mat[2,2] = {5,6,7,8};
		> define f(x) = (x ? A : B)[[1]];
		> print f(1), f(0)
		2 6

		> obj xy {x,y}
		> C = obj xy = {4,5}
		> p = &C
		> *p.x
		Not indexing matrix or object
		> (*p).x
		4

	(14) swap(a,b) now permits swapping of octets in the same or different
	     blocks.

	     For example:

		> A = blk() = {1,2,3}
		> B = blk() = {4,5,6}
		> swap(A[0], B[2])
		> A
			chunksize = 256, maxsize = 256, datalen = 3
			060203

    A few bug fixes from Ernest Bowen:

	B1: qcmpi(q, n) in qmath.c sometimes gave the wrong result if
		LONG_BITS > BASEB, len = 1 and nf = 0, since it then
		reduces to the value of (nf != q->num.v[1]) in which
		q->num.v[1] is not part of the size-1 array of HALFs for
		q->num.  At present this is used only for changing opcodes
		for ^2 and ^4 from sequences involving OP_POWER to
		sequences using OP_SQUARE, which has no effect on the
		results of calculations.

	B2: in matdet(m) in matfunc.c, a copy of the matrix m was not freed
		when the determinant turned out have zero value.

	B3: in f_search() in func.c, a qlinking of the NUMBER * storing the
		the size of a file was not qfreed.

	B4: in comalloc() in commath.c the initial zero values for real and
		imag parts are qlinked but not qfreed when nonzero values are
		assigned to them.  Rather than changing
		the definition of comalloc(), I have included any relevant
		qfrees with the calls to comalloc() as in
			c = comalloc();
			qfree(c->real);
			c->real = ...

	B5: in calls to matsum(), zeros are qlinked but not qfreed.  Rather
		than changing addnumeric(), I have changed the definition
		of matsum(m) so that it simply adds the components of m,
		which requires only that the relevant additions be defined,
		not that all components of m be numbers.


    Simple arithmetic expressions with literal numbers are evaluated
    during compilation rather than   The val representations of "a" and "b" have
	 been reversed.

	 bit with index n in this array.   This is consistent with the use of
	 bit for a number ch in [0,256), i.e. bit(char(ch), n) = bit(ch, n).
	 For n < 0 or n >= size(A), bit(A,n) returns the null value.

    (25) For assigning values to specified bits in a string, I've defined
	 setbit(A, n) and setbit(A, n, v).  The first assigns the value 1 to
	 bit(A, n), the second assigns test(v) to bit(A, n).

    (26) For consistency with the corresponding number operations, the shift
	 operations A << n and A >> n have been defined to give what look
	 like right- and left-shifts, respectively.  For example, "ab" << 2
	 returns the 16-bit array

		    0010000110010001

	 in which the array for "ab" has been moved 2 bits to the right.

    (27) To achieve much the same as the C strcpy and strncpy functions for
	 null-terminated strings, strcpy(S1, S2) and strncpy(S1, S2, n) have
	 been defined.  Unlike the blkcpy() and copy() functions, the copying
	 for these is only from the beginning of the strings.  Also, unlike C,
	 no memory overflow can occur as the copying ceases when size(S1) is
	 reached.  Note that these overwrite the content of S1 (which affects
	 all strings linked to it) as well as returning S1.  Examples:

	    S = strcpy(6 * "x", "abc")      <=>  S = "abc\0xx"

	    S = strcpy(3 * "x", "abcdef")   <=>  S = "abc"

	    S = strncpy(6 * "x", "abcd", 2) <=>  S = "ab\0xxx"

	    S = strncpy(6 * "x", "ab", 4)   <=>  S = "ab\0\0xx"

	    S = strncpy(6 * "x", "ab", 20)  <=>  S = "ab\0\0\0\0"

	 If a new string S not linked to S1 is to be created, this can be
	 achieved by using str(S1) in place of S1.  For example, the strcpy in

	    A = "xxxxxx"
	    S = strcpy(str("xxxxxx"), "abc")

	 would not change the value of A.

    (28) I've extended the definitions of copy(A, B, ssi, num, dsi) and
	 blkcpy(B, A, num, ssi, dsi) to allow for string-to-string copying
	 and block-to-string copying, but num is now an upper bound for the
	 number of characters to be copied - copying will cease before num
	 characters are copied if the end of the data in the source A or the
	 end of the destination B is reached.  As with other character-changing
	 operations, copying to a string B will not change the locations of
	 B[0], B[1], ... or the size of B.

	 In the case of copying a string to itself, characters are copied in
	 order of increasing index, which is different from block-to-block
	 copying where a memmove is used.  This affects only copy from a
	 string to itself.  For example,

		    A = "abcdefg";
		    copy(A, A, , , 2);

	 will result in A == "abababa".  If the overwriting that occurs here
	 is not wanted, one may use

		    A = "abcdefg";
		    copy(str(A), A, , , 2);

	  which results in A == "ababcde".

    (29) perm(a,b) and comb(a,b) have been extended to accept any real a and
	 any integer b except for perm(a, b) with integer a such that b <= a < 0
	 which gives a "division by zero" error.  For positive b, both functions
	 are polynomials in a of degree b;  for negative b, perm(a,b) is a
	 rational function (1/((a + 1) * (a+2) ...) with abs(b) factors in the
	 denominator), and comb(a,b) = 0.  (An obvious "todo" is to extend this
	 to complex or other types of a.)

    (30) Although it is not illegal, it seems pointless to use a comma operator
	 with a constant or simple variable as in

		    > 2 * 3,14159
			    14159
		    > a = 4; b = 5;
		    > A = (a , b + 2);
		    > A
			    7

	 I have added a few lines to addop.c so that when this occurs a
	 "unused value ignored" message and the relevant line number are
	 displayed.  I have found this useful as I occasionally type ','
	 when I mean '.'.

	 There may be one or two other changes resulting from the way I have
	 rewritten the optimization code in addop.c.  I think there was a bug
	 that assumed that PTR_SIZE would be the same as sizeof(long).  By
	 the way, the new OP_STRING is now of index rather than pointer type.
	 It follows that pointers are now used in opcodes only for global
	 variables.  By introducing a table of addresses of global variables
	 like those used for "constants" and "literal strings", the use of
	 pointers in opcodes could be eliminated.

    (31) When calc has executed a quit (or exit) statement in a function or
	 eval evaluation, it has invoked a call to math_error() which causes
	 a long jump to an initial state without freeing any data on the
	 stack, etc.  Maybe more detail should be added to math_error(), but
	 to achieve the freeing of memory for a quit statement and at the same
	 time give more information about its occurrence I have changed the
	 way opcodes.c handles OP_QUIT.  Now it should free the local variables
	 and whatever is on the stack, and display the name and line-number,
	 for each of the functions currently being evaluated.  The last
	 function listed should be the "top-level" one with name "*".
	 Strings being eval-ed will have name "**".

	 Here is a demo:

	    > global a;
	    >
	    > define f(x) {local i = x^2; a++;
	    >> if (x > 5) quit "Too large!"; return i;}
	    f() defined
	    > define g(x) = f(x) + f(2*x);
	    g() defined
	    > g(2)
		    20
	    > g(3)
	    Too large!
		    "f": line 3
		    "g": line 0
		    "*": line 6
	    > eval("g(3)")
	    Too large!
		    "f": line 3
		    "g": line 0
		    "**": line 1
		    "*": line 7
	    > a
		    6

    (32) I've made several small changes like removing

		    if (vp->v_type == V_NUM) {
			    q = qinv(vp->v_num);
			    if (stack->v_type == V_NUM)
				    qfree(stack->v_num);
			    stack->v_num = q;
			    stack->v_type = V_NUM;
			    return;
		    }

	 from the definition of o_invert.  Presumably these lines were intended
	 to speed up execution for the common case of numerical argument.
	 Comparing the runtimes with and without these lines for inverting
	 thousands of large random numbers in a matrix suggest that execution
	 for real numbers is slightly faster without these lines.

	 Maybe this and other similar treatment of "special cases" should be
	 looked at more closely.

    (33) The new lib script lib/natnumset.cal demonstrates how the new
	 string operators and functions may be used for defining and
	 working with sets of natural numbers not exceeding a
	 user-specified bound.


Following is the change from calc version 2.10.3t5.28 to 2.10.3t5.33:

    Added hnrmod(v, h, n, r) builtin to compute:

	v % (h * 2^n + r), h>0, n>0, r = -1, 0 or 1

    Changed lucas.cal and mersenne.cal to make use of hnrmod().

    A number of changes from Ernest Bowen:

	(1) introduction of unary & and * analogous to those in C;

	    For an lvalue var, &var returns what I call a
	    value-pointer; this is a constant which may be assigned to
	    a variable as in p = &var, and then *p in expressions has
	    the same effect as var.  Here is a simple example of their use:

		> define s(L) {local v=0; while (size(L)) v+= *pop(L);return v;}
		s() defined
		> global a = 1, b = 2;
		> L = list(&a, &b);
		> print s(L)
		3
		> b = 3;
		> print s(L)
		4

	    Octet-pointers, number-pointers, and string-pointers in
	    much the same way, but have not attempted to do much with
	    the latter two.

	    To print a pointer, use the "%p" specifier.

	    Some arithmetic operations has been defined for corresponding
	    C operations.  For example:

		> A = mat[4];
		> p = &A[0];
		> *(p+2) == A[2]
		> ++p
		> *p == A[1]

	    There is at present no protection against "illegal" use of &
	    and *, e.g. if one attempts here to assign a value to *(p+5),
	    or to use p after assigning another value to A.

	    NOTE: Unlike C, in calc &A[0] and A are quite different things.

	    NOTE: If the current value of a variable X is an octet,
	    number or string, *X may be used to to return the value of
	    X; in effect X is an address and *X is the value at X.

	    Added isptr(p) builtin to return 0 is p is not a pointer,
	    >0 if it is a pointer.  The value of isptr(p) comes from the
	    V_XYZ #define (see the top of value.h) of the value to which
	    p points.

	    To allow & to be used as a C-like address operator, use of it
	    has been dropped in calls to user-defined functions.  For the
	    time being I have replaced it by the back-quote `.  For example:

		> global a
		> define f(a,b) = a = b
		> f(&a,5)
		> print a
		0
		> f(`a,5)
		> print a
		5

	   However, one may use & in a similar way as in:

		> define g(a,b) = *a = b
		> g(&a, 7)
		> print a
		7

	   There is no hashvalue for pointers. Thus, like error values,
	   they cannot be used as indices in an association.

	   The -> also works in calc. For example:

		> obj xy {x,y}
		> obj uvw {u, v, w}
		> obj xy A = {1,2}
		> obj uvw B = {3,4,5}
		> p = &A
		> q = &B
		> p->x
			1
		> p->y = 6
		> A
			obj xy {1, 6}
		> q -> u
			3
		> p->y = q
		> A
			obj xy {1, v-ptr: 1400474c0}
		> p->y->u
			3
		> p->y->u = 7
		> B
			obj uvw {7, 4, 5}
		> p -> y = p
		> A
			obj xy {1, v-ptr: 140047490}
		> p -> y -> x
			1
		> p->y->y
			v-ptr: 140047490
		> p->y->y-> x
			1
		> p->y->y->x = 8
		> A
			obj xy {8, v-ptr: 140047490}


	(2) a method of "protecting" variables;

	    For the various kinds of "protection", of an l_value var,
	    bits of var->v_subtype, of which only bits 0 and 1 have been
	    used in the past to indicate literal and allocated strings.
	    This has meant initialization of var->v_subtype when a new var
	    is introduced, and for assignments, etc., examination of the
	    appropriate bits to confirm that the operation is to be permitted.

	    See help/protect for details.

	(3) automatic "freeing" of constants that are no longer required.

	    For the "freeing" of constants, the definition of a NUMBER
	    structure so that a NUMBER * q could be regarded as a
	    pointing to a "freed number" if q->links = 0.

	    The old q->num was changed to a union q->nu which had a pointer
	    to the old q->num if q->links > 0 and to the next freed number
	    if q->links = 0.  The old "num" is #defined to "nu->n_num".

	    The prior method calc has used for handling "constants" amounted
	    to leakage.  After:

		> define f(x) = 27 + x;
		> a = 27;

	    It is of course necessary for the constant 27 to be stored, but
	    if one now redefines f and a by:

		> define f(x) = 45 + x;
		> a = 45;

	    There seems little point in retaining 27 as a constant and
	    therefore using up memory.  If this example seems trivial,
	    replace 27 with a few larger numbers like 2e12345, or better,
	    -2e12345, for which calc needs memory for both 2e12345 and
	    -2e12345!

	    Constants are automatically freed a definition when a
	    function is re- or un-defined.

	    The qalloc(q) and qfree(q) functions have been changed so
	    that that q->links = 0 is permitted and indicates that q
	    has been freed.  If a number has been introduced as a
	    constant, i.e. by a literal numeral as in the above
	    examples, its links becoming zero indicates that it is no
	    longer required and its position in the table of constants
	    becomes available for a later new constant.

	(4) extension of transcendental functions like tan, tanh, etc.
	    to complex arguments

	(5) definition of gd(z) and agd(z), i.e. the gudermannian and
	    inverse gudermannian

	(6) introduction of show options for displaying information about
	    current constants, global variables, static variables, and cached
	    redc moduli.

	    To help you follow what is going on, the following show
	    items have been introduced:

		show constants ==> display the currently stored constants
		show numbers   ==> display the currently stored numbers
		show redcdata  ==> display the currently stored redc moduli
		show statics   ==> display info about static variables
		show real      ==> display only real-valued variables

	    The constants are automatically initialized as constants and
	    should always appear, with links >= 1, in in the list of constants.

	    The show command:

		show globals

	    has been redefined so that it gives information about all
	    current global and still active static variables.

	(7) definition of functions for freeing globals, statics, redc values

	    To free memory used by different kinds of variable, the following
	    builtins have been added:

		freeglobals();		/* free all globals */
		freestatics();		/* free all statics */
		freeredc();		/* free redc moduli */
		free(a, b, ...);	/* free specific variables */

	   NOTE: These functions do not "undefine" the variables, but
	   have the effect of assigning the null value to them, and so
	   frees the memory used for elements of a list, matrix or object.

	   See 10) below for info about "undefine *".

	(8) enhancement of handling of "old value": having it return an
	    lvalue and giving option of disabling updating.

	    Now, by default, "." return an lvalue with the appropriate
	    value instead of copying the old value.

	    So that a string of commands may be given without changing
	    the "oldvalue", the new builtin:

		saveval(0)

	    function simply disables the updating of the "." value.
	    The default updating can be resumed by calling:

		saveval(1)

	    The "." value:

		> 2 + 2
		4
		> .
		4

	    can now be treated as an unnamed variable.  For example:

		> mat x[3,3]={1,2,3,4,5,6,7,8,9}
		> x
		> print .[1,2]
		6

	(9) for a list L defining L[i] to be same as L[[i]]

	(10) extending undefine to permit its application to all user-defined
	     functions by using "undefine *".

	     The command:

		undefine *

	     undefines all current user-defined functions.  After
	     executing all the above freeing functions (and if
	     necessary free(.) to free the current "old value"), the
	     only remaining numbers as displayed by:

		show numbers

	     should be those associated with epsilon(), and if it has been
	     called, qpi().

	(11) storing the most recently calculated value of qpi(epsilon)i and
	     epsilon so that when called again with the same epsilon it
	     is copied rather than recalculateed.

	(12) defining trace() for square matrices

	(13) expression in parentheses may now be followed by a qualifier
	     computible with its type

	     When an expression in parentheses evaluates to an lvalue
	     whose current value is a matrix, list or object, it may
	     now be followed by a qualifier computible with its type.

	     For example:

		> A = list(1,2,4);
		> B = mat[2,2] = {5,6,7,8};
		> define f(x) = (x ? A : B)[[1]];
		> print f(1), f(0)
		2 6

		> obj xy {x,y}
		> C = obj xy = {4,5}
		> p = &C
		> *p.x
		Not indexing matrix or object
		> (*p).x
		4

	(14) swap(a,b) now permits swapping of octets in the same or different
	     blocks.

	     For example:

		> A = blk() = {1,2,3}
		> B = blk() = {4,5,6}
		> swap(A[0], B[2])
		> A
			chunksize = 256, maxsize = 256, datalen = 3
			060203

    A few bug fixes from Ernest Bowen:

	B1: qcmpi(q, n) in qmath.c sometimes gave the wrong result if
		LONG_BITS > BASEB, len = 1 and nf = 0, since it then
		reduces to the value of (nf != q->num.v[1]) in which
		q->num.v[1] is not part of the size-1 array of HALFs for
		q->num.  At present this is used only for changing opcodes
		for ^2 and ^4 from sequences involving OP_POWER to
		sequences using OP_SQUARE, which has no effect on the
		results of calculations.

	B2: in matdet(m) in matfunc.c, a copy of the matrix m was not freed
		when the determinant turned out have zero value.

	B3: in f_search() in func.c, a qlinking of the NUMBER * storing the
		the size of a file was not qfreed.

	B4: in comalloc() in commath.c the initial zero values for real and
		imag parts are qlinked but not qfreed when nonzero values are
		assigned to them.  Rather than changing
		the definition of comalloc(), I have included any relevant
		qfrees with the calls to comalloc() as in
			c = comalloc();
			qfree(c->real);
			c->real = ...

	B5: in calls to matsum(), zeros are qlinked but not qfreed.  Rather
		than changing addnumeric(), I have changed the definition
		of matsum(m) so that it simply adds the components of m,
		which requires only that the relevant additions be defined,
		not that all components of m be numbers.


    Simple arithmetic expressions with literal numbers are evaluated
    during compilation rather than   The val representations of "a" and "b" have
	 been reversed.

	 bit with index n in this array.   This is consistent with the use of
	 bit for a number ch in [0,256), i.e. bit(char(ch), n) = bit(ch, n).
	 For n < 0 or n >= size(A), bit(A,n) returns the null value.

    (25) For assigning values to specified bits in a string, I've defined
	 setbit(A, n) and setbit(A, n, v).  The first assigns the value 1 to
	 bit(A, n), the second assigns test(v) to bit(A, n).

    (26) For consistency with the corresponding number operations, the shift
	 operations A << n and A >> n have been defined to give what look
	 like right- and left-shifts, respectively.  For example, "ab" << 2
	 returns the 16-bit array

		    0010000110010001

	 in which the array for "ab" has been moved 2 bits to the right.

    (27) To achieve much the same as the C strcpy and strncpy functions for
	 null-terminated strings, strcpy(S1, S2) and strncpy(S1, S2, n) have
	 been defined.  Unlike the blkcpy() and copy() functions, the copying
	 for these is only from the beginning of the strings.  Also, unlike C,
	 no memory overflow can occur as the copying ceases when size(S1) is
	 reached.  Note that these overwrite the content of S1 (which affects
	 all strings linked to it) as well as returning S1.  Examples:

	    S = strcpy(6 * "x", "abc")      <=>  S = "abc\0xx"

	    S = strcpy(3 * "x", "abcdef")   <=>  S = "abc"

	    S = strncpy(6 * "x", "abcd", 2) <=>  S = "ab\0xxx"

	    S = strncpy(6 * "x", "ab", 4)   <=>  S = "ab\0\0xx"

	    S = strncpy(6 * "x", "ab", 20)  <=>  S = "ab\0\0\0\0"

	 If a new string S not linked to S1 is to be created, this can be
	 achieved by using str(S1) in place of S1.  For example, the strcpy in

	    A = "xxxxxx"
	    S = strcpy(str("xxxxxx"), "abc")

	 would not change the value of A.

    (28) I've extended the definitions of copy(A, B, ssi, num, dsi) and
	 blkcpy(B, A, num, ssi, dsi) to allow for string-to-string copying
	 and block-to-string copying, but num is now an upper bound for the
	 number of characters to be copied - copying will cease before num
	 characters are copied if the end of the data in the source A or the
	 end of the destination B is reached.  As with other character-changing
	 operations, copying to a string B will not change the locations of
	 B[0], B[1], ... or the size of B.

	 In the case of copying a string to itself, characters are copied in
	 order of increasing index, which is different from block-to-block
	 copying where a memmove is used.  This affects only copy from a
	 string to itself.  For example,

		    A = "abcdefg";
		    copy(A, A, , , 2);

	 will result in A == "abababa".  If the overwriting that occurs here
	 is not wanted, one may use

		    A = "abcdefg";
		    copy(str(A), A, , , 2);

	  which results in A == "ababcde".

    (29) perm(a,b) and comb(a,b) have been extended to accept any real a and
	 any integer b except for perm(a, b) with integer a such that b <= a < 0
	 which gives a "division by zero" error.  For positive b, both functions
	 are polynomials in a of degree b;  for negative b, perm(a,b) is a
	 rational function (1/((a + 1) * (a+2) ...) with abs(b) factors in the
	 denominator), and comb(a,b) = 0.  (An obvious "todo" is to extend this
	 to complex or other types of a.)

    (30) Although it is not illegal, it seems pointless to use a comma operator
	 with a constant or simple variable as in

		    > 2 * 3,14159
			    14159
		    > a = 4; b = 5;
		    > A = (a , b + 2);
		    > A
			    7

	 I have added a few lines to addop.c so that when this occurs a
	 "unused value ignored" message and the relevant line number are
	 displayed.  I have found this useful as I occasionally type ','
	 when I mean '.'.

	 There may be one or two other changes resulting from the way I have
	 rewritten the optimization code in addop.c.  I think there was a bug
	 that assumed that PTR_SIZE would be the same as sizeof(long).  By
	 the way, the new OP_STRING is now of index rather than pointer type.
	 It follows that pointers are now used in opcodes only for global
	 variables.  By introducing a table of addresses of global variables
	 like those used for "constants" and "literal strings", the use of
	 pointers in opcodes could be eliminated.

    (31) When calc has executed a quit (or exit) statement in a function or
	 eval evaluation, it has invoked a call to math_error() which causes
	 a long jump to an initial state without freeing any data on the
	 stack, etc.  Maybe more detail should be added to math_error(), but
	 to achieve the freeing of memory for a quit statement and at the same
	 time give more information about its occurrence I have changed the
	 way opcodes.c handles OP_QUIT.  Now it should free the local variables
	 and whatever is on the stack, and display the name and line-number,
	 for each of the functions currently being evaluated.  The last
	 function listed should be the "top-level" one with name "*".
	 Strings being eval-ed will have name "**".

	 Here is a demo:

	    > global a;
	    >
	    > define f(x) {local i = x^2; a++;
	    >> if (x > 5) quit "Too large!"; return i;}
	    f() defined
	    > define g(x) = f(x) + f(2*x);
	    g() defined
	    > g(2)
		    20
	    > g(3)
	    Too large!
		    "f": line 3
		    "g": line 0
		    "*": line 6
	    > eval("g(3)")
	    Too large!
		    "f": line 3
		    "g": line 0
		    "**": line 1
		    "*": line 7
	    > a
		    6

    (32) I've made several small changes like removing

		    if (vp->v_type == V_NUM) {
			    q = qinv(vp->v_num);
			    if (stack->v_type == V_NUM)
				    qfree(stack->v_num);
			    stack->v_num = q;
			    stack->v_type = V_NUM;
			    return;
		    }

	 from the definition of o_invert.  Presumably these lines were intended
	 to speed up execution for the common case of numerical argument.
	 Comparing the runtimes with and without these lines for inverting
	 thousands of large random numbers in a matrix suggest that execution
	 for real numbers is slightly faster without these lines.

	 Maybe this and other similar treatment of "special cases" should be
	 looked at more closely.

    (33) The new lib script lib/natnumset.cal demonstrates how the new
	 string operators and functions may be used for defining and
	 working with sets of natural numbers not exceeding a
	 user-specified bound.


Following is the change from calc version 2.10.3t5.28 to 2.10.3t5.33:

    Added hnrmod(v, h, n, r) builtin to compute:

	v % (h * 2^n + r), h>0, n>0, r = -1, 0 or 1

    Changed lucas.cal and mersenne.cal to make use of hnrmod().

    A number of changes from Ernest Bowen:

	(1) introduction of unary & and * analogous to those in C;

	    For an lvalue var, &var returns what I call a
	    value-pointer; this is a constant which may be assigned to
	    a variable as in p = &var, and then *p in expressions has
	    the same effect as var.  Here is a simple example of their use:

		> define s(L) {local v=0; while (size(L)) v+= *pop(L);return v;}
		s() defined
		> global a = 1, b = 2;
		> L = list(&a, &b);
		> print s(L)
		3
		> b = 3;
		> print s(L)
		4

	    Octet-pointers, number-pointers, and string-pointers in
	    much the same way, but have not attempted to do much with
	    the latter two.

	    To print a pointer, use the "%p" specifier.

	    Some arithmetic operations has been defined for corresponding
	    C operations.  For example:

		> A = mat[4];
		> p = &A[0];
		> *(p+2) == A[2]
		> ++p
		> *p == A[1]

	    There is at present no protection against "illegal" use of &
	    and *, e.g. if one attempts here to assign a value to *(p+5),
	    or to use p after assigning another value to A.

	    NOTE: Unlike C, in calc &A[0] and A are quite different things.

	    NOTE: If the current value of a variable X is an octet,
	    number or string, *X may be used to to return the value of
	    X; in effect X is an address and *X is the value at X.

	    Added isptr(p) builtin to return 0 is p is not a pointer,
	    >0 if it is a pointer.  The value of isptr(p) comes from the
	    V_XYZ #define (see the top of value.h) of the value to which
	    p points.

	    To allow & to be used as a C-like address operator, use of it
	    has been dropped in calls to user-defined functions.  For the
	    time being I have replaced it by the back-quote `.  For example:

		> global a
		> define f(a,b) = a = b
		> f(&a,5)
		> print a
		0
		> f(`a,5)
		> print a
		5

	   However, one may use & in a similar way as in:

		> define g(a,b) = *a = b
		> g(&a, 7)
		> print a
		7

	   There is no hashvalue for pointers. Thus, like error values,
	   they cannot be used as indices in an association.

	   The -> also works in calc. For example:

		> obj xy {x,y}
		> obj uvw {u, v, w}
		> obj xy A = {1,2}
		> obj uvw B = {3,4,5}
		> p = &A
		> q = &B
		> p->x
			1
		> p->y = 6
		> A
			obj xy {1, 6}
		> q -> u
			3
		> p->y = q
		> A
			obj xy {1, v-ptr: 1400474c0}
		> p->y->u
			3
		> p->y->u = 7
		> B
			obj uvw {7, 4, 5}
		> p -> y = p
		> A
			obj xy {1, v-ptr: 140047490}
		> p -> y -> x
			1
		> p->y->y
			v-ptr: 140047490
		> p->y->y-> x
			1
		> p->y->y->x = 8
		> A
			obj xy {8, v-ptr: 140047490}


	(2) a method of "protecting" variables;

	    For the various kinds of "protection", of an l_value var,
	    bits of var->v_subtype, of which only bits 0 and 1 have been
	    used in the past to indicate literal and allocated strings.
	    This has meant initialization of var->v_subtype when a new var
	    is introduced, and for assignments, etc., examination of the
	    appropriate bits to confirm that the operation is to be permitted.

	    See help/protect for details.

	(3) automatic "freeing" of constants that are no longer required.

	    For the "freeing" of constants, the definition of a NUMBER
	    structure so that a NUMBER * q could be regarded as a
	    pointing to a "freed number" if q->links = 0.

	    The old q->num was changed to a union q->nu which had a pointer
	    to the old q->num if q->links > 0 and to the next freed number
	    if q->links = 0.  The old "num" is #defined to "nu->n_num".

	    The prior method calc has used for handling "constants" amounted
	    to leakage.  After:

		> define f(x) = 27 + x;
		> a = 27;

	    It is of course necessary for the constant 27 to be stored, but
	    if one now redefines f and a by:

		> define f(x) = 45 + x;
		> a = 45;

	    There seems little point in retaining 27 as a constant and
	    therefore using up memory.  If this example seems trivial,
	    replace 27 with a few larger numbers like 2e12345, or better,
	    -2e12345, for which calc needs memory for both 2e12345 and
	    -2e12345!

	    Constants are automatically freed a definition when a
	    function is re- or un-defined.

	    The qalloc(q) and qfree(q) functions have been changed so
	    that that q->links = 0 is permitted and indicates that q
	    has been freed.  If a number has been introduced as a
	    constant, i.e. by a literal numeral as in the above
	    examples, its links becoming zero indicates that it is no
	    longer required and its position in the table of constants
	    becomes available for a later new constant.

	(4) extension of transcendental functions like tan, tanh, etc.
	    to complex arguments

	(5) definition of gd(z) and agd(z), i.e. the gudermannian and
	    inverse gudermannian

	(6) introduction of show options for displaying information about
	    current constants, global variables, static variables, and cached
	    redc moduli.

	    To help you follow what is going on, the following show
	    items have been introduced:

		show constants ==> display the currently stored constants
		show numbers   ==> display the currently stored numbers
		show redcdata  ==> display the currently stored redc moduli
		show statics   ==> display info about static variables
		show real      ==> display only real-valued variables

	    The constants are automatically initialized as constants and
	    should always appear, with links >= 1, in in the list of constants.

	    The show command:

		show globals

	    has been redefined so that it gives information about all
	    current global and still active static variables.

	(7) definition of functions for freeing globals, statics, redc values

	    To free memory used by different kinds of variable, the following
	    builtins have been added:

		freeglobals();		/* free all globals */
		freestatics();		/* free all statics */
		freeredc();		/* free redc moduli */
		free(a, b, ...);	/* free specific variables */

	   NOTE: These functions do not "undefine" the variables, but
	   have the effect of assigning the null value to them, and so
	   frees the memory used for elements of a list, matrix or object.

	   See 10) below for info about "undefine *".

	(8) enhancement of handling of "old value": having it return an
	    lvalue and giving option of disabling updating.

	    Now, by default, "." return an lvalue with the appropriate
	    value instead of copying the old value.

	    So that a string of commands may be given without changing
	    the "oldvalue", the new builtin:

		saveval(0)

	    function simply disables the updating of the "." value.
	    The default updating can be resumed by calling:

		saveval(1)

	    The "." value:

		> 2 + 2
		4
		> .
		4

	    can now be treated as an unnamed variable.  For example:

		> mat x[3,3]={1,2,3,4,5,6,7,8,9}
		> x
		> print .[1,2]
		6

	(9) for a list L defining L[i] to be same as L[[i]]

	(10) extending undefine to permit its application to all user-defined
	     functions by using "undefine *".

	     The command:

		undefine *

	     undefines all current user-defined functions.  After
	     executing all the above freeing functions (and if
	     necessary free(.) to free the current "old value"), the
	     only remaining numbers as displayed by:

		show numbers

	     should be those associated with epsilon(), and if it has been
	     called, qpi().

	(11) storing the most recently calculated value of qpi(epsilon)i and
	     epsilon so that when called again with the same epsilon it
	     is copied rather than recalculateed.

	(12) defining trace() for square matrices

	(13) expression in parentheses may now be followed by a qualifier
	     computible with its type

	     When an expression in parentheses evaluates to an lvalue
	     whose current value is a matrix, list or object, it may
	     now be followed by a qualifier computible with its type.

	     For example:

		> A = list(1,2,4);
		> B = mat[2,2] = {5,6,7,8};
		> define f(x) = (x ? A : B)[[1]];
		> print f(1), f(0)
		2 6

		> obj xy {x,y}
		> C = obj xy = {4,5}
		> p = &C
		> *p.x
		Not indexing matrix or object
		> (*p).x
		4

	(14) swap(a,b) now permits swapping of octets in the same or different
	     blocks.

	     For example:

		> A = blk() = {1,2,3}
		> B = blk() = {4,5,6}
		> swap(A[0], B[2])
		> A
			chunksize = 256, maxsize = 256, datalen = 3
			060203

    A few bug fixes from Ernest Bowen:

	B1: qcmpi(q, n) in qmath.c sometimes gave the wrong result if
		LONG_BITS > BASEB, len = 1 and nf = 0, since it then
		reduces to the value of (nf != q->num.v[1]) in which
		q->num.v[1] is not part of the size-1 array of HALFs for
		q->num.  At present this is used only for changing opcodes
		for ^2 and ^4 from sequences involving OP_POWER to
		sequences using OP_SQUARE, which has no effect on the
		results of calculations.

	B2: in matdet(m) in matfunc.c, a copy of the matrix m was not freed
		when the determinant turned out have zero value.

	B3: in f_search() in func.c, a qlinking of the NUMBER * storing the
		the size of a file was not qfreed.

	B4: in comalloc() in commath.c the initial zero values for real and
		imag parts are qlinked but not qfreed when nonzero values are
		assigned to them.  Rather than changing
		the definition of comalloc(), I have included any relevant
		qfrees with the calls to comalloc() as in
			c = comalloc();
			qfree(c->real);
			c->real = ...

	B5: in calls to matsum(), zeros are qlinked but not qfreed.  Rather
		than changing addnumeric(), I have changed the definition
		of matsum(m) so that it simply adds the components of m,
		which requires only that the relevant additions be defined,
		not that all components of m be numbers.


    Simple arithmetic expressions with literal numbers are evaluated
    during compilation rather than   The val representations of "a" and "b" have
	 been reversed.

	 bit with index n in this array.   This is consistent with the use of
	 bit for a number ch in [0,256), i.e. bit(char(ch), n) = bit(ch, n).
	 For n < 0 or n >= size(A), bit(A,n) returns the null value.

    (25) For assigning values to specified bits in a string, I've defined
	 setbit(A, n) and setbit(A, n, v).  The first assigns the value 1 to
	 bit(A, n), the second assigns test(v) to bit(A, n).

    (26) For consistency with the corresponding number operations, the shift
	 operations A << n and A >> n have been defined to give what look
	 like right- and left-shifts, respectively.  For example, "ab" << 2
	 returns the 16-bit array

		    0010000110010001

	 in which the array for "ab" has been moved 2 bits to the right.

    (27) To achieve much the same as the C strcpy and strncpy functions for
	 null-terminated strings, strcpy(S1, S2) and strncpy(S1, S2, n) have
	 been defined.  Unlike the blkcpy() and copy() functions, the copying
	 for these is only from the beginning of the strings.  Also, unlike C,
	 no memory overflow can occur as the copying ceases when size(S1) is
	 reached.  Note that these overwrite the content of S1 (which affects
	 all strings linked to it) as well as returning S1.  Examples:

	    S = strcpy(6 * "x", "abc")      <=>  S = "abc\0xx"

	    S = strcpy(3 * "x", "abcdef")   <=>  S = "abc"

	    S = strncpy(6 * "x", "abcd", 2) <=>  S = "ab\0xxx"

	    S = strncpy(6 * "x", "ab", 4)   <=>  S = "ab\0\0xx"

	    S = strncpy(6 * "x", "ab", 20)  <=>  S = "ab\0\0\0\0"

	 If a new string S not linked to S1 is to be created, this can be
	 achieved by using str(S1) in place of S1.  For example, the strcpy in

	    A = "xxxxxx"
	    S = strcpy(str("xxxxxx"), "abc")

	 would not change the value of A.

    (28) I've extended the definitions of copy(A, B, ssi, num, dsi) and
	 blkcpy(B, A, num, ssi, dsi) to allow for string-to-string copying
	 and block-to-string copying, but num is now an upper bound for the
	 number of characters to be copied - copying will cease before num
	 characters are copied if the end of the data in the source A or the
	 end of the destination B is reached.  As with other character-changing
	 operations, copying to a string B will not change the locations of
	 B[0], B[1], ... or the size of B.

	 In the case of copying a string to itself, characters are copied in
	 order of increasing index, which is different from block-to-block
	 copying where a memmove is used.  This affects only copy from a
	 string to itself.  For example,

		    A = "abcdefg";
		    copy(A, A, , , 2);

	 will result in A == "abababa".  If the overwriting that occurs here
	 is not wanted, one may use

		    A = "abcdefg";
		    copy(str(A), A, , , 2);

	  which results in A == "ababcde".

    (29) perm(a,b) and comb(a,b) have been extended to accept any real a and
	 any integer b except for perm(a, b) with integer a such that b <= a < 0
	 which gives a "division by zero" error.  For positive b, both functions
	 are polynomials in a of degree b;  for negative b, perm(a,b) is a
	 rational function (1/((a + 1) * (a+2) ...) with abs(b) factors in the
	 denominator), and comb(a,b) = 0.  (An obvious "todo" is to extend this
	 to complex or other types of a.)

    (30) Although it is not illegal, it seems pointless to use a comma operator
	 with a constant or simple variable as in

		    > 2 * 3,14159
			    14159
		    > a = 4; b = 5;
		    > A = (a , b + 2);
		    > A
			    7

	 I have added a few lines to addop.c so that when this occurs a
	 "unused value ignored" message and the relevant line number are
	 displayed.  I have found this useful as I occasionally type ','
	 when I mean '.'.

	 There may be one or two other changes resulting from the way I have
	 rewritten the optimization code in addop.c.  I think there was a bug
	 that assumed that PTR_SIZE would be the same as sizeof(long).  By
	 the way, the new OP_STRING is now of index rather than pointer type.
	 It follows that pointers are now used in opcodes only for global
	 variables.  By introducing a table of addresses of global variables
	 like those used for "constants" and "literal strings", the use of
	 pointers in opcodes could be eliminated.

    (31) When calc has executed a quit (or exit) statement in a function or
	 eval evaluation, it has invoked a call to math_error() which causes
	 a long jump to an initial state without freeing any data on the
	 stack, etc.  Maybe more detail should be added to math_error(), but
	 to achieve the freeing of memory for a quit statement and at the same
	 time give more information about its occurrence I have changed the
	 way opcodes.c handles OP_QUIT.  Now it should free the local variables
	 and whatever is on the stack, and display the name and line-number,
	 for each of the functions currently being evaluated.  The last
	 function listed should be the "top-level" one with name "*".
	 Strings being eval-ed will have name "**".

	 Here is a demo:

	    > global a;
	    >
	    > define f(x) {local i = x^2; a++;
	    >> if (x > 5) quit "Too large!"; return i;}
	    f() defined
	    > define g(x) = f(x) + f(2*x);
	    g() defined
	    > g(2)
		    20
	    > g(3)
	    Too large!
		    "f": line 3
		    "g": line 0
		    "*": line 6
	    > eval("g(3)")
	    Too large!
		    "f": line 3
		    "g": line 0
		    "**": line 1
		    "*": line 7
	    > a
		    6

    (32) I've made several small changes like removing

		    if (vp->v_type == V_NUM) {
			    q = qinv(vp->v_num);
			    if (stack->v_type == V_NUM)
				    qfree(stack->v_num);
			    stack->v_num = q;
			    stack->v_type = V_NUM;
			    return;
		    }

	 from the definition of o_invert.  Presumably these lines were intended
	 to speed up execution for the common case of numerical argument.
	 Comparing the runtimes with and without these lines for inverting
	 thousands of large random numbers in a matrix suggest that execution
	 for real numbers is slightly faster without these lines.

	 Maybe this and other similar treatment of "special cases" should be
	 looked at more closely.

    (33) The new lib script lib/natnumset.cal demonstrates how the new
	 string operators and functions may be used for defining and
	 working with sets of natural numbers not exceeding a
	 user-specified bound.


Following is the change from calc version 2.10.3t5.28 to 2.10.3t5.33:

    Added hnrmod(v, h, n, r) builtin to compute:

	v % (h * 2^n + r), h>0, n>0, r = -1, 0 or 1

    Changed lucas.cal and mersenne.cal to make use of hnrmod().

    A number of changes from Ernest Bowen:

	(1) introduction of unary & and * analogous to those in C;

	    For an lvalue var, &var returns what I call a
	    value-pointer; this is a constant which may be assigned to
	    a variable as in p = &var, and then *p in expressions has
	    the same effect as var.  Here is a simple example of their use:

		> define s(L) {local v=0; while (size(L)) v+= *pop(L);return v;}
		s() defined
		> global a = 1, b = 2;
		> L = list(&a, &b);
		> print s(L)
		3
		> b = 3;
		> print s(L)
		4

	    Octet-pointers, number-pointers, and string-pointers in
	    much the same way, but have not attempted to do much with
	    the latter two.

	    To print a pointer, use the "%p" specifier.

	    Some arithmetic operations has been defined for corresponding
	    C operations.  For example:

		> A = mat[4];
		> p = &A[0];
		> *(p+2) == A[2]
		> ++p
		> *p == A[1]

	    There is at present no protection against "illegal" use of &
	    and *, e.g. if one attempts here to assign a value to *(p+5),
	    or to use p after assigning another value to A.

	    NOTE: Unlike C, in calc &A[0] and A are quite different things.

	    NOTE: If the current value of a variable X is an octet,
	    number or string, *X may be used to to return the value of
	    X; in effect X is an address and *X is the value at X.

	    Added isptr(p) builtin to return 0 is p is not a pointer,
	    >0 if it is a pointer.  The value of isptr(p) comes from the
	    V_XYZ #define (see the top of value.h) of the value to which
	    p points.

	    To allow & to be used as a C-like address operator, use of it
	    has been dropped in calls to user-defined functions.  For the
	    time being I have replaced it by the back-quote `.  For example:

		> global a
		> define f(a,b) = a = b
		> f(&a,5)
		> print a
		0
		> f(`a,5)
		> print a
		5

	   However, one may use & in a similar way as in:

		> define g(a,b) = *a = b
		> g(&a, 7)
		> print a
		7

	   There is no hashvalue for pointers. Thus, like error values,
	   they cannot be used as indices in an association.

	   The -> also works in calc. For example:

		> obj xy {x,y}
		> obj uvw {u, v, w}
		> obj xy A = {1,2}
		> obj uvw B = {3,4,5}
		> p = &A
		> q = &B
		> p->x
			1
		> p->y = 6
		> A
			obj xy {1, 6}
		> q -> u
			3
		> p->y = q
		> A
			obj xy {1, v-ptr: 1400474c0}
		> p->y->u
			3
		> p->y->u = 7
		> B
			obj uvw {7, 4, 5}
		> p -> y = p
		> A
			obj xy {1, v-ptr: 140047490}
		> p -> y -> x
			1
		> p->y->y
			v-ptr: 140047490
		> p->y->y-> x
			1
		> p->y->y->x = 8
		> A
			obj xy {8, v-ptr: 140047490}


	(2) a method of "protecting" variables;

	    For the various kinds of "protection", of an l_value var,
	    bits of var->v_subtype, of which only bits 0 and 1 have been
	    used in the past to indicate literal and allocated strings.
	    This has meant initialization of var->v_subtype when a new var
	    is introduced, and for assignments, etc., examination of the
	    appropriate bits to confirm that the operation is to be permitted.

	    See help/protect for details.

	(3) automatic "freeing" of constants that are no longer required.

	    For the "freeing" of constants, the definition of a NUMBER
	    structure so that a NUMBER * q could be regarded as a
	    pointing to a "freed number" if q->links = 0.

	    The old q->num was changed to a union q->nu which had a pointer
	    to the old q->num if q->links > 0 and to the next freed number
	    if q->links = 0.  The old "num" is #defined to "nu->n_num".

	    The prior method calc has used for handling "constants" amounted
	    to leakage.  After:

		> define f(x) = 27 + x;
		> a = 27;

	    It is of course necessary for the constant 27 to be stored, but
	    if one now redefines f and a by:

		> define f(x) = 45 + x;
		> a = 45;

	    There seems little point in retaining 27 as a constant and
	    therefore using up memory.  If this example seems trivial,
	    replace 27 with a few larger numbers like 2e12345, or better,
	    -2e12345, for which calc needs memory for both 2e12345 and
	    -2e12345!

	    Constants are automatically freed a definition when a
	    function is re- or un-defined.

	    The qalloc(q) and qfree(q) functions have been changed so
	    that that q->links = 0 is permitted and indicates that q
	    has been freed.  If a number has been introduced as a
	    constant, i.e. by a literal numeral as in the above
	    examples, its links becoming zero indicates that it is no
	    longer required and its position in the table of constants
	    becomes available for a later new constant.

	(4) extension of transcendental functions like tan, tanh, etc.
	    to complex arguments

	(5) definition of gd(z) and agd(z), i.e. the gudermannian and
	    inverse gudermannian

	(6) introduction of show options for displaying information about
	    current constants, global variables, static variables, and cached
	    redc moduli.

	    To help you follow what is going on, the following show
	    items have been introduced:

		show constants ==> display the currently stored constants
		show numbers   ==> display the currently stored numbers
		show redcdata  ==> display the currently stored redc moduli
		show statics   ==> display info about static variables
		show real      ==> display only real-valued variables

	    The constants are automatically initialized as constants and
	    should always appear, with links >= 1, in in the list of constants.

	    The show command:

		show globals

	    has been redefined so that it gives information about all
	    current global and still active static variables.

	(7) definition of functions for freeing globals, statics, redc values

	    To free memory used by different kinds of variable, the following
	    builtins have been added:

		freeglobals();		/* free all globals */
		freestatics();		/* free all statics */
		freeredc();		/* free redc moduli */
		free(a, b, ...);	/* free specific variables */

	   NOTE: These functions do not "undefine" the variables, but
	   have the effect of assigning the null value to them, and so
	   frees the memory used for elements of a list, matrix or object.

	   See 10) below for info about "undefine *".

	(8) enhancement of handling of "old value": having it return an
	    lvalue and giving option of disabling updating.

	    Now, by default, "." return an lvalue with the appropriate
	    value instead of copying the old value.

	    So that a string of commands may be given without changing
	    the "oldvalue", the new builtin:

		saveval(0)

	    function simply disables the updating of the "." value.
	    The default updating can be resumed by calling:

		saveval(1)

	    The "." value:

		> 2 + 2
		4
		> .
		4

	    can now be treated as an unnamed variable.  For example:

		> mat x[3,3]={1,2,3,4,5,6,7,8,9}
		> x
		> print .[1,2]
		6

	(9) for a list L defining L[i] to be same as L[[i]]

	(10) extending undefine to permit its application to all user-defined
	     functions by using "undefine *".

	     The command:

		undefine *

	     undefines all current user-defined functions.  After
	     executing all the above freeing functions (and if
	     necessary free(.) to free the current "old value"), the
	     only remaining numbers as displayed by:

		show numbers

	     should be those associated with epsilon(), and if it has been
	     called, qpi().

	(11) storing the most recently calculated value of qpi(epsilon)i and
	     epsilon so that when called again with the same epsilon it
	     is copied rather than recalculateed.

	(12) defining trace() for square matrices

	(13) expression in parentheses may now be followed by a qualifier
	     computible with its type

	     When an expression in parentheses evaluates to an lvalue
	     whose current value is a matrix, list or object, it may
	     now be followed by a qualifier computible with its type.

	     For example:

		> A = list(1,2,4);
		> B = mat[2,2] = {5,6,7,8};
		> define f(x) = (x ? A : B)[[1]];
		> print f(1), f(0)
		2 6

		> obj xy {x,y}
		> C = obj xy = {4,5}
		> p = &C
		> *p.x
		Not indexing matrix or object
		> (*p).x
		4

	(14) swap(a,b) now permits swapping of octets in the same or different
	     blocks.

	     For example:

		> A = blk() = {1,2,3}
		> B = blk() = {4,5,6}
		> swap(A[0], B[2])
		> A
			chunksize = 256, maxsize = 256, datalen = 3
			060203

    A few bug fixes from Ernest Bowen:

	B1: qcmpi(q, n) in qmath.c sometimes gave the wrong result if
		LONG_BITS > BASEB, len = 1 and nf = 0, since it then
		reduces to the value of (nf != q->num.v[1]) in which
		q->num.v[1] is not part of the size-1 array of HALFs for
		q->num.  At present this is used only for changing opcodes
		for ^2 and ^4 from sequences involving OP_POWER to
		sequences using OP_SQUARE, which has no effect on the
		results of calculations.

	B2: in matdet(m) in matfunc.c, a copy of the matrix m was not freed
		when the determinant turned out have zero value.

	B3: in f_search() in func.c, a qlinking of the NUMBER * storing the
		the size of a file was not qfreed.

	B4: in comalloc() in commath.c the initial zero values for real and
		imag parts are qlinked but not qfreed when nonzero values are
		assigned to them.  Rather than changing
		the definition of comalloc(), I have included any relevant
		qfrees with the calls to comalloc() as in
			c = comalloc();
			qfree(c->real);
			c->real = ...

	B5: in calls to matsum(), zeros are qlinked but not qfreed.  Rather
		than changing addnumeric(), I have changed the definition
		of matsum(m) so that it simply adds the components of m,
		which requires only that the relevant additions be defined,
		not that all components of m be numbers.


    Simple arithmetic expressions with literal numbers are evaluated
    during compilation rather than   The val representations of "a" and "b" have
	 been reversed.

	 bit with index n in this array.   This is consistent with the use of
	 bit for a number ch in [0,256), i.e. bit(char(ch), n) = bit(ch, n).
	 For n < 0 or n >= size(A), bit(A,n) returns the null value.

    (25) For assigning values to specified bits in a string, I've defined
	 setbit(A, n) and setbit(A, n, v).  The first assigns the value 1 to
	 bit(A, n), the second assigns test(v) to bit(A, n).

    (26) For consistency with the corresponding number operations, the shift
	 operations A << n and A >> n have been defined to give what look
	 like right- and left-shifts, respectively.  For example, "ab" << 2
	 returns the 16-bit array

		    0010000110010001

	 in which the array for "ab" has been moved 2 bits to the right.

    (27) To achieve much the same as the C strcpy and strncpy functions for
	 null-terminated strings, strcpy(S1, S2) and strncpy(S1, S2, n) have
	 been defined.  Unlike the blkcpy() and copy() functions, the copying
	 for these is only from the beginning of the strings.  Also, unlike C,
	 no memory overflow can occur as the copying ceases when size(S1) is
	 reached.  Note that these overwrite the content of S1 (which affects
	 all strings linked to it) as well as returning S1.  Examples:

	    S = strcpy(6 * "x", "abc")      <=>  S = "abc\0xx"

	    S = strcpy(3 * "x", "abcdef")   <=>  S = "abc"

	    S = strncpy(6 * "x", "abcd", 2) <=>  S = "ab\0xxx"

	    S = strncpy(6 * "x", "ab", 4)   <=>  S = "ab\0\0xx"

	    S = strncpy(6 * "x", "ab", 20)  <=>  S = "ab\0\0\0\0"

	 If a new string S not linked to S1 is to be created, this can be
	 achieved by using str(S1) in place of S1.  For example, the strcpy in

	    A = "xxxxxx"
	    S = strcpy(str("xxxxxx"), "abc")

	 would not change the value of A.

    (28) I've extended the definitions of copy(A, B, ssi, num, dsi) and
	 blkcpy(B, A, num, ssi, dsi) to allow for string-to-string copying
	 and block-to-string copying, but num is now an upper bound for the
	 number of characters to be copied - copying will cease before num
	 characters are copied if the end of the data in the source A or the
	 end of the destination B is reached.  As with other character-changing
	 operations, copying to a string B will not change the locations of
	 B[0], B[1], ... or the size of B.

	 In the case of copying a string to itself, characters are copied in
	 order of increasing index, which is different from block-to-block
	 copying where a memmove is used.  This affects only copy from a
	 string to itself.  For example,

		    A = "abcdefg";
		    copy(A, A, , , 2);

	 will result in A == "abababa".  If the overwriting that occurs here
	 is not wanted, one may use

		    A = "abcdefg";
		    copy(str(A), A, , , 2);

	  which results in A == "ababcde".

    (29) perm(a,b) and comb(a,b) have been extended to accept any real a and
	 any integer b except for perm(a, b) with integer a such that b <= a < 0
	 which gives a "division by zero" error.  For positive b, both functions
	 are polynomials in a of degree b;  for negative b, perm(a,b) is a
	 rational function (1/((a + 1) * (a+2) ...) with abs(b) factors in the
	 denominator), and comb(a,b) = 0.  (An obvious "todo" is to extend this
	 to complex or other types of a.)

    (30) Although it is not illegal, it seems pointless to use a comma operator
	 with a constant or simple variable as in

		    > 2 * 3,14159
			    14159
		    > a = 4; b = 5;
		    > A = (a , b + 2);
		    > A
			    7

	 I have added a few lines to addop.c so that when this occurs a
	 "unused value ignored" message and the relevant line number are
	 displayed.  I have found this useful as I occasionally type ','
	 when I mean '.'.

	 There may be one or two other changes resulting from the way I have
	 rewritten the optimization code in addop.c.  I think there was a bug
	 that assumed that PTR_SIZE would be the same as sizeof(long).  By
	 the way, the new OP_STRING is now of index rather than pointer type.
	 It follows that pointers are now used in opcodes only for global
	 variables.  By introducing a table of addresses of global variables
	 like those used for "constants" and "literal strings", the use of
	 pointers in opcodes could be eliminated.

    (31) When calc has executed a quit (or exit) statement in a function or
	 eval evaluation, it has invoked a call to math_error() which causes
	 a long jump to an initial state without freeing any data on the
	 stack, etc.  Maybe more detail should be added to math_error(), but
	 to achieve the freeing of memory for a quit statement and at the same
	 time give more information about its occurrence I have changed the
	 way opcodes.c handles OP_QUIT.  Now it should free the local variables
	 and whatever is on the stack, and display the name and line-number,
	 for each of the functions currently being evaluated.  The last
	 function listed should be the "top-level" one with name "*".
	 Strings being eval-ed will have name "**".

	 Here is a demo:

	    > global a;
	    >
	    > define f(x) {local i = x^2; a++;
	    >> if (x > 5) quit "Too large!"; return i;}
	    f() defined
	    > define g(x) = f(x) + f(2*x);
	    g() defined
	    > g(2)
		    20
	    > g(3)
	    Too large!
		    "f": line 3
		    "g": line 0
		    "*": line 6
	    > eval("g(3)")
	    Too large!
		    "f": line 3
		    "g": line 0
		    "**": line 1
		    "*": line 7
	    > a
		    6

    (32) I've made several small changes like removing

		    if (vp->v_type == V_NUM) {
			    q = qinv(vp->v_num);
			    if (stack->v_type == V_NUM)
				    qfree(stack->v_num);
			    stack->v_num = q;
			    stack->v_type = V_NUM;
			    return;
		    }

	 from the definition of o_invert.  Presumably these lines were intended
	 to speed up execution for the common case of numerical argument.
	 Comparing the runtimes with and without these lines for inverting
	 thousands of large random numbers in a matrix suggest that execution
	 for real numbers is slightly faster without these lines.

	 Maybe this and other similar treatment of "special cases" should be
	 looked at more closely.

    (33) The new lib script lib/natnumset.cal demonstrates how the new
	 string operators and functions may be used for defining and
	 working with sets of natural numbers not exceeding a
	 user-specified bound.


Following is the change from calc version 2.10.3t5.28 to 2.10.3t5.33:

    Added hnrmod(v, h, n, r) builtin to compute:

	v % (h * 2^n + r), h>0, n>0, r = -1, 0 or 1

    Changed lucas.cal and mersenne.cal to make use of hnrmod().

    A number of changes from Ernest Bowen:

	(1) introduction of unary & and * analogous to those in C;

	    For an lvalue var, &var returns what I call a
	    value-pointer; this is a constant which may be assigned to
	    a variable as in p = &var, and then *p in expressions has
	    the same effect as var.  Here is a simple example of their use:

		> define s(L) {local v=0; while (size(L)) v+= *pop(L);return v;}
		s() defined
		> global a = 1, b = 2;
		> L = list(&a, &b);
		> print s(L)
		3
		> b = 3;
		> print s(L)
		4

	    Octet-pointers, number-pointers, and string-pointers in
	    much the same way, but have not attempted to do much with
	    the latter two.

	    To print a pointer, use the "%p" specifier.

	    Some arithmetic operations has been defined for corresponding
	    C operations.  For example:

		> A = mat[4];
		> p = &A[0];
		> *(p+2) == A[2]
		> ++p
		> *p == A[1]

	    There is at present no protection against "illegal" use of &
	    and *, e.g. if one attempts here to assign a value to *(p+5),
	    or to use p after assigning another value to A.

	    NOTE: Unlike C, in calc &A[0] and A are quite different things.

	    NOTE: If the current value of a variable X is an octet,
	    number or string, *X may be used to to return the value of
	    X; in effect X is an address and *X is the value at X.

	    Added isptr(p) builtin to return 0 is p is not a pointer,
	    >0 if it is a pointer.  The value of isptr(p) comes from the
	    V_XYZ #define (see the top of value.h) of the value to which
	    p points.

	    To allow & to be used as a C-like address operator, use of it
	    has been dropped in calls to user-defined functions.  For the
	    time being I have replaced it by the back-quote `.  For example:

		> global a
		> define f(a,b) = a = b
		> f(&a,5)
		> print a
		0
		> f(`a,5)
		> print a
		5

	   However, one may use & in a similar way as in:

		> define g(a,b) = *a = b
		> g(&a, 7)
		> print a
		7

	   There is no hashvalue for pointers. Thus, like error values,
	   they cannot be used as indices in an association.

	   The -> also works in calc. For example:

		> obj xy {x,y}
		> obj uvw {u, v, w}
		> obj xy A = {1,2}
		> obj uvw B = {3,4,5}
		> p = &A
		> q = &B
		> p->x
			1
		> p->y = 6
		> A
			obj xy {1, 6}
		> q -> u
			3
		> p->y = q
		> A
			obj xy {1, v-ptr: 1400474c0}
		> p->y->u
			3
		> p->y->u = 7
		> B
			obj uvw {7, 4, 5}
		> p -> y = p
		> A
			obj xy {1, v-ptr: 140047490}
		> p -> y -> x
			1
		> p->y->y
			v-ptr: 140047490
		> p->y->y-> x
			1
		> p->y->y->x = 8
		> A
			obj xy {8, v-ptr: 140047490}


	(2) a method of "protecting" variables;

	    For the various kinds of "protection", of an l_value var,
	    bits of var->v_subtype, of which only bits 0 and 1 have been
	    used in the past to indicate literal and allocated strings.
	    This has meant initialization of var->v_subtype when a new var
	    is introduced, and for assignments, etc., examination of the
	    appropriate bits to confirm that the operation is to be permitted.

	    See help/protect for details.

	(3) automatic "freeing" of constants that are no longer required.

	    For the "freeing" of constants, the definition of a NUMBER
	    structure so that a NUMBER * q could be regarded as a
	    pointing to a "freed number" if q->links = 0.

	    The old q->num was changed to a union q->nu which had a pointer
	    to the old q->num if q->links > 0 and to the next freed number
	    if q->links = 0.  The old "num" is #defined to "nu->n_num".

	    The prior method calc has used for handling "constants" amounted
	    to leakage.  After:

		> define f(x) = 27 + x;
		> a = 27;

	    It is of course necessary for the constant 27 to be stored, but
	    if one now redefines f and a by:

		> define f(x) = 45 + x;
		> a = 45;

	    There seems little point in retaining 27 as a constant and
	    therefore using up memory.  If this example seems trivial,
	    replace 27 with a few larger numbers like 2e12345, or better,
	    -2e12345, for which calc needs memory for both 2e12345 and
	    -2e12345!

	    Constants are automatically freed a definition when a
	    function is re- or un-defined.

	    The qalloc(q) and qfree(q) functions have been changed so
	    that that q->links = 0 is permitted and indicates that q
	    has been freed.  If a number has been introduced as a
	    constant, i.e. by a literal numeral as in the above
	    examples, its links becoming zero indicates that it is no
	    longer required and its position in the table of constants
	    becomes available for a later new constant.

	(4) extension of transcendental functions like tan, tanh, etc.
	    to complex arguments

	(5) definition of gd(z) and agd(z), i.e. the gudermannian and
	    inverse gudermannian

	(6) introduction of show options for displaying information about
	    current constants, global variables, static variables, and cached
	    redc moduli.

	    To help you follow what is going on, the following show
	    items have been introduced:

		show constants ==> display the currently stored constants
		show numbers   ==> display the currently stored numbers
		show redcdata  ==> display the currently stored redc moduli
		show statics   ==> display info about static variables
		show real      ==> display only real-valued variables

	    The constants are automatically initialized as constants and
	    should always appear, with links >= 1, in in the list of constants.

	    The show command:

		show globals

	    has been redefined so that it gives information about all
	    current global and still active static variables.

	(7) definition of functions for freeing globals, statics, redc values

	    To free memory used by different kinds of variable, the following
	    builtins have been added:

		freeglobals();		/* free all globals */
		freestatics();		/* free all statics */
		freeredc();		/* free redc moduli */
		free(a, b, ...);	/* free specific variables */

	   NOTE: These functions do not "undefine" the variables, but
	   have the effect of assigning the null value to them, and so
	   frees the memory used for elements of a list, matrix or object.

	   See 10) below for info about "undefine *".

	(8) enhancement of handling of "old value": having it return an
	    lvalue and giving option of disabling updating.

	    Now, by default, "." return an lvalue with the appropriate
	    value instead of copying the old value.

	    So that a string of commands may be given without changing
	    the "oldvalue", the new builtin:

		saveval(0)

	    function simply disables the updating of the "." value.
	    The default updating can be resumed by calling:

		saveval(1)

	    The "." value:

		> 2 + 2
		4
		> .
		4

	    can now be treated as an unnamed variable.  For example:

		> mat x[3,3]={1,2,3,4,5,6,7,8,9}
		> x
		> print .[1,2]
		6

	(9) for a list L defining L[i] to be same as L[[i]]

	(10) extending undefine to permit its application to all user-defined
	     functions by using "undefine *".

	     The command:

		undefine *

	     undefines all current user-defined functions.  After
	     executing all the above freeing functions (and if
	     necessary free(.) to free the current "old value"), the
	     only remaining numbers as displayed by:

		show numbers

	     should be those associated with epsilon(), and if it has been
	     called, qpi().

	(11) storing the most recently calculated value of qpi(epsilon)i and
	     epsilon so that when called again with the same epsilon it
	     is copied rather than recalculateed.

	(12) defining trace() for square matrices

	(13) expression in parentheses may now be followed by a qualifier
	     computible with its type

	     When an expression in parentheses evaluates to an lvalue
	     whose current value is a matrix, list or object, it may
	     now be followed by a qualifier computible with its type.

	     For example:

		> A = list(1,2,4);
		> B = mat[2,2] = {5,6,7,8};
		> define f(x) = (x ? A : B)[[1]];
		> print f(1), f(0)
		2 6

		> obj xy {x,y}
		> C = obj xy = {4,5}
		> p = &C
		> *p.x
		Not indexing matrix or object
		> (*p).x
		4

	(14) swap(a,b) now permits swapping of octets in the same or different
	     blocks.

	     For example:

		> A = blk() = {1,2,3}
		> B = blk() = {4,5,6}
		> swap(A[0], B[2])
		> A
			chunksize = 256, maxsize = 256, datalen = 3
			060203

    A few bug fixes from Ernest Bowen:

	B1: qcmpi(q, n) in qmath.c sometimes gave the wrong result if
		LONG_BITS > BASEB, len = 1 and nf = 0, since it then
		reduces to the value of (nf != q->num.v[1]) in which
		q->num.v[1] is not part of the size-1 array of HALFs for
		q->num.  At present this is used only for changing opcodes
		for ^2 and ^4 from sequences involving OP_POWER to
		sequences using OP_SQUARE, which has no effect on the
		results of calculations.

	B2: in matdet(m) in matfunc.c, a copy of the matrix m was not freed
		when the determinant turned out have zero value.

	B3: in f_search() in func.c, a qlinking of the NUMBER * storing the
		the size of a file was not qfreed.

	B4: in comalloc() in commath.c the initial zero values for real and
		imag parts are qlinked but not qfreed when nonzero values are
		assigned to them.  Rather than changing
		the definition of comalloc(), I have included any relevant
		qfrees with the calls to comalloc() as in
			c = comalloc();
			qfree(c->real);
			c->real = ...

	B5: in calls to matsum(), zeros are qlinked but not qfreed.  Rather
		than changing addnumeric(), I have changed the definition
		of matsum(m) so that it simply adds the components of m,
		which requires only that the relevant additions be defined,
		not that all components of m be numbers.


    Simple arithmetic expressions with literal numbers are evaluated
    during compilation rather than   The val representations of "a" and "b" have
	 been reversed.

	 bit with index n in this array.   This is consistent with the use of
	 bit for a number ch in [0,256), i.e. bit(char(ch), n) = bit(ch, n).
	 For n < 0 or n >= size(A), bit(A,n) returns the null value.

    (25) For assigning values to specified bits in a string, I've defined
	 setbit(A, n) and setbit(A, n, v).  The first assigns the value 1 to
	 bit(A, n), the second assigns test(v) to bit(A, n).

    (26) For consistency with the corresponding number operations, the shift
	 operations A << n and A >> n have been defined to give what look
	 like right- and left-shifts, respectively.  For example, "ab" << 2
	 returns the 16-bit array

		    0010000110010001

	 in which the array for "ab" has been moved 2 bits to the right.

    (27) To achieve much the same as the C strcpy and strncpy functions for
	 null-terminated strings, strcpy(S1, S2) and strncpy(S1, S2, n) have
	 been defined.  Unlike the blkcpy() and copy() functions, the copying
	 for these is only from the beginning of the strings.  Also, unlike C,
	 no memory overflow can occur as the copying ceases when size(S1) is
	 reached.  Note that these overwrite the content of S1 (which affects
	 all strings linked to it) as well as returning S1.  Examples:

	    S = strcpy(6 * "x", "abc")      <=>  S = "abc\0xx"

	    S = strcpy(3 * "x", "abcdef")   <=>  S = "abc"

	    S = strncpy(6 * "x", "abcd", 2) <=>  S = "ab\0xxx"

	    S = strncpy(6 * "x", "ab", 4)   <=>  S = "ab\0\0xx"

	    S = strncpy(6 * "x", "ab", 20)  <=>  S = "ab\0\0\0\0"

	 If a new string S not linked to S1 is to be created, this can be
	 achieved by using str(S1) in place of S1.  For example, the strcpy in

	    A = "xxxxxx"
	    S = strcpy(str("xxxxxx"), "abc")

	 would not change the value of A.

    (28) I've extended the definitions of copy(A, B, ssi, num, dsi) and
	 blkcpy(B, A, num, ssi, dsi) to allow for string-to-string copying
	 and block-to-string copying, but num is now an upper bound for the
	 number of characters to be copied - copying will cease before num
	 characters are copied if the end of the data in the source A or the
	 end of the destination B is reached.  As with other character-changing
	 operations, copying to a string B will not change the locations of
	 B[0], B[1], ... or the size of B.

	 In the case of copying a string to itself, characters are copied in
	 order of increasing index, which is different from block-to-block
	 copying where a memmove is used.  This affects only copy from a
	 string to itself.  For example,

		    A = "abcdefg";
		    copy(A, A, , , 2);

	 will result in A == "abababa".  If the overwriting that occurs here
	 is not wanted, one may use

		    A = "abcdefg";
		    copy(str(A), A, , , 2);

	  which results in A == "ababcde".

    (29) perm(a,b) and comb(a,b) have been extended to accept any real a and
	 any integer b except for perm(a, b) with integer a such that b <= a < 0
	 which gives a "division by zero" error.  For positive b, both functions
	 are polynomials in a of degree b;  for negative b, perm(a,b) is a
	 rational function (1/((a + 1) * (a+2) ...) with abs(b) factors in the
	 denominator), and comb(a,b) = 0.  (An obvious "todo" is to extend this
	 to complex or other types of a.)

    (30) Although it is not illegal, it seems pointless to use a comma operator
	 with a constant or simple variable as in

		    > 2 * 3,14159
			    14159
		    > a = 4; b = 5;
		    > A = (a , b + 2);
		    > A
			    7

	 I have added a few lines to addop.c so that when this occurs a
	 "unused value ignored" message and the relevant line number are
	 displayed.  I have found this useful as I occasionally type ','
	 when I mean '.'.

	 There may be one or two other changes resulting from the way I have
	 rewritten the optimization code in addop.c.  I think there was a bug
	 that assumed that PTR_SIZE would be the same as sizeof(long).  By
	 the way, the new OP_STRING is now of index rather than pointer type.
	 It follows that pointers are now used in opcodes only for global
	 variables.  By introducing a table of addresses of global variables
	 like those used for "constants" and "literal strings", the use of
	 pointers in opcodes could be eliminated.

    (31) When calc has executed a quit (or exit) statement in a function or
	 eval evaluation, it has invoked a call to math_error() which causes
	 a long jump to an initial state without freeing any data on the
	 stack, etc.  Maybe more detail should be added to math_error(), but
	 to achieve the freeing of memory for a quit statement and at the same
	 time give more information about its occurrence I have changed the
	 way opcodes.c handles OP_QUIT.  Now it should free the local variables
	 and whatever is on the stack, and display the name and line-number,
	 for each of the functions currently being evaluated.  The last
	 function listed should be the "top-level" one with name "*".
	 Strings being eval-ed will have name "**".

	 Here is a demo:

	    > global a;
	    >
	    > define f(x) {local i = x^2; a++;
	    >> if (x > 5) quit "Too large!"; return i;}
	    f() defined
	    > define g(x) = f(x) + f(2*x);
	    g() defined
	    > g(2)
		    20
	    > g(3)
	    Too large!
		    "f": line 3
		    "g": line 0
		    "*": line 6
	    > eval("g(3)")
	    Too large!
		    "f": line 3
		    "g": line 0
		    "**": line 1
		    "*": line 7
	    > a
		    6

    (32) I've made several small changes like removing

		    if (vp->v_type == V_NUM) {
			    q = qinv(vp->v_num);
			    if (stack->v_type == V_NUM)
				    qfree(stack->v_num);
			    stack->v_num = q;
			    stack->v_type = V_NUM;
			    return;
		    }

	 from the definition of o_invert.  Presumably these lines were intended
	 to speed up execution for the common case of numerical argument.
	 Comparing the runtimes with and without these lines for inverting
	 thousands of large random numbers in a matrix suggest that execution
	 for real numbers is slightly faster without these lines.

	 Maybe this and other similar treatment of "special cases" should be
	 looked at more closely.

    (33) The new lib script lib/natnumset.cal demonstrates how the new
	 string operators and functions may be used for defining and
	 working with sets of natural numbers not exceeding a
	 user-specified bound.


Following is the change from calc version 2.10.3t5.28 to 2.10.3t5.33:

    Added hnrmod(v, h, n, r) builtin to compute:

	v % (h * 2^n + r), h>0, n>0, r = -1, 0 or 1

    Changed lucas.cal and mersenne.cal to make use of hnrmod().

    A number of changes from Ernest Bowen:

	(1) introduction of unary & and * analogous to those in C;

	    For an lvalue var, &var returns what I call a
	    value-pointer; this is a constant which may be assigned to
	    a variable as in p = &var, and then *p in expressions has
	    the same effect as var.  Here is a simple example of their use:

		> define s(L) {local v=0; while (size(L)) v+= *pop(L);return v;}
		s() defined
		> global a = 1, b = 2;
		> L = list(&a, &b);
		> print s(L)
		3
		> b = 3;
		> print s(L)
		4

	    Octet-pointers, number-pointers, and string-pointers in
	    much the same way, but have not attempted to do much with
	    the latter two.

	    To print a pointer, use the "%p" specifier.

	    Some arithmetic operations has been defined for corresponding
	    C operations.  For example:

		> A = mat[4];
		> p = &A[0];
		> *(p+2) == A[2]
		> ++p
		> *p == A[1]

	    There is at present no protection against "illegal" use of &
	    and *, e.g. if one attempts here to assign a value to *(p+5),
	    or to use p after assigning another value to A.

	    NOTE: Unlike C, in calc &A[0] and A are quite different things.

	    NOTE: If the current value of a variable X is an octet,
	    number or string, *X may be used to to return the value of
	    X; in effect X is an address and *X is the value at X.

	    Added isptr(p) builtin to return 0 is p is not a pointer,
	    >0 if it is a pointer.  The value of isptr(p) comes from the
	    V_XYZ #define (see the top of value.h) of the value to which
	    p points.

	    To allow & to be used as a C-like address operator, use of it
	    has been dropped in calls to user-defined functions.  For the
	    time being I have replaced it by the back-quote `.  For example:

		> global a
		> define f(a,b) = a = b
		> f(&a,5)
		> print a
		0
		> f(`a,5)
		> print a
		5

	   However, one may use & in a similar way as in:

		> define g(a,b) = *a = b
		> g(&a, 7)
		> print a
		7

	   There is no hashvalue for pointers. Thus, like error values,
	   they cannot be used as indices in an association.

	   The -> also works in calc. For example:

		> obj xy {x,y}
		> obj uvw {u, v, w}
		> obj xy A = {1,2}
		> obj uvw B = {3,4,5}
		> p = &A
		> q = &B
		> p->x
			1
		> p->y = 6
		> A
			obj xy {1, 6}
		> q -> u
			3
		> p->y = q
		> A
			obj xy {1, v-ptr: 1400474c0}
		> p->y->u
			3
		> p->y->u = 7
		> B
			obj uvw {7, 4, 5}
		> p -> y = p
		> A
			obj xy {1, v-ptr: 140047490}
		> p -> y -> x
			1
		> p->y->y
			v-ptr: 140047490
		> p->y->y-> x
			1
		> p->y->y->x = 8
		> A
			obj xy {8, v-ptr: 140047490}


	(2) a method of "protecting" variables;

	    For the various kinds of "protection", of an l_value var,
	    bits of var->v_subtype, of which only bits 0 and 1 have been
	    used in the past to indicate literal and allocated strings.
	    This has meant initialization of var->v_subtype when a new var
	    is introduced, and for assignments, etc., examination of the
	    appropriate bits to confirm that the operation is to be permitted.

	    See help/protect for details.

	(3) automatic "freeing" of constants that are no longer required.

	    For the "freeing" of constants, the definition of a NUMBER
	    structure so that a NUMBER * q could be regarded as a
	    pointing to a "freed number" if q->links = 0.

	    The old q->num was changed to a union q->nu which had a pointer
	    to the old q->num if q->links > 0 and to the next freed number
	    if q->links = 0.  The old "num" is #defined to "nu->n_num".

	    The prior method calc has used for handling "constants" amounted
	    to leakage.  After:

		> define f(x) = 27 + x;
		> a = 27;

	    It is of course necessary for the constant 27 to be stored, but
	    if one now redefines f and a by:

		> define f(x) = 45 + x;
		> a = 45;

	    There seems little point in retaining 27 as a constant and
	    therefore using up memory.  If this example seems trivial,
	    replace 27 with a few larger numbers like 2e12345, or better,
	    -2e12345, for which calc needs memory for both 2e12345 and
	    -2e12345!

	    Constants are automatically freed a definition when a
	    function is re- or un-defined.

	    The qalloc(q) and qfree(q) functions have been changed so
	    that that q->links = 0 is permitted and indicates that q
	    has been freed.  If a number has been introduced as a
	    constant, i.e. by a literal numeral as in the above
	    examples, its links becoming zero indicates that it is no
	    longer required and its position in the table of constants
	    becomes available for a later new constant.

	(4) extension of transcendental functions like tan, tanh, etc.
	    to complex arguments

	(5) definition of gd(z) and agd(z), i.e. the gudermannian and
	    inverse gudermannian

	(6) introduction of show options for displaying information about
	    current constants, global variables, static variables, and cached
	    redc moduli.

	    To help you follow what is going on, the following show
	    items have been introduced:

		show constants ==> display the currently stored constants
		show numbers   ==> display the currently stored numbers
		show redcdata  ==> display the currently stored redc moduli
		show statics   ==> display info about static variables
		show real      ==> display only real-valued variables

	    The constants are automatically initialized as constants and
	    should always appear, with links >= 1, in in the list of constants.

	    The show command:

		show globals

	    has been redefined so that it gives information about all
	    current global and still active static variables.

	(7) definition of functions for freeing globals, statics, redc values

	    To free memory used by different kinds of variable, the following
	    builtins have been added:

		freeglobals();		/* free all globals */
		freestatics();		/* free all statics */
		freeredc();		/* free redc moduli */
		free(a, b, ...);	/* free specific variables */

	   NOTE: These functions do not "undefine" the variables, but
	   have the effect of assigning the null value to them, and so
	   frees the memory used for elements of a list, matrix or object.

	   See 10) below for info about "undefine *".

	(8) enhancement of handling of "old value": having it return an
	    lvalue and giving option of disabling updating.

	    Now, by default, "." return an lvalue with the appropriate
	    value instead of copying the old value.

	    So that a string of commands may be given without changing
	    the "oldvalue", the new builtin:

		saveval(0)

	    function simply disables the updating of the "." value.
	    The default updating can be resumed by calling:

		saveval(1)

	    The "." value:

		> 2 + 2
		4
		> .
		4

	    can now be treated as an unnamed variable.  For example:

		> mat x[3,3]={1,2,3,4,5,6,7,8,9}
		> x
		> print .[1,2]
		6

	(9) for a list L defining L[i] to be same as L[[i]]

	(10) extending undefine to permit its application to all user-defined
	     functions by using "undefine *".

	     The command:

		undefine *

	     undefines all current user-defined functions.  After
	     executing all the above freeing functions (and if
	     necessary free(.) to free the current "old value"), the
	     only remaining numbers as displayed by:

		show numbers

	     should be those associated with epsilon(), and if it has been
	     called, qpi().

	(11) storing the most recently calculated value of qpi(epsilon)i and
	     epsilon so that when called again with the same epsilon it
	     is copied rather than recalculateed.

	(12) defining trace() for square matrices

	(13) expression in parentheses may now be followed by a qualifier
	     computible with its type

	     When an expression in parentheses evaluates to an lvalue
	     whose current value is a matrix, list or object, it may
	     now be followed by a qualifier computible with its type.

	     For example:

		> A = list(1,2,4);
		> B = mat[2,2] = {5,6,7,8};
		> define f(x) = (x ? A : B)[[1]];
		> print f(1), f(0)
		2 6

		> obj xy {x,y}
		> C = obj xy = {4,5}
		> p = &C
		> *p.x
		Not indexing matrix or object
		> (*p).x
		4

	(14) swap(a,b) now permits swapping of octets in the same or different
	     blocks.

	     For example:

		> A = blk() = {1,2,3}
		> B = blk() = {4,5,6}
		> swap(A[0], B[2])
		> A
			chunksize = 256, maxsize = 256, datalen = 3
			060203

    A few bug fixes from Ernest Bowen:

	B1: qcmpi(q, n) in qmath.c sometimes gave the wrong result if
		LONG_BITS > BASEB, len = 1 and nf = 0, since it then
		reduces to the value of (nf != q->num.v[1]) in which
		q->num.v[1] is not part of the size-1 array of HALFs for
		q->num.  At present this is used only for changing opcodes
		for ^2 and ^4 from sequences involving OP_POWER to
		sequences using OP_SQUARE, which has no effect on the
		results of calculations.

	B2: in matdet(m) in matfunc.c, a copy of the matrix m was not freed
		when the determinant turned out have zero value.

	B3: in f_search() in func.c, a qlinking of the NUMBER * storing the
		the size of a file was not qfreed.

	B4: in comalloc() in commath.c the initial zero values for real and
		imag parts are qlinked but not qfreed when nonzero values are
		assigned to them.  Rather than changing
		the definition of comalloc(), I have included any relevant
		qfrees with the calls to comalloc() as in
			c = comalloc();
			qfree(c->real);
			c->real = ...

	B5: in calls to matsum(), zeros are qlinked but not qfreed.  Rather
		than changing addnumeric(), I have changed the definition
		of matsum(m) so that it simply adds the components of m,
		which requires only that the relevant additions be defined,
		not that all components of m be numbers.


    Simple arithmetic expressions with literal numbers are evaluated
    during compilation rather than   The val representations of "a" and "b" have
	 been reversed.

	 bit with index n in this array.   This is consistent with the use of
	 bit for a number ch in [0,256), i.e. bit(char(ch), n) = bit(ch, n).
	 For n < 0 or n >= size(A), bit(A,n) returns the null value.

    (25) For assigning values to specified bits in a string, I've defined
	 setbit(A, n) and setbit(A, n, v).  The first assigns the value 1 to
	 bit(A, n), the second assigns test(v) to bit(A, n).

    (26) For consistency with the corresponding number operations, the shift
	 operations A << n and A >> n have been defined to give what look
	 like right- and left-shifts, respectively.  For example, "ab" << 2
	 returns the 16-bit array

		    0010000110010001

	 in which the array for "ab" has been moved 2 bits to the right.

    (27) To achieve much the same as the C strcpy and strncpy functions for
	 null-terminated strings, strcpy(S1, S2) and strncpy(S1, S2, n) have
	 been defined.  Unlike the blkcpy() and copy() functions, the copying
	 for these is only from the beginning of the strings.  Also, unlike C,
	 no memory overflow can occur as the copying ceases when size(S1) is
	 reached.  Note that these overwrite the content of S1 (which affects
	 all strings linked to it) as well as returning S1.  Examples:

	    S = strcpy(6 * "x", "abc")      <=>  S = "abc\0xx"

	    S = strcpy(3 * "x", "abcdef")   <=>  S = "abc"

	    S = strncpy(6 * "x", "abcd", 2) <=>  S = "ab\0xxx"

	    S = strncpy(6 * "x", "ab", 4)   <=>  S = "ab\0\0xx"

	    S = strncpy(6 * "x", "ab", 20)  <=>  S = "ab\0\0\0\0"

	 If a new string S not linked to S1 is to be created, this can be
	 achieved by 