These are chat archives for symengine/symengine

18th
May 2015
Ondřej Čertík
@certik
May 18 2015 17:58
Sure, that would work.
Isuru Fernando
@isuruf
May 18 2015 18:00
There are several reasons why eval_double is slower for evaluations of functions
We know that arg is a RealDouble, but it is not used. We know that the function is Sin, but it is not used. Allocating memory for a visitor each call.
Fact that function is Sin can be used if we use the visitor without calling the eval_method
Isuru Fernando
@isuruf
May 18 2015 18:17
I implemented eval_mpfr as well. How do I add tests for it?
Ondřej Čertík
@certik
May 18 2015 18:17
I think we already interface with mpfr, don't we?
So I would just test it on some examples, just like eval double.
I think the memory for visitor is allocated on stack, so that should have no overhead.
Isuru Fernando
@isuruf
May 18 2015 18:30
eval_double has no support for complex numbers. So we could add a new one like eval_complex_double like Sage which first tries to eval in real numbers and if it cannot in complex numbers. At the moment if it cannot be evaluated in real numbers, eval_double throws a runtime_error, and catching the exception leads to other problems. What's the best way to handle this?
a flag telling it failed. Was there any decision made on how to handle exceptions for the ruby project?
Ondřej Čertík
@certik
May 18 2015 18:32
Yes, for the Ruby project we catch exceptions and convert them to 0, 1 (or more numbers) exit codes from the C functions. Then we wrap this in Ruby.
Why not to raise our own exception, that eval_double_real encountered a complex number?
What kind of problems does catching exceptions lead to?
Do you know how Sage signals this?
Isuru Fernando
@isuruf
May 18 2015 18:34
There was an error of a null pointer in a RCP
Ondřej Čertík
@certik
May 18 2015 18:34
Can you be more specific?
Isuru Fernando
@isuruf
May 18 2015 18:34
Let me run it again
Ondřej Čertík
@certik
May 18 2015 18:34
RCP should be exception safe, so if it isn't, it's a bug that can be fixed.
Isuru Fernando
@isuruf
May 18 2015 18:41
It's running without an error, if I encounter one, I'll let you know
Ondřej Čertík
@certik
May 18 2015 18:42
Definitely. I am aware that our RCP implementation is not as Debug safe as the Teuchos one, but either way this shouldn't be happening. I am investigating if we can use the Teuchos one for Debug build and our own for Release.
Isuru Fernando
@isuruf
May 18 2015 18:49
MPFR also has a cache that needs to cleared for each thread like Arb. (http://fredrikj.net/arb/arb.pdf#page=15) Do we need to do it automatically or let the user deal with it?
Ondřej Čertík
@certik
May 18 2015 18:52
If the code is part of SymEngine, then we should definitely clean it up ourselves.
For example by calling it from a destructor of a stack allocated object.