This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @baurms on Feb 29, 2016, 15:32

The scons help text seems not to be up to date, please have a look

In GitLab by @valentjn on May 7, 2016, 10:58

SWIG's director feature seems to have been broken in commit 9514d92 (by @fabianfranzelin; determined via git bisect). In sgpp::optimization, there is a Python example which uses the director feature for sgpp::base::DataVector:

class ExampleFunction(pysgpp.OptScalarFunction):
    def __init__(self):
        super(ExampleFunction, self).__init__(2)
    def eval(self, x):
        return math.sin(8.0 * x[0]) + math.sin(7.0 * x[1])

The corresponding eval method is declared in ScalarFunction.hpp:

virtual double eval(const base::DataVector& x) = 0;

Before 9514d92, print type(x) in ExampleFunction.eval prints <class 'pysgpp.pysgpp_swig.DataVector'>; the methods and elements of x could be accessed transparently (e.g., print x prints the entries of x).

After 9514d92, print type(x) prints <type 'SwigPyObject'>; print x now shows <Swig Object of type 'sgpp::base::DataVector *' at 0x7fc8f2a3c300>. Consequently, trying to access entries of x via x[1] etc. fails, since x is only a pointer to the DataVector.

The error is introduced by %shared_ptr(sgpp::base::DataVector) in base/build/pysgpp/base.i. When commenting out that line, the generated pysgpp_swig.py stays exactly the same; only pysgpp_wrap.cc differs (and the bug vanishes). Attached are versions of that file before and after commenting out the offending line. But I think the culprit lies in _wrap_OptScalarFunction_eval, the two versions of which I will attach in the following two comments.

• pysgpp_wrap.good.cc
• pysgpp_wrap.bad.cc

In GitLab by @valentjn on Mar 1, 2016, 09:45

The SCons scripts eventually need a general overhaul.

• Currently, much code is duplicated in the modules' SConscript files (searching for source files, tests, examples, ...). This could be refactored into site_scons to ease maintenance.
• The dependencies for the "final build steps" (tests, examples, installation of pysgpp) are set manually to enforce sequential execution, which is not a nice solution.
• Building of the documentation should be separated from compiling code. Currently, scons -h or similar has to be executed before running doxygen, which is just non-intuitive. Maybe we could introduce a special documentation target or a separated SConstruct.

In GitLab by @valentjn on Feb 26, 2016, 09:19

As discussed on the Coding Days in February 2016, single precision (SP) support will be removed from SG++ (not used, causes maintenance overhead). The namespace macro SGPP will be removed; the namespace will instead be called sgpp.

In GitLab by @baurms on Aug 16, 2016, 14:37

• valgrind-ocl.supp ( @DavidPfander-UniStuttgart )
• moduleDoxy ( @baurms )
• buildForMIC_with_unit_tests.sh ( @secklesn )
• buildForMIC_with_unit_tests_mpi.sh ( @secklesn )
• insert.py ( @DavidPfander-UniStuttgart )
• setup.py ( @fabianfranzelin )

@DavidPfander-UniStuttgart move datasets in seperate folder?

Before doing anything: should we do all of this stuff in an extra branch in order to keep track of the changes made for this issue, please give your opinion below!

In GitLab by @valentjn on May 14, 2016, 08:52

Documentation sections like "Manual", "Installation and Usage", and "Examples" have been proved to be hard to find by users. Dirk came up with the idea to extend the corresponding points in the treeview in Doxygen's navigation bar by default. Most likely, there is no such functionality in Doxygen, which means that we have to do some JavaScript hacking.

In GitLab by @leiterrl on Aug 3, 2016, 15:33

When executing the doxygen scons target and there is a module present that does not contain an existing doc/doxygen folder to complete process fails.

A simple "path exists" check at the right time should suffice.

In GitLab by @MLocs on Dec 14, 2016, 13:47

Hello all,

as just discussed in the DG-AG meeting, it would be great if @spc90 has
the rights to add new users to the gitlab.

