Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

[RFC] MPFR and MPC on Base #2814

Merged
merged 31 commits into from

7 participants

@andrioni
Collaborator

Hello,

as it was discussed in #2564, I am doing this pull request with a tentative integration of both MPFR and MPC on Base. It is currently working and passes all tests (I used the same tests I wrote when they were in packages), so it's easy for anyone to try it.

Known issues:

  • make check for MPFR and MPC runs their test suites, lengthening considerably the build process, as make check is always called, and I have yet to discover how to bypass this.
  • There is no written documentation currently, nor examples other than the tests.
  • Support for different rounding modes.
  • Renaming MPFRFloat to BigFloat.
  • Renaming precision-related functions
  • convert methods for BigComplex
  • Migration to a direct representation of the structs involved, instead of a bunch of memory allocated as an array
    • BigInt
    • BigFloat
  • mpfr_hypot
  • Better basic operations rules between BigTypes and primitives to avoid using promotion to deal with it
  • Set 256 as the default precision.
  • Add the needed -dev libraries to .travis.yml
  • Reimplement sum for MPFRFloat in a way that works, as it needs an array of pointers.
  • MPFR has no make distclean option, it seems.
@ViralBShah
Owner

@staticfloat Do you think we can support these in travis before we merge this?

@stevengj
Owner

The types should probably be called BigFloat (replacing the current type of the same name) and BigComplex, rather than MPFRFloat and MPCComplex. (Which libraries are used to implement a given functionality should be mostly invisible to the user.)

