From: Richard F. <fa...@be...> - 2014-06-29 21:29:47
|
On 6/29/2014 2:13 PM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: > Disallowing arithmetic on non-finite 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 over-pessimistic. But > for now, where the simplifier is ignorant of non-finite things, we are > doing over-optimistic 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 single-argument '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 x-y is 0. (or maybe interval(0,0)). However, if label1 and label2 are different, x-y 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 single-argument 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 non-finite.) 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 <fa...@be... > <mailto:fa...@be...>> 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 floating-point 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 arithmetic-on-constants? > > 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 >> <fa...@be... <mailto:fa...@be...>> 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 2014-06-28, Dimiter Prodanov <dim...@gm... >> <mailto:dim...@gm...>> 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 Non-Standard 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 >> > _______________________________________________ >> > Maxima-discuss mailing list >> > Max...@li... >> <mailto:Max...@li...> >> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss >> >> >> ------------------------------------------------------------------------------ >> 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 >> _______________________________________________ >> Maxima-discuss mailing list >> Max...@li... >> <mailto:Max...@li...> >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss >> >> > > > ------------------------------------------------------------------------------ > 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 > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > <mailto:Max...@li...> > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > |