[ts-gen] currency crosses now work [was: adding new-expiry ...]

[Bill Pippin]

Nils,

Thanks much for this report; I believe it's an excellent example of how
you and the rest of our user community help us produce a better shim.

Since I'm unsure if you are facing multiple problems, I'll give a
detailed explanation of my analysis.  The short answer may well turn
out to be that the patch below is sufficient; though please read on
to decide if you want to look elsewhere for additional problems.
Once having read this post, though, you should start by applying the
following patch to lib/text.c, recompiling, and trying your order
again with a paper account.  

*** old/lib/text.c	Wed Mar 11 10:42:42 2009
--- new/lib/text.c	Mon Apr 13 11:42:01 2009
***************
*** 128,134 ****
  Sig(nat)    { append("%u"  , t); return self; }
  Sig(Long)   { append("%llu", t); return self; }
  Sig(bool)   { append("%u"  , t); return self; }
! Sig(double) { append("%.2f", t); return self; }
  Sig(char_0) {   copy(t);         return self; }
  
  #undef  Sig
--- 128,134 ----
  Sig(nat)    { append("%u"  , t); return self; }
  Sig(Long)   { append("%llu", t); return self; }
  Sig(bool)   { append("%u"  , t); return self; }
! Sig(double) { append("%.4f", t); return self; }
  Sig(char_0) {   copy(t);         return self; }
  
  #undef  Sig
________________________________________________________________________

Now, the analysis: the dataflow for an order starting from the
downstream command is:

1.     |command text|
             |
A.       <scanner>
             |
2.     |ChangeOrder|    -> database
             |
B.   <request mapping>
             |
3.     |wire layout|    -> log text
             |
C. <IB tws process, etc.>
             |
4.   |Open Order, etc|  -> log text, database

In the ascii diagram above, and speaking loosely, the numbered steps
correspond to objects, or at least visible formatted data; and the
lettered steps, to processing operations.  Of course the dataflow
can be broken down into finer levels of detail, but this should be
fine for our purposes.

I believed you were seeing one of three things:

    I.   An artifact, i.e., the log format looses precision, but
         the order wire layout does not; or

    II.  An identifiable loss of precision outside the IB tws and
         its upstream, that is 1-A-2, or 2-B-3; or else

    III. An apparently inexplicable loss of precision with the 
         IB tws or its upstream, with the IB tws looking like an
         intermittent blackhole for significant figures.

If I understood your post correctly, you'd already ruled out (I).
Using a modified risk.rb script, and checking that the journal
stores the full precision of the order, I ruled out 1-A-2; and
checking the log, and using the bin/req.filter script to translate
the shim2tws.bin trace file, it was clear that 2-B-3 was at least
part of the problem; and the resulting patch fixes the loss of
precision in wire layout.  You can double check yourself after
patching by comparing the log file and your journal.

Due to the symbol-specific nature of your problem, I originally
suspected, however, that you were facing (III).  I still don't see
how you could have been seeing intermittent symptoms; I would have
expected consistent failure to use more than two significant figures
in the limit price and aux price attributes.

By the way, you'll still see many floating point message attributes
with other precision formats, even after applying the patch above; the
shim tries to preserve input as read from the wire, with most
formatting limited to whitespace layout.

If you still have other problems after applying the patch, there may
well be some factor in the way the shim lays out the contract
description on the wire that also contributes to the problem, though
I'm not sure what it might be; the problem may possibly have to do
with the contract multiplier, or perhaps the price magnifier.

In the case of additional problems, that is, the place order wire layout
has greater precision than comes back in order status messages, so the
problem class seems to be (III), please consider using the IB sample
client to investigate, to see if you can duplicate the symptoms, fix it
there, and let us know on the list so a full fix can be applied to the
shim.

I.e., take the wire layout as echoed to the log, and enter it by hand
into the IB sample client.  If this duplicates the problem, then try
varying the order and contract parameters to fix the problem.  Otherwise,
in the unlikely case that you can't reproduce a class (III) problem with
the sample client, and you've already ruled out (I) and (II), something
very odd is going on, and be sure to let us know.

You shouldn't need to look into the issue this way, since the patch
above hopefully solved your problem, but if you still have problems
after applying the patch, and you're not able to figure out what's
happening using the IB sample client, please let me know via the list,
and I'll look into it furthur myself.

As for the patch, it will of course be included in the next release of
the shim.  In addition, and a more flexible fix, I intend eventually
to add an FpFormat configuration string to the shimrc file name value
language.  Because of initialization dependencies --- all buffers are
setup before the config file is read, and in any case, some of them
must already be useable --- it may be awhile.  Please speak up on the
list if this is a problem, and feel free to patch with other formats
if you desire.

In any case, I'd like to know what you find.  Thanks again for the
report.

Thanks,

Bill