## #15 change from fraction or scientific mode

open
nobody
None
5
2012-11-20
2009-09-27
Jim Michaels
No

this would be a change from "fraction mode" or "scientific mode" to more of a "fraction mode by default, real if necessary, either on command".

it would be nice if reduce had a function or command to convert fractions to a real number (such as a variable) without destroying the variable or the current mode. And possibly something where you could set the precision too.
I know about the SCIENTIFIC_NOTATION command, but that changes the mode and destroys the output and variable content's precision. the documentation even warns about it.
If it is a fraction, I would like to keep it a fraction. If it is a real, I would like to keep it as a real.
If I wanted to convert a number from a real to a fraction, I would want to use a function for that. I don't want it to be automatic.
for example if I might use
x=55/10
real(x)
or
toReal(x)

just as I might use imag(x) to get the imaginary part of a complex number.
and similarly,
x:=fraction(0.125)

fractions would stay fractions until it was necessary to convert them to a real. reals would stay reals even when fractions are combined with them.

what do you think?

please bear with me, I am a reduce newbie and I am still learning the syntax.
I don't know what kind of effect this would have on the math. you decide. if you are calculating with real numbers and you have a finite precision, eventually you are going to lose precision due to round-off error.
for instance,
1/2=0.5
0.5/2=0.25
0.25/2=0.125
0.125/2=0.0625
etc., as the number of digits grow and the number of bits required grows with each successive divide.
I suppose this is why you chose to convert reals to fractions. it looks a little awkward, but it keeps the precision, doesn't it? or is it any different than reals really?

the idea behind this change is to preserve the number type where possible, converting where needed.

## Discussion

• Jim Michaels
2009-09-27

example:
1/2 remains 1/2 because it is a fraction.
1/2*0.5 becomes 0.25 because it has been multiplied by a real.
0.5 remains 0.5 because it is a real.
0.5*0.5 results in 0.25 because it is a real.

if lhs.datatype=fraction and rhs.datatype=fraction then
return lhs op rhs
endif
if lhs.datatype=real and rhs.datatype=real then
return lhs op rhs
endif
if lhs.datatype=fraction and rhs.datatype=real then
endif
if lhs.datatype=real and rhs.datatype=fraction then
return lhs op toReal(rhs)
endif

• Jim Michaels
2009-09-27

correction to that last example: 1/2=0.5 should be 1.0/2=0.5

• Jim Michaels
2009-09-27

btw, this would mean that there should be a default scientific precision.

• Arthur Norman
2009-09-27

Hmm. At present the deep insides of Reduce tend to expect that any one expression is a rational function where the two polynomials are both over the same domain of coefficients. So I suspect it would be hard to allow it to represent an expression like say (0.33333*x - (1/3)) and keep the fractions and real numbers separate in a way that people might understand. Eg at present (x-(1/3)) is converted internally to (3x-1)/3 [off mcd may affect the display style]. And there are modular numbers and bigfloats as well as regular floats to worry about. The "precision" statement sets the floating point precision to use.

I could imagine a scheme that may make life nicer for many people where writing a floating point number in an input expression caused rounded mode to be set at least during that line of input, but getting the rules just right to avoid nasty traps for unsuspecting users will need much more thinking about odd cases! I think that the easy ones look easy but cases like perhaps (x-1/3)^10 - (x-0.3333)^10 may be harder to get "right".

Any other developers got good ideas/insight?
Arthur