Re: [lmi] An experimental change for withdrawal solves

[Greg Chicares]

On 2009-02-17 19:57Z, Murphy, Kimberly wrote:
> Greg Chicares wrote:
>> [...]
>> > Perhaps the approach used for
>> > loans could be made to serve for withdrawals, too.
>> 
>> Implemented in cvs on 20090209T1605Z.
> 
> Consider:  
>   F | N | I
>   solve for withdrawal - from retirement to maturity,
>                          target $0 at maturity
>   generic product
>   $100,000 specified amount
>   individual payment - 1285 retirement; 0
>   default values for all other data
> 
> The system returns an illustration with no withdrawals. 
> However, I did not receive any message to indicate why.

I can confirm the behavior. But I can't reproduce it with this
particular testcase; first, I'd like to understand why. Did you
use cvs HEAD as of the posting date? Do you have a 'default.ill'
file that could give you different defaults than I have, given
that I use no such file? (If it's a 'default.ill' issue, then
maybe we should have a way to suppress it, to make it easier to
report problems reproducibly.) I tried entering the case twice;
I'll send you my attempts in personal mail.

However, I already had a testcase of my own that reproduces this
behavior with current HEAD, giving

  iteration 26 iterand 99.96 value 2212507.550000002
  iteration 27 iterand 100.03 value -1000100.03
  iteration 28 iterand 100 value -1000100
  iteration 29 iterand 99.98 value 2212507.550000002
  iteration 30 iterand 99.99 value 2212507.550000002

which is essentially the same as what you're seeing:

> Using 'idiosyncrasyT', I see these results in 
> 'trace.txt':
> 
>    iteration 21 iterand 99.95 value 25343.43
>    iteration 22 iterand 100 value -99333.0900000001
>    iteration 23 iterand 99.96 value 25343.43
>    iteration 24 iterand 99.98 value 25343.43
>    iteration 25 iterand 99.99 value 25343.43
> 
> It appears that once the system finds the solution falls 
> below the product's minimum withdrawal amount, the system 
> stops future iterations. The system cannot state "Solution 
> not found, using zero instead" because it does find a 
> solution, just one that isn't optimal.

The minimum is $100. Presumably you crafted your testcase
(as I did mine) to produce a maximum lower than that, which is
possible as noted here:

http://cvs.savannah.gnu.org/viewvc/lmi/lmi/ihs_avmly.cpp?r1=1.119&r2=1.120

/// If the (dynamic) maximum withdrawal would be less than the
/// (fixed) minimum, then the maximum becomes zero.

If you've got only twelve dollars in your bank account, and the
ATM has a minimum transaction limit of twenty dollars, then you
can't get anything from the ATM.

> IMO, the system 
> should return some message similar to "Solution found 
> violates minimum withdrawal, using zero instead".

I noticed the lack of an error message when the maximum crossed
the minimum, but figured it wasn't so bad: after all, if I run
the same testcase, but with an explicit $100 withdrawal instead
of a solve, I get no error message and no withdrawal.

OTOH, there is a difference between those two scenarios:

 - If you explicitly ask for what you cannot get, you probably
   don't want a messagebox--it's distracting.

 - If you ask the system to solve a problem, and the problem has
   no solution, then it normally tells you so. To exclude, in
   effect, the case where the infeasibility is concealed--because
   a $99.99 requested withdrawal is silently turned into $0--is
   perhaps a little too precious.

Please test the patch below [0]. Without it, my testcase began:

iteration 0 iterand 0 value 2212507.550000002
iteration 1 iterand 999999999.99 value -1000999999.99

   iterand 999999999.99 [the withdrawal being tried]
 + value -1000999999.99 [the objective function]
 =             -1000000 [the target CSV]

so the whole trial value is considered ullage. But the maximum
ullage in a barrel that's too small to hold anything is zero:
that's what the patch aims to say, and with that patch, I get:

iteration 0 iterand 0 value 2212507.550000002
iteration 1 iterand 999999999.99 value 2212507.550000002

at which point iteration halts with the usual message:
  Solution not found: using zero instead.

> If I change the premium just a little:
> 1423 retirement; 0
> 
> I receive: "Solution not found, using zero instead".

I would suppose that in that (modified) case, the maximum didn't
cross the minimum. If the patch is correct, failure is reported
uniformly regardless of the underlying cause.

---------

[0] "the patch below"

Index: ihs_avmly.cpp
===================================================================
RCS file: /sources/lmi/lmi/ihs_avmly.cpp,v
retrieving revision 1.120
diff -U 3 -r1.120 ihs_avmly.cpp
--- ihs_avmly.cpp       16 Feb 2009 10:27:28 -0000      1.120
+++ ihs_avmly.cpp       18 Feb 2009 12:58:02 -0000
@@ -2766,6 +2766,10 @@
     if(Solving)
         {
         withdrawal_ullage_[Year] = std::max(0.0, RequestedWD - MaxWD);
+        if(0.0 == MaxWD)
+            {
+            withdrawal_ullage_[Year] = 0.0;
+            }
         }

     if(Solving || mce_run_gen_curr_sep_full == RunBasis_)