I'm not a happy camper. Mathcad 15 trial download AND paid box version both have the same undefined variable error bug?

[EETStoodent]

I spent an entire week out of my life neglecting my responsibilities while probing the mathcad help menus and tutorials and quicksheets so I could figure out what I'm doing wrong. I'm not doing anything wrong. I've included my latest worksheet as proof. I can't believe mathcad does not have an option for updates in the help menu like every other reputable software company on the planet. Am I going to have to search for some kind of update file on the ptc website to fix the bugs that come with the Mathcad 15 software that I paid for? I sincerely hope I will not have to purchase a yearly maintenance plan so that I can get basic bug fixes for "The Global Standard for Engineering Calculations."

[f.kohlhepp]

It's not broke; and it's not wrong.

The red and error are symptoms of your call to the symbolic processor. But the evaluation of Z_1 iss correct.

If you type Z_1:=R_1+L_1 and enter there will be no red, and Z_1--.>will get you the proper answer.

Red errors and symbolic processes are not new.

[EETStoodent]

::sigh:: Okay, here we go. Here is a better example of the Mathcad 15 bug that I'm trying to describe.

Just because a bug isn't new doesn't mean it's not broke and it's not wrong. If this bug has existed for a long time and it still has not yet been fixed then the people who work at Mathcad should really be ashamed of themselves. "The product development company" "The Global Standard for Engineering Calculations." Seriously?

[RichardJ]

It is not a bug. When you use the explicit keyword you are asking the symbolic processor to replace the variable with it's numeric value. In this case, it can't, because the symbolic processor sees ohms as an undefined variable. The symbolic processor does not know about units. That is a limitation, but it''s not a bug. Since PTC (or previously Mathsoft) did not write the symbolic engine there is little they can do about that.

[EETStoodent]

If it is not a bug then why was it working for me part of the time? Let me see if I can find those worksheets where it was working part of the time.

[EETStoodent]

Here is one example where it is working, and then later down the page on that same worksheet it stopped working again. I tell you there is something really weird going on behind the scenes. It has to be a bug. When things work sometimes but not other times, there is no way you can say it is supposed to be that way. I was born at night, but it wasn't last night!

[RichardJ]

When things work sometimes but not other times, there is no way you can say it is supposed to be that way.

On a computer, things very rarely work sometimes and not other times. They may appear to, but it's ecause something was done differently.

I was born at night, but it wasn't last night!

I'm not sure why you think I'm trying to mislead you.

Well, this shows how often I ever actually use the explicit keyword and/or inline evaluation (i.e. never). It looks like it is a bug. It's a combination of the inline evaluation in the definitions, units, and a symbolic evaluation followed by numerical evaluation. If you drop either the inline evaluations or the units it works. If you have both then for some reason when the expression is passed through the symbolic processor the units don't come through correctly and the numeric processor flags them as undefined variables.

[EETStoodent]

I don't think you are trying to mislead me. I appreciate the time you have spent helping me to find the answer to my question. Every bit of feedback that I receive will hopefully lead us closer to the solution.

And hopefully somebody who works for PTC will see this discussion and fix the dog gone bug/limitation/problem before more people download the 30 day trial and think "These PTC people don't know what they are doing because there are bugs in the 30 day trial download. Why should I give them my money?"

Because it wasn't just this one problem that I had with the 30 day trial download; it was unstable:

1.) It frequently locked up and crashed and displayed things wrong until I hit page up and page down a couple of times.

2.) The top line of an "area" can be backed up off of the top of page and UNDO won't bring it back down. ARGH!

3.) It is often times very not user friendly to figure out how to delete items from a previously entered equation, which is something that I frequently want to do after using copy/paste so I don't have to type part of the equation over again.

4.) One time after making a lot of changes to a worksheet I hit save and it told me that my worksheet was corrupted and Mathcad would not be able to open the worksheet later if I save the current version of the worksheet. WITW???

5.) And last but not least, many times it would not recognize variables that are clearly defined farther up on the worksheet. This is such a frustrating bug that I think I said a few curse words. It's true. I'm going to have to go to confession again just because of my experience with the Mathcad 30 day trial download.

Keep in mind that I'm not even trying to do anything complicated in the worksheet. Just using the basic features of Mathcad that are advertised in the quick sheets along with basic navigation and moving objects around the worksheet the way that any new user of Mathcad would try to do after having used any other basic WYSIWYG software program.

[StuartBruff]

Richard Jackson wrote:

It is not a bug. ... The symbolic processor does not know about units. That is a limitation, but it''s not a bug. Since PTC (or previously Mathsoft) did not write the symbolic engine there is little they can do about that.

I'm not sure that is entirely true. They could, perhaps, have defined a symbolic units handler that mimics the action of the numeric unit engine. I've got a vague recollection of writing a couple of worksheets that played around with this idea ... probably only worked in M11, of course 🙂

Stuart

Here's one, but it's not the one I had in mind. ... sorry about this, just whistle amongst yourself whilst I continue to rumage through worksheets ... ah hah! found it - had to search in the Collaboratory, though. 🙂

[RichardJ]

I'm not sure that is entirely true.

Well, OK. It is actually a bug: see my other post.

They could, perhaps, have defined a symbolic units handler that mimics the action of the numeric unit engine.

In principle, I guess you are right. In practice I think they just said "the symbolics engine has no units handling, end of story", because implementing a symbolic unit handler would be too much work.

probably only worked in M11, of course 🙂

Actually, "Test - Mixed Units 01a" works in MC15. "Mixed Units - symbolic" doesn't of course, because it relies on undocumented Maple commands. By the sound ot it, you haven't fixed your installation of 14.

found it - had to search in the Collaboratory, though. 🙂

I know that feeling

[RichardJ]

Why are you doing a symbolic evaluation followed by a numeric evaluation (if you are not aware of the distinction please say so, and you will get the 5 minute introduction)? The symbolic processor does not know about units, and that is the source of your problem. If you do a symbolic evaluation you see the symbol for Ohms, but it's not the unit of resistance, it's just an undefined variable. The symbolic processor does not care about undefined variables (after all, it does symbolic math!) but the result from the symbolic prrocessor is then passed to the numeric processor, which does care about undefined variables. If you want a numeric evaluation, use the numeric evaluation operator. If you want a symbolic evaluation use the symbolic evaluation operator, but always be aware that the symbolic processor does not know about units.

[EETStoodent]

It's all about the presentation. That is the whole reason I'm trying to use Mathcad instead of Mathematica or Matlab or Maple, all products which are vastly superior to Mathcad in just about every way you can imagine except when it comes to easily presenting the data the way that math PhD's want to see the data.

[wayne]

Well,

I learned Turbocad before Autocad, thought Autocad was not as good, unitl I got used to it. Now there's RIVIT, which is vastly better, except when it's not. Then must go back to Autocad.

I learned STAAD before SAP, then ROBOT, thought ROBOT was not as good, until I go used to it.

Then I learned RISA, it was better for the user and faster to learn that ROBOT, but not as general, and not as general as SAP either, but for everyday use, was better. So when RISA is not apporpriate , I go to one of the others.

A sledge hammer is more powerful and general than a finishing hammer, but If I was building a shelf I would rather have the finishing hammer.

( Just a saying, I am not necessarily saying that Mathcad is a finishing hammer compared to the others, but to suggest that the right tool for the job is not always the same tool)

Mathcad is by far the better tool for production work that must be documented and reviewed by others.

[MikeArmstrong]

Nice point Wayne.

Mike

[EETStoodent]

A sledge hammer is more powerful and general than a finishing hammer, but If I was building a shelf I would rather have the finishing hammer.

( Just a saying, I am not necessarily saying that Mathcad is a finishing hammer compared to the others, but to suggest that the right tool for the job is not always the same tool)

LMAO!!!!!!!!!!!!!!!!!

[MikeArmstrong]

Mathematica or Matlab or Maple, all products which are vastly superior to Mathcad in just about every way you can imagine except when it comes to easily presenting the data the way that math PhD's want to see the data.

Every single way!!!!!!!!!

Come on.

Mike

[EETStoodent]

LMAO

I heard that Maple is recruiting Mathcad customers after adding similar presentation friendly features to the Maple software. But I really don't have the time to obsessively learn yet ANOTHER software program, just so that I can find out that it has it's own set of limitations that I don't want to live with.

Mathcad would be almost perfect for what I need if PTC could just fix this seemingly trivial ----- NewVariable := CalculationWithOldVariables explicit, ALL → NumbersStoredInOldVariablesWithUnits = NewAnswerWithUnits ----- bug.

How hard can it possibly be for the PTC programmers, who are intimately familiar with the layout of the Mathcad code, to find and fix this bug? I was assuming it would have to be already fixed but I really don't want to download an "updated" version with a whole new set of bugs unless I know for sure that it will at least have this bug fixed.

[RichardJ]

I spent an entire week out of my life neglecting my responsibilities while probing the mathcad help menus and tutorials and quicksheets so I could figure out what I'm doing wrong.

As a tip for the future, your attempt at solving the problem by looking in the help is admirable. It is actually quite annoying when someone posts a question here that could have been answered easily by just looking in the help or Quicksheets. But there comes a time when the best thing to do is post a question to these forums, and perhaps that's at less than the one week point

[EETStoodent]

Yes, I'm really good at obsessing over a problem that seems like it should be easy enough to solve until I finally find the answer (days later LOL). I've been 100% sure that the answer to this problem exists just right around the next corner if I just open up the next quicksheet or the next help file. I've actually spent a lot of my time trying to engineer a work around to trick the software into doing what I want it to do since it was actually working part of the time. It was like somebody was playing a prank on me. This was all with the 30 day trial download that I wasted a week of my life. I shouldn't say wasted because now I'm really good at using a lot of the features of mathcad since I learned those features while searching for the solution that I was never able to find.

[mzeftel]

Hello,

I've gone through the posted worksheets, and Richard's example clearly shows the bug. I've logged the bug for both Mathcad 15 and the issue for the new version of the software, Mathcad Prime 1.0, as we implement symbolics in it.

As Richard pointed out, symbolics and explicit don't currently handle units, so you see some issues. He provided some workarounds for you.

We prioritize bugs for each release. It may seem easy to you to fix this issue, but units aren't implemented in symbolics, which makes it more complex.

If you recently purchased Mathcad 15, you also received a license for Mathcad Prime 1.0. We will be adding symbolics to Mathcad Prime.

Mathcad Prime 1.0 has both dynamic units, and units added to most functions, plots, and tables. It also allows mixed units in matrices, which is not a feature of previous versions of Mathcad. As we add symbolics to Mathcad Prime, we'll be adding improvements to it as well.

I hope this helps answer your questions.

And I'm glad you were able to learn many features of Mathcad through your investigation.

Best regards,

Mona

Mathcad Senior Technical Consultant

[Philip.Oakley]

Hi Mona,

I also reported a similar problem and it was registered as an SPR (software problem report) today, though I don't have permissions to view it! Apparently the setting is 'High'.

You mentioned the potential for the problem to be harder than we may think underneath. I'd suggest that part of the problem is that some of the development folk are just being 'reactive' and that with a little consideration, the particular problem at hand, isn't as hard as first thought.

The issue isn't that the symbolic processor doesn't care about units (which it doesn't), nor that the Numeric processor is able to resolve units down to their lowest common unit (e.g. Joule). We can easily see that these two processes work together after an 'explicit' and the numeric result is displayed.

The problem is with the 'read-back' interface between the numeric result, with its resolved units, and the input to the symbolic processor. We already know that if we re-type exactly the same result as the explicit/numeric result, with the implied units multiplication, then the symbolkic processor does fully recognise the answer.

The symbolic solver doesn't need to understand units, as long as the input parser includes the implied mulktiply between the number part and the units part of the numeric result display.

There is no need for the symbolic process itself (internally) to know anything about units. It is already quite happy, and we already get good results from the explicit keyword operation.

Essentially the gap is that when 'explicit', with in-line numeric results, was implemented, the codfe didn't include a regeneration of the whole expression including the implied multiply with the units place holder, with a full re-parsing of that expression.

I thoght I'd better get that off my chest, as I have seen similar misunderstandings in other development programmes

Philip

[mzeftel]

Philip,

Thanks for the additional details. My point was that this bug or any other bug is generally more complex to fix than just a couple of days. We prioritize bugs and new features for each release. It's been logged and will be reviewed.

Best,

Mona

[PhilipOakley]

Mona Zeftel wrote:

Philip,

Thanks for the additional details. My point was that this bug or any other bug is generally more complex to fix than just a couple of days. We prioritize bugs and new features for each release. It's been logged and will be reviewed.

Best,

Mona

No problem Mona, I know it won't be a couple of days! [unless that part of the code is already being ammended and would get in under the radar]. Once you have to complete SPRs, and do all the paperwork it can take a long time.

The point I was making was that often the bugs often aren't understood before the 'estimate' of effort is generated (I get it all the time + see the tree swing!). Once you actually talk to the coders and explain the situation they often see it in a clearer light and the estimate is greatly reduced, or are able to highlight some hidden bit that they hadn't told you about buried in their code, but at least everyone is better informed.

Good to hear that it will be addressed.

Philip