Is there a way to symbolic constants to have them stay correctly in place?
Subject: Is there a way to symbolic constants to have them stay correctly in place?
From: Berns Buenaobra
Date: Sat, 20 Apr 2013 18:30:41 +0800
Hi all:
Its a bit awkward and I find that students trying out Maxima can't resist
to check how well are constants are ordered in the derived relations from a
text book to a Maxima output.
Consider for example a worksheet snippet:
('diff(Vin(t),t,1))*C=Vout/R; solve([('diff(Vin(t),t,1))*C=Vout(t)/R],
[Vout(t)]);
I'm deriving the classic differentiator circuit here for my physical
electronics lecture and I get like:
which should really be nice if it does not look strange and unfamiliar like
this:
Vout(t)=RC*dVin(t)/dt
or for the case of it's inverse the integrator below:
which would be nice if it would like Vout(t)= 1/RC <integral_sign> Vin(t)
dt.
This maybe too trivial to ask but student do ask me many trivial questions
which be answered in a non-trivial way.
Regards,
Berns B.
University of San Carlos - Dept.of Physics
Cebu,Philippines
On Sat, Apr 20, 2013 at 8:16 AM, <maxima-request at math.utexas.edu> wrote:
> Send Maxima mailing list submissions to
> maxima at math.utexas.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.math.utexas.edu/mailman/listinfo/maxima
> or, via email, send a message with subject or body 'help' to
> maxima-request at math.utexas.edu
>
> You can reach the person managing the list at
> maxima-owner at math.utexas.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Maxima digest..."
>
>
> Today's Topics:
>
> 1. how to say k>1? (Witold E Wolski)
> 2. Re: plotdf questions: tstep, Runge-Kutta and singular points
> (Ilya Schurov)
> 3. Re: how to say k>1? (Raymond Toy)
> 4. Re: algorithms for 'invert', was: program works with maxima
> 5.29.1 but freezes with maxima 5.30.0 (Henry Baker)
> 5. Re: algorithms for 'invert', was: program works with maxima
> 5.29.1 but freezes with maxima 5.30.0 (Stavros Macrakis)
> 6. Re: algorithms for 'invert', was: program works with maxima
> 5.29.1 but freezes with maxima 5.30.0 (Stavros Macrakis)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 19 Apr 2013 20:50:03 +0200
> From: Witold E Wolski <wewolski at gmail.com>
> To: maxima at math.utexas.edu
> Subject: how to say k>1?
> Message-ID:
> <
> CAAjnpdg0rkSxxsdWHivLYBLWOcsY5ffzt+i7EyGEeihc_Q5Nqw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I want to integrate
> integrate(c*x^k,x);
>
> Maxima asks Is k + 1 zero or nonzero?
>
> So I would like to tell that k>1.
> How do I do it?
>
> regards
> Witold
> -------------- next part --------------
> URL: <
> http://www.math.utexas.edu/pipermail/maxima/attachments/20130419/e8dcfd39/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 19 Apr 2013 23:03:44 +0400
> From: Ilya Schurov <ilya at schurov.com>
> To: Jaime Villate <villate at fe.up.pt>
> Cc: maxima at math.utexas.edu
> Subject: Re: [Maxima] plotdf questions: tstep, Runge-Kutta and
> singular points
> Message-ID:
> <CAC6ErROG_=
> tGP1Zx3LZysUjzO+XKOVhLVUjh0vTnJbno22_dWQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi, Jaime,
>
> > I see to problems with that approach: the value of vmin (or tmin or
> > something else) would have to be given by the user because it is not
> easy to
> > find a good estimate automatically and in the regions where the phase
> > velocity is almost constant, the trajectory would move very slowly (with
> > velocity vmin) making the algorithm as inefficient as it was when a fixed
> > value of tstep was used.
> I see the point. If one multiply the vector field by a constant (or
> even scalar function), phase curves will be the same, but the lengths
> of the vector will change. As far as I understand, we want an
> algorithm that will be efficient even if we multiply vector field by a
> very small constant.
>
> > I think that the major problem near the equilibrium points is not only
> that
> > the phase velocity is small but that it changes direction abruptly. What
> I
> > was planning to do is to detect those abrupt changes of direction to
> triger
> > the end of the trajectory. But I will try out your suggestion anyway.
> I see two different ways to check that we are near the equilibrium:
> first, as you suppose, is to check that directions changes quickly
> (e.g. we can try to calculate the partial derivatives of
> ux^2/(ux^2+uy^2) and uy^2/(ux^2+uy^2), which are sine and cosine of
> normalized phase speed), and the other (supposed by my colleague) is
> to consider the derivative of the phase speed in current point and
> estimate the distance to the singular point assuming that the vector
> field is linear (a kind of Newton method). For example, in dimension
> 1, we are estimating the distance to the equilibrium by the value
>
> -ux/(d(ux)/dx)
>
> (which is exact distance to the root of ux if ux=k*x+b linear).
>
> If that distance is small, we have to decrease h.
>
> One can use some multidimensional counterpart of this method.
>
> I'm not sure which one is better suit our needs.
>
> > plotdf is written in Tcl. The lisp part is just a front end that prepares
> > the expressions and options into a form that Tcl can understand. You can
> see
> > the source code for the current Runge-Kutta algorithm in:
> >
> > interfaces/xmaxima/Tkmaxima/rk4.tcl
> >
> > In the same directory I also kept the original programs of William
> Shelter,
> > which are not being used:
> >
> > interfaces/xmaxima/Tkmaxima/Rk.tcl
> > interfaces/xmaxima/Tkmaxima/Adams.tcl
> Oh, that's great! I found Rk.tcl but missed rk4.tcl :)
>
> Tcl seem to be a bit easier than Lisp though I'm not familiar with it
> either :) I'll try to tweak it when time permit.
>
> Thanks again!
>
> --
> With best regards,
> Ilya V. Schurov.
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 19 Apr 2013 12:29:36 -0700
> From: Raymond Toy <toy.raymond at gmail.com>
> To: maxima at math.utexas.edu
> Subject: Re: [Maxima] how to say k>1?
> Message-ID: <wvmili8euxnj.fsf at rtoy2.mtv.corp.google.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> >>>>> "Witold" == Witold E Wolski <Witold> writes:
>
> Witold> I want to integrate
> Witold> integrate(c*x^k,x);
>
>
> Witold> Maxima asks Is? k + 1? zero or nonzero?
>
>
> Witold> So I would like to tell that k>1.
>
> assume(k>1);
> integrate(c*x^k,x);
> c*x^(k+1)/(k+1)
>
> Ray
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 19 Apr 2013 12:45:44 -0700
> From: Henry Baker <hbaker1 at pipeline.com>
> To: Stavros Macrakis <macrakis at alum.mit.edu>
> Cc: maxima mailing list <maxima at math.utexas.edu>, Robert Dodier
> <robert.dodier at gmail.com>
> Subject: Re: [Maxima] algorithms for 'invert', was: program works with
> maxima 5.29.1 but freezes with maxima 5.30.0
> Message-ID: <E1UTHHh-0004we-Pe at elasmtp-curtail.atl.sa.earthlink.net>
> Content-Type: text/plain; charset="us-ascii"
>
> I should point out that programming a really reliable, robust matrix
> inversion algorithm is a lot harder than most mathematicians would make it
> seem.
>
> For example, if the matrix is 'almost' singular (i.e., det(M) almost
> zero), then things can go haywire. In order to avoid various kinds of
> overflow/underflow, you may want to fiddle with the floating point
> exponents in advance, etc. BTW, don't bfloats allow unrestricted integers
> for their exponent, so that overflow/underflow is never an issue?
>
> Although the adjoint algorithm has terrible algorithmic complexity, at
> least it is perspicuous, so that the only division is the division by the
> determinant.
>
> As I pointed out in post on the topic of Matlab, many codes try to avoid
> the computation of an explicit matrix inverse, because the inverse of a
> sparse matrix is usually non-sparse. For these reasons, Matlab & other
> packages provide the ability to compute (M^^-1).b without the explicit
> computation of (M^^-1). I guess that Maxima could do the same thing via
> Cramer's Rule (or equivalent), so that the only division would still be
> that by det(M).
>
> At 10:46 AM 4/19/2013, Stavros Macrakis wrote:
> >I believe adjoint was chosen as the default because it works well in the
> symbolic case.
> >
> >According to Henry, LU is better for floats (but not rationals). Perhaps
> the right policy is: if matrix is entirely float or bfloat, use LU,
> otherwise use adjoint.
> >
> >If adjoint produces simpler results, it sounds like the right algorithm
> for symbolic matrices regardless of size, as a first cut at least. An
> unwieldy symbolic result returned fast is probably less useful to most
> users than a tractable symbolic result that takes longer.
> >
> >Perhaps there are more sophisticated policies possible (depending on
> sparseness or proportion of symbolic vs. small integer entries, etc.), but
> it seems like a good start.
> >
> > -s
> >
> >On Fri, Apr 19, 2013 at 12:27 PM, Robert Dodier <robert.dodier at gmail.com>
> wrote:
> >On 2013-04-19, Henry Baker <hbaker1 at pipeline.com> wrote:
> >
> >> So it depends upon what you're trying to achieve, and which
> fields/rings are involved.
> >
> >> The advantages of certain 'efficient' matrix operations like LU quickly
> disappear when
> >> operating with rings other than floating point numbers.
> >
> >Can we derive from these considerations a policy for automatically
> >choosing which algorithm to use? E.g. if small then adjoint method, else
> >if numerical then LU, otherwise print a warning message ("umm, it might
> >or might not work") and use either one. Each method should be available
> >as a separate function (e.g. invert_by_adjoint) so that the user can
> >explicitly choose one or another.
> >
> >I realize that such heuristics are not foolproof, but it would be an
> >improvement on the current situation, and in any event it is
> >unreasonable to expect users to have any idea how to choose among
> >algorithms.
> >
> >best
> >
> >Robert Dodier
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 19 Apr 2013 16:14:13 -0400
> From: Stavros Macrakis <macrakis at alum.mit.edu>
> To: Henry Baker <hbaker1 at pipeline.com>
> Cc: maxima mailing list <maxima at math.utexas.edu>, Robert Dodier
> <robert.dodier at gmail.com>
> Subject: Re: [Maxima] algorithms for 'invert', was: program works with
> maxima 5.29.1 but freezes with maxima 5.30.0
> Message-ID:
> <CACLVabXxax0G15=
> ax6vYqkqGphCeAvxLk2rbKdMYDGB4TOyvdg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> bfloats allow unrestricted integer exponents, but you can still get the
> infamous catastrophic cancellation because precision is finite. The
> numerical analysts have thought quite a bit about how to code matrix
> operations (including inversion) for efficiency and accuracy using floats.
> I imagine someone's thought about issues of efficiency for the rational
> case (including cost of GCDs, size of intermediate results, etc.) and
> efficiency and simplicity/tractability of result for the symbolic cases.
>
> -s
>
>
> On Fri, Apr 19, 2013 at 3:45 PM, Henry Baker <hbaker1 at pipeline.com> wrote:
>
> > I should point out that programming a really reliable, robust matrix
> > inversion algorithm is a lot harder than most mathematicians would make
> it
> > seem.
> >
> > For example, if the matrix is 'almost' singular (i.e., det(M) almost
> > zero), then things can go haywire. In order to avoid various kinds of
> > overflow/underflow, you may want to fiddle with the floating point
> > exponents in advance, etc. BTW, don't bfloats allow unrestricted
> integers
> > for their exponent, so that overflow/underflow is never an issue?
> >
> > Although the adjoint algorithm has terrible algorithmic complexity, at
> > least it is perspicuous, so that the only division is the division by the
> > determinant.
> >
> > As I pointed out in post on the topic of Matlab, many codes try to avoid
> > the computation of an explicit matrix inverse, because the inverse of a
> > sparse matrix is usually non-sparse. For these reasons, Matlab & other
> > packages provide the ability to compute (M^^-1).b without the explicit
> > computation of (M^^-1). I guess that Maxima could do the same thing via
> > Cramer's Rule (or equivalent), so that the only division would still be
> > that by det(M).
> >
> > At 10:46 AM 4/19/2013, Stavros Macrakis wrote:
> > >I believe adjoint was chosen as the default because it works well in the
> > symbolic case.
> > >
> > >According to Henry, LU is better for floats (but not rationals).
> Perhaps
> > the right policy is: if matrix is entirely float or bfloat, use LU,
> > otherwise use adjoint.
> > >
> > >If adjoint produces simpler results, it sounds like the right algorithm
> > for symbolic matrices regardless of size, as a first cut at least. An
> > unwieldy symbolic result returned fast is probably less useful to most
> > users than a tractable symbolic result that takes longer.
> > >
> > >Perhaps there are more sophisticated policies possible (depending on
> > sparseness or proportion of symbolic vs. small integer entries, etc.),
> but
> > it seems like a good start.
> > >
> > > -s
> > >
> > >On Fri, Apr 19, 2013 at 12:27 PM, Robert Dodier <
> robert.dodier at gmail.com>
> > wrote:
> > >On 2013-04-19, Henry Baker <hbaker1 at pipeline.com> wrote:
> > >
> > >> So it depends upon what you're trying to achieve, and which
> > fields/rings are involved.
> > >
> > >> The advantages of certain 'efficient' matrix operations like LU
> quickly
> > disappear when
> > >> operating with rings other than floating point numbers.
> > >
> > >Can we derive from these considerations a policy for automatically
> > >choosing which algorithm to use? E.g. if small then adjoint method, else
> > >if numerical then LU, otherwise print a warning message ("umm, it might
> > >or might not work") and use either one. Each method should be available
> > >as a separate function (e.g. invert_by_adjoint) so that the user can
> > >explicitly choose one or another.
> > >
> > >I realize that such heuristics are not foolproof, but it would be an
> > >improvement on the current situation, and in any event it is
> > >unreasonable to expect users to have any idea how to choose among
> > >algorithms.
> > >
> > >best
> > >
> > >Robert Dodier
> >
> >
> -------------- next part --------------
> URL: <
> http://www.math.utexas.edu/pipermail/maxima/attachments/20130419/c38f8e15/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Fri, 19 Apr 2013 20:16:39 -0400
> From: Stavros Macrakis <macrakis at alum.mit.edu>
> To: Robert Dodier <robert.dodier at gmail.com>
> Cc: maxima mailing list <maxima at math.utexas.edu>
> Subject: Re: [Maxima] algorithms for 'invert', was: program works with
> maxima 5.29.1 but freezes with maxima 5.30.0
> Message-ID:
> <CACLVabVYkqnm=
> bjeoKKXMupukf8fm8yA+9A8RzwoQFcdrx3H6g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> One of the rationales for preferring LU was speed. I believe it is indeed
> faster in the float case, but it seems to be much slower and produce bigger
> results in many symbolic cases, especially dense ones (see measurements
> below). If you eyeball them, the LU results are also much more deeply
> nested and don't seem to be a particularly simple/useful form for humans.
> The big disadvantage of ^^ is that it converts floats and bignums to
> rationals.
>
> So it doesn't looks like we should use LU for anything but floats and
> bfloats. Of course, the measurements below are pretty simple-minded. In
> particular, I didn't measure rational number, mixed rational/symbolic
> cases, elements in more exotic rings, etc.
>
> -s
>
> Timings on Maxima 5.28/SBCL (from before the replacement of 'invert' by
> 'invert_by_lu'). Size is slength(string(m[3,4])).
>
> m5: genmatrix(m,5,5)$
>
> Time Size ratsimp time
> ^^: 55mS 2929 305mS
> inv: 4mS 2931 289mS
> lu: 2370mS 7089 5999mS
>
> ndiag(m,n):=genmatrix(lambda([i,j],if abs(i-j)<=n then q[i,j] else 0),m,m)$
> n102: ndiag(10,2)$
>
> Time Size ratsimp time
> ^^: 292mS 3230 1209mS
> inv: 204mS 3346 1168mS
> lu: 6891mS 3700 27633mS
>
> A very sparse matrix with small determinant; Size is total size, not just
> one element
> sp12:
>
> matrix([0,q[1,2],0,0,0,0,0,0,q[1,9],0,0,0],[0,0,0,q[2,4],0,q[2,6],q[2,7],0,0,0,0,0],
> [0,0,0,0,0,0,q[3,7],0,0,0,0,0],[q[4,1],0,0,0,0,q[4,6],0,0,0,0,q[4,11],0],
> [0,0,q[5,3],0,0,0,0,0,q[5,9],0,0,0],[0,0,0,0,0,0,0,0,q[6,9],0,0,0],
> [0,0,0,q[7,4],0,q[7,6],0,0,0,0,0,0],[0,0,0,0,0,0,0,q[8,8],0,0,q[8,11],0],
> [0,0,0,0,0,0,0,0,0,0,0,q[9,12]],[0,0,0,0,q[10,5],0,0,q[10,8],0,0,0,0],
>
> [q[11,1],0,0,0,0,0,0,0,0,0,0,0],[0,0,0,0,0,q[12,6],0,0,q[12,9],q[12,10],0,0])
>
> Time Size ratsimp time
> ^^: 6mS 1848 9mS
> inv: 1775mS 10447 240mS
> lu: 730mS 1856 8mS
>
>
>
>
> On Fri, Apr 19, 2013 at 3:51 AM, Robert Dodier <robert.dodier at gmail.com
> >wrote:
>
> > On 2013-04-16, Dmitry Shkirmanov <piminusmeson at bk.ru> wrote:
> >
> > > Hello, list. I have wxmaxima program that takes a few seconds to run
> > > with maxima 5.29.1. But in maxima 5.30.0 it freezes. Is there any way
> > > to make it work with maxima 5.30?
> >
> > Well, it turns out the problem is very simple. The previous version of
> > the function 'invert' used the adjoint method, while the current version
> > uses the LU decomposition. (Yes, it was yours truly who made the change,
> > after some discussion on the mailing list.) For the matrices in the
> > program given, the results are substantially different -- the ones
> > produced by the adjoint method are "simpler".
> >
> > Not sure where to go from here. I remember from working on the code that
> > the adjoint method often produces 'simpler' results, but it is practical
> > only for small matrices. Maybe use the adjoint method for small matrices
> > and punt to LU otherwise? Just guessing.
> >
> > In the case at hand, I think all you have to do is load(invert) before
> > loading the temp3.wxm script -- share/matrix/invert.mac is an
> > implementation of the adjoint method (in fact the previous 'invert'
> > function was a Lisp version of that code).
> >
> > best
> >
> > Robert Dodier
> >
> > _______________________________________________
> > Maxima mailing list
> > Maxima at math.utexas.edu
> > http://www.math.utexas.edu/mailman/listinfo/maxima
> >
> -------------- next part --------------
> URL: <
> http://www.math.utexas.edu/pipermail/maxima/attachments/20130419/cbf8d4d9/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>
> End of Maxima Digest, Vol 81, Issue 40
> **************************************
>