quo, rem, quorem -> poly divide

[DrD]

Enter a polynomial division to obtain the quotient and remainder:

(x^4-3*x^2-3*x-2) / (x^3-x^2-2*x) => [quotient, remainder];

Why is it that just entering the division expression, is insufficient?

Commands to return quotient, remainder, (or both), exist, but they require separating the numerator poly from the denominator poly:

quo(numerator,denominator)
rem(numerator,denominator)
quorem(numerator,denominator)

Just wondering about this, as maxima and wolfram aren't any different.

-Dale-

[Han]

Is there that much of a difference between typing a slash versus a comma?

Moreover the commands are more useful this way from a programming perspective because fractions are generally represented as numerator and denominator pairs and not as a single atomic object due to constraints on exact representations.

[DrD]

(03-22-2018 02:47 PM)Han Wrote:  Is there that much of a difference between typing a slash versus a comma?

Moreover the commands are more useful this way from a programming perspective because fractions are generally represented as numerator and denominator pairs and not as a single atomic object due to constraints on exact representations.

In programming, one has the luxury, when creating the program, with ample time to make the details fit the paradigm. A comma is only convenient for command syntax, and isn't a universal division symbol. Not to mention that it is more than just a comma at issue, the command name and syntax must also be considered.

Far more often, at the command entry, a student is interactively working with problems and solution steps as part of a lesson, or homework session. Often problems can be copy/pasted from some source to the command entry line. So, after copy and paste, a student must then "know" that a special command is required, and deal with it's entry syntax, and then configure numerator and denominator accordingly. When time is important, this is quite inefficient.

The idea of textbook representation is more fluid than a special comma configured obscure command representation, at times when intermediate processing is quickly desired. I say 'obscure' command, because the same command has various names depending on the software encountered. From my experience, I think that IS a big difference.

However, there may be better reasons for not simply honoring the divide symbol as the operator ... I don't think comma, slash, or programming, is the underlying reason, is it?

[Tim Wessman]

What if you have more then one divide?

[DrD]

(03-22-2018 04:43 PM)Tim Wessman Wrote:  What if you have more then one divide?

Conceptually, processing the arguments by their operators in precedence order. I'm thinking, just as you would any other numeric expression. Symbolically this means using CAS, of course. My example, and a typical one, only involves a single dividend, and a single divisor. Does it have to be limited to that? (Parenthesis could be your friend...)

[Han]

(03-22-2018 04:31 PM)DrD Wrote:  

(03-22-2018 02:47 PM)Han Wrote:  Is there that much of a difference between typing a slash versus a comma?

Moreover the commands are more useful this way from a programming perspective because fractions are generally represented as numerator and denominator pairs and not as a single atomic object due to constraints on exact representations.

In programming, one has the luxury, when creating the program, with ample time to make the details fit the paradigm. A comma is only convenient for command syntax, and isn't a universal division symbol. Not to mention that it is more than just a comma at issue, the command name and syntax must also be considered.

Far more often, at the command entry, a student is interactively working with problems and solution steps as part of a lesson, or homework session. Often problems can be copy/pasted from some source to the command entry line. So, after copy and paste, a student must then "know" that a special command is required, and deal with it's entry syntax, and then configure numerator and denominator accordingly. When time is important, this is quite inefficient.

This is not an issue particular to the HP Prime (or any calculator or CAS); it is a an issue with any complex tool. Even a power drill might be difficult to use to a beginner who wishes to drill a hole and has no idea how to insert proper drill bits. To address your issue directly, a quotient is "merely" a numerator and denominator. However, it is quite a difficult problem for even simple cases. Consider the fraction

\[ \frac{\frac{x^2+1}{x}}{2x} \]

