Product Suggestions

Post your suggestions on new features and products.

Transfer functions are normally not used with units. Involving units when deriving transfer functions can help identify unit inconsistencies and reduce the likelihood of unit conversion errors.

Maple is already a great help in not having to do this manually. However, the final step of simplification still requires manual intervention, as shown in this example.

Given transfer function

H(s) = 60.*Unit('m'*'kg'/('s'^2*'A'))/(.70805*s^2*Unit('kg'^2*'m'^2/('s'^3*'A'^2))+144.*s*Unit('kg'^2*'m'^2/('s'^4*'A'^2))+0.3675e-4*s^3*Unit('kg'^2*'m'^2/('s'^2*'A'^2)))

H(s) = 60.*Units:-Unit(m*kg/(s^2*A))/(.70805*s^2*Units:-Unit(kg^2*m^2/(s^3*A^2))+144.*s*Units:-Unit(kg^2*m^2/(s^4*A^2))+0.3675e-4*s^3*Units:-Unit(kg^2*m^2/(s^2*A^2)))

(1)

Desired output (derived by hand) where the transfer function is separated in a dimensionless expression and a gain that can be attributed to units with a physical meaning in the context of an application (here displacement per voltage).

H(s) = 60.*Unit('m'/'V')/(.70805*s^2*Unit('s'^2)+144.*s*Unit('s')+0.3675e-4*s^3*Unit('s'^3))

H(s) = 60.*Units:-Unit(m/V)/(.70805*s^2*Units:-Unit(s^2)+144.*s*Units:-Unit(s)+0.3675e-4*s^3*Units:-Unit(s^3))

(2)

is(simplify((H(s) = 60.*Units[Unit](m*kg/(s^2*A))/(.70805*s^2*Units[Unit](kg^2*m^2/(s^3*A^2))+144.*s*Units[Unit](kg^2*m^2/(s^4*A^2))+0.3675e-4*s^3*Units[Unit](kg^2*m^2/(s^2*A^2))))-(H(s) = 60.*Units[Unit](m/V)/(.70805*s^2*Units[Unit](s^2)+144.*s*Units[Unit](s)+0.3675e-4*s^3*Units[Unit](s^3)))))

true

(3)

Units to factor out in the denominator are Unit('kg'^2*'m'^2/('s'^5*'A'^2)). Quick check:

Unit('m'*'kg'/('s'^2*'A'))/Unit('kg'^2*'m'^2/('s'^5*'A'^2)) = Unit('m'/'V')

Units:-Unit(m*kg/(s^2*A))/Units:-Unit(kg^2*m^2/(s^5*A^2)) = Units:-Unit(m/V)

(4)

simplify(Units[Unit](m*kg/(s^2*A))/Units[Unit](kg^2*m^2/(s^5*A^2)) = Units[Unit](m/V))

Units:-Unit(s^3*A/(m*kg)) = Units:-Unit(s^3*A/(m*kg))

(5)

"Simplification" attempts with the denominator

denom(rhs(H(s) = 60.*Units[Unit](m*kg/(s^2*A))/(.70805*s^2*Units[Unit](kg^2*m^2/(s^3*A^2))+144.*s*Units[Unit](kg^2*m^2/(s^4*A^2))+0.3675e-4*s^3*Units[Unit](kg^2*m^2/(s^2*A^2)))))

s*(.70805*s*Units:-Unit(kg^2*m^2/(s^3*A^2))+144.*Units:-Unit(kg^2*m^2/(s^4*A^2))+0.3675e-4*s^2*Units:-Unit(kg^2*m^2/(s^2*A^2)))

(6)

collect(s*(.70805*s*Units[Unit](kg^2*m^2/(s^3*A^2))+144.*Units[Unit](kg^2*m^2/(s^4*A^2))+0.3675e-4*s^2*Units[Unit](kg^2*m^2/(s^2*A^2))), Unit('kg'^2*'m'^2/('s'^5*'A'^2)))

