@acer I'm on 2020.1 at the moment.

It seemed on 2020.2 the caracters appeared smaller (as said, not much, but still something I found fatiguing). I'm mainly taking about 1D math input. I could take a screenshot I guess when I move back to 2020.2.

As I mentionned though, it's not a big deal, but would be easily fixed with an arbitrary settable zoom in the settings instead of fixed choices.

So in a nutshell I'm comparing 2020.1 to 2020.2

@acer 

I understand you guy's point but you only look at one way of solving, which is (for example by plotting) comparing the LHS to the RHS in a strict sense. I perfectly understand that if you calculate the LHS "as is" you won't arrive to the RHS simply because arctan() is bound to [-Pi/2, Pi/2], I perfectly agree with that.

But if you do it in the other way i.e. isolating the atan() term you end up with a solution that doesn't matter how much n*Pi terms you have inside the LHS/RHS.

-Pi/2 - atan(25x) - n*Pi = -2*Pi/3

atan(25*x) = Pi*(1/6 - n)

x = tan(Pi(1/6 - n))/25 = (1/sqrt(3))/25

On that matter this is why I prefer the "robustness" of the solve() under Maxima, which doesn't strictly evaluate LHS - RHS == 0

In a sense it's useful that it can be "smart" enough to see there's a solution to x when considering tan() is periodic.

If the solve() function strictly has to respect LHS = RHS, I think it would not hurt to have another function which can violate RHS=LHS, because it's useful when dealing with periodic functions and their opposite. My problem mostly arises from evalutating the phase of steady state s-domain systems for example, in which you can have equations (solved numerically) of the kind -A*y - B - atan(C*y) - atan(D*y) ... = 0 (because those equations can be easily extracted by inspection, but won't be necessarily perfectly formatted, the formatting being an extra step)

It somewhat becomes painful to check the bounds are respected (so that a solution exists) and would be (in this case) more useful to be able to "just get it" like I can with Maxima. I understand the math sense, but it would still be useful to be able to do that in Maple.

@Thomas Dean Do the inverse by hand. No matter how much n*Pi terms you have, you get the correct answer. I view it as a limitation given other CAS programs "get it".

@vv I understand the period of tan is pi and yes you can format the equation, but still the solve() function should be able to resolve it without any "preformatting". If you do the operation in reverse by hand, you will get the correct answer regardless of you having n*Pi terms in the LHS.

Given the function is periodic, don't you think we shouldn't have to perfectly format the equation? For example both Mathematica and Maxima give the correct answer with the equation typed as above.

Besides, fsolve() should at least have gotten it.

Well, glad I'm the one who did a mistake. But shouldn't Maple have thrown an error or assumed the multiplication?

I would logically see those two choices : either assume a multiplication, or don't assume a multiplication and just throw an error?

Or is it because it somewhat recognized omega__n() as a function? If so then shouldn't the contradiction (sometime it's used as a variable and then suddenly as a function) be warned about?

@Scot Gould It's not a bad workaround, altough I think it would still be ideal to have an option to delete it as it pertains to debugging more than anything else.

That said this solution will not always work if for example you have variables you want to be substituted at the time of the function definition (in this case you shall not see the 2D output "simplified" version, for example if you have some variables that have numerical values).

Well I can upload it but the issue is somewhat a one liner so I thought it would be fine.

I understand the unapply works, but its still ugly. Less ugly than Units:-Standard thing, but still I'd prefer be able to declare the function as is. I can't believe there's no way to disable this, it just makes the document non presentable, and besides the information isn't very useful (unless you're actively developing a Maple plugin or something).

Is there a trick with interface() or something to disable this? Otherwise I would dare say it's bad design, and ought to be changed.

x.mw   x.pdf

@acer  Well I used interface(showassumed= 0) and that solved it. I prefer that option anyway as I didn't like the tilde (again thinking about presentation purpose, as in "i don't have to re-typeset all of this in latex", it's preferrable).

That said, I'm not sure how but if it's a bug it could be a good thing the developers are informed, because I must admit I lost like 30 mins just on that. For somebody who doesn't know precisely maple, it can be confusing.

P.S. Speaking of presentation, I can't wait for you phasor module update ;)

@acer Thanks a lot. Well if you pull it off (sadly I don't understand much about maple programming) I would probably abuse the use of this module.

I have some suggestions as well, though I'm not 100% sure whether or not they are simple:

- Small small "issue" but perhaps have the Units show at the end of the angle expression like in textbooks ex. 9V angle 45 could become (9 angle 45) V, as well as have the degree sign show up (9 angle 45°)V (for 2D output not declarations)

- Have a function dedicated to declaring phasors, like polar(), for example phasor(9, 45), instead of having to use convert() all the time

- When converting from 1D input to 2D input, convert the phasor(9,45) call to "9 ∠ 45" notation in 2D input (this way it's easier to have read-to-print documents), a bit like 1D sqrt() becomes pretty printed in 2D input

Well these are small suggestions but I think that, at least for me, they would make it really well integrated into Maple. I'm surprised Maplesoft hasn't done this yet. In engineering this notation is everywhere, even my 2005 Sharp calculator does this.

@acer

Coming from Mathematica there's some things I really like better on Maple, but one thing lacking is the inability to use fluently the {magnitude, angle_in_degrees} form, only stuck to Polar that spams a bunch of radians, which I have to convert everytime and just makes it super tedious to work with (it's the main unit used in EE hence I'm trying to conform to the norm).

Until I came down to your module... which... would seem to be awesome if it worked, at least the way I see it. I wonder if you have a more recent version than the 2017 version. It seems it might have a bug in arithmetic ops so I wondered if you had somewhat fixed it in later versions.

Here's an image:

As you can see it seems the angle becomes 0 while the magnitude becomes complex. As if the whole "number" was shifted into the magnitude part. (On 2019.2)