Symbolic solution switches to built in constant

[DJF]

I've noticed this several times.  I have to assume it's a bug.

When using symbolics to solve for a variable, Prime 3.1 swaps out my defined variable with the built-in variable.  In this case, gamma (ratio of specific heats) is replaced with Euler's constant.  The good news is the color of the variable changes so I've at least got a clue it's happening.  But it shouldn't happen, right?  In this case it's unitless (or units cancel) so I didn't even get crazy units to point out a problem.  Is there a modifier to prevent this?

And it brings up another question, is there a way to turn off built-in constants?  (except for pi and e, ideally)  While I understand they are useful, on several occasions I've gotten 'wrong' answers because of a mixup.  (e.g. sigma = Stefan-Boltzman instead of stress).  Admittedly my fault but I'd rather get an error if I haven't defined 'h' rather than it jumping to Planck's constant.  When trying to advocate for Mathcad this is one of the little things that makes me question my choice; a new and uncautious user could easily get the wrong number.

Thanks,

[-MFra-]

Hi dferry,

have you tried to set the selected labels on automatic, as in the following picture:

[Fred_Kohlhepp]

This is one of my "pet peeves" with Prime.  The use of Labels has been brought forward to the level of nuisance:

The difference from above is that the definition (:=) gamma is a variable; the bottom line has the left gamma labeled a constant and the right gamma is a variable.  Relabeling the definition as a constant creates

The "variable" gamma is undefined.

Valery loves playing these games; they drive me crazy!

[Fred_Kohlhepp]

Not sure exactly what you're seeing.  In Prime 3.0, in a new sheet, I see this:

Here gamma is (apparently) Euler's constant.  (I wasn't aware or this); but the symbolic engine left it as a symbol.  This is how I interpret your page above--the symbolic solution treats the answer.  If I define a numeric variable with the symbolic solution, I get:

and if I change gamma:

(This may be a clue why the gamma changed--your symbolic engine didn't put the 1.4 in to replace gamma.)

[Werner_E]

I agree that it should not happen.

I don't know of a way to turn off built-in constants (other than to redefine them).

Also the setting

does not change anything here.

The problem seems to be the "explicit" command which, as it looks, does not accept the redefinition of built-in constants. "Explicit" is often good for unexpected results.

Nevertheless - its sure not as is should be:

[-MFra-]

Hi Werner,

The user can redefine the constants as he like. For example:

[Werner_E]

Hi F.M., I guess you missed the point of the question and my answer to it.

Sure you can redefine every constant.Nobody has doubt it.

But the point is that dferry wants to define a variable with the same name as a predefined constant. Due to different labels this is possible and should be possible. And we would expect that every calculation respects the difference and distinguishes between the two. Now a calculation was found (symbolic solve, eval with explicit) which mixes up the two and replaces the variable by the constant. Thats a no-go and can be called a bug.

Hope you understand the problem better now.

[-MFra-]

Dear Werner,

I See, on several occasions, that you point out, with pleasure, that I do not understand almost nothing, thank you for letting me know, but I would like you to think to solve the user's problem and not to intervene on the validity of my answer, on which It should only intervene the person-to-whom it is addressed.

I'm almost  seventy years old, and after a life of teaching,  bother me being treated like a schoolboy. Let me take care to correct my mistakes.

[Werner_E]

ADDENDUM:

Mathcad 15 treats built-in constants as variables, so we do not experience this effect

So obviously the newly (?hmm) introduces labeling system in Prime has still its quirks.

When I wrote above

"The problem seems to be the "explicit" command which, as it looks, does not accept the redefinition of built-in constants."

this wasn't exactly what I was trying to say. The symbolic "explicit" has problems to distinguish between the built-in constant gamma and the newly defined variable gamma and replaces the variable with the constant. Redefining the constant is possible and works OK, but means more work (explicitly labeling the typed gamma a constant) and may not be desirable.

Nonetheless, my " "Explicit" is often good for unexpected results." still applies 😉

[-MFra-]

[Werner_E]

Not sure what you want to show - your screenshot seems to shows  the same effect as the one provided by the original poster, or doesn't it? Better to stay with simplified examples which show the same effect as seen in my screenshots and change the colors for constants and variables for clarity. The default colors cannot be distinguished that well in a screenshot.

Turning on or off automatic labeling does not change anything here (as you can see from my answer above) and numeric evaluation of course works, unless you apply it to the symbolically derived (wrong) expression (also seen in my screen shot - the first eval using "explicit").

BTW, the only way to avoid this nasty effect is to label gamma explicitly as "constant" when you define it via gamma:=1.5.

This will get rid of the built-in constant gamma completely and the subsequent calculations will be es expected - even the symbolic evaluations using "explicit" without arguments or with non-existing arguments.

But this is not always desirable. Maybe I'd like to have a variable called c and want to use the built-in const c, too. Not good style and would avoid doing so in any way, but with a correctly working labeling  system this should be possible.

So I still consider this effect being a bug.

[-MFra-]

Well, with my first and third picture I wanted to show the uncertainty of results when in symbolic calculations, we use the names of universal physical constants, redefined by ourselves. But Prime is full of oddities. To avoid this weird stuff is better to add a subscript to the variables and constants in order to avoid confusion. For example, instead of writing just gamma, write gamma with a numerical subscript, other common cases are s, m, l and L et cetera.

In fact in the following illustration, the uncertainty there is no more:

[Werner_E · Accepted solution]

I guess most of us know how to avoid those "oddities", e.g. by using variable names with indices. But ever so often we want to use a variable name corresponding to the name of predefined constant and we don't want to use indices for various reasons. Maybe because we are used to, maybe because its the common term, maybe because we want to duplicate what we see in a book. ... And Mathcad should be the tool to make this possible in a convenient and easy way.

But in this thread the OP simply pointed to a bug in Prime (which it sure is and can only be confirmed) and asked if there would be a way to disable predefined constant (and there is none other than redefining them).

The bug, BTW is only very specific to symbolic evaluation in conjunction with the "explicit" modifier used without a valid variable.

So I was confused by your post, missing the reference to the posed question.