Like most food, pizza has a substantial quantity of water, even after it's baked. If it didn't, it would be extremely crunchy, more so than a cracker. The boiling temperature of water is 212 degrees F (at standard atmospheric pressure). Just because it comes out of a 350-degree oven doesn't mean that its temperature is 350 degrees: Its temperature never equilibrated in the oven. (This also means that the surface temperature is more than the maximum internal temperature, so Newton's Law can't be easily applied.) The standard food-safety recommendation in the USA is to cook things until they reach an internal temperature of 165 degrees.  

@Preben Alsholm Ah, thanks Preben. So the reason that I've never seen this is that I don't use 2D Input.

@C_R I use Maple 2023, but I've never seen this problem.

@mmcdara The syntax for local declarations has been updated in recent versions, and they no longer are required to be before any statements of a procedure. So, there's no syntax error in the OP's original. However, I do consider your modification to be a stylistic improvement because there's no need for the variable difference.

@Kitonum Yes, I was simultaneously computing that (using discrim), and it's now posted.

The maximum range of m can be determined thus:

eqBJ := y = m*(x - xJ) + yJ; 
eq1 := x^2 + y^2 - r^2;
solve(discrim(eval(eq1, eqBJ), x), m);

For your particular values of xJ, yJ, and r, that's

eval([%], [xJ,yJ,r]=~ [5,1,3]);
             [(5-sqrt(153))/16, (5+sqrt(153))/16] 

That's approximately m = -0.46 .. 1.08. Using this range in the animate command produces good results.

@dharr When using forget, it is often difficult to figure out exactly which procedures need to be forgotten; sometimes I find it impossible. Two things that should help in this example:

1. Int is just an inert unassigned name, not a command or procedure. Thus it can't have a remember table. It's a shame that forget(Int) doesn't return an error.

2. Although evalf is builtin, you can still extract its remember table via op(4, eval(evalf)). If you do this after a numeric integration, you will see the corresponding entry. This is likely one of those remembered results that is removed by garbage collection; if so, you'd need to extract it before it gets collected.

@ecterrab I totally agree with you that for the prettyprinted 2D output of the example you just showed, those parentheses are essential. In that particular case, the problem is that sometimes (and I don't know exactly what makes it happen), when it is converted into 1D input, it becomes ((diff(x),x))^2. You will often see this in 1D transcriptions of (usually lengthy) systems of ODEs in Questions here on MaplePrimes.

In the recent Post "Physics:-LagrangeEquations", I just added a Comment about some example where the parentheses are unneeded in the 2D display and one example where they are wrong (IMO).

(This Comment is not related to the Math and Physics discussion in this thread. It's only about how Maple displays derivatives.)

@ecterrab Edgardo,

Yesterday you said that you'd like reports of unnecessary or incorrect brackets (parentheses) in Maple output. I just found some examples in this thread. In your original Post, the equations labelled 16, 17, and 19 have some unnecessary brackets around derivatives. In your most-recent Comment (2024-Nov-6), the equation labelled 4 has brackets that to me are flat-out wrong: If brackets are used at all, then the S must be inside them.

If these brackets are different in the most recently updated Maple 2024 than they are on MaplePrimes, then I withdraw the Comment. However, in my Maple 2023, they do appear as they do above.

@dharr You need to replace forget(Int) with forget(evalf).

@acer Why did you use unevaluation quotes around util rather than making it a procedure?

Yes, I also don't like these extra brackets. They are very common around derivatives, for example diff(f(x),x)^2 becoming (diff(f(x),x))^2, even when that is transcribed from 2D into plaintext code. I spend too much time editing them out. 

Oddly enough, the extra brackets don't occur if you change your example from subtraction to addition.

@lemelinm You original Question very clearly and explicitly (in at least 5 different places, including the title and supplied image) asked about variables with assumptions. Now you say, essentially, that you want information about variables with assignments, which are mutally exclusive from variables with assumptions. (I am just explaining the source of my understanding of the Question, not trying to criticize you.)

The variables that have been assigned by you in the current session can be obtained by anames(user). To get them as a table, you could use

MyVars:= 'MyVars':
MyVars:= table((evaln=eval)~([anames](user)));

With a small amount of extra work, that table could be formatted; but you'd need to be careful about variables whose values are too large to easily display.

@C_R The ~ isn't needed to make the `*` case work. What's shown is just a red herring. See my Answer for complete details.

@janhardo You wrote (Replying to @dharr ):

• I'm not a fan of your code, which only shows maple commands. Keep in mind, that someone is asking for your help and needs some more explanation.

I doubt that the OP needs any mathematical help with this. You can view the OP's other Questions to assess this. I think that only help with the Maple commands is needed.