Jenkins Jobs are running again.

Latest Jenkins Jobs still have warninings in the style-Job. The error in the coverage-testing Job can be ignored.

master needs to be merged into this branch again due to another PR that just got merged.
Next jenkins run will start as soon as jenkins has resources (we will need to do another as soon as the master is merged).

Hi,
sorry for turning up so late but I have two major remarks (also @krsgpp ) for this pull request:

First, the functionality introduced here seems to partially belong to the combigrid module. I understand that touching this might be too much effort for a student project but I still believe merging this PR as is would result in duplicate code. IIRC the current combigrid module should already offer dimensional adaptivity.

Second, some of the core logic of this PR is implemented in python, which is called from C++. This adds an unnecessary dependency on python-dev and might obfuscate attempts at debugging this part of the code in the future. What is the reason for this is not being implemented in C++?

Other than that I only have two more minor things:

• Debug output should be removed/guarded
• I don't understand the logic in the testAnisotropicFull boost test. Aren't the checks doing the same in each iteration of that for loop? What is the if clause in the beginning supposed to do?

Hello,

to the boost test:
The function i.set(d, l, i) sets the level and the index of a point in the dimension d. The if clause is setting the level and indexes for dimension 0 of point i. Afterwards the levels and indices in dim 1 of point i are set to different values bevor BOOST_CHECK(s.isContaining(i)) checks if s contains them. There are 21 Points in an anisotropic full grid of levels (2,3) and the code checks if they are all contained in s after calling HashGenerator::anisotropicFull(s, (2,3)).

Alright so as promised @pfluegdk and I had a little discussion about this today. Bottom line is that we think the introduction of another interface (C++ -> Python) is a blocking issue here. We understand that nobody wants to reinvent the wheel but at the same time we want to avoid further complication of the SGpp library.

Also, I would like to remark two more minor things:

• There is a hardcoded dependency on zlib added. This should be replaced by using the USE_ZLIB define that is already there
• During the last coding days we were concerned with licensing issues of datasets. What's the licensing status on redistributing the iris flower dataset added in this PR?

@niglz We just discussed the merge with @krsgpp. The dependency on Python is not something that matches our policy of dependencies.
At the next SG++ Coding Days (July 30 + 31) we will need to discuss a split of the data-driven module anyway, and it could be an option to separate the DataMining pipeline. This should be a win-win situation for everyone. @niglz - would you like to join the coding days in Stuttgart? We can provide travel support and accommodation.

@pfluegdk I would really like to join, but i have an exam on July 31.

So should i close the pull request for now?

I will merge this today, so we won't close this :-)