@acer 

That worked wonderfully well. In a million years I couldn't have done that.

But,  for 1. your information and 2. my curiosity:

1. your code forgot to put ";" after each of the lines containing

"end proc)"

which was easy enough to fix.

2. The whole issue raises the question:

"Why did the Maple developers not insert line feeds when the internal procedures were read when they put them everywhere else"?

Thank you.

@mmcdara 

Hi:

That worked well... until I looked at the ouput.

It seems that my ancient program consists of a procedure with two embedded internal procedures, each of which has many lines.

So the output of the outermost procedure looks fine, but the listing of the inner procedures omits line feeds, so all I can see is one long mess of run-on commands that are undecipherable, even though the ";" are present. I tried cut/paste but that didn't add any line feeds; I tried writing the eval output to a separate file, but there are still no line feeds to be found. If I execute the outer procedure, output look OK, but copypaste just reverts to run-on.

Is there a simple way to add line feeds to the eval output?

I also checked to see if the internal procedures show in unames and they don't so eval( internal procedure name) doesn't do anything.

Thank you.

PS - I am using Maple 2024.1 now. Maybe I should try resurrecting Maple 11.

regarding my previous comment, I should have added that when CERN stopped work on SCHOONSCHIP, both Veltman and Wolfram left for greener fields - Veltman to continue developiing his code, and Wolfram to developing Mathematica. You can still see traces of SCHOONSCHIP syntax in Mathematica, notable the use of underscore as in "x_" to denote an argument.

I was very interested in your blog essay since I was heavily involved with such calculations in the mid-1980's and thought that I could add a bit to your history.

From the late 1970's for about 10 years, I used SCHOONSCHIP ("Man the Decks!" in Dutch I believe) on a CDC 6600 with great success [1]. 

It was written in CDC assembly language (60 bit), and I might somewhere still have a floppy disk with a listing.

I had tried REDUCE, MACSYMA and an early version of MAPLE without any success - they quickly ran out of memory.

Sometime about 1980, Veltman left CERN for U Michigan and took SCHOONSCHIP with him by rewriting it (in Motorola 6000(?) assembly language - one of the most amazing and unheralded achievements in programming history!) and distributed it on

an Atari games cartridge [2]. I think his company somehow later morphed into the Lahey compiler company. 

When we lost our 6600 computer, I switched to a desktop Atari (with a hard drive) and continued evaluating Feynman integrals with considerable success.

I don't know how he did it, but Veltman wrote SCHOONSCHIP so that it could expand the number of terms in an expression into the millions and then whittled them down to a final answer with a few terms - in minutes - on an Atari!

It always told you how many millions of terms it had dealt with at the maximum. I still have access to the games cartridge which I recently donated to a local museum (http://nuclearheritage.com), 

so if anyone reading this knows how to duplicate an Atari games cartridge and has a 1980's Atari desktop still running, I suppose it is worth trying  some of  the more recent problems described in the blog to see how far ahead of the times Veltman really was.

Michael Milgram

[1]  Annals of Physics 157(2):408-431, DOI:10.1016/0003-4916(84)90067-8; or https://www.researchgate.net/publication/238952544

[2] H.Strubbe, Computer Physics Comm., 8, 1974, 1

That worked great.

Thank you.

Answered my own question:

This works

Test:=plots[textplot]([3,3,typeset(A,"'","(x)")]);

Very educational. Thank you both.

Very nice, but, there is an added complexity I don't understand.

How did you decide that _Z was a posint? According to the following, it is either an index, a symbol or an integer. The indets works as you suggested, but then we come to _B which seems to be either  an index, a symbol or OrProp. Again it works with posint, but why? See below. Thank you.

Just what I was looking for. Thank you.

But here is a subsidiary issue: if bb and aa are the first and second elements in the indets output (as they appear to be), could that change someday in a later release of Maple?

Or, is there a way to specify or quesry the output order of indets? Otherwise one must check the output against X, bringing us back to the beginning.

BTW: the previous suggestion

solve('identity'(aa/f^bb = 1.234/(f^6.789), f), {aa, bb});

is pretty clever, but doesn't work well because it introduces round-off, making logical checks later down the line fail.

To answer your query:

Because I was trying to understand Hansen's (and Maple's) reasoning so I could apply it to other cases that aren't so straighforward.

Thank you.

@Carl Love 

Yup, that works too.

All I needed was a simple one-time program to use as part of the testing of someone else's fancy algorithm, so thank you both, and I've learned something new about Maple programming.

@acer 

Hi:

Just one prime factor.

I just tried it and your solution works fine if you use "try" and "catch" in case the factor being sought isn't present.

Thank you.

Before I posed this question, I had read the "help" and found the command "printlevel" where it says that "printlevel=1000 is not uncommon". You  can guess what my traceback looked like. Your suggestion is much better. Thank you.

By the way, in case anyone reading this is interested, I tried this sum on Mathematica and it failed to come up with an answer.

Sorry not to be clear. To rephrase: the question is: "what internal algorithm did Maple use to come up with that answer", or alternatively, how can I find out what internal algorithm it used.

Thank you.

@acer Thank you - that did it.