From: Raymond T. <toy...@gm...> - 2024-08-18 00:37:09
|
On 8/17/24 5:09 PM, Raymond Toy wrote: > > > On Sat, Aug 17, 2024, 3:40 PM Stavros Macrakis <mac...@gm...> wrote: > > Normally, the *translated* property means that the function was > defined using *translate*. > > I have no idea why functions originally defined in Lisp have this > flag. This is intentional (defmfun/ commac.lisp): > > ;; I (rtoy) think we can consider all defmfun'sas translated > functions. > (defprop ,function t translated) > > but I have no idea of the rationale. This seems wrong -- for > example, (mget '$cons 'mexpr) => nil, unlike a genuine translated > function, where it is the Maxima definition of the function. > > I'm not really sure, but I think many of the original functions before > conversion to defmfun, had the translated property already. So I just > made defmfun do that automatically. Is have to do some code archeology > to figure this out. If possible. Ah. Found this message: |commit 96e28268b5129b566a517499d31b5ae3c9d28285 Author: rtoy <rtoy> Date: Thu Dec 8 18:21:41 2005 +0000 Add the TRANLATED property for every function defined by defmfun. Then translated code doesn't have to mfunction-call these functions, but can call them directly. (Makes the code easier to read.) | Does not using |mfunction-call| really matter? Don’t know. I rarely use |translate|. > > Ray? > > -s > > On Sat, Aug 17, 2024 at 6:22 PM Eduardo Ochs > <edu...@gm...> wrote: > > Thanks!!! > A quick question... > The source of taylorp in simp.lisp is very clear: > > (defmfun $taylorp (x) > (and (not (atom x)) > (eq (caar x) 'mrat) > (member 'trunc (cdar x)) t)) > > but > > :lisp (describe '$taylorp) > > says "Symbol-plist: ... TRANSLATED -> T ...". > > What does the "translated" mean in this case? I took a quick > look at > all the occurences of "translate" in the info manual and I got the > impression that translated functions come from Maxima > functions, but I > grepped the sources and I didn't find a possible Maxima source for > this $taylorp... > > Cheers, TIA, etc, > Eduardo > > > On Sat, 17 Aug 2024 at 19:04, Stavros Macrakis > <mac...@gm...> wrote: > > taylorp(taylor(1,x,0,1)) => true > > > On Sat, Aug 17, 2024, 16:54 Eduardo Ochs > <edu...@gm...> wrote: > > Hi all, > > sorry for the delay - we're at the end of the semester > here, with lots > of tests to prepare and to mark... and this will be a > partial answer - > I haven't tried all of your suggestions yet. Anyway... > > My questions about the internal representation of the > objects returned > by "factor", "trunc" and "taylor" were not because I > need to do > something "practical" with these objects in the near > future - I was > asking them just because my mental model of Maxima > objects is still > very incomplete, and when I ask these questions here I > usually get > answers that help me a lot. > > The documentation for "trunc", at > > (info "(maxima)trunc") > https://maxima.sourceforge.io/docs/manual/maxima_141.html#trunc > > says: > > Annotates the internal representation of the general > expression > <expr> so that it is displayed as if its sums were > truncated Taylor > series. <expr> is not otherwise modified. > > The snippet below shows some ways of exploring these > annotations - I'm > guessing that "annotations" is the correct term: > > a1 : a*b; > a2 : factor(100); > b1 : 23 + 45*x; > b2 : trunc(b1); /* has a ... */ > b3 : taylor(b1, x, 0, 1); /* has a ... and a /T/ */ > ratp(b1); /* false */ > ratp(b2); /* false */ > ratp(b3); /* true */ > to_lisp(); > #$a*b$ ; ((MTIMES SIMP) $A $B) > #$a1$ ; ((MTIMES SIMP) $A $B) > #$a2$ ; ((MTIMES SIMP FACTORED) ((MEXPT SIMP) 2 > 2) ((MEXPT SIMP) 5 2)) > #$b1$ ; ((MPLUS SIMP) 23 ((MTIMES SIMP) 45 $X)) > #$b2$ ; ((MPLUS SIMP TRUNC) 23 ((MTIMES SIMP) 45 > $X)) > #$b3$ ; ((MRAT SIMP ... TRUNC) PS ...) > (car #$b2$) ; (MPLUS SIMP TRUNC) > (cdar #$b2$) ; (SIMP TRUNC) > (cddar #$b2$) ; (TRUNC) > (to-maxima) > > There is a simple way to detect "taylorness" from > Maxima - we can use > "ratp" - but I couldn't find a simple way to detect > "truncness", or > "factoredness"... my guess is that if, and when, I > decide that some of > these annotations are important in my programs that > represent Maxima > objects as trees, then I will have write some Lisp to > interpret the > "cdar"s or the "cddar"s of these objects to see if > they have any > annotations that are worth showing... and "worth > showing" is something > that obviously depends on the context, and in many > cases just adding a > way to indicate that "this object has non-trivial > annotations" would > be enough. > > Anyway, these annotations look very important, but the > only places in > the manual in which I remember seeing them mentioned > clearly are here, > > (info "(maxima)Introduction to Simplification") > https://maxima.sourceforge.io/docs/manual/maxima_45.html > > that points to this paper, in which they are called > "flags", > > https://people.eecs.berkeley.edu/~fateman/papers/intro5.txt > https://maxima.sourceforge.io/misc/Fateman-Salz_Simplifier_Paper.pdf > > and here: > > (info "(maxima)Introduction to Lists") > https://maxima.sourceforge.io/docs/manual/maxima_20.html > > Are there standard functions to inspect them _from > Maxima_? Any > pointers, comments, recommendations? > > Thanks in advance, and, again, sorry for not having > digested all the > material in your previous answers _yet_... =/ > > Eduardo Ochs > http://anggtwu.net/eev-maxima.html > > > On Thu, 15 Aug 2024 at 14:11, Stavros Macrakis > <mac...@gm...> wrote: > > As I said in my post: > > The clean way to process factorizations > programmatically is with *ifactors*. > > ifactors(10!) => [[2, 8], [3, 4], [5, 2], [7, 1]] > > > No reason to call internal functions or futz > around with the output of *factor*, which is not > designed for programmatic use. > > -s > > > On Thu, Aug 15, 2024 at 9:29 AM Richard Fateman > <fa...@gm...> wrote: > > > If you expect Maxima to continually retain a > factorization like 2^3 through various > simplifications, > you have to turn off the simplifier, which > pretty much breaks the whole system. > > If you want to see the factors and > multiplicities, do this: > :lisp (trace nratfact). > > If you want to acquire a result that gives > prime factors and multiplicities in some > structure that > does not disappear, that structure might look > like ... factorlist([2,3], [3,1}) for > 2^3*3^1 or 24. > It would be quite easy to make an alternative > version of nratfact, or consider > > *factorlist(r) := psubst([ "^"="[","*"="[" ], > factor(r)); > * > > which, for factorlist(24) gives [[2,3],3]. > (sorry, if you want 3 to appear as 3^1 or > [3,1] you'll have to write another line of code. > > As for the show expression task, here's a > simpler piece of code for most of the task.. > *showit(r):=psubst(psubstlist,r);* > where > > *psubstlist: [ "^"=Power, "*"=Times, > "+"=Plus, "/"=Div]; (*etc etc for all > operators of interest . Maybe choose other > names *) > * > > I think that the graphical tree representation > of expressions may be of some brief > explanatory use, but > the prefix expression version is, for me, much > more appealing. Thus > *showit (rat(x+1)^2);* > returns > *Plus(Power(x,2),Times(2,x),1)* > > > RJF > > On Wed, Aug 14, 2024 at 6:15 PM Stavros > Macrakis <mac...@gm...> wrote: > > One problem with integer factorizations is > that they are pseudo-simplified: normally, > Maxima does not allow 2^3 as a simplified > expression, but *factor* cheats and marks > the expression as simplified, even though > it isn't. That means that it gives strange > results if you try to manipulate it: > > qq:factor(24) => 2^3*3 > qq+1 => 2^3*3 + 1 > > <big snip> > > _______________________________________________ > Maxima-discuss mailing list > Max...@li... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > |