Hi tbfl1919,

Let's first investigate what exactly is going on.

The functions *V__tot* and similar all take a unitless quantity t as their argument, as you can see by evaluating, for example, *V__tot*(1.3). In the integral, however, you specify the lower and upper bounds for *t*, the argument of *V__tot*, as *T*__1 and *T*__2, which are 0 and 1 ms. (I should note here that 0 is a special case - it can only be unitless in Maple for technical reasons - but the *int* command interprets the range as expressed in units of time.) So the *int* command tries to substitute time values for *t*, which causes the *sin* command inside *V__tot* to fail, as it does on the command line if you evaluate *V__tot*(1.3**Unit*(ms)). Maple decides that that's an expression it can't integrate and merely takes the unit, V^{2}, out of the integral. So we have now evaluated the integral to some unevaluated integral times the unit V^{2}. This is then divided by *T__*2 - *T*__1, a duration, to obtain an unevaluated integral with the unit V^{2}/s. The square root of this then has the unit V/s^{1/2}, which is equivalent to the unit you see. It could be argued that this is correct, because if we could specify the integrand better, the integral would come out to be a duration (it is a unitless quantity, integrated over a period of time, so the dimension is time), its square root therefore has the unit s^{1/2}, and multiplying that with the unit we see gives the unit m^{2} kg / s^{3} / A, which is the same as V.

However, this is all of course incredibly clunky and it doesn't lead to Maple giving you the answer you're looking for. So let's talk about solutions. The first option is to make the integral strip off the time unit and add it back on manually. I think the appropriate unit is ms, correct? So we can do that by specifying the lower and upper bounds as *T*__1/*Unit*(ms) and *T*__2/*Unit*(ms) and multiplying the integral by *Unit*(ms). This appears to lead to a correct result (of *sqrt*(2)/2 V). But this is, in some sense, cheating: we just remove the units manually and then put them back on. It's possible to do better.

The second option is to make *V__tot* accept an expression in terms of time, rather than a unitless quantity. For this we need to do two things:

- Redefine
*V__tot_AC*(*t*) := *A* * sin(*omega* * *t*);
- Be very careful to never submit a unitless quantity into
*V__tot* or *V__tot_AC*.

The latter issue appears, for example, when we try to plot these functions: the only way I can think to do this is to change the command to *plot*(*V__tot*(*t* * *Unit*(ms)), *t* = 0 .. 5) (and similar for *V__tot_AC*). It also appears when we want to do the integration: just entering *V__tot*(*t*) already causes an error. However, we can prevent the error by using unevaluation quotes (single forward quotes) around *V__tot*(*t*): *int*('*V__tot*(*t*)'^{2}, *t* = *T*__1 .. *T*__2) evaluates no problem. This leads to the same result of *sqrt*(2)/2 V.

You don't write what version of Maple you are using; if it is version 2017, you can use another trick to get around some of the problems here. In 2017 we introduced the *Units*[*Simple*] package as an alternative to *Units*[*Standard*]. The most important difference between the two is the following: the *Units*[*Standard*] package assumes that **every unassigned variable**, such as *t*, **represents a unitless quantity**. The *Units*[*Simple*] package does not. This restriction may have played a role in your decision to define *V__tot_AC*(*t*) the way you did, where you included the unit for *t* in the definition, rather than it just being part of the value *t* that the user submits. Indeed, with the *Units*[*Standard*] package, you cannot evaluate sin(*omega* * *t*), if *t* is unassigned and *omega* has a unit of frequency, because the argument to the sine function is then assumed to have a unit of frequency, which is illegal. On the other hand, if you load the *Units*[*Simple*] package, it will see the unassigned variable *t* and not assume anything about it. (It does assume that every unassigned variable has a single well-defined dimension within one expression; if you evaluate (*t* + 5 kg) * (*t* + 5 ms), then Maple will complain: the first factor implies that *t* must be a mass and the second that *t* must be a duration.) So compared with the *Units*[*Standard*] solution, you don't need to worry about what arguments you submit to *V__tot* so much: if the argument can be a duration for some assignment of units to your variables, then Maple will accept it. So item 2. above is not so important anymore. In particular, you get the correct answer for *V__tot_rms* by only removing the unit ms from the definition of *V__tot_AC*, no quoting needed anywhere.

Finally, for the upcoming version of Maple (which is still some time away!) we have overhauled plotting with units somewhat; if you use my suggested definition of *V__tot* and you use *Units*[*Simple*] so that you don't need to worry about evaluating *V__tot* on symbolic arguments, you will be able to get the correct plot just by writing *plot*(*V__tot*(*t*), *t* = 0**Unit*(ms) .. 5**Unit*(ms)) or, if you prefer, *plot*(*V__tot*, 0**Unit*(ms) .. 5**Unit*(ms)). We feel this is a more natural way to use units in plots.