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?
Ralf Stephan
@rwst
Dec 28 2015 09:28
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.
Ralf Stephan
@rwst
Dec 28 2015 09:37
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?
Isuru Fernando
@isuruf
Dec 28 2015 16:24
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
PATH_SUFFIXES
\${pkg}
)``````
to
``````find_path(\${PKG}_INCLUDE_DIR
NAMES
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
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
what tests?
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?
Dec 28 2015 19:02
Yes.
Sumith Kulal
@Sumith1896
Dec 28 2015 19:04
Hmm. Weird. Give me some time.
You can push it to your fork, just link me your `add.cpp` file
Dec 28 2015 19:06
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.