s*(.70805*s*Units:-Unit(kg^2*m^2/(s^3*A^2))+144.*Units:-Unit(kg^2*m^2/(s^4*A^2))+0.3675e-4*s^2*Units:-Unit(kg^2*m^2/(s^2*A^2)))

(7)

is not effective because all units are wrapped in Unit commands. Example:

Unit('kg'^2*'m'^2/('s'^2*'A'^2))

Units:-Unit(kg^2*m^2/(s^2*A^2))

(8)

Expand does not expand the argument of Unit commands.

expand(Units[Unit](kg^2*m^2/(s^2*A^2))); lprint(%)

Units:-Unit(kg^2*m^2/(s^2*A^2))

 

Units:-Unit(kg^2*m^2/s^2/A^2)

 

NULL

C1: Expanding Unit command

An expand facility could be a solution that expands a Unit command with combined units to a product of separate Unit commands.

When all units are expanded in a separate Unit command, collect or factor can be used to collect units:

.70805*s*Unit('kg')^2*Unit('m')^2/(Unit('A')^2*Unit('s')^3)+144.*Unit('kg')^2*Unit('m')^2/(Unit('A')^2*Unit('s')^4)+0.3675e-4*s^2*Unit('kg')^2*Unit('m')^2/(Unit('A')^2*Unit('s')^2)

.70805*s*Units:-Unit(kg)^2*Units:-Unit(m)^2/(Units:-Unit(A)^2*Units:-Unit(s)^3)+144.*Units:-Unit(kg)^2*Units:-Unit(m)^2/(Units:-Unit(A)^2*Units:-Unit(s)^4)+0.3675e-4*s^2*Units:-Unit(kg)^2*Units:-Unit(m)^2/(Units:-Unit(A)^2*Units:-Unit(s)^2)

(9)

collect(.70805*s*Units[Unit](kg)^2*Units[Unit](m)^2/(Units[Unit](A)^2*Units[Unit](s)^3)+144.*Units[Unit](kg)^2*Units[Unit](m)^2/(Units[Unit](A)^2*Units[Unit](s)^4)+0.3675e-4*s^2*Units[Unit](kg)^2*Units[Unit](m)^2/(Units[Unit](A)^2*Units[Unit](s)^2), [Unit('A'), Unit('kg'), Unit('m'), Unit('s')])

(.70805*s/Units:-Unit(s)^3+144./Units:-Unit(s)^4+0.3675e-4*s^2/Units:-Unit(s)^2)*Units:-Unit(m)^2*Units:-Unit(kg)^2/Units:-Unit(A)^2

(10)

factor(.70805*s*Units[Unit](kg)^2*Units[Unit](m)^2/(Units[Unit](A)^2*Units[Unit](s)^3)+144.*Units[Unit](kg)^2*Units[Unit](m)^2/(Units[Unit](A)^2*Units[Unit](s)^4)+0.3675e-4*s^2*Units[Unit](kg)^2*Units[Unit](m)^2/(Units[Unit](A)^2*Units[Unit](s)^2))

0.3675e-4*Units:-Unit(kg)^2*Units:-Unit(m)^2*(19266.66666*s*Units:-Unit(s)+3918367.346+.9999999999*s^2*Units:-Unit(s)^2)/(Units:-Unit(A)^2*Units:-Unit(s)^4)

(11)

C2: Using the Natural Units Environment

In this environment, no Unit commands are required and the collection of units should work with Maple commands.
However, for the expressions discussed here, this would lead to a naming conflict with the complex variable s of the transfer function and the unit symbol s for seconds.

NULL

C3: A type declaration or unit assumptions on names

A type declaration as an option of commands like in

Units[TestDimensions](s*(.70805*s*Units[Unit](kg^2*m^2/(s^3*A^2))+144.*Units[Unit](kg^2*m^2/(s^4*A^2))+0.3675e-4*s^2*Units[Unit](kg^2*m^2/(s^2*A^2))), {s::(Unit(1/s))})

true

(12)

could help Maple in simplification tasks (in its general meaning of making expressions shorter or smaller).
Alternatively, assumptions could provide information of which "unit type" a name is

`assuming`([simplify(H(s) = 60.*Units[Unit](m*kg/(s^2*A))/(.70805*s^2*Units[Unit](kg^2*m^2/(s^3*A^2))+144.*s*Units[Unit](kg^2*m^2/(s^4*A^2))+0.3675e-4*s^3*Units[Unit](kg^2*m^2/(s^2*A^2))))], [s::(Unit(1/s))]); `assuming`([combine(H(s) = 60.*Units[Unit](m*kg/(s^2*A))/(.70805*s^2*Units[Unit](kg^2*m^2/(s^3*A^2))+144.*s*Units[Unit](kg^2*m^2/(s^4*A^2))+0.3675e-4*s^3*Units[Unit](kg^2*m^2/(s^2*A^2))), 'units')], [s::(Unit(1/s))])

Error, (in assuming) when calling 'property/ConvertProperty'. Received: 'Units:-Unit(1/s) is an invalid property'

 

On various occasions (beyond transfer functions) I have looked for such a functionality.

 

C4: DynamicSystems Package with units

C4.1: The complex variable s could be attributed to the unit 1/s (i.e. Hertz) either by default or as an option. This could enable using units within the dynamic system package which is not possible in Maple 2022. An example what the package provides currently can be found here: help(applications, amplifiergain)
The phase plot shows that the package is already implicitly assuming that the unit of s is Hertz. A logical extension would be to have magnitude plots with units (e.g. m/V, as in this example).

 

C4.2: A dedicated "gain" command that takes units into account and that could potentially simplify the transfer function to an expression like (2) in SI units. In such a way the transfer function is separated into a dimensionless (but frequency depended) term and a gain term with units.
This would make the transfer of transfer functions to MapleSim easy and avoid unit conversion errors.

 

Download Collecting_and_expanding_units.mw

In an old post, vv reported a bug in simpl/max, which has been "fixed" in Maple 2018. However, it seem that such repairs are not complete enough.
For example, suppose it is required to find the (squared) distance between the origin and a point on x3 - x + y2 = ⅓ which is closest to the origin. In other words, one needs to minimize x²+y² among the points on this curve, i.e., 

extrema(x^2 + y^2, {x^3 + y^2 - x = 1/3}, {x, y}, 's'); # in exact form

Unfortunately, an identical error message appears again: 

restart;

extrema(x^2+y^2, {x^3+y^2-x = -2/(3*sqrt(3))}, {x, y})

{4/3}

(1)

extrema(x^2+y^2, {x^3+y^2-x = 1/3}, {x, y})

Error, (in simpl/max) complex argument to max/min: 1/36*((36+12*I*3^(1/2))^(2/3)+12)^2/(36+12*I*3^(1/2))^(2/3)

 

`~`[`^`](extrema(sqrt(x^2+y^2), {x^3+y^2-x = 1/3}, {x, y}), 2)

{4/3, 4/27}

(2)

extrema(x^2+1/3-x^3+x, {x^3+y^2-x = 1/3}, {x, y})

{4/3, 4/27}

(3)

MTM[limit](extrema(x^2+y^2, {x^3+y^2-x = a}, {x, y}), 1/3)

{4/3, 4/27}

(4)

Download tryHarder.mws

How about changing the values of parameter ?

for a from -3 by 3/27 to 3 do
    try
        extrema(x^2 + y^2, {x^3 + y^2 - x = a}, {x, y}); 
    catch:
        print(a); 
    end;
od;
                               -1
                               --
                               3 

                               -2
                               --
                               9 

                               -1
                               --
                               9 

                               1
                               -
                               9

                               2
                               -
                               9

                               1
                               -
                               3

