subject:"Use of C99 extra long double math functions after r236148"

On Sun, Jul 08, 2012 at 11:51:56AM -0600, Warner Losh wrote:
 
 On Jul 8, 2012, at 6:40 AM, David Schultz wrote:
 
  On Tue, May 29, 2012, Peter Jeremy wrote:
  On 2012-May-28 15:54:06 -0700, Steve Kargl 
  s...@troutmask.apl.washington.edu wrote:
  Given that cephes was written years before C99 was even
  conceived, I suspect all functions are sub-standard.
  
  Well, most of cephes was written before C99.  The C99 parts of
  cephes were written to turn it into a complete C99 implementation.
  
  I'm a bit late to the party, but I thought I'd chime in with some
  context.  We did consider using Cephes years ago, and even got
  permission from the author to release it under an acceptable license.
  We later decided not to use it for technical reasons.
  
  By the way, virtually none of the people who have complained about the
  missing functions actually need them.  Mostly they just want to
  compile some software that was written by a naive programmer who
  thought it would be cool to use the most precise type available.  The
  complex functions are even less commonly needed, and the truth is that
  they have no business being part of the C standard anyway.
  
  The question remains of what to do about the missing functions.  Bruce
  and Steve have been working on expl and logl for years.  If those ever
  get in the tree, the remaining long double functions are easy.  Those
  functions are basically done, modulo a bunch of cleanup and testing,
  and I encourage any mathematically inclined folks who are interested
  in pushing things along to get in touch with them.  I'm not going to
  have any time myself for a few months at least.
 
 Where can I find these?

I've posted expl() a few times for the ld80 version.
I don't have an ld128 version, which is why I have
yet to submit a formal patch for expl().  I also
have an ld80 expm1l().  I have a copy of bde's ld80
logl().  IIRC, bde wrote an ld128, but I don't have
nor do I know if it has been tested.

  Lastly, there's the question of mediocre alternatives, such as
  solutions that get the boundary cases wrong or don't handle 128-bit
  floating point.  For the exponential and logarithmic functions, Bruce
  and Steve have already written good implementations, so there's no
  reason to settle for less.  As for the other long double functions,
  bringing in some Cephes code in a separate directory as a temporary
  fix might be the way to go.  I don't like that solution, and Steve
  raises some good technical points about why it isn't ideal; however, a
  better solution is more than a decade overdue, and people are
  justified in finding that unacceptable.
 
 Don't let the perfect be the enemy of the good.  It is better to
 have OK implementations of these functions than none at all.

You'll need to define OK, because some of the implementations
I've read are poor.  I also hope that before anything is
committed to libm that the person doing the committing does
some rather thorough testing of the code.

 We originally had so-so double support, but bruce spent many
 years optimizing them to make them very good.  If we were
 just starting out, and hadn't let 10 years get behind us, I'd
 give the substandard argument some weight.  But now that we're
 13 years down the line from c99's publication I think we need
 to relax our standards a bit.  I'd even argue that these
 functions being a little bad could easily spur people to make
 them better.  Their absence makes people just
 #define llexp(x) lexp(x), etc. :(

Of course, the converse argument is that people have had 10 years
to learn enough about floating point to actually write and submit
code.  I knew very little about FP before I wrote sqrtl().  I had
a need for sqrtl() and so I went looking for a solution.

PS: I also wrote sincos[fl](), which is very handy for the
complex trig functions.
 
-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-07-08 Thread David Schultz

On Sun, Jul 08, 2012, Steve Kargl wrote:
   The question remains of what to do about the missing functions.  Bruce
   and Steve have been working on expl and logl for years.  If those ever
   get in the tree, the remaining long double functions are easy.  Those
   functions are basically done, modulo a bunch of cleanup and testing,
   and I encourage any mathematically inclined folks who are interested
   in pushing things along to get in touch with them.  I'm not going to
   have any time myself for a few months at least.
  
  Where can I find these?
 
 I've posted expl() a few times for the ld80 version.
 I don't have an ld128 version, which is why I have
 yet to submit a formal patch for expl().  I also
 have an ld80 expm1l().  I have a copy of bde's ld80
 logl().  IIRC, bde wrote an ld128, but I don't have
 nor do I know if it has been tested.

Yes, Bruce has ld128 versions, and clusteradm very kindly got us a
sparc64 machine to test on.  That was about the time I ran out of time
to keep working on it.  If someone wants to pick it up, that would be
great.

 PS: I also wrote sincos[fl](), which is very handy for the
 complex trig functions.

Yes, you should commit that!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote:
 Here is a technical question.  I know that people always talk about 
 ulp's in the context of how good a function implementation is.  I think 
 the ulp is the number of base 2 digits at the end of the mantissa that 
 we cannot rely on.

There are a few definitions of ULP (units in the last place).
Google 'Muller ULP' and check goldberg's paper (google
'goldberg floating point'.

Here's how I define ULP for my testing and the MPFR code.

/* From a das email:
 ulps = err * (2**(LDBL_MANT_DIG - e)), where e = ilogb(z).

 I use:

 mpfr_sub(err, acc_out, approx_out, GMP_RNDN);
 mpfr_abs(err, err, GMP_RNDN);
 mpfr_mul_2si(ulpx, err, -mpfr_get_exp(acc_out) + LDBL_MANT_DIG, GMP_RNDN);
 ulp = mpfr_get_d(ulpx, GMP_RNDN);
 if (ulp  0.506  mpfr_cmpabs(err, ldbl_minx)  0) {
   print warning...;
 }
*/
#include gmp.h
#include mpfr.h
#include sgk.h

static mpfr_t mp_ulp_err;

/*
 * Set the precision of the ULP computation.
 */
void
mp_ulp_init(int prec)
{
mpfr_init2(mp_ulp_err, (mpfr_prec_t)prec);
}

/*
 * Given the 'approximate' value of a function and
 * an 'accurate' value compute the ULP.
 */
double
mp_ulp(mpfr_t approximate, mpfr_t accurate, int dig)
{
double ulp;
mpfr_sub(mp_ulp_err, accurate, approximate, RD);
mpfr_abs(mp_ulp_err, mp_ulp_err, RD);
mpfr_mul_2si(mp_ulp_err, mp_ulp_err, - mpfr_get_exp(accurate) + dig,
RD);
ulp = mpfr_get_d(mp_ulp_err, RD);
return (ulp);   
}

 So if one were to write a naive implementation of lexp(x) that used 
 Taylor's series if x is positive, and 1/lexp(-x) is x is negative - well 
 one could fairly easily estimate an upper bound on the ulp, but it 
 wouldn't be low (like ulp=1 or 2), but probably rather higher (ulp of 
 the order of 10 or 20).

I've already written an ld80 expl().  I have tested billions if not
trillions of values.  Don't recall the max ULP I saw, but I know it
was less than 1.  I don't have an ld128 version, so I won't submit
a patch for libm.

 So do people really work hard to get that last drop of ulp out of their 
 calculations?

I know very few scientist who work hard to reduce the ULP.  Most
have little understanding of floating point.  

  Would a ulp=10 be considered unacceptable?

Yes, it is unacceptable for the math library.  Remember ULPs
propagate and can quickly grow if the initial ulp for a 
result is large. 

 Also, looking through the source code for the FreeBSD implementation of 
 exp, I saw that they used some rather smart rational function.  (I don't 
 know how they came up with it.)

See Steven Moshier's book, which is the basis for CEPHES.
Instead of using a minimax polynomial approximation for
the function in some interval, one uses a minimax approximation
with a rational function.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-07-08 Thread Stephen Montgomery-Smith


On 07/08/2012 06:58 PM, Steve Kargl wrote:

On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote:



So do people really work hard to get that last drop of ulp out of their
calculations?


I know very few scientist who work hard to reduce the ULP.  Most
have little understanding of floating point.


  Would a ulp=10 be considered unacceptable?


Yes, it is unacceptable for the math library.  Remember ULPs
propagate and can quickly grow if the initial ulp for a
result is large.


OK.  But suppose I wanted ld80 precision.  What would be the advantage 
of using an ld80 expl function with a ulp of 1 over an ld128 expl 
function with a ulp of 10?  The error propagation in the latter case 
could not be worse than the error propagation in the latter case.


In other words, if I were asked to write a super-fantastic expl 
function, where run time was not a problem, I would use mpfr, use 
Taylor's series with a floating point precision that had way more digits 
than I needed, and then just truncate away the last digits when 
returning the answer.  And this would be guaranteed to give the correct 
answer to just above 0.5 ulp (which I assume is best possible).


From a scientist's point of view, I would think ulp is a rather 
unimportant concept.  The concepts of absolute and relative error are 
much more important to them.


