MaplePrimes - Maplesoft Blog - Posts by Dr. Robert Lopez

Unary vs. Binary Negation Signs

rlopez — Mon, 26 Jun 2023 14:23:09 Z

Some texts distinguish between unary and binary negation signs, using short dashes for unary negation and a longer dash for binary subtraction. How important is this distinction to users of Maple?

Some earlier versions of Maple used to have short dashes for negation (in some places). Maple 2023 has apparently abandoned the short dash for unary negation, and all such signs are now a long dash.

How about math books? Do all texts make this short-long distinction? The typesetters for my 2001 Advanced Engineering Math book also opted for all long dashes and that book was set from the LaTeX exported from Maple 20+ years ago. But I also have texts in my library that use a short dash for unary negation, on the grounds that -a, the additive inverse of "a" is a complete symbol unto itself, the short dash being part of the symbol for that additive inverse.

Apparently, this issue bugs me. Am I making a tempest in a teapot?

A Surprising "Next-Number" Puzzle

rlopez — Mon, 08 Jan 2018 20:39:54 Z

My September 9, 2016, blog post ("Next Number" Puzzles) pointed out the meaninglessness of the typical "next-number" puzzle. It did this by showing that two such puzzles in the STICKELERS column by Terry Stickels had more than one solution. In addition to the solution proposed in the column, another was found in a polynomial that interpolated the given members of the sequence. Of course, the very nature of the question "What is the next number?" is absurd because the next number could be anything. At best, such puzzles should require finding a pattern for the given sequence, admitting that there need not be a unique pattern.

The STICKELERS column continued to publish additional "next-number" puzzles, now no longer of interest. However, the remarkable puzzle of December 30, 2017, caused me to pull from the debris on my retirement desk the puzzle of July 15, 2017, a puzzle I had relegated to the accumulating dust thereon.

The members of the given sequence appear across the top of the following table that reproduces the graphic used to provide the solution.

It turns out that the pattern in the graphic can be expressed as 100 – (-1)^k k(k+1)/2, k=0,…, a pattern Maple helped find. By the techniques in my earlier blog, an alternate pattern is expressed by the polynomial

which interpolates the nodes (1, 100), (2, 101) ... so that f(8) = -992.

The most recent puzzle consists of the sequence members 0, 1, 8, 11, 69, 88; the next number is given as 96 because these are strobogrammatic numbers, numbers that read the same upside down. Wow! A sequence with apparently no mathematical structure! Is the pattern unique? Well, it yields to the polynomial

which can also be expressed as

Hence, g(x) is an integer for any nonnegative integer x, and g(6) = -401, definitely not a strobogrammatic number. However, I do have a faint recollection that one of Terry's "next-number" puzzles had a pattern that did not yield to interpolation. Unfortunately, the dust on my desk has not yielded it up.

The Saga of the Subscript

rlopez — Thu, 21 Dec 2017 21:51:33 Z

In the beginning, Maple had indexed names, entered as x[abc]; as early as Maple V Release 4 (mid 1990s), this would display as x_abc. So, x[1] could be used as x₁, a subscripted variable; but assigning a value to x₁ created a table whose name was x. This had, and still has, undesirable side effects. See Table 0 for an illustration in which an indexed variable is assigned a value, and then the name of the concomitant table is also assigned a value. The original indexed name is destroyed by these steps.

At one time this quirk could break commands such as dsolve. I don't know if it still does, but it's a usage that those "in the know" avoid. For other users, this was a problem that cried out for a solution. And Maplesoft did provide such a solution by going nuclear - it invented the Atomic Variable, which subsumed the subscript issue by solving a larger problem.

The larger problem is this: Arbitrary collections of symbols are not necessarily valid Maple names. For example, the expression is not a valid name, and cannot appear on the left of an assignment operator. Values cannot be assigned to it. The Atomic solution locks such symbols together into a valid name originally called an Atomic Identifier but now called an Atomic Variable. Ah, so then x₁can be either an indexed name (table entry) or a non-indexed literal name (Atomic Variable). By solving the bigger problem of creating assignable names, Maplesoft solved the smaller problem of subscripts by allowing literal subscripts to be Atomic Variables.

It is only in Maple 2017 that all vestiges of "Identifier" have disappeared, replaced by "Variable" throughout. The earliest appearance I can trace for the Atomic Identifier is in Maple 11, but it might have existed in Maple 10. Since Maple 11, help for the Atomic Identifier is found on the page

