# Percent Unit behavior

Posted 6 years ago
5507 Views
|
6 Replies
|
4 Total Likes
|
 (first things first: I'm absolutely no specialist in units and on S.I. rules...)When we use the % Unit in a Mathematica numerical calculation, I feel that it is odd that it doesn't simplify it to a fraction multiplication.   Probably this is correct behavior (if I placed different forms of it, its because I question myself...), but I'm interesting to know why we might prefer this non reduced form.And if we try to divide a number or unit by a percentage number, Mathematica returns an odd result. Is this something that should be fixed? Answer
6 Replies
Sort By:
Posted 6 years ago
 If you think of Percent as just another unit (Like meters, kilograms, seconds, Ampere, Joule et cetera), then it is nice that it doesn't automatically reduce it. Just like Joule is equivalent to a constant: 1 Kilogram*meter^2/second^2, so is percent: % is the constant 0.01[no units]. Of course you can simplify this if you want using normal: Quantity[3.0, "Meters"] Normal[Quantity[50, "Percent"]] which will give you 1.5 meters as you might expect. To be honest, I never use 'percent' as a unit, I just use 0.04 (to indicate 4%), which is kind of standard in Physics...I guess the last one is indeed a small bug... Answer
Posted 5 years ago
 Still on the percentage "unit" behaviour, and extending this to other multipliers, I still have some trouble using them.In my head, I see % as being somehow similar to Kilo or Mega. But it seems that Mathematica treats it differently. For instance, the following seems very wrong: While this has a correct treatment: But other inconsistencies remain common to these multiples or fractions "units". The following behaves badly: But so does this one: And the same doesn't happen, for instance, while subtracting meters.Also interesting to notice that multiplying between the same "multiplier" units, makes them vanish: (...so are they really to be seen as Units? The percentage "units" on my original post didn't vanish. I'm really confused...)And interesting to notice that, while on the above they seem to be treated as multipliers (for instance, we don't get mega squared), we can't multiply between different ones: (the error message is interesting)And even more interesting is the fact that if we add a "first class" unit on the above example, we do get something: (I talked to early... we can get a mega squared! Extremely bizarre)So, some questions: are these known bugs and limitations? what is the language design philosophy concerning these multipliers? are there practical ways to deal with them? To have the control on making all disappear, or transforming all multipliers to a specified one, or to keep them all, etc.? (...I haven't explored the problems that can be brought by crossing the above with "compound" units, like Kilograms, but I guess that this "squares" the problem...) Every time I try to use Units, I always get blocked with these problems. Am I the only one? I mean, we can use units (besides the bugs) for personal calculations, and although sometimes confusing, we can help in someway to check for coherence. But for me, the most interesting thing brought by units is the "auto" documentation of the code. We can simply show the code to someone else, and, thanks to units, it gets understood much faster. But with all these idiosyncrasies (and the corrections that I'm forced to add to the code to correct them), really makes it less readable, and not of good publicity to the language... Answer
Posted 5 years ago
 Your first (2) examples are actually correct, W/Pa has the same dimensions as L/h (lengthscale^3 per timescale). Instead of using UnitSimplify, replace your commands with UnitConvert (without second argument), and these problems go away. Note that neither L nor h are SI units (and W and Pa are derived SI units). And % (also not an SI unit) can indeed be interpreted as 0.01. Your example of multiplying SI prefixes are indeed strange they don't further simplify. M^2 should become T(Tera). Your other example: UnitConvert[Quantity[1, "%"] Quantity[1, "Mega"]] Does work like that, but a mid-way error message is spawned...I always convert my non-SI units using UnitCovert (never used UnitSimplify) to SI units, from there it works flawlessly. I think the main problem is with using % is that sometimes you want it to be a number and sometimes a percentage. With addition of two percentages, you want percentage back. If you multiply it with anything else you want it to be 'absorbed'. This behavior should indeed be corrected.As a substitute you could use the SI prefix Centi to denote 1%. This might have better behavior than %. I always write my percentages as e.g. 0.3 rather than 30%...Final note; one never uses "mega" or "Kilo" separately. It is always Kilometer, or MegaPascal, or Centi meter. I've never seen just a prefix by itself, it should be a pre-fix... So that is maybe why you see the unexpected behavior, because it normally is never used like that... Answer
Posted 5 years ago
 Just to add, there seems to be some inconsistent behavior indeed, but (fortunately) it never gives a 'wrong' answer... Answer
Posted 5 years ago
 Thank you Sander. Indeed I can agree with the UnitSimplify result. It is very wrong in respect to my needs... I know that the uses are so many that it would be difficult to come with something universal (is this a job for NN? A high school trained NN, a biologist's trained NN, etc...). So, we should probably have simplify and a full simplify (or different options for simplify).I'm going to report some of the above, just to make sure they get into the tracking system. Answer
Posted 5 years ago
 Note that your last example of your first post was fixed in 11.0.1. There are also cases btw where you don't want kilo^2 not to be simplified. For example: Quantity[1,"Kilometers"]^2 'should' give 1 km^2 (to be read as (kilometer)^2) not 1 Mm^2 (to be read as mega-(meter^2)). So it is not that trivial in general... But if you start multiplying just prefixes, it is trickier! Answer