Correspondingly, I would use get_bigfloat_precision etcetera to get/set the precision. The short names prec and prec2 should probably be `get_bigcomplex_precision(x::BigComplex) (and just do mpc_get_prec2), or have a generic get_precision that works for all floating-point types.

You don't need iscomplex(::MPCComplex) = true since true is the default for any subtype of Number.

Why isn't there a convert(::Type{Complex{Float64}}, x::MPCComplex) function etcetera?

@andrioni
Collaborator

I will do the replacements and renamings right now.

The convert functions are lacking mainly because I was finishing them in MPFR (as MPC is just a library around a pair of MPFR floats). Implementing them will be quite direct now.

I'll add these issues to the checklist on the top, and update it as I do them, thanks!

@andrioni
Collaborator

Also, one question: I'm currently using 53 bits as the default precision (i.e. a Float64), but BigFloat currently uses the GMP default, 64 bits. Should I up the default to match it (for compatibility), or should I use a higher number (maybe 256), to give a nice precision by default for those who don't want to mess with it?

@stevengj
Owner

I would default to 256-ish (~octuple) precision.

It would be much nicer to implement BigComplex as Complex{BigFloat}, so that you share all of the Complex{T} methods. You can still call MPC for the operations as needed. In fact, if you do it right (make BigFloat an immutable wrapper around a single mpfr_t pointer), Complex{BigFloat} should even be bit-compatible with mpc_t, so you won't even need to do a conversion (although making an mpc_t on the fly as needed should be cheap).

I'm confused: why is MPFRFloat.mpfr a Vector{Int32}, instead of being an opaque mpfr_t pointer?

@StefanKarpinski

I'm confused: why is MPFRFloat.mpfr a Vector{Int32}, instead of being an opaque mpfr_t pointer?

I don't know if it's the case here, but in cases where a fixed amount of memory is used to store some C blob, you can make the thing serializable by using a Julia array for the storage. E.g. that's how compiled PCRE regex patterns work: https://github.com/JuliaLang/julia/blob/master/base/regex.jl#L10. Not sure if that's what's going on here though.

@stevengj
Owner

@StefanKarpinski, that doesn't seem to be what's going on here. mpfr_t in C is an array (pointer) of one __mpfr_struct, which consists of three integers plus a pointer. MPFR.jl uses a Vector{Int32} of length 5 instead, where I guess 5 comes from the number of Int32s you need to store 3 32-bit int variables and a 64-bit pointer?? One problem is that 5 seems wrong to me: with struct padding, it seems like more space is required on a 64-bit architecture, and moreover one of the 3 integer fields is a long which is 64 bits on 64-bit Unix systems. In any case, the naive serialize function won't work for this because you can't just serialize the value of the pointer, you have to serialize the contents of the pointed-to array. So, it needs its own serialize method anyway.

The problem here is that MPFR's interface, now that I look at it, requires the caller to know the layout (or at least the size) of the __mpfr_struct, since it doesn't provide a way to allocate an opaque mpfr_t pointer.

There are two possibilities that occur to me. One is to just make BigFloat a type with some padding that is at least as big as __mpfr_struct, i.e. type BigFloat; pad0::Int32; pad1::Int32; .......; end. The other (better, I think) is to try and match the actual size by copying the original struct definition from mpfr.h

type BigFloat
     prec::Cint # problem: may be a Cshort in some MPFR compilations
     sign::Cint
     exp::Clong
     d::Ptr{Void} # pointer to mp_limb_t, which can vary in size depending on how GMP is compiled
end

However, since this will be part of the Julia build, it should be straightforward to extract the correct types from the header files to insert into the .jl file (e.g. you can run a little C program to print the sizeof values, and there are even tricks to get sizeof that only require running the compiler so that it works when cross-compiling).

(It shouldn't be immutable since the contents are, in fact, mutable by the C API.) This would avoid the double allocation (where you now allocate a type whose contents are a pointer to an array that contains another struct). Then you would pass a Ptr{BigFloat} (via &) to MPFR functions and it should work, assuming the struct types match. Getting Complex{BigFloat} to work with MPC is a more tricky, however, since I don't think Complex{BigFloat} will then have the same layout as a struct of two __mpfr_structs. (It would if BigFloat were immutable, but BigFloat must be mutable.)

@stevengj
Owner

Also, it's not completely clear to me that we need MPC. If we just do Complex{BigFloat}, the generic Complex{T} methods seem like they provide pretty much all of what MPC provides.

(There doesn't seem to be anything too special in the MPC implementations; they just convert everything into the corresponding operations on the real and imaginary parts. They might be more clever about minimizing the number of temporary values compared to Complex{T}. It would be interesting to have a benchmark or two.)

@ViralBShah
Owner

@stevengj That is useful to know. In that case, let's get MPFR in shape. It would be nice to leverage Complex{BigFloat} as much as possible and avoid adding another library.

@stevengj
Owner

PS. It looks like you need to wrap the mpfr_hypot function. (This is necessary for abs(::Complex{BigFloat}) to work.)

@staticfloat
Owner

Everything looks good. Once this lands, we can make some very simple changes to .travis.yml. No packaging required on my end! :D

I suppose we could also include the travis changes in this pull request..... that might actually be the best plan, as then we get to test the travis integration with the pull request itself.

@stevengj
Owner

Another TODO item: BigFloat really shouldn't use promotion rules to perform e.g. *(::BigFloat,::Float64), since converting the second argument to a BigFloat before multiplying is heinously inefficient compared to calling mpfr_mul_d.

This is also a flaw of our BigInt implementation, by the way, since GMP provides special functions to add a BigInt to a Clong etcetera that we aren't exploiting (see #2839).

@stevengj
Owner

I notice that the BigInt implementation in bigint.jl pulls the same ugly stunt: it allocates an Array(Int32, 4) to hold an __mpz_struct, which should really be a

type BigInt
    alloc::Cint
    size::Cint
    d::Ptr{Void}
 end

to match the C struct and avoid the double allocation. Again, I think it should be mutable (since the entries are mutable in the C API).

@andrioni
Collaborator

I wrote a comment here, but you all basically said everything I was going to say and more, so thanks for the help.

I was trying to make the suggestion work with BigInt as preliminary test, but I got a bunch of stack overflows randomly, and then I wasn't able to compile Julia anymore because it wasn't able to read libreadline.a and some other files, so I'm doing a fresh install of Julia and updating gcc/glibc on this computer to work on it again.

@andrioni
Collaborator

@staticfloat @ViralBShah the build I did for this pull request is already with a modified .travis.yml to use the system MPFR and MPC (they are needed for newer GCC versions, so they are bundled with it in almost every Linux distro)

@staticfloat
Owner

hahaha, so I ended up putting USE_SYSTEM_MPFR in there twice! Awesome. Nice work, @andrioni. I would only ask you to include libmpfr-dev in the apt-get install line, as many users use .travis.yml as a template for an easy Ubuntu install, and if they don't have mpfr, they will need that line too.

@andrioni andrioni referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@andrioni
Collaborator

BigInt now uses the approach proposed by @stevengj, and the .travis.yml now installs the dependencies correctly.

@andrioni
Collaborator

__GMP_MP_SIZE_T_INT only gets set on some Cray architectures, so _MPFR_PREC_FORMAT gets set to 3 and so both the default precision and the exponent variables are long, if my interpretation of mpfr.h is right.

(by the way, kudos to the one who implemented Cint and Clong types.)

@andrioni andrioni referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@andrioni andrioni referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@stevengj
Owner

pointer_from_objref won't work because it returns a jl_value_t*, which has some header information before the member data starts. @vtjnash, will #2818 fix this (so that pointer_from_objref(x::Foo) returns a pointer that can be passed as a C struct corresponding to Foo)?

@vtjnash
Collaborator

Actually the purpose of #2818 is to help eliminate uses of pointer_from_objref. In this case, it would make the following work: ptrarr = [x.mpfr for x in arr] (although the previous suggestion would also be made to work, but be more difficult from a garbage collection and usage standpoint)

@stevengj
Owner

@andrioni, note that you shouldn't need to have a separate mpfr_struct type. Just put the members directly in BigFloat:

type BigFloat{N} <: FloatingPoint
    prec::Clong
    sign::Cint
    exp::Clong
    d::Ptr{Void}
end

Similarly, BigInt shouldn't need a separate mpz_struct.

@andrioni
Collaborator

I was having some issues with constructors before, but then again, it seems a recompile after make distclean solved all my stack overflows. I'm updating it again right now.

@andrioni
Collaborator
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3ffff8
0x0000000101f5dc48 in ?? ()

Ok, I got more stack overflows. Here's the code I tried to use. I'll keep improving this using the auxiliary mp*_struct types, and when I find a solution for these stack overflows (basically, the constructor seems to call itself endlessly if you define the type and some functions for it, but not if there aren't extra functions).

@stevengj
Owner

@JeffBezanson, do you see why this version of the BigInt() constructor would lead to a stack overflow?

@StefanKarpinski

Passing &b to gmpz_init where b is the Julia BigInt object seems like a bad idea. That pointer is going to be a jl_value_t* and include the box (type tag, etc.) in front of the actual value. I'm not sure what the best way to do this is, but you need to get a pointer to the data of the value, not the value itself. Could be as simple as adding 1 to the pointer, but that feels kind of hacky. Also, @vtjnash's "recurse types" branch might change this by making Julia reference point at the beginning of the data of Julia values instead of the box.

@andrioni
Collaborator

Why it works then when I use the auxiliary mpz_struct, shouldn't it be boxed as well?
(I had a similar problem for the mpc_struct, as using two mpfr_struct as members directly doesn't work, but hand 'unrolling' them (i.e. putting the mpfr_struct fields directly, as in f17210d242597cc64b1037776a5318e15d0647ee) works fine.)

@StefanKarpinski

If that works, then maybe I'm wrong about this. The & syntax may provide a pointer to the data rather than the box. In that case the issue must be something else.

@stevengj
Owner

@StefanKarpinski, my understanding is that &b is not a jl_value_t*, it is the pointer to the member data. This came up on the julia-dev list when I was developing PyCall. This is necessary in order to call C routines expecting struct pointers, and has worked for a long time.

#2818 goes further than this, and makes jl_value_t* point to the member data, which erases the current distinction between pointer_from_objref(b) and &b.

@andrioni
Collaborator

If so, then it makes sense why this works

type mpc_struct
    # Real MPFR part
    reprec::Clong
    resign::Cint
    reexp::Clong
    red::Ptr{Void}
    # Imaginary MPFR part
    imprec::Clong
    imsign::Cint
    imexp::Clong
    imd::Ptr{Void}
end

while this doesn't

type mpfr_struct
    prec::Clong
    sign::Cint
    exp::Clong
    d::Ptr{Void}
end
type mpc_struct
    re::mpfr_struct
    im::mpfr_struct
end

The second one probably includes the boxes for the mpfr_structs, so it segfaults when I call mpc_init3.

@vtjnash
Collaborator

Those two declarations are quite different in that the mpfr_struct is allocated inline in the mpc_struct in the first example, but in the second example, mpc_struct merely contains two pointers (jl_value_t*). My work in #2818 would make the 2nd example compatible with many C libraries, but not this one.

@stevengj
Owner

See above: I'm still not clear on why we need MPC at all. What advantage does it bring over Complex{BigFloat}, assuming BigFloat is implemented with MPFR?

@andrioni
Collaborator

Potentially more efficient implementations of the trigonometric functions (I have yet to check) and having different precisions for the real and the imaginary parts. MPACK (multiple precision BLAS+LAPACK) may use MPC, but I don't if it's needed or not.

@ViralBShah
Owner

We do not use libm implementations for the complex trig functions for single and double precision. It would be better to avoid an extra library in the build, if possible, and use generic julia code. Of course, we can always add MPC later, if we change our mind.

@JeffBezanson

I'm going to cherry pick the changes to BigInt that close #2839.

@JeffBezanson

Ok, why is there both mpz_struct and BigInt wrapping it? Couldn't we make do with just the former?

@andrioni
Collaborator

Using BigInt directly instead of having mpz_struct leads to stack overflows. An example of BigInt in this way is here.

@JeffBezanson

Of course. Damn there is too much going on and I'm not able to keep track of everything.

@JeffBezanson

It's because of

convert{T<:Integer}(::Type{BigInt}, x::T) = BigInt(x)

trying to convert BigInt to BigInt.

@JeffBezanson

Since our BigInts are immutable, we can define BigInt(x::BigInt) = x, which will fix this.

@andrioni
Collaborator

Well, I was using BigInt(x::BigInt) as a copy constructor, so I never thought it'd be an issue.

@JeffBezanson

In julia numbers are immutable by convention, so there is no need for copy constructors.

@andrioni
Collaborator

Thanks, @JeffBezanson, now it is working.

@JeffBezanson

Nice! Looking forward to merging this.

@stevengj
Owner

@andrioni, it would good to have a benchmark showing a significant performance advantage to MPC (versus Complex{BigFloat}), as using Complex{BigFloat} provides substantial usability advantages in a Julia context.

(I don't think that the ability to use differing precisions for the real and imaginary parts is a compelling advantage; I'm not sure of the use-case for that.)

(The thing about linear algebra with arbitrary-precision values is that the performance becomes completely arithmetic-bound. Most of the complexity of LAPACK and BLAS has to do with blocking operations for the memory hierarchy, and that goes away here. It seems like much simpler LINPACK-style implementations, e.g. a 3-loop textbook implementation of LU with partial pivoting, should be just as good as a LAPACK-style blocked implementation once arithmetic becomes the bottleneck. (Eigenvalue algorithms are still fairly complicated, though.) So, I'm not sure that MPACK is the best approach to arbitrary-precision linear algebra.)

@andrioni
Collaborator

Here's a small benchmark I've just wrote to test addition and multiplication, and here are the results:

julia> benchmark(1000000)
MPCComplex
elapsed time: 3.801137814 seconds
elapsed time: 4.067451952 seconds
elapsed time: 4.064801694 seconds
elapsed time: 4.08396451 seconds
elapsed time: 3.791925912 seconds
Complex{MPFRFloat}
elapsed time: 15.303616165 seconds
elapsed time: 15.046311355 seconds
elapsed time: 15.36503601 seconds
elapsed time: 15.063599901 seconds
elapsed time: 15.577502974 seconds

Both are using 256-bit floats for each of the components, and both returned the same value. The great advantage of MPC is curious, especially since even just the addition is faster:

julia> benchmark_add(1000000)
MPCComplex
elapsed time: 1.860483595 seconds
elapsed time: 1.582588105 seconds
elapsed time: 1.566541694 seconds
elapsed time: 1.823278764 seconds
elapsed time: 1.549144944 seconds
Complex{MPFRFloat}
elapsed time: 5.086425175 seconds
elapsed time: 4.780957285 seconds
elapsed time: 5.101767226 seconds
elapsed time: 4.867165618 seconds
elapsed time: 4.906140103 seconds

Considering that the MPC code for addition is completely straight-forward, I think the problem could be in the allocation of intermediaries.

MPC code:

/* return 0 iff both the real and imaginary parts are exact */
int
mpc_add (mpc_ptr a, mpc_srcptr b, mpc_srcptr c, mpc_rnd_t rnd)
{
  int inex_re, inex_im;

  inex_re = mpfr_add (mpc_realref(a), mpc_realref(b), mpc_realref(c), MPC_RND_RE(rnd));
  inex_im = mpfr_add (mpc_imagref(a), mpc_imagref(b), mpc_imagref(c), MPC_RND_IM(rnd));

  return MPC_INEX(inex_re, inex_im);
}
@JeffBezanson

Can we inline the space for the mpfr float into the BigFloat struct like we did for BigInt? It could be 6 Int32 fields if nothing else.

@andrioni
Collaborator

I'm working on it right now. Some small issues arise because a Ptr{MPFRFloat} isn't the same as a Ptr{MPFRFloat{N}}, so I'm trying to fix them right now. Any recommendations and/or a way to ignore this kind of typecheck? I'm considering scrapping the use of parametric types for BigFloats, to be honest.

@JeffBezanson

Yes, I suspect the precision is too dynamic to be useful as a type parameter. Two MPFR floats with different precisions are really of exactly the same type and can be combined with no trouble.

@andrioni
Collaborator

There we are. As soon as the MPC status is defined, I'll rename MPFRFloat to BigFloat, iron out any last issues and start updating the documentation.

Anyone can see why make check is run for MPFR and MPC after every build? I'm not very proficient with Makefile magic.

@andrioni
Collaborator

The same benchmark as above but done in 5a33e37d0dd8912f5c8c3f3ab624d1803ad61864:

julia> benchmark(1000000)
MPCComplex
elapsed time: 3.427331435 seconds
elapsed time: 3.739340839 seconds
elapsed time: 3.379784126 seconds
elapsed time: 3.795981066 seconds
elapsed time: 3.425525577 seconds
Complex{MPFRFloat}
elapsed time: 8.764472844 seconds
elapsed time: 8.930827007 seconds
elapsed time: 9.069092048 seconds
elapsed time: 8.942332004 seconds
elapsed time: 8.909431904 seconds

Some improvements in both ways, but using MPC is still quite faster.

EDIT: Just addition:

julia> benchmark_add(1000000)
MPCComplex
elapsed time: 1.600921134 seconds
elapsed time: 1.505429175 seconds
elapsed time: 1.522493259 seconds
elapsed time: 1.165482978 seconds
elapsed time: 1.509874264 seconds
Complex{MPFRFloat}
elapsed time: 2.222745837 seconds
elapsed time: 2.242084832 seconds
elapsed time: 2.251348006 seconds
elapsed time: 2.234148905 seconds
elapsed time: 2.233682002 seconds
@ViralBShah
Owner

I notice that none of the BigFloat types are immutable. Perhaps they should all be immutable in line with the rest of the numbers all being immutable in julia. I wonder if it would also give a performance boost.

@JeffBezanson

Right now they can't be immutable, since they need finalizers.

@stevengj
Owner

I'm a little confused, because I don't see how

 +(z::Complex, w::Complex) = complex(real(z) + real(w), imag(z) + imag(w))

will allocate unnecessary temporaries for Complex{MPFRFloat}. Operations like real and imag should (by default for Complex) return a reference, not a copy. Each + operation should return a new MPFRFloat, which complex then uses to build the Complex{MPFRFloat} return value; this seems like the minimal number of allocations.

Is your benchmark doing the MPC addition in-place on a pre-allocated result, which would give it an unfair advantage?

@andrioni
Collaborator

I thought

 +(z::Complex, w::Complex) = complex(real(z) + real(w), imag(z) + imag(w))

would use four temporaries: real(z) + real(w), imag(z) + imag(w) and their copies when complex is called, but I'm probably wrong.

No, no pre-allocated results are used, as all operations always allocate new memory to guarantee immutability. Maybe it happens because Complex{MPFRFloat} has to call two finalizers instead of one?

@StefanKarpinski

I made the old BigInt type immutable by putting the finalized on the memory buffer instead. Can't do that here though.

@andrioni
Collaborator

exp, log and trigonometric functions are added to MPCComplex, and I've used @simonbyrne's test suite from #2845 to check them for correctness. Seven sign issues were found (the test suite expected a -Inf, but MPC returned a +Inf) and are commented in the tests.

@JeffBezanson
andrioni added some commits
@andrioni andrioni Basic support for building the MPFR 4acb40c
@andrioni andrioni Add more mentions to the MPFR on the build system and documentation 9853f7f
@andrioni andrioni Add mpc to the build system and basic documentation 6762def
@andrioni andrioni Add MPC and MPFR to Base
Both MPC and MPFR are building correctly and running all tests (the
same I had when they were a different package).
Currently, the biggest issue is that `make check` for MPFR and MPC
run all their tests, considerably lengthening the build process.
e0ec409
@andrioni andrioni Change BigInt to use a precise mpz_struct
As discussed in #2814.
f48a16a
@andrioni andrioni Install libmpfr-dev and libmpc-dev packages explicitly 5142d1d
@andrioni andrioni Update MPFRFloat to use a precise sized mpfr_struct
As discussed in #2814. The function `sum` is disabled currently
(so the default one is used as a fallback), as it needs direct
pointer access to each of the members of the array.
f88a640
@andrioni andrioni Change default precision of MPFRFloat to 256 bits
As discussed in #2814
94ba263
@andrioni andrioni Rename precision-related functions and add them to Float32 and Float64
Now get_precision is defined for all T <: FloatingPoint, and returns
24 for Float32 and 53 for Float64 (the effective number of bits in the
mantissa, taking in account the implicit leading bit.

get_bigfloat_precision and set_bigfloat_precision are used to get and set
the defaults for all BigFloats, and the BigComplex case is analogous.
9bff273
@andrioni andrioni Update MPCComplex to use a precise mpc_struct
As using two mpfr_structs doesn't work, I decided to expand them
directly into two groups of four elements (two longs, an int and
a pointer). They could be useful if we ever need to implement
efficient in-place algorithms, as they can be directly extracted
and manipulated as MPFRFloats.
4309078
@andrioni andrioni Flexibilize the ROUNDING_MODE for MPCComplex numbers cd20424
@andrioni andrioni Convert methods for other common complex types available
These methods were written in order to avoid having to use real()
or imag(), as they create a new MPFRFloat object.
2d23952
@andrioni andrioni Use more efficient addition/subtraction/multiplication for ints/uints
This also is the first function which tries to take in account
that Clong is not always Int.
38392cd
@andrioni andrioni Scrap mpz_struct, as suggested by Jeff d458148
@andrioni andrioni Fix ccall type issues in bigint.jl, according to #2901
Now it uses Culong and Clong when needed.
d23657c
@andrioni andrioni Inline MPFRFloat structure and refactor it into a non-parametric type 1ee273e
@andrioni andrioni Fix ccall type signatures in mpfr.jl, according to #2901 577b307
@andrioni andrioni Fix the BigInt basic arithmetic issues 3bead72
@andrioni andrioni Implement efficient basic arithmetic for signed/unsigned/float/BigInt…
… and MPFRFloat

The four basic operations are now implemented using the MPFR functions
instead of promotion to MPFRFloat.
9a00d5a
@andrioni andrioni Add hypot function b25a36e
@andrioni andrioni Inline MPCComplex structure and refactor it into a non-parametric type ba9a8d4
@andrioni andrioni Add copy function to MPCComplex 07346b0
@andrioni andrioni Change default precision of MPCComplex to 256-256 8b33832
@andrioni andrioni Add exp, log, trigonometric functions and @simonbyrne's test suite
Some sign issues were found and commented in test file, and no
errors are thrown yet.
28328d0
@andrioni andrioni Add conjugate function to MPCComplex 1b9ba27
@andrioni andrioni Add ldexp and atan2 functions to MPFRFloat
As they are being used by @jiahao in the new Kahan complex functions,
it is needed to have them in MPFRFloat.
4a01f1b
@andrioni andrioni Fix Makefile after rebase 22e6f36
@andrioni andrioni Basic rounding control available for MPFRFloat bec3c4f
@andrioni andrioni Finally rename MPFRFloat to BigFloat and remove the old code 0eca14e
@andrioni andrioni Remove all mentions to MPC, as it was decided to scrap it
Now BigComplex support is given directly through Complex{BigFloat}.
728a1f5
@andrioni
Collaborator

Can someone comment on the rounding modes? Currently I'm using constants in the MPFR module, should I rename/export them?

Other than that, I think it is finally reasonably finished. I've also rebased it (up to 9a72fab), so the merge should be simple.

@StefanKarpinski

See #2976 – we don't currently expose rounding modes, but we should have a uniform interface across IEEE 754 and other types of floats for rounding modes. So I would say hold off exposing if for now and leave it as part of #2976.

@JeffBezanson
Owner

Why are we now back to using separate BigInt and mpz_struct types? Not a big deal, I guess I can change it myself.
Also, unfortunately there is a new merge conflict.

@andrioni
Collaborator

Ahem, I unfortunately destroyed the changes on the repo trying to merge it on my lab computer, I'll restore it as soon as I get back home.

@andrioni
Collaborator

Which should be in twenty minutes.

@andrioni
Collaborator

Restored now. (that's why one should never use rebase to rewrite history nor try to manually push changes on a Friday afternoon :))

@JeffBezanson
Owner

Awesome! Hoping to merge this today.

@JeffBezanson JeffBezanson merged commit fd89714 into JuliaLang:master

1 check passed

Details default The Travis build passed
@andrioni
Collaborator

Feel free to assign me to any issues related to BigFloat or BigInt, I'm willing to support them and help as much as I can :)

@JeffBezanson
Owner

Thanks, and thanks again for doing this. After a couple small tweaks it's looking good!

@ViralBShah
Owner

@andrioni It would be great if you could add the documentation for BigFloat and even review the BigInt documentation. For the rest of the issues that are not addressed here (make check, sum, etc.), I think we should open new issues so that these are not lost.

Fantastic work.

@andrioni andrioni referenced this pull request
Closed

0.2 release notes #2581

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on May 3, 2013
  1. @andrioni
  2. @andrioni
  3. @andrioni
  4. @andrioni

    Add MPC and MPFR to Base

    andrioni authored
    Both MPC and MPFR are building correctly and running all tests (the
    same I had when they were a different package).
    Currently, the biggest issue is that `make check` for MPFR and MPC
    run all their tests, considerably lengthening the build process.
  5. @andrioni

    Change BigInt to use a precise mpz_struct

    andrioni authored
    As discussed in #2814.
  6. @andrioni
  7. @andrioni

    Update MPFRFloat to use a precise sized mpfr_struct

    andrioni authored
    As discussed in #2814. The function `sum` is disabled currently
    (so the default one is used as a fallback), as it needs direct
    pointer access to each of the members of the array.
  8. @andrioni
  9. @andrioni

    Rename precision-related functions and add them to Float32 and Float64

    andrioni authored
    Now get_precision is defined for all T <: FloatingPoint, and returns
    24 for Float32 and 53 for Float64 (the effective number of bits in the
    mantissa, taking in account the implicit leading bit.
    
    get_bigfloat_precision and set_bigfloat_precision are used to get and set
    the defaults for all BigFloats, and the BigComplex case is analogous.
  10. @andrioni

    Update MPCComplex to use a precise mpc_struct

    andrioni authored
    As using two mpfr_structs doesn't work, I decided to expand them
    directly into two groups of four elements (two longs, an int and
    a pointer). They could be useful if we ever need to implement
    efficient in-place algorithms, as they can be directly extracted
    and manipulated as MPFRFloats.
  11. @andrioni
  12. @andrioni

    Convert methods for other common complex types available

    andrioni authored
    These methods were written in order to avoid having to use real()
    or imag(), as they create a new MPFRFloat object.
  13. @andrioni

    Use more efficient addition/subtraction/multiplication for ints/uints

    andrioni authored
    This also is the first function which tries to take in account
    that Clong is not always Int.
  14. @andrioni
  15. @andrioni

    Fix ccall type issues in bigint.jl, according to #2901

    andrioni authored
    Now it uses Culong and Clong when needed.
  16. @andrioni
  17. @andrioni
  18. @andrioni
  19. @andrioni

    Implement efficient basic arithmetic for signed/unsigned/float/BigInt…

    andrioni authored
    … and MPFRFloat
    
    The four basic operations are now implemented using the MPFR functions
    instead of promotion to MPFRFloat.
  20. @andrioni

    Add hypot function

    andrioni authored
  21. @andrioni
  22. @andrioni
  23. @andrioni
  24. @andrioni

    Add exp, log, trigonometric functions and @simonbyrne's test suite

    andrioni authored
    Some sign issues were found and commented in test file, and no
    errors are thrown yet.
  25. @andrioni
  26. @andrioni

    Add ldexp and atan2 functions to MPFRFloat

    andrioni authored
    As they are being used by @jiahao in the new Kahan complex functions,
    it is needed to have them in MPFRFloat.
  27. @andrioni

    Fix Makefile after rebase

    andrioni authored
  28. @andrioni
  29. @andrioni
  30. @andrioni

    Remove all mentions to MPC, as it was decided to scrap it

    andrioni authored
    Now BigComplex support is given directly through Complex{BigFloat}.
  31. @andrioni

    Remove MPC version

    andrioni authored
Something went wrong with that request. Please try again.