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}
(350) 
_{Dec}
(359) 

2015 
_{Jan}
(267) 
_{Feb}
(220) 
_{Mar}
(311) 
_{Apr}
(269) 
_{May}
(98) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: Jaime Villate <villate@fe...>  20150504 10:14:37

On 04052015 08:52, Pankaj Sejwal wrote: > Extract from book: > "An implementation of algorithms from Chapters 8 to 10 and part of > Chapter 11 has been written in Maxima by Fabrizio Caruso in the SARAG > library. SARAG is part of the standard Maxima distribution. Thanks for this information. There is a manual for SARAG in the file https://sourceforge.net/p/maxima/code/ci/master/tree/share/contrib/sarag/readme.txt It would be nice to transform that file into a texinfo file and included it in the manual (and update the link to the book which is still pointing to the first edition). Anyone with some free time to contribute to the project? (I have other tasks pending but am willing to review the texinfo file and incorporate it into the reference manual if someone else creates it) Regards, Jaime 
From: Pankaj Sejwal <pankajsejwal@gm...>  20150504 07:53:20

On Mon, May 4, 2015 at 3:11 AM, < maximadiscussrequest@...> wrote: > Message: 6 > Date: Sun, 03 May 2015 14:41:42 0700 > From: Richard Fateman <fateman@...> > Subject: Re: [Maximadiscuss] Inequality testing > To: maximadiscuss@... > MessageID: <55469616.5070901@...> > ContentType: text/plain; charset="windows1252" > > This is a geometric computation that can be done > algebraically, if all the constraints are algebraic (polynomial) > inequalities. > Cylindrical Algebraic Decomposition. > > If the constraints include, exp, log, trig, etc., dunno. > > If the constraints are LINEAR, the solution is, I think, already > programmed for Maxima. > > The heuristics and just fiddling around might be needed in the "dunno" > case. But not the others. > > Is there anyone out there that can confirm the statements above? Or > deny them authoritatively? > > RJF > There is a book "Algorithms in real algebraic geometry" by Sugata,Richard and Merie which towards its end explains CAD. Also probably not known to most of us, there is some part of it already coded for Maxima and available as standard package. Extract from book: "An implementation of algorithms from Chapters 8 to 10 and part of Chapter 11 has been written in Maxima by Fabrizio Caruso in the SARAG library. SARAG is part of the standard Maxima distribution.For most of the algorithms presented in Chapter 13 to 16, there is no implementation at all. The reason for this situation is that the methods developed are well adapted to complexity results but are not adapted to efficient implementation." Book is available with a note from authors: According to our contract with SpringerVerlag, we have the right to post updated versions of the second edition of the book [21] on our websites since January 2008. (SO ITS LEGAL) http://perso.univrennes1.fr/mariefrancoise.roy/bpred2posted2.pdf Hope this info is helpful to everyone who is interested in CAD.  Regards, Pankaj Sejwal ____________________________________________________ "The more I read, the more I acquire, the more certain I am that I know nothing.”  Voltaire 
From: <daiyanh@ya...>  20150504 07:48:08

Never had problems compiling Maxima until now. Build stops at ixlink error I can’t comprehend ^^; Any change made to the build script for Windows? I’m too lazy to check the source myself ^^; BTW ECL is Embeddable CL, and Win version says 13.4.1 though the official number is 13.5.1, go figure. Sent from Windows Mail 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20150504 06:54:33

(reposting, truncating quoted messages because of annoyingly tiny limit on message size  can we fix that?) Mike, Why don't you go ahead and implement this? I would recommend that you start simple: the arithmetic functions (including ^) and monotonic functions (log, exp, atan, erf, sinh, tanh, floor, ceiling, etc.). Then functions which have a small number of 'interesting' monotonic sections: abs, signum, cosh, maybe gamma/factorial for arg > 1.47/0.47 <http://oeis.org/A030169>;, etc. Then maybe multiargument monotonics (min, max). Finally, periodic functions like sin/cos/tan. The cases where you do a more global analysis — not just bottomup — may also be useful, but I would defer those, except for univariate polynomials with numeric coefficients. Just doing that will handle a huge number of useful cases for users. And as Fateman says, in symbolic calculations, bigger or more complicated cases will probably return large, unwieldy, and probably not very useful results. There are some parts that will require a bit of investigation. For example, I don't think there is an existing function to extract all the lower/upper bounds of a number from the 'assume' database. So the hardest part may be simply value_range(x)! s On Sun, May 3, 2015 at 10:31 AM, Mike Valenzuela <mickle.mouse@...> wrote: > Hello all again, > > I've been trying to put together a rule list for working with > inequalities, especially for testing, so I put together some rules (they > need double, triple, etc. checking). I got pretty tired so I don't even > know if this mailing list will understand what I wrote. I suspect these > rules can be vastly improved, probably compressed, and overall made more > accurate and complete. This is sort of a work in progress and is not even > ready for Maxima, so I haven't even moved this to git yet. I just do not > want to invest anymore time into this project if someone already has a > solution. If no one has a better solution for testing inequalities, then > maybe the following text could be converted into test cases and eventually > a lisp or Maxima routine can be written. > .... > 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20150504 06:44:38