By the way, like extrema, Student[MultivariateCalculus]:-LagrangeMultipliers also executes the Lagrange Multiplier method, but strangely, 

Student[MultivariateCalculus][LagrangeMultipliers](y^2 + x^2, [x^3 + y^2 - x - 1/3], [x, y], output = plot):

does not cause any errors.

Any chance to have "Evaluate->Remove Output From Worksheet" become active and usable when one is still running something in the worksheet?  May be in 2023 version?

This is something that has been missing in Maple for ages.

Maple definitely slows down when the worksheet becomes full of output (from print messages) when a command has been running for long time. Now there is no way to remove the output in the worksheet until the command completes which can take hours. May be this slow down because the scrolling/writing to the worksheet slows down, and this affects how long it takes to complete as the engine is waiting for the frontend to finish writing to the worksheet?. I do not know. I just know Maple slows down when this happens.

I do not understand why Maple can't implement this. Is there a tehnical reson which will make removing current output in the worksheet not possible while a command is running?

As we head back to school, I want to take a moment to thank all the math teachers out there who take on the demanding yet overlooked task of educating our children, teenagers, and young people. 

I'm where I am today because my calculus teacher, Prof. Srinivasan, was unwavering in her belief that my classmates and I could master any math topic, including calculus. Her conviction in me gave me the confidence to believe I could 'do' math. While Prof. Srinivasan made teaching look easy, I'm acutely aware that teaching math is no easy feat. Speaking with math educators regularly, I can appreciate how challenging teaching math is today compared to a decade ago. Not only do they have to teach the subject, but they must be able to teach it in-person and online, to a group of students that may not be up to speed on the prerequisite material, and in an era where disruptive technologies vie for their student's attention. No wonder math educators are so anxious about returning to the classroom this fall!

And while I wish I could abracadabra your worries away, what I can do is offer you the opportunity to use Maple Learn, a tool built to support the utopian vision of a world where all students love math. A world where math is for everyone, not just the gifted, and the purpose of math class is to explore and marvel at the wonders of the universe, not just get to the correct answer.

Slightly more concretely, Maple Learn is a flexible interactive environment for exploring concepts, solving problems, and creating rich online math content. I've seen educators use Maple Learn to help their students: 

I’ve talked to lots of instructors, in math, and in courses like economics and physics that use math, who have lots of ideas of how to engage their students and deepen their understanding through interactive online activities. What they don’t have are the tools, programming experience, deployment platform, or time to implement their vision. Fortunately, Maple Learn makes it incredibly easy to develop and share your own content, and all you need are your ideas and a web browser. But you don’t need to start from scratch. You can choose from an extensive, constantly growing repository of ready-made, easily customizable content covering a wide range of topics. I think you’ll be pleasantly surprised by how easy it is, but since we are well aware that instructors are extremely busy people, we also have content development services that can help you transform your static content into interactive lessons.

If you haven't looked at Maple Learn, or it's been a while since you last saw it, you can visit Reinventing Math Education with Maple Learn for more information, including an upcoming webinar you might be interested in attending and a special offer on Maple Learn for Maple campuses. And if you ever want to discuss ways Maple Learn might help you, or have ideas on how to make it better, please reach out. I'm always up for good conversation. 

And for all the dedicated teachers who are taking a deep breath and heading back into the classroom this fall, thank you.

 

Combing a Prismatic Joint component with an Elasto Gap component does not always provide correct results. Incorrectly combined (red mass below), a force is generated although the distance between the flanges is greater than the relaxed spring length. A force is exerted (instead of no force is exerted as stated here) on the mass which leads to a smaler deflection (expected are 9.81 m).

This happened to me although I connected flange_a to flange_a and flange_b to flange_b in configruation A bellow. Configuration B works with inverted flanges and configuration C works with inverted unit vector of the prismatic joint. By reversing the direction of gravity, configuration A becomes a valid configuration and configurations B and C become invalid configurations.

It seems that in invalid configruations the value of the  flange distance s_rel can have a large magnitude but is negative in sign which generates significant forces although there is no contact of flanges.

So far for the observations.

 

Would a change of the contact condition

prevent invalid configurations or do we have to live with it for principal reasons that I am over looking?

If so, I don't see a foolproof method to avoid invalid configurations. Instead, I can only suggest measuring the flange distance of the Elasto Gap component as in the attached. If negative values of large amplitude occur, the configuration is invalid.

Assuming that a beginner would connect intuetively flange_a to flange_a and flange_b to flange_b, there is a chance of 50% that the configuration is invalid (A instead of C). This is too much to be acceptable, especially since verifying results in complex assemblies is often not possible.

It is worth noting that the contact condition comes from the underlying Modelica component and not from MapleSoft.

Prismatic_Joint_with_Elasto_Gap.msim

According to Wikipedia

"In computing, a programming language reference or language reference manual is
part of the documentation associated with most mainstream programming languages. It is
written for users and developers, and describes the basic elements of the language and how
to use them in a program. For a command-based language, for example, this will include details
of every available command and of the syntax for using it.

The reference manual is usually separate and distinct from a more detailed
 programming language specification meant for implementors of the language rather than those who simply use it to accomplish some processing task."

 

And no, Maple's Programming guide is not a Language reference manual. This is a guide to how to program in Maple. But it is not reference manual for the language itself. i.e. description of the Language itself.

Examples of Language reference manuals are

C

Original C++ 

Python

Ada

Fortran 77

 

and so on.

Why is there no LRM for Maple? Should there be one? I find Maple semantics sometime confusing, and many times I find how things work by trial and error. Having a reference to look at will be good. 

I know for a language as large as Maple, this is not easy to do. But it will good for Maplesoft to invest into making one.

MapleSim is a mature product. The rich component library leaves little room for improvement for wide range of applications. It is understandable that latest product releases focused on specialized toolboxes and performance improvements.

Here is what I think could be beneficial for many users, which is not related to performance, but can help improve the user experience:

  1. Crossing connection lines: A view option to render a crossing connection line with an arc at the crossing point of two connection lines of the same type. Right-click on a connection line might be enough.
     

    -> To avoid misinterpretations of routing in crowded model diagrams
     
  2. Parameters: An option to populate or reset changes in the parameter pane to the parameter default settings view and vice versa

    -> When testing or optimizing a model, sometimes changed parameters should become default values or be reset. Doing this manually is error prone and takes time.
     
  3. Component flip: Selecting more than one component including connection lines and applying a flip to all of them

    -> When building a model, it can happen that a nicely laid out arrangement of components needs to be mirrored or rotated in its entirety. Doing this component by component and connection by connection is a lot of work that can be saved by this option.
     
  4. Initial conditions: An option in the view menu to highlight components where ICs have been changed from ignore to treat as guess or to strictly enforce
     

    -> ICs are set for many purposes. In addition to defining ICs needed for simulations, this can include extracting equations, testing different model states, or temporarily "immobilizing" a model during assembly, to name a few. Undoing a tentative change can easily be forgotten. Combining existing models that work on their own into a new more complex model often results in an overly constrained model that either cannot be assembled or does not simulate.
    In debugging a model, ICs of all components must be individually inspected. This takes time. A quick overview that shows components where ICs are not set to ignore would be very helpful in debugging models.
     
  5. Undo Create subsystem: A reverse operation that inserts the contents of a subsystem into a parent subsystem.

    -> With the evolution of a model it is sometimes useful to exclude or include existing components from or to a subsystem. For this purpose, an undo create subsystem operation should preserve existing connections. A time saver.
     
  6. Subsystem ports: An option to align a subsystem port to the drawing grid to remove “micro” steps in connection lines
     

    -> For perfectionists who do not have the time to learn (and remember) how to fine-tune at the component level

    Update: MapleSim 2022.2 has subtantially improved on this. This item could be removed from the list.
     
  7. A history or log function of user actions changing a model, its parametrization or internal state.

    -> Often a model does not simulate at all or as desired after modifications. Restoring to a configuration that worked by undo only goes back to the last simulation performed. In such a situation, only reloading the latest file version and redoing modifications may restore the desired model, parametrization, or state. This takes time and migth be unsuccessful. A record of user actions would be a great help.
    History or log information in file format could also help MapleSim support to reproduce an error.

For me personally, reducing errors (4. > 7. > 2.) would improve the use experience much more than layouting aids (3. > 1., 5., 6.).

Hi, just some ideas for improvement!

- since MapleFlow uses Maple as its engine, more integration of MapleFlow and Maple would be nice. Some commands that work very well in Maple not always work the same in MapleFlow. For example, BodePlot plots magnitude and phase in Maple but plots only magnitude in MapleFlow

- a better Help documentation would also help. ?command/function works in Maple but not in MapleFlow. It's a bit anoying to have to open Maple just to get help documentation

- a lot of palettes are not enabled in MapleFlow. Again, it is a little anoying to have to open Maple to get some of the palettes copied and pasted into MapleFlow

Auto paste last entry

So maple uses % as the last expression entry.  My suggestion is to use Crtl+Space on the % command to re-display the last expression.  Yes one could easily use the mouse to select the last entry then Crtl+c and Crtl+v. 

Or maybe the command Crtl+Shift+L to auto paste last entry. 

**edit** actually I would prefer the Crtl+Shift+L option to auto paste the last entry.

** Appears to be a suggestion I made earlier https://www.mapleprimes.com/questions/148867-Is-There-A-Way-To-Recallrepeat-Previous

December and Maple 2021.2 have both arrived, which means that we can look forward to year 2022 and Maple 2022.

        What should we like to find new in Maple 2022?  Here follow a few suggestions, to which readers of Maple Primes can add.

        In my opinion the weakest feature of Maple 2021 is the solution of integral equations.  Even when this package was first introduced into Maple, a couple of decades ago, it was weak, applicable to only linear such equations.  A quarter century earlier, David Stoutemyer (a true genius and entrepreneur, originator of Mu-Math, Mu-Lisp, Derive and computer-algebra capabilities incorporated in calculators of Texas Instruments) had published code for non-linear integral equations, based on Reduce.  There is a Handbook of Integral Equations by Polyanin and Manzhirov that lists about 2000 solutions of integral equations.  Let Maple 2022 be the basis of a boast by Maplesoft for Maple to be able to solve 96 per cent of those equations, in the same way that Edgardo Cheb-Terrab can (rightfully) boast that Maple can solve 96 per cent of differential equations in a standard compilation.  Any differential equation can, apparently, be converted to an integral equation, whereas the converse is not true.  For this reason alone, the development of solution of integral equations should become a priority to assist users of Maple.

        Another area worthy of expansion and enhancement is the solution of differential equations in terms of Heun functions; that capability is already present, but working with those functions in their present form is difficult and slow.  The inclusion of related functions, such as Lame functions, into Maple is long overdue.  Although efforts have been devoted to the development of the physics package in recent years, culminating in a tremendous achievement of capability, only a few physicists in the world can appreciate that luxury, whereas the solution of differential, and integral, equations permeates all science and engineering. 

          What items are on your list of wishes for Maple 2022?

A simple suggestion...

I would appreciate being able to open multiple help pages simultaneously instead of just one.
This seems to me particularly interesting when you have to browse back and forth between several related items.

Guys, this is still the most painful thing i Maple for me, and I hope this gets a high priority for future development.

It is still not possible to compare variables, when one of them could become zero.

with(Units[Standard])

