[go: up one dir, main page]
Menu ▾ ▴

#180 Reduce references undefined term.

open
nobody
None
5
2025-06-22
2025-06-21
videohead
No

Hi reduce devs,

When I run the following script in Reduce CSL rev 5890 it outputs a file tmp.log.

Line 158 of this file contains the line

g149 := g10**(1/3)$

The term g10 is not defined anywhere.

This problem does not happen when I replace 1/3 with the term k.

Regards.

1 Attachments
bug.red

Discussion

  • videohead

    videohead - 2025-06-22

    I take that back. Problem not solved.

    I now have a situation where g10 is referenced before it is defined

    g209 := g882*g10$
g211 := g881*g10$
g926 := g924*j$
g213 := g926*g10$
g525 := g13*g10$
g928 := g1174*g10$
... % skip eight lines
g10 := ((g1441 + g1381 + g1059 - g1437*DvDX + g1210*DwDZ)/g13)**k$
     

    • Arthur Norman

      Arthur Norman - 2025-06-22

      In your first test file maybe the first thing to say is that without
      "optimize" the results are very voluminous but with they are a lot better.
      However your "missing definition of g10" looks like a clear-cut bug in the
      "scope" package.

      The code impleme4nting that seems to date from 1981 and 1983 (see
      scope/codopt.red that points to papers that describe how it works) and
      it is not clear that the the originators are immediatly available to
      investigate! Of course all the code is there in the source tree:
      .../reduce-algebra/packages/scope/*.red
      and if one idenbtifies key functions it is possible to ask that they
      be traced as things go...
      tr extbrsea, redcodmat, findhr, addcse;
      (or whatever - those are just sample procedure names) so it will be
      neecessary to sort of what procedure4s are called in the bad case. This
      will be MUCH kess hideous if the example is small!

      So what would be really helpful from you both with the "missing g10" case
      and your "g10 not defined soon enough" case would be all you can manage to
      find as smallest example of bad behaviour as you can.

      As a comment to other who may be willing to dive into the code to try to
      see what is going in, my attention fell on line around 47 of codmat.red
      that reads
      for j:=inb:nb do gensym() >>
      which seems liks an oddity to me since I do not expect gensym() to have a
      side-effect...
      I also tried using redpsl rather than redcsl and the "g10" issue is also
      there (suggesting this not terribly system dependent) but then all the
      upper case letters come out escaped which may or may not be what was
      wanted but is certainly another "oddity".

      Anyway please see if you can find a tiny example possibly starting by
      trimming what you have for so long as bad things remain, but if you can
      reduce things yet further bu guessing what in your input triggers problems
      using that...

      Arthur

      On Sun, 22 Jun 2025, videohead wrote:

      I take that back. Problem not solved.

      I now have a situation where g10 is referenced before it is defined
      ~~~
      g209 := g882g10$
      g211 := g881      g10$
      g926 := g924j$
      g213 := g926      g10$
      g525 := g13g10$
      g928 := g1174      g10$
      ... % skip eight lines
      g10 := ((g1441 + g1381 + g1059 - g1437DvDX + g1210DwDZ)/g13)**k$
      ~~~

       

      • Arthur Norman

        Arthur Norman - 2025-06-22

        Eg here is a somewhat trimmed down version. It will be good to see if it
        can be cut down yet further...

        off fancy,raise,lower;
        on echo;

        load_package scope;

        depend(DvDX, x4, x11);
        depend(DvDY, x4, x11);
        depend(DvDZ, x4, x11);

        F := mat((1,0,0),(0,1,0),(0,0,1)) +
        mat((DuDX,DuDY,DuDZ), (DvDX, DvDY,DvDZ),(DwDX,DwDY,DwDZ))/j;
        J := det(F);
        B := F*tp(F);

        B11 := B(1,1);

        I1 := B11;
        I1bar := I1/J^(2/3);

        off nat;

        vDI1barDx11 := df(I1bar,x11);
        vDI1barDx4 := df(I1bar,x4);

        optimize
        DI1barDx11 :=: vDI1barDx11,
        DI1barDx4 :=: vDI1barDx4;

        end;

         

  • videohead

    videohead - 2025-06-22

    The g10 problem only appears when J has an exponent.

    No such problem occurs when I1bar := I1/J;

     

    • videohead

      videohead - 2025-06-22

      I found a hack. The problem seems to be arise with the divisor in the quotient rule, therefore I optimized it separately as shown below:

      optimize
DI1barDx11_ :=: (J^k*df(I1, x11) - I1*df(J^k, x11)), %/J^(2*k),
DI1barDx4_ :=: (J^k*df(I1, x4) - I1*df(J^k, x4)), %/J^(2*k),
den :=: J^(2*k);

      No undefined g10 term appears in this case.

       

    • Arthur Norman

      Arthur Norman - 2025-06-22

      Thank you. Can you find a smaller thing that goes into I1 (with an
      exponent for J) that causes pain? Even the cut-down version I got still
      generated somewhat over 100 lines of output. One that failed while
      generating just a dozen would be much nicer for somebody who needs to dig
      into that code from a cold start to use!
      Arthur

      On Sun, 22 Jun 2025, videohead wrote:

      The g10 problem only appears when J has an exponent.
      No such problem occurs when I1bar := I1/J;

       

      • videohead

        videohead - 2025-06-22

        Yes I have.

        off echo, fancy,raise,lower;

load_package scope;

depend(DvDX, x4, x11);

J := DuDY*DvDX*DwDZ - DuDX*DvDZ*DwDY + DuDX*DvDY*DwDZ$

I1bar := 1/J^k;

off nat;

on echo$

optimize
DI1barDx11 :=: df(I1bar,x11),
DI1barDx4 :=: df(I1bar,x4);

end;

        Output (excerpt):

        ...
g13 := g5*DuDX$
g14 := DwDY*DvDZ$
g16 := DvDY*DwDZ$
g5 := (g11 + DuDX*(g16 - g14))**k$
...

        g5 is now the erring term.

         

        Last edit: videohead 2025-06-22

        • Arthur Norman

          Arthur Norman - 2025-06-22

          Thank you very much! Thaty now looks small enough that to work through and
          try to understand why g5 gets used before it is defined might be
          feasible!!!

          But with a bit more trial I can shrink it yet further

          on echo;
          off nat;
          load scope;

          KK := (DXEY - DXEZ + DYEX)k *
          (DX          EY - DX          EZ + DYEX);

          w11 := zx11 / KK;
          w4 := zx4 / KK;

          optimize
          m11 :=: w11,
          m4 :=: w4;

          end;

          For me the output now comes as just 5 lines:

          g8 := g3dx$
          g3 := (dyex + dx          (ey - ez))k$
          g6 := dyex          g3 - g8          ez + g8*ey$
          m11 := zx11/g6$
          m4 := zx4/g6$

          but see that g3 is used before it is set.

          It is now too late for me to start investigating the4 path it all takes
          and there are several other "distractions" I have over the next few days
          so since you managed to find a work-around for your particular case I will
          get see about looking into this som emore SOME TIME rather than instantly,
          but also maybe it the test case is small enough that somebody else on the
          list will feel like diving in...

          Arthur

           

Log in to post a comment.