Here it is in a downloadable worksheet.
 

Download rectangles.mw

@inteli The error messages combined with Tom's worksheet shows me clearly that you're trying to append a column with 7 entries to a Matrix with 6 rows. Obviously that can't be done. Tom's worksheet shows that you have 2 data sets, one with 6 rows, labeled JAN through JUNE, and one with 7 rows, labeled JUNE through DEC. You must be inadvertently trying to combine one with the other.

Note that JUNE occurs twice. Is that a problem? The data for the two JUNEs are different.

Would you like to combine the two data sets into a single data set with 13 months? That can be easily done.

If you continue to have problems, please upload your worksheet that shows the error message. It only needs to be executed up to the first error message.

@nm I agree wholeheartedly; I hate reading superfluous parentheses in standard algebraic expressions.

Maple's conversion of 2-D input to 1-D form also suffers from automatically added superfluous parentheses.

Your Mathematica example doesn't look so great to me! The spacing is awkward, and the 2 is not superscripted.

@Sabrina Kamal It's not some unprintable character. The function's name literally has a question mark. Explicitly, it's

back-quote question-mark left-square-bracket right-square-bracket back-quote

Or, if execute this, you'll see the name in Maple:

convert(cat(StringTools:-Char~([96, 63, 91, 93, 96])[]), name);

@Sabrina Kamal In that case (Maple 2016) you can use

R:= unapply(map(`?[]`, <P1, P2, P3, P4, P1 | Q1, Q2, Q3, Q4, Q1>, [i]), i):
plot([seq(R(i), i= 1..21)], color= plots:-setcolors()[1]);

And before you ask, this neither goes inside nor outside your loop. Instead, it completely replaces your loop.

@one man Your solution works fine when the numerator of the fractional exponent is an even integer, but not if it's an odd integer. Your solution is probably fine for the OP in this case, but a surd solution is more general.

This doesn't seem to me like a problem appropriate for Groebner.

Do you want all solutions? Or would you be satisfied with just one solution? Are all the inequalities linear?

@Carl Love My code above doesn't handle every possible case of obtaining a decimal approximation of frac(x) where x is a symbolic real constant of large magnitude. It relies on the ability of frac to find the integer part. There are some extreme cases where frac returns unevaluated.

My code also doesn't the handle the two-argument derivative-of-frac case. It seems unlikely that that case would come up.

@acer You mentioned "special evaluation rules of evalf." Do you know what those rules are? There does seem to be something special, but my experiments so far haven't been able to nail it down.

@rahinui The exp= 1 trick works because explicit numbers can be used as procedures that return themselves. This doesn't apply to symbolic numbers like Pi.

@vv In that case I'll continue. But this material is still intended primarily for @nm.

In some library procedure, inplace can be specified as an option by using an index on the procedure's name. This is coded as

foo:= proc(REC::record)
local 
   inplace:= procname::'indexed' and ':-inplace' in {op(procname)}, 
   rec:= `if`(inplace, REC, copy(REC))
;
   rec:-b:= 5;
   `if`(inplace, NULL, eval(rec))
end proc:

And it's invoked as

foo(R)
or
foo[inplace](R)

@vv Oops, that Reply was not meant to be directed specifically at you. I forgot to take off the @vv.

@vv In the related thread, I just posted some `evalf/...` code to work around the frac problem.

@das1404 lprint shows you output in its most-basic one-dimensional plaintext format. It is useful for re-examining output that you can't otherwise understand. That is the context that I previously recommended it for. Setting interface(prettyprint= 0) is pretty much equivalent to putting all output into lprint form.

The command print(expr) means "evaluate expr and display it in whatever format it would've been displayed in had it been output at the top level." So, if expr is a plot, then it's displayed as a plot. I guess that that wasn't your intuition.

@Kitonum You said that "everything works with assuming." But the very thing that the OP wants, simplify(A*B), still doesn't work with assuming.