Improper integral

[Joe Horn]

(06-14-2014 10:23 AM)Onkel Otto Wrote:  

(06-14-2014 09:40 AM)alexzkter Wrote:  Is it the way it's meant to be? I mean, if you change a setting on CAS, shouldn't it just affect the CAS mode?

+ 1

I really do not like this kind of inconsistencies.

No no no, it's not inconsistent at all. One of the main benefits of the "Change apparent integers to exact integers" CAS setting is that it lets you use CAS functions, with CAS accuracy, from Home (and in non-CAS programs).

Why? Here's why. In CAS, you can specify whether the input is an integer, or a whole real, by omitting or including a decimal point, respectively. For example, try the following with "sqrt" spelled out (not using the √ key):

CAS: sqrt(8) --> 2*√2
CAS: sqrt(8.) --> 2.82842712475

Nice, right? Ah, but Home does not make this distinction between integers and whole reals. In fact, Home doesn't support the integer object type at all; Home passes all numbers to CAS as reals. So how can the user force CAS functions, when called from home, to treat whole numbers as integers?

Answer: By setting the "Change apparent integers to exact integers" flag. That's what it's for.

Home: sqrt(8) = sqrt(8.) = 2.82842712475 if that flag is clear.
Home: sqrt(8) = sqrt(8.) = 2*√2 if that flag is set.

If that setting did not exist, people would be bellyaching about not being able to use CAS functions in Home the way they want to. So that flag was added... so that people CAN use CAS functions in Home and in programs the way they work in CAS if they want to. This is a Good Thing.

The only objection I can think of is, "But what good is that information to programmers, when that flag is not programmable???" To which I answer: If you want your program to use the integer object type and reals without needing to worry about that flag, then write CAS programs.