Mike, Why don't you go ahead and implement this? I would recommend that you start simple: the arithmetic functions (including ^) and monotonic functions (log, exp, atan, erf, sinh, tanh, floor, ceiling, etc.). Then functions which have a small number of 'interesting' monotonic sections: abs, signum, cosh, maybe gamma/factorial for arg > 1.47/0.47 <http://oeis.org/A030169>;, etc. Then maybe multiargument monotonics (min, max). Finally, periodic functions like sin/cos/tan. The cases where you do a more global analysis — not just bottomup — may also be useful, but I would defer those, except for univariate polynomials with numeric coefficients. Just doing that will handle a huge number of useful cases for users. And as Fateman says, in symbolic calculations, bigger or more complicated cases will probably return large, unwieldy, and probably not very useful results. There are some parts that will require a bit of investigation. For example, I don't think there is an existing function to extract all the lower/upper bounds of a number from the 'assume' database. So the hardest part may be simply value_range(x)! s On Sun, May 3, 2015 at 10:31 AM, Mike Valenzuela <mickle.mouse@...> wrote: > Hello all again, > > I've been trying to put together a rule list for working with > inequalities, especially for testing, so I put together some rules (they > need double, triple, etc. checking). I got pretty tired so I don't even > know if this mailing list will understand what I wrote. I suspect these > rules can be vastly improved, probably compressed, and overall made more > accurate and complete. This is sort of a work in progress and is not even > ready for Maxima, so I haven't even moved this to git yet. I just do not > want to invest anymore time into this project if someone already has a > solution. If no one has a better solution for testing inequalities, then > maybe the following text could be converted into test cases and eventually > a lisp or Maxima routine can be written. > > > I release the following mistake ridden ramblings of a tired crazy person > under the GPL3 license. (I don't even know if I have to say as much). > /* Revisions to do: */ > /* > * > * To extend the following to multiple intervals, perform it on each > interval one at a time > * > * Unless stated bounds are (inf,inf) > * > * pedantic_flag = true by default, but may be set to false to allow 0^0 = > 1. > * > * TODO Add power support > * what if lower_bound=upper_bound? Should we error on (4,4] and [4,4) > or treat it as [4,4]? > * > * Note all power laws here assume lower_bound and upper_bound refer to > the base's lower and upper bounds > * if exponent is a positive, even integer > * if lower_bound is (negative OR nonpositive) AND upper_bound is > (positive OR nonnegative): > * lower_bound=0; //the interval includes zero > * lower_bound_type=closed; > * if( abs(lower_bound) > abs(upper_bound)){upper_bound = > abs(lower_bound)^exponent; upper_bound_type = lower_bound_type} > * if( abs(lower_bound) < abs(upper_bound)){upper_bound = > abs(upper_bound)^exponent; upper_bound_type = upper_bound_type} > * if( abs(lower_bound) = abs(upper_bound)){upper_bound = > abs(upper_bound)^exponent; upper_bound_type = Closing(lower_bound_type, > upper_bound_type) } > * if lower_bound is (nonnegative OR positive) AND upper_bound is > (nonnegative OR positive) > * lower_bound = lower_bound^exponent; > upper_bound=lower_bound^exponent; lower_bound_type=lower_bound_type; > upper_bound_type = upper_bound_type; > * if lower_bound is (negative OR nonpositive) AND upper_bound is > (negative OR nonpositive) > * lower_bound = abs(upper_bound)^exponent; > upper_bound=abs(lower_bound); Swap(lower_bound_type, upper_bound_type); > * if exponent is a symbol and a positive integer, (not a concrete > number), > * if lower_bound >= 1, optionally "flatten" even exponents to 2. > * if 0>=lower_bound>1, optionally "flatten" the lower bound to 0 > (large exponents will push the new lower_bound toward 0). > * > * if exponent is a nonnegative, even integer //now we have to worry > about 0^0 > * if anything is potentially zero (zero, nonnegative, nonpositive) > AND pedantic_flag : error "0^0" is undefined > * if lower_bound is negative and upper_bound is positive : > * lower_bound=0; //the interval includes zero > * lower_bound_type=closed; > * if( abs(lower_bound) > abs(upper_bound)){upper_bound = > abs(lower_bound)^exponent; upper_bound_type = lower_bound_type} > * if( abs(lower_bound) < abs(upper_bound)){upper_bound = > abs(upper_bound)^exponent; upper_bound_type = upper_bound_type} > * if( abs(lower_bound) = abs(upper_bound)){upper_bound = > abs(upper_bound)^exponent; upper_bound_type = Closing(lower_bound_type, > upper_bound_type) } > * if lower_bound and upper_bound are both positive > * lower_bound = lower_bound^exponent; > upper_bound=lower_bound^exponent; lower_bound_type=lower_bound_type; > upper_bound_type = upper_bound_type; > * if lower_bound and upper_bound are both negative > * lower_bound = abs(upper_bound)^exponent; > upper_bound=abs(lower_bound)^exponent; Swap(lower_bound_type, > upper_bound_type); > * if exponent is a symbol and a nonnegative integer, (not a concrete > number), optionally "flatten" exponent > * lower_bound = min(lower_bound, 1); upper_bound = max(1, > upper_bound) > * if lower_bound=1, lower_bound_type=closed; if upper_bound=1, > upper_bound_type = closed; > * > * if exponent is positive, odd (integer) > * lower_bound = lower_bound^exponent; upper_bound = > upper_bound^exponent; > * lower_bound_type = lower_bound_type; upper_bound_type = > upper_bound_type; > * if exponent is a symbol and a positive integer, (not a concrete > number), optionally "flatten" the exponent > * if lower_bound>=1, we may optionally replace the exponent with > 1. Large exponents will cause the bound to grow, so the current bound is > least. > * if 0 < lower_bound< 1, lower_bound=0, lower_bound_type=open. Large > exponents will shrink the bounds toward zero. > * if 1 < lower_bound< 0, we may optionally replace the exponent with > 1. Larger exponents will only cause the bound to grow towards zero, so the > current bound is least. > * if lower_bound<1, lower_bound=inf, lower_bound_type=open. > Larger exponents will only cause the bound to grow towards negative > infinity. > * if upper_bound<=1, we may optionally replace the exponent > with 1. Large exponents will cause the bound to grow more negative, so the > current bound is greatest. > * if 1 < upper_bound< 0, upper_bound=0, upper_bound_type=open. > Large exponents will cause the bound to grow toward zero. > * if 0 < upper_bound< 1, we may optionally replace the exponent > with 1. Large exponents will cause the bound to grow more negative, so the > current bound is greatest. > * if 1 < upper_bound , upper_bound=+inf, upper_bound_type=open. > Large exponents will cause the bound to grow towards infinity. > * > * if exponent is negative AND the base's interval includes zero AND > pedantic_flag : invalid > * if exponent is negative AND the base's interval includes zero AND NOT > pedantic_flag : split the interval, removing zero from it, and continue > * if exponent is even, negative integer AND the base's interval > excludes zero TODO > * if exponent is odd, negative integer AND the base's interval excludes > zero TODO > * if exponent is a symbol, even negative integer, optionally "flatten" > TODO > * if exponent is a symbol, odd negative integer, optionally "flatten" > TODO > * if exponent is zero and base nonzero : identically 1 > * if exponent is zero and base zero : invalid > * Add abs value support > * if lower bound is positive > nothing changes > * if lower bound is negative and upper bound is positive > [0,upper > bound] (upper bound type remains the same) > * if lower bound is negative and upper bound is negative > > ([upper_bound, lowerbound]) (flip the bounds basically) > * > * METHODS USED ABOVE > * Closing(lower_bound_type, upper_bound_type){ > if(lower_bound_type==closed){return closed} > if(upper_bound_type==closed){return closed} else {return open} } > * > */ > > > /* in C`esque pseudo code, altered in ways to make it more clear, > hopefully */ > > bool[6] determine_signs(expr){ /*Returns a list of Booleans: neg, > negzero, zero, poszero, positive, and unknown (unknown not required)*/ > /* Yes I know it is bad practice allocate memory within a method without > freeing that object in the same method */ > bool[] expression_signs = calloc( sizeof(int) ); /*allocating less than > an int can be inefficient, calloc zeros the memory*/ > unsigned int numnegs = 0; > > /* if this is a basecase, an atom */ > if( is_atom(expression) ){ > expressions_signs = assumption_lookup(atom); > } > > for(i=1; i<=max_parts; i++){ > bool[6] local_signs = determine_signs(part(expr,i)); > expression_signs = expression_signs OR local_signs; /* do for neg, > negzero, zero, poszero, positive, and unknown */ > if( local_signs::neg OR local_signs::negzero ){ numnegs= numnegs+1; } > free(local_signs); /* Yes I know it is bad practice allocate and free > memory this way */ > } > > /* if the expression was empty or invalid */ > if(NOT(expression_signs)){ /*If the entire zero'ed memory is still > zeroed */ > *expression_signs::unknown = 1; > return(expression_signs); > } > > /* if its addition */ > if part(expr, 0) = '+'{ > /* unknown or conflicting signs */ > if(expression_signs::unknown OR > (( expression_signs::neg OR expression_signs::negzero) AND > (expression_signs::pos OR expression_signs::poszero))){ > *expression_signs = 0; > *expression_signs::unknown = 1; > return(expression_signs); > } > /* Everything that follows assumes the signs are not unknown or > conflicting */ > > /* is anything strictly negative? If so then we can clear the zero and > negzero bits */ > if(expression_signs::neg){ > *expression_signs::zero = 0; > *expression_signs::negzero = 0; > } > > /* is anything strictly positive? If so then we can clear the zero and > poszero bits */ > if(expression_signs::neg){ > *expression_signs::zero = 0; > *expression_signs::poszero = 0; > } > } > > /* if its multiplication */ > If part(expr, 0) = '*'{ > /* unknown or conflicting signs */ > if(expression_signs::unknown){ > *expression_signs = 0; > *expression_signs::unknown = 1; > return(expression_signs); > } > /* If there is an even number of negative terms */ > if( is_even(numnegs) ){ > /* And if there are zeros of any sort > if( express_signs::negzero OR express_signs::zero OR > express_signs::poszero ){ > /* positive or zero */ > *express_signs = 0; > *express_signs::poszero = 1; > } > else{ /* no zeros were possible */ > /* positive */ > *express_signs = 0; > *express_signs::pos = 1; > } > } > /* If there is an odd number of negative terms */ > else { > /* And if there are zeros of any sort > if( express_signs::negzero OR express_signs::zero OR > express_signs::poszero ){ > /* negative or zero */ > *express_signs = 0; > *express_signs::negzero = 1; > } > else{ /* no zeros were possible */ > /* negative */ > *express_signs = 0; > *express_signs::neg = 1; > } > } > } > return(express_signs) > } > > > On Sat, May 2, 2015 at 11:13 PM, Mike Valenzuela <mickle.mouse@...> > wrote: > >> Oh another example of a Maxima not figuring out inequalities well: >> >> assume(a>=0, b>=0, a<=1, b<=1)$ >> assume(m>4)$ >> is(a1 <= 0); >> is(b*(a1) <= 0); >> is(b*2 <= 2); >> is(b*2  2 <= 0); >> is(b*(a1) + 2  2<=0); >> is(b*(a1) + (b*2  2) <=0); >> true >> true >> true >> true >> true >> unknown >> >> The last answer should be true, because the sum of any nonpositive terms >> is still nonpositive. Although I can find these cases, I am having trouble >> figuring out how Maxima should solve this kind of problem. At least for >> multiplication and addition I think this can be solved. >> >> I'm thinking about ways to improve Maxima's capabilities. >> >> >> On Sat, May 2, 2015 at 7:19 PM, Mike Valenzuela <mickle.mouse@...> >> wrote: >> >>> Hello again, >>> >>> Sorry for posting so many questions, but I've been trying to solve a >>> rather difficult problem and I'm taking several approaches. Anyways I've >>> found a few "issues" with inequality testing. >>> >>> (%i1) load(ineq)$ >>> (%i2) assume(a>=0, b>=0, a<=1, b<=1)$ >>> (%i3) is(a*b >= 0); >>> (%o3) true >>> (%i4) is(a*b <= 1); >>> (%o4) unknown >>> (%i5) is( 1(a*b) >= 0); >>> (%o5) unknown >>> (%i6) (a * b >=0), pred; >>> (%o6) true >>> (%i7) (a * b <=1), pred; >>> (%o7) a*b<=1 >>> I would expect that if a<=X and b<=Y, then a*b<=X*Y, but Maxima cannot >>> figure that out. Annoying but at least it is not giving a strictly wrong >>> answer. >>> >>> And someone else once complained about the following: >>> (%i8) declare(k, integer)$ >>> (%i9) assume(k>1)$ >>> (%i10) is(k^2>k); >>> (%o10) true >>> (%i11) is(k^2 + 1 > k); >>> (%o12) unknown >>> (%i12) k^2+1 > k, pred; >>> (%o12) k^2+1>k >>> Again, this is annoying, but not strictly wrong. Yes, we can figure it >>> out, but Maxima cannot. I can even think of cases where if (a>b) then not >>> a+1>b, but this requires working with modulus arithmetic or finite fields >>> or something like that. But in this case k was declared an integer. >>> >>> Is there some other package to expand Maxima's inequality testing? >>> >>> >> > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Robert Dodier <robert.dodier@gm...>  20150504 06:12:43

