Re: [Maxima-discuss] Functions of non-finite objects; WAS bugs related to infinity ?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Yes, we've discussed labelled non-finites 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 inf-inf => 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 <fa...@be...>
wrote:

>  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...>
> 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...>
>> 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...> 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...
>>> > 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...
>>> 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...
>> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>>
>>
>
>

Re: [Maxima-discuss] Functions of non-finite objects; WAS bugs related to infinity ?

Computer Algebra System written in Common Lisp

Re: [Maxima-discuss] Functions of non-finite objects; WAS bugs related to infinity ?