I realize that we all come here from our own backgrounds. Mine is engineering. I have insisted on using units in documents for decades (swimming against the tide, I fear), and have been grateful that Mathcad used them, and used them in the same way that I see them in my professional journals and texts. I have seen some journals require the use of X = {X} [X] when first declaring a value. When I first encountered Maple, I thought that the use of [[]] was for academia. The comment here about students seems to address that.

I have seen the use of () {} [] for table col row labeling in texts and journals, which I think is fine, though I don't see any confusion arising from the absence of these symbols, either.

I have wished for many years that Maple provided a clean way to use bracketless units, because I find the brackets needlessly cluttering the document. In general, I find Maple's handling of units awkward and obtrusive. The idea of entering
convert(spd, 'units', 'mi'/'h');
is not one I look forward to.

It seems that the OP for this thread was referring to the use of Maple "natural units", which I have tried in the past. Unfortunately...up to the point where I last experimented with them, it was not easy to change from one unit to a more convenient one, say, from V/m to mV/m.

In closing, I vote strongly for at least making the use of [[]] optional, and providing for a clean and well-supported alternative presentation, rather than asking us to jump through print unit hoops. I'd simply like to see the units displayed as I see them in my journals and texts, and if I produce a document with units, I'd like to be able to simply type mV/m where I see V/m, and have the calculation rescaled. Students should not be /encouraged/ to use correctly scaled units; they should be /required/ to use correctly scaled and sensible units. Once past the classroom, the cost of not doing so is generally not acceptable.  I agree completely with the intent of the OP of that comment to develop a sense of formality in their work. I also teach at University, and /do not accept for credit/ any work that lacks properly scaled units where they are needed. Anyone completing a degree in any scientific|engineering field must surely learn the need for them. (In fact, I have found that by analyzing units in journal articles, I have uncovered flaws in reported algorithms.)
If I could, I'd give this thread 100 "thumbs up".
 

Georgio,

Thanks for the speedy reply. I checked the link, and it seems that Maple will still report -0 when the number is < 0, even if those digits are not showing. But I will see how this compares to the number formatting dialog.

Georgio,

Thanks for the speedy reply. I checked the link, and it seems that Maple will still report -0 when the number is < 0, even if those digits are not showing. But I will see how this compares to the number formatting dialog.

Thanks, acer. I followed these instructions and got the result, which I'll apply to all future documents as necessary. it is nice to have the muF working, and the auto simplification. I am not nearly proficient enough to have arrived at this solution any time soon ;-) I put this in the startup code for the document.

Thanks, acer. I followed these instructions and got the result, which I'll apply to all future documents as necessary. it is nice to have the muF working, and the auto simplification. I am not nearly proficient enough to have arrived at this solution any time soon ;-) I put this in the startup code for the document.

For the past several days I have gotten 5 copies of several of my own posts dating from last year. "I classify this issue as an 'annoyance', not a critical issue" ...well, yes, I agree with the "annoyance" part...(So what is critical? A badge is the wrong color? (I know - sarcasm...)) ...and w Alexjandro on both counts. I vote for "do less and do it well"...kill the glitter and bolster the foundation. Just as Alejandro has decreased his particitation, so have I - not because I don't want to share, but because time constraints make dealing with a balky and inefficient interface somewhat prohibitive. It would be one thing if this were the best that the web has to offer, but it is not by a long shot. Maplesoft is in good company with several other major software vendors who all apparently sip coffee at the same cafe...if there is time to implement the glitter of badges and scoring, there is time to NOT do that, and focus on producing a good forum. "A significant number of regular posters expressed also their share of complaints." Well, I wasn't online at the time, so I didn't see it, but I did see it at other forums. I appreciate the forum being in existence more than I can adequately express here, but that doesn't mean that I don't know that there are much better ways to implement it. To be honest, I am not a web developer or a forum developer, so maybe I am missing some understanding

"Our web development team is small, and we do not have a dedicated MaplePrimes resource." This seems to be a problem w many companies these days. I still see it as a sort of corporate ADHD. Time to start things and look good, no time to do it well...hard to blame the folks at the bottom of the ladder who are just doing what they are told to do each day...

20 years ago, I left a corporate environment as a software engineering supervisor and started my own company. We produce very technical, vertical market products. I took with me lessons learned in the corporate environment of a very large company. Preeminent among my company's principles of conducting business are customer relationships, product excellence, and integrity. Increasingly it seems to me that companies are just rolling out products with little attention paid to the actual quality involved or how their client base will relate to the product. 3 months to fix a simple email notification problem is indefensible, and points to Maplesoft's priorities. Think of all the extra internet traffic that was generated, the wasted time spent managing the useless repeated emails, the irritation of those who received them...all not worth Maplesoft's time to address.

I will admit in making these comparisons that my customers pay for our products, and therefore may be thought to have a different set of expectations. But in reply, I opine that the expectations should be similar. Just because we don't pay /directly/ for access to this forum is not an excuse for the poor implementation. This forum is slow and awkward to use, and loaded with useless glitter and glitz. As someone who appreciates a "sense of artistry in delivered products," I certainly appreciate an attractive presentation over a stark one. There are, however, simpler, more effective forums to implement.

This preference for glitter over function, and the lack of corporate response is not limited to Maplesoft by any means. Another company whose product I use regularly recently swapped out a reasonablly efficient and easy-to-use forum for one of these glitter boxes, and the critical response was (still is) lengthy and harsh. What's the point of doing something if you are not going to do it well? While I don't want to say that the whole forum is a complete waste - after all, I came here hoping to find an effective tool to help me learn Maple (in the face of the less-than-adequate Maple Help system) - I do find myself wondering what all the fluff is supposed to achieve. Am I in a minority; that is, did a majority of forum members vote for this in my absense, or is this the implementation of some corporate entity that imagines that this fulfulls a corporate goal, with little regard to its actual performance?

Story time: When I worked for the corporation, I was jointly tasked one fine day, along with a recent graduate with a M.S. degree in engineering, with producing an internal product to be used by the company's blue collar work force. The other engineer (I'll call him Fred) quickly finished his part of the project (a precursor to my part), and brought it to me so that I could do my work. I commented that his implementation would place a long-term burden of extra work on the workers. His repy was that /we/ were highly paid engineers with goals to meet, and the workers got paid less, so could work more - or something to that effect. The bottom line was that Fred was more concerned with looking good to our boss by finishing his task in short order than he was in the quality of the finished product, and his attitude toward blue collar workers was clearly less than complimentary. He suggested that we take the project to our supervisor for evaluation. We did so. After Fred had proudly presented his part of the project and expressed his disagreement with my reaction to his work, our supervisor simply looked at him and quietly commented that Fred would be in the field for the first 3 months of product rollout to help the workers learn how to use the product. No criticism, just the comment. Not long after that, Fred showed up at my desk to ask me what I thought might be improved in his part of the project before he turned it over to me. The lesson here is not that I have all the answers, rather that the greater value is looking at the goals of a project and how effectively it will be used rather than checking off a COMPLETED box on some corporate checklist.

@amrramadaneg While it is true that I have been a member for longer than you, I have very little experience with Maple itself, for reasons that I have posted elsewhere in this forum. I am just graduating with a B.S. in Physics in the U.S. I am already in grad school and intend to go on to my Ph.D. So while I have some good experiences in life so far that will stand me in good stead, I have neither the math knowledge nor the Maple skills of most of the folks here. Nonetheless, I am here to learn and to help where I can.

Regards, &c.,

~R~

@amrramadaneg While it is true that I have been a member for longer than you, I have very little experience with Maple itself, for reasons that I have posted elsewhere in this forum. I am just graduating with a B.S. in Physics in the U.S. I am already in grad school and intend to go on to my Ph.D. So while I have some good experiences in life so far that will stand me in good stead, I have neither the math knowledge nor the Maple skills of most of the folks here. Nonetheless, I am here to learn and to help where I can.

Regards, &c.,

~R~

