Re[2]: [lmi] assert in stratified_entity::assert_validity()

[Vadim Zeitlin]

On Sat, 31 Jul 2010 14:35:35 +0000 Greg Chicares <address@hidden> wrote:

GC> > Would you know of an explanation as to why this happens by chance? I did
GC> > regenerate the project files, including sample.strata from which the
GC> > offending value is being read by stratified_charges ctor, using
GC> > product_files. Should I do something else to fix this?
GC> 
GC> That's the right way. Every '</limits>' should be preceded by
GC> '<item>inf</item>':
GC> 
GC> $grep -B1 '</limits>' sample.strata |sed '/item/!d' |uniq; echo END
GC>       <item>inf</item>
GC> END

 Thanks for the hint, this allowed me to see the problem: I had
<item>1</item> everywhere.

GC> > Or is it some artefact of MSVC build (I didn't test under Linux yet
GC> > because I still didn't finish my floating point changes there)?
GC> 
GC> Oh...msvc...and you observe a value equal to one...sounds like the
GC> problem I found with the OS's 'msvcrt.dll'. I figured they would
GC> have fixed that in their commercial compiler, which provides its
GC> own updated runtime.
GC> 
GC> 'numeric_io_test.cpp':
GC>     // This test fails for como with msvcrt, because the latter
GC>     // defectively prints infinity as "1.#INF". Distressingly,
GC>     // that converts to '1.0'.
GC>     BOOST_TEST_EQUAL(inf_dbl, numeric_io_cast<double>(inf_str));

 This does look like the same issue. Should I look into fixing it or just
use the MinGW version of product_files.exe which does produce the correct
files (which surprises me a little as I thought it used the same CRT but
apparently this is not the case for the functions used here)?

 And thanks again for remotely debugging the problem for me!
VZ