See attached. I'm using MathCAD 9.0.0.0 and am having a few problems...
- Is there a way to put a bar above the variable Yf so it looks like
? I found something online about using the Windows Character Map and I can copy the bar symbol, but it won't paste in MathCAD.
- The last few equations are showing values with a long trail of decimal places following "explicit,ALL." Is there a way to limit it to displaying only 3 or4 decimals? I set it in "Math Formatting > Results > Display Precision," but that seems to have no effect.
- Alternatively, is there a way to break long equations to have them continued on the next line?
- The following values are off...
- T=19.76*10^3 and it should be 19,786 N-m. That's only slightly off.
- P=1.3*10^6 W and it should be 207,201 N-m/s(W). That's way off.
- HP=1.744*10^3 and it should be 278 hp. That's way off. Is that all because of a rounding error, Something I did wrong, or is MathCAD misinterpreting one of my variables?
Thanks,
Brent
ACCEPTED SOLUTION
Accepted Solutions
problem 1: already was answered by Stuart
problem 2: You cannot format the numeric results of symbolic calculations, but you can limit the precision (in significant digits) symbolic calculations are done by using the modifier float,[nr]. Default is 20.
Unfortunately, 'float' negates the efforts of 'explicit'
So there is probably no solution to your problem except perhaps the possibility to explicitly round all (intermediate) results with "round".
problem 3: Short answer - NO. At least when you have breaking long results of (symbolic) evaluations in mind. Prime only offers options for inserting line breaks at the four basic arithmetic operations when entering terms.
So all you can do is using narrow margins, smaller font size and maybe paper in landscape mode instead of portrait.
problem 4: Already covered by Stuart. The 'unit' "rev" is an angle unit and actually it equals 2 pi. So either you redefine "rev" as being just 1 as suggested by Stuart or you omit the factor 2 pi when calculating P.
BTW, instead of rev/min you also could use the predefined frequency unit "rpm".
Concerning the other numeric discrepancies I also guess that they stem from the fact that your source document is using rounded intermediate results.
Hi, Brent,
Problem 1: You have to construct the overbarred character. The following is one way to get the desired result.
This process would be considerably simplified if there were a means of converting a string directly into an in-place variable.
By curious (or not) serendipity, there was another recent case where such a facility would have been useful. The OP wanted to automatically create some numbered variables (eg, n0, n1, .. n9) whilst obeying the principle of optimal laziness (ie, not doing manual repetitive work when a computer can do that stuff for you).
Stuart
Hi Brent,
Just had a look at your worksheet,
Problem 4:
It's possibly worthwhile checking the multiplications "by hand" in the worksheet, just to show where any rounding differences and assumptions might lie.
Stuart
problem 1: already was answered by Stuart
problem 2: You cannot format the numeric results of symbolic calculations, but you can limit the precision (in significant digits) symbolic calculations are done by using the modifier float,[nr]. Default is 20.
Unfortunately, 'float' negates the efforts of 'explicit'
So there is probably no solution to your problem except perhaps the possibility to explicitly round all (intermediate) results with "round".
problem 3: Short answer - NO. At least when you have breaking long results of (symbolic) evaluations in mind. Prime only offers options for inserting line breaks at the four basic arithmetic operations when entering terms.
So all you can do is using narrow margins, smaller font size and maybe paper in landscape mode instead of portrait.
problem 4: Already covered by Stuart. The 'unit' "rev" is an angle unit and actually it equals 2 pi. So either you redefine "rev" as being just 1 as suggested by Stuart or you omit the factor 2 pi when calculating P.
BTW, instead of rev/min you also could use the predefined frequency unit "rpm".
Concerning the other numeric discrepancies I also guess that they stem from the fact that your source document is using rounded intermediate results.
