quo, rem, quorem -> poly divide

[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.