output format request or "div&quo...

Developers
James
2011-04-24
2012-11-20
  • James
    James
    2011-04-24

    I've been playing with the output mode switches, trying to find some combination that displays the way I like, but cannot quite get the format I want.  Consider the expression "sigma0 := a1 - b1/r^2 - ((3 + nu1)/8) * rho1 * omega^2 * r^2;"  Is there any way to have that display in that form, as here entered?

    With "on div;off exp;", it comes close, giving, with "off nat", "- 1/8*((nu1 + 3)*omega**2*r**4*rho1 + 8*b1 - 8*a1*r**2)*r**(-2)".  So, either, with "off exp;" there is this "- 1/8*r^(-2)" factor that is not distributed across the terms in parenthesis, or, with "on exp;", the "(nu1 + 3)" factor gets multiplied out.

    Hmm - I suppose that I want the "outer" "- 1/8*r^(-2)" factor distributed across the parenthetic terms, but not the "inner" "omega^2*r^4*rho1" term.  But then, it is really this divisor term, this "- 1/8*r^(-2)", that is at issue here.  When setting "on div;", I might have expected this divisor term to simply be applied to each numerator term individually.  But no - this divisor term is simply "wrapped around" the parenthetic numerator, in this case.  Is that a bug with the "div" switch function?

    For instance, if all the original terms are made positive, so that there is no "-" outside the parenthesis, then, setting "on div;", the "1/8" factor is taken inside the parenthesis, but not the "r^(-2)" factor.  That suggests to me that the "div" switch is, at least, a little confused by the minus sign outside the parenthesis.  And, it may be that the "div" switch is also a little confused by that minus sign in the "r^(-2)" exponent.  If the "-2" exponent is changed to "+2", then the "1/8" factor is again pulled outside the parenthesis.  Like, it works sometimes one way, but, in other circumstances, another way.  Is the "div" switch being confused by the parenthesis in the numerator?

    And here, the "on gcd;" switch does not help.

    So, I am either reporting a bug in the "div" switch, or I am requesting something similar to, but different from, the "div" switch functionality.  Or, am I missing some proper combination of output switches?  Any thoughts?

    Thanks
    James

     
  • James
    James
    2011-04-24

    Hmm - so this is odd.  I had actually entered two expressions when I was playing with this.  The second expression was similar, "sigma1 := A1 + B1/r^2 - ((1 + 3*nu1)/8) * rho1*omega^2*r^2;".  After having changed the first earlier expression, once so that all the terms were positive, and then so that "r^(-2)" changed to "r^2", to see what would happen, I re-entered the original first expression, the "sigma0 := A1 - B1/r^2 - ((3 +   nu1)/8) * rho1*omega^2*r^2;".  Lo and behold, the output format of the first expression, which previously had been the same as for the second expression, is now completely different.  Ha!  But that is not good.  What changed?

    I know that the first expression has been redefined several times while playing with the format, but the second expression was only entered once.  I also know that the difference is not the result of just some inadvertent change in the switch configurations, because whatever the switch configuration, it is being applied to both otherwise similar expressions at the same time.

    The two very similar expressions now look like "r**(-2)*(a1*r**2 - b1 - 1/8*(nu1 + 3)*omega**2*r**4*rho1)" and "- 1/8*((3*nu1 + 1)*omega**2*r**4*rho1 - 8*b1 - 8*a1*r**2)*r**(-2)".  In the first expression, the order of terms has been reversed, and the "-1/8" term has been taken inside the parenthesis.  The first "sigma0" expression has "magically" changed format, but the second "sigma1" expression format is still very much like the first expression format had been, before re-entering the "sigma0" expression.  The output here is being generated from the command "sigma0;sigma1;".

    Amusingly, the "revpri" switch will swap the ordering of both expressions, but not change the format of the "-1/8" factor, giving "r**(-2)*( - 1/8*(3 + nu1)*omega**2*r**4*rho1 - b1 + a1*r**2)" and "- 1/8*( - 8*a1*r**2 - 8*b1 + (1 + 3*nu1)*omega**2*r**4*rho1)*r**(-2)".

    And then,  turning off again the "revpri" switch, and now setting "off allfac", there is no effect at all on the second "sigma1" expression, but the first "sigma0" expression format is changed, with the "r^(-2)" factor being distributed partially, giving now "(a1*r**2 - b1)*r**(-2) - 1/8*(nu1 + 3)*omega**2*r**2*rho1" for "sigma0", but unchanged, "- 1/8*((3*nu1 + 1)*omega**2*r**4*rho1 - 8*b1 - 8*a1*r**2)*r**(-2)" for "sigma1".

    Something does not seem right about this unpredictable variability in the output formating, especially where re-entering the exact same expression causes a completely different output format.  It all seems a bit "capricious", even though the expressions are equivalent in all cases.

    Any thoughts?

    Thanks
    James

     
  • James
    James
    2011-05-12

    I just ran across another "format variation", this one giving a visually incorrect display, because of missing parenthesis.  I have "sqrt(2/s);", which - when "reduce" first starts, and with "on rounded;" and "fancy" still on - displays as "2^0.5/s", with the "0.5" up against the "2", and no parenthesis.  Note that the entered expression is NOT "sqrt(2/s^2)"!  But, with "off fancy;", the display is then correct, showing "(2/s)^0.5", with the parenthesis in place.  With "off rounded;", the display shows the "2/s" under a radical.

    Another problem, "sometimes" - I have not yet found a way to reliably reproduce some as yet unknown internal change of state - the above equation will display as "s^-1/2 radical 2" in fancy mode, or as "s**(( - 1)/2)*sqrt(2)" with "off nat;".

    I also ran across another problem, which may be related to, or the cause of, some of these display problems.  Again, "sometimes", I have entered "on div;", and there has been no change to the "div" setting in the "Switch" drop-down menu.  But then, "checking div" in the drop-down menu does then show the "tick-mark" in the menu, but also completely fails to change the display format, where, as above, if the display were to be in the form "s**(( - 1)/2)*sqrt(2)", then "off div;" will change the display format to "sqrt(2)/sqrt(s)".

    It suddenly occurs to me that this must also have something to do with "reduce" applying a rule - or sometimes NOT applying a rule, to change "sqrt(2/s)" into "sqrt(2)/sqrt(s)", as mentioned in another thread 'sqrt problems in "rounded" mode'.  Is it possible that there is some inaccessible internal state associated with "precise" mode?  Or that, like the "div" mode, the internal state fails to change with the command "on/off"?  That could explain some of these "mysterious" display format changes.

    And could there also be some kind of program flow mix-up around this routine which would otherwise change "sqrt(2/s)" into "sqrt(2)/sqrt(s)" which would explain the "loss" of some otherwise necessary parenthesis in "fancy" mode?

    James

     
  • James
    James
    2011-05-12

    A little correction - I notice that, if I enter "sqrt(2)/sqrt(s);" instead, when "reduce" is NOT changing "sqrt(2/s)" to that format, then "on div;" does change the display format.  It just fails to set the "tick-mark" in the "Switch" drop-down menu.  Unfortunately, that means that looking at the drop-down menu settings will not be a reliable indicator of the internal state of "reduce".  Is there some other way to dump the internal "switch" state, that might be "more honest"?  Is internal state being kept in more than one location?  Or maybe there are effectively conflicting rules in operation?  Just making guesses…

    James

     
  • Arthur Norman
    Arthur Norman
    2011-05-12

    The "fancy" display mode relies on the tmprint.red package to lay things out. The sqrt(2/s) in on rounded mode generated TeX as \frac{2}s^{0.5} and that leads to the oddity you observe. The use that tmprint thus gets by being part of the default rendering pipeline in the CSL version reveals all sorts of cases it had not quite got right! So the missing parents are liable to be JUST to do with output rendering, and you may wish to go "off fancy" to get back into older display code that may do better. I try to look at tmprint.red every so often, but while I have worked on it it did not start as my code and I have trouble wrapping my mind round bits of it. Would anybody like to volunteer to help?

    If you use the switch drop-down to set or clear switches then that keeps in step. If you set them by hand it may not!

    Arthur

     
  • James
    James
    2011-05-13

    Thanks Arthur.
    >  you may wish to go "off fancy" to get back into older display code
    Nooooo!  I like "fancy".  I'll just have to "take it with a grain of salt", so to speak.  Ha!

    > it did not start as my code and I have trouble wrapping my mind round bits of it. Would anybody like to volunteer
    I suppose I will have to learn RLISP at some point!

    > If you use the switch drop-down to set or clear switches then that keeps in step. If you set them by hand it may not!
    But that's scary, eh?

    Do you suppose writing an "internal state dump" function would be difficult?  Is the internal state all in one place?  or "scattered around"?

    On Google, I see "RLisp is a Lisp dialect naturally embedded in Ruby".  I assume that this is no relation?  And I also see there is a book, "RLISP '88: an evolutionary approach to program design and reuse" By Jed Marti, but there does not seem to be much online…

    James

     
  • Arthur Norman
    Arthur Norman
    2011-05-14

    The info about switch values is distributed, but I already had code that collects it. I just checked in an update that makes that happen more often! But to get it activated you need to recompile FOX. Easiest is to delere the cslbuild dircetory then re-configure. Smarter is to go into cslbuild/<arch>/fox and go "make install" by hand. While I was at it I also updated the list of packages and switches that appear in those menus to reflect a year of extra features.

    Rlisp with an "R" for Ruby is merely a name clash. The Jed Marti rlisp88 book is about what rlisp might have moved to around then but the weight of existing code means that the version used within Reduce does not do all that. The PDF form of a Reduce manual in trunk/doc/util/r38.pdf still says "Reduce 3.8" but neverthless is relevant and documents the syntax. The list of functions you can be very certain of having available from the Lisp is as per trunk/doc/misc/sl.pdf

    Obviously the Reduce sources themselves provide a range of examples (some cleaner than others). And as you see you can ask here if something hurts you. Very typically reading code is easier than writing in that you can often GUESS what it means. And learning to add a line that says
        princ "I get to this point, and the value of x is "; print x;
    to your private copy of something so you can trace it is not terribly deep… once you get started it is not too bad.

    I have a pile of students here starting to panic about exams, so just what I get done how fast over the next month is way uncertain!

    Arthur

     
  • Arthur Norman
    Arthur Norman
    2011-05-15

    I just checked in a patch to tmprint.red that should put parens in expt(quotient(2,s), 0.5). If anybody spots it wrecking other cases please tell me. This patch doe snot mean that there may not be other similar bad things in there!