From: Stavros M. (Σ. Μ. <mac...@al...> - 2016-04-01 01:33:20
|
It is tempting to want to take advantage of Lisp complex numbers in Maxima. The main advantage is presumably to make numeric-only code more efficient when interpreted, and *much* more efficient when compiled. Perhaps it also makes it easier to integrate outside numeric packages more easily into Maxima. (But it is easy enough to convert types in the glue code.) However, there are several big problems with this theory: - Maxima code was not written with Lisp complexes in mind, and so makes many implicit assumptions (e.g., that numberp implies real and that the only imaginary symbol is %i) which become false, and therefore cause bugs. - The Maxima test suite has no tests to find such bugs. - The presumed speedup for compiled code requires that Maxima's translate function understand these, which I don't think anyone is working on. - You might think it makes Maxima simpler to have all numbers be Lisp numbers, but that isn't going to happen by itself. We will need to continue to support bigfloats, and bigfloat complexes (and in the future perhaps other composite numeric types like intervals). Of course, these could be packaged up as CLOS objects, but again, I don't see that anyone has done that work, either. So allowing Lisp complexes as Maxima numbers (a) will require a lot of work, which no one has volunteered to do; (b) will probably introduce lots of obscure new bugs; (c) mostly benefits purely numerical code, which is not Maxima's forte anyway; (d) really has no other clear benefits. So why would anyone want to do it? Just because Common Lisp has a feature doesn't mean we have to use it. -s PS The case for Lisp rationals is a little different, but not hugely so. The performance gains are smaller, since the numerator and denominator can't be stored as machine numbers. I guess the "integrate outside packages" part becomes irrelevant, since most other languages don't support rationals at all. On Thu, Mar 31, 2016 at 2:19 PM, Raymond Toy <toy...@gm...> wrote: > >>>>> "Richard" == Richard Fateman <fa...@be...> writes: > > Richard> It is possible to construct complex numbers in lisp (though > so far we have > Richard> mostly avoided it....) . The simplest way is > > Richard> :lisp (setf $k #c(1 3) > > Richard> now > Richard> k; prints as 3 %i+1 > > I wish maxima didn't do that. Well, as long as maxima doesn't really > operate with Lisp complex numbers. > > Richard> however, k -3*%i -1 > Richard> prints as 0 + 3 %i - 3 %i. > > Richard> There are other anomalies, such as > > Richard> ratcoef(k,%i) returns 0. > Richard> k+1/2 signals an error. > Richard> sin(k) signals an error > > We should probably fix those. For k+1/2, the error comes from trying > to print k+1/2 which has somehow been computed as ((rat simp) #c(3 6) > 2) and printing wants to compare #c(3 6) with 0. > > sin(k) fails trying to apply the reflection formula and ends up > comparing (in lisp) #c(-2 -6) and 0. I have no idea where the #c(-2 > -6) comes from. > > -- > Ray > > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > |