You can subscribe to this list here.
2014 
_{Jan}

_{Feb}
(232) 
_{Mar}
(323) 
_{Apr}
(383) 
_{May}
(359) 
_{Jun}
(435) 
_{Jul}
(252) 
_{Aug}
(172) 
_{Sep}
(265) 
_{Oct}
(263) 
_{Nov}
(259) 
_{Dec}


S  M  T  W  T  F  S 

1
(28) 
2
(22) 
3
(17) 
4
(21) 
5
(13) 
6
(14) 
7
(5) 
8
(9) 
9
(14) 
10
(21) 
11
(8) 
12
(4) 
13
(20) 
14
(9) 
15
(5) 
16
(27) 
17
(18) 
18
(16) 
19
(10) 
20
(18) 
21
(14) 
22
(23) 
23
(18) 
24
(12) 
25
(11) 
26
(15) 
27
(7) 
28
(12) 
29
(17) 
30
(7) 





From: Camm Maguire <camm@ma...>  20140630 22:55:26

Greetings! When compiling some functions that were previously interpreted under gcl, I have one small test failure on 32bit intel only: ev (e7, alfa=2, vita=1); (of rtest8.mac) returns [0.052961027786557, 4.8572257327350623E17, 50, 0] insead of [0.052961027786557, 5.551115123125785E17, 50, 0] This is solely due to the loss of one bit of precision in res24 of slatec::dqc25s when the optimized compile is done in 64 bits instead of the 80 that are specially available on the x87 fpu: 0.5391596517903231 (80 bits) vs 0.539159651790323 (64 bits) (%i6) :lisp (integerdecodefloat 0.5391596517903231) 4856318413792211 53 1 (%i6) :lisp (integerdecodefloat 0.539159651790323) 4856318413792210 53 1 (%i6) The muladd in 64bits appears in C as V40= (double)(V40)+(double)((double)(((V29))>lfa.lfa_self[(long)((long)0)+((long)(V31)((long)1))])* (double)(((V26))>lfa.lfa_self[(long)(V27)+((long)(V31)((long)1))])); vs. {double V253= lf(fLrow_major_aref((V29),(long)((long)0)+((long)(V31)((long)1)))); {double V254= lf(fLrow_major_aref((V26),(long)(V27)+((long)(V31)((long)1)))); V40= (double)(V40)+(double)((double)(/* INLINEARGS */V253)*(double)(/* INLINEARGS */V254));}} I don't really think this is a GCL bug, yet I've constructed the debian package build to fail on any test failure. Is there a way I can set the floating point tolerance higher here to let this result through? Take care,  Camm Maguire camm@... ========================================================================== "The earth is but one country, and mankind its citizens."  Baha'u'llah 
From: Gunter Königsmann <gunter@pe...>  20140630 17:47:11

You are right: I was so convinced of having seen the bug again that I didn't see the obvious error maxima had any right to complain about. Thanks a lot, And kind regards, Gunter. On 30. Juni 2014 19:38:23 MESZ, Robert Dodier <robert.dodier@...> wrote: >On 20140630, Gunter Königsmann <gunter@...> wrote: > >> Did take me a much longer time to find an example that triggers the >> bug and that doesn't contain confidental data. Sorry for that. But at >> least the example I found reliably produces lisp errors both on >> windows and my linux installation. >> >> load(fft); >> load(draw); >> pts(x):=points( >> makelist(i,i,1,length(x)), >> x >> ); >> signal:makelist(sin(x/10),x,0,127)$ >> draw2d(pts(signal)); >> draw2d(pts(fft(signal))); > >draw2d seems to fail because fft(signal) contains mostly complex >numbers. But that's to be expected for the Fourier transform. >Perhaps you want to compute sine and cosine coefficients  see the >remark "When the data <x> are real, real coefficients `a' and `b' can >be >computed such that ..." in the description of fft. One can also compute >a cosine coefficient and phase angle  I forget the formula for that. > >Even when results are provably real, there might be imaginary parts >on the order of magnitude of the floating point epsilon  realpart >can squash those. > >Hope this helps, > >Robert Dodier > > > >Open source business process management suite built on Java and Eclipse >Turn processes into business applications with Bonita BPM Community >Edition >Quickly connect people, data, and systems into organized workflows >Winner of BOSSIE, CODIE, OW2 and Gartner awards >http://p.sf.net/sfu/Bonitasoft >_______________________________________________ >Maximadiscuss mailing list >Maximadiscuss@... >https://lists.sourceforge.net/lists/listinfo/maximadiscuss  Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet. 
From: Robert Dodier <robert.dodier@gm...>  20140630 17:38:48

On 20140630, Gunter Königsmann <gunter@...> wrote: > Did take me a much longer time to find an example that triggers the > bug and that doesn't contain confidental data. Sorry for that. But at > least the example I found reliably produces lisp errors both on > windows and my linux installation. > > load(fft); > load(draw); > pts(x):=points( > makelist(i,i,1,length(x)), > x > ); > signal:makelist(sin(x/10),x,0,127)$ > draw2d(pts(signal)); > draw2d(pts(fft(signal))); draw2d seems to fail because fft(signal) contains mostly complex numbers. But that's to be expected for the Fourier transform. Perhaps you want to compute sine and cosine coefficients  see the remark "When the data <x> are real, real coefficients `a' and `b' can be computed such that ..." in the description of fft. One can also compute a cosine coefficient and phase angle  I forget the formula for that. Even when results are provably real, there might be imaginary parts on the order of magnitude of the floating point epsilon  realpart can squash those. Hope this helps, Robert Dodier 
From: Raymond Toy <toy.raymond@gm...>  20140630 16:33:25

>>>>> "Gunter" == Gunter Königsmann <gunter@...> writes: Gunter> Did take me a much longer time to find an example that triggers the Gunter> bug and that doesn't contain confidental data. Sorry for that. But at Gunter> least the example I found reliably produces lisp errors both on Gunter> windows and my linux installation. Gunter> load(fft); Gunter> load(draw); Gunter> pts(x):=points( Gunter> makelist(i,i,1,length(x)), Gunter> x Gunter> ); Gunter> signal:makelist(sin(x/10),x,0,127)$ Gunter> draw2d(pts(signal)); Gunter> draw2d(pts(fft(signal))); Gunter> assigning the value of the fft to a variable works fine, though as does Gunter> tst:pts(fft(signal)); What is the strange behavior? I see that draw2d(pts(fft(signal))) produces an error, but AFAICT, the fft did what it was supposed to do. And the subject mentions inverse_fft, but I see no inverse_fft here. Maybe draw2d doesn't like plotting complex points? This doesn't work for me: draw2d(points([1,2],[1+%i,2+%i]). Ray 
From: Wilhelm Haager <wilhelm.haager@ht...>  20140630 13:12:36

Hi, Unfortunately, the phpbb forum for user contributed code https://sourceforge.net/apps/phpbb/maxima/viewforum.php?f=3 has gone (as Robert Dodier has announced a couple of weeks ago) and thus the access to the control engineering package "COMA". That package is widely used in control engineering lectures in Austrian technical colleges (HTLs). Is there a chance to ge that package incorporated into the Maxima share directory (as proposed several years ago)? Wilhelm Haager 
From: Gunter Königsmann <gunter@pe...>  20140630 11:05:41

