These are chat archives for symengine/symengine

9th
Jun 2015
Isuru Fernando
@isuruf
Jun 09 2015 02:44
Thanks for the feedback
Isuru Fernando
@isuruf
Jun 09 2015 03:07

Now, adding of two RealMPFRs looks like this

RCP<const Number> RealMPFR::addreal(const RealMPFR &other) const {
    mpfr_class t(std::max(get_prec(), other.get_prec()));
    mpfr_add(t.get_mpfr_t(), i.get_mpfr_t(), other.i.get_mpfr_t(), rnd_);
    return rcp(new RealMPFR(std::move(t)));
}

where the precision of the new number is the max of the precision of the two numbers being added.
Question is what to use for rounding_mode for mpfr_add

Sumith Kulal
@Sumith1896
Jun 09 2015 06:51
@isuruf I still have to write a FindBoost.cmake to try the cases Boost_NO_SYSTEM_PATHS on and off, right?
Isuru Fernando
@isuruf
Jun 09 2015 08:54
That would conflict with the system FindBoost.cmake right?
You could write it in root CMakelists.txt
Sumith Kulal
@Sumith1896
Jun 09 2015 08:55
Okay
Sumith Kulal
@Sumith1896
Jun 09 2015 09:55
When Boost_NO_SYSTEM_PATHS is set to yes, should I use LibFindMacros?
Isuru Fernando
@isuruf
Jun 09 2015 12:33
You can't, because LibFindMacros doesn't search for libraries whose name end with the version number.
Sumith Kulal
@Sumith1896
Jun 09 2015 12:34
Yes, I was facing that issue when I tried
So what exactly is expected when Boost_NO_SYSTEM_PATHS is set to yes?
How do I give hints?
If I can get the components regularly, why are we trying this?
Isuru Fernando
@isuruf
Jun 09 2015 12:41
# This module reads hints about search locations from variables:
#  BOOST_ROOT             - Preferred installation prefix
#   (or BOOSTROOT)
#  BOOST_INCLUDEDIR       - Preferred include directory e.g. <prefix>/include
#  BOOST_LIBRARYDIR       - Preferred library directory e.g. <prefix>/lib
#  Boost_NO_SYSTEM_PATHS  - Set to ON to disable searching in locations not
#                           specified by these hint variables. Default is OFF.
#  Boost_ADDITIONAL_VERSIONS
#                         - List of Boost versions not known to this module
#                           (Boost install locations may contain the version)
Francesco Biscani
@bluescarni
Jun 09 2015 12:43
@isuruf unless you have specific needs in mind, I'd go with round to nearest. At least this is what I would expect as "default" behaviour.
Isuru Fernando
@isuruf
Jun 09 2015 12:43
Purpose of first giving Boost_NO_SYSTEM_PATHS with yes is to check for the libraries given by the user and not to search in the default directories. Sometimes, you may not want to link with the library in the system default directories.
@bluescarni thanks. What should happen when you want to add two RealMPFRs (which is a wrapper for mpfr_class like Integer is for mpz_class) with different rounding modes?
Or should the rounding mode be global?
Francesco Biscani
@bluescarni
Jun 09 2015 12:49
I would probably select a global rounding mode and use it for all operations, at least in the beginning
also, I don't think that MPFR stores the rounding mode in the mpfr_t, or does it?
Isuru Fernando
@isuruf
Jun 09 2015 12:50
Nope. We have to store it in the RealMPFR class
Francesco Biscani
@bluescarni
Jun 09 2015 12:53
Not sure if it is something that belongs there... you should probably ask Ondrej on how he envisions the usage of the MPFR class, but IMO the rounding mode should stay out
I always think of MPFR as an extension of the float, double and long double types
as a floating-point type in which the size of the mantissa can be set at runtime, if you will
so I think it makes sense to do what you are doing with the precisions
if I do float + double, the float number gets promoted to double
but I don't see a meaningful way of mixing two different rounding modes
Isuru Fernando
@isuruf
Jun 09 2015 13:14
Makes sense. Let's ask Ondrej what he thinks as well.
I looked into how Sage handles this. real_mpfr.RealNumber class has a parent with mpfr_rnd_t and mpfr_prec_t and when adding, minimum of the precisions is taken and if precisions are equal, rounding mode is taken to be the rounding mode of the first operand.
Francesco Biscani
@bluescarni
Jun 09 2015 14:08
this seems to introduce some sort of asymmetry if you switch the operands of an otherwise commutative operation?
Isuru Fernando
@isuruf
Jun 09 2015 14:09
yes
sage: a.parent()
Real Field with 100 bits of precision and rounding RNDD
sage: b.parent()
Real Field with 100 bits of precision and rounding RNDU
sage: (a+b).parent()
Real Field with 100 bits of precision and rounding RNDD
sage: (b+a).parent()
Real Field with 100 bits of precision and rounding RNDU
Isuru Fernando
@isuruf
Jun 09 2015 14:14
sage: c.parent()
Real Field with 50 bits of precision and rounding RNDD
sage: (b+c).parent()
Real Field with 50 bits of precision and rounding RNDD
sage: (c+b).parent()
Real Field with 50 bits of precision and rounding RNDD
Francesco Biscani
@bluescarni
Jun 09 2015 14:22
I guess it might make sense for Sage to do such a thing as they are defining a Field (so I imagine that the rounding mode somehow is part of the arithmetic operations on that field?)
Isuru Fernando
@isuruf
Jun 09 2015 14:24
Yes, for example sin(c) would be done with the rounding mode of c's parent
Ondřej Čertík
@certik
Jun 09 2015 14:28
Why don't we do the precision promotion, as @bluescarni described, and just do nearest rounding mode for everything? What are the applications of changing the rounding mode? It seems that such usage would be very specialized, and users can write their own code to do that if needed. For the default mpfr_class I would just use the nearest.
Isuru Fernando
@isuruf
Jun 09 2015 14:40
Sure. Usage of different rounding modes would be very low. So we'll go with default rounding mode.
Francesco Biscani
@bluescarni
Jun 09 2015 15:15
@certik I think the rounding mode is useful for instance if you do interval arithmetic (it's probably used by MPFI). Since you use Arb for that probably you will not care about different rounding modes if you just use MPFR as a "fat" floating point type
Ondřej Čertík
@certik
Jun 09 2015 15:22
@bluescarni right, I think so.