Cheers,
Valeriy

In GitLab by @baurms on Aug 3, 2016, 15:27

Look through all files in tools/sgpp-deb/ and add documentation, use correct mails and stuff

In GitLab by @valentjn on Jul 17, 2016, 10:12

Currently, there are OperationNaiveEval operations which all derive from the OperationNaiveEval base class (similarly, OperationNaiveEvalGradient, OperationNaiveEvalHessian, and OperationNaiveEvalPartialDerivative). As the basic structure of what a OperationNaiveEval can do is no different from a OperationEval (the only difference is how evaluation is done), all of the OperationNaiveEval should derive from OperationEval to allow using them in all contexts where a OperationEval is required. This should simplify things a bit.

• Merge OperationNaiveEval into OperationEval, deleting OperationNaiveEval in the process.
• The gradient, Hessian, and partial derivative base classes should be renamed to OperationEvalGradient etc.
• The Naive parts in the names of the derived classes should be moved to the end of the names, such that the names begin with OperationEval, OperationEvalGradient, etc.

In GitLab by @pfluegdk on Aug 4, 2016, 14:55

Sollte unter dem Developers Manual auftauchen

Hi guys,
sorry to bother you every day with some new issue :)
I found that the GridPrinter::printSparseGrid function is not working (for me). It is only printing out "0" as grid coordinates.
The coords string seems to be correct but the writing of the stringstream into the tmp variable seems to fail and produces the zeros.

In GitLab by @krsgpp on Mar 28, 2017, 11:34

See config and build log attached:
config.log
build.log

Credits to Florian Künzner (he sent me this by E-Mail).

In GitLab by @valentjn on Jul 4, 2017, 14:25

gcc_ocl for master is currently failing with

datadriven/tests/test_MultipleClassRefinementFunctor.cpp(157): error in "testRefine2class": check grid1->getStorage().getSize() > sizeGrids failed [17 <= 17]
datadriven/tests/test_MultipleClassRefinementFunctor.cpp(158): error in "testRefine2class": check grid2->getStorage().getSize() > sizeGrids failed [17 <= 17]

I think that's @degelkn's stuff.
As the gcc jobs are passing, and as that code isn't doing anything with OCL, it might be a machine problem (old versions or whatever).

In GitLab by @valentjn on May 19, 2016, 10:08

SG++'s BoundingBoxes are a possibility to linearly scale grids from [0, 1]^d to arbitrary hyperrectangles [a, b]^d . This functionality is useful for some applications. However, no one has looked after that feature in the past years. Somebody should reactivate the feature for all the current grids and bases, which means correct scaling of the derivatives, etc. If this could not be done in a efficient way (in terms of both code writing and runtime), the feature should be removed altogether; this would still be better than the current state.

In GitLab by @lettrich on Jul 2, 2017, 12:30

Durch Commit b8f5768 kommt es beim Aufruf von
datadriven/examples/learnerSGDEOnOffTest zu einem Segfault.

Der Fehler kann bis zu LearnerSGDEOnOff.cpp : 352 verfolgt werden:
densityFunction.first->eval(data, perClassDensities.back(), true);

Reported by
@waegemans
@krsgpp

In GitLab by @valentjn on May 13, 2016, 08:58

Peter Schober of the Goethe-Uni Frankfurt reports a segfault when executing the following:

#include <iostream>
#include <memory>

#include "sgpp_base.hpp"

int main() {
  const size_t dim = 2;
  const size_t degree = 3;
  const size_t level = 3;
  std::unique_ptr<sgpp::base::Grid> g = sgpp::base::Grid::createModPolyGrid(dim, degree);
  g->getGenerator().regular(level);
  std::cout << "dim = " << g->getDimension() << ", size = " << g->getSize() << "\n";
  sgpp::base::DataVector dv(g->getSize(), 42.1337);
  std::cout << "tmp = " << dv.toString() << "\n";
  sgpp::op_factory::createOperationHierarchisation(*g)->doHierarchisation(dv);
  std::cout << "tmp = " << dv.toString() << "\n";
}