BEGIN PGP SIGNED MESSAGE Hash: SHA1 Did take me a much longer time to find an example that triggers the bug and that doesn't contain confidental data. Sorry for that. But at least the example I found reliably produces lisp errors both on windows and my linux installation. load(fft); load(draw); pts(x):=points( makelist(i,i,1,length(x)), x ); signal:makelist(sin(x/10),x,0,127)$ draw2d(pts(signal)); draw2d(pts(fft(signal))); assigning the value of the fft to a variable works fine, though as does tst:pts(fft(signal)); Thanks again and kind regards, Gunter. build_info(version="branch_5_33_base_76_ge99672b",timestamp="20140625 07:56:18", host="x86_64unknownlinuxgnu",lisp_name="SBCL",lisp_version="1.2.0.debian") On 06.06.2014 01:51, Robert Dodier wrote: > On Thu, Jun 5, 2014 at 1:08 PM, Gunter Königsmann > <gunter@...> wrote: > >> Cool! Will do that as soon as possible but I will need a few >> day's time to find an example I am allowed to send to this list. > > My guess is that there are some values which are not literal floats > in the input array. Maybe you can find a subset of the actual input > values which trigger the bug. > > Thanks for your help, > > Robert > BEGIN PGP SIGNATURE Version: GnuPG v1 Comment: Using GnuPG with Thunderbird  http://www.enigmail.net/ iQIcBAEBAgAGBQJTsUR2AAoJEFyGwOQhHVuOrPsQAK5tMQNlnX4QhZ5zJaSbpgdM Ulk8ft4duAQex/BYlwllkK31PyobzyJLxL3mb897JylsVABT4TmTSq1s9vymznFP P6yCMloIp34DaFXs5KlVuinOtXCmG9QDKatZuLrbPPx/V74wiL5d2TICYgqGxpj7 J0xGWWvJqaaaxfpQoCTOsjnafIBXrJw42ochBSMiDAd/nRUp8nTFeSro/rvkThfj UhtVz0wNAR1b73hBc4frnP7WMaab5nLVp+XrwdRsrgKqPv7kVjyrjp7KkIFPqHoN 56MiK9CE/coFiy2m5ScAKZpf5vzuxBcbZTqg/ZUA0K4zkSqTo9ZxL1SDTypFT8u5 LNBKLY1qAkJ+q85l4byC5ddt6cN4xxXoP4nteQeA3qNydcWpOlRM6H0hJJzUGXAO u4GIFhRM38/+cPpImFOVKwUrO8ZpcYxCyItYWFpgw1llgYbcQbxiSEkRti3IBuFa op53l6/jO+FXBXXZeEJ+FZOihFVMDacDXLnLYFij4zGzYilN8pemtv4H6agPJ58N W5KMbSWiSxqxaUgtd74+DzmTre6n23E8FxADkeT+u+BxfHVP+mnVTHQ2FbnQrtE3 57ncLsBMG8JvEVL5D8owAsmn7fGCssAKt0EmhVDU4ipRl7lgrt76DH88agl/p39b cOx3QnKFGAQLZjGOzDOi =zxgL END PGP SIGNATURE 
From: Robert Dodier <robert.dodier@gm...>  20140630 02:03:01

On 20140629, Richard Fateman <fateman@...> wrote: > Introducing backtracking adds capabilities but potentially horrendous > inefficiency. Perhaps the solution here is to introduce one of the > (lispsourcecode) matching programs that are around. Yeah  I think there is more than one Lisp package for unification  presumably one could be bolted onto Maxima without too much effort. Haven't tried it yet, though. Same goes for MockMMA. Looks like Mathics is written in Python, although presumably the effort of translation is less than that of reimplementing. I looked at the Mathics examples for pattern matching and it seems to do some interesting stuff not possible with Maxima's current pattern matcher. > Another solution that simplifies the pattern matching is to rearrange > the arguments so they can be matched lefttoright. Yes, that does work; I've tried that before. The solution I arrived at for the Z transform stuff is to have one superrule which matches only the parameters (n and z) and then applies other rules to hack on the function to be transformed. This exploits dynamic binding  the inner rules assume than n and z are bound to whatever the superrule found. > Here's a case that I assume would be of some interest, and not covered... > integrate(delta(z)* delta(z1)* f(z) ,.... ) . Yup. Scientists say more research is needed. best Robert Dodier 
From: Dimiter Prodanov <dimiterpp@gm...>  20140629 23:56:27

Thanks a lot for the suggestions! I will try out the workarounds. Re. the suggestion of Richard, in my package about Fourier transofrm I was following exactly this route but the Robert suggested to do as little expression hacking as possible. So in my package for the Delta function I am trying his suggestions. The current version can be pulled out from here: https://github.com/dprodanov/maximadelta For the record, I am using Maxima 33.0/ GCL 2.6.5 on Windows XP. best regards, Dimiter 
From: Richard Fateman <fateman@be...>  20140629 23:30:16

On 6/29/2014 3:17 PM, Robert Dodier wrote: <snip> >> 3. Check that arg 2 is a symbol. locally bind it to u. That is u:z . >> else fail ;********important, not done so early by matcher********** > Yeah  at present, the matcher considers arguments only in the order > they are given. I've run into exactly this problem in another context > (rules for Ztransforms). The general problem, as you know already, is > that the matcher has no backtracking capability. Introducing backtracking adds capabilities but potentially horrendous inefficiency. Perhaps the solution here is to introduce one of the (lispsourcecode) matching programs that are around. One that I wrote for "MockMMA" looks very much like the Mathematica (tm) matcher. However the surface syntax is quite different  the declarations are kind of inlined in the pattern. Anyway, it has backtracking, and could be added. I view it as an alternative not a replacement. There's also Mathics, for people who like Mathematica's pattern matching but don't want to pay Another solution that simplifies the pattern matching is to rearrange the arguments so they can be matched lefttoright. That is do this: rule1: change integrate(a,var,low,high) to integrate_var(var, a low, high). This means that the pattern matcher can look at the argument "a" to see how the particular variable var occurs in it without "guessing" what var might be... All the other rules operate on integrate_var(var, ....) except maybe one that rearranges the arguments to the conventional order. No backtracking needed to do this. > >> For example, integrate(delta(z)*foo(a,z),z,minf,inf) should probably >> return foo(a,0) but it won't. >> neither will this work... integrate(delta(z)* foo(z)*bar(z),z,minf,inf) >> or >> integrate(delta(z)*foo(bar(z)), ... > Well, the rule 'integrate(delta(u)*fn(u), u, ...) > fn(0) can't handle > those, because fn must have exactly one argument and it must be u. This is true. Your rule is much better, in addition to being simpler! I'm not sure it does a good enough job to cover all the interesting cases. And of course if we really want to allow inf, und, etc, what do we do if someone starts to ask for freefloating delta functions not inside integrate()? Here's a case that I assume would be of some interest, and not covered... integrate(delta(z)* delta(z1)* f(z) ,.... ) . But I don't use these things myself. RJF > The reformulation I gave can handle them: > > (%i1) display2d : false $ > (%i2) matchdeclare (aa, all, uu, symbolp) $ > (%i3) simp : false $ > (%i4) defrule (r1, 'integrate(delta(uu)*aa, uu, minf, inf), subst(uu=0, aa)) $ > (%i5) simp : true $ > (%i6) r1 ('integrate (delta(z)*foo(a, z), z, minf, inf)); > (%o6) foo(a,0) > (%i7) r1 ('integrate (delta(z)*foo(z)*bar(z), z, minf, inf)); > (%o7) bar(0)*foo(0) > (%i8) r1 ('integrate (delta(z)*foo(bar(z)), z, minf, inf)); > (%o8) foo(bar(0)) > > r1 doesn't have the bug in it, so these will work even without the bug > fix. > > best > > Robert Dodier > > __________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Robert Dodier <robert.dodier@gm...>  20140629 22:17:47

