@Kitonum -- I have display precision set, which makes the numbers look funny.  I have tried removing that also.

But the problem exists with the context menu "solve for x", not with the solve() function which you keep using.  Please tell me why I can't solve using the context menu in a document.

@Kitonum -- I've tried that, as I mentioned in my original post.  Using the solve() function as you are works just fine, but not using the "solve for x" context menu in a document.

@acer -- thanks.  I had just figured this out and was writing up an update.

It does seem that units get in the way somehow, though.  My original example showed an error from units even though units were not involved.  I found that "sqrt" is a protected item in units, which may have something to do with it:

So if I define a function not named "sqrt" to do a square root I can do it elementwise like this.  Your example using "sqrt" directly works too, and is simpler.

The normal ~ usage is to put the operator followed by ~ to make it elementwise.  That's why I thought putting a radical followed by a tilde would make it elementwise.  It's kind of ugly to have to use sqrt~() instead of a radical -- reminds me of Excel...

@rlopez -- thanks for the quick response.  I guess I'm talking to the right guy, too!  I tried it again in a fresh worksheet and got this error when I clicked Initialize the first time:

I have units set in my .mapleprofile, so I tried turning that off in the startup code for my test doc and still no go.  I don't get this error message though.  I've re-calculated the whole worksheet also.

I'm attaching my version, if you can glean anything from it.  Do I need to remove units from my .mapleprofile?

I've got version 2017.3 also.

Bezier_not_working.mw

Edit ==========================================================

@rlopez -- I got the task working.  I had to remove with(Units[Standard]) from my .mapleprofile code.  I think this is a bug -- the task should work fine if units are installed.  If you come up with a patch please let me know.

@acer -- if you're a Maple developer I'm sure you've got the programming chops!  Certainly better than mine, but my algorithm might be helpful.  I get what you mean about "tricky" also.  I'm sure there are a bazillion cases where it would need to work right.

Thanks again for your help.

@acer -- thanks for the thoughtful reply.  What you describe looks like it will indeed do the trick for a fixed number of significant digits, and generally 3 is what I use.  As long as there is a way to dynamically alter that in a given document (similar to your lprint example), that should do the trick.  I'll experiment with that and with putting the displayprecision in my .mapleprofile too.

I wrote a Python utility some time ago to convert arbitrary numbers to engineering notation with the u, m, k, M, etc prefixes.  You are welcome to use http://exality.com/convert-floats-to-engineering-notation/ for any ideas.

@Kitonum -- that doesn't seem to do it.  From Help: "The Digits environment variable controls the number of digits that Maple uses when making calculations with software floating-point numbers."  And here is what I see with a test:

Digits := 3;
a := 123.456;
a;
                            123.456
Putting interface(displayprecision = 3) after Digits doesn't help either.