Valgrind shows the following stacktrace:

==9870== Invalid read of size 8
==9870==    at 0x514B463: evalPolynom (PolyModifiedBasis.hpp:109)
==9870==    by 0x514B463: eval (PolyModifiedBasis.hpp:79)
==9870==    by 0x514B463: evalHierToTop (PolyModifiedBasis.hpp:86)
==9870==    by 0x514B463: sgpp::base::HierarchisationModPoly::rec(sgpp::base::DataVector&, sgpp::base::DataVector&, sgpp::base::HashGridIterator&, unsigned long, sgpp::base::DataVector&) (HierarchisationModPoly.cpp:47)
==9870==    by 0x514B70D: sgpp::base::HierarchisationModPoly::operator()(sgpp::base::DataVector&, sgpp::base::DataVector&, sgpp::base::HashGridIterator&, unsigned long) (HierarchisationModPoly.cpp:31)
==9870==    by 0x4F813B4: sweep_rec (sweep.hpp:190)
==9870==    by 0x4F813B4: sweep1D (sweep.hpp:92)
==9870==    by 0x4F813B4: sgpp::base::OperationHierarchisationModPoly::doHierarchisation(sgpp::base::DataVector&) (OperationHierarchisationModPoly.cpp:25)
==9870==    by 0x400E51: main (debug.cpp:15)
==9870==  Address 0x67339f8 is 8 bytes before a block of size 720 alloc'd
==9870==    at 0x4C2FFC6: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9870==    by 0x4C300D1: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9870==    by 0x514DA47: operator new[](unsigned long) (AlignedMemory.cpp:96)
==9870==    by 0x4F37663: sgpp::base::PolyModifiedBasis<unsigned int, unsigned int>::PolyModifiedBasis(unsigned long) (PolyModifiedBasis.hpp:53)
==9870==    by 0x4F3544F: OperationHierarchisationModPoly (OperationHierarchisationModPoly.hpp:35)
==9870==    by 0x4F3544F: sgpp::op_factory::createOperationHierarchisation(sgpp::base::Grid&) (BaseOpFactory.cpp:174)
==9870==    by 0x400E41: main (debug.cpp:15)

Is this a bug? My wisdom on polynomial bases is not infinite; therefore, I can't tell for sure 😄

In GitLab by @spc90 on Mar 16, 2017, 15:58

I have solved the problem of resizing images introduced by doxygen in the html documentation.
Currently the way it could work is to put images in place with the \image tag and resize them through the css styling file base/doc/doxygen_html_style.cssreferenced in the Doxyfile_template.

The problem is that almost all \image commands extend past the limit imposed by cpplint because both the image names and the captions are long, and I have not found any method to make doxygen accept arguments on multiple lines for the \image command.

Hi,
today I found something a little bit more technical:
The ANOVAHashRefinement inherits all its methods from HashRefinement. The method ANOVAHashRefinement::refineGridpoint is overwritten such that only directions are considered in which the actucal basis function has a level greater than 0.
However, when you choose to refine with threshold 0 and just want to refine a fixed number of points K, then the HashRefinement::collectRefinablePoints method reports the K points for which the IndicatorFunctor was largest and which have at least one child which has not yet been refined.
However, this can lead to (and in my case led to ;)) situations, where K points are reported, which cannot be refined w.r.t. the ANOVA type of refinement. Then a refinement loop terminates although there might be K other points which should really have been refined.

My suggestion (and temporary workaround):
Implement an ANOVAHashRefinement::collectRefinablePoints routine such that only directions d in which point.getLevel(d) > 1 holds, are viewed as potential refinement candidates.

In GitLab by @DavidPfander-UniStuttgart on May 8, 2017, 09:47