@amrramadaneg I am as puzzled as Markiyan by this number. I am not proficient with the MaplePrimes forum, and cannot relate to either "registrations" or to the number 595. Do you see something in my profile that I do not? You list your "registration" as 49, but I do not see such a number on your profile page when I look there. This is a small matter, of little consequence, but you have piqued my curiosity.

~R~

@amrramadaneg I am as puzzled as Markiyan by this number. I am not proficient with the MaplePrimes forum, and cannot relate to either "registrations" or to the number 595. Do you see something in my profile that I do not? You list your "registration" as 49, but I do not see such a number on your profile page when I look there. This is a small matter, of little consequence, but you have piqued my curiosity.

~R~

Thanks for a clear explanation and example. Perhaps someone @ Maple (now Cyberne?) will consider modifying Help in this vein?

I looked quickly in the programs I use regularly (MATLAB, C++, Delphi, &c.) and did not find a reference to left and right precedence, but a web search did turn up some references. If there is a mathematical reason for such a construct in Maple, I'd appreciate seeing the explanation; if not, then I recommend simplifying precedences so that operators have hierarchical precedence that is either left-to-right or right-to-left. Without this thread, I would have been puzzled and frustrated the first time that I used mod and got these strange results. Of course, even though I am a new student using Maple, I already have a habit of using () to order operations in programs such as Maple, so perhaps it would have been some time before the mod bug bit me ;-)

Thanks for a clear explanation and example. Perhaps someone @ Maple (now Cyberne?) will consider modifying Help in this vein?

I looked quickly in the programs I use regularly (MATLAB, C++, Delphi, &c.) and did not find a reference to left and right precedence, but a web search did turn up some references. If there is a mathematical reason for such a construct in Maple, I'd appreciate seeing the explanation; if not, then I recommend simplifying precedences so that operators have hierarchical precedence that is either left-to-right or right-to-left. Without this thread, I would have been puzzled and frustrated the first time that I used mod and got these strange results. Of course, even though I am a new student using Maple, I already have a habit of using () to order operations in programs such as Maple, so perhaps it would have been some time before the mod bug bit me ;-)

@Robert Israel (...and one of them is how this reply will work...)

In the interim, I ran several mod tests...

I interpreted "The left precedence of the mod operator is lower than (less binding strength than) the other arithmetic operators.  Its right precedence is immediately higher than +, - and lower than *, /."

...to mean that in the expression "a + b mod c + d" that "right precedence is immediately higher than +, -" would result in a + (b mod c), mod, in this case, being to the right of the expression "a + b." In other programming languages that I have used, this is the way I the way that I interpreted precedences. And "left precedence of the mod operator is lower than..." meant to me that in the expression above I'd get mod (c+d), mod, in this case, being to the left of the expression "c + d." In fact, it is just the opposite: "left precedence of the mod operator is lower than..." means that mod gets executed before expressions to the right. It may be that "left precedence of the mod operator is lower than" means that mod is of lower precedence than expressions to the left, but I find that an unusual way to express such a concept; hence my confusion.

I'm glad that I ran into this before I actually had to use mod in Maple, because I'd have been puzzled for a while with the results.

~R~

@Robert Israel (...and one of them is how this reply will work...)

In the interim, I ran several mod tests...

I interpreted "The left precedence of the mod operator is lower than (less binding strength than) the other arithmetic operators.  Its right precedence is immediately higher than +, - and lower than *, /."

...to mean that in the expression "a + b mod c + d" that "right precedence is immediately higher than +, -" would result in a + (b mod c), mod, in this case, being to the right of the expression "a + b." In other programming languages that I have used, this is the way I the way that I interpreted precedences. And "left precedence of the mod operator is lower than..." meant to me that in the expression above I'd get mod (c+d), mod, in this case, being to the left of the expression "c + d." In fact, it is just the opposite: "left precedence of the mod operator is lower than..." means that mod gets executed before expressions to the right. It may be that "left precedence of the mod operator is lower than" means that mod is of lower precedence than expressions to the left, but I find that an unusual way to express such a concept; hence my confusion.

I'm glad that I ran into this before I actually had to use mod in Maple, because I'd have been puzzled for a while with the results.

~R~