maxima-discuss — Maxima discussion list

You can subscribe to this list here.

 2014 2015 2016 2017 Jan Feb (232) Mar (323) Apr (383) May (359) Jun (435) Jul (252) Aug (172) Sep (265) Oct (263) Nov (350) Dec (359) Jan (267) Feb (220) Mar (311) Apr (269) May (388) Jun (403) Jul (172) Aug (399) Sep (364) Oct (269) Nov (357) Dec (468) Jan (618) Feb (592) Mar (625) Apr (516) May (375) Jun (155) Jul (346) Aug (262) Sep (346) Oct (291) Nov (333) Dec (335) Jan (275) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

Showing results of 12349

<< < 1 .. 73 74 75 76 77 .. 494 > >> (Page 75 of 494)
 Re: [Maxima-discuss] f90 and precision of constants From: Richard Fateman - 2016-07-30 20:57:45 ```You could try something like this .. rationalp(x):= is(numberp(x) and not floatnump(x) and not integerp(x)) ratrpize(x):= if rationalp(x) then concat(ratnumer(x),"_rp") / concat(ratdenom(x),"_rp") else x and run fullmap of ratrpize on your expression also. RJF ```
 Re: [Maxima-discuss] f90 and precision of constants From: Frank Muldoon - 2016-07-30 20:36:07 ```On Sat, 2016-07-30 at 10:54 -0700, Richard Fateman wrote: > The entries in the matrix are not floats. If you do A:float(A) and > try the > program, you will see the _rp suffix. Hello Richard, OK, got it. Thanks. > > If you want to change other kinds of numbers, you can do that too, > but you might need special checks for rational numbers like 2/3. If > you first change 2/3 to a Maxima float, you do not get additional > accuracy in f90 via 0.6666..._rp. > I assumed that for f90 you wanted to leave integers alone, and didn't > have rational numbers. Yes, I see that now. Unfortunately the case of rational numbers cannot be excluded as they are omnipresent in the Maxima expressions. If they are simply written out as integers then Fortran does integer arithmetic on them and hence 2/3 becomes zero, 5/2 becomes 2 and so forth. > > You can also use Maxima bigfloats. Maybe you don't even need f90, > if you spend much time doing extra-precision float arithmetic. Using bfloatp and bfloat instead in the function suggested by yourself unfortunately also does not work. While this could provide any desired level of precision, it still seems to be a somewhat crude workaround as the desired approach is to preserve the rational numbers while marking the numerator and denominator by "_rp". Cheers, Frank > > RJF > > > On 7/30/2016 7:54 AM, Frank Muldoon wrote: > > Hello Richard, > > > > Thanks for the program. It does not seem, however, to work for matrices > > as nothing gets concatenated in this case. > > > > load (f90)\$ > > attach_text_to_floats(v):=if ?floatp(v) then concat(v,_rp) else v; > > > > A : matrix([+1,-2/3], > > [+2/4,+3]); > > > > f90('a=fullmap(attach_text_to_floats,A)); > > > > > > a(1,1) = 1 > > a(1,2) = (-2.0)/3.0 > > a(2,1) = 1.0/2.0 > > a(2,2) = 3 > > > > Cheers, > > Frank > > > > On Sat, 2016-07-30 at 06:07 -0700, Richard Fateman wrote: > >> Here is a program to scan through the expressions and > >> replace float constants. > >> However f90 renders this as "1.23_rp" so you have to remove the quote > >> marks. > >> > >> Maybe the option to f90() should be how to render literal strings, with > >> or without quotes. > >> This would be more general. > >> > >> rpize(v):=if ?floatp(v) then concat(v,"_rp") else v; > >> > >> e:1.2+2.3*x+cos(45.0+ 2*z); > >> > >> f90(fullmap(rpize,e)); > >> > >> cos(2*z+"45.0_rp")+"2.3_rp"*x+"1.2_rp" > >> > >> On 7/30/2016 1:07 AM, Frank Muldoon wrote: > >>> Hello all, > >>> > >>> I write concerning the function "f90(expr_1, …, expr_n)" obtained from > >>> "load (f90)\$". This is a very useful function and one of the reasons > >>> why I choose Maxima for many problems. > >>> > >>> It does however have one flaw. This concerns its treatment of > >>> constants. "f90()" writes them out for example as 968.0/11025.0 or 2896E > >>> +7. According to the Fortran standard these are single precision > >>> constants. While many compilers have command line options to promote > >>> constants from single to double (and sometimes to quad) precision, this > >>> is done globally, and therefore may not at all be desirable. > >>> > >>> This issue could easily be resolved by the addition of an argument to > >>> "f90()" which causes a character string to be added to all constants. > >>> For example assuming myfunction=2.3*x+1.2, then "f90(myfunction,_rp)" > >>> would result in > >>> > >>> 2.3_rp*x+1.2_rp > >>> > >>> which, assuming the Fortran program had > >>> > >>> integer, parameter :: rp = selected_real_kind(31) > >>> > >>> would result in 2.3 and 1.2 being represented in quad precision. This > >>> approach would allow arbitrary precision depending on the value for "rp" > >>> in the Fortran program. > >>> > >>> Cheers, > >>> Frank > >>> > >> > >> ------------------------------------------------------------------------------ > >> _______________________________________________ > >> Maxima-discuss mailing list > >> Maxima-discuss@... > >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering New Technologies and Service 27 Gzhatskaya street, room 205 Saint Petersburg Russia, 195220 +79313075021 (cell) Фрэнк Херберт Малдун, к.ф.-м.н. Новые Технологии и Сервис 195220 г. Санкт-Петербург ул. Гжатская, д. 27, комната 205 +79313075021 (мобильный) fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html ```
 Re: [Maxima-discuss] f90 and precision of constants From: Robert Dodier - 2016-07-30 19:07:21 ```On 2016-07-30, Frank Muldoon wrote: > It does however have one flaw. This concerns its treatment of > constants. "f90()" writes them out for example as 968.0/11025.0 or 2896E > +7. According to the Fortran standard these are single precision > constants. While many compilers have command line options to promote > constants from single to double (and sometimes to quad) precision, this > is done globally, and therefore may not at all be desirable. > > This issue could easily be resolved by the addition of an argument to > "f90()" which causes a character string to be added to all constants. > For example assuming myfunction=2.3*x+1.2, then "f90(myfunction,_rp)" > would result in > > 2.3_rp*x+1.2_rp I see a couple of approaches here -- you'll have to tell me which one is more appropriate for your needs. If the problem is that f90 prints out only E exponent markers, while it should print out D, that is a bug in f90. Incidentally there is also a separate function fortran(...) in Maxima, which doesn't have that bug. Fixing f90 in this respect just requires copying a couple of lines of code from fortran to f90. In the meantime maybe you can try the fortran function and see if it serves your needs. If the problem is to print out floats with an arbitrary precision marker, I believe the right way to do it is to make the _rp part of the Maxima expression. Here is how I recommend it: postfix ("_rp"); matchdeclare (xx, floatnump); defrule (mark_floats, xx, xx _rp); marked_expr : applyb1 (my_expr, mark_floats); load (f90); f90 (marked_expr); Here's an example output: (%i4) my_expr : sin(1.3489 + 385.2882*cos(u + 34989.2)); (%o4) sin(385.2882 cos(u + 34989.2) + 1.3489) (%i5) marked_expr : applyb1 (my_expr, mark_floats); (%o5) sin(385.2882 _rp cos(u + 34989.2 _rp) + 1.3489 _rp) (%i8) f90 (marked_expr); sin(385.2882 _rp*cos(u+34989.2 _rp)+1.3489 _rp) Is it necessary to suppress the usual exponent markers if the _rp notation is used? If so this approach will need some more work. In general I believe that working with Maxima expressions (here using the user-defined "_rp" operator) is much more general and powerful than working with string representations. Hope this helps, Robert Dodier ```
 Re: [Maxima-discuss] f90 and precision of constants From: Richard Fateman - 2016-07-30 17:54:44 ```The entries in the matrix are not floats. If you do A:float(A) and try the program, you will see the _rp suffix. If you want to change other kinds of numbers, you can do that too, but you might need special checks for rational numbers like 2/3. If you first change 2/3 to a Maxima float, you do not get additional accuracy in f90 via 0.6666..._rp. I assumed that for f90 you wanted to leave integers alone, and didn't have rational numbers. You can also use Maxima bigfloats. Maybe you don't even need f90, if you spend much time doing extra-precision float arithmetic. RJF On 7/30/2016 7:54 AM, Frank Muldoon wrote: > Hello Richard, > > Thanks for the program. It does not seem, however, to work for matrices > as nothing gets concatenated in this case. > > load (f90)\$ > attach_text_to_floats(v):=if ?floatp(v) then concat(v,_rp) else v; > > A : matrix([+1,-2/3], > [+2/4,+3]); > > f90('a=fullmap(attach_text_to_floats,A)); > > > a(1,1) = 1 > a(1,2) = (-2.0)/3.0 > a(2,1) = 1.0/2.0 > a(2,2) = 3 > > Cheers, > Frank > > On Sat, 2016-07-30 at 06:07 -0700, Richard Fateman wrote: >> Here is a program to scan through the expressions and >> replace float constants. >> However f90 renders this as "1.23_rp" so you have to remove the quote >> marks. >> >> Maybe the option to f90() should be how to render literal strings, with >> or without quotes. >> This would be more general. >> >> rpize(v):=if ?floatp(v) then concat(v,"_rp") else v; >> >> e:1.2+2.3*x+cos(45.0+ 2*z); >> >> f90(fullmap(rpize,e)); >> >> cos(2*z+"45.0_rp")+"2.3_rp"*x+"1.2_rp" >> >> On 7/30/2016 1:07 AM, Frank Muldoon wrote: >>> Hello all, >>> >>> I write concerning the function "f90(expr_1, …, expr_n)" obtained from >>> "load (f90)\$". This is a very useful function and one of the reasons >>> why I choose Maxima for many problems. >>> >>> It does however have one flaw. This concerns its treatment of >>> constants. "f90()" writes them out for example as 968.0/11025.0 or 2896E >>> +7. According to the Fortran standard these are single precision >>> constants. While many compilers have command line options to promote >>> constants from single to double (and sometimes to quad) precision, this >>> is done globally, and therefore may not at all be desirable. >>> >>> This issue could easily be resolved by the addition of an argument to >>> "f90()" which causes a character string to be added to all constants. >>> For example assuming myfunction=2.3*x+1.2, then "f90(myfunction,_rp)" >>> would result in >>> >>> 2.3_rp*x+1.2_rp >>> >>> which, assuming the Fortran program had >>> >>> integer, parameter :: rp = selected_real_kind(31) >>> >>> would result in 2.3 and 1.2 being represented in quad precision. This >>> approach would allow arbitrary precision depending on the value for "rp" >>> in the Fortran program. >>> >>> Cheers, >>> Frank >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Maxima-discuss mailing list >> Maxima-discuss@... >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss ```
 Re: [Maxima-discuss] f90 and precision of constants From: Frank Muldoon - 2016-07-30 15:55:04 ```Hello Richard, Thanks for the program. It does not seem, however, to work for matrices as nothing gets concatenated in this case. load (f90)\$ attach_text_to_floats(v):=if ?floatp(v) then concat(v,_rp) else v; A : matrix([+1,-2/3], [+2/4,+3]); f90('a=fullmap(attach_text_to_floats,A)); a(1,1) = 1 a(1,2) = (-2.0)/3.0 a(2,1) = 1.0/2.0 a(2,2) = 3 Cheers, Frank On Sat, 2016-07-30 at 06:07 -0700, Richard Fateman wrote: > Here is a program to scan through the expressions and > replace float constants. > However f90 renders this as "1.23_rp" so you have to remove the quote > marks. > > Maybe the option to f90() should be how to render literal strings, with > or without quotes. > This would be more general. > > rpize(v):=if ?floatp(v) then concat(v,"_rp") else v; > > e:1.2+2.3*x+cos(45.0+ 2*z); > > f90(fullmap(rpize,e)); > > cos(2*z+"45.0_rp")+"2.3_rp"*x+"1.2_rp" > > On 7/30/2016 1:07 AM, Frank Muldoon wrote: > > Hello all, > > > > I write concerning the function "f90(expr_1, …, expr_n)" obtained from > > "load (f90)\$". This is a very useful function and one of the reasons > > why I choose Maxima for many problems. > > > > It does however have one flaw. This concerns its treatment of > > constants. "f90()" writes them out for example as 968.0/11025.0 or 2896E > > +7. According to the Fortran standard these are single precision > > constants. While many compilers have command line options to promote > > constants from single to double (and sometimes to quad) precision, this > > is done globally, and therefore may not at all be desirable. > > > > This issue could easily be resolved by the addition of an argument to > > "f90()" which causes a character string to be added to all constants. > > For example assuming myfunction=2.3*x+1.2, then "f90(myfunction,_rp)" > > would result in > > > > 2.3_rp*x+1.2_rp > > > > which, assuming the Fortran program had > > > > integer, parameter :: rp = selected_real_kind(31) > > > > would result in 2.3 and 1.2 being represented in quad precision. This > > approach would allow arbitrary precision depending on the value for "rp" > > in the Fortran program. > > > > Cheers, > > Frank > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering New Technologies and Service 27 Gzhatskaya street, room 205 Saint Petersburg Russia, 195220 +79313075021 (cell) Фрэнк Херберт Малдун, к.ф.-м.н. Новые Технологии и Сервис 195220 г. Санкт-Петербург ул. Гжатская, д. 27, комната 205 +79313075021 (мобильный) fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html ```
 Re: [Maxima-discuss] f90 and precision of constants From: Richard Fateman - 2016-07-30 13:07:33 ```Here is a program to scan through the expressions and replace float constants. However f90 renders this as "1.23_rp" so you have to remove the quote marks. Maybe the option to f90() should be how to render literal strings, with or without quotes. This would be more general. rpize(v):=if ?floatp(v) then concat(v,"_rp") else v; e:1.2+2.3*x+cos(45.0+ 2*z); f90(fullmap(rpize,e)); cos(2*z+"45.0_rp")+"2.3_rp"*x+"1.2_rp" On 7/30/2016 1:07 AM, Frank Muldoon wrote: > Hello all, > > I write concerning the function "f90(expr_1, …, expr_n)" obtained from > "load (f90)\$". This is a very useful function and one of the reasons > why I choose Maxima for many problems. > > It does however have one flaw. This concerns its treatment of > constants. "f90()" writes them out for example as 968.0/11025.0 or 2896E > +7. According to the Fortran standard these are single precision > constants. While many compilers have command line options to promote > constants from single to double (and sometimes to quad) precision, this > is done globally, and therefore may not at all be desirable. > > This issue could easily be resolved by the addition of an argument to > "f90()" which causes a character string to be added to all constants. > For example assuming myfunction=2.3*x+1.2, then "f90(myfunction,_rp)" > would result in > > 2.3_rp*x+1.2_rp > > which, assuming the Fortran program had > > integer, parameter :: rp = selected_real_kind(31) > > would result in 2.3 and 1.2 being represented in quad precision. This > approach would allow arbitrary precision depending on the value for "rp" > in the Fortran program. > > Cheers, > Frank > ```
 [Maxima-discuss] f90 and precision of constants From: Frank Muldoon - 2016-07-30 09:07:23 ```Hello all, I write concerning the function "f90(expr_1, …, expr_n)" obtained from "load (f90)\$". This is a very useful function and one of the reasons why I choose Maxima for many problems. It does however have one flaw. This concerns its treatment of constants. "f90()" writes them out for example as 968.0/11025.0 or 2896E +7. According to the Fortran standard these are single precision constants. While many compilers have command line options to promote constants from single to double (and sometimes to quad) precision, this is done globally, and therefore may not at all be desirable. This issue could easily be resolved by the addition of an argument to "f90()" which causes a character string to be added to all constants. For example assuming myfunction=2.3*x+1.2, then "f90(myfunction,_rp)" would result in 2.3_rp*x+1.2_rp which, assuming the Fortran program had integer, parameter :: rp = selected_real_kind(31) would result in 2.3 and 1.2 being represented in quad precision. This approach would allow arbitrary precision depending on the value for "rp" in the Fortran program. Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering New Technologies and Service 27 Gzhatskaya street, room 205 Saint Petersburg Russia, 195220 +79313075021 (cell) Фрэнк Херберт Малдун, к.ф.-м.н. Новые Технологии и Сервис 195220 г. Санкт-Петербург ул. Гжатская, д. 27, комната 205 +79313075021 (мобильный) fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html ```
 Re: [Maxima-discuss] informative messages, was: Maxima CAS branch, master, updated. branch-5_38-base-189-g0ab4c89 From: Gunter Königsmann - 2016-07-30 06:43:26 ```Sorry that I wasn't able to answer earlier this time: Normally we try to make error messages as concise as possible - which is a good thing. This time, though, the manual contains no real help on resolving the problem since we don't document what we derive the location for maxout.gnuplot from => in order to be helpful this time the message needs to be longer. Actually I thought of adding code that first tests first if the path still contains maxima_tmpdir before adding the second half of this message. But I don't know if that would be exaggerated. Another TODO would be to document the environment variables maxima reads out at startup - and I think the .rc file maxima reads at startup isn't documented either. Don't know if the output of maxima --help or the manual would be the appropriate place to do so. For the "when": Give me again a little time to optimize that. Kind regards, Gunter. ```
 Re: [Maxima-discuss] rat(%i) doesn't act like %i; triangularize vs echelon From: Robert Dodier - 2016-07-30 00:57:53 ```On 2016-07-29, Robert Dodier wrote: > To fix bug #3158 I've copied the logic for binding algebraic from > echelon to triangularize. That seems to have the desired effect. I've pushed that as commit c9375b3. > I find that cutting out line 468 enables triangularize to return the > expected result for a matrix containing foo, and does not cause any > unexpected test failures. I'm investigating whether cutting out that > line has any unintended effects. After finding all the calls leading to ALGPCHK, it appears that there are two calls to ALGPGET in src/nalgfa.lisp which have potentially different behavior if line 468 in src/rat3e.lisp is removed. So I'm going to let it stand. I didn't know what nalgfa.lisp is about, but I found these notes: http://def.fe.up.pt/pipermail/maxima-discuss/2002/003302.html Perhaps that info could be adapted into some documentation -- it appears that nalgfa is entirely undocumented. I wasn't able to locate nalgfa.msgs or nalgfc.demo whose existence is hinted by an ancient tape: http://pdp-10.trailing-edge.com/SRI_NIC_PERM_SRC_3_19910112/01/utility/ps-perm.901006-01.html HTH Robert Dodier ```
 Re: [Maxima-discuss] rat(%i) doesn't act like %i; triangularize vs echelon From: Stavros Macrakis (Σταῦρος Μακράκης) - 2016-07-29 22:49:15 Attachments: Message as HTML ```PS rat/algebraic rationalizes variables in the denominator as a function of variable ordering: rat(1/(sqrt(x)-x)), ratvars=[sqrt(x),x], algebraic => -1/(x-sqrt(x)) but rat(1/(sqrt(x)-x)), ratvars=[x,sqrt(x)], algebraic => -(sqrt(x)+x)/(x^2-x) Similarly for rat(1/(sqrt(x)+sqrt(y)+x)),ratvars=[x,y,sqrt(y),sqrt(x)],algebraic rat(1/(sqrt(3)+sqrt(5)+x)),ratvars=[sqrt(3),sqrt(5)],algebraic etc. On Thu, Jul 28, 2016 at 8:37 PM, Stavros Macrakis (Σταῦρος Μακράκης) < macrakis@...> wrote: > That is working as designed, just like rat(sqrt(2))^2 => sqrt(2)^2. > > I wonder whether algebraic should be true by default. With modern > machines, no one will notice the execution time difference, which for that > matter only seems to affect expressions with algebraic parts (fractional > powers including %i). > > It does, however, give more complicated results in some cases. > > I am also not quite sure what it is supposed to do. > > rat(1/(sqrt(x)-1)), algebraic => (sqrt(x)+1)/(x-1) > > but > > > rat(1/(sqrt(x)-x)), algebraic => -1/(x-sqrt(x)) > > > where I would have expected it to rationalize the denominator: > > => -(x+sqrt(x))/(x^2-x) > > > > On Thu, Jul 28, 2016 at 5:55 PM, Robert Dodier > wrote: > >> It seems rat(%i) doesn't act the same as %i. >> >> (%i5) %i^2 + 1; >> (%o5) 0 >> (%i6) rat(%i)^2 + 1; >> (%o6) %i^2+1 >> >> algebraic:true helps Maxima get the expected result. >> >> (%i7) %, algebraic; >> (%o7) 0 >> >> It seems that part of the story is that RATREP* is replacing %i with a >> gensym, which might not have the same algebraic properties as %i. But >> then, why does algebraic:true help? I'm mystified. Anyway take a look: >> >> (%i8) rat(%i)^2 + 1; >> 1. Trace: (RATREP* '\$%I) >> 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 1 1) . >> 1) >> 1. Trace: (RATREP* '((MEXPT) ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 >> 1 1) . 1) 2)) >> 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 2 1) . >> 1) >> 1. Trace: (RATREP* '((MPLUS) ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 >> 2 1) . 1) 1)) >> 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 2 1 0 >> 1) . 1) >> (%o8) %i^2+1 >> >> I came across this while investigating bug #3158. >> https://sourceforge.net/p/maxima/bugs/3158/ >> >> In that case triangularize when called on a matrix containing %i gets an >> incorrect result. I find algebraic:true enables Maxima to get the >> correct result for that problem. >> >> Incidentally I see that echelon enables algebraic:true and gets the >> correct result for the matrix in #3158. Does anyone see why I shouldn't >> copy the logic for algebraic from echelon to triangularize? (Compare >> echelon and triangularize in src/matrix.lisp.) >> >> Thanks for any insights. >> >> Robert Dodier >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Maxima-discuss mailing list >> Maxima-discuss@... >> https://lists.sourceforge.net/lists/listinfo/maxima-discuss >> > > ```
 Re: [Maxima-discuss] rat(%i) doesn't act like %i; triangularize vs echelon From: Robert Dodier - 2016-07-29 22:25:19 ```On 2016-07-29, Stavros Macrakis wrote: > That is working as designed, just like rat(sqrt(2))^2 => sqrt(2)^2. OK, thanks for the info. To fix bug #3158 I've copied the logic for binding algebraic from echelon to triangularize. That seems to have the desired effect. Something I noticed about ALGPCHK in src/rat3e.lisp: echelon, triangularize, etc call ALGPCHK (via ALGP) to determine if algebraic should be enabled. But ALGPCHK quits early (line 468) if algebraic is disabled. Clearly that interferes with using ALGPCHK to decide if algebraic is needed; for example, tellrat(foo^2 + 1); triangularize(subst(%i=foo, M)); doesn't work the same as triangularize(M) where M is a matrix containing %i. I find that cutting out line 468 enables triangularize to return the expected result for a matrix containing foo, and does not cause any unexpected test failures. I'm investigating whether cutting out that line has any unintended effects. > I wonder whether algebraic should be true by default. As an experiment I enabled algebraic by default. As you might expect, many (some dozens) of tests come out differently. I looked at a few and it appears the results are equivalent but in a different form. At this time I'm not interested in changing the default value so I didn't look at it any more carefully than that. best Robert Dodier ```
 Re: [Maxima-discuss] informative messages, was: Maxima CAS branch, master, updated. branch-5_38-base-189-g0ab4c89 From: Kris Katterjohn - 2016-07-29 17:30:57 ```On Thu, Jul 28, 2016 at 04:12:53PM -0700, Raymond Toy wrote: > Robert> or perhaps just omit it -- after all the vast majority of error messages > Robert> in Maxima don't include any attempt at diagnosis or repair. As to > > I'm ok with no attempt at diagnosis or repair, but I strongly want > error messages to give me as much information as possible about why > the error happened. I agree. Cheers, Kris Katterjohn ```
 Re: [Maxima-discuss] Second order differential equation with boundary conditions From: Pablo Fonovich - 2016-07-29 17:07:57 Attachments: Message as HTML ```thanks! that works great. Now i should investigate a bit more every command you gave me. Thanks a lot! ________________________________ De: serge de marre Enviado: viernes, 29 de julio de 2016 11:16 a.m. Para: Pablo Fonovich Cc: maxima-discuss@... Asunto: Re: [Maxima-discuss] Second order differential equation with boundary conditions Hello, Indeed, bc2 seems to have an issue with the fact that the second boundary condition is expressed as a function of y, or at least I wasn't able to use bc2 to solve the equation. But you can use maxima to assist you in doing what you did by hand: subst([x=0,y=0],sol); gives you an equation in %k2, which you can solve: k2:solve(%)[1]; Now, for the second boundary condition, we substitute the solution for the differential equation and k2 into it: subst([sol,k2],-y='diff(y,x)); This equation still has an unevaluated diff, which we can evaluate like this: ev(%,nouns); This is only valid for x=1 (as per the second boundary condition), so: subst(x=1,%); This gives an equation in %k1, which we can solve: k2:solve(%)[1]; Finally, we can compute the solution to the boundary condition problem by putting k1 and k2 back into sol: subst([k1,k2],sol); serge On Thu, Jul 28, 2016 at 10:32 PM, Pablo Fonovich > wrote: Hi: I'm a begginer with maxima, and i want to solve this second order differential equation with boundary conditions: 'diff(y,x,2)+y+1=0 y=0 for x=0 'diff(y,x)=-y for x=1 Can i do this with bc2? i tried the following: eq: 'diff(y,x,2)+y+1=0; sol: ode2(eq,y,x); bc2: bc2(sol,x=0,y=0,x=1,'diff(y,x)=-y); but i'm getting a confusing result. By using the output of sol: ode2(eq,y,x); and applying the conditions by hand i arrived to the following solution: y=-1.2676*sen(x)+cos(x)-1 How could i achieve this with maxima? Thanks a lot ------------------------------------------------------------------------------ _______________________________________________ Maxima-discuss mailing list Maxima-discuss@... https://lists.sourceforge.net/lists/listinfo/maxima-discuss ```
 Re: [Maxima-discuss] extracting the matrix from a quadratic form From: Leo Butler - 2016-07-29 16:00:58 ```You want ? coefmatrix ===== Example: (%i1) h : sum(sum(A[j,i]*x[i]-a[j],i,1,2)^2,j,1,4); (%o1) (x[2]*A[4,2]+x[1]*A[4,1]-2*a[4])^2+(x[2]*A[3,2]+x[1]*A[3,1]-2*a[3])^2 +(x[2]*A[2,2]+x[1]*A[2,1]-2*a[2])^2 +(A[1,2]*x[2]+x[1]*A[1,1]-2*a[1])^2 (%i2) v : makelist(x[i],i,1,2)\$ (%i3) mgrad(f,v) := map(lambda([x],diff(f,x)),v)\$ (%i4) mgrad(h,v); (%o4) [2*A[4,1]*(x[2]*A[4,2]+x[1]*A[4,1]-2*a[4]) +2*A[3,1]*(x[2]*A[3,2]+x[1]*A[3,1]-2*a[3]) +2*A[2,1]*(x[2]*A[2,2]+x[1]*A[2,1]-2*a[2]) +2*A[1,1]*(A[1,2]*x[2]+x[1]*A[1,1]-2*a[1]), 2*A[4,2]*(x[2]*A[4,2]+x[1]*A[4,1]-2*a[4]) +2*A[3,2]*(x[2]*A[3,2]+x[1]*A[3,1]-2*a[3]) +2*A[2,2]*(x[2]*A[2,2]+x[1]*A[2,1]-2*a[2]) +2*A[1,2]*(A[1,2]*x[2]+x[1]*A[1,1]-2*a[1])] (%i5) coefmatrix(%,v); (%o5) matrix([2*A[4,1]^2+2*A[3,1]^2+2*A[2,1]^2+2*A[1,1]^2, 2*A[4,1]*A[4,2]+2*A[3,1]*A[3,2]+2*A[2,1]*A[2,2] +2*A[1,1]*A[1,2]], [2*A[4,1]*A[4,2]+2*A[3,1]*A[3,2]+2*A[2,1]*A[2,2]+2*A[1,1]*A[1,2], 2*A[4,2]^2+2*A[3,2]^2+2*A[2,2]^2+2*A[1,2]^2]) Here is how you would implement (a simple-minded) coefmatrix if maxima didn't already have it: (%i7) mycoefmatrix(e,v) := apply('matrix,outermap(ratcoef,e,v))\$ (%i8) mycoefmatrix(%o4,v); (%o8) matrix([2*A[4,1]^2+2*A[3,1]^2+2*A[2,1]^2+2*A[1,1]^2, 2*A[4,1]*A[4,2]+2*A[3,1]*A[3,2]+2*A[2,1]*A[2,2] +2*A[1,1]*A[1,2]], [2*A[4,1]*A[4,2]+2*A[3,1]*A[3,2]+2*A[2,1]*A[2,2]+2*A[1,1]*A[1,2], 2*A[4,2]^2+2*A[3,2]^2+2*A[2,2]^2+2*A[1,2]^2]) (%i9) %o8 - %o5; (%o9) matrix([0,0],[0,0]) Frank Muldoon writes: > Hello all, > > I have q question concerning extracting the matrix from a quadratic > form. > > I have an objective function of the form > > H(x_1,x_2,...x_N) = (x_1+x_2+...+x_N-a_1)^2+(x_1+x_2+...+x_N-a_2)^2 > +...+(x_1+x_2+...+x_N-a_N)^2 > > from which it is desired to find the minimum by differentiating wrt the > x's and setting the resulting gradient to zero: > > dH/dx_1 = > > ... > > dH/dx_N = > > > Since the function is quadratic in x, this of course can be written as > > Ax=b > > I can get to the stage of the gradient, and from that, by taking each > element of the gradient and setting each value of x to one in turn and > the rest to zero, can determine the matrix A. This however, requires > N^2 work. Is there perhaps a more elegant way to do this? Perhaps some > function exists that does this automatically? > > Cheers, > Frank ```
 Re: [Maxima-discuss] Second order differential equation with boundary conditions From: serge de marre - 2016-07-29 14:16:57 Attachments: Message as HTML ```Hello, Indeed, bc2 seems to have an issue with the fact that the second boundary condition is expressed as a function of y, or at least I wasn't able to use bc2 to solve the equation. But you can use maxima to assist you in doing what you did by hand: subst([x=0,y=0],sol); gives you an equation in %k2, which you can solve: k2:solve(%)[1]; Now, for the second boundary condition, we substitute the solution for the differential equation and k2 into it: subst([sol,k2],-y='diff(y,x)); This equation still has an unevaluated diff, which we can evaluate like this: ev(%,nouns); This is only valid for x=1 (as per the second boundary condition), so: subst(x=1,%); This gives an equation in %k1, which we can solve: k2:solve(%)[1]; Finally, we can compute the solution to the boundary condition problem by putting k1 and k2 back into sol: subst([k1,k2],sol); serge On Thu, Jul 28, 2016 at 10:32 PM, Pablo Fonovich wrote: > Hi: > > I'm a begginer with maxima, and i want to solve this second order > differential equation with boundary conditions: > > > 'diff(y,x,2)+y+1=0 > > y=0 for x=0 > > 'diff(y,x)=-y for x=1 > > > Can i do this with bc2? > > i tried the following: > > > eq: 'diff(y,x,2)+y+1=0; > > sol: ode2(eq,y,x); > > bc2: bc2(sol,x=0,y=0,x=1,'diff(y,x)=-y); > > > but i'm getting a confusing result. > > > By using the output of sol: ode2(eq,y,x); and applying the conditions by > hand i arrived to the following solution: > > y=-1.2676*sen(x)+cos(x)-1 > > > How could i achieve this with maxima? > > > Thanks a lot > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > > ```
 Re: [Maxima-discuss] atexit in maxima From: Richard Fateman - 2016-07-29 13:42:38 ```On 7/29/2016 5:09 AM, Michel Talon wrote: > Well, you write (unwind-protect .... > and where is the closing parenthesis, when you want to span a whole > session? Yes, I think you include the whole session in the unwind-protect. That is, say there is a program called something like "run" to start maxima within lisp.. (defun run()(unwind-protect (previous-definition-of-run) (cleanup-temp-files etc )) ;; new definition of run. ```
 Re: [Maxima-discuss] atexit in maxima From: Michel Talon - 2016-07-29 12:09:14 ```Le 29/07/2016 à 08:20, Gunter Königsmann a écrit : > I think one way to make sure that the file is kept long enough that we > are sure gnuplot can finish its work first would be to wrap the whole > maxima session within one big unwind-protect. > Actually having an atexit() function for maths would be quite an absurd > kind of concept feeling like "too much Mozart"... > Well, you write (unwind-protect .... and where is the closing parenthesis, when you want to span a whole session? Indeed i think that atexit is the correct solution, but since it is not a lisp primitive, you need to use alien calls to implement it (also called foreign functions). Since there is no uniformity in foreign function interfaces between various lisps, this may work only after having chosen a lisp variant, e.g. sbcl. One of the main strengths of python is that a large part of the unix system calls are wrapped in the language in a well documented way and are very easy to use. It is a pity that no such similar thing exists for at least the most popular lisp variant, namely sbcl. > In the meantime I have stumbled upon a additional problem: What if a > maxima batch file plots something big to a file and then ends in a > quit(): Linux will keep the file alive after it has officially already > been deleted in case that it has already been opened by gnuplot. We will > encounter bug reports about that. If a file is opened by two programs, and then one of these programs delete it, it is only deleted when the second program closes it, at least this is the way it works in Unix. -- Michel Talon ```
 [Maxima-discuss] extracting the matrix from a quadratic form From: Frank Muldoon - 2016-07-29 11:56:04 ```Hello all, I have q question concerning extracting the matrix from a quadratic form. I have an objective function of the form H(x_1,x_2,...x_N) = (x_1+x_2+...+x_N-a_1)^2+(x_1+x_2+...+x_N-a_2)^2 +...+(x_1+x_2+...+x_N-a_N)^2 from which it is desired to find the minimum by differentiating wrt the x's and setting the resulting gradient to zero: dH/dx_1 = ... dH/dx_N = Since the function is quadratic in x, this of course can be written as Ax=b I can get to the stage of the gradient, and from that, by taking each element of the gradient and setting each value of x to one in turn and the rest to zero, can determine the matrix A. This however, requires N^2 work. Is there perhaps a more elegant way to do this? Perhaps some function exists that does this automatically? Cheers, Frank -- Frank Herbert Muldoon, Ph.D. Mechanical Engineering New Technologies and Service 27 Gzhatskaya street, room 205 Saint Petersburg Russia, 195220 +79313075021 (cell) Фрэнк Херберт Малдун, к.ф.-м.н. Новые Технологии и Сервис 195220 г. Санкт-Петербург ул. Гжатская, д. 27, комната 205 +79313075021 (мобильный) fmuldoo (skype) http://tetra.fluid.tuwien.ac.at/fmuldoo/public_html/webpage/frank-muldoon.html ```
 Re: [Maxima-discuss] atexit in maxima From: Gunter Königsmann - 2016-07-29 10:54:28 ```> At least with sbcl there are a number of unix-like primitives which are > implemented, see > https://github.com/sbcl/sbcl/blob/master/src/code/unix.lisp > and provide essentially the same tools that come with "batteries > included" python. In particular the system call mkstemp is provided > see at lines 186-206. This is an interesting resource. But using undocumented stuff that isn't portable to other lisps for implementing a nice-to-have in a portable program that is meant for production use... > > Deleting these temporaries when exiting maxima is perhaps not obvious, > since wrapping the call in unwind-protect could serve to delete the file > immediately after use, but i don't see how it could keep the file > for the whole maxima session and then delete it. Unwind-protect is a cool concept I didn't know about. Quite like making c++ keep a spinlock alive for exactly the right amount of time by placing it within a block. I think one way to make sure that the file is kept long enough that we are sure gnuplot can finish its work first would be to wrap the whole maxima session within one big unwind-protect. Actually having an atexit() function for maths would be quite an absurd kind of concept feeling like "too much Mozart"... In the meantime I have stumbled upon a additional problem: What if a maxima batch file plots something big to a file and then ends in a quit(): Linux will keep the file alive after it has officially already been deleted in case that it has already been opened by gnuplot. We will encounter bug reports about that. Watching the life time of the gnuplot process instead? Currently I tend to think that Robert is right that the problem isn't big enough to justify the remedies I could think of. But unwind-protect really is nice. Thanks again! Kind regards, Gunter. ```
 Re: [Maxima-discuss] rat(%i) doesn't act like %i; triangularize vs echelon From: Stavros Macrakis (Σταῦρος Μακράκης) - 2016-07-29 00:37:12 Attachments: Message as HTML ```That is working as designed, just like rat(sqrt(2))^2 => sqrt(2)^2. I wonder whether algebraic should be true by default. With modern machines, no one will notice the execution time difference, which for that matter only seems to affect expressions with algebraic parts (fractional powers including %i). It does, however, give more complicated results in some cases. I am also not quite sure what it is supposed to do. rat(1/(sqrt(x)-1)), algebraic => (sqrt(x)+1)/(x-1) but rat(1/(sqrt(x)-x)), algebraic => -1/(x-sqrt(x)) where I would have expected it to rationalize the denominator: => -(x+sqrt(x))/(x^2-x) On Thu, Jul 28, 2016 at 5:55 PM, Robert Dodier wrote: > It seems rat(%i) doesn't act the same as %i. > > (%i5) %i^2 + 1; > (%o5) 0 > (%i6) rat(%i)^2 + 1; > (%o6) %i^2+1 > > algebraic:true helps Maxima get the expected result. > > (%i7) %, algebraic; > (%o7) 0 > > It seems that part of the story is that RATREP* is replacing %i with a > gensym, which might not have the same algebraic properties as %i. But > then, why does algebraic:true help? I'm mystified. Anyway take a look: > > (%i8) rat(%i)^2 + 1; > 1. Trace: (RATREP* '\$%I) > 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 1 1) . > 1) > 1. Trace: (RATREP* '((MEXPT) ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 1 > 1) . 1) 2)) > 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 2 1) . > 1) > 1. Trace: (RATREP* '((MPLUS) ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 2 > 1) . 1) 1)) > 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 2 1 0 1) > . 1) > (%o8) %i^2+1 > > I came across this while investigating bug #3158. > https://sourceforge.net/p/maxima/bugs/3158/ > > In that case triangularize when called on a matrix containing %i gets an > incorrect result. I find algebraic:true enables Maxima to get the > correct result for that problem. > > Incidentally I see that echelon enables algebraic:true and gets the > correct result for the matrix in #3158. Does anyone see why I shouldn't > copy the logic for algebraic from echelon to triangularize? (Compare > echelon and triangularize in src/matrix.lisp.) > > Thanks for any insights. > > Robert Dodier > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Maxima-discuss mailing list > Maxima-discuss@... > https://lists.sourceforge.net/lists/listinfo/maxima-discuss > ```
 Re: [Maxima-discuss] informative messages, was: Maxima CAS branch, master, updated. branch-5_38-base-189-g0ab4c89 From: Raymond Toy - 2016-07-28 23:13:06 ```>>>>> "Robert" == Robert Dodier writes: >> On Thu, Jul 28, 2016 at 2:39 AM, Gunter Königsmann >> >>> + (if (eql cmdstorage nil) >>> + (merror "draw: Cannot create file '~a'. Probably maxima_tempdir >>> doesn't point to a writable directory." gfn)) Robert> My comment on this is that it's preferable to carefully separate what's Robert> known and what's conjectured. In this case I'd prefer this: Robert> draw: cannot create temporary file '~a'. Robert> draw: perhaps maxima_tempdir doesn't point to a writeable directory. Didn't look, but if gfn is the full path, then I don't think it's really necessary to say anything else. It's pretty clear that the file can't be created and the user needs to figure out from the path why. Robert> or for the second one, Robert> draw: ensure that maxima_tempdir points to a writeable directory. Robert> or perhaps just omit it -- after all the vast majority of error messages Robert> in Maxima don't include any attempt at diagnosis or repair. As to I'm ok with no attempt at diagnosis or repair, but I strongly want error messages to give me as much information as possible about why the error happened. So, no messages like Failed to compute foo. But messages like Failed to compute foo because bar is not baz. or something. -- Ray ```
 Re: [Maxima-discuss] Pioneering MIT Computer Scientist, Robert Fano From: Raymond Toy - 2016-07-28 23:00:35 ```>>>>> "Berns" == Berns Buenaobra writes: Berns> Requiescat in Pace Dr. Fano classic engineer and scientist - thank you for laying many stepping Berns> stones of computing for the generations to come! And information theory! Including such things as the Fano algorithm for decoding convolutional codes that I studied way back when, and Shannon-Fano coding. -- Ray ```
 Re: [Maxima-discuss] Pioneering MIT Computer Scientist, Robert Fano From: Berns Buenaobra - 2016-07-28 21:58:22 Attachments: Message as HTML ```Requiescat in Pace Dr. Fano classic engineer and scientist - thank you for laying many stepping stones of computing for the generations to come! ```
 [Maxima-discuss] rat(%i) doesn't act like %i; triangularize vs echelon From: Robert Dodier - 2016-07-28 21:55:35 ```It seems rat(%i) doesn't act the same as %i. (%i5) %i^2 + 1; (%o5) 0 (%i6) rat(%i)^2 + 1; (%o6) %i^2+1 algebraic:true helps Maxima get the expected result. (%i7) %, algebraic; (%o7) 0 It seems that part of the story is that RATREP* is replacing %i with a gensym, which might not have the same algebraic properties as %i. But then, why does algebraic:true help? I'm mystified. Anyway take a look: (%i8) rat(%i)^2 + 1; 1. Trace: (RATREP* '\$%I) 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 1 1) . 1) 1. Trace: (RATREP* '((MEXPT) ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 1 1) . 1) 2)) 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 2 1) . 1) 1. Trace: (RATREP* '((MPLUS) ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 2 1) . 1) 1)) 1. Trace: RATREP* ==> ((MRAT SIMP (\$%I) (#:%I18793)) (#:%I18793 2 1 0 1) . 1) (%o8) %i^2+1 I came across this while investigating bug #3158. https://sourceforge.net/p/maxima/bugs/3158/ In that case triangularize when called on a matrix containing %i gets an incorrect result. I find algebraic:true enables Maxima to get the correct result for that problem. Incidentally I see that echelon enables algebraic:true and gets the correct result for the matrix in #3158. Does anyone see why I shouldn't copy the logic for algebraic from echelon to triangularize? (Compare echelon and triangularize in src/matrix.lisp.) Thanks for any insights. Robert Dodier ```
 [Maxima-discuss] informative messages, was: Maxima CAS branch, master, updated. branch-5_38-base-189-g0ab4c89 From: Robert Dodier - 2016-07-28 21:28:33 ```> On Thu, Jul 28, 2016 at 2:39 AM, Gunter Königsmann > >> + (if (eql cmdstorage nil) >> + (merror "draw: Cannot create file '~a'. Probably maxima_tempdir >> doesn't point to a writable directory." gfn)) My comment on this is that it's preferable to carefully separate what's known and what's conjectured. In this case I'd prefer this: draw: cannot create temporary file '~a'. draw: perhaps maxima_tempdir doesn't point to a writeable directory. or for the second one, draw: ensure that maxima_tempdir points to a writeable directory. or perhaps just omit it -- after all the vast majority of error messages in Maxima don't include any attempt at diagnosis or repair. As to whether that state of affairs is desirable, I won't speculate here. best Robert Dodier ```

Showing results of 12349

<< < 1 .. 73 74 75 76 77 .. 494 > >> (Page 75 of 494)