gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: precalc_first


From: al davis
Subject: Re: precalc_first
Date: Sat, 17 Apr 2021 21:40:30 -0400

> On Mon, Apr 12, 2021 at 07:36:43PM -0400, al davis wrote:
> > I think a different test would show that wherever first is needed, last
> > is also.

I'm wrong there.

The whole reason for first and last is that some calculations must be
done before expand because the result is needed by expand, and some
must be done after, because they require what was done by expand.  By
"expand" here I mean the whole set of allocation stuff.

On Tue, 13 Apr 2021 17:37:50 +0200
Felix Salfelder <felix@salfelder.org> wrote:
> Are you suggesting to call both of the precalcs from list_save, instead
> of just first? I tried and it exposes a few bugs, e.g. in bm_table...
> 
> Perhaps it makes sense to fix those bugs, it just needs work. Not sure
> if this is the right direction. Do any other plans depend on it?

No .. they are not really bugs.

It is now evident that anything with a print_test, or possible return
from param_is_printable that might depend on something done in precalc
must be in precalc_first.

That was the intent.  I forgot since  it was so long ago.  This is
consistent with:
http://gnucap.org/dokuwiki/doku.php/gnucap:manual:tech:plugins:devices:allocation_and_setup

In most cases, param_is_printable just returns true, so strictly it
doesn't matter, which is why some are in last that it seems should be
in first.  

It seems existing code always puts model parameter evaluation in first and 
usually puts instance parameter evaluation in last.  The reason for that is 
that it is possible that evaluation of an instance parameter might depend on a 
model parameter, so models first  instances last guarantees that the model 
parameters have already been evaluated before any of its instances.

So except for the initial question, it is correct as is.  

One thing that does need to be corrected, which would appear to fix the initial 
issue here, is that if a parameter has_hard_value, it should always be printed. 
 As it stands, if there is some other test (like has_good_value or xx == 0) 
even a hard value would be suppressed.  I see two ways to fix ..  One is to 
change all print_test in the ,model files to add "has_hard_value()||".  The 
other is to add it to modelgen or in the code that calls param_is_printable().




reply via email to

[Prev in Thread] Current Thread [Next in Thread]