Test failures

[dhirschfeld]

I've just built pyql with boost 1.61 and QL master on Win64 and am seeing the below errors:

======================================================================
FAIL: test_smith (quantlib.test.test_heston_model.HestonModelTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\dev\code\pyql\quantlib\test\test_heston_model.py", line 421, in test_smith
    self.assertAlmostEqual(price_mc, expected, delta=tolerance)
AssertionError: 15.24497079433352 != 15.1796 within 0.05 delta

======================================================================
FAIL: test_bond_schedule_anotherday_bug_cython_implementation (quantlib.test.test_settings.SettingsTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\dev\code\pyql\quantlib\test\test_settings.py", line 142, in test_bond_schedule_anotherday_bug_cython_implementation
    self.assertEqual(date1, date2)
AssertionError: 15/09/2016 !=  2/09/2011

======================================================================
FAIL: test_simulate_heston_2 (quantlib.test.test_simulate.SimTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\dev\code\pyql\quantlib\test\test_simulate.py", line 118, in test_simulate_heston_2
    self.assertAlmostEqual(res[1, -1], 152.50, delta=.1)
AssertionError: 153.26720068021842 != 152.5 within 0.1 delta

----------------------------------------------------------------------
Ran 183 tests in 96.865s

FAILED (failures=3, skipped=2)

Are these something to be worried about?

I see that 2 of them have already been reported in #64.

Is test_bond_schedule_anotherday_bug_cython_implementation a knownfail - the name is certainly suggestive but there are no other comments which would allow me to deduce what the problem is. It looks like it has been around for a while though 33d9329

[dpinte]

@dhirschfeld test_bond_schedule_anotherday_bug_cython_implementation means you're missing the patch on the QL source. It is required to make sure the singleton works properly when the C++ code is linked with pyql.

See https://github.com/enthought/pyql/blob/master/docs/source/getting_started.rst#installation-from-source-on-windows

[dhirschfeld]

The below patch?

class __declspec(dllexport) Settings : public Singleton<Settings> {

I applied that!

I did initially build without it so maybe it didn't get picked up. I'll clean my source, rebuild and try again.

Thanks for the quick response!

[dpinte]

Keep me updated. Having working windows builds is important for the project!

[dhirschfeld]

I've had no joy unfortunately. I've patched settings.hpp as above, have recompiled twice and still get the same errors as above.

When compiling QuantLib I do get hundreds of the below warnings repeated - is that normal?

2>C:\\dev\\lib\\QuantLib\\ql/settings.hpp(111): warning C4251: 'QuantLib::Settings::evaluationDate_': class 'QuantLib::Settings::DateProxy' needs to have dll-interface to be used by clients of class 'QuantLib::Settings'
2>C:\\dev\\lib\\QuantLib\\ql/settings.hpp(113): warning C4251: 'QuantLib::Settings::includeTodaysCashFlows_': class 'boost::optional<bool>' needs to have dll-interface to be used by clients of class 'QuantLib::Settings'

[dpinte]

@dhirschfeld which version of VStudio do you use?

[dhirschfeld]

2015 Enterprise

[dpinte]

@dhirschfeld regarding the warnings, I think it should be safe as we don't access directly the attributes that are not exposed to the dll.

I will need to take the time to do a build and see if I can reproduce the issue. The latest builds I made where for Python 2 and thus using VS2008. I can't promise anything but will try to do it asap.

[dhirschfeld]

Thanks @dpinte for looking into it. I'd be very interested to know if it's just me or if it doesn't build correctly for py3/win64. I'm happy to help / test / provide any assistance I can but I think I'm a little out of my depth.

[dpinte]

@dhirschfeld can you let me know which py3 version you use? That will help making sure we're testing exactly the same things

[dhirschfeld]

In case it's of interest I also tried a QuantLib build with CMake using the CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS flag.

I managed to compile pyql against it but had large numbers of failures. I believe I removed the __declspec(dllexport) from pyql but I still had to run the module def export because it complained about private methods or classes. After doing the recompile with the exported module def it worked but failed lots of tests.

[dhirschfeld]

{'default_encoding': 'cp850',
 'os_name': 'nt',
 'platform': 'Windows-7-6.1.7601-SP1',
 'sys_executable': 'C:\\Python\\python.exe',
 'sys_platform': 'win32',
 'sys_version': '3.5.2 |Continuum Analytics, Inc.| (default, Jul  5 2016, '
                '11:41:13) [MSC v.1900 64 bit (AMD64)]'}

[dpinte]

@dhirschfeld thanks a lot for all the information, that will be really useful. What I'll probably do is making sure we have available QuantLib dll's for the standard Python versions that pyql can download (in place of losing time building it ;-)).

[dhirschfeld]

That would be fantastic. Let me know if you get it compiled for py3 - I'd be very keen to test it out!

[dpinte]

@dhirschfeld I can reproduce the issue (py3.5/win32). Which boost version do you use? The issue is again the problem of the Settings singleton that does not seem to be shared properly between the pyd's.

[dhirschfeld]

That was 1.61 IIRC

[mrslezak]

Are you guys using a patched generate_symbols.py or something? Mine always fails. 1) it thinks the build directory is vc140 (despite msvc9.compiler.VERSION returning: 14.1, it's ignored) when it's actually: QuantLib-1.22/build/v141/ (yes, I hardcoded that instead, still doesn't work; also tried to let it be and copy QuantLib-1.22/build/v141 to QuantLib-1.22/build/vc140/, still fails).

Despite abcd.obj being clearly in the directory, the call to:

nm_result = subprocess.check_output(command, startupinfo=startupinfo)
Always fails, with:

  nm_result = subprocess.check_output(command, startupinfo=startupinfo)

File "C:\Users\Matt.Slezak\Anaconda3\lib\subprocess.py", line 411, in check_output
  return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,

File "C:\Users\Matt.Slezak\Anaconda3\lib\subprocess.py", line 489, in run
  with Popen(*popenargs, **kwargs) as process:

File "C:\Users\Matt.Slezak\Anaconda3\lib\site-packages\spyder_kernels\customize\spydercustomize.py", line 105, in __init__
  super(SubprocessPopen, self).__init__(*args, **kwargs)

File "C:\Users\Matt.Slezak\Anaconda3\lib\subprocess.py", line 854, in __init__
  self._execute_child(args, executable, preexec_fn, close_fds,

File "C:\Users\Matt.Slezak\Anaconda3\lib\subprocess.py", line 1307, in _execute_child
  hp, ht, pid, tid = _winapi.CreateProcess(executable, args,

FileNotFoundError: [WinError 2] The system cannot find the file specified

I even go further into the process and pass the "command" = nm, --extern-only, --defined-only, abcd.obj and it still fails. How exactly are you generating the symbols on Windows from the obj files?

[dpinte]

@mrslezak IIRC, I was generating the symbols using cygwin, which came with nm.