These are chat archives for symengine/symengine

28th
Dec 2015
Isuru Fernando
@isuruf
Dec 28 2015 09:27
@rwst, about Pynac, how do I check that out?
Isuru Fernando
@isuruf
Dec 28 2015 09:29
Thanks
@rwst, @certik, @shivamvats, in ring_series.py, sin(p) is evaluated using the expansion of sin(x), but changes the method to 2*tan(p/2)/(1-tan^2(p/2) when there are more than 20 terms in p.
Using piranha, it's much faster to do the evaluation using the expansion of sin(x) compared to 2*tan(p/2)/(1-tan^2(p/2)
Ralf Stephan
@rwst
Dec 28 2015 09:33
@isuruf How do you use the sin(x)expansion, do you substitute p for x?
Isuru Fernando
@isuruf
Dec 28 2015 09:33
yes
Ralf Stephan
@rwst
Dec 28 2015 09:35
There is code for that in rs_series that I didn't transcribe, that is faster than simple substitution
It was planned as one of the next enhancements
Isuru Fernando
@isuruf
Dec 28 2015 09:36
Ah. I'll stick with just substitution for now, as it's faster than 2*tan(p/2)/(1-tan^2(p/2). I just have to remove the condition if (s == var) in your code.
Isuru Fernando
@isuruf
Dec 28 2015 13:52

I just checked sin(cos(x+1)) series with order 30.
symengine vs ginac vs mathematica
19 ms vs 80 ms vs 84432 ms

order 100
559 ms vs 2841 ms

Ralf Stephan
@rwst
Dec 28 2015 14:43
That looks good. I haven't callgrinded Pynac with such an expression, only without symbolic constants, and there is an issue about expression creation () so there might be room for improvement of Pynac. Isn't the number of sin/cos function objects cubic in the order? A guess is >100k of such objects.
A guess is >100k of such objects for order 100.
Isuru Fernando
@isuruf
Dec 28 2015 14:53
172875 occurrences in order 100 series. Timings for ginac is using ginac, not Pynac. Sage is still compiling.
Ralf Stephan
@rwst
Dec 28 2015 14:55
that would be about n^3 + 3n^2 + 5n + O(1)
eh divided by 6
Ondřej Čertík
@certik
Dec 28 2015 15:48
@isuruf, regarding symengine/symengine#675, do you know what the best fix is?
The find_package doesn't seem to use CMAKE_PREFIX_PATH, but I am not sure yet.
Isuru Fernando
@isuruf
Dec 28 2015 15:52

find_package will use CMAKE_PREFIX_PATH, but you cannot give it on the command line. The fix will be

adding hints to CMAKE_PREFIX_PATH before each find_package call in SymEngineConfig.cmake

Ondřej Čertík
@certik
Dec 28 2015 15:55
I don't understand. You are right that find_package will use CMAKE_PREFIX_PATH, according to https://cmake.org/cmake/help/v3.0/command/find_package.html
How does the command line usage work?
The command line usage does not call find_package?
Isuru Fernando
@isuruf
Dec 28 2015 15:56
Command line cmake --find-package -DCMAKE_PREFIX_PATH=hint won't work
Because -DCMAKE_PREFIX_PATH=hint is not passed to cmake
cmake --find-package will call Modules/CMakeFindPackageMode.cmake in your cmake installation
Ondřej Čertík
@certik
Dec 28 2015 15:59
I see.
So cmake --find-package doesn't parse the command line?
Isuru Fernando
@isuruf
Dec 28 2015 16:00
No. only the pre-defined variables like MODE LANGUAGE etc
Ondřej Čertík
@certik
Dec 28 2015 16:00
How can SymEngineConfig.cmake have access to CMAKE_PREFIX_PATH then?
Isuru Fernando
@isuruf
Dec 28 2015 16:03
It doesn't. Idea of a cmake --find-package is that you only have to point to the directory of SymEngine and SymEngineConfig.cmake should take care of the rest without any other user interaction (like giving the path to GMP)
Ondřej Čertík
@certik
Dec 28 2015 16:04
So we save CMAKE_PREFIX_PATH in SymEngineConfig?
Isuru Fernando
@isuruf
Dec 28 2015 16:04
Yes, that's the only option.
Ondřej Čertík
@certik
Dec 28 2015 16:04
Ah!
I think that's also the right option. It makes sense now. So we just have a bug in SymEngineConfig.cmake.
Isuru Fernando
@isuruf
Dec 28 2015 16:09
Btw, there is one concern I had with the PR. In all of the Find*.cmake modules in cmake installation there is some kind of a way for the user to give hints. For ex. FindBoost.cmake has BOOST_ROOT which has higher priority than other paths
correction, BOOST_ROOT has lower priority than CMAKE_PREFIX_PATH
Ondřej Čertík
@certik
Dec 28 2015 16:11
@isuruf the idea is that you use CMAKE_PREFIX_PATH for everything.
Isuru Fernando
@isuruf
Dec 28 2015 16:14
Yes, I'm fine with using CMAKE_PREFIX_PATH. I think that other Find*.cmake modules have these in case you don't want to have the CMAKE_PREFIX_PATH polluted by a hint you want to give. Still CMAKE_PREFIX_PATH has higher priority
Ondřej Čertík
@certik
Dec 28 2015 16:15
I just want to use the default cmake approach.
Isuru Fernando
@isuruf
Dec 28 2015 16:15
If we add the mechanism of hints, then we can save these hints in SymEngineConfig.cmake. When installing it the path we found can be given as a hint
Ondřej Čertík
@certik
Dec 28 2015 16:16
So we just save CMAKE_PREFIX_PATH into SymEngine_CMAKE_PREFIX_PATH?
and then use it as hint to find_library?
Actually, I am still confused. If you look at the failure here: https://travis-ci.org/symengine/symengine/jobs/95832399
Why cannot we just save the full path to the gmp we found?
(or relative path to it)
The CMAKE_PREFIX_PATH is only used to initially find it. But once we find it, we should just use the gmp we actually used to install symengine. The only issue left is how to properly save absolute and/or relative path it, but that's a different issue.
Isuru Fernando
@isuruf
Dec 28 2015 16:19
I agree
Ondřej Čertík
@certik
Dec 28 2015 16:21
Why do we call find_package from within SymEngineConfig.cmake?
We should not.
We should only save the paths that we already have.
Isuru Fernando
@isuruf
Dec 28 2015 16:21
I introduced that because of the absolute/relative path issue
Ondřej Čertík
@certik
Dec 28 2015 16:22
So I think we need to find a different solution to the absolute/relative path issue.
Isuru Fernando
@isuruf
Dec 28 2015 16:23

If you change

find_library(${LIBNAME}_LIBRARY
          NAMES
              ${libname}
)

to

find_library(${LIBNAME}_LIBRARY
          NAMES
              ${libname}
          HINTS
              ${${LIBNAME}_LIBRARIES}
)

everything should work

and similar change to find_path
Ondřej Čertík
@certik
Dec 28 2015 16:24
Where should this change go?
Ondřej Čertík
@certik
Dec 28 2015 16:26
I don't want to use LibFindMacros at all.
I want to just use find_library directly eventually.
But for now, how would your fix work?
How would the ${LIBNAME}_LIBRARIES be set?
Isuru Fernando
@isuruf
Dec 28 2015 16:27
find_path(${PKG}_INCLUDE_DIR
        NAMES
            ${HEADER}
        PATH_SUFFIXES
            ${pkg}
    )
to
find_path(${PKG}_INCLUDE_DIR
        NAMES
            ${HEADER}
        PATH_SUFFIXES
            ${pkg}
        HINTS
             ${${PKG}_INCLUDE_DIRS}
    )
This change also
So that the paths we already found will be checked
Ondřej Čertík
@certik
Dec 28 2015 16:30
Ok. What does find_package in SymEngineConfig.cmake call?
I thought we can only call find_package for symengine, not for gmp?
Isuru Fernando
@isuruf
Dec 28 2015 16:31
SymEngine's FindGMP.cmake , FindMPFR.cmake etc
Ondřej Čertík
@certik
Dec 28 2015 16:32
so find_package(GMP) will call our FindGMP.cmake?
Isuru Fernando
@isuruf
Dec 28 2015 16:32
yes
Ondřej Čertík
@certik
Dec 28 2015 16:33
Ah, sorry, of course.
find_package is what is used to find all our dependencies.
Isuru Fernando
@isuruf
Dec 28 2015 16:35
@certik, yes. We can get rid of that as well, by manually checking the absolute path and then relative path
Ondřej Čertík
@certik
Dec 28 2015 16:36
So if we only want to do absolute paths, we simply set those paths in SymEngineConfig.cmake, without calling any find_package, find_library or find_path in it, right?
Isuru Fernando
@isuruf
Dec 28 2015 16:36
yes
Ondřej Čertík
@certik
Dec 28 2015 16:36
So that should be our first iteration.
Then we need to figure out how to do relative paths, but without calling all these find_library or find_package things, as that seems to be fragile and complicated.
Well, or maybe not, I am actually not sure
Isuru Fernando
@isuruf
Dec 28 2015 16:38
SYMENGINE_LIBRARIES and SYMENGINE_INCLUDE_DIRS are the only things that are needed
Ondřej Čertík
@certik
Dec 28 2015 16:40
Needed for relative paths?
When we say "relative" path, do we mean relative to where symengine is installed?
To use the same prefix.
Isuru Fernando
@isuruf
Dec 28 2015 16:40
Yes
Ondřej Čertík
@certik
Dec 28 2015 16:47
For the relative path, do we want the user to also completely change where to find dependencies?
Isuru Fernando
@isuruf
Dec 28 2015 16:49
I'm sorry, can you explain what you mean by that?
Ondřej Čertík
@certik
Dec 28 2015 16:50
So for absolute path, all we need is to store the exact path that we used when installing symengine. No ambiguity there.
What are all the use cases for the relative path?
Isuru Fernando
@isuruf
Dec 28 2015 16:51
Something like conda where you want to use installed SymEngine for a project
Ondřej Čertík
@certik
Dec 28 2015 16:56
For the conda use case, do we want to call our Find*.cmake to discover the dependencies, or do we want to simply substitute the absolute path for a relative path, relative to where symengine is installed?
Isuru Fernando
@isuruf
Dec 28 2015 16:57
I'm not sure what should be done
Ondřej Čertík
@certik
Dec 28 2015 16:58
Me neither.
How about we only support absolute paths for now and once we figure out the right way, we add relative paths?
Isuru Fernando
@isuruf
Dec 28 2015 16:59
Sure
Ondřej Čertík
@certik
Dec 28 2015 17:22
I've implemented the absolute paths in symengine/symengine#675, it seems to be working.
@isuruf thanks for the help!
Isuru Fernando
@isuruf
Dec 28 2015 17:38
That's great. Next step would be to figure out what to do for relative paths
Pradyot Prakash
@pradyotprakash
Dec 28 2015 18:57
Hi!
I was working towards converting the public members in add.cpp to private. On adding the appropriate function and making the necessary changes wherever needed, i ran the test. Unfortunately 2 tests failed.
Need help fixing that.
Sumith Kulal
@Sumith1896
Dec 28 2015 18:59
@pradyotprakash Go on
what tests?
Pradyot Prakash
@pradyotprakash
Dec 28 2015 19:00
test_arit and test_functions failed.
In the file tests/basic/test_functions.cpp I narrowed down the source of the error to line #213. For some reason a seg fault is being thrown!
Sumith Kulal
@Sumith1896
Dec 28 2015 19:01
r2 = sin(sub(div(pi, i2), real_double(2.0)));
this line?
Pradyot Prakash
@pradyotprakash
Dec 28 2015 19:02
Yes.
Sumith Kulal
@Sumith1896
Dec 28 2015 19:04
Hmm. Weird. Give me some time.
Have you pushed your work?
You can push it to your fork, just link me your add.cpp file
Sumith Kulal
@Sumith1896
Dec 28 2015 19:15
Thanks. Will have a look.
Sumith Kulal
@Sumith1896
Dec 28 2015 19:52
In test_functions.cpp the test fails here and in test_arit.cpp they fail here. Both have to do with RealDouble, I have nothing concrete but I'm guessing add and sub in RealDouble may be the case.
Akash Trehan
@CodeMaxx
Dec 28 2015 21:48
I used the cmake . and then make command. Is there a way to revert it and get the original directory back?
Ondřej Čertík
@certik
Dec 28 2015 23:15
@pradyotprakash, @Sumith1896 compile symengine in Debug mode, then it should not segfault, but rather give you a nice exception. If it segfaults in Debug mode, then please ping me, that would mean that we have a bug to fix.