On 20140629, Richard Fateman <fateman@...> wrote: > Interestingly, if the correctness of the rule seems to depend on the > alphabetic order of the terms in the integrand. > Thus changing it from delta(u)* fn(u) to gdelta(u)*fn(u) > makes it work. Yes  in that case, the bug is not triggered. > 3. Check that arg 2 is a symbol. locally bind it to u. That is u:z . > else fail ;********important, not done so early by matcher********** Yeah  at present, the matcher considers arguments only in the order they are given. I've run into exactly this problem in another context (rules for Ztransforms). The general problem, as you know already, is that the matcher has no backtracking capability. > For example, integrate(delta(z)*foo(a,z),z,minf,inf) should probably > return foo(a,0) but it won't. > neither will this work... integrate(delta(z)* foo(z)*bar(z),z,minf,inf) > or > integrate(delta(z)*foo(bar(z)), ... Well, the rule 'integrate(delta(u)*fn(u), u, ...) > fn(0) can't handle those, because fn must have exactly one argument and it must be u. The reformulation I gave can handle them: (%i1) display2d : false $ (%i2) matchdeclare (aa, all, uu, symbolp) $ (%i3) simp : false $ (%i4) defrule (r1, 'integrate(delta(uu)*aa, uu, minf, inf), subst(uu=0, aa)) $ (%i5) simp : true $ (%i6) r1 ('integrate (delta(z)*foo(a, z), z, minf, inf)); (%o6) foo(a,0) (%i7) r1 ('integrate (delta(z)*foo(z)*bar(z), z, minf, inf)); (%o7) bar(0)*foo(0) (%i8) r1 ('integrate (delta(z)*foo(bar(z)), z, minf, inf)); (%o8) foo(bar(0)) r1 doesn't have the bug in it, so these will work even without the bug fix. best Robert Dodier 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20140629 21:53:19

Yes, we've discussed labelled nonfinites in the past. But right now, we don't even have a reasonable interval package for Maxima, so labelled intervals aren't terribly relevant. As I say, let's take one step at a time, reduce user confusion by eliminating infinf => 0 and the like, and make 1/und => und. We can improve from there. s On Sun, Jun 29, 2014 at 5:29 PM, Richard Fateman <fateman@...> wrote: > On 6/29/2014 2:13 PM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: > > Disallowing arithmetic on nonfinite numbers (different from > transfinite, I think) is the safest solution  I suppose that could be yet > another switch. > > Still, in this case I agree with (what I am guessing) will be Dodier's > response: why give an error if you can give a somewhat useful and > meaningful result? Some of the time it will be overpessimistic. But for > now, where the simplifier is ignorant of nonfinite things, we are doing > overoptimistic horrors like und/und=>1! > > I wouldn't call und/und > 1 optimistic. I would say that the semantics > for "und" are not part of Maxima. > Maybe "und" is shorthand for "underwear". > > > > As for the definition of sin(und), etc., I would want those to be > consistent with singleargument 'limit'. As it happens, > limit(sin(ind))=>ind, limit(atan(inf))=>%pi/2, and limit(sin(inf))=>ind, > while limit(sin(und))=>und and limit(atan(und))=>und. > > In Mathematica (and Maple too, I think... I don't have a current Maple) > sin[Infinity] is Interval[{1,1}] > > I'm not endorsing this, just saying.. > > I think we should break out some of the parts of the limit code so that we > know who is computing what. > so if there is an implementation of the algorithm by Gruntz, it should be > available. > So should tlimit (this is the case now!) which uses Taylor series. > Then there is the old code (mostly by Paul Wang) which I think is > majorized by Gruntz, but I'm not > sure. > > I have proposed that one could make some sense of these odd objects > (especially intervals) by giving them each unique > labels. Thus if you have an x : interval(1,1,label1) and another y: > interval(1,1,label2), you could say that > if label1=label2, then xy is 0. (or maybe interval(0,0)). > However, if label1 and label2 are different, xy is interval(2,2, > label3). > > works a little for inf and und as well, if you insist on letting them hang > around. You still need to implement something that > poisons any computation with und as resulting in und. And you still > can't prevent x/x from becoming 1 unless you > start computing, as I've said just yesterday, to produce "if > finite(x) then 1 else ???".. > > It's too nice a day here to type any more.. > RJF > > > > The intuition behind singleargument limit is that if for all functions > f and g, limit(f(x))=>F and limit(g(x))=>G implies that > limit(h(f(x),g(x)),...)=>H, then limit(h(F,G)) => H (or a superset of H). > (Where F, G, and H, are all possibly nonfinite.) und is a superset of all > other values; und is a superset of ind; ind is a superset of a single > number; etc. > > Though I don't understand what limit is trying to do in some cases. For > example, k1:limit(ind+1)=>ind+1, not ind, though > k2:limit(sin(x)+1,x,inf)=>ind and k3:limit(sin(x)+cos(x+k),x,inf) => ind. > Is it assuming that all ind's are the same ind? No. Is it assuming that > they are all distinct? No. Is it assuming that it doesn't know whether they > are the same or distinct? Not really; if it were, k3 shouldn't give ind, > because for some values of k, the answer is a constant. > > s > > > > On Sun, Jun 29, 2014 at 4:51 PM, Richard Fateman <fateman@...> > wrote: > >> Before hacking away on the simplifier and such... >> >> I think a more cautious (and accurate) approach would be to disallow any >> arithmetic with transfinite numbers, >> based on the realization that most of Maxima relies on the symbolic >> manipulation of object that are >> not ever transfinite numbers. >> >> That is, inf, minf and friends are OK in only very limited >> circumstances. As the input to limit (and friends) >> (where the construction limit (....., x, inf) has a particular >> meaning and could perhaps be >> represented as... >> >> limit_inf( lambda([x], ....) >> >> without use of inf as a symbol... >> >> and it is also OK to have inf as the output of a limit command, or a few >> others. On the condition >> that it not be used again. >> >> Note that currently 1/0 produces an error. It does not produce und, >> inf, infinity, >> >> If you wish to create a system with transfinite numbers, it is not likely >> to fit easily as a >> patch on existing Maxima with symbols inf, minf, und. >> >> Here's one way of doing things though, if you want to have arithmetic >> solely on real/rational/transfinite/... >> you can use the IEEE754 floatingpoint encodings for NaN, inf, etc. Not >> that these are without >> problems, but at least they have been specified in detail, and the >> glitches are described. >> Presumably someone has written such a package >> >> e.g. is UND real? is cos(UND) supposed to be UND, or might it be >> interval(1,1)? >> are you going to just make up the answer to this question, or have some >> comprehensive >> basis for all of Maxima? Or all of arithmeticonconstants? >> >> RJF >> >> >> On 6/29/2014 7:16 AM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: >> >> Agreed that it is not a perfect fix. But "the best is the enemy of >> the good". >> >> s >> >> >> On Sun, Jun 29, 2014 at 1:40 AM, Richard Fateman <fateman@...> >> wrote: >> >>> These are not fixes. At best they move the bugs/features. The failure >>> remains as >>> a failure in referential transparency because of the transfinite numbers. >>> >>> Let's define f(x):= x^2/x. >>> >>> Maxima simplifies f(z) to z. >>> >>> For all z. >>> >>> >>> except this is a lie for some values of z that one can imagine, like >>> inf, und, minf, and >>> (depending on how you define them) intervals. >>> >>> so if you choose to do arithmetic on infs, most of the rest of the >>> system becomes broken. >>> >>> Inf (etc) are not numbers. They are handy notations for limits and >>> such. But patches such >>> as making 0*inf be und will not work unless you simplify 0*x to "if >>> transfinite(x) then und else 0" >>> or some such thing. >>> >>> RJF >>> >>> >>> >>> On 6/28/2014 4:31 PM, Robert Dodier wrote: >>> > On 20140628, Dimiter Prodanov <dimiterpp@...> wrote: >>> > >>> >>>> 0*minf >>> >> 0 >>> >> should be undefined >>> >> >>> >>>> 0*inf >>> >> 0 >>> >> should be undefined >>> >> >>> >>>> 0*infinity; >>> >> 0 >>> >> should be undefined >>> > I agree that these are all bugs and we should simplify such expressions >>> > as suggested. >>> > >>> >> On the other hand, in NonStandard analysis/ Infinitesimal calculus >>> the >>> >> results can be OK. >>> > Maxima had better stick to standard analysis  heaven knows we have >>> > enough trouble as it is .... >>> > >>> > best >>> > >>> > Robert Dodier >>> > >>> > >>> > >>>  >>> > Open source business process management suite built on Java and Eclipse >>> > Turn processes into business applications with Bonita BPM Community >>> Edition >>> > Quickly connect people, data, and systems into organized workflows >>> > Winner of BOSSIE, CODIE, OW2 and Gartner awards >>> > http://p.sf.net/sfu/Bonitasoft >>> > _______________________________________________ >>> > Maximadiscuss mailing list >>> > Maximadiscuss@... >>> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss >>> >>> >>> >>>  >>> Open source business process management suite built on Java and Eclipse >>> Turn processes into business applications with Bonita BPM Community >>> Edition >>> Quickly connect people, data, and systems into organized workflows >>> Winner of BOSSIE, CODIE, OW2 and Gartner awards >>> http://p.sf.net/sfu/Bonitasoft >>> _______________________________________________ >>> Maximadiscuss mailing list >>> Maximadiscuss@... >>> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >>> >> >> >> >> >>  >> Open source business process management suite built on Java and Eclipse >> Turn processes into business applications with Bonita BPM Community >> Edition >> Quickly connect people, data, and systems into organized workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> >> > > 
From: Richard Fateman <fateman@be...>  20140629 21:29:47

On 6/29/2014 2:13 PM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: > Disallowing arithmetic on nonfinite numbers (different from > transfinite, I think) is the safest solution  I suppose that could > be yet another switch. > > Still, in this case I agree with (what I am guessing) will be Dodier's > response: why give an error if you can give a somewhat useful and > meaningful result? Some of the time it will be overpessimistic. But > for now, where the simplifier is ignorant of nonfinite things, we are > doing overoptimistic horrors like und/und=>1! I wouldn't call und/und > 1 optimistic. I would say that the semantics for "und" are not part of Maxima. Maybe "und" is shorthand for "underwear". > > As for the definition of sin(und), etc., I would want those to be > consistent with singleargument 'limit'. As it happens, > limit(sin(ind))=>ind, limit(atan(inf))=>%pi/2, and > limit(sin(inf))=>ind, while limit(sin(und))=>und and > limit(atan(und))=>und. In Mathematica (and Maple too, I think... I don't have a current Maple) sin[Infinity] is Interval[{1,1}] I'm not endorsing this, just saying.. I think we should break out some of the parts of the limit code so that we know who is computing what. so if there is an implementation of the algorithm by Gruntz, it should be available. So should tlimit (this is the case now!) which uses Taylor series. Then there is the old code (mostly by Paul Wang) which I think is majorized by Gruntz, but I'm not sure. I have proposed that one could make some sense of these odd objects (especially intervals) by giving them each unique labels. Thus if you have an x : interval(1,1,label1) and another y: interval(1,1,label2), you could say that if label1=label2, then xy is 0. (or maybe interval(0,0)). However, if label1 and label2 are different, xy is interval(2,2, label3). works a little for inf and und as well, if you insist on letting them hang around. You still need to implement something that poisons any computation with und as resulting in und. And you still can't prevent x/x from becoming 1 unless you start computing, as I've said just yesterday, to produce "if finite(x) then 1 else ???".. It's too nice a day here to type any more.. RJF > The intuition behind singleargument limit is that if for all > functions f and g, limit(f(x))=>F and limit(g(x))=>G implies that > limit(h(f(x),g(x)),...)=>H, then limit(h(F,G)) => H (or a superset of > H). (Where F, G, and H, are all possibly nonfinite.) und is a > superset of all other values; und is a superset of ind; ind is a > superset of a single number; etc. > > Though I don't understand what limit is trying to do in some cases. > For example, k1:limit(ind+1)=>ind+1, not ind, though > k2:limit(sin(x)+1,x,inf)=>ind and k3:limit(sin(x)+cos(x+k),x,inf) => > ind. Is it assuming that all ind's are the same ind? No. Is it > assuming that they are all distinct? No. Is it assuming that it > doesn't know whether they are the same or distinct? Not really; if it > were, k3 shouldn't give ind, because for some values of k, the answer > is a constant. > > s > > > > On Sun, Jun 29, 2014 at 4:51 PM, Richard Fateman <fateman@... > <mailto:fateman@...>> wrote: > > Before hacking away on the simplifier and such... > > I think a more cautious (and accurate) approach would be to > disallow any arithmetic with transfinite numbers, > based on the realization that most of Maxima relies on the > symbolic manipulation of object that are > not ever transfinite numbers. > > That is, inf, minf and friends are OK in only very limited > circumstances. As the input to limit (and friends) > (where the construction limit (....., x, inf) has a > particular meaning and could perhaps be > represented as... > > limit_inf( lambda([x], ....) > > without use of inf as a symbol... > > and it is also OK to have inf as the output of a limit command, or > a few others. On the condition > that it not be used again. > > Note that currently 1/0 produces an error. It does not > produce und, inf, infinity, > > If you wish to create a system with transfinite numbers, it is not > likely to fit easily as a > patch on existing Maxima with symbols inf, minf, und. > > Here's one way of doing things though, if you want to have > arithmetic solely on real/rational/transfinite/... > you can use the IEEE754 floatingpoint encodings for NaN, inf, > etc. Not that these are without > problems, but at least they have been specified in detail, and the > glitches are described. > Presumably someone has written such a package > > e.g. is UND real? is cos(UND) supposed to be UND, or might it > be interval(1,1)? > are you going to just make up the answer to this question, or have > some comprehensive > basis for all of Maxima? Or all of arithmeticonconstants? > > RJF > > > On 6/29/2014 7:16 AM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: >> Agreed that it is not a perfect fix. But "the best is the enemy >> of the good". >> >> s >> >> >> On Sun, Jun 29, 2014 at 1:40 AM, Richard Fateman >> <fateman@... <mailto:fateman@...>> wrote: >> >> These are not fixes. At best they move the bugs/features. >> The failure >> remains as >> a failure in referential transparency because of the >> transfinite numbers. >> >> Let's define f(x):= x^2/x. >> >> Maxima simplifies f(z) to z. >> >> For all z. >> >> >> except this is a lie for some values of z that one can >> imagine, like >> inf, und, minf, and >> (depending on how you define them) intervals. >> >> so if you choose to do arithmetic on infs, most of the rest >> of the >> system becomes broken. >> >> Inf (etc) are not numbers. They are handy notations for >> limits and >> such. But patches such >> as making 0*inf be und will not work unless you simplify >> 0*x to "if >> transfinite(x) then und else 0" >> or some such thing. >> >> RJF >> >> >> >> On 6/28/2014 4:31 PM, Robert Dodier wrote: >> > On 20140628, Dimiter Prodanov <dimiterpp@... >> <mailto:dimiterpp@...>> wrote: >> > >> >>>> 0*minf >> >> 0 >> >> should be undefined >> >> >> >>>> 0*inf >> >> 0 >> >> should be undefined >> >> >> >>>> 0*infinity; >> >> 0 >> >> should be undefined >> > I agree that these are all bugs and we should simplify such >> expressions >> > as suggested. >> > >> >> On the other hand, in NonStandard analysis/ Infinitesimal >> calculus the >> >> results can be OK. >> > Maxima had better stick to standard analysis  heaven >> knows we have >> > enough trouble as it is .... >> > >> > best >> > >> > Robert Dodier >> > >> > >> > >>  >> > Open source business process management suite built on Java >> and Eclipse >> > Turn processes into business applications with Bonita BPM >> Community Edition >> > Quickly connect people, data, and systems into organized >> workflows >> > Winner of BOSSIE, CODIE, OW2 and Gartner awards >> > http://p.sf.net/sfu/Bonitasoft >> > _______________________________________________ >> > Maximadiscuss mailing list >> > Maximadiscuss@... >> <mailto:Maximadiscuss@...> >> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> >> >>  >> Open source business process management suite built on Java >> and Eclipse >> Turn processes into business applications with Bonita BPM >> Community Edition >> Quickly connect people, data, and systems into organized >> workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> <mailto:Maximadiscuss@...> >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> >> > > >  > Open source business process management suite built on Java and > Eclipse > Turn processes into business applications with Bonita BPM > Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > <mailto:Maximadiscuss@...> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Richard Fateman <fateman@be...>  20140629 21:18:08

Thanks for finding/fixing this. Interestingly, if the correctness of the rule seems to depend on the alphabetic order of the terms in the integrand. Thus changing it from delta(u)* fn(u) to gdelta(u)*fn(u) makes it work. I hope your fix works even in this case ... (matchdeclare (u, atom, fn, symbolp), defrule (ddint21, 'integrate(gdelta(u)*fn(u), u, minf, inf), fn(0)) ); RJF (who put this code in Macsyma in the late 1960's, but doesn't necessary recognize what's in there anymore.. postscript The commercial Macsyma code apparently has a rewritten matchcompiler) The code it generates looks like this (LAMBDA (TEMP8) (MATCHPROG ($FN $U TEMP9 TEMP10 TEMP11 TEMP12 TEMP13 TEMP14) (DECLARE (SPECIAL $FN $U)) (WHEN (ATOM TEMP8) (MATCHFAIL)) (UNLESS (EQUAL (CAAR TEMP8) (QUOTE %INTEGRATE)) (MATCHFAIL)) (SETQ TEMP9 (CDR TEMP8)) (UNLESS (= (LENGTH TEMP9) 4) (MATCHFAIL)) (SETQ TEMP10 TEMP9) (SETQ TEMP11 (NTH 1 TEMP10)) (IF ($ATOM TEMP11) (MSETQ $U TEMP11) (MATCHFAIL)) (SETQ TEMP11 (NTH 0 TEMP10)) (LET ((*INHIBITUSERRULES* T)) (SETQ TEMP11 (SRATSIMP (M/ TEMP11 (MEVAL (QUOTE (($DELTA SIMP) $U))))))) (WHEN (ATOM TEMP11) (MATCHFAIL)) (IF ($SYMBOLP (CAAR TEMP11)) (MSETQ $FN (CAAR TEMP11)) (MATCHFAIL)) (SETQ TEMP12 (CDR TEMP11)) (UNLESS (= (LENGTH TEMP12) 1) (MATCHFAIL)) (SETQ TEMP13 TEMP12) (SETQ TEMP14 (NTH 0 TEMP13)) (UNLESS (ALIKE1 TEMP14 (MEVALWITHOUTRULES (QUOTE $U))) (MATCHFAIL)) (SETQ TEMP11 (NTH 2 TEMP10)) (UNLESS (ALIKE1 TEMP11 (MEVALWITHOUTRULES (QUOTE $MINF))) (MATCHFAIL)) (SETQ TEMP11 (NTH 3 TEMP10)) (UNLESS (ALIKE1 TEMP11 (MEVALWITHOUTRULES (QUOTE $INF))) (MATCHFAIL)) (RETURN (MEVAL (QUOTE (($FN SIMP) 0)))))) It took a little work (via tracing) to get this code, since Macsyma routinely runs it through the lisp compiler. Maxima could do the same as part of the defrule and/or defmatch code. Macsyma does not seem to have the same bug, but seems to have the general defect that it doesn't match things in the right order for the user. At least that's what it seems to me from scanning the code. That is, what the user probably intends is the following. Given the expression integrate(delta(z)*foo(z),z,minf,inf) 1. Look for a nonatom with a header, 'integrate. if you've found it, continue else fail 2. Look for presence of 4 arguments. If yes, continue else fail 3. Check that arg 2 is a symbol. locally bind it to u. That is u:z . else fail ;********important, not done so early by matcher********** 4. check that arg3 and 4 are minf and inf respectively else fail 5. Let temp = arg 1 / delta(u). 6. [several steps...] Does temp look like fn(u)? If yes, everything matches and return fn(0) else fail. Even this much improved protocol is wrong, though. Even if it probably reflects what the user sort of meant. For example, integrate(delta(z)*foo(a,z),z,minf,inf) should probably return foo(a,0) but it won't. neither will this work... integrate(delta(z)* foo(z)*bar(z),z,minf,inf) or integrate(delta(z)*foo(bar(z)), ... etc etc etc. So let's face it: this ruledirected approach has a fair amount to disrecommend its use for this task. How about a little program that might be applied in appropriate circumstances, perhaps detected by pattern matching or not, but the pattern just feeds into an algorithm like this. integrate_deltaprod_minf_inf( integrand, u):= 1. See if the integrand can be arranged to be a product of delta (f1(u)) * f2(f1(u)) where f1(minf) is minf and f1(inf) is inf. (true if f1(u)=u or u^3, say) 2. Make sure that f2(f1(u)) does not contain any delta terms that depend on u, and then return f2(f1(0)). Step1 can be accomplished by making a list of all delta() items, using division to find what is left over, and calling that f2. Note that there is a big advantage to knowing what u is BEFORE looking for delta(u). By the way, didn't someone already write a package for integrating delta stuff? Um, finally, none of this comment on integration is meant to indicate that it is ok for the pattern code to have bugs. Thanks for finding/fixing bugs! RJF On 6/29/2014 1:28 PM, Robert Dodier wrote: > On 20140629, Dimiter Prodanov <dimiterpp@...> wrote: > >> (matchdeclare (u, atom, fn, symbolp), >> defrule (ddint21, 'integrate(delta(u)*fn(u), u, minf, inf), fn(0)) >> ); > OK, I've fixed this bug and pushed it as commit 2919edf1. > > Now I get: > > (%i1) matchdeclare (u, atom, fn, symbolp) $ > (%i2) defrule (ddint21, 'integrate(delta(u)*fn(u), u, minf, inf), fn(0)) $ > (%i3) ddint21 ('integrate (delta(x) * foo(x), x, minf, inf)); > (%o3) foo(0) > > best > > Robert Dodier > > >  > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20140629 21:13:14

Disallowing arithmetic on nonfinite numbers (different from transfinite, I think) is the safest solution  I suppose that could be yet another switch. Still, in this case I agree with (what I am guessing) will be Dodier's response: why give an error if you can give a somewhat useful and meaningful result? Some of the time it will be overpessimistic. But for now, where the simplifier is ignorant of nonfinite things, we are doing overoptimistic horrors like und/und=>1! As for the definition of sin(und), etc., I would want those to be consistent with singleargument 'limit'. As it happens, limit(sin(ind))=>ind, limit(atan(inf))=>%pi/2, and limit(sin(inf))=>ind, while limit(sin(und))=>und and limit(atan(und))=>und. The intuition behind singleargument limit is that if for all functions f and g, limit(f(x))=>F and limit(g(x))=>G implies that limit(h(f(x),g(x)),...)=>H, then limit(h(F,G)) => H (or a superset of H). (Where F, G, and H, are all possibly nonfinite.) und is a superset of all other values; und is a superset of ind; ind is a superset of a single number; etc. Though I don't understand what limit is trying to do in some cases. For example, k1:limit(ind+1)=>ind+1, not ind, though k2:limit(sin(x)+1,x,inf)=>ind and k3:limit(sin(x)+cos(x+k),x,inf) => ind. Is it assuming that all ind's are the same ind? No. Is it assuming that they are all distinct? No. Is it assuming that it doesn't know whether they are the same or distinct? Not really; if it were, k3 shouldn't give ind, because for some values of k, the answer is a constant. s On Sun, Jun 29, 2014 at 4:51 PM, Richard Fateman <fateman@...> wrote: > Before hacking away on the simplifier and such... > > I think a more cautious (and accurate) approach would be to disallow any > arithmetic with transfinite numbers, > based on the realization that most of Maxima relies on the symbolic > manipulation of object that are > not ever transfinite numbers. > > That is, inf, minf and friends are OK in only very limited > circumstances. As the input to limit (and friends) > (where the construction limit (....., x, inf) has a particular > meaning and could perhaps be > represented as... > > limit_inf( lambda([x], ....) > > without use of inf as a symbol... > > and it is also OK to have inf as the output of a limit command, or a few > others. On the condition > that it not be used again. > > Note that currently 1/0 produces an error. It does not produce und, > inf, infinity, > > If you wish to create a system with transfinite numbers, it is not likely > to fit easily as a > patch on existing Maxima with symbols inf, minf, und. > > Here's one way of doing things though, if you want to have arithmetic > solely on real/rational/transfinite/... > you can use the IEEE754 floatingpoint encodings for NaN, inf, etc. Not > that these are without > problems, but at least they have been specified in detail, and the > glitches are described. > Presumably someone has written such a package > > e.g. is UND real? is cos(UND) supposed to be UND, or might it be > interval(1,1)? > are you going to just make up the answer to this question, or have some > comprehensive > basis for all of Maxima? Or all of arithmeticonconstants? > > RJF > > > On 6/29/2014 7:16 AM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: > > Agreed that it is not a perfect fix. But "the best is the enemy of the > good". > > s > > > On Sun, Jun 29, 2014 at 1:40 AM, Richard Fateman <fateman@...> > wrote: > >> These are not fixes. At best they move the bugs/features. The failure >> remains as >> a failure in referential transparency because of the transfinite numbers. >> >> Let's define f(x):= x^2/x. >> >> Maxima simplifies f(z) to z. >> >> For all z. >> >> >> except this is a lie for some values of z that one can imagine, like >> inf, und, minf, and >> (depending on how you define them) intervals. >> >> so if you choose to do arithmetic on infs, most of the rest of the >> system becomes broken. >> >> Inf (etc) are not numbers. They are handy notations for limits and >> such. But patches such >> as making 0*inf be und will not work unless you simplify 0*x to "if >> transfinite(x) then und else 0" >> or some such thing. >> >> RJF >> >> >> >> On 6/28/2014 4:31 PM, Robert Dodier wrote: >> > On 20140628, Dimiter Prodanov <dimiterpp@...> wrote: >> > >> >>>> 0*minf >> >> 0 >> >> should be undefined >> >> >> >>>> 0*inf >> >> 0 >> >> should be undefined >> >> >> >>>> 0*infinity; >> >> 0 >> >> should be undefined >> > I agree that these are all bugs and we should simplify such expressions >> > as suggested. >> > >> >> On the other hand, in NonStandard analysis/ Infinitesimal calculus the >> >> results can be OK. >> > Maxima had better stick to standard analysis  heaven knows we have >> > enough trouble as it is .... >> > >> > best >> > >> > Robert Dodier >> > >> > >> > >>  >> > Open source business process management suite built on Java and Eclipse >> > Turn processes into business applications with Bonita BPM Community >> Edition >> > Quickly connect people, data, and systems into organized workflows >> > Winner of BOSSIE, CODIE, OW2 and Gartner awards >> > http://p.sf.net/sfu/Bonitasoft >> > _______________________________________________ >> > Maximadiscuss mailing list >> > Maximadiscuss@... >> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> >> >> >>  >> Open source business process management suite built on Java and Eclipse >> Turn processes into business applications with Bonita BPM Community >> Edition >> Quickly connect people, data, and systems into organized workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> > > > > >  > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Richard Fateman <fateman@be...>  20140629 20:51:20

Before hacking away on the simplifier and such... I think a more cautious (and accurate) approach would be to disallow any arithmetic with transfinite numbers, based on the realization that most of Maxima relies on the symbolic manipulation of object that are not ever transfinite numbers. That is, inf, minf and friends are OK in only very limited circumstances. As the input to limit (and friends) (where the construction limit (....., x, inf) has a particular meaning and could perhaps be represented as... limit_inf( lambda([x], ....) without use of inf as a symbol... and it is also OK to have inf as the output of a limit command, or a few others. On the condition that it not be used again. Note that currently 1/0 produces an error. It does not produce und, inf, infinity, If you wish to create a system with transfinite numbers, it is not likely to fit easily as a patch on existing Maxima with symbols inf, minf, und. Here's one way of doing things though, if you want to have arithmetic solely on real/rational/transfinite/... you can use the IEEE754 floatingpoint encodings for NaN, inf, etc. Not that these are without problems, but at least they have been specified in detail, and the glitches are described. Presumably someone has written such a package e.g. is UND real? is cos(UND) supposed to be UND, or might it be interval(1,1)? are you going to just make up the answer to this question, or have some comprehensive basis for all of Maxima? Or all of arithmeticonconstants? RJF On 6/29/2014 7:16 AM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: > Agreed that it is not a perfect fix. But "the best is the enemy of > the good". > > s > > > On Sun, Jun 29, 2014 at 1:40 AM, Richard Fateman <fateman@... > <mailto:fateman@...>> wrote: > > These are not fixes. At best they move the bugs/features. The failure > remains as > a failure in referential transparency because of the transfinite > numbers. > > Let's define f(x):= x^2/x. > > Maxima simplifies f(z) to z. > > For all z. > > > except this is a lie for some values of z that one can imagine, like > inf, und, minf, and > (depending on how you define them) intervals. > > so if you choose to do arithmetic on infs, most of the rest of the > system becomes broken. > > Inf (etc) are not numbers. They are handy notations for limits and > such. But patches such > as making 0*inf be und will not work unless you simplify 0*x to > "if > transfinite(x) then und else 0" > or some such thing. > > RJF > > > > On 6/28/2014 4:31 PM, Robert Dodier wrote: > > On 20140628, Dimiter Prodanov <dimiterpp@... > <mailto:dimiterpp@...>> wrote: > > > >>>> 0*minf > >> 0 > >> should be undefined > >> > >>>> 0*inf > >> 0 > >> should be undefined > >> > >>>> 0*infinity; > >> 0 > >> should be undefined > > I agree that these are all bugs and we should simplify such > expressions > > as suggested. > > > >> On the other hand, in NonStandard analysis/ Infinitesimal > calculus the > >> results can be OK. > > Maxima had better stick to standard analysis  heaven knows we have > > enough trouble as it is .... > > > > best > > > > Robert Dodier > > > > > > >  > > Open source business process management suite built on Java and > Eclipse > > Turn processes into business applications with Bonita BPM > Community Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > _______________________________________________ > > Maximadiscuss mailing list > > Maximadiscuss@... > <mailto:Maximadiscuss@...> > > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > >  > Open source business process management suite built on Java and > Eclipse > Turn processes into business applications with Bonita BPM > Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > <mailto:Maximadiscuss@...> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Robert Dodier <robert.dodier@gm...>  20140629 20:28:51

On 20140629, Dimiter Prodanov <dimiterpp@...> wrote: > (matchdeclare (u, atom, fn, symbolp), > defrule (ddint21, 'integrate(delta(u)*fn(u), u, minf, inf), fn(0)) > ); OK, I've fixed this bug and pushed it as commit 2919edf1. Now I get: (%i1) matchdeclare (u, atom, fn, symbolp) $ (%i2) defrule (ddint21, 'integrate(delta(u)*fn(u), u, minf, inf), fn(0)) $ (%i3) ddint21 ('integrate (delta(x) * foo(x), x, minf, inf)); (%o3) foo(0) best Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20140629 19:24:54

On 20140629, Dimiter Prodanov <dimiterpp@...> wrote: > (matchdeclare (u, atom, fn, symbolp), > defrule (ddint21, 'integrate(delta(u)*fn(u), u, minf, inf), fn(0)) > ); > >>> ddint21('integrate(delta(u)*fn(u), u, minf, inf)); > output false > should be > fn(0) That's a bug in the function which is generated for that rule. I've appended the generated code below  you can see that TRGENSYM7 is referenced but without being assigned a value before. I suspect that the (KAAR TRGENSYM7) should be (KAAR TRGENSYM3). (An alternative suspicion is that the immediately preceding (SETQ TRGENSYM3 ...) should be (SETQ TRGENSYM7 ...).) I'll look at fixing the bug although it might be tricky to figure it out. A workaround is to phrase the rule in a different way which doesn't trigger the bug; here's an example. There are probably other formulations that also work. (%i1) display2d : false $ (%i2) matchdeclare (aa, all, xx, symbolp) $ (%i3) simp : false $ (%i4) defrule (r1, 'integrate(delta(xx)*aa, xx, minf, inf), subst (xx = 0, aa)) $ (%i5) simp : true $ (%i6) r1 ('integrate (delta(u)*f(u)*g(t  u), u, minf, inf)); (%o6) f(0)*g(t) best Robert Dodier PS. I'm working with Clisp. :lisp #'$ddint21 #<FUNCTION LAMBDA (TRGENSYM1) (DECLARE (SPECIAL TRGENSYM1)) (CATCH 'MATCH (PROG ($FN $U TRGENSYM2 TRGENSYM3 TRGENSYM4 TRGENSYM5 TRGENSYM6 TRGENSYM7 TRGENSYM8 TRGENSYM9 TRGENSYM10 TRGENSYM11 TRGENSYM12 TRGENSYM13) (DECLARE (SPECIAL $FN $U TRGENSYM2 TRGENSYM3 TRGENSYM4 TRGENSYM5 TRGENSYM6 TRGENSYM7 TRGENSYM8 TRGENSYM9 TRGENSYM10 TRGENSYM11 TRGENSYM12 TRGENSYM13)) (COND ((NOT (EQUAL (KAAR TRGENSYM1) '%INTEGRATE)) (MATCHERR))) (SETQ TRGENSYM2 (KDR TRGENSYM1)) (SETQ TRGENSYM3 (KAR TRGENSYM2)) (SETQ TRGENSYM4 (FINDFUN TRGENSYM3 (MEVAL '$DELTA) 'MTIMES)) (SETQ TRGENSYM5 (KDR TRGENSYM4)) (SETQ TRGENSYM6 (KAR TRGENSYM5)) (COND ((DEFINITELYSO '(($ATOM) TRGENSYM6)) (MSETQ $U TRGENSYM6)) ((MATCHERR))) (COND ((NTHKDR TRGENSYM5 1) (MATCHERR))) (SETQ TRGENSYM3 (MEVAL '((MQUOTIENT) TRGENSYM3 (($DELTA SIMP) $U)))) (MSETQ $FN (KAAR TRGENSYM7)) (SETQ TRGENSYM8 (FINDFUN TRGENSYM3 $FN 'MTIMES)) (SETQ TRGENSYM9 (KDR TRGENSYM8)) (SETQ TRGENSYM10 (KAR TRGENSYM9)) (COND ((NOT (ALIKE1 TRGENSYM10 (MEVAL '$U))) (MATCHERR))) (COND ((NTHKDR TRGENSYM9 1) (MATCHERR))) (SETQ TRGENSYM3 (MEVAL '((MQUOTIENT) TRGENSYM3 (($FN SIMP) $U)))) (COND ((NOT (EQUAL TRGENSYM3 1)) (MATCHERR))) (SETQ TRGENSYM11 (KAR (KDR TRGENSYM2))) (COND ((NOT (ALIKE1 TRGENSYM11 (MEVAL '$U))) (MATCHERR))) (SETQ TRGENSYM12 (KAR (KDR (KDR TRGENSYM2)))) (COND ((NOT (ALIKE1 TRGENSYM12 (MEVAL '$MINF))) (MATCHERR))) (SETQ TRGENSYM13 (KAR (KDR (KDR (KDR TRGENSYM2))))) (COND ((NOT (ALIKE1 TRGENSYM13 (MEVAL '$INF))) (MATCHERR))) (COND ((NTHKDR TRGENSYM2 4) (MATCHERR))) (RETURN (VALUES (MEVAL '(($FN SIMP) 0)) T))))> 
From: Pankaj Sejwal <pankajsejwal@gm...>  20140629 18:33:18

> > Hi, > > >>>>>>>>>>Dimiter question>>>>>> > > I have a problem with the following rule > > (matchdeclare (u, atom, fn, symbolp), > defrule (ddint21, 'integrate(delta(u)*fn(u), u, minf, inf), fn(0)) > ); > >> ddint21('integrate(delta(u)*fn(u), u, minf, inf)); > output false > > should be > > fn(0) > > I tried playing around relaxing the match but even with true true it > doesn't work. > > Dimiter > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > May be you could use let instead, > %in:: let('integrate(delta(u)*fn(u), u, minf, inf), fn(0)); %out:: integrate(delta(u)*fn(u),u,inf,inf) > fn(0) %in:: letsimp('integrate(delta(u)*fn(u), u, minf, inf)); %out:: fn(0) > > Hope it helps.  Regards, Pankaj Sejwal 
From: 有坂富雄 <arisaka_110430@ic...>  20140629 17:08:18

Thank you for your description. I almost agree with you on thinking of the powerseries. I am looking forward to your project. If you need help, please let me know. Regards, Tomio Arisaka On 2014629, Barton Willis wrote: > Does it mean the function powerseries includes some experimental codes? > Please let me know what you think of the powerseries. No, not really. I thought some bugs in powerseries were a bit hard to fix, so I started from scratch. And like all such projects, the first 90+% is easy and the rest is tedious. My from scratch code incorporates some code I wrote long ago that attempts to convert to hypergeometric formbessel functions, for example. After conversion, the power series of the hypergeometric is routine. One thing I don't particularly like about the series.lisp code is that the function dispatch isn't, I think, sufficient to deal with multivariate function (for example Bessel) Another thing about series.lisp is that it apparently duplicates partial fraction code. I don't know how much I'll work on this codeit was a fun thing I started one day. Maybe somebody would like to help me with it. That would be OK. Barton 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20140629 14:16:46

Agreed that it is not a perfect fix. But "the best is the enemy of the good". s On Sun, Jun 29, 2014 at 1:40 AM, Richard Fateman <fateman@...> wrote: > These are not fixes. At best they move the bugs/features. The failure > remains as > a failure in referential transparency because of the transfinite numbers. > > Let's define f(x):= x^2/x. > > Maxima simplifies f(z) to z. > > For all z. > > > except this is a lie for some values of z that one can imagine, like > inf, und, minf, and > (depending on how you define them) intervals. > > so if you choose to do arithmetic on infs, most of the rest of the > system becomes broken. > > Inf (etc) are not numbers. They are handy notations for limits and > such. But patches such > as making 0*inf be und will not work unless you simplify 0*x to "if > transfinite(x) then und else 0" > or some such thing. > > RJF > > > > On 6/28/2014 4:31 PM, Robert Dodier wrote: > > On 20140628, Dimiter Prodanov <dimiterpp@...> wrote: > > > >>>> 0*minf > >> 0 > >> should be undefined > >> > >>>> 0*inf > >> 0 > >> should be undefined > >> > >>>> 0*infinity; > >> 0 > >> should be undefined > > I agree that these are all bugs and we should simplify such expressions > > as suggested. > > > >> On the other hand, in NonStandard analysis/ Infinitesimal calculus the > >> results can be OK. > > Maxima had better stick to standard analysis  heaven knows we have > > enough trouble as it is .... > > > > best > > > > Robert Dodier > > > > > > >  > > Open source business process management suite built on Java and Eclipse > > Turn processes into business applications with Bonita BPM Community > Edition > > Quickly connect people, data, and systems into organized workflows > > Winner of BOSSIE, CODIE, OW2 and Gartner awards > > http://p.sf.net/sfu/Bonitasoft > > _______________________________________________ > > Maximadiscuss mailing list > > Maximadiscuss@... > > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > >  > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Dimiter Prodanov <dimiterpp@gm...>  20140629 10:24:43

Dear all, I have a problem with the following rule (matchdeclare (u, atom, fn, symbolp), defrule (ddint21, 'integrate(delta(u)*fn(u), u, minf, inf), fn(0)) ); >> ddint21('integrate(delta(u)*fn(u), u, minf, inf)); output false should be fn(0) I tried playing around relaxing the match but even with true true it doesn't work. Any ideas? best regards, Dimiter 
From: Richard Fateman <fateman@be...>  20140629 05:40:55

These are not fixes. At best they move the bugs/features. The failure remains as a failure in referential transparency because of the transfinite numbers. Let's define f(x):= x^2/x. Maxima simplifies f(z) to z. For all z. except this is a lie for some values of z that one can imagine, like inf, und, minf, and (depending on how you define them) intervals. so if you choose to do arithmetic on infs, most of the rest of the system becomes broken. Inf (etc) are not numbers. They are handy notations for limits and such. But patches such as making 0*inf be und will not work unless you simplify 0*x to "if transfinite(x) then und else 0" or some such thing. RJF On 6/28/2014 4:31 PM, Robert Dodier wrote: > On 20140628, Dimiter Prodanov <dimiterpp@...> wrote: > >>>> 0*minf >> 0 >> should be undefined >> >>>> 0*inf >> 0 >> should be undefined >> >>>> 0*infinity; >> 0 >> should be undefined > I agree that these are all bugs and we should simplify such expressions > as suggested. > >> On the other hand, in NonStandard analysis/ Infinitesimal calculus the >> results can be OK. > Maxima had better stick to standard analysis  heaven knows we have > enough trouble as it is .... > > best > > Robert Dodier > > >  > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20140629 01:35:11

The "obvious" thing as far as I'm concerned is to simplify to und or whatever. s On Jun 28, 2014 7:30 PM, "Robert Dodier" <robert.dodier@...> wrote: > On 20140628, Stavros Macrakis <macrakis@...> wrote: > > > Even though the Maxima manual never claims you can perform arithmetic on > > nonfinite numbers, many users come across these cases and find the > result > > unsatisfactory. > > > > So I think we ought to have them act in the obvious way. > > > > Yes, we could potentially do something more sophisticated, but "le mieux > > est l'ennemi du bien". > > ?? I'm honestly puzzled  are you arguing for maintaining the status > quo or against it? > > best > > Robert Dodier > > > >  > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: 本田康晃 <yasuaki.honda@gm...>  20140629 00:00:16

Dear Thanh Xuan NGUYEN san, Sorry that I did not notice this thread and failed to respond promptly. I will take a look into this issue and hopefully fix it in the next release (MoA 2.4). You can access the entire source code at https://github.com/YasuakiHonda/MaximaonAndroid Anyway, thanks for pointing out. Yasuaki Honda, Chiba, Japan 20140502 8:53 GMT+09:00 Thanh Xuan NGUYEN <thanhnguyen20080616@...>: > Thank you, Leo and Robert! I will report the issue to the maintainers of > the app MaximaonAndroid. > > Kind regards, > > Thanh > Vào 02052014 01:48, "Robert Dodier" <robert.dodier@...> đã viết: > > On 20140430, Thanh Xuan NGUYEN <thanhnguyen20080616@...> wrote: >> >> > (%i1) file_search_maxima; >> > >> >  >> > Missing close brace >> > >> > $.{mac,mc}} , \text{/tmp/.maxima/ >> > >> > Extra close brace or missing open brace >> >> The value to be displayed contains curly braces, which have a special >> meaning to the markup system (TeX? I don't know). The display system >> should have sanitized the output by preceding any curly braces with >> a backslash or something. Can you please report this to the maintainer >> of the MaximaonAndroid package. >> >> best >> >> Robert Dodier >> >> >> >>  >> "Accelerate Dev Cycles with Automated CrossBrowser Testing  For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform >> available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> > > >  > "Accelerate Dev Cycles with Automated CrossBrowser Testing  For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Robert Dodier <robert.dodier@gm...>  20140628 23:40:12

On 20140628, Dimiter Prodanov <dimiterpp@...> wrote: > _unit(x):= ( > if x<0 then (0) else > if x=0 then (1/2) else > if x>0 then (1) > )$ Careful  a = b is true iff a and b are identical expressions. But 0 is not the same expression as 0.0. Perhaps you want equal(x, 0) instead. best Robert Dodier 