If you did this you'd need to tell maxima to assume various things about the variables (real, in between floatvalue - epsilon and floatvalue + epsilon...). I don't know maxima well enough to determine how feasible this idea is if you made such assumptions, but it's worth investigating. David
On Tue, Jun 12, 2012 at 8:15 PM, Eviatar <eviatarb...@gmail.com> wrote: > Yes, but I'm saying that that shouldn't occur if we want to maintain > consistency, > > I don't know how feasible this is, but due to this and other Maxima > precision issues <http://trac.sagemath.org/sage_trac/ticket/11643>, would > it be possible to replace floating-point numbers with variables before > passing them off to Maxima, and then substituting them back? > > > On Tuesday, 12 June 2012 03:40:32 UTC-7, Volker Braun wrote: >> >> In the maxima interface we are always converting floating-point numbers >> into exact fractions. This is why solve behaves in the way you describe. >> >> >> >> On Tuesday, June 12, 2012 1:47:09 AM UTC+1, Eviatar wrote: >>> >>> solve has inconsistent behaviour when using exact numerical >>> representations of numbers. >>> >>> For example: >>> >>> sage: solve(sin(x) == 0.5, x) >>> [x == 1/6*pi] >>> sage: arcsin(0.5) >>> 0.523598775598299 >>> >>> sage: solve(log(x) == 0.5, x) >>> [x == sqrt(e)] >>> sage: e^0.5 >>> 1.64872127070013 >>> >>> Shouldn't this be consistent? It seems to me that returning >>> approximations makes more sense, because that's what all the functions do. >>> >> -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
