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`

@isuruf I still have to write a

`FindBoost.cmake`

to try the cases `Boost_NO_SYSTEM_PATHS`

on and off, right?
That would conflict with the system

You could write it in root

`FindBoost.cmake`

right?You could write it in root

`CMakelists.txt`

When

`Boost_NO_SYSTEM_PATHS`

is set to yes, should I use `LibFindMacros`

?
You can't, because

`LibFindMacros`

doesn't search for libraries whose name end with the version number.
So what exactly is expected when

How do I give hints?

`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?

```
# 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)
```

@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.

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

`RealMPFR`

s (which is a wrapper for `mpfr_class`

like `Integer`

is for `mpz_class`

) with different rounding modes?
Or should the rounding mode be global?

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?
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

Makes sense. Let's ask Ondrej what he thinks as well.

I looked into how Sage handles this.

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.
this seems to introduce some sort of asymmetry if you switch the operands of an otherwise commutative operation?

```
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
```

```
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
```

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?)

Yes, for example

`sin(c)`

would be done with the rounding mode of `c`

's parent
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.

Sure. Usage of different rounding modes would be very low. So we'll go with default rounding mode.

@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