The only way I can see ULP errors greatly propagating is if one is 
performing iteration type calculations (like f(f(f(f(x).  This sort 
of thing is done when computing Julia sets and such like.  And in that 
case, as far as I can see, a slightly better ulp is not going to 
drastically change the limitations of whatever floating point precision 
you are using.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

On Sun, Jul 08, 2012 at 07:29:30PM -0500, Stephen Montgomery-Smith wrote:
 On 07/08/2012 06:58 PM, Steve Kargl wrote:
 On Sun, Jul 08, 2012 at 02:06:46PM -0500, Stephen Montgomery-Smith wrote:
 
 So do people really work hard to get that last drop of ulp out of their
 calculations?
 
 I know very few scientist who work hard to reduce the ULP.  Most
 have little understanding of floating point.
 
   Would a ulp=10 be considered unacceptable?
 
 Yes, it is unacceptable for the math library.  Remember ULPs
 propagate and can quickly grow if the initial ulp for a
 result is large.
 
 OK.  But suppose I wanted ld80 precision.  What would be the advantage 
 of using an ld80 expl function with a ulp of 1 over an ld128 expl 
 function with a ulp of 10?  The error propagation in the latter case 
 could not be worse than the error propagation in the latter case.

Well, on the most popular hardware (that being i386/amd64), 
ld80 will use hardware fp instruction while ld128 must be
done completely in software.  The speed difference is 
significant.

 In other words, if I were asked to write a super-fantastic expl 
 function, where run time was not a problem, I would use mpfr, use 
 Taylor's series with a floating point precision that had way more digits 
 than I needed, and then just truncate away the last digits when 
 returning the answer.  And this would be guaranteed to give the correct 
 answer to just above 0.5 ulp (which I assume is best possible).

It's more like 1 ULP after truncation (, which isn't truncation 
but rounding).

The problem is run-time that 'run-time is the problem'.  Try
writing a expl() and simply use mpfr_exp() with 64-bit
precision.  If you're doing any serious simulation where 
exp() will be evaluate millions or billions of time, you'll
notice the difference.

 The only way I can see ULP errors greatly propagating is if one is 
 performing iteration type calculations (like f(f(f(f(x).

Have you read Goldberg's paper?

Not to mention, I've seen way too many examples of 'x - y'
where cancellation of significant digits causes
problems.  Throw in rather poor estimates of function
results with real poor ULP and you have problems.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-07-08 Thread Warner Losh


On Jul 8, 2012, at 8:01 PM, Steve Kargl wrote:
 Not to mention, I've seen way too many examples of 'x - y'
 where cancellation of significant digits causes
 problems.  Throw in rather poor estimates of function
 results with real poor ULP and you have problems.

Are these problems significantly more or less than the usual #define I talked 
about before?  If the functions are so so, but much better than the double 
version, we have a significant win, even if things aren't perfect.

If we weren't 13 past the publication date of the c99 standard, I'd be more 
sympathetic to the 'we need a high quality implementation' arguments.  However, 
we can't let the perfect be the enemy of the good here.  We claim c99 
conformance, yet don't have these functions. 

After all, many of the original functions that were in our library had 
sub-optimial performance which bruce optimized over many years.  Why can't we 
use this model here?

Warner

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

On Sun, Jul 08, 2012 at 08:13:21PM -0600, Warner Losh wrote:
 
 On Jul 8, 2012, at 8:01 PM, Steve Kargl wrote:
  Not to mention, I've seen way too many examples of 'x - y'
  where cancellation of significant digits causes
  problems.  Throw in rather poor estimates of function
  results with real poor ULP and you have problems.
 
 Are these problems significantly more or less than the
 usual #define I talked about before?  If the functions
 are so so, but much better than the double version, we
 have a significant win, even if things aren't perfect.

The answer is more complicated than the question asked.
On i386, the precision of long double and double is
53 bits.  On amd64, the precision of long double and
double are 64 and 53 bits.  On i386 and amd64, emax
and emin are 1024 and -1023 (could be off by one here)
for double and 16384 and -16383 for long double.  Now,
consider 2**emin = exp(x) = 2**emax for some set of
x (where I'm using the Fortran exponential operator **
instead of powl(2,{emin|emax}) because FreeBSD does not
have a powl()).  The sets for long double and double are
significantly different.

 If we weren't 13 past the publication date of the c99 standard,
 I'd be more sympathetic to the 'we need a high quality
 implementation' arguments.  However, we can't let the perfect
 be the enemy of the good here.  We claim c99 conformance, yet
 don't have these functions. 

AFAIK, neither gcc in base nor clang would be c99 complaint
even if all of the c99 math functions were available.

 After all, many of the original functions that were in our
 library had sub-optimial performance which bruce optimized
 over many years.  Why can't we use this model here?

I think the fear is that committing sub-optimal code would
take many many more years to fix.  AFAICT, bde longer commits
code to src/ (since the switch from cvs to svn), and he depends
on his code reviews to get things fixed.  With das and me
both having little to no time for FreeBSD, that leaves no one
to review/commit his suggested fixes (not that I would question
bde's opinion on a code change).

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-07-08 Thread Stephen Montgomery-Smith


On 07/08/2012 09:01 PM, Steve Kargl wrote:


Have you read Goldberg's paper?


I must admit that I had not.  I found it at:

http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html


Not to mention, I've seen way too many examples of 'x - y'
where cancellation of significant digits causes
problems.  Throw in rather poor estimates of function
results with real poor ULP and you have problems.


I think that if a program includes x-y where cancellation causes huge 
loss of digits, then the program should be considered highly flawed. 
The programmer might get lucky, and a few extra ULP might save his skin, 
but it would be better if the program catastrophically failed so that he 
would realize they need to do something smarter.


I got my first scientific calculator around 1975, and I remember my 
surprise when I discovered that (1/3)*3-1 on my calculator did not 
produce zero.  Years later I bought another calculator, and imagine my 
further surprise when (1/3)*3-1 did produce zero.  They must have done 
something very smart, I thought.


The problem is, these kinds of tricks can only help you so much. 
Calculations like 
arccos(arccos(arccos(arccos(cos(cos(cos(cos(x)-x are probably 
not going to be correct no matter how smart the programmer is.


The paper by Goldberg has some really nice stuff.  I teach a class on 
numerical methods.  One example I present is the problem using equation 
(4) of Goldberg's paper to solve quadratic equations.  I tell them that 
the smart thing to do is to use equation (4) or equation (5) depending 
on whether b has the same sign as sqrt(b^2-4ac).  This is a very good 
illustration of how to overcome the x-y problem, and in my opinion it 
has to be understood by the programmer, not the writer of the 
square-root package.  Trying to compensate by getting that lost drop of 
ULP out of square root is looking in the wrong direction.


But there is other stuff in his paper I don't like, and it comes across 
as nit-picking rather than really thinking through why he wants the 
extra accuracy.  I feel like he is saving the pennies, but losing the 
dollars.


For example, computing the quadratic formula when b^2 and 4ac are 
roughly equal (discussed in his proof of Theorem 4).  He says that 
roughly half the digits of the final answer will be contaminated.  He 
recommends performing the calculation with double the precision, and 
then retaining what is left.  The reason I don't like his solution is 
this.  The contamination of half the digits is real, not some artifact 
of the computing method.  Unless you know EXACTLY what a, b and c are, 
only half the digits of the quadratic formula are valid, no matter how 
you calculate it.  For example, maybe a is calculated by some other part 
of the program as 1/3.  Since 1/3 cannot be represented exactly in base 
2, it will not be exactly 1/3.  That part of the program doesn't know 
that this number is going to be used later on in the quadratic formula, 
so it computes it in single precision.  Now the quadratic formula 
algorithm converts a to double precision.  But a will still be 1/3 to 
single precision.  The only way to avoid this error is to perform EVERY 
pertinent calculation prior to the use of quadratic formula in double 
precision.  (And suppose instead the data comes from a scientific 
experiment - the programmer needs to be performing an error analysis, 
not hoping his implementation of quadratic formula is performed in 
double precision.)


Similarly, I am not a fan of the Kahan Summation Formula (Theorem 8). 
There are two reasons why I might compute large sums.  One is 
accounting, when I better be using high enough precision that the 
arithmetic is exact.  The other is something like numerical integration. 
 But in the latter case, unless the summands have a very special form, 
it is likely that each summand will only be accurate to within e.  Thus 
the true sum is only known to within n*e, and so the naive method really 
hasn't lost any precision at all.  And typically n*e will be so small 
compared to the true answer that it won't matter.  If it does matter, 
the problem is that n is too big.  The algorithm will take decades to 
run.  Focus efforts on producing a different numerical integration 
method, instead of getting that lost drop of ULP.  I cannot envision any 
non-contrived circumstance where the Kahan summation formula is going to 
give an answer that is significantly more reliable than naive summation. 
 I can envision a circumstance when the reduction in speed of the Kahan 
summation formula over naive summation could be significant.


I think the example I like best that illustrates floating point errors 
is inverting badly conditioned matrices.  And any scientist who works 
with large matrices had better know what ill-conditioned means.  The 
proper answer is that if your matrix is ill-conditioned, give up.  You 
need to look at the problem where your matrix came from, and rethink how 
you concert

Re: Use of C99 extra long double math functions after r236148

On Sun, Jul 08, 2012 at 10:41:44PM -0500, Stephen Montgomery-Smith wrote:
 On 07/08/2012 09:01 PM, Steve Kargl wrote:
 
 Have you read Goldberg's paper?
 
 I must admit that I had not.  I found it at:
 
 http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

Yes, it's easy to find.  Unfortunately, many people don't
know that it exists.  I've read that paper between 10 and
20 times and I still learn something new with every reading.

 Not to mention, I've seen way too many examples of 'x - y'
 where cancellation of significant digits causes
 problems.  Throw in rather poor estimates of function
 results with real poor ULP and you have problems.
 
 I think that if a program includes x-y where cancellation causes huge 
 loss of digits, then the program should be considered highly flawed. 
 The programmer might get lucky, and a few extra ULP might save his skin, 
 but it would be better if the program catastrophically failed so that he 
 would realize they need to do something smarter.
 
 I got my first scientific calculator around 1975, and I remember my 
 surprise when I discovered that (1/3)*3-1 on my calculator did not 
 produce zero.  Years later I bought another calculator, and imagine my 
 further surprise when (1/3)*3-1 did produce zero.  They must have done 
 something very smart, I thought.

Yes.  They used CORDIC arithmetic instead of (binary) floating point.

 The problem is, these kinds of tricks can only help you so much. 
 Calculations like 
 arccos(arccos(arccos(arccos(cos(cos(cos(cos(x)-x are probably 
 not going to be correct no matter how smart the programmer is.

Well, I would claim that any programmer who wrote such an
expression is not smart.

 The paper by Goldberg has some really nice stuff.  I teach a class on 
 numerical methods.

It may be profitable to at least have your students read the
paper.  I don't know about others, but I find doing floating
point arithematic correctly very difficult.

 One example I present is the problem using equation 
 (4) of Goldberg's paper to solve quadratic equations.  I tell them that 
 the smart thing to do is to use equation (4) or equation (5) depending 
 on whether b has the same sign as sqrt(b^2-4ac).  This is a very good 
 illustration of how to overcome the x-y problem, and in my opinion it 
 has to be understood by the programmer, not the writer of the 
 square-root package.  Trying to compensate by getting that lost drop of 
 ULP out of square root is looking in the wrong direction.

Careful.  IEEE 754 specifies and one can prove that sqrt()
can be computed correctly to less than or equal to 1/2 ULP
for all input in all rounding modes.  Computing the roots
of the quartic equation, which uses the sqrt() function,
is a different matter.

 But there is other stuff in his paper I don't like, and it comes across 
 as nit-picking rather than really thinking through why he wants the 
 extra accuracy.  I feel like he is saving the pennies, but losing the 
 dollars.

well, in Goldberg's defense, think about the title of the paper.
I think his major aim in the paper is get scientist to think
about what and how they compute some number.  

 Similarly, I am not a fan of the Kahan Summation Formula (Theorem 8). 

Oh my.  I'm a fan of Kahan's summation formula.  But, I assume
that one applies it to situations where it is needed.

 There are two reasons why I might compute large sums.  One is 
 accounting, when I better be using high enough precision that the 
 arithmetic is exact.

If you're doing accouting, hopefully, you're using BCD.
Accouting and floating point simply do not mix.

  The other is something like numerical integration. 
  But in the latter case, unless the summands have a very special form, 
 it is likely that each summand will only be accurate to within e.  Thus 
 the true sum is only known to within n*e, and so the naive method really 
 hasn't lost any precision at all.  And typically n*e will be so small 
 compared to the true answer that it won't matter.  If it does matter, 
 the problem is that n is too big.  The algorithm will take decades to 
 run.  Focus efforts on producing a different numerical integration 
 method, instead of getting that lost drop of ULP.  I cannot envision any 
 non-contrived circumstance where the Kahan summation formula is going to 
 give an answer that is significantly more reliable than naive summation. 
 I can envision a circumstance when the reduction in speed of the Kahan 
 summation formula over naive summation could be significant.

I can envision a use.  Try computing the RMS height of a
numerically generated random rough surface in the scattering
of an incident acoustic field from said surface.  The RMS
height is a main component in the first order perturbation
theory expansion of the scattered field.  You get the
RMS height wrong, you have no idea what the scatter field
strength is.

 I think the example I like best that illustrates floating point errors 
 is inverting badly

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread Eitan Adler

On 31 May 2012 08:45, John Baldwin j...@freebsd.org wrote:
 I do think we should provide something in ports as an interim solution.
 There are other 3rd party applications looking to drop FreeBSD support
 because we are missing APIs that almost all other OS's have.  I'm fine
 if the interim lives in ports and that we don't import substandard
 routines into the base.  I would even be fine with calling it
 /usr/local/lib/libm_inaccurate.so.  However, I do think we need an option.

Do we have a wiki page listing the functions in libm we are missing?
Having some kind of place to track progress and figure out what
exactly is needed is the first step to getting these APIs into shape.

Also, are there BSD licensed naive implementations of these functions
we can use? Would it be okay to have slow, but accurate versions of
these functions as a stopgap?

-- 
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread b. f.

  I do think we should provide something in ports as an interim solution.
  There are other 3rd party applications looking to drop FreeBSD support
  because we are missing APIs that almost all other OS's have.  I'm fine
  if the interim lives in ports and that we don't import substandard
  routines into the base.  I would even be fine with calling it
  /usr/local/lib/libm_inaccurate.so.  However, I do think we need an option.
 

 I think it should be called libm.so.  Otherwise we have to do a serious
 editing job on the Makefiles/configure scripts.

I think that this is as it should be: only those applications that
really need to link against such a library should do so, and this
should be enforced and checked by the port maintainer.  If you call it
by the same name you still need to make other changes to ensure that
the right library is used, and these other changes can be confusing
and lead to problems, as with the openssl and gcc support libraries.
Some portable applications already provide convenient variables in
their build infrastructure, since the quality, coverage, and location
of the math libraries varies on different systems.

b.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread b. f.

 Do we have a wiki page listing the functions in libm we are missing?
 Having some kind of place to track progress and figure out what
 exactly is needed is the first step to getting these APIs into shape.

I already suggested this, and mentioned:

http://wiki.freebsd.org/MissingMathStuff

 Also, are there BSD licensed naive implementations of these functions
 we can use? Would it be okay to have slow, but accurate versions of
 these functions as a stopgap?

I don't know of any BSD-licensed routines that would be suitable for
use in the base system.  You can cobble together replacements from
various ports, with different licenses.  For example, if you wanted
accuracy and correctness, but didn't care about speed, you could use
math/mpc and math/mpfr.  Unfortunately, with many naive
implementations, you often lose more than just speed.

b.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread John Baldwin

On Friday, June 01, 2012 1:55:10 am Eitan Adler wrote:
 On 31 May 2012 08:45, John Baldwin j...@freebsd.org wrote:
  I do think we should provide something in ports as an interim solution.
  There are other 3rd party applications looking to drop FreeBSD support
  because we are missing APIs that almost all other OS's have.  I'm fine
  if the interim lives in ports and that we don't import substandard
  routines into the base.  I would even be fine with calling it
  /usr/local/lib/libm_inaccurate.so.  However, I do think we need an option.
 
 Do we have a wiki page listing the functions in libm we are missing?
 Having some kind of place to track progress and figure out what
 exactly is needed is the first step to getting these APIs into shape.
 
 Also, are there BSD licensed naive implementations of these functions
 we can use? Would it be okay to have slow, but accurate versions of
 these functions as a stopgap?

Peter Jeremy more or less has a stopgap already ready judging by the comments 
in the thread thus far.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread Peter Jeremy

On 2012-Jun-01 10:29:13 -0400, John Baldwin j...@freebsd.org wrote:
On Friday, June 01, 2012 1:55:10 am Eitan Adler wrote:
 Also, are there BSD licensed naive implementations of these functions
 we can use? Would it be okay to has slow, but accurate versions of
 these functions as a stopgap?

Peter Jeremy more or less has a stopgap already ready judging by the comments 
in the thread thus far.

There's probably an hours work by either stephen@ or myself to adapt
the work I did on cephes in Sage to a standalone FreeBSD port.
Unfortunately, both stephen@  I are currently otherwise occupied and
other comments in this thread suggest that the inclusion of such a port
would be strongly opposed.

Note that cephes isn't slow but accurate - it's reasonably fast but
naive and therefore dodgy in edge cases.

-- 
Peter Jeremy


pgpHAsPC0mWbI.pgp
Description: PGP signature

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread Eitan Adler

On 1 June 2012 17:03, Peter Jeremy pe...@rulingia.com wrote:
 On 2012-Jun-01 10:29:13 -0400, John Baldwin j...@freebsd.org wrote:
On Friday, June 01, 2012 1:55:10 am Eitan Adler wrote:
 Also, are there BSD licensed naive implementations of these functions
 we can use? Would it be okay to has slow, but accurate versions of
 these functions as a stopgap?

Peter Jeremy more or less has a stopgap already ready judging by the comments
in the thread thus far.

 There's probably an hours work by either stephen@ or myself to adapt
 the work I did on cephes in Sage to a standalone FreeBSD port.
 Unfortunately, both stephen@  I are currently otherwise occupied and
 other comments in this thread suggest that the inclusion of such a port
 would be strongly opposed.

 Note that cephes isn't slow but accurate - it's reasonably fast but
 naive and therefore dodgy in edge cases.

Yes, I was asking if any of the former type exist.
Optimally we would want fast and accurate - but it doesn't currently exist.
Fast, but inaccurate has been strongly objected to.

Is there third option?



-- 
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread Steve Kargl

On Fri, Jun 01, 2012 at 05:16:03PM -0700, Eitan Adler wrote:
 On 1 June 2012 17:03, Peter Jeremy pe...@rulingia.com wrote:
  On 2012-Jun-01 10:29:13 -0400, John Baldwin j...@freebsd.org wrote:
 On Friday, June 01, 2012 1:55:10 am Eitan Adler wrote:
  Also, are there BSD licensed naive implementations of these functions
  we can use? Would it be okay to has slow, but accurate versions of
  these functions as a stopgap?
 
 Peter Jeremy more or less has a stopgap already ready judging by the 
 comments
 in the thread thus far.
 
  There's probably an hours work by either stephen@ or myself to adapt
  the work I did on cephes in Sage to a standalone FreeBSD port.
  Unfortunately, both stephen@  I are currently otherwise occupied and
  other comments in this thread suggest that the inclusion of such a port
  would be strongly opposed.
 
  Note that cephes isn't slow but accurate - it's reasonably fast but
  naive and therefore dodgy in edge cases.
 
 Yes, I was asking if any of the former type exist.
 Optimally we would want fast and accurate - but it doesn't currently exist.
 Fast, but inaccurate has been strongly objected to.
 
 Is there third option?
 

Of course.  Sit down and write code.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread Eitan Adler

On 1 June 2012 23:52, Steve Kargl s...@troutmask.apl.washington.edu wrote:

 Of course.  Sit down and write code.

If I ever find the time, I just might. Do we have a wiki page listing
the set of functions which we don't yet have?


-- 
Eitan Adler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-06-01 Thread Steve Kargl

On Sat, Jun 02, 2012 at 12:04:58AM -0400, Eitan Adler wrote:
 On 1 June 2012 23:52, Steve Kargl s...@troutmask.apl.washington.edu wrote:
 
  Of course. ??Sit down and write code.
 
 If I ever find the time, I just might. Do we have a wiki page listing
 the set of functions which we don't yet have?
 

I don't know.  I don't read the wiki.  You can
many/most/all by looking in /usr/include/math.h
There are many #if 0 ... #endif blocks.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-31 Thread John Baldwin

On Monday, May 28, 2012 7:02:18 pm Steve Kargl wrote:
 On Tue, May 29, 2012 at 07:05:07AM +1000, Peter Jeremy wrote:
  On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith 
step...@missouri.edu wrote:
  One thing that could be done is to have a math/cephes port that adds 
  the extra C99 math functions.  This is already done in the math/sage 
  port, using a rather clever patch due to Peter Jeremy, that applies to 
  the cephes code.
  
  What it would do is to create a /usr/local/lib/libm.so that would 
  provide the extra functions not currently included in /lib/libm.so, and 
  then link in /lib/libm.so as well.  It would also create its own 
  /usr/local/include/math.h and /usr/local/include/complex.h as well.
  
  Basically, as long as the compiler searches /usr/local/{include,lib}
  before the base include/lib then math.h, complex.h and -lm give
  the application a complete C99 math implementation by using base
  functions where they exist and cephes functions where they don't.
  
  The patch I wrote for sage can be found at
  http://trac.sagemath.org/sage_trac/ticket/9543
  If there's any interest, I could produce a port for this.
  
  Another option would be to import cephes into base and use it to
  provide the missing C99 functions.  Cephes includes copyright notices
  but the closest I can find to a license is:
 Some software in this archive may be from the book _Methods and
   Programs for Mathematical Functions_ (Prentice-Hall or Simon  Schuster
   International, 1989) or from the Cephes Mathematical Library, a
   commercial product. In either event, it is copyrighted by the author.
   What you see here may be used freely but it comes with no support or
   guarantee.
 
 Please talk to das@ (although I believe he's finishing up his
 dissertation).  I recall that he's stated that he looked into
 using cephes, and concluded that it is not suitable for libm.
 
 Note there is also
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599
 
 which I've also objected to importing into libm.

I do think we should provide something in ports as an interim solution.
There are other 3rd party applications looking to drop FreeBSD support
because we are missing APIs that almost all other OS's have.  I'm fine
if the interim lives in ports and that we don't import substandard
routines into the base.  I would even be fine with calling it 
/usr/local/lib/libm_inaccurate.so.  However, I do think we need an option.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-31 Thread Stephen Montgomery-Smith


On 05/31/12 10:45, John Baldwin wrote:

On Monday, May 28, 2012 7:02:18 pm Steve Kargl wrote:

On Tue, May 29, 2012 at 07:05:07AM +1000, Peter Jeremy wrote:

On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith

step...@missouri.edu  wrote:

One thing that could be done is to have a math/cephes port that adds
the extra C99 math functions.  This is already done in the math/sage
port, using a rather clever patch due to Peter Jeremy, that applies to
the cephes code.

What it would do is to create a /usr/local/lib/libm.so that would
provide the extra functions not currently included in /lib/libm.so, and
then link in /lib/libm.so as well.  It would also create its own
/usr/local/include/math.h and /usr/local/include/complex.h as well.


Basically, as long as the compiler searches /usr/local/{include,lib}
before the base include/lib thenmath.h,complex.h  and -lm give
the application a complete C99 math implementation by using base
functions where they exist and cephes functions where they don't.

The patch I wrote for sage can be found at
http://trac.sagemath.org/sage_trac/ticket/9543
If there's any interest, I could produce a port for this.

Another option would be to import cephes into base and use it to
provide the missing C99 functions.  Cephes includes copyright notices
but the closest I can find to a license is:
   Some software in this archive may be from the book _Methods and
  Programs for Mathematical Functions_ (Prentice-Hall or Simon  Schuster
  International, 1989) or from the Cephes Mathematical Library, a
  commercial product. In either event, it is copyrighted by the author.
  What you see here may be used freely but it comes with no support or
  guarantee.


Please talk to das@ (although I believe he's finishing up his
dissertation).  I recall that he's stated that he looked into
using cephes, and concluded that it is not suitable for libm.

Note there is also

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599

which I've also objected to importing into libm.


I do think we should provide something in ports as an interim solution.
There are other 3rd party applications looking to drop FreeBSD support
because we are missing APIs that almost all other OS's have.  I'm fine
if the interim lives in ports and that we don't import substandard
routines into the base.  I would even be fine with calling it
/usr/local/lib/libm_inaccurate.so.  However, I do think we need an option.



I think it should be called libm.so.  Otherwise we have to do a serious 
editing job on the Makefiles/configure scripts.


sed -E 's/[[::]]-lm[[::]]/-lm_inaccuarate/'

might have some false positives and false negatives.  (Did I even get 
the sed syntax correct?)




By the way, I was looking through:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599

They say they compute cosh(2y) - cos(2x) using Taylor's series.  I would 
agree with Steve that this is seriously low quality.  Floating point 
errors are likely to be truly horrible.  This will fail even for 
non-edge cases.  (This was the same error that openoffice used to have 
for computing erf(x), that gave things like erf(100) = -4353243242.)


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-31 Thread Daniel O'Connor


On 01/06/2012, at 2:42, Stephen Montgomery-Smith wrote:
 
 I do think we should provide something in ports as an interim solution.
 There are other 3rd party applications looking to drop FreeBSD support
 because we are missing APIs that almost all other OS's have.  I'm fine
 if the interim lives in ports and that we don't import substandard
 routines into the base.  I would even be fine with calling it
 /usr/local/lib/libm_inaccurate.so.  However, I do think we need an option.
 
 
 I think it should be called libm.so.  Otherwise we have to do a serious 
 editing job on the Makefiles/configure scripts.
 
 sed -E 's/[[::]]-lm[[::]]/-lm_inaccuarate/'
 
 might have some false positives and false negatives.  (Did I even get the sed 
 syntax correct?)


Another option would be to put it in base but bleat about it if it's actually 
used (like mktemp et al)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-30 Thread Hans Ottevanger


On 05/29/12 19:54, Stephen Montgomery-Smith wrote:

[...]



Anyway, given that floating point is a big issue, and we are about a
decade behind schedule, really suggests that a
floating-po...@freebsd.org mailing list is needed. Or maybe there is an
existing freebsd mailing list you guys already occupy.



I would certainly take part in discussions on such a list.

And since I have developed similar software in the past, I could even 
contribute a bit more, if desired. I have quite a tight schedule, but 
this type of development does not require an extensive infrastructure 
and can be done in lost hours on the road.



Kind regards,

Hans Ottevanger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-30 Thread Mark Linimon

Perhaps a more general name might be appropriate so as to include
fixed-point problems?  math-libs@?  numerics@?

I'm sure someone will come up with a better name.

mcl
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-30 Thread Mehmet Erol Sanliturk

On Wed, May 30, 2012 at 8:51 AM, Mark Linimon lini...@lonesome.com wrote:

 Perhaps a more general name might be appropriate so as to include
 fixed-point problems?  math-libs@?  numerics@?

 I'm sure someone will come up with a better name.

 mcl



Numerics@ is good .

Other names may be

numerical-analysis@
computing@  ( includes high performance computing )
mathematics@  ( includes statistics , numerical analysis ,
computation , probability , ... )


Thank you very much .

Mehmet Erol Sanliturk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-30 Thread Adrian Chadd

Holy crap, if there was ever a current example of a bikeshed, this is it. :-)



Adrian


On 30 May 2012 10:19, Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote:
 On Wed, May 30, 2012 at 8:51 AM, Mark Linimon lini...@lonesome.com wrote:

 Perhaps a more general name might be appropriate so as to include
 fixed-point problems?  math-libs@?  numerics@?

 I'm sure someone will come up with a better name.

 mcl



 Numerics@ is good .

 Other names may be

 numerical-analysis@
 computing@              ( includes high performance computing )
 mathematics@          ( includes statistics , numerical analysis ,
 computation , probability , ... )


 Thank you very much .

 Mehmet Erol Sanliturk
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-30 Thread b. f.

This discussion confirms my impression, that it should be possible as an
interim solution, to use a port for missing math functions (cephes alike
or whatever). The port itself could warn the user about inaccuracies and
edge-cases.

Parts of Cephes are already in ports: math/ldouble.  I had planned to
add the remainder.  It can be useful, but it has problems, some of
which have been described.  The same is true of other open-source
alternatives that I am aware of.


I would be happy to take on any steep learning curve, and make
contributions, if only I were part of a group that would steer me in the
right direction.


A Functional Analyst offering to write code for a floating-point math
library!?!! ;)  You should send me a message off-list: maybe I can
find some time to help.


Anyway, given that floating point is a big issue, and we are about a
decade behind schedule, really suggests that a
floating-point at freebsd.org mailing list is needed.  Or maybe there is an
existing freebsd mailing list you guys already occupy.


I do not know that a separate FreeBSD mailing list would be of great
help, considering the likely volume of traffic, and the fact that we
already have the standards mailing list.  There is also:

http://mailman.oakapple.net/pipermail/numeric-interest/

which serves, among other things, as a forum for discussing changes
and improvements to the open-source math library from which parts of
our system math library were derived:

http://mailman.oakapple.net/pipermail/numeric-interest/2010-September/002054.html

A wiki page detailing problems and procedures, with a wish list for
the system libraries and toolchain(s) might help.  At present there
are only scattered messages in the mailing list archives, PRs, and
http://wiki.freebsd.org/MissingMathStuff .

b.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-29 Thread Steve Kargl

On Tue, May 29, 2012 at 02:56:13PM +1000, Peter Jeremy wrote:
 On 2012-May-28 15:54:06 -0700, Steve Kargl 
 s...@troutmask.apl.washington.edu wrote:
 
 There some test code in cephes.  Can you point me to a suitable test
 suite for LD80 and LD128?  The reason for calling it libm is to avoid
 having to hack every consumer to add an additional library.

I can't point you to test code.  When I work on a function,
I write test code.

   It took
 me 3+ years to get sqrtl() into libm, but bde and das (and
 myself) wanted to make sure the code worked.
 
 Last time I checked (a couple of years ago), FreeBSD was missing 65
 C99 libm functions.  At 3 years per function, we should have C99
 support available early in the 23rd century - which may be a bit late.

sqrtl() is a bit special in that IEEE 754 requires that
it have no more than 0.5 ULP for all arguments in all
roundng modes.  As to other functions, I've been trying
for 10+ years to get some of these into FreeBSD.  I can
assure you that there has never been a rush of people
volunteering to help or a rush of people willing to fund
the development of the necessary code. 

 
 On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smith 
 step...@missouri.edu wrote:
 1.  By being so picky about being so precise, FreeBSD is behind the time 
 line in rolling out a usable set of C99 functions.
 
 And at the current rate, we'll all be long dead before they are
 available.

It seems you've had a couple of years to implement one or
more of the missing functions.  Yes, we'll all be dead before
libm is C99 ready because no one, other than bde@, das@ and
myself, has been willing to actually help write the code.  I
know that at least one of those three people has had no time
in the last year or two work on libm. 

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-29 Thread Rainer Hurling


On 29.05.2012 08:10 (UTC+1), Steve Kargl wrote:

On Tue, May 29, 2012 at 02:56:13PM +1000, Peter Jeremy wrote:

On 2012-May-28 15:54:06 -0700, Steve Kargls...@troutmask.apl.washington.edu  
wrote:

There some test code in cephes.  Can you point me to a suitable test
suite for LD80 and LD128?  The reason for calling it libm is to avoid
having to hack every consumer to add an additional library.


I can't point you to test code.  When I work on a function,
I write test code.


  It took
me 3+ years to get sqrtl() into libm, but bde and das (and
myself) wanted to make sure the code worked.


Last time I checked (a couple of years ago), FreeBSD was missing 65
C99 libm functions.  At 3 years per function, we should have C99
support available early in the 23rd century - which may be a bit late.


sqrtl() is a bit special in that IEEE 754 requires that
it have no more than 0.5 ULP for all arguments in all
roundng modes.  As to other functions, I've been trying
for 10+ years to get some of these into FreeBSD.  I can
assure you that there has never been a rush of people
volunteering to help or a rush of people willing to fund
the development of the necessary code.


The almost complete absence of volunteers in this case is first of all 
caused by the need of very special, deep knowlegdes on mathematical and 
informatical issues. I bet there are only a few people out there, who 
are really good in both (three of them are known to us ;) ). The 
problems with quality standards in such libraries spreaded over most 
OS'es and platforms support this view. (I am aware that these arguments 
are kown and discussed before.)


People like me, who wanted to _use_ FreeBSD as scientific desktops, have 
an urgent need on such mathematical libraries. But most of us have no 
chance to contribute conceptual. For some tasks we could use specialized 
libraries or software, which include missing procedures and functions. 
But more often, modern apps expect to get this functionalities from the OS.


This discussion confirms my impression, that it should be possible as an 
interim solution, to use a port for missing math functions (cephes alike 
or whatever). The port itself could warn the user about inaccuracies and 
edge-cases.


The more important question to me is, how can the remaining (huge!) work 
on the systems libm done in a foreseeable time. As one possibility, 
wouldn't it be imaginable to pay some people for doing (some of) this 
work (FreeBSD Foundation, Sponsors from industry and science etc.)? I 
personally, as a private person, would be willing to pay a few hundred 
dollars for it. Paying people for other tasks in FreeBSD is not entirely 
uncommon, if I am not mistaken.




On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smithstep...@missouri.edu  
wrote:

1.  By being so picky about being so precise, FreeBSD is behind the time
line in rolling out a usable set of C99 functions.


And at the current rate, we'll all be long dead before they are
available.


It seems you've had a couple of years to implement one or
more of the missing functions.  Yes, we'll all be dead before
libm is C99 ready because no one, other than bde@, das@ and
myself, has been willing to actually help write the code.  I
know that at least one of those three people has had no time
in the last year or two work on libm.



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-29 Thread Stephen Montgomery-Smith


On 05/29/2012 11:48 AM, Rainer Hurling wrote:

On 29.05.2012 08:10 (UTC+1), Steve Kargl wrote:



sqrtl() is a bit special in that IEEE 754 requires that
it have no more than 0.5 ULP for all arguments in all
roundng modes. As to other functions, I've been trying
for 10+ years to get some of these into FreeBSD. I can
assure you that there has never been a rush of people
volunteering to help or a rush of people willing to fund
the development of the necessary code.


The almost complete absence of volunteers in this case is first of all
caused by the need of very special, deep knowlegdes on mathematical and
informatical issues. I bet there are only a few people out there, who
are really good in both (three of them are known to us ;) ). The
problems with quality standards in such libraries spreaded over most
OS'es and platforms support this view. (I am aware that these arguments
are kown and discussed before.)



The more important question to me is, how can the remaining (huge!) work
on the systems libm done in a foreseeable time. As one possibility,
wouldn't it be imaginable to pay some people for doing (some of) this
work (FreeBSD Foundation, Sponsors from industry and science etc.)? I
personally, as a private person, would be willing to pay a few hundred
dollars for it. Paying people for other tasks in FreeBSD is not entirely
uncommon, if I am not mistaken.


If there were a freebsd-floating-po...@freebsd.org mailing list to 
discuss these issues, I would eagerly join.  While I have never written 
libm-style libraries myself, I do have knowledge of both computers AND 
mathematics, and I do teach two university courses: Numerical Methods 
and Numerical Linear Algebra.  And I have written quite a bit of 
numerical code, so I do know about the issues of testing and debugging 
such code.


I would be happy to take on any steep learning curve, and make 
contributions, if only I were part of a group that would steer me in the 
right direction.


Finally, Steve made a point that the way gcc multiplies complex numbers 
is wasteful in computational time.  I have been bitten by this.  I wrote 
some code that involved multiplying large numbers of complex numbers.  I 
first wrote it using the complex C99 code.  Then I rewrote it using 
double, writing out the complex multiplication long hand, and the 
program went twice as fast!  (It involved multiplying numbers that were 
purely real or purely imaginary, so performing (x)*(I*y) by 
(x+0*I)*(0+y*I) really did slow it down.)


Anyway, given that floating point is a big issue, and we are about a 
decade behind schedule, really suggests that a 
floating-po...@freebsd.org mailing list is needed.  Or maybe there is an 
existing freebsd mailing list you guys already occupy.


Stephen
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-29 Thread Adrian Chadd

.. I don't think it's a bad idea to get freebsd-numeric@ created and
start discussing this kind of stuff there.



Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-29 Thread Julian H. Stacey

Hi,
Reference:
 From: Stephen Montgomery-Smith step...@missouri.edu 

 Anyway, given that floating point is a big issue, and we are about a 
 decade behind schedule, really suggests that a 
 floating-po...@freebsd.org mailing list is needed.  Or maybe there is an 
 existing freebsd mailing list you guys already occupy.

The string fl does not occur in 
http://lists.freebsd.org/mailman/listinfo/
Apart from this list, you might also find extra people interested to support 
a proposal to create a floating-point@ list among the subscribers to:
freebsd-performance@
freebsd-standards@
freebsd-toolchain@
Good luck

Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Reply below not above, cumulative like a play script,  indent with  .
 Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
Mail from @yahoo dumped @berklix.  http://berklix.org/yahoo/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148


On 05/28/2012 07:07 PM, Steve Kargl wrote:

On Mon, May 28, 2012 at 06:44:42PM -0500, Stephen Montgomery-Smith wrote:

On 05/28/2012 06:30 PM, Steve Kargl wrote:



 From clog.c in http://www.netlib.org/cephes/c9x-complex

double complex
ccosh (z)
  double complex z;
{
   double complex w;
   double x, y;

   x = creal(z);
   y = cimag(z);
   w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
   return (w);
}

See math_private.h about the above.



I looked in math_private.h - I presume you meant
lib/msun/src/math_private.h.  I wasn't able to find anything about ccosh
there.

I think that for a rough and ready ccosh, this is high enough quality
for a math/cephes port.


That's the problem.  It is not acceptable (imo).  The comment in
math_private.h that is relevant is

/*
  * Inline functions that can be used to construct complex values.
  *
  * The C99 standard intends x+I*y to be used for this, but x+I*y is
  * currently unusable in general since gcc introduces many overflow,
  * underflow, sign and efficiency bugs by rewriting I*y as
  * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product.
  * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted
  * to -0.0+I*0.0.
  */

Those wrong +-0 mean you may up end up on the worng riemann sheet,
and that NaN propagates.



OK, I agree with you that gcc fails to be C99 compliant.  But I disagree 
with you that this is a big deal.


1.  By being so picky about being so precise, FreeBSD is behind the time 
line in rolling out a usable set of C99 functions.  The compilers and 
operating systems have many bugs, and if we waited until we were totally 
sure that all the bugs were gone, we wouldn't have any operating system 
to work with at all.  Why be more picky with floating point arithmetic 
than the other aspects of FreeBSD?


2.  If I was really worried about being on the correct Riemann sheet, I 
would code very, very carefully, and not rely on numerical accuracy of 
any kind of floating point calculation.  There is a certain mathematical 
inconsistency in introducing 0, -0 and Inf+I*Inf, and the number of 
times programmers really want a very specific kind of behavior for 
exceptions is so rare that they are better off writing their own wrapper 
code than relying on any library functions.  (For example, is there a 
difference between 0 and +0?  If not, does -(0) compute to 0 or -0?  I 
can see circumstances where I sometimes want one, and sometimes the other.)


3.  But to counter my own argument, it highly bothers me that in C that 
(-5)%3 evaluates to -2 and not to 1.  That bug^H^H^H feature has 
truly bitten me.  And I have had lengthy arguments online with some C 
experts as to why 1 should be the correct answer, without being able 
to convince them.  If it were up to me, the whole of the C standard 
would be scrapped, and rewritten with everything exactly the same except 
for this one thing.  But to those I argued with, I seem just as picky as 
you seem when you insist that 0 and -0 are different.  So what do I do? 
 I live with it, just like we all live in an imperfect world.


If I had a choice between correcting the C standard for % or solving 
world hunger, I would definitely settle for the second.  And maybe the C 
programming language, for all its imperfections, has helped push 
frontiers of technology sufficiently that someone is less hungry than 
they would have otherwise been.  And if those resources used to feed 
people had been redirected to fix the C standard, then maybe a few more 
people would be hungry.


In the end, I do think it is good to ultimately settle on good C99 
compliant code.  But having something intermediate that mostly works is 
better than nothing.  Especially if it exists only in the ports, and not 
in the base code.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread David Chisnall

On 28 May 2012, at 05:35, Rainer Hurling wrote:

 Yesterday r236148 (Allow inclusion of libc++ cmath to work after including 
 math.h) was comitted to head, many thanks.
 
 Does this mean, that extra long double functions like acoshl, expm1l or 
 log1pl are now really implemented? As far as I understand, they had only 
 been declared before?

They are still not implemented.  The cmath header in libc++ provides wrappers 
around these functions for C++, but if they are not declared then the compiler 
throws an error.  Now there is a linker error if they are used, but if they are 
not used then it works irrespective of whether you just include cmath or do 
undefined things like include math.h first.

 If this is right, are they usable on a recent CURRENT, built with gcc42 
 (system compiler), by ports which use gcc46 (not clang)? If not, are there 
 any plans to implement these functions in the near future?

I think they're one of the last bits of C99 / C11 that anyone actually cares 
about (C11 unicode support being another), so they'll probably get done at some 
point, but doing them correctly is nontrivial, except on platforms where double 
and long double are the same.  

 The use of C99 extra long double functions would be of interest for example 
 for programs like math/R, especially its upcoming releases.

I would be very wary of anything that depends on long double.  The C spec makes 
no constraints on the range of float, double, or long double, but by convention 
on most platforms float is an IEEE 754 32-bit floating point value and double 
is 64-bit.  No such conventions apply to long doubles and I know of (widely 
deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively. 
 I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even 
though the platform ABI spec recommends using 128 bits.  x86 uses 80-bit x87 
values (although sizeof(long double) may be 16 because they have some padding 
bytes in memory).  If your program is tolerant of a potential variation in 
precision between 64 bits and 128 bits, then it is probably tolerant of just 
using doubles.

David___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread Rainer Hurling

On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 05:35, Rainer Hurling wrote:

First I should note that I am by no means an expert in C / C++ or C99
standards. So my comments are only on a level of someone who is using
FreeBSD for scientific purposes like GIS and math applications and who
is the maintainer of some scientific ports (like math/saga).

Yesterday r236148 (Allow inclusion of libc++cmath to work after including
math.h) was comitted to head, many thanks.

Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now
really implemented? As far as I understand, they had only been declared
before?

They are still not implemented. Thecmath header in libc++ provides wrappers around
these functions for C++, but if they are not declared then the compiler throws an error. Now
there is a linker error if they are used, but if they are not used then it works irrespective of
whether you just includecmath or do undefined things like includemath.h first.

Ok, that's what I had supposed. Because the main difference between
r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest
is more a type of binning?

If this is right, are they usable on a recent CURRENT, built with gcc42 (system
compiler), by ports which use gcc46 (not clang)? If not, are there any plans to
implement these functions in the near future?

I think they're one of the last bits of C99 / C11 that anyone actually cares
about (C11 unicode support being another), so they'll probably get done at some
point, but doing them correctly is nontrivial, except on platforms where double
and long double are the same.

Yes, I agree. These outstanding long double math functions (like log1pl)
and better unicode support are really needed for some important third
party projects like R or SAGA GIS.

In the past I have read several times discussions about the correctness
of long double functions on FreeBSD. Some drafts have been dismissed
because of there inaccuracy in special cases. Also was discussed to get
missing libm routines from NetBSD [1]. It appears as if we have to wait
some more time ...

The use of C99 extra long double functions would be of interest for example for
programs like math/R, especially its upcoming releases.

I would be very wary of anything that depends on long double. The C spec makes
no constraints on the range of float, double, or long double, but by convention
on most platforms float is an IEEE 754 32-bit floating point value and double
is 64-bit. No such conventions apply to long doubles and I know of (widely
deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively.
I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even
though the platform ABI spec recommends using 128 bits. x86 uses 80-bit x87
values (although sizeof(long double) may be 16 because they have some padding
bytes in memory). If your program is tolerant of a potential variation in
precision between 64 bits and 128 bits, then it is probably tolerant of just
using doubles.

Yes, I think in most cases math/R is tolerant enough of just using
doubles. But in the near future they plan to implement much more of the
C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks
from release to release [2]. So these problems will increase :-(

Many thanks for your fast und well explained answer, I really appreciate it.

Rainer

David

[1]
http://lists.freebsd.org/pipermail/freebsd-standards/2011-February/002119.html

[2] https://stat.ethz.ch/pipermail/r-devel/2012-May/064128.html

And some more places I found interesting about C99 and FreeBSD

[3] http://www.freebsd.org/projects/c99/index.html

[4] http://wiki.freebsd.org/MissingMathStuff

[5] http://marc.info/?l=freebsd-standardsm=123158761305427

[6]
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028030.html

[7]
http://www.koders.com/c/fid164FD2F50C9AAA63119A641875824455B3AE6B55.aspx?s=log1pl.c

[8] http://www.mail-archive.com/bug-gnulib@gnu.org/msg26571.html

[9] http://leaf.dragonflybsd.org/mailarchive/commits/2011-12/msg00190.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread David Chisnall

On 28 May 2012, at 13:30, Rainer Hurling wrote:

 On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:
 On 28 May 2012, at 05:35, Rainer Hurling wrote:
 
 Ok, that's what I had supposed. Because the main difference between r236147 
 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a 
 type of binning?

Yes, it's just about making libc++'s cmath header compile, nothing more.  

 Yes, I agree. These outstanding long double math functions (like log1pl) and 
 better unicode support are really needed for some important third party 
 projects like R or SAGA GIS.

I very much doubt that anything is using the C11 unicode stuff yet, since no 
compiler or libc currently supports it...

 In the past I have read several times discussions about the correctness of 
 long double functions on FreeBSD. Some drafts have been dismissed because of 
 there inaccuracy in special cases. Also was discussed to get missing libm 
 routines from NetBSD [1]. It appears as if we have to wait some more time ...

I thought we did pull in some NetBSD libm stuff recently.  Not sure what the 
status of that is, you'd need to check with das@.

 Yes, I think in most cases math/R is tolerant enough of just using doubles. 
 But in the near future they plan to implement much more of the C99 stuff and 
 their tolerance to offer workarounds for FreeBSD shrinks from release to 
 release [2]. So these problems will increase :-(

Reading that email, it seems that they would prefer a function that exists and 
returns the wrong result to one that does not exist.  If this is really the 
attitude of the developers of R, then I shall make absolutely certain that I 
avoid using R for anything where I actually care about the results, and would 
strongly encourage everyone else to do the same.  

In general, (sane) people use the long double versions because they need the 
extra precision and care about the result.  We could easily implement the long 
double versions now as toy versions that just called the double versions, but 
that would upset a lot of people who actually care about accuracy, who are the 
main target audience for these functions.  

David___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread Rainer Hurling


On 28.05.2012 14:49 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 13:30, Rainer Hurling wrote:


On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 05:35, Rainer Hurling wrote:


Ok, that's what I had supposed. Because the main difference between r236147 and 
r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of 
binning?


Yes, it's just about making libc++'s cmath header compile, nothing more.


I see, thanks.


Yes, I agree. These outstanding long double math functions (like log1pl) and 
better unicode support are really needed for some important third party 
projects like R or SAGA GIS.


I very much doubt that anything is using the C11 unicode stuff yet, since no 
compiler or libc currently supports it...


Of course you are right with C11 unicode stuff.

I thougt more about my actual problems to get the right charset 
conversions between different apps, i.e. qgis - wxgtk29 - saga gis. 
Or using Gnome apps (utf8) on windowmaker using ISO8859-15. But this is 
OT here, sorry.



In the past I have read several times discussions about the correctness of long 
double functions on FreeBSD. Some drafts have been dismissed because of there 
inaccuracy in special cases. Also was discussed to get missing libm routines 
from NetBSD [1]. It appears as if we have to wait some more time ...


I thought we did pull in some NetBSD libm stuff recently.  Not sure what the 
status of that is, you'd need to check with das@.


I am not aware of it and will have a look. But this did not implement 
the missing long double functions.



Yes, I think in most cases math/R is tolerant enough of just using doubles. But 
in the near future they plan to implement much more of the C99 stuff and their 
tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. 
So these problems will increase :-(


Reading that email, it seems that they would prefer a function that exists and 
returns the wrong result to one that does not exist.  If this is really the 
attitude of the developers of R, then I shall make absolutely certain that I 
avoid using R for anything where I actually care about the results, and would 
strongly encourage everyone else to do the same.


This was a statement of just one (though not unimportant) person from 
the R Core team. I don't think that this is the only view of R Core 
developers. On the other hand he is the person, who actually did most of 
the stuff within R for years now to circumvent the problems running on 
FreeBSD.



In general, (sane) people use the long double versions because they need the 
extra precision and care about the result.  We could easily implement the long 
double versions now as toy versions that just called the double versions, but 
that would upset a lot of people who actually care about accuracy, who are the 
main target audience for these functions.


It seems to be a general trend (outside of FreeBSD) to implement more 
and more stuff at the cost of quality. I am certain that for many 
FreeBSD users accuracy is more important than completeness, especially 
for scientists.


Nevertheless this policy brings some problems in the real world ;-)

Thanks again for your thoughts,
Rainer


David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

One thing that could be done is to have a math/cephes port that adds 
the extra C99 math functions.  This is already done in the math/sage 
port, using a rather clever patch due to Peter Jeremy, that applies to 
the cephes code.


What it would do is to create a /usr/local/lib/libm.so that would 
provide the extra functions not currently included in /lib/libm.so, and 
then link in /lib/libm.so as well.  It would also create its own 
/usr/local/include/math.h and /usr/local/include/complex.h as well.


What do you guys think?  Do you want someone to start experimenting with 
this idea?  I could do it, but probably not for a little while.


Stephen

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
 One thing that could be done is to have a math/cephes port that adds 
 the extra C99 math functions.  This is already done in the math/sage 
 port, using a rather clever patch due to Peter Jeremy, that applies to 
 the cephes code.
 
 What it would do is to create a /usr/local/lib/libm.so that would 
 provide the extra functions not currently included in /lib/libm.so, and 
 then link in /lib/libm.so as well.  It would also create its own 
 /usr/local/include/math.h and /usr/local/include/complex.h as well.
 
 What do you guys think?  Do you want someone to start experimenting with 
 this idea?  I could do it, but probably not for a little while.
 

This is a horrible, horrible, horrible idea.  Have you
looked at the cephes code, particularly the complex.h
functions?

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148


On 05/28/2012 03:31 PM, Steve Kargl wrote:

On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:

One thing that could be done is to have a math/cephes port that adds
the extra C99 math functions.  This is already done in the math/sage
port, using a rather clever patch due to Peter Jeremy, that applies to
the cephes code.

What it would do is to create a /usr/local/lib/libm.so that would
provide the extra functions not currently included in /lib/libm.so, and
then link in /lib/libm.so as well.  It would also create its own
/usr/local/include/math.h and /usr/local/include/complex.h as well.

What do you guys think?  Do you want someone to start experimenting with
this idea?  I could do it, but probably not for a little while.



This is a horrible, horrible, horrible idea.  Have you
looked at the cephes code, particularly the complex.h
functions?


I have only taken a very cursory look.  What should I specifically look 
for in seeing that the code is bad?


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread Peter Jeremy

On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith step...@missouri.edu 
wrote:
One thing that could be done is to have a math/cephes port that adds 
the extra C99 math functions.  This is already done in the math/sage 
port, using a rather clever patch due to Peter Jeremy, that applies to 
the cephes code.

What it would do is to create a /usr/local/lib/libm.so that would 
provide the extra functions not currently included in /lib/libm.so, and 
then link in /lib/libm.so as well.  It would also create its own 
/usr/local/include/math.h and /usr/local/include/complex.h as well.

Basically, as long as the compiler searches /usr/local/{include,lib}
before the base include/lib then math.h, complex.h and -lm give
the application a complete C99 math implementation by using base
functions where they exist and cephes functions where they don't.

The patch I wrote for sage can be found at
http://trac.sagemath.org/sage_trac/ticket/9543
If there's any interest, I could produce a port for this.

Another option would be to import cephes into base and use it to
provide the missing C99 functions.  Cephes includes copyright notices
but the closest I can find to a license is:
   Some software in this archive may be from the book _Methods and
 Programs for Mathematical Functions_ (Prentice-Hall or Simon  Schuster
 International, 1989) or from the Cephes Mathematical Library, a
 commercial product. In either event, it is copyrighted by the author.
 What you see here may be used freely but it comes with no support or
 guarantee.

-- 
Peter Jeremy


pgpYmCz2gMd3i.pgp
Description: PGP signature

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread Peter Jeremy

On 2012-May-28 13:31:59 -0700, Steve Kargl s...@troutmask.apl.washington.edu 
wrote:
On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
 One thing that could be done is to have a math/cephes port that adds 
 the extra C99 math functions.  This is already done in the math/sage 
 port, using a rather clever patch due to Peter Jeremy, that applies to 
 the cephes code.
...
This is a horrible, horrible, horrible idea.  Have you
looked at the cephes code, particularly the complex.h
functions?

The cephes code is somewhat a mess layout-wise.  Algorithmetically,
it seems somewhat variable - some functions are implemented (hopefully
correctly) using semi-numerical techniques, whereas others just use
mathematical identities which will result in precision loss - though
most of the functions include accuracy information.

I agree it would be far preferable to have a properly validated C99
libm with all functions having maximum errors of a no more than a few
LSB over their complete domain, as well as correct support for signed
zeroes, infinities and signalling and non-signalling NaNs but that is
a non-trivial undertaking.

In the interim, how should FreeBSD handle apps that want a C99 libm?
1) Fail to build them
2) Provide possibly imperfect fallbacks for the unimplemented bits.

If someone (I don't have the expertise) wants to identify the cephes
functions that are sub-standard, we can include link-time warnings
(as done for eg gets(3)) when they are used.

-- 
Peter Jeremy


pgpcG5SKNkFm9.pgp
Description: PGP signature

Re: Use of C99 extra long double math functions after r236148

On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:
 On 05/28/2012 03:31 PM, Steve Kargl wrote:
 On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
 One thing that could be done is to have a math/cephes port that adds
 the extra C99 math functions.  This is already done in the math/sage
 port, using a rather clever patch due to Peter Jeremy, that applies to
 the cephes code.
 
 What it would do is to create a /usr/local/lib/libm.so that would
 provide the extra functions not currently included in /lib/libm.so, and
 then link in /lib/libm.so as well.  It would also create its own
 /usr/local/include/math.h and /usr/local/include/complex.h as well.
 
 What do you guys think?  Do you want someone to start experimenting with
 this idea?  I could do it, but probably not for a little while.
 
 
 This is a horrible, horrible, horrible idea.  Have you
 looked at the cephes code, particularly the complex.h
 functions?
 
 I have only taken a very cursory look.  What should I specifically look 
 for in seeing that the code is bad?

Well, to start with, the extra C99 math functions that
are missing in libm include a few for the long double type
and many (if not most) of the complex functions for any
type.  Cephes at best will give you float, double, and ld80, but
not ld128 versions of the functions.  Then, there is fun little fact
that neither (base) gcc nor clang nor gcc less than 4.6 does
complex arithematic correctly; so, one needs to jump through
hoops to get the correct answer (See Annex G in n1256.pdf).
One item of particular importance in Annex G is the behavior
of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
NaN.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

On Tue, May 29, 2012 at 08:04:36AM +1000, Peter Jeremy wrote:
 On 2012-May-28 13:31:59 -0700, Steve Kargl 
 s...@troutmask.apl.washington.edu wrote:
 On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
  One thing that could be done is to have a math/cephes port that adds 
  the extra C99 math functions.  This is already done in the math/sage 
  port, using a rather clever patch due to Peter Jeremy, that applies to 
  the cephes code.
 ...
 This is a horrible, horrible, horrible idea.  Have you
 looked at the cephes code, particularly the complex.h
 functions?
 
 The cephes code is somewhat a mess layout-wise.  Algorithmetically,
 it seems somewhat variable - some functions are implemented (hopefully
 correctly) using semi-numerical techniques, whereas others just use
 mathematical identities which will result in precision loss - though
 most of the functions include accuracy information.
 
 I agree it would be far preferable to have a properly validated C99
 libm with all functions having maximum errors of a no more than a few
 LSB over their complete domain, as well as correct support for signed
 zeroes, infinities and signalling and non-signalling NaNs but that is
 a non-trivial undertaking.
 
 In the interim, how should FreeBSD handle apps that want a C99 libm?
 1) Fail to build them
 2) Provide possibly imperfect fallbacks for the unimplemented bits.
 
 If someone (I don't have the expertise) wants to identify the cephes
 functions that are sub-standard, we can include link-time warnings
 (as done for eg gets(3)) when they are used.

Given that cephes was written years before C99 was even
conceived, I suspect all functions are sub-standard.  For
example, AFAIK, none of the long double functions are
appropriate for any platform that has an 128-bit long double;
as cephes was written for an Intel 80-bit format.

If portmgr or a port maintainer wants to use a library with
untested implementations of missing libm functions, please do
not put it into /usr/local/lib and call it libm.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

On Tue, May 29, 2012 at 07:05:07AM +1000, Peter Jeremy wrote:
 On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith 
 step...@missouri.edu wrote:
 One thing that could be done is to have a math/cephes port that adds 
 the extra C99 math functions.  This is already done in the math/sage 
 port, using a rather clever patch due to Peter Jeremy, that applies to 
 the cephes code.
 
 What it would do is to create a /usr/local/lib/libm.so that would 
 provide the extra functions not currently included in /lib/libm.so, and 
 then link in /lib/libm.so as well.  It would also create its own 
 /usr/local/include/math.h and /usr/local/include/complex.h as well.
 
 Basically, as long as the compiler searches /usr/local/{include,lib}
 before the base include/lib then math.h, complex.h and -lm give
 the application a complete C99 math implementation by using base
 functions where they exist and cephes functions where they don't.
 
 The patch I wrote for sage can be found at
 http://trac.sagemath.org/sage_trac/ticket/9543
 If there's any interest, I could produce a port for this.
 
 Another option would be to import cephes into base and use it to
 provide the missing C99 functions.  Cephes includes copyright notices
 but the closest I can find to a license is:
Some software in this archive may be from the book _Methods and
  Programs for Mathematical Functions_ (Prentice-Hall or Simon  Schuster
  International, 1989) or from the Cephes Mathematical Library, a
  commercial product. In either event, it is copyrighted by the author.
  What you see here may be used freely but it comes with no support or
  guarantee.

Please talk to das@ (although I believe he's finishing up his
dissertation).  I recall that he's stated that he looked into
using cephes, and concluded that it is not suitable for libm.

Note there is also

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599

which I've also objected to importing into libm.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148


On 05/28/2012 05:17 PM, Steve Kargl wrote:

On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:

On 05/28/2012 03:31 PM, Steve Kargl wrote:

On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:

One thing that could be done is to have a math/cephes port that adds
the extra C99 math functions.  This is already done in the math/sage
port, using a rather clever patch due to Peter Jeremy, that applies to
the cephes code.

What it would do is to create a /usr/local/lib/libm.so that would
provide the extra functions not currently included in /lib/libm.so, and
then link in /lib/libm.so as well.  It would also create its own
/usr/local/include/math.h and /usr/local/include/complex.h as well.

What do you guys think?  Do you want someone to start experimenting with
this idea?  I could do it, but probably not for a little while.



This is a horrible, horrible, horrible idea.  Have you
looked at the cephes code, particularly the complex.h
functions?


I have only taken a very cursory look.  What should I specifically look
for in seeing that the code is bad?


Well, to start with, the extra C99 math functions that
are missing in libm include a few for the long double type
and many (if not most) of the complex functions for any
type.  Cephes at best will give you float, double, and ld80, but
not ld128 versions of the functions.  Then, there is fun little fact
that neither (base) gcc nor clang nor gcc less than 4.6 does
complex arithematic correctly; so, one needs to jump through
hoops to get the correct answer (See Annex G in n1256.pdf).
One item of particular importance in Annex G is the behavior
of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
NaN.



IMHO these problems are definitely not bad enough to avoid making a 
math/cephes port.  I for one would definitely like to have some kind of 
implementation of ccosh, even if it gets a few things wrong when it is 
fed Nan or I*Inf or such like as its input.  I mean, if clang or gcc46 
doesn't even get this right, how can we expect better from libm?


Also, a really nice thing about Jeremy's patch is that it automatically 
detects which functions are already included in the base libm, and only 
adds functions not already in libm.


And ld80 is better than nothing if ld128 isn't available.

I would avoid cephes only if it got some of the answers horribly wrong 
(as in erf(100) being something like -14232 as the openoffice 
implementation of the erf function used to report).


I say, lets go ahead and add a math/cephes port.

By the way, do you have an opinion on the complex functions used in 
Linux?  (I tried reading the glibc code, but I could only find chains of 
macros and functions calling each other, and I could never find where 
the actual work was performed.)


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

On Mon, May 28, 2012 at 06:03:37PM -0500, Stephen Montgomery-Smith wrote:
 On 05/28/2012 05:17 PM, Steve Kargl wrote:
 On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:
 On 05/28/2012 03:31 PM, Steve Kargl wrote:
 On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
 One thing that could be done is to have a math/cephes port that adds
 the extra C99 math functions.  This is already done in the math/sage
 port, using a rather clever patch due to Peter Jeremy, that applies to
 the cephes code.
 
 What it would do is to create a /usr/local/lib/libm.so that would
 provide the extra functions not currently included in /lib/libm.so, and
 then link in /lib/libm.so as well.  It would also create its own
 /usr/local/include/math.h and /usr/local/include/complex.h as well.
 
 What do you guys think?  Do you want someone to start experimenting with
 this idea?  I could do it, but probably not for a little while.
 
 
 This is a horrible, horrible, horrible idea.  Have you
 looked at the cephes code, particularly the complex.h
 functions?
 
 I have only taken a very cursory look.  What should I specifically look
 for in seeing that the code is bad?
 
 Well, to start with, the extra C99 math functions that
 are missing in libm include a few for the long double type
 and many (if not most) of the complex functions for any
 type.  Cephes at best will give you float, double, and ld80, but
 not ld128 versions of the functions.  Then, there is fun little fact
 that neither (base) gcc nor clang nor gcc less than 4.6 does
 complex arithematic correctly; so, one needs to jump through
 hoops to get the correct answer (See Annex G in n1256.pdf).
 One item of particular importance in Annex G is the behavior
 of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
 NaN.
 
 
 IMHO these problems are definitely not bad enough to avoid making a 
 math/cephes port.  I for one would definitely like to have some kind of 
 implementation of ccosh, even if it gets a few things wrong when it is 
 fed Nan or I*Inf or such like as its input.  I mean, if clang or gcc46 
 doesn't even get this right, how can we expect better from libm?

Search the llvm and gcc bug databases, I'm the person that informed
both that they can't deal with complex arithematic correctly.

Interesting that you mention ccosh.

From clog.c in http://www.netlib.org/cephes/cmath.tgz

void
ccosh (z, w)
 cmplx *z, *w;
{
  double x, y;
  x = z-r;
  y = z-i;
  w-r = cosh (x) * cos (y);
  w-i = sinh (x) * sin (y);
}

From clog.c in http://www.netlib.org/cephes/c9x-complex

double complex
ccosh (z)
 double complex z;
{
  double complex w;
  double x, y;

  x = creal(z);
  y = cimag(z);
  w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
  return (w);
}

See math_private.h about the above. 

And, finally,

:
/*-
 * Copyright (c) 2005 Bruce D. Evans and Steven G. Kargl
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice unmodified, this list of conditions, and the following
 *disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
 * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/*
 * Hyperbolic cosine of a complex argument z = x + i y.
 *
 * cosh(z) = cosh(x+iy)
 * = cosh(x) cos(y) + i sinh(x) sin(y).
 *
 * Exceptional values are noted in the comments within the source code.
 * These values and the return value were taken from n1124.pdf.
 */

#include sys/cdefs.h
__FBSDID($FreeBSD: head/lib/msun/src/s_ccosh.c 226599 2011-10-21 06:29:32Z das 
$);

#include complex.h
#include math.h

#include math_private.h

static const double huge = 0x1p1023;

double complex
ccosh(double complex z)
{
double x, y, h;
int32_t hx, hy, ix, iy, lx, ly;

x = creal(z);
y = cimag(z);

EXTRACT_WORDS(hx, lx, x);
EXTRACT_WORDS(hy, ly, y);

ix = 0x7fff  hx;
iy = 0x7fff  hy;

/* Handle the

Re: Use of C99 extra long double math functions after r236148


On 05/28/2012 06:30 PM, Steve Kargl wrote:




From clog.c in http://www.netlib.org/cephes/c9x-complex


double complex
ccosh (z)
  double complex z;
{
   double complex w;
   double x, y;

   x = creal(z);
   y = cimag(z);
   w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
   return (w);
}

See math_private.h about the above.



I looked in math_private.h - I presume you meant 
lib/msun/src/math_private.h.  I wasn't able to find anything about ccosh 
there.


I think that for a rough and ready ccosh, this is high enough quality 
for a math/cephes port.


I do agree that it might not be high enough quality to make FreeBSD base.

(Although I don't think I have ever been in a situation where I would 
have been tripped up by a transcendental function that responded 
incorrectly to exceptional input.)





And, finally,


Yes, it is very nice.



Who's writing the code to test the implementations?  That is
better much the problem.  Without testing, one might get an
implementation that appears to work until it doesn't!  It took
me 3+ years to get sqrtl() into libm, but bde and das (and
myself) wanted to make sure the code worked.


Fair enough if we are talking about the base system.


I haven't looked at glibc code in years, because I hack on libm
when I can.  I do not want to run into questions about whether
my code is tainted by the gpl.



They had similar lists of exceptions.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148