In Maple 17 this help could be obtained by executing help("AtomicIdentifier"). In Maple 2017, a help page for AtomicVariables exists.

In Maple 17, construction of these Atomic things changed, and a setting was introduced to make writing literal subscripts "simpler." With two settings and two outcomes for a "subscripted variable" (either indexed or non-indexed), it might be useful to see the meaning of "simpler," as detailed in the worksheet AfterMath.mw.

Kitonum's IntOverDomain Deconstructed

rlopez — Thu, 24 Aug 2017 21:09:46 Z

On 5/July/2017, Kitonum responded to the 3/July/2017 MaplePrimes question "How to perform double integration over subdomain" by providing code for a procedure IntOverDomain that implements Green's theorem applied to a planar region whose boundary is a simple, closed, rectifiable, oriented curve (SCROC by some authors).

I was intrigued. First, this is a significant extension of existing Maple functionalities. Second, the implementation admits boundaries defined piecewise with sections defined parametrically; or sections that are polygonal lines defined by a list of nodes.

But how was the line integral around such boundaries coded? In the worksheet "IntOverDomain_Deconstructed," I summarize the existing Maple functionality for implementing iterated double integrals over specified domains, then analyze how Kitonum coded Green's theorem as an extension of Maple's capabilities. After recognizing the great coding skills of Kitonum, I conclude with a short wishlist of related extensions that I would like to see added to Maple in the future.

Download the worksheet: IntOverDomain_Deconstructed.mw

Typesetting and Maple 2017

rlopez — Wed, 07 Jun 2017 15:54:07 Z

While preparing for a recent webinar, I ran across something that didn't behave the same way in Maple 2017 as it did in previous releases. In particular, it was the failure of the over-dot notation for t-derivatives to display with the over-dot. Turns out that this is due to a change in behavior of typesetting that was detailed in the What's New page for Maple 2017, a page I had looked at many times in the last few months, but apparently didn't comprehend fully. The details are below.

Prior to Maple 2017, under the aegis of extended typesetting, the following two lines of code would alert Maple that the over-dot notation for t-derivatives should be used in the output display.

However, this changed in Maple 2017. Extended typesetting is now the default, but these two lines of code are no longer sufficient to induce Maple to display the over-dot in output. Indeed, we would now have

as output. The change is documented in the following paragraph

lifted from the help page

Thus, it now takes the additional command

to induce Maple to display the over-dot notation in output.

I must confess that, even though I pored over the "What's New" pages for Maple 2017, I completely missed the import of this change to typesetting. I stumbled over the issue while preparing for an upcoming webinar, and frantically sent out help calls to the developers back in the building. Fortunately, I was quickly set straight on the matter, but was disappointed in my own reading of all the implications of the typesetting changes in Maple 2017. So perhaps this note will alert other users to the changes, and to the help page wherein one finds those essential bits of information needed to complete the tasks we set for ourselves.

And one more thing - I was cautioned that the "= true" was essential. Without it, the command would act as a query, echoing the present state of the setting, and not making the desired change to the setting.

Girding the Equator of the Earth with a Belt

rlopez — Mon, 06 Feb 2017 21:17:50 Z

Recently, I came across an addendum to a problem that appears in many calculus texts, an addendum I had never explored. It intrigued me, and I hope it will capture your attention too.

The problem is that of girding the equator of the earth with a belt, then extending by one unit (here, taken as the foot) the radius of the circle so formed. The question is by how much does the circumference of the belt increase. This problem usually appears in the section of the calculus text dealing with linear approximations by the differential. It turns out that the circumference of the enlarged band is 2*Pi ft greater than the original band.

(An alternate version of this has the circumference of the band increased by one foot, with the radius then being increased by 0.16 ft.)

The addendum to the problem then asked how high would the enlarged band be over the surface of the earth if it were lifted at one point and drawn as tight as possible around the equator. At first, I didn't know what to think. Would the height be some surprisingly large number? And how would one go about calculating this height.

It turns out that the enlarged and lifted band would be some 616.67 feet above the surface of the earth! This is significantly larger than the increase in the diameter of the original band. So, the result is a surprise, at least to me.

This is the kind of amusement that retirement affords. I heartily recommend both the amusement and the retirement. The supporting calculations can be found in the attached worksheet: Girding.mw