On 20150503, Dimiter Prodanov <dimiterpp@...> wrote: > %top_simp_hook:[ ]; > > reg_simprule(rname, aa, bb)::=buildq([rname], > block( defrule(rname, aa, bb), > %top_simp_hook:cons(rname, %top_simp_hook) > ) > ); > > and then apply them in the top level simplification. > > Do you think this is feasible? Yes, it seems like this should work. I assume that the toplevel function will be modified to apply the rules listed in %top_simp_hook. I think it's preferable that the toplevel function will simply call apply(apply1, cons (stuff, %top_simp_hook)), i.e., let apply1 handle the business about how to apply all the rules. Although that immediately leads to a question about why it should be apply1 and not applyb1 or apply2, which are also reasonable choices. best, Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20150504 06:06:31

On 20150503, Jaime Villate <villate@...> wrote: > I used the Wiki, just to experiment with it, but I could have created > the same page directly into the Website, with about the same effort. I > would like to hear opinions about whether to keep using the Wiki for the > change logs or to move them to the Website. Hey, that's terrific. Very nice to have links to bug reports etc. I don't have a preference for the wiki versus the website. best, Robert Dodier 
From: Robert Dodier <robert.dodier@gm...>  20150504 05:58:24

On 20150503, Mike Valenzuela <mickle.mouse@...> wrote: > I release the following mistake ridden ramblings of a tired crazy person > under the GPL3 license. (I don't even know if I have to say as much). Thanks for posting the code. It is absolutely a good idea to paste an explicit license notice on it (under any terms you wish). That makes it easy for others to determine if they can use your code. In the absence of a license notice, others have to fall back on guesswork to infer your intent and their rights, etc.  why not save them the trouble. best, Robert Dodier 
From: Raymond Toy <toy.raymond@gm...>  20150504 05:02:11

On Sun, May 3, 2015 at 9:25 PM, Richard Fateman <fateman@...> wrote: > There is a huge literature on interval arithmetic, more recently > sometimes with the more general concept of "reliable computation". > The notion of extending it from pairs of explicit numbers to symbolic > endpoints > may seem feasible and plausible, but on slightly closer examination it is > apparent > that it does not sustain repeated operations on the data without becoming > so unwieldy as to be useless. > > There is an IEEE proposed standard for interval arithmetic (P 1788) in > progress, > and a variety of implementations, some of which could be immediately > plugged > in to a Maxima which permitted foreign function calls. > > MPFRI for example. > > It would require a substantial effort to put all this into the right > places in Maxima, > though. If Maxima were written in an objectoriented fashion, it might be > much > easier. > > But numbers for endpoints. > If numbers are endpoints, the compilers for cmucl and sbcl have interval arithmetic to support type derivation. They support basic operations and also special functions. Trig functions aren't supported so well due to periodicity (due to lack of developer desire?), but the other special functions should be well supported. The compiler even knows that x*x is always positive. > > RJf > > > > On 5/3/2015 5:19 PM, Mike Valenzuela wrote: > > There is also the question of how much work do we want the user to have to > do and how easily understood the answers. > > A large class of functions can have their intervals computed. According > to the wikipedia (not really an authoritative source, but often at least > links to http://dx.doi.org/10.1511%2F2003.6.484), intervals of any > piecewise monotonic function, and a fair number of nonlinear functions are > at least piecewise monotonic: > > " > More generally, one can say that for piecewise monotonic functions it is > sufficient to consider the endpoints x_1, x_2 of the interval [x_1, x_2], > together with the socalled critical points within the interval being those > points where the monotonicity of the function changes direction. > > For the sine and cosine functions, the critical points are at (1/2 + > n)*pi or n*pi for all n in \mathbb{Z} respectively. Only up to five points > matter as the resulting interval will be [1,1] if the interval includes at > least two extrema. For sine and cosine, only the endpoints need full > evaluation as the critical points lead to easily precalculated values – > namely 1, 0, +1. > " > > So most (all?) of the common and elementary functions in Maxima can > support interval arithmetic as long as all critical points can be > identified. The problem would be the overly complicated answer to problems > like: when_is(sin(a) > sin(b)). This has a tedious closedform answer using > all the critical points. > > This could also be problematic when a user wants to specify a new > function and determine intervals involving that function. I guess we could > automatically determine the critical points. When dealing with functions of > multiple random variables, we have to be careful of these critical points. > These critical points appear when the determinant of the Jacobian becomes > zero. I believe the determinant of the Jacobian going to zero is > sufficient, but not necessary for critical points (consider the 1D > function: y=x^3). > > > Another thought I had was the "flattening" of symbolic variables. If > h(a,b) has the interval [f(a,b), g(a,b)], and we wish to remove the > dependence on b, then we have to worry about the minimum(f(a,b), w.r.t b) > and the maximum(g(a,b), w.r.t. b). This feels like a nice optional > feature. The more is known about b (the tighter the interval), the less the > interval widens. > > > One final thought, which is mostly just for fun. A superheavy weight > method to determine the interval, of piecewise monotonic functions of > intervals, is to use random variable algebra. Let interval (or intervals) > be a uniform distribution (or mixture of uniform distributions). Unbounded > intervals may use the exponential or Gaussian distributions. Then let Y > equal the expression, where we desire the expression's interval. Solve for > Y's pdf. This commonly uses the absolute value of the determinant of the > Jacobian (hence the piecewise monotone requirement is still there). The > interval of the expression is the support of Y. This is way more work than > necessary, but the pw.mac can mostly automate handling the piecewise > integration commonly required if two or more intervals are interacting. I > liken this to using a tractor to hammer in a nail. Like I said, fun! > > > On Sun, May 3, 2015 at 2:58 PM, Stavros Macrakis (Σταῦρος Μακράκης) < > macrakis@...> wrote: > >> Barton implements the linear case in %solve using FourierMotzkin (as I >> already mentioned). This can be very (exponentially?) slow in general. We >> have generally avoided using slow algorithms in basic Maxima operations. >> Maybe we can use FM by default, and turn it off with (yet another :( ) >> flag. >> >> Maxima does a very poor job in even extremely elementary cases: >> >>  Maxima doesn't even know that atan(x)<2 for all (real) x. >>  It doesn't even know if you restrict to 1 < x < 1. This does not >> require any subtlety. >>  is(sin(x)<=1+2^52) => true; but is(sin(x)+2^53) => unknown; >> where of course is(sin(x)<=1) should be true. Somehow floating point is >> sneaking in inappropriately. >>  is(sin(x)^2)<2 => unknown (let alone <=1) >>  Maxima does not use realroots for univariate polynomials. >> assume(r>0,r<1)  sign(r^21) => neg (correct), but sign(r^22) => pnz ! >> Realroots, though a numerical method, provides guarantees about its results >> which are suitable for cases like this. >> >> Going beyond all this is gravy. >> >> On Sun, May 3, 2015 at 11:41 PM, Richard Fateman <fateman@...> >> wrote: >> >>> This is a geometric computation that can be done >>> algebraically, if all the constraints are algebraic (polynomial) >>> inequalities. >>> Cylindrical Algebraic Decomposition. >>> >>> If the constraints include, exp, log, trig, etc., dunno. >>> >>> If the constraints are LINEAR, the solution is, I think, already >>> programmed for Maxima. >>> >>> The heuristics and just fiddling around might be needed in the "dunno" >>> case. But not the others. >>> >>> Is there anyone out there that can confirm the statements above? Or >>> deny them authoritatively? >>> >>> RJF >>> >>> >>> >>> On 5/2/2015 11:13 PM, Mike Valenzuela wrote: >>> >>> Oh another example of a Maxima not figuring out inequalities well: >>> >>> assume(a>=0, b>=0, a<=1, b<=1)$ >>> assume(m>4)$ >>> is(a1 <= 0); >>> is(b*(a1) <= 0); >>> is(b*2 <= 2); >>> is(b*2  2 <= 0); >>> is(b*(a1) + 2  2<=0); >>> is(b*(a1) + (b*2  2) <=0); >>> true >>> true >>> true >>> true >>> true >>> unknown >>> >>> The last answer should be true, because the sum of any nonpositive >>> terms is still nonpositive. Although I can find these cases, I am having >>> trouble figuring out how Maxima should solve this kind of problem. At least >>> for multiplication and addition I think this can be solved. >>> >>> I'm thinking about ways to improve Maxima's capabilities. >>> >>> >>> On Sat, May 2, 2015 at 7:19 PM, Mike Valenzuela <mickle.mouse@...> >>> wrote: >>> >>>> Hello again, >>>> >>>> Sorry for posting so many questions, but I've been trying to solve a >>>> rather difficult problem and I'm taking several approaches. Anyways I've >>>> found a few "issues" with inequality testing. >>>> >>>> (%i1) load(ineq)$ >>>> (%i2) assume(a>=0, b>=0, a<=1, b<=1)$ >>>> (%i3) is(a*b >= 0); >>>> (%o3) true >>>> (%i4) is(a*b <= 1); >>>> (%o4) unknown >>>> (%i5) is( 1(a*b) >= 0); >>>> (%o5) unknown >>>> (%i6) (a * b >=0), pred; >>>> (%o6) true >>>> (%i7) (a * b <=1), pred; >>>> (%o7) a*b<=1 >>>> I would expect that if a<=X and b<=Y, then a*b<=X*Y, but Maxima cannot >>>> figure that out. Annoying but at least it is not giving a strictly wrong >>>> answer. >>>> >>>> And someone else once complained about the following: >>>> (%i8) declare(k, integer)$ >>>> (%i9) assume(k>1)$ >>>> (%i10) is(k^2>k); >>>> (%o10) true >>>> (%i11) is(k^2 + 1 > k); >>>> (%o12) unknown >>>> (%i12) k^2+1 > k, pred; >>>> (%o12) k^2+1>k >>>> Again, this is annoying, but not strictly wrong. Yes, we can figure >>>> it out, but Maxima cannot. I can even think of cases where if (a>b) then >>>> not a+1>b, but this requires working with modulus arithmetic or finite >>>> fields or something like that. But in this case k was declared an integer. >>>> >>>> Is there some other package to expand Maxima's inequality testing? >>>> >>>> >>> >>> >>>  >>> One dashboard for servers and applications across PhysicalVirtualCloud >>> Widest outofthebox monitoring support with 50+ applications >>> Performance metrics, stats and reports that give you Actionable Insights >>> Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> >>> >>> >>> _______________________________________________ >>> Maximadiscuss mailing listMaximadiscuss@...nethttps://lists.sourceforge.net/lists/listinfo/maximadiscuss >>> >>> >>> >>> >>>  >>> One dashboard for servers and applications across PhysicalVirtualCloud >>> Widest outofthebox monitoring support with 50+ applications >>> Performance metrics, stats and reports that give you Actionable Insights >>> Deep dive visibility with transaction tracing using APM Insight. >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> _______________________________________________ >>> Maximadiscuss mailing list >>> Maximadiscuss@... >>> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >>> >>> >> >> >>  >> One dashboard for servers and applications across PhysicalVirtualCloud >> Widest outofthebox monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> >> > > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > >  Ray 
From: Richard Fateman <fateman@be...>  20150504 04:50:26

There is a huge literature on interval arithmetic, more recently sometimes with the more general concept of "reliable computation". The notion of extending it from pairs of explicit numbers to symbolic endpoints may seem feasible and plausible, but on slightly closer examination it is apparent that it does not sustain repeated operations on the data without becoming so unwieldy as to be useless. There is an IEEE proposed standard for interval arithmetic (P 1788) in progress, and a variety of implementations, some of which could be immediately plugged in to a Maxima which permitted foreign function calls. MPFRI for example. It would require a substantial effort to put all this into the right places in Maxima, though. If Maxima were written in an objectoriented fashion, it might be much easier. But numbers for endpoints. RJf On 5/3/2015 5:19 PM, Mike Valenzuela wrote: > There is also the question of how much work do we want the user to > have to do and how easily understood the answers. > > A large class of functions can have their intervals computed. > According to the wikipedia (not really an authoritative source, but > often at least links to http://dx.doi.org/10.1511%2F2003.6.484), > intervals of any piecewise monotonic function, and a fair number of > nonlinear functions are at least piecewise monotonic: > > " > More generally, one can say that for piecewise monotonic functions it > is sufficient to consider the endpoints x_1, x_2 of the interval [x_1, > x_2], together with the socalled critical points within the interval > being those points where the monotonicity of the function changes > direction. > > For the sine and cosine functions, the critical points are at (1/2 + > n)*pi or n*pi for all n in \mathbb{Z} respectively. Only up to five > points matter as the resulting interval will be [1,1] if the interval > includes at least two extrema. For sine and cosine, only the endpoints > need full evaluation as the critical points lead to easily > precalculated values – namely 1, 0, +1. > " > > So most (all?) of the common and elementary functions in Maxima can > support interval arithmetic as long as all critical points can be > identified. The problem would be the overly complicated answer to > problems like: when_is(sin(a) > sin(b)). This has a tedious > closedform answer using all the critical points. > > This could also be problematic when a user wants to specify a new > function and determine intervals involving that function. I guess we > could automatically determine the critical points. When dealing with > functions of multiple random variables, we have to be careful of these > critical points. These critical points appear when the determinant of > the Jacobian becomes zero. I believe the determinant of the Jacobian > going to zero is sufficient, but not necessary for critical points > (consider the 1D function: y=x^3). > > > Another thought I had was the "flattening" of symbolic variables. If > h(a,b) has the interval [f(a,b), g(a,b)], and we wish to remove the > dependence on b, then we have to worry about the minimum(f(a,b), w.r.t > b) and the maximum(g(a,b), w.r.t. b). This feels like a nice optional > feature. The more is known about b (the tighter the interval), the > less the interval widens. > > > One final thought, which is mostly just for fun. A superheavy weight > method to determine the interval, of piecewise monotonic functions of > intervals, is to use random variable algebra. Let interval (or > intervals) be a uniform distribution (or mixture of uniform > distributions). Unbounded intervals may use the exponential or > Gaussian distributions. Then let Y equal the expression, where we > desire the expression's interval. Solve for Y's pdf. This commonly > uses the absolute value of the determinant of the Jacobian (hence the > piecewise monotone requirement is still there). The interval of the > expression is the support of Y. This is way more work than necessary, > but the pw.mac can mostly automate handling the piecewise integration > commonly required if two or more intervals are interacting. I liken > this to using a tractor to hammer in a nail. Like I said, fun! > > > On Sun, May 3, 2015 at 2:58 PM, Stavros Macrakis (Σταῦρος Μακράκης) > <macrakis@... <mailto:macrakis@...>> wrote: > > Barton implements the linear case in %solve using FourierMotzkin > (as I already mentioned). This can be very (exponentially?) slow > in general. We have generally avoided using slow algorithms in > basic Maxima operations. Maybe we can use FM by default, and turn > it off with (yet another :( ) flag. > > Maxima does a very poor job in even extremely elementary cases: > > * Maxima doesn't even know that atan(x)<2 for all (real) x. > * It doesn't even know if you restrict to 1 < x < 1. This does > not require any subtlety. > * is(sin(x)<=1+2^52) => true; but is(sin(x)+2^53) => unknown; > where of course is(sin(x)<=1) should be true. Somehow floating > point is sneaking in inappropriately. > * is(sin(x)^2)<2 => unknown (let alone <=1) > * Maxima does not use realroots for univariate polynomials. > assume(r>0,r<1)  sign(r^21) => neg (correct), but > sign(r^22) => pnz ! Realroots, though a numerical method, > provides guarantees about its results which are suitable for > cases like this. > > Going beyond all this is gravy. > > On Sun, May 3, 2015 at 11:41 PM, Richard Fateman > <fateman@... <mailto:fateman@...>> wrote: > > This is a geometric computation that can be done > algebraically, if all the constraints are algebraic > (polynomial) inequalities. > Cylindrical Algebraic Decomposition. > > If the constraints include, exp, log, trig, etc., dunno. > > If the constraints are LINEAR, the solution is, I think, already > programmed for Maxima. > > The heuristics and just fiddling around might be needed in the > "dunno" > case. But not the others. > > Is there anyone out there that can confirm the statements > above? Or > deny them authoritatively? > > RJF > > > > On 5/2/2015 11:13 PM, Mike Valenzuela wrote: >> Oh another example of a Maxima not figuring out inequalities >> well: >> >> assume(a>=0, b>=0, a<=1, b<=1)$ >> assume(m>4)$ >> is(a1 <= 0); >> is(b*(a1) <= 0); >> is(b*2 <= 2); >> is(b*2  2 <= 0); >> is(b*(a1) + 2  2<=0); >> is(b*(a1) + (b*2  2) <=0); >> true >> true >> true >> true >> true >> unknown >> >> The last answer should be true, because the sum of any >> nonpositive terms is still nonpositive. Although I can find >> these cases, I am having trouble figuring out how Maxima >> should solve this kind of problem. At least for >> multiplication and addition I think this can be solved. >> >> I'm thinking about ways to improve Maxima's capabilities. >> >> >> On Sat, May 2, 2015 at 7:19 PM, Mike Valenzuela >> <mickle.mouse@... <mailto:mickle.mouse@...>> wrote: >> >> Hello again, >> >> Sorry for posting so many questions, but I've been trying >> to solve a rather difficult problem and I'm taking >> several approaches. Anyways I've found a few "issues" >> with inequality testing. >> >> (%i1) load(ineq)$ >> (%i2) assume(a>=0, b>=0, a<=1, b<=1)$ >> (%i3) is(a*b >= 0); >> (%o3) true >> (%i4) is(a*b <= 1); >> (%o4) unknown >> (%i5) is( 1(a*b) >= 0); >> (%o5) unknown >> (%i6) (a * b >=0), pred; >> (%o6) true >> (%i7) (a * b <=1), pred; >> (%o7) a*b<=1 >> I would expect that if a<=X and b<=Y, then a*b<=X*Y, but >> Maxima cannot figure that out. Annoying but at least it >> is not giving a strictly wrong answer. >> >> And someone else once complained about the following: >> (%i8) declare(k, integer)$ >> (%i9) assume(k>1)$ >> (%i10) is(k^2>k); >> (%o10) true >> (%i11) is(k^2 + 1 > k); >> (%o12) unknown >> (%i12) k^2+1 > k, pred; >> (%o12) k^2+1>k >> Again, this is annoying, but not strictly wrong. Yes, we >> can figure it out, but Maxima cannot. I can even think of >> cases where if (a>b) then not a+1>b, but this requires >> working with modulus arithmetic or finite fields or >> something like that. But in this case k was declared an >> integer. >> >> Is there some other package to expand Maxima's inequality >> testing? >> >> >> >> >>  >> One dashboard for servers and applications across PhysicalVirtualCloud >> Widest outofthebox monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> >> >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... <mailto:Maximadiscuss@...> >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > >  > One dashboard for servers and applications across > PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you > Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > <mailto:Maximadiscuss@...> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > >  > One dashboard for servers and applications across > PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > <mailto:Maximadiscuss@...> > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Mike Valenzuela <mickle.mouse@gm...>  20150504 00:19:29

There is also the question of how much work do we want the user to have to do and how easily understood the answers. A large class of functions can have their intervals computed. According to the wikipedia (not really an authoritative source, but often at least links to http://dx.doi.org/10.1511%2F2003.6.484), intervals of any piecewise monotonic function, and a fair number of nonlinear functions are at least piecewise monotonic: " More generally, one can say that for piecewise monotonic functions it is sufficient to consider the endpoints x_1, x_2 of the interval [x_1, x_2], together with the socalled critical points within the interval being those points where the monotonicity of the function changes direction. For the sine and cosine functions, the critical points are at (1/2 + n)*pi or n*pi for all n in \mathbb{Z} respectively. Only up to five points matter as the resulting interval will be [1,1] if the interval includes at least two extrema. For sine and cosine, only the endpoints need full evaluation as the critical points lead to easily precalculated values – namely 1, 0, +1. " So most (all?) of the common and elementary functions in Maxima can support interval arithmetic as long as all critical points can be identified. The problem would be the overly complicated answer to problems like: when_is(sin(a) > sin(b)). This has a tedious closedform answer using all the critical points. This could also be problematic when a user wants to specify a new function and determine intervals involving that function. I guess we could automatically determine the critical points. When dealing with functions of multiple random variables, we have to be careful of these critical points. These critical points appear when the determinant of the Jacobian becomes zero. I believe the determinant of the Jacobian going to zero is sufficient, but not necessary for critical points (consider the 1D function: y=x^3). Another thought I had was the "flattening" of symbolic variables. If h(a,b) has the interval [f(a,b), g(a,b)], and we wish to remove the dependence on b, then we have to worry about the minimum(f(a,b), w.r.t b) and the maximum(g(a,b), w.r.t. b). This feels like a nice optional feature. The more is known about b (the tighter the interval), the less the interval widens. One final thought, which is mostly just for fun. A superheavy weight method to determine the interval, of piecewise monotonic functions of intervals, is to use random variable algebra. Let interval (or intervals) be a uniform distribution (or mixture of uniform distributions). Unbounded intervals may use the exponential or Gaussian distributions. Then let Y equal the expression, where we desire the expression's interval. Solve for Y's pdf. This commonly uses the absolute value of the determinant of the Jacobian (hence the piecewise monotone requirement is still there). The interval of the expression is the support of Y. This is way more work than necessary, but the pw.mac can mostly automate handling the piecewise integration commonly required if two or more intervals are interacting. I liken this to using a tractor to hammer in a nail. Like I said, fun! On Sun, May 3, 2015 at 2:58 PM, Stavros Macrakis (Σταῦρος Μακράκης) < macrakis@...> wrote: > Barton implements the linear case in %solve using FourierMotzkin (as I > already mentioned). This can be very (exponentially?) slow in general. We > have generally avoided using slow algorithms in basic Maxima operations. > Maybe we can use FM by default, and turn it off with (yet another :( ) > flag. > > Maxima does a very poor job in even extremely elementary cases: > >  Maxima doesn't even know that atan(x)<2 for all (real) x. >  It doesn't even know if you restrict to 1 < x < 1. This does not > require any subtlety. >  is(sin(x)<=1+2^52) => true; but is(sin(x)+2^53) => unknown; where > of course is(sin(x)<=1) should be true. Somehow floating point is sneaking > in inappropriately. >  is(sin(x)^2)<2 => unknown (let alone <=1) >  Maxima does not use realroots for univariate polynomials. > assume(r>0,r<1)  sign(r^21) => neg (correct), but sign(r^22) => pnz ! > Realroots, though a numerical method, provides guarantees about its results > which are suitable for cases like this. > > Going beyond all this is gravy. > > On Sun, May 3, 2015 at 11:41 PM, Richard Fateman <fateman@...> > wrote: > >> This is a geometric computation that can be done >> algebraically, if all the constraints are algebraic (polynomial) >> inequalities. >> Cylindrical Algebraic Decomposition. >> >> If the constraints include, exp, log, trig, etc., dunno. >> >> If the constraints are LINEAR, the solution is, I think, already >> programmed for Maxima. >> >> The heuristics and just fiddling around might be needed in the "dunno" >> case. But not the others. >> >> Is there anyone out there that can confirm the statements above? Or >> deny them authoritatively? >> >> RJF >> >> >> >> On 5/2/2015 11:13 PM, Mike Valenzuela wrote: >> >> Oh another example of a Maxima not figuring out inequalities well: >> >> assume(a>=0, b>=0, a<=1, b<=1)$ >> assume(m>4)$ >> is(a1 <= 0); >> is(b*(a1) <= 0); >> is(b*2 <= 2); >> is(b*2  2 <= 0); >> is(b*(a1) + 2  2<=0); >> is(b*(a1) + (b*2  2) <=0); >> true >> true >> true >> true >> true >> unknown >> >> The last answer should be true, because the sum of any nonpositive >> terms is still nonpositive. Although I can find these cases, I am having >> trouble figuring out how Maxima should solve this kind of problem. At least >> for multiplication and addition I think this can be solved. >> >> I'm thinking about ways to improve Maxima's capabilities. >> >> >> On Sat, May 2, 2015 at 7:19 PM, Mike Valenzuela <mickle.mouse@...> >> wrote: >> >>> Hello again, >>> >>> Sorry for posting so many questions, but I've been trying to solve a >>> rather difficult problem and I'm taking several approaches. Anyways I've >>> found a few "issues" with inequality testing. >>> >>> (%i1) load(ineq)$ >>> (%i2) assume(a>=0, b>=0, a<=1, b<=1)$ >>> (%i3) is(a*b >= 0); >>> (%o3) true >>> (%i4) is(a*b <= 1); >>> (%o4) unknown >>> (%i5) is( 1(a*b) >= 0); >>> (%o5) unknown >>> (%i6) (a * b >=0), pred; >>> (%o6) true >>> (%i7) (a * b <=1), pred; >>> (%o7) a*b<=1 >>> I would expect that if a<=X and b<=Y, then a*b<=X*Y, but Maxima cannot >>> figure that out. Annoying but at least it is not giving a strictly wrong >>> answer. >>> >>> And someone else once complained about the following: >>> (%i8) declare(k, integer)$ >>> (%i9) assume(k>1)$ >>> (%i10) is(k^2>k); >>> (%o10) true >>> (%i11) is(k^2 + 1 > k); >>> (%o12) unknown >>> (%i12) k^2+1 > k, pred; >>> (%o12) k^2+1>k >>> Again, this is annoying, but not strictly wrong. Yes, we can figure it >>> out, but Maxima cannot. I can even think of cases where if (a>b) then not >>> a+1>b, but this requires working with modulus arithmetic or finite fields >>> or something like that. But in this case k was declared an integer. >>> >>> Is there some other package to expand Maxima's inequality testing? >>> >>> >> >> >>  >> One dashboard for servers and applications across PhysicalVirtualCloud >> Widest outofthebox monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> >> >> >> _______________________________________________ >> Maximadiscuss mailing listMaximadiscuss@...nethttps://lists.sourceforge.net/lists/listinfo/maximadiscuss >> >> >> >> >>  >> One dashboard for servers and applications across PhysicalVirtualCloud >> Widest outofthebox monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Maximadiscuss mailing list >> Maximadiscuss@... >> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >> >> > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20150503 21:58:29

Barton implements the linear case in %solve using FourierMotzkin (as I already mentioned). This can be very (exponentially?) slow in general. We have generally avoided using slow algorithms in basic Maxima operations. Maybe we can use FM by default, and turn it off with (yet another :( ) flag. Maxima does a very poor job in even extremely elementary cases:  Maxima doesn't even know that atan(x)<2 for all (real) x.  It doesn't even know if you restrict to 1 < x < 1. This does not require any subtlety.  is(sin(x)<=1+2^52) => true; but is(sin(x)+2^53) => unknown; where of course is(sin(x)<=1) should be true. Somehow floating point is sneaking in inappropriately.  is(sin(x)^2)<2 => unknown (let alone <=1)  Maxima does not use realroots for univariate polynomials. assume(r>0,r<1)  sign(r^21) => neg (correct), but sign(r^22) => pnz ! Realroots, though a numerical method, provides guarantees about its results which are suitable for cases like this. Going beyond all this is gravy. On Sun, May 3, 2015 at 11:41 PM, Richard Fateman <fateman@...> wrote: > This is a geometric computation that can be done > algebraically, if all the constraints are algebraic (polynomial) > inequalities. > Cylindrical Algebraic Decomposition. > > If the constraints include, exp, log, trig, etc., dunno. > > If the constraints are LINEAR, the solution is, I think, already > programmed for Maxima. > > The heuristics and just fiddling around might be needed in the "dunno" > case. But not the others. > > Is there anyone out there that can confirm the statements above? Or > deny them authoritatively? > > RJF > > > > On 5/2/2015 11:13 PM, Mike Valenzuela wrote: > > Oh another example of a Maxima not figuring out inequalities well: > > assume(a>=0, b>=0, a<=1, b<=1)$ > assume(m>4)$ > is(a1 <= 0); > is(b*(a1) <= 0); > is(b*2 <= 2); > is(b*2  2 <= 0); > is(b*(a1) + 2  2<=0); > is(b*(a1) + (b*2  2) <=0); > true > true > true > true > true > unknown > > The last answer should be true, because the sum of any nonpositive > terms is still nonpositive. Although I can find these cases, I am having > trouble figuring out how Maxima should solve this kind of problem. At least > for multiplication and addition I think this can be solved. > > I'm thinking about ways to improve Maxima's capabilities. > > > On Sat, May 2, 2015 at 7:19 PM, Mike Valenzuela <mickle.mouse@...> > wrote: > >> Hello again, >> >> Sorry for posting so many questions, but I've been trying to solve a >> rather difficult problem and I'm taking several approaches. Anyways I've >> found a few "issues" with inequality testing. >> >> (%i1) load(ineq)$ >> (%i2) assume(a>=0, b>=0, a<=1, b<=1)$ >> (%i3) is(a*b >= 0); >> (%o3) true >> (%i4) is(a*b <= 1); >> (%o4) unknown >> (%i5) is( 1(a*b) >= 0); >> (%o5) unknown >> (%i6) (a * b >=0), pred; >> (%o6) true >> (%i7) (a * b <=1), pred; >> (%o7) a*b<=1 >> I would expect that if a<=X and b<=Y, then a*b<=X*Y, but Maxima cannot >> figure that out. Annoying but at least it is not giving a strictly wrong >> answer. >> >> And someone else once complained about the following: >> (%i8) declare(k, integer)$ >> (%i9) assume(k>1)$ >> (%i10) is(k^2>k); >> (%o10) true >> (%i11) is(k^2 + 1 > k); >> (%o12) unknown >> (%i12) k^2+1 > k, pred; >> (%o12) k^2+1>k >> Again, this is annoying, but not strictly wrong. Yes, we can figure it >> out, but Maxima cannot. I can even think of cases where if (a>b) then not >> a+1>b, but this requires working with modulus arithmetic or finite fields >> or something like that. But in this case k was declared an integer. >> >> Is there some other package to expand Maxima's inequality testing? >> >> > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > Maximadiscuss mailing listMaximadiscuss@...nethttps://lists.sourceforge.net/lists/listinfo/maximadiscuss > > > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > > 
From: Richard Fateman <fateman@be...>  20150503 21:41:53

This is a geometric computation that can be done algebraically, if all the constraints are algebraic (polynomial) inequalities. Cylindrical Algebraic Decomposition. If the constraints include, exp, log, trig, etc., dunno. If the constraints are LINEAR, the solution is, I think, already programmed for Maxima. The heuristics and just fiddling around might be needed in the "dunno" case. But not the others. Is there anyone out there that can confirm the statements above? Or deny them authoritatively? RJF On 5/2/2015 11:13 PM, Mike Valenzuela wrote: > Oh another example of a Maxima not figuring out inequalities well: > > assume(a>=0, b>=0, a<=1, b<=1)$ > assume(m>4)$ > is(a1 <= 0); > is(b*(a1) <= 0); > is(b*2 <= 2); > is(b*2  2 <= 0); > is(b*(a1) + 2  2<=0); > is(b*(a1) + (b*2  2) <=0); > true > true > true > true > true > unknown > > The last answer should be true, because the sum of any nonpositive > terms is still nonpositive. Although I can find these cases, I am > having trouble figuring out how Maxima should solve this kind of > problem. At least for multiplication and addition I think this can be > solved. > > I'm thinking about ways to improve Maxima's capabilities. > > > On Sat, May 2, 2015 at 7:19 PM, Mike Valenzuela > <mickle.mouse@... <mailto:mickle.mouse@...>> wrote: > > Hello again, > > Sorry for posting so many questions, but I've been trying to solve > a rather difficult problem and I'm taking several approaches. > Anyways I've found a few "issues" with inequality testing. > > (%i1) load(ineq)$ > (%i2) assume(a>=0, b>=0, a<=1, b<=1)$ > (%i3) is(a*b >= 0); > (%o3) true > (%i4) is(a*b <= 1); > (%o4) unknown > (%i5) is( 1(a*b) >= 0); > (%o5) unknown > (%i6) (a * b >=0), pred; > (%o6) true > (%i7) (a * b <=1), pred; > (%o7) a*b<=1 > I would expect that if a<=X and b<=Y, then a*b<=X*Y, but Maxima > cannot figure that out. Annoying but at least it is not giving a > strictly wrong answer. > > And someone else once complained about the following: > (%i8) declare(k, integer)$ > (%i9) assume(k>1)$ > (%i10) is(k^2>k); > (%o10) true > (%i11) is(k^2 + 1 > k); > (%o12) unknown > (%i12) k^2+1 > k, pred; > (%o12) k^2+1>k > Again, this is annoying, but not strictly wrong. Yes, we can > figure it out, but Maxima cannot. I can even think of cases where > if (a>b) then not a+1>b, but this requires working with modulus > arithmetic or finite fields or something like that. But in this > case k was declared an integer. > > Is there some other package to expand Maxima's inequality testing? > > > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Andrej Vodopivec <andrej.vodopivec@gm...>  20150503 20:49:30

I have uploaded a dmg image to https://dl.dropboxusercontent.com/u/3305126/Maxima5.36.1.dmg If somebody wants to test it and I get some positive feedback I will upload it to sourceforge. Andrej On Sat, May 2, 2015 at 9:23 PM, Albrecht, Helmut <Helmut.Albrecht@...> wrote: > Hello again, > > first of all, I will pay tribute to you and your work in developing and maintaining maxima. The most important reasons for choosing maxima at our university: It is open source and free of charge (students normally only have a little money) and it is available for Windows and OS X. > Unfortunately the most recent downloadversion for OS X dates back to April 2013, while the WindowsVersion has been updated much more frequently. > > Is there a special reason for neglecting OS X in the past two years? > > Of course I tried the "homebrew"installation as recommended on the wxMaximaHomepage. I succeeded in installing maxima 5.34.1 but I failed in installing wxMaxima, because I got only wxmaxima version 13.4.2, which dates back to 2013. > > Please keep in mind that most people buying and using a Mac are only users  and no UNIXexperts. > > I would appreciate your answer in this matter. > > Best regards > > Helmut Albrecht > ************************************* > Prof. Dr. Helmut Albrecht > Institut für Mathematik > Pädagogische Hochschule > 73525 Schwäbisch Gmünd > 07171983455 (fon) > 07171983370 (fax) > > PS: Wollten Sie schon immer wissen, warum Elefanten dicke Beine haben? > http://www.amazon.de/WarumElefantendickeBeinehaben/dp/3833496932 > > > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Gunter Königsmann <gunter@pe...>  20150503 18:25:18

Very nice, this ChangeLog. And useful: ChangeLog entries need to be compact and therefore cannot possibly always tell the whole story. But a ChangeLog that is this complete with all the links looks like being much work... Kind regards, Gunter. On So, Mai 3, 2015 at 7:34 , Jaime Villate <villate@...> wrote: > Hi, > I I have made an HTML version of the most recent change log file: > https://sourceforge.net/p/maxima/wiki/5.36.0/ > > The big advantage of an HTML version is that it includes direct links > to > bug reports, commit messages and mailing lists messages. I also > corrected a couple of dates that were wrong in the mailing list > messages > list. > > I used the Wiki, just to experiment with it, but I could have created > the same page directly into the Website, with about the same effort. I > would like to hear opinions about whether to keep using the Wiki for > the > change logs or to move them to the Website. > > I also take the opportunity to tell you that the Sourceforge > administration decided to choose Maxima as one of > the projects of the week that will be announced tomorrow in: > > http://sourceforge.net/blog/projectoftheweekmay42015 > > Regards, > Jaime > > >  > One dashboard for servers and applications across > PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable > Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: Jaime Villate <villate@fe...>  20150503 17:34:25

Hi, I I have made an HTML version of the most recent change log file: https://sourceforge.net/p/maxima/wiki/5.36.0/ The big advantage of an HTML version is that it includes direct links to bug reports, commit messages and mailing lists messages. I also corrected a couple of dates that were wrong in the mailing list messages list. I used the Wiki, just to experiment with it, but I could have created the same page directly into the Website, with about the same effort. I would like to hear opinions about whether to keep using the Wiki for the change logs or to move them to the Website. I also take the opportunity to tell you that the Sourceforge administration decided to choose Maxima as one of the projects of the week that will be announced tomorrow in: http://sourceforge.net/blog/projectoftheweekmay42015 Regards, Jaime 
From: Jaime Villate <villate@fe...>  20150503 14:37:07

This is a bug. It is related to a bug that already existed in version 5.31.3 (see https://sourceforge.net/p/maxima/bugs/2835/) and which became worst in recent versions. I'll try to fix it. Regards, Jaime 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20150503 14:34:39

> Yes, but I'm not clear on how those apply to the kinds of calculations we're discussing here, which is why an example would be useful. > > On May 3, 2015 3:39 PM, "Helmut Jarausch" <jarausch@...> wrote: >> >> On 05/03/2015 12:58:07 PM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: >> > I'm probably missing something. Could you give a concrete example? >> Please have a look at >> http://www.mat.univie.ac.at/~neum/ >> >> and especially his old book on Interval Methods for Systems of Equations. >> >> And there is a lot of literature on ODE (including differential inequalities) >> and PDEs, quadratures, ... >> 
From: Dimiter Prodanov <dimiterpp@gm...>  20150503 11:45:11

Dear all, if possible I would like to come back on the topic let's define a global variable %top_simp_hook:[ ]; reg_simprule(rname, aa, bb)::=buildq([rname], block( defrule(rname, aa, bb), %top_simp_hook:cons(rname, %top_simp_hook) ) ); and then apply them in the top level simplification. Do you think this is feasible? best regards, Dimiter 
From: Volker van Nek <volkervannek@gm...>  20150503 11:21:02

Helmut, no decision has been made to neglect OS X. It just happens. I guess there is no developer using OS X. Speaking for myself I switched to GNU/Linux some years ago because this is simply the best system for developing and using software in the field of mathematics and related topics. Meanwhile I am a member of the Free Software Foundation to support the free software movement. Due to its open source code free software has a great potential in schools and universities. It's great to learn from code that was written by experienced developers. And also freedom matters. Free operating systems principally have no limitations and are the only ones you can still rely on. If recommendations from the wxMaximahomepage don't help you can try the FINK project. There is Maxima 5.36.1 for OS X. http://pdb.finkproject.org/pdb/package.php/maxima An alternative way to install Maxima on OS X and Microsoft Windows is to install a GNU/Linux in a virtual box and Maxima and friends on top. A simple way to get in touch with a GNU system. I guess you are teaching young teachers. Again speaking for myself please help your students to bring the idea of software freedom into schools. And by the way you don't have be a UNIXexpert. Be a GNUuser. And AFAIK GNU is not UNIX ;) Volker van Nek Am 02.05.2015 um 21:23 schrieb Albrecht, Helmut: > Hello again, > > first of all, I will pay tribute to you and your work in developing and maintaining maxima. The most important reasons for choosing maxima at our university: It is open source and free of charge (students normally only have a little money) and it is available for Windows and OS X. > Unfortunately the most recent downloadversion for OS X dates back to April 2013, while the WindowsVersion has been updated much more frequently. > > Is there a special reason for neglecting OS X in the past two years? > > Of course I tried the "homebrew"installation as recommended on the wxMaximaHomepage. I succeeded in installing maxima 5.34.1 but I failed in installing wxMaxima, because I got only wxmaxima version 13.4.2, which dates back to 2013. > > Please keep in mind that most people buying and using a Mac are only users  and no UNIXexperts. > > I would appreciate your answer in this matter. > > Best regards > > Helmut Albrecht > ************************************* > Prof. Dr. Helmut Albrecht > Institut für Mathematik > Pädagogische Hochschule > 73525 Schwäbisch Gmünd > 07171983455 (fon) > 07171983370 (fax) > > PS: Wollten Sie schon immer wissen, warum Elefanten dicke Beine haben? > http://www.amazon.de/WarumElefantendickeBeinehaben/dp/3833496932 > > > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss > 
From: Stavros Macrakis (Σταῦρος Μακράκης) <macrakis@al...>  20150503 10:58:15

I'm probably missing something. Could you give a concrete example? On May 3, 2015 12:05 PM, "Helmut Jarausch" <jarausch@...> wrote: > > On 05/03/2015 11:14:20 AM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: > > I doubt there's much to be learned from a numeric interval library in > > writing a symbolic interval library that isn't obvious. > > > > I disagree. > > Most work in numerical interval analysis has nothing to do with numerics but pure analysis like estimating upper bounds, sensitivity analysis and so on. > All this would have to be done for a symbolic interval library, as well. > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Maximadiscuss mailing list > Maximadiscuss@... > https://lists.sourceforge.net/lists/listinfo/maximadiscuss 
From: edgar <edgarrft@we...>  20150503 10:30:11

Hi again Maxima list, >>> From: Ronald Modesitt >>> Sent: Saturday, May 02, 2015 9:32 AM >>> To: maximadiscuss@... >>> Subject: [Maximadiscuss] Plot2d parametric plot errors from >>> mb2eplotfit >>> >>> System Configuration: >>> >>> Linux Mint 17.1, >>> >>> Dell Precision 690, 8 Gb >>> >>> Maxima Configuration: >>> >>> wxMaxima version 13.04.2 >>> >>> Maxima version: 5.32.1 >>> myoptions: [maxima_userdir, stardisp, float, numer, display2d, >>> %edispflag, exptdispflag, fpprintprec, leftjust] >>> >>> The following plot statement from the mbe2plotfit tutorial, in >>> wxMaxima >>> >>> plot2d ([uˆ3,[parametric, cos(t), sin(t), [’t,%pi,%pi]]], >>> [’u,1.1,1.1],[’x,1.5,1.5],[’y,1.5,1.5], >>> [gnuplot_preamble,"set size ratio 1;"])$ >>> >>> gives the error message: >>> >>> plotoptionsparser: unknown plot option: [u, 1.1,1.1] >>> >>> Xmaxima gives the same result. >>> >>> Parametric plot examples from Maxima book all work. >>> >>> I would appreciate a review by someone to help me find my error. >>> >>> Thanks in advance. >>> >>> Ron >>> >>> Ronald F. Modesitt >>> 1215 Ptarmigan Dr. >>> Longmont, CO 80504 >>> 3034853887 >>> >> >> Am Sat, 2 May 2015 12:17:11 0700 >> schrieb "Edwin Woollett" <woollett@...>: >> >> On my windows xp box, with gcl binary 5.31.2, I have no problems. >> Here are a series of test examples I ran with no problems as you >> describe: ========================================================== >> >> Maxima 5.31.2 http://maxima.sourceforge.net >> using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL) >> Distributed under the GNU Public License. See the file COPYING. >> Dedicated to the memory of William Schelter. >> The function bug_report() provides bug reporting information. >> "20150502" >>  >> with display2d:false in all the following, >> >> (%i1) plot2d(u^3,['u,1.1,1.1],['x,1.5,1.5],['y,1.5,1.5])$ >> >> (%i2) plot2d([parametric,cos(t),sin(t),['t,%pi,%pi]], >> ['x,1.5,1.5],['y,1.5,1.5])$ >> >> (%i3) plot2d([parametric,cos(t),sin(t),['t,%pi,%pi]], >> ['x,1.5,1.5],['y,1.5,1.5], >> [gnuplot_preamble,"set size ratio 1"])$ >> >> (%i4) plot2d( [ u^3, [parametric,cos(t),sin(t), ['t,%pi,%pi] ] ], >> ['u,1.1,1.1],['x,1.5,1.5],['y,1.5,1.5])$ >> >> (%i5) plot2d( [ u^3, [parametric,cos(t),sin(t), ['t,%pi,%pi] ] ], >> ['u,1.1,1.1],['x,1.5,1.5],['y,1.5,1.5], >> [gnuplot_preamble,"set size ratio 1"])$ >> >> (%i6) plot2d( [ u^3, [parametric,cos(t),sin(t), ['t,%pi,%pi] ] ], >> ['u,1.1,1.1],['x,1.5,1.5],['y,1.5,1.5], >> [gnuplot_preamble,"set size ratio 1;"])$ >> >> here is my build info: >>  >> (%i8) build_info(); >> (%o8) ?%build_info("5.31.2","20131007 23:05:06","i686pcmingw32", >> "GNU Common Lisp (GCL)","GCL 2.6.8") >> (%i9) display2d:true$ >> (%i10) build_info(); >> (%o10) >> Maxima version: "5.31.2" >> Maxima build date: "20131007 23:05:06" >> Host type: "i686pcmingw32" >> Lisp implementation type: "GNU Common Lisp (GCL)" >> Lisp implementation version: "GCL 2.6.8" >> ============================================ >> >> Ted > > Am Sat, 2 May 2015 21:50:08 +0200 > schrieb edgar <edgarrft@...>: > > In case it helps to find the problem: > > On Debian Linux, Ted's examples (%i4), (%i5), and (%i6) > all produce the same error: > > plotoptionsparser: unknown plot option: [u,1.1,1.1] >  an error. To debug this try: debugmode(true); > > If I set debugmode(true); and type :bt in the debugger > Idon't get a backtrace. :( > > Maybe this is something Linux or nonWindows specific. I have compiled an old Maxima 5.31.2 (the same Maxima version Ed Woolett uses to test the examples of his tutorials), and there are _no_ errors, everything plots fine. I have compiled a brandnew Maxima 5.36.1 where the same errors happen as already reported: (%i1) plot2d([u^3, [parametric,cos(t),sin(t), ['t,%pi,%pi]]], ['u,1.1,1.1],['x,1.5,1.5],['y,1.5,1.5], [gnuplot_preamble,"set size ratio 1"])$ plotoptionsparser: unknown plot option: [u,1.1,1.1]  an error. To debug this try: debugmode(true); The HTML manual of the current Maxima 5.36.1 tells that the ['u,1.1,1.1] list is explicitely needed to define the range of the u variable in u^3. Everything looks as if plot2d in recent Maxima versions is broken. Maxima version: "5.36.1" Maxima build date: "20150502 22:41:28" Host type: "x86_64unknownlinuxgnu" Lisp implementation type: "SBCL" Lisp implementation version: "1.2.11"  edgar 
From: Jaime Villate <villate@fe...>  20150503 10:16:46

On 03052015 04:27, Ronald Modesitt wrote: > I tried all your examples again professor, with the same results as > before beginning with [%i4] on both Xmaxima and wxMaxima. > > Jamie's approach works on both wxMaxima and Xmaxima interfaces. > > Do you suppose this represents the inherent differences between > Windows XP (32) and Linux (64) execution? Hi, I don't think this has anything to do with the underlying operating system or even with different Lisp implementations. What we are talking about is a very simple parsing of the options given to plot2d which seems to be working differently in different versions. The only source of differences in this case that I can think of are the modifications of the source code for plot2d. I will have to install version 5.31 again (I hope I can get a copy of it because it is a very old version) and see if I missed something when the new options parser for plot2d was introduced after version 5.31. In the meantime, I'd like to ask Ted to check whether the plots he reported in the previous message really give the expected results; namely, they might not report any errors, because the old version of the options parser was very permissive, but do the plots really show the two curves? (a circle and a cubic curve). Thanks to Ronald for bringing this up. Best regards, Jaime 
From: Helmut Jarausch <jarausch@sk...>  20150503 10:04:44

On 05/03/2015 11:14:20 AM, Stavros Macrakis (Σταῦρος Μακράκης) wrote: > I doubt there's much to be learned from a numeric interval library in > writing a symbolic interval library that isn't obvious. > I disagree. Most work in numerical interval analysis has nothing to do with numerics but pure analysis like estimating upper bounds, sensitivity analysis and so on. All this would have to be done for a symbolic interval library, as well. 
From: Gunter Königsmann <gunter@pe...>  20150503 09:35:56

I am just a user, not one of the mathematics wizards that are in this list. But I think better inequality testing will add much to the experience with maxima: Currently when solving differential equations I always get asked thinks like: Is 4L>(R_1+R_2)*C even if it is known that the opposite is true and sometimes I cannot find an assume that gives the right answers and seem to be stuck with answering these questions manually. So thumbsup from me! Kind regards, Gunter. On So, Mai 3, 2015 at 11:22 , Mike Valenzuela <mickle.mouse@...> wrote: > I guess there are a bunch of rules on wikipedia > (http://en.wikipedia.org/wiki/Interval_arithmetic). I knew odd powers > were easy, but even powers were a bit easier than I was making them > out to be. Still if the exponent could be zero, then there is more to > worry about. I was also worrying about extending the intervals to > unknown even/odd powers. For symbolic odd powers, the bounds will > either grow toward negative infinity, towards 0, or towards infinity. > Depending on its previous value, whether the bound was an upper or > lower, this will impact the new bounds. > > [1/2, 2]^k, for a positive integer k. The new bounds are [1/2^k, > 2^k]. We can drop the variable k by considering all its possible > values. Then the bounds adjust to (0, inf). > > On Sun, May 3, 2015 at 2:14 AM, Stavros Macrakis (Σταῦρος > Μακράκης) <macrakis@...> wrote: >> I doubt there's much to be learned from a numeric interval library >> in writing a symbolic interval library that isn't obvious. >> >> On Sun, May 3, 2015 at 5:08 AM, Mike Valenzuela >> <mickle.mouse@...> wrote: >>> ninja edit. >>> >>> I have two parts to that rambling. At one point I was just worrying >>> about signs when I discovered it wasn't enough. I'll look into the >>> c++ boost library later to see if it is suitable for working with >>> symbolic intervals. >>> >>> On Sun, May 3, 2015 at 2:07 AM, Mike Valenzuela >>> <mickle.mouse@...> wrote: >>>> I have two parts to that rambling. At one point I was just >>>> worrying about signs when I discovered it was enough. >>>> >>>> I recently recalled the c++ boost interval library: >>>> http://www.boost.org/doc/libs/1_58_0/libs/numeric/interval/doc/interval.htm. >>>> I wonder if carrying out many of the same operations symbolically, >>>> if it would work. >>>> >>>> On Sun, May 3, 2015 at 1:44 AM, Stavros Macrakis (Σταῦρος >>>> Μακράκης) <macrakis@...> wrote: >>>>> (resending to group without Mike's code because moderation kicks >>>>> in for long messages) >>>>> >>>>> Thanks for your ideas. >>>>> >>>>> I haven't read your code (sorry), but it looks from the names >>>>> lower_ and upper_bound that you're doing some sort of symbolic >>>>> interval arithmetic, which would be a useful addition to Maxima. >>>>> Currently, Maxima doesn't do any of that, which is a bit >>>>> surprising. >>>>> >>>>> s >>>>> >>>>> On Sun, May 3, 2015 at 4:31 AM, Mike Valenzuela >>>>> <mickle.mouse@...> wrote: >>>>>> Hello all again, >>>>>> >>>>>> I've been trying to put together a rule list for working with >>>>>> inequalities, especially for testing, so I put together some >>>>>> rules.... >>>> >>> >>> >>>  >>> One dashboard for servers and applications across >>> PhysicalVirtualCloud >>> Widest outofthebox monitoring support with 50+ applications >>> Performance metrics, stats and reports that give you Actionable >>> Insights >>> Deep dive visibility with transaction tracing using APM Insight. >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> _______________________________________________ >>> Maximadiscuss mailing list >>> Maximadiscuss@... >>> https://lists.sourceforge.net/lists/listinfo/maximadiscuss >>> >> > 