from the credit where credit is due department: Arb (available with
Nemo.jl) is better.
On Saturday, October 17, 2015 at 7:43:02 PM UTC-4, John Gibson wrote:
>
> I have to take back a couple things. The Julia docs are clearer than I
> thought about the BigFloat type: it's fixed-sized but arbitr
I have to take back a couple things. The Julia docs are clearer than I
thought about the BigFloat type: it's fixed-sized but arbitrarily large,
with size resettable by a function call. Second,
julia> eps(BigFloat)
1.72723371101925077270372560079914223200072887256277004740694033718360632485e
I have re-implemented a number of them. The better double-double libraries
are very good +,-,*,^, exp, slightly less so with /; I found some trig lsbs
to be wiggly.
I mapped triple-double basics and quad-double algorithms into a triplet
cooperative, used internally to assure the manifold smooth
I have been -- this has taken up much of the past month. The better
double-double libraries are very good +,-,*,^, exp, slightly less so with
/; I found some trig lsbs to be wiggly.
I hand down-converted some quad-double algorithms and routines to be
triple-double work-alikes. I use them inter
On Saturday, October 17, 2015 at 9:39:54 AM UTC-4, Jeffrey Sarnoff wrote:
>
> I am working on routines for a double-double-like floating point type.
>>
>>
There are plenty of such libraries already existing as free/open-source
software. Why not crib from them?
>
> Have you found Unums to more a probable solution or more of an exploratory
> project?
A little of both, I guess. I do think the framework has the potential to
solve many problems that are seemingly impossible using floating points
with any precision (including infinite!) This is due to the
My local design will enfold any type <: Real that supports the usual ops
for an AbstractFloat and for which fma is defined.
Float12x does not do that, to be more transparent for others' useful play.
On Saturday, October 17, 2015 at 2:41:41 PM UTC-4, Jeffrey Sarnoff wrote:
>
> My local design w
My local design will enfold any type <: AbstractFloat for which fma is
defined. Float12x does not do that, to be more transparent for others.
On Saturday, October 17, 2015 at 1:27:44 PM UTC-4, Tom Breloff wrote:
>
> Jeffrey: If you're building your own floating point library specifically
> gea
Have you found Unums to more a probable solution or more of an exploratory
project?
On Saturday, October 17, 2015 at 1:27:44 PM UTC-4, Tom Breloff wrote:
>
> Jeffrey: If you're building your own floating point library specifically
> geared toward ensuring exact results when mathematically possi
It is Float128 in resolution and modulo the refining the trig, in accuracy
of results if one allows the least sig nibble to be inexact . Float125,
Float127 are working titles.
BigFloat is not used except as an intermediary for IO/strings (and for
running tests). BigFloat is problematic becaus
Jeffrey: If you're building your own floating point library specifically
geared toward ensuring exact results when mathematically possible, then I
highly recommend you read up on Unums and come collaborate with me:
https://github.com/tbreloff/Unums.jl. There's a bunch of info/links in the
wiki th
Ok, I see from github that you're working on a Float125 and Float127
implementation. Why not Float128?, and why not use Julia BigFloats? Out of
curiosity, I did a few tests on Julia's sin(BigFloat).
julia> p=Float64(pi)
3.141592653589793
julia> length(string(p))
17
julia> sin(p)
1.224646799
thanks, good pointer.
I am working on routines for a double-double-like floating point type.
Straight double-double implementations have very nice arithmetic
properties; in my experimentation, most double-double trig routines resolve
fewer bits than I want.
I want to take as much advantage of
Search for the comment that begins "OK kiddies, time for the pros"
in
http://stackoverflow.com/questions/2284860/how-does-c-compute-sin-and-other-math-functions
John
On Saturday, October 17, 2015 at 9:00:35 AM UTC-4, John Gibson wrote:
>
> Why are you trying to roll your own sin(x) function
Why are you trying to roll your own sin(x) function? I think you will be
hard pressed to improve on the library sin(x) in either speed or accuracy.
John
On Saturday, October 17, 2015 at 3:38:17 AM UTC-4, Jeffrey Sarnoff wrote:
>
> I had tried to find a clean way to jump into the taylor series us
I had tried to find a clean way to jump into the taylor series using the
well approximated sin(x) or cos(x) and so additionally limit the terms used
-- there may be / probably is a way in concert with an additional
tabulation (which would be fine in this case). Taylor's theorem is not
numerica
That has promise, Kristoffer. I did port something of that nature,
expecting it to work well -- but there was some numerical mush in more than
a couple of trailing bits in some cases.
Using more terms did not help. Thinking about it just now, it might be more
robustly stable if I expand in one
Use a truncated Taylor series around the point maybe?
your point about sin^2 + cos^2 is well taken --
On Friday, October 16, 2015 at 10:35:39 PM UTC-4, Jeffrey Sarnoff wrote:
>
> I am not using a library, I am writing one.
> I have e.g. for x = 0.5, sinx = sin(x); cosx=cos(x);
> I want sinxx = sin(x + dx), cosxx = cos(x +dx) for dx << x.
> Is there
I am not using a library, I am writing one.
I have e.g. for x = 0.5, sinx = sin(x); cosx=cos(x);
I want sinxx = sin(x + dx), cosxx = cos(x +dx) for dx << x.
Is there some relationship that allows me to refine sinxx, cosxx
simultaneously?
On Friday, October 16, 2015 at 10:23:05 PM UTC-4, Yichao Yu
On Fri, Oct 16, 2015 at 10:14 PM, Jeffrey Sarnoff
wrote:
> Is there a way to use sin(x)^2 + cos(x)^2 = 1 to refine very close
> approximations to sin(x), cos(x)?
> I am using an extended precision, so I have Float64 approximations for
> sin,cos for 'free'.
>
I would guess any library you use to d
Is there a way to use sin(x)^2 + cos(x)^2 = 1 to refine very close
approximations to sin(x), cos(x)?
I am using an extended precision, so I have Float64 approximations for
sin,cos for 'free'.
22 matches
Mail list logo