The misc tests fail sometimes. At this point, I suspect a race condition in some of A. Heinecke's parallel algorithms (probably in the pde module).

Hi,

I have found an issue with the SurplusCoarseningFunctor. If you want to coarsen only w.r.t. the threshhold, you could easily do that by passing std::numeric_limits<int>::max() as removements_num parameter and expect it to work in the same way as SurplusRefinementFunctor.

However in the HashCoarsening::free_coarsen_NFirstOnly method, a GridPointPair array of size removements_num is allocated which leads to a bad_alloc in this case. However, since you cannot coarsen any more points than points available in the grid anyhow, one could easily circumvent this for the user by changing the output of SurplusCoarseningFunctor::getRemovementsNum() to
min(this->removements_num, alpha.size()).

In GitLab by @valentjn on Sep 14, 2016, 16:46

@schobepr reported the following: If there are errors in the SCons configuration phase (i.e., compiler doesn't support C++11), scons doxygen will fail with a configuration-related error message. Better would be to allow building the documentation in any case (if SCons + Doxygen are installed) by omitting all of the configuration which is not needed for Doxygen. In this specific case, we tried to get the documentation for compiling on OSX, which doesn't work since SCons fails with a message related to compilation on OSX 😄

In GitLab by @baurms on Jul 19, 2016, 17:44

The python source file in this example is missing in the documentation currently online on http://sgpp.sparsegrids.org/code_examples_predictive_refinement.html

In GitLab by @valentjn on May 19, 2016, 10:17

SG++'s Stretchings are a possibility to use other coordinate definitions x_{l,i} instead of the standard uniform points i*2^-l. This functionality is useful for some applications. However, no one has looked after that feature in the past years. Somebody should reactivate the feature for all the current grids and bases, which includes writing tests etc.

Also, there is currently the construct of PointDistributions in HashGridIndex, where one can change the coordinate definition for a single grid point to Clenshaw-Curtis points. The code was written at a time when I was not aware of the Stretching functionality; the Clenshaw-Curtis changing of the PointDistribution should be merged with/included in the existing Stretching feature. The current implementation of PointDistribution has severe downsides as grids like LinearClenshawCurtisGrid don't set the PointDistribution of generated points by themselves. Rather, one has to loop after the grid generation over all grid points and set the PointDistribution manually. If one forgets that, great confusion and bugs will occur due to using Clenshaw-Curtis basis functions with uniform grid points. So, it is relatively urgent to fix that, and the hope is that this would be fixed automatically if Clenshaw-Curtis would be included in Stretching.

In GitLab by @lettrich on Mar 15, 2017, 17:35

During the Coding Days I had a look at the base::HashGridStorage which has two pointer Members : BoundingBox and Stretching. Talking to @pfluegdk , he pointed out that these are exclusive - so either Stretching or BoundingBox is possible. This leads to a very inconvenient interface since there are member functions to access and change both and confusing, error prone implementation. Since Stretching is derived from BoundingBox - are there ways to unify the interface ?

In GitLab by @valentjn on May 19, 2016, 12:57

Currently, you need OperationMultipleHierarchisation from optimization to hierarchize with B-splines. This should somehow be merged into base's OperationHierarchisation; or, at least, OperationHierarchisation should give useful hints that the optimization module has to be used.

Closely related with this issue is the solving of linear systems within the optimization module. This should likely be in the solver module, but base with the B-splines hierarchization shouldn't depend on other modules. We have to think about this...

In GitLab by @baurms on Aug 16, 2016, 14:41

There are inappropriate license terms and an outdated installation guideline in the TODO folder. Please correct it and move it to the root folder.

In GitLab by @fabianfranzelin on Jul 28, 2016, 14:50

In GitLab by @valentjn on May 24, 2016, 08:49

Currently, new SG^++ users cannot tell the difference between the various operations that are available. In particular, no one (but me) knows the difference between OperationEval and OperationNaiveEval, or between OperationHierarchisation and OperationMultipleHierarchisation (the latter should be merged anyway with the former, see issue #13).

We need an overview page in Doxygen that lists all the available operations of at least base (and at least, the common ones of those), explaining what they do, what the requirements are, and what the result is. The keywords are here that hierarchical ancestors must exist for OperationEval to work with linear functions, OperationEval doesn't produce exact results with B-splines, etc.

In GitLab by @pfluegdk on Sep 25, 2016, 13:40

• Multi-Eval/Eval in its different versions needs extra example- or explanation-page
• Adaptivity transparent
• Add general information about workflow (creation, adaptivity, refinement, use, ...)
• Document serialization

In GitLab by @valentjn on Jul 26, 2016, 08:52

@schobepr reports the following issue when trying to compile SG++ on his MacBook:

Gerade versuche ich, SGpp auf dem MacBook zu kompilieren. Ein kleiner Hinweis für die Doku:
Wenn man macports installiert hat und nicht Clang nutzen will, gibt es folgenden Fehler

Peter-Schobers-MacBook-Air:SGpp Peter$ scons -j 2 COMPILER="gnu" VERBOSE=0 SG_ALL=0 SG_BASE=1 SG_OPTIMIZATION=1 USE_EIGEN=1 BUILD_STATICLIB=1
scons: Reading SConscript files ...
Info: Platform: Darwin, peterscobersair.hof.uni-frankfurt.de, 15.5.0, Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016; root:xnu-3248.50.21~8/RELEASE_X86_64, x86_64, i386
Info: Using SCons 2.4.1 on Python 2.7.12
Info: SCons command line: /opt/local/bin/scons -j 2 COMPILER=gnu VERBOSE=0 SG_ALL=0 SG_BASE=1 SG_OPTIMIZATION=1 USE_EIGEN=1 BUILD_STATICLIB=1
Info: Available modules: SG_BASE, SG_COMBIGRID, SG_DATADRIVEN, SG_FINANCE, SG_MISC, SG_OPTIMIZATION, SG_PARALLEL, SG_PDE, SG_QUADRATURE, SG_SOLVER
Info: Available language support: SG_JAVA, SG_PYTHON

Checking programs and libraries:
Info: Using g++ 4.2.1
Checking for g++...(cached) /usr/bin/g++
Checking for gcc...(cached) /usr/bin/gcc
Checking for $SMARTLINK...(cached) /usr/bin/gcc
Checking for flag "-std=c++11"... no

Error: The compiler doesn't seem to support the C++11 standard. Abort!
# ------------------------------------------------------------------------
# An error occurred while compiling SG++.
# If you believe this is a bug in SG++, please attach the build.log and
# the config.log file when contacting the SG++ developers.
# ------------------------------------------------------------------------

Peter-Schobers-MacBook-Air:SGpp Peter$ cat config.log 
file /Users/Peter/Documents/MATLAB/SparseGridsLifecycle/Libraries/SGpp/site_scons/SGppConfigure.py,line 21:
	Configure(confdir = .sconf_temp)
scons: Configure: Checking for g++...
scons: Configure: (cached) /usr/bin/g++

scons: Configure: Checking for gcc...
scons: Configure: (cached) /usr/bin/gcc

scons: Configure: Checking for $SMARTLINK...
scons: Configure: (cached) /usr/bin/gcc

scons: Configure: Checking for flag "-std=c++11"... 
..clang: error: unsupported argument '-q' to option 'Wa,'
scons: Configure: no

Den ich durch auskommentieren von Zeile 21 beheben konnte:
   #env.AppendUnique(CPPFLAGS=["-Wa,-q"]) 

Was unschön ist, ist, dass scons -—help in diesem Falle gar nicht erst die Liste aller möglichen Commands anzeigt.

Alternativ müsste ich eigentlich auch das Xcode clang nutzen können, aber war mir jetzt zu umständlich, den symlink von clang von dem macports clang auf das Xcode clang umzusetzen.

This looks more like a bug in our SCons files (not a bug in the docs).

In GitLab by @pfluegdk on Aug 2, 2016, 15:58

(Nice to have)

• automatically generate dependency graph of modules.
• see base/doc/doxygen/modules.stub0

In GitLab by @valentjn on Nov 8, 2017, 14:53

After compiling the current master (d070206) with scons -j 4 SG_ALL=0 SG_BASE=1, the following base tests fail on my machine:

• TestForwardSelectorRefinement/testFreeRefine2d
• TestImpurityRefinement/testFreeRefine2d

The failing checks compare the result of constructing an adaptive sparse grid with an explicitly stored reference grid. The grid points are the same, but the ordering is not. It seems that the ordering of unordered_map, the underlying type in HashGridStorage, has changed in the standard library implementation.

I should mention that I haven't compiled master in quite a while and that I upgraded my Ubuntu to 17.10 just earlier today. It may or may not have something to do with the update. I tried to compile with g++ 6.4 instead of the now current 7.2, but that yielded the same error.

I'm happy to provide more info if needed.

In GitLab by @valentjn on Apr 25, 2016, 17:37

Most of them are really useful and point to real bugs in the code.

In GitLab by @valentjn on May 7, 2016, 11:19

Surely, the 1D sparse grid bases are not designed to be evaluated outside of [0, 1]. However, either due to numerical errors (rounding, etc.) or deliberately, it might happen that one just does that. There are basis classes, most of the B-spline bases, which jump down right to zero from a non-zero value. Fixing that would make basis evaluations more robust.

In GitLab by @secklesn on Aug 3, 2016, 13:22

Jenkins is no longer automatically triggered.
This should probably be fixed.

In GitLab by @baurms on Aug 3, 2016, 15:33

@pfluegdk please remind me :)

In GitLab by @fabianfranzelin on Mar 22, 2017, 14:10

The test

TestAlgorithms/TestBsplineClenshawCurtisBasis

in "base/tests/test_algorithms.cpp" fails under Windows if the compiler flag OPT=1 -> -O3 is set. The function that crashes is the basis evaluation call for a BsplineClenshawCurtisBasis in line 219

bsplinePropertiesTest
-> const double fxNew = basis.eval(l, i, x);

The error doesn't seem to be reproducible. We have collected a few very strange observations

• Der Fehler tritt nur unter MinGW auf, nicht unter Linux/GCC.
• Der Fehler tritt nicht auf, wenn man mit -O0 oder -O1 kompiliert. Er tritt auf wenn man mit -O2 oder -O3 kompiliert.
• Der Fehler tritt nicht auf, wenn man zum Debugging std::cout-Statements einfügt. Dasselbe für die Ausgabe in ein Logfile.
• Der Fehler tritt nicht 100%ig reproduzierbar auf; manchmal reicht ein Neukompilieren mit einer trivialen, unwichtigen Änderung und es geht dann auf einmal. Manchmal kommt der Fehler bei Grad 3, manchmal bei Grad 5...
• valgrind --tool=memcheck unter Linux beschwert sich nicht. valgrind unterstützt Windows nicht.

Possible reasons (by Julian):

• Ein Out-of-Bounds-Zugriff in xi. Dagegen spricht, dass es ja unter Linux oder mit OPT=0 geht und dass sich valgrind nicht beschwert.
• Ein Problem mit dem Singleton ClenshawCurtisTable, z. B., dass es noch nicht initialisiert wurde, wenn BsplineClenshawCurtisBasis (Konstruktor und constructKnots) es verwenden will. So was gab's schon mal. Dagegen spricht der Backtrace vom gdb - er stürzt ja in nonUniformBSpline ab, da ist constructKnots schon vorbei.
• Die vom gdb angegebene Absturzstelle und der Backtrace sind falsch, das Problem liegt woanders.
• Ein Compiler-Bug in MinGW/g++, z. B. falsche Optimierung für -O3 oder so.

Any ideas? Anyone?

gdb-backtrace.log

In GitLab by @valentjn on Jul 21, 2016, 17:45

OperationEvalModBspline computes wrong evaluation values, see my Master thesis (sec. 6.1.3).

In GitLab by @pfluegdk on Aug 2, 2016, 15:31

sgpp@ipvs auf Mailman überführen?
sgpp-users einrichten (Infrastruktur)

In GitLab by @valentjn on Oct 28, 2016, 10:11

The following was reported by @fabianfranzelin: When creating a LinearBoundary grid with boundaryLevel > 1 (i.e., the points on the boundary are coarser than those on the main axes), hierarchisation via sweep (unidirectional principle) produces wrong results. This is likely due to sweep not properly finding the poles where to apply the 1D hierarchisation scheme. It seems to work only on those poles for which boundary points exists; and for boundaryLevel > 1, there are poles for which this isn't the case.

In GitLab by @lettrich on Nov 17, 2016, 14:28

It is generally considered good practice to use the constwhenever possible. All guidelines on C++ programming agree on that. Not only does it help to identify input and output parameters, it also helps to ensure that certain side effects do not occur which can be very hard to find. And the compiler enforces it automatically during compilation with zero runtime overhead. As Most interfaces insgpp::base have already stabilized and we know which parameters are input and output parameters and which member functions actually change the state of of the object I would see it as a good measure to improve overall code quality without breaking any of the code which builds on top of it. What are the thoughts on that ?

PS: I'd gladly help implement the necessary changes!

In GitLab by @lettrich on Jun 25, 2017, 14:45

Dear all,

while my time with SGpp is (currently) almost over, I have again stumbled upon the problem of debugging winsgpp which currently is, as I think absolutely horrible. Since we require the students to post merge requests and check against all platforms, it is essential to provide students a way how to debug their winsgpp releases.

I understand that there are licensing burdens when trying to make a windows system accessible to students . However I am very sure that most students have either a windows VM at their disposal or are running windows. So instead of providing a whole VM or the access to a VM via remote desktop - why not encapsulate the entire development environment we need to build and run winsgpp using container technology like docker? This way, the burden of setting up winsgpp is reduced to a bare minimum while being useful to developers (and maybe even users!). this way we can even reproduce the environment against which we test on our unit test machines and be sure that things that actually run in the container, will pass our unit tests. And since containers are non-intrusive for the host system, this won't clutter the system of the developer who maybe needs to just fix one or two small bugs in a week and never use winsgpp again.

I understand however that in spite of all benefits, this requires resources to set up the containers in the first place, but on the long run this has the potential to save a lot of resources supporting students that have failing unit tests.

Just tried to install sg++ on ubuntu on windows (which is essentially ubuntu 14.04). Just going through the compile stage using scons (via scons -j 2) and get this error.

g++ -o datadriven/src/sgpp/datadriven/algorithm/DBMatOnlineDE.os -c -fPIC -O3 -g -Wall -Wextra -Wcast-qual -Wconversion -Wformat=2 -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-format-attribute -Wmissing-include-dirs -Wpacked -Wunreachable-code -Wunused -Wno-unused-parameter -Wswitch-enum -Wredundant-decls -pedantic -Wswitch-default -fno-strict-aliasing -funroll-loops -mfpmath=sse -fopenmp -fno-omit-frame-pointer -msse3 -fPIC -std=c++11 -Ibase/src -Icombigrid/src -Idatadriven/src -Ioptimization/src -Ipde/src -Iquadrature/src -Isolver/src -I/usr/include -I/usr/include/python2.7 -I/usr/local/lib/python2.7/dist-packages/numpy/core/include -I/usr/lib/jvm/java-7-openjdk-amd64/include -I/usr/lib/jvm/java-7-openjdk-amd64/include/linux -Itools datadriven/src/sgpp/datadriven/algorithm/DBMatOnlineDE.cpp
datadriven/src/sgpp/datadriven/algorithm/DBMatOnline.cpp: In constructor ‘sgpp::datadriven::DBMatOnline::DBMatOnline(sgpp::datadriven::DBMatOffline&)’:
datadriven/src/sgpp/datadriven/algorithm/DBMatOnline.cpp:17:60: error: invalid initialization of non-const reference of type ‘sgpp::datadriven::DBMatOffline&’ from an rvalue of type ‘<brace-enclosed initializer list>’
 DBMatOnline::DBMatOnline(DBMatOffline& o) : offlineObject{o} {}
                                                            ^
scons: *** [datadriven/src/sgpp/datadriven/algorithm/DBMatOnline.os] Error 1
scons: building terminated because of errors.
# ------------------------------------------------------------------------
# An error occurred while compiling SG++.
# If you believe this is a bug in SG++, please attach the build.log and
# the config.log file when contacting the SG++ developers.
# ------------------------------------------------------------------------

The version of gcc is 4.8.4

Here is the build log
build.log

In GitLab by @valentjn on Nov 7, 2017, 16:17

Bug reported by @schroeji:

Ich habe einen Bug in den beiden BSplineClenshawCurtisBasen gefunden:
Wird das selbe Basis-Objekt für die gleichzeitige Evaluation durch
mehrere Threads verwendet, kann es passieren, dass die Aufrufe von
eval, evalDx, evalDxDx und getIntegral falsche Resultate liefern.
Der Grund dafür ist, dass alle Threads sich den xi-Vektor teilen
und bei Überschneidungen der Funktionsaufrufe dieser eventuell
falsche Werte enthält.
Am Beispiel der eval-Funktion führt folgende Reihenfolge (für
unterschiedliche l,i) zu Problemen:

Thread A: constructKnots(l,i);
Thread B: constructKnots(l,i);
Thread A: nonUniformBSpline(x, bsplineBasis.getDegree(), 0)  <---- Falscher xi-Vektor bei Auswertung
Thread B: nonUniformBSpline(x, bsplineBasis.getDegree(), 0)

In GitLab by @valentjn on Apr 25, 2016, 10:10

The following warning is raised when trying to generate the Java interface with SWIG:

datadriven/src/sgpp/datadriven/application/LearnerSGDE.hpp:48: Warning 401: Nothing known about base class 'json::JSON'. Ignored.

The warning is caused by the fact that all classes from the json namespace are currently not wrapped by SWIG. Possible solutions would be to wrap the classes (more effort) or to leave LearnerSGDE unwrapped in the Java interface.

Hi,
I experienced a problem with reading in CSV files using DataSourceBuilder. ARFF Files seem to work fine, but comma separated value files of this format

x0,x1,x2,x3,x4,y
0.220847790771,0.517040101927,0.19956562731,0.639407139068,1.46804001503
0.0838406379871,0.295235516856,0.272006109762,0.310603660615,1.52258099856
...

If I try to read in a file like this e.g. with sgpp/datadriven/examples/CrossValidationExample it results in a segfault. For ARFF files like the sgpp/datadriven/tests/data/friedman3_10k_train.arff file it works fine. I also tried without the header line in the CSV file and whitespace separator. Am I using it wrong/have the wrong CSV format (the needed format does not seem to occur in the documentation, at least I did not find it) or is this an issue with the DataSourceBuilder?

Best,
Bastian

In GitLab by @valentjn on Sep 5, 2016, 10:27

HierarchisationSLE currently uses gridStorage.getCoordinate for evaluation of the basis functions at the grid points. This is wrong as getCoordinate returns coordinates in the bounding box, but eval expects them to be in the unit interval.

In GitLab by @baurms on Apr 12, 2016, 18:33

baurms@vgpu1:~/Code/SGpp/datadriven/examplesOCL$ ./multiEvalPerformance
terminate called after throwing an instance of 'sgpp::base::file_exception'
what(): Unable to open file: debugging.arff
Aborted

On branch AutoTune