Menu
▾
▴
maxima-discuss
|
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
>
|
|
From: Barton W. <wi...@un...> - 2016-04-01 12:58:32
|
>PS The case for Lisp rationals is a little different, but not hugely so. The performance gains are smaller, CL complex numbers would automatically give us rectangular form for complex number arithmetic. That would be nice. Likely the least disruptive way to achieve this wouldn't be to allow naked CL complex numbers to be Maxima expressions, but to squeeze code into simplus and friends. --Barton |
|
From: Richard F. <fa...@be...> - 2016-04-01 15:22:40
|
This reminds me of a set of bugs I reported in Wolfram's Mathematica. A while ago. Maybe the simplest indication is that (still, in Mathematica 10) Head[3+4 I] returns Complex Head[a+b I] returns Plus this means that a pattern a_+b_ I does NOT match 3+4 I but does match x+y*I. If you want to match 3+4 I you can use a pattern Z_Complex but either of these two fails if you want to 3+x+ 4 I to match. So you need a third. Bringing us back to Maxima ... the Common Lisp objects for complex numbers and for rationals are viewed as "atoms" and so all the Maxima code that looks for lists beginning with mplus and involving $%i to identify complex numbers, and for lists beginning with rat for rationals ... have to be augmented somehow. RJF On 4/1/2016 5:58 AM, Barton Willis wrote: > > >PS The case for Lisp rationals is a little different, but not hugely > so. The performance gains are smaller, > > > CL complex numbers would automatically give us rectangular form for > complex number arithmetic. That would be nice. Likely the least > disruptive way to achieve this wouldn't be to allow naked CL complex > numbers to be Maxima expressions, but to squeeze code into simplus and > friends. > > > --Barton > > > > > ------------------------------------------------------------------------------ > 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 |
|
From: Raymond T. <toy...@gm...> - 2016-04-01 15:11:49
|
>>>>> "Stavros" == Stavros Macrakis <(Σταῦρος Μακράκης)" <mac...@al...>> writes:
Stavros> o You might think it makes Maxima simpler to have all numbers be Lisp
Stavros> numbers, but that isn't going to happen by itself. We will need to continue
Stavros> to support bigfloats, and bigfloat complexes (and in the future perhaps
Stavros> other composite numeric types like intervals). Of course, these could be
Stavros> packaged up as CLOS objects, but again, I don't see that anyone has done
Stavros> that work, either.
Bigfloats and complex bigfloat are already packaged up in CLOS
objects. See the bigfloat package in src/numeric.lisp. But that's
not really exposed in anyway to maxima; it's all for internal
processing.
One slight negative of using Lisp complexes: you can't have purely
imaginary numbers.
For me the only advantage of using Lisp complexes is that presumably I
don't have to constantly call expand or rectform or something to get a
final numeric result that is just x + %i*y. But if this really
mattered to me, I'd just do it in lisp.
--
Ray
|
|
From: Stavros M. (Σ. Μ. <mac...@al...> - 2016-04-01 15:13:57
|
On Fri, Apr 1, 2016 at 11:11 AM, Raymond Toy <toy...@gm...> wrote: > >>>>> "Stavros" == Stavros Macrakis <(Σταῦρος Μακράκης)" < > mac...@al...>> writes: > > Stavros> o You might think it makes Maxima simpler to have all numbers > be Lisp > Stavros> numbers, but that isn't going to happen by itself. We will > need to continue > Stavros> to support bigfloats, and bigfloat complexes (and in the > future perhaps > Stavros> other composite numeric types like intervals). Of course, > these could be > Stavros> packaged up as CLOS objects, but again, I don't see that > anyone has done > Stavros> that work, either. > > Bigfloats and complex bigfloat are already packaged up in CLOS > objects. See the bigfloat package in src/numeric.lisp. But that's > not really exposed in anyway to maxima; it's all for internal > processing. > OK, I should have been clearer: the packaging is the easy part. The hard part is making the CLOS objects work correctly in the rest of Maxima. |
|
From: Robert D. <rob...@gm...> - 2016-04-01 18:52:04
|
On 2016-04-01, Barton Willis <wi...@un...> wrote: > CL complex numbers would automatically give us rectangular form for > complex number arithmetic. That would be nice. Yeah. I've always been annoyed that it's necessary to apply rectform to reduce stuff like (1 + %i)/(1 - %i). Complex literals which automatically simplify are tempting. best Robert Dodier |
|
From: Stavros M. (Σ. Μ. <mac...@al...> - 2016-04-01 19:01:54
|
That's a reasonable goal which should be easy to implement in the current system (probably switch-controlled). I wonder — will some users prefer (e.g.) (1+%i)/2 to 1/2+%i/2? On Fri, Apr 1, 2016 at 2:51 PM, Robert Dodier <rob...@gm...> wrote: > On 2016-04-01, Barton Willis <wi...@un...> wrote: > > > CL complex numbers would automatically give us rectangular form for > > complex number arithmetic. That would be nice. > > Yeah. I've always been annoyed that it's necessary to apply rectform to > reduce stuff like (1 + %i)/(1 - %i). Complex literals which > automatically simplify are tempting. > > best > > Robert Dodier > > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Robert D. <rob...@gm...> - 2016-04-01 19:43:56
|
On Fri, Apr 1, 2016 at 12:01 PM, Stavros Macrakis (Σταῦρος Μακράκης) <mac...@al...> wrote: > That's a reasonable goal which should be easy to implement in the current > system (probably switch-controlled). For the record, I've entered a feature request for this (https://sourceforge.net/p/maxima/feature-requests/134/) so, I hope, it doesn't get lost. best Robert Dodier |
|
From: Robert D. <rob...@gm...> - 2016-04-01 19:21:58
|
On 2016-04-01, Stavros Macrakis <mac...@al...> wrote: > It is tempting to want to take advantage of Lisp complex numbers in Maxima. > However, there are several big problems with this theory: It's not clear to me if you're proposing any action here. Do you want to remove any extant accommodation for Lisp complex numbers and instead trigger an error if any appears? or something else? There is little support for Lisp complex numbers at present -- are you actively trying to discourage others from filling the gaps? Would you be disappointed if someone did make such an effort? Full of questions today, I guess -- Robert Dodier |
|
From: Stavros M. (Σ. Μ. <mac...@al...> - 2016-04-01 20:33:52
|
Reasonable questions.
It's safest to trigger an error whenever Maxima sees a Lisp complex or
rational. But I don't think that adding such code is a particularly
productive use of anyone's time.
It is a bug for any Maxima code to *create *Lisp complexes or rationals,
because much of Maxima assumes they don't exist. Not a bug to handle them
correctly if they appear in the input, but not terribly useful.
If someone wants to make a serious effort to systematically add support for
Lisp complexes or rationals, yes, I will try to dissuade them, because it's
a large project and they're wasting their time. Calling that "filling the
gaps" is a strange description of that project. It would be equally strange
to call converting Maxima to CLOS objects rather than Lisp structures
"filling the gaps" (though it is potentially more useful). But if they
insist, I'd insist that it be under yet-another-flag control to minimize
disruption while it wasn't well tested. And I'd also try to persuade them
that they need to start by writing a lot of tests, not just to check that
(1+%i)/(1-%i) => %i, but that factor(2+4*%i) => 2*(1+2*%i), etc.
Tell me again, what would be the advantage of using Lisp complexes?
-s
PS There is also a bunch of design work to be done:
I assume that the canonical form of %i is #C(0 1).
Is #C(2 0) considered simplified, or is it always canonicalized to 2?; if
canonicalized, it looks like we still need glue code at interfaces with
Lisp code using Lisp complexes.
With inflag:false, do we treat #C(1 2) as though it were 1+2*%i? How about
with inflag:true (inpart(2/3,0) currently => "/", although inpart(a/b,0) =>
"*").
By the way, what do you expect general simplification to do with x/(1-%i)
== (1/2+%i/2)*x == (1+%i)*x/2 == x/2+x*%i/2? Which of these forms is
simplified? If more than one, which simplifies to which?
Do we continue to allow things like (-1)^(1/4) or do we always simplify to
#C(1,1)/sqrt(2), the way we simplify sqrt(12) => 2*sqrt(3)?
On Fri, Apr 1, 2016 at 3:21 PM, Robert Dodier <rob...@gm...>
wrote:
> On 2016-04-01, Stavros Macrakis <mac...@al...> wrote:
>
> > It is tempting to want to take advantage of Lisp complex numbers in
> Maxima.
>
> > However, there are several big problems with this theory:
>
> It's not clear to me if you're proposing any action here. Do you want to
> remove any extant accommodation for Lisp complex numbers and instead
> trigger an error if any appears? or something else? There is little
> support for Lisp complex numbers at present -- are you actively trying
> to discourage others from filling the gaps? Would you be disappointed if
> someone did make such an effort?
>
> Full of questions today, I guess --
>
> Robert Dodier
>
>
>
> ------------------------------------------------------------------------------
> 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
>
|
|
From: Raymond T. <toy...@gm...> - 2016-04-01 21:24:49
|
>>>>> "Stavros" == Stavros Macrakis <(Σταῦρος Μακράκης)" <mac...@al...>> writes:
Stavros> Do we continue to allow things like (-1)^(1/4) or do we
Stavros> always simplify to #C(1,1)/sqrt(2), the way we simplify
Stavros> sqrt(12) => 2*sqrt(3)?
Richard would probably say #c(1,1)/sqrt(2) is wrong because (-1)^(1/4)
has 4 values.
This particular value has always been a problem for me. Most of the
time I do what (1+%i)/sqrt(2), but not always.
--
Ray
|
|
From: Robert D. <rob...@gm...> - 2016-04-01 23:26:21
|
On 2016-04-01, Stavros Macrakis <mac...@al...> wrote: > Tell me again, what would be the advantage of using Lisp complexes? Because it's there. <shrug> Oh, also one has complex numbers which don't require rectform to get the obvious result. You raise lots of interesting questions, for which I mostly don't have any answers. I'm just wondering why we would want to make it impossible to work with Lisp complex numbers; it seems an unmathematical attitude. But unless you or anybody actually arranges for Maxima to expel Lisp complex numbers, I don't have any actual opposition. best Robert Dodier |
|
From: Richard F. <fa...@be...> - 2016-04-01 23:41:54
|
I think that if we had a notation and operations specifically on them, it wouldn't interfere with anything already in Maxima. And someone might find a use. Like add and multiply "natively". ?complex(1,2) doesn't quite do it because in Lisp #c(1 2) is an atom and therefore part(%,1) etc won't work and there are other issues. Maybe ?.complex(1,2) ?? RJF On 4/1/2016 4:26 PM, Robert Dodier wrote: > On 2016-04-01, Stavros Macrakis <mac...@al...> wrote: > >> Tell me again, what would be the advantage of using Lisp complexes? > |
|
From: Stavros M. (Σ. Μ. <mac...@al...> - 2016-04-01 23:44:13
|
On Fri, Apr 1, 2016 at 7:26 PM, Robert Dodier <rob...@gm...> wrote: > On 2016-04-01, Stavros Macrakis <mac...@al...> wrote: > > > Tell me again, what would be the advantage of using Lisp complexes? > > Because it's there. <shrug> > > Oh, also one has complex numbers which > don't require rectform to get the obvious result. > Well, that's easily taken care of in a much simpler way! You raise lots of interesting questions, for which I mostly don't have > any answers. I'm just wondering why we would want to make it impossible > to work with Lisp complex numbers; it seems an unm > > athematical attitude. > I don't think mathematics says anything about how to use the features of a programming language to build a new abstraction. If Maxima were written in C, would you give users access to untyped pointers? (Hmm, scary to think that you might...) > But unless you or anybody actually arranges for Maxima to expel Lisp > complex numbers, I don't have any actual opposition. > > > best > > Robert Dodier > > > > ------------------------------------------------------------------------------ > 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 > |
|
From: Robert D. <rob...@gm...> - 2016-04-02 01:25:04
|
On 2016-04-01, Stavros Macrakis <mac...@al...> wrote: > I don't think mathematics says anything about how to use the features of a > programming language to build a new abstraction. If Maxima were written in > C, would you give users access to untyped pointers? (Hmm, scary to think > that you might...) Ha, don't tempt me. Clearly the answer is yes, if untyped pointers have any algebraic properties of interest ... 8^) best Robert Dodier |
|
From: Stavros M. (Σ. Μ. <mac...@al...> - 2016-04-02 01:45:09
|
If you want to talk mathematics, why not think in terms of isomorphism
rather than identity?
Maxima complexes are *isomorphic* to Lisp complexes. They have the same
algebraic properties. That doesn't mean that Maxima complexes must be
represented as Lisp complexes.
-s
On Fri, Apr 1, 2016 at 9:24 PM, Robert Dodier <rob...@gm...>
wrote:
> On 2016-04-01, Stavros Macrakis <mac...@al...> wrote:
>
> > I don't think mathematics says anything about how to use the features of
> a
> > programming language to build a new abstraction. If Maxima were written
> in
> > C, would you give users access to untyped pointers? (Hmm, scary to think
> > that you might...)
>
> Ha, don't tempt me. Clearly the answer is yes, if untyped pointers have
> any algebraic properties of interest ... 8^)
>
> best
>
> Robert Dodier
>
>
>
> ------------------------------------------------------------------------------
> 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
>
|
|
From: Richard F. <fa...@be...> - 2016-04-02 16:05:29
|
On 4/1/2016 6:45 PM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: > If you want to talk mathematics, why not think in terms of isomorphism > rather than identity? > > Maxima complexes are /isomorphic/ to Lisp complexes. Not quite.. the Re and Im parts of a Maxima complex can be bigfloats or symbols or expressions. e.g. cos(x)+%i*sin(x). A CL complex must have components that are CL numbers. This morning I'm thinking that a CL complex display could be something that indicates it is somehow CL. Earlier, I put together a display for intervals so they print like <1..3>, so a user would not be so tempted to use inpart() and such. If CL complexes are another example, maybe we need something more general, that hints of exotic representation. e.g. <# interval, 1,3> <# complex, 1, 3> <# otherstructure,1,2,3,4> thus we could create a CL complex with ?complex(1,3) and the resulting atom would be displayed as <# complex , 1, 3>. (I suppose, with matchfix, we could even allow typing that, but the result would still be an atom...) > They have the same algebraic properties. That doesn't mean that Maxima > complexes must be represented as Lisp complexes. > This is true. RJF > -s > > On Fri, Apr 1, 2016 at 9:24 PM, Robert Dodier <rob...@gm... > <mailto:rob...@gm...>> wrote: > > On 2016-04-01, Stavros Macrakis <mac...@al... > <mailto:mac...@al...>> wrote: > > > I don't think mathematics says anything about how to use the features of a > > programming language to build a new abstraction. If Maxima were > written in > > C, would you give users access to untyped pointers? (Hmm, scary > to think > > that you might...) > > Ha, don't tempt me. Clearly the answer is yes, if untyped pointers > have > any algebraic properties of interest ... 8^) > > best > > Robert Dodier > > > ------------------------------------------------------------------------------ > 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... > <mailto:Max...@li...> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > > > ------------------------------------------------------------------------------ > 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X