Some see \( \frac{x^2+1}{x} \) as the numerator, and \( 2x \) as the denominator. Some might simplify this a bit a see \( x^2+1 \) divided by \( 2x^2 \). What exactly is meant by the division in each case? If you really think about it from a programmer's perspective (in terms of object types -- rational divided by polynomial vs polynomial divided by polynomial), these are two very different division operations. How would a calculator know which is which? From a pedagogical point of view, the commands you mentioned forces the user to be more clear as to what they want to do (and also reinforces the notions of division in terms of numerator and denominator).

In case you were thinking parentheses would help:

Suppose the \( \frac{x^2+1}{x} \) were surrounded by a set of parentheses. Would the calculator then compute the quotient and remainder as \( [q(x), r(x) ]\) and then proceed to divide \( [q(x),r(x)] \) by \( 2x \) ? If so, how would it know that \( [ q(x), r(x) ] \) is not a vector or list as opposed to a quotient + remainder? What if it returned \( [q(x)/2x, r(x)/2x ] \)? That seems like a reasonable result (even if undesired).

Quote:The idea of textbook representation is more fluid than a special comma configured obscure command representation, at times when intermediate processing is quickly desired. I say 'obscure' command, because the same command has various names depending on the software encountered. From my experience, I think that IS a big difference.

However, there may be better reasons for not simply honoring the divide symbol as the operator ... I don't think comma, slash, or programming, is the underlying reason, is it?

I am of the opinion that it is. Said differently, I find that textbook representation can often be very ambiguous and relies too much on context. By forcing the user to specify what their arguments are (and as a side-effect requiring them to know what operation/command name is relevant), we reduce the possibility of ambiguity -- which is always desirable in mathematics.

[DrD]

I need to clarify: I was specifically referring to a direct command entry. Not a programming task, which is almost a different topic, in that a programmer is looking for commands that facilitate certain operations.

More to your point: At the command entry line, if you enter an ambiguous problem such as your example, a default approach might be to perform divisions on a first in first out. Then it's on you for the garbage collection. However, if YOU know what YOU mean, and can parenthesize accordingly, then the divisions would follow the parenthetical path, innermost outwards.

By way of my example, it was just a step involving "integration by partial fractions," and the specific example I used in that post was seeking the quotient and remainder for further operations.

I used wxMaxima as a math/word processor. Wanting to verify results, I copied the polynomial division from wxMaxima, which uses "quotient()" and "remainder()" to the prime, which uses quo() and rem().

My first approach was to try a direct command entry of the basic poly division. Failing that, and to make things easier, I assigned the numerator and denominator to variables, then used the equivalent prime CAS commands to finally arrive at a result. That seemed like a lot of hubbub to get a simple division of two poly's, which set my mind to wondering ....

To your conclusion:

1. The division operator, with poly's as arguments, would, itself, need to be smart enough to know that since you are asking for a [quotient, remainder], the result would not be just any old "vector or list." Context sensitivity.

2. Your divisor 2*x should also be parenthesized: ( (x^2+1) / (x) ) / (2*x);

IF it worked that way, the divide technology would be transparent to the student, at the command line. P/Q => [quotient, remainder] in some form. It doesn't, and neither did the other products I tried. Maybe this can't be done, I really don't know.

Uhmm ...{RTFM} If a beginner has trouble with that drill / bits dilemma, maybe that hole is just not meant to be?

[Han]

First: Perhaps the partfrac() command may be helpful in what you are trying to achieve.

Quote:1. The division operator, with poly's as arguments, would, itself, need to be smart enough to know that since you are asking for a [quotient, remainder], the result would not be just any old "vector or list." Context sensitivity.

2. Your divisor 2*x should also be parenthesized: ( (x^2+1) / (x) ) / (2*x);

IF it worked that way, the divide technology would be transparent to the student, at the command line. P/Q => [quotient, remainder] in some form. It doesn't, and neither did the other products I tried. Maybe this can't be done, I really don't know.

Let's just say -- for the sake of academic discussion -- that the division operator could in fact discern through parsing parentheses that the numerator should return a [quotient, remainder] pair and not be treated as a vector or list. I.e. it behaves just how you imagined it should. How, then, would one quickly take this [quotient, remainder] pair and divide both components by a single polynomial (or ratio of polynomials) if one desired the output [quotient/(2x), remainder/(2x)] as a list/vector? Would we then have to apply some sort of quorem2list() command first? (If so, we're pretty much back to square one for a different set of users).

My hunch is that / behaves the way it does for ratios of polynomials for the same reason that 13/7 stays exactly as 13/7.

[DrD]

No, partfrac() isn't the point here. Strictly, "/" is the topic. At the command line, poly1 / poly2 (entered in that way), does not compute.

quo(poly1,poly2) returns the quotient. rem(poly1,poly2) returns the remainder. quotrem(poly1,poly2) returns both. The important detail, is the visual ability to see the calculated result, not that it will be used for further processing.

If to get the result of 13/7, at the command line you had to use quo(13/7), rem(13/7), or quorem(13/7), a beginner might be better off spending that time trying to learn how to "insert drill bits in a drill."

13/7 [Enter] => 13/7
13/7 [Shift] [Enter] => 1.8 ...

(x^4-3*x^2-3*x-2)/(x^3-x^2-2*x) [Enter]=> (x^4-3*x^2-3*x-2)/(x^3-x^2-2*x)
[Shift] [Enter] Doesn't return the quotient plus remainder, either.

That's the state of things, and all I was wondering about.
It's kind of similar to the question about how to resolve fractional powers into radical representation. Some things just aren't supported, and that's the way it is.

This is somewhat like I was thinking, only with the "/" directly on the command line as discussed above. The Maxima manual has this command detail:

Function: divide (p_1, p_2, x_1, …, x_n)
computes the quotient and remainder of the polynomial p_1 divided by the polynomial p_2, in a main polynomial variable, x_n. The other variables are as in the ratvars function. The result is a list whose first element is the quotient and whose second element is the remainder.
Examples:
(%i1) divide (x + y, x - y, x);
(%o1) [1, 2 y]
(%i2) divide (x + y, x - y);
(%o2) [- 1, 2 x]

Note that y is the main variable in the second example.

[Han]

(03-23-2018 11:55 AM)DrD Wrote:  No, partfrac() isn't the point here. Strictly, "/" is the topic. At the command line, poly1 / poly2 (entered in that way), does not compute.

quo(poly1,poly2) returns the quotient. rem(poly1,poly2) returns the remainder. quotrem(poly1,poly2) returns both. The important detail, is the visual ability to see the calculated result, not that it will be used for further processing.

If to get the result of 13/7, at the command line you had to use quo(13/7), rem(13/7), or quorem(13/7), a beginner might be better off spending that time trying to learn how to "insert drill bits in a drill."

13/7 [Enter] => 13/7
13/7 [Shift] [Enter] => 1.8 ...

If you are strictly speaking about "/" and overloading the division operator, then [Shift][Enter] needs to be left out of the discussion. [Shift][Enter] is a format conversion -- think of it as an extra command that must be applied, only the process is simplified via a combination of keys rather than having to manually type in something like feval(). (You could just as easily create a user key that does a conversion for ratios of polynomials.)

As for why the operation is not overloaded, I think I already gave a reasonable explanation. Whatever output the "/" operator gives for ratios of polynomials must be consistent; the scenario I provided has two different desired outcomes yet would have the same input (same from a syntax point of view). No algorithm is going to be able to pick which output to produce without some further assistance.

In the same vein, the CAS will never sometimes use 13/7 and sometimes use a 12 significant-digits representation of that fraction -- even if internally both forms are represented exactly somehow. Otherwise it would be impossible for the CAS to know which is which when a user supplies a 12 sig.-dig. value -- is this value to be interpreted as-is, or did the user enter the 12 sig-dig form of an exact value.

[DrD]

Thanks for your contribution, Han!

-Dale-