[`*`, `+`, `-`, `/`, `<`, `<=`, `<>`, `=`, Im, Re, `^`, abs, add, arccos, arccosh, arccot, arccoth, arccsc, arccsch, arcsec, arcsech, arcsin, arcsinh, arctan, arctanh, argument, ceil, collect, combine, conjugate, cos, cosh, cot, coth, csc, csch, csgn, diff, eval, evalc, evalr, exp, expand, factor, floor, frac, int, ln, log, log10, log2, max, min, mul, normal, polar, root, round, sec, sech, seq, shake, signum, simplify, sin, sinh, sqrt, surd, tan, tanh, trunc, type, verify]

(1)

a := 15*Unit('kN')

15*Units:-Unit(kN)

(2)

b := 0*Unit('kN')

0

(3)

NULL``

if a < b then "True" else "False" end if

Error, cannot determine if this expression is true or false: 15*Units:-Unit(kN) < 0

 

NULL

Download CompareUnits.mw

Has this ever happened to you? You’re using Maple Learn, and having a grand old time, but suddenly! The horror! You notice a bug! Of course, it’s a shocking experience to realize that our products are not, in fact, flawless, but unfortunately it’s true. There are bugs. But, what’s this? There’s a glimmer of hope on the horizon… the Flag a Problem button! By using the Flag a Problem button, you can let us know about the problem you found, and with the power of our mighty development team, we’ll fix it! Yes, with our forces combined… we can defeat all of these bugs!

A picture of the Flag a Problem button with glowing rays surrounding it.

In all seriousness, we really do appreciate your feedback. Whether you’ve spotted a bug or are looking for a new feature, let us know! We’re constantly updating and improving Maple Learn, and user feedback is a hugely important part of this process. For example, we had a user suggest that Maple Learn treat Δt as a single entity, as in physics that notation is used to mean a change in time rather than Δ times t. And we’re happy to announce that this is now a feature! Here’s just a taste of some of the other things we’ve changed based on user feedback:

  • Can now use the Context Panel to evaluate operations with matrices
  • Maximum number of intersection points shown has increased to 20
  • Intersection points now shown for parametric equations and circles
  • Using the Context Panel no longer scrolls the page
  • Quick Actions menu no longer parameterizes the f of f(x)
  • Fixed display bug for inverse trig functions

Evidently, not every piece of feedback we get is a feature request. Sometimes there’s bugs! And we want to hear about those too. In all honesty, I think it’s pretty neat to see the bugs I’ve reported being fixed. It wasn’t too long ago that I noticed a small error with tables—when the header of the table had a subscript, pressing the down arrow jumped to the next group instead of the next row. I reported it, and now it’s fixed! I can’t help but feeling a little smug, like I’m the one who fixed it. Of course, the credit for the actual code goes to our developers. But it is also true that they wouldn’t have fixed it if no one had pointed it out. Truly, teamwork makes the dream work. And if you want to feel smug about the bug you pointed out being fixed, or the feature you asked for being added, then head on over to that Flag a Problem button. Let us know what you want to see and we’ll listen. What’s more, we’ll be making more posts every now and then to let you know about what’s new with Maple Learn and what we’ve changed based on your feedback. That way you have something to print out and frame on your wall as proof of the contribution you’ve made to Maple Learn! (Or I suppose you could just read it. But where’s the fun in that?)

In the context of analyzing physical systems I often have to plot results in the form of y=f(x,a,b,c,…). Here the plot variables x and y are physical quantities and the system parameters a,b,c… can have units as well.

After substitution of parameters the expression f(x,a,b,c,…) can be plotted using plot(f(x,a,b,c,…),x_range). Unit choice and labeling of the abscissa work already well when x_range is given in the format x=x0..x1 (where x0 and x1 have a value and a unit). This is already a huge improvement since labeling and unit conversion errors on the abscissa are almost impossible.

