@wlferguson19 I don't understand what you mean. The pair [x,y] = [sin(3t),cos(3t)] parametrizes a circle, which doesn't intersect itself (leaving alone the originating point, or points following overlap, from discussion).

@wlferguson19 I don't understand what you mean. The period of the path is Pi. It repeats every Pi unit of the parameter. If you make the parameter go from 0 to 2*Pi then the x- and y-coordinates of the intersection points will just be repeated (as will the curve's path).

Download intersect_2Pi2.mw

@nepomukk The sin command uses the result of sign on the argument, but it doesn't offer anything but the default lexicographic ordering of variables to determine that sign.

It is possible to force the issue, with a forced sort and a custom call to sign.

Download signsin.mw

@minhthien2016 

Download intsimp.mw

@awass This might be a clue.

When editing normally within an Execution Group, pressing the <Enter> key executes the statements and pressing <Shift><Enter> inserts a new line and moves the cursor down.

Your problematic examples are in Execution Groups that appear in the .mw file as two adjacent separate XML Equation substructures, which I don't recall seeing before to represent a single statement.

Normally, when one pastes in code containing newlines (LF, \n, U+000A) then all is ok. For example, in the last attempt in your attached worksheet there is such a newline after the Q:=proc(x) and before the sin(x). 

But I suspect that something else is getting pasted in, after the sin(x), that may be causing interpretation by the GUI as two separate statements. (I don't mean a hidden semi-colon, as that seems to come as a consequence of further conversion to 1D, not the original cause.) And this seems to cause the GUI to send the first and second portion to the kernel separately.

The first portion being like,

Q:=proc(x)
  sin(x)

and the second portion being,

end proc;

There was a post a month (or several) ago, in which a Mac OSX user was having trouble due to an unexpected character in a text file. I am wondering whether your issue might be similar. For example, something to do with a difference between a carriage return and a newline.

I have never seen anyone report this problem before. On the one hand, there is some evidence that were some changes to the 2D parser in Maple 2018, but on the other hand this situation doesn't seem a general problem. As a guess, I suspect that it might be a Mac OSX specific issue, with something (CR, LF, etc) being misinterpreted and causing an unintended statement split.

If my guess is right, then diagnosing the problem might require examining the original plaintext (if you copied from that, with the mouse), or examining the file, or knowing which key strokes were using in writing it.

@Joe Riel Oh, right, sure, I would believe that. I just meant that the whole topic relates to kernel-based parameter processing in general, (including, but not only) what happens in the debugger.

@José Goulart I figured that you were using an older version, and that for some reason you wanted to keep it a secret.

I've now changed the header on the Question, to denote the Produce as Maple 18. (You could do that too, in future.)

@Joe Riel I changed it to an Answer, as I too was preparing to mention _npassed .

@José Goulart Your last shows 2D Input (which just happens to be in red), in an Execution Group. That's not 1D Input. (You would also have to use F5 or the toggle to switch to 1D input mode, if it's not your default.)

The following is 2D Input. Here I'm using the prefix form of the inert `%*` operator, rather than infix form as was previously showed with 1D input.

Download inert_star.mw

@awass I am not sure that Mapleprimes allows a ( .maple file name extension) workbook to be uploaded directly. But .zip files work.

However, I'd be interested in seeing the original .mw , rather than a workbook .maple file which is a container for .mw Worksheets/Documents.

It would also be interesting to see what you get with the Maple 2018.2 update.

It sounds like you are copying plaintext and pasting it in (where the source is a text file?). But, sorry, the exact steps aren't clear to me.

@Kitonum The result from rsolve could be simplified prior to unapplying, and the result from this new operator could also be evala'd (simplified). It seems a bit faster to use add on the binomial expansion, say if m::posint .

If the operator "Tm" is going to be called multiple times with the same arguments then it could also get, say, option remember, system (sure, I realize that's the recursive procedure originally had it for a finesse on that).

It's hard to compete with the performance of the original recursive procedure, though, which is very fast. So this is mostly in fun.

Download Tm.mw

@awass It is not helpful to not upload a worksheet that exhibits the problem, and to not tell us exactly which Maple version (major and minor number) you are using.

@danyheatley Another choice is the command SolveEquations from the (free) DirectSearch add-on package.

But note that can act more like an optimizer than a root-finder. By this I mean that it can return a set of values that minimizes the residuals in the case that an actual root does not exist. Sometimes people want that, though, because the rounding of float coefficients in the equations are why the minimum residuals cannot be attained closer to zero.

@aalho What old version do you have? Note that there is no need for this in any version later than Maple 18 (eg, Maple 18, Maple 2015, Maple 2016, Maple 2017, and Maple 2018).

In those versions, 2D plotting can use the size option.

@Kitonum I don't doubt that you are right, so I vote up.

I was answering the Question body as asked, and over-hastily discounted the title entirely as "parametrics" is an awkward construct that I wouldn't normally expect to see (and he hadn't yet posted his later Question about arrows and parametric curves). Not the first time I've made that flavor of mistake.

[edited] Upon further reflection, I retract my concession above. It would be a perfectly fine question to ask whether the path of a moving object (parametrized by time, say) intersected with the path of another at the same time value. A sensible question could be whether they are ever in the same place at the same time, in which case the original formulation is ok. So far, the OP has not provided any clear indication whether the question is about whether two parametrized curves ever cross, or whether they ever cross at the same parameter value(s).

It could well be that Kitonum's interpretation happens to be correct. But there is, so far, not evidence that it must be so.