Also, the units on the ordinate are correctly displayed. However, if the depended variable y is desired to be displayed on the ordinate it must be added by hand using the label option. In doing so the display units and labels of both axes must be re-entered by hand. This re-entering step is a source of labeling and conversion errors.

To improve ordinate labeling and to reduce conversion errors I would love to see two improvements:

  • A plot option that would allow unit conversion of plot axes. I.e. telling Maple in which units a physical quantity has to be displayed and forcing a rescaling of the values of the physical quantities.
  • With less priority and additional to expressions, the plot command should also accept equations in the form of y=f(x) as input. This would lead to a very compact syntax that produces content rich and, more importantly, correct plots of physical quantities. Wrong labeling and conversion errors would be very unlikely.

Overall, I am very pleased by Maples unit functionality. I have been reluctant to switch from my old work style of using names as unit placeholder and self-made conversion sets. But now I feel that the likelihood of producing unit conversion errors with my old work style has become higher than using Maples units.

I can only encourage interested users to give units a try. Its good!  For me it has turned out to be time worth invested.

I also hope that Maplesoft continues their efforts of providing more unit functionalities. It’s a big task but calculations with physical quantities are also a big differentiator.  

... and two suggestions to the development team

POINT 1
In ?DiscreteValueMap (package Statistics) it's given an example concerning rhe Geometric distribution along with this comment:
"The Geometric distribution is discrete but it necessarily assumes integer values, so (bold font is mine) it also does not have a DiscreteValueMap"

This sentence seems to indicate that "because a distribution is discrete over the set of integers, it cannot have a DiscreteValueMap", some sort of logical implication...

But my feeling is that the Geometric distribution (or any other discrete distribution) does not have a DiscreteValueMap because this attribute has just not been specified when defining the distribution.

restart:
with(Statistics):

GeomRV := RandomVariable(Geometric(1/2)):
f := unapply(ProbabilityFunction(GeomRV, n), n):

AnotherGeomRV := Distribution(
      'ProbabilityFunction'=f,
      'Support'=0..infinity,
      'DiscreteValueMap'=(n->n),
      'Type'=discrete
):
DiscreteValueMap(AnotherGeomRV , n);

Thus having the set of natural numbers as support doesn't imply that DiscreteValueMap cannot exist.

Suggestion 1: modify the ?DiscreteValueMap help page so that it no longer suggests that some discrete distributions cannot have a .DiscreteValueMap 

______________________________________________________________________________________

POINT 2
I think there exists a true problem with the definition of discrete distributions in Maple: the ProbabilityFunction of a (discrete) random variable) takes non zero values outside their definition set.
For instance

ProbabilityFunction(GeomRV, Pi);  # something non null


To ivercome this problem I defined a new Geometric distribution this way (not entirely satisfying):

restart:
with(Statistics):

GeomRV := RandomVariable(Geometric(1/2)):
f := unapply(ProbabilityFunction(GeomRV, n), n):
g := n -> (1-ceil(n-floor(n)))*f(n)    # (1-ceil(n-floor(n))) = 1 if n in Z, 0 otherwise

AnotherGeomRV := Distribution(
      'ProbabilityFunction'=g,
      'Support'=0..infinity,
      'DiscreteValueMap'=(n->n),  # is wanted
      'Type'=discrete
):
ProbabilityFunction(AnotherGeomRV, 2);
                 1/8
ProbabilityFunction(AnotherGeomRV, Pi);
                  0

PS: None of the statistics based upon the  ProbabilityFunction (Mean, Variance, ... ) is correctly computed with the previous construction. This could be easily overcome by completing this definition, just as its done in Maple, for all the requires statistics, for instance 

AnotherGeomRV := Distribution(
      ....
      'Mean'=1   # or more generally (1-p)/p form Geometric(p)
):


Suggestion 2: modify the way discrete distributions are defined in Maple in order to avoid ProbabilityFunction to return wrong values.

1 2 3 4 5 6 7 Last Page 1 of 22