- mathfun@mailman.xmission.com - mailman.xmission.com

Re: [math-fun] about a certain François Mendzina Essomba and surprising pi formulas
by Dan Asimov 27 Mar '17

27 Mar '17

Unfortunately, you have to be logged on to Facebook to see those formulas, but I am not a member (and don't want to be one). Can the formulas be copied and reposted to an open-access web page? —Dan >From: Simon Plouffe <simon.plouffe(a)gmail.com> >Hello funsters and for some Pi fans, > > I was contacted by a certain François Mendzina Essomba from >Cameroun. > > He showed to me some formulas for pi, the first one was kind of >surprising, >then he sent me a couple of others , > > They are surprising, at first sight : it resembles the ones about the >AGM, >but I am not certain, > > you may judge by yourself here, : > > https://www.facebook.com/photo.php?fbid=1261279953954407&set=gm.13739836826… >https://www.facebook.com/photo.php?fbid=1261281097287626&set=pcb.1373984792… > >and here is the facebook page : > >https://www.facebook.com/search/top/?q=Fran%C3%A7ois%20Mendzina%20Essomba > > > Does anyhone has ever see any of this ? not me.

3 3

[math-fun] posits, IEEE floats, asinh numbers
by Henry Baker 27 Mar '17

27 Mar '17

Over the years, I've bored you all to tears talking about asinh numbers. Basically, asinh numbers represent a real number x as the integer: round(alpha*asinh(beta*x)) For example, if alpha=1/asinh(beta), then the asinh # for 1 is also 1. Since asinh(x) is an odd function, we get smooth transitions about 0. This means we can capture a brief segment of the integers within this representation, while also getting a logarithmic representation of numbers with very large absolute values. In particular, if beta ~ 2^(-22) and we have a 32-bit asinh # representation, then all of the signed 16-bit integers are mapped 1-1, but the overall range is ~ +-10^228. If beta ~ 2^(-46) and we have a 64-bit asinh # representation, then all of the signed 32-bit integers are mapped 1-1, but the overall range is ~ +-10^56937. asinh numbers are thus the *smooth* integration of Kahan IEEE "denormalized" floats with normalized floats. asinh numbers don't have a separate exponent and mantissa, and therefore don't require a "regime" number to specify the size of the exponent. Of course, we can adjust alpha & beta so that asinh #'s have the same denorm range as IEEE denorms. I claim that asinh numbers provide a much smoother (and therefore more accurate) set of numbers than Gustafson's "posits". If I have any time, I'll try to re-do some of Gustafson's calculations with asinh numbers.

5 11

Re: [math-fun] Beyond Floats: Next Gen Computer Arithmetic
by Henry Baker 26 Mar '17

26 Mar '17

If I understood Gustafson's talk correctly, IEEE doubles aren't good enough. He showed some examples where IEEE quads (128 bits) weren't good enough. Is there any way you could convert to Maxima bigfloats, do the operation, and convert back? Bigfloats can be set to any precision you want. Alternatively, could you convert to rationals, do the operation, and convert back? (This should be relatively easy -- if slow -- in most Common Lisp implementations.) I'm not interested in speed, but in precision of the *representation*, as divorced from the precision of the operation itself. I'll talk about this again in another post about "asinh numbers", which Yonemoto (Gustafson's programmer) dismissed out of hand to me as requiring table lookup. At 11:03 PM 3/25/2017, you wrote: >For every operation, my implementation converts posits to IEEE doubles, >performs the operation, and converts the result back to a posit by figuring >out the number of fraction bits based on the exponent, and rounding the >scaled fraction to an integer.

3 6

Re: [math-fun] posits, IEEE floats, asinh numbers
by Bill Gosper 26 Mar '17

26 Mar '17

I think the early largest Mersenne primes were found using a bignum package built on floating point. (E.g. Brillhart's 11213(?)). -------- Original Message -------- Date: 2017-03-26 18:07 From: Henry Baker <hbaker1(a)pipeline.com> To: math-fun <math-fun(a)mailman.xmission.com> Reply-To: math-fun <math-fun(a)mailman.xmission.com> At 01:02 PM 3/26/2017, Gareth McCaughan wrote: This has the drawback that essentially no integers other than >0 and +-1 are *exactly* represented, unless I'm missing something. >I'm not sure how much that matters, but it would be quite a >departure from conventional floating-point representations. I'm not so sure that anyone cares about this anymore. I may have been one of the few people trying to do integer calculations using a floating point unit: January 1992 http://home.pipeline.com/~hbaker1/AB-mod-N.html http://home.pipeline.com/~hbaker1/AB-mod-N.pdf "We show how to compute A*B (mod N) efficiently, for single-precision A,B, and N, on a modern RISC architecture (Intel 80860) in ANSI C. On this architecture, our method computes A*B (mod N) faster than ANSI C computes A%N, for unsigned longs A and N."

2 1

[math-fun] Merely algebraic FullSimplify challenge
by Bill Gosper 26 Mar '17

26 Mar '17

In[50]:= Assuming[Re@z > Sqrt[1/4 + (Im@z)^2/3], FullSimplify[1/2 ((-3 z + 4 z^3 - Sqrt[-1 + (3 z - 4 z^3)^2])^( 1/3) + (-3 z + 4 z^3 + Sqrt[-1 + (3 z - 4 z^3)^2])^(1/3))]] Out[50]= 1/2 ((-3 z + 4 z^3 - Sqrt[-1 + (3 z - 4 z^3)^2])^( 1/3) + (-3 z + 4 z^3 + Sqrt[-1 + (3 z - 4 z^3)^2])^(1/3)) "Should" be z. Some evidence: In[51]:= FullSimplify[%/.z->1/2] Out[51]= (-1)^(1/3) (*Isolated discontinuity*) In[52]:= FullSimplify[%50/.z->11/21] Out[52]= 11/21 In[53]:= FullSimplify[%50/.z->10001/20001] Out[53]= 10001/20001 In[71]:= Series[%50,{z,1/2,9}]//FullSimplify Out[71]= 1/2+(z-1/2)+O[z-1/2]^10 Not f(1/2) + ... ! In[74]:= Series[%50,{z,1,9}]//FullSimplify Out[74]= 1+(z-1)+O[z-1]^(19/2) In[75]:= Series[%50,{z,3/2,9}]//FullSimplify Out[75]= 3/2+(z-3/2)+O[z-3/2]^10 In[76]:= Series[%50,{z,1+I,9}]//FullSimplify Out[76]= (1+I)+(z-(1+I))+O[z-(1+I)]^10. --Bill Gosper

1 0

Re: [math-fun] Brutal FullSimplify challenge II
by Bill Gosper 26 Mar '17

26 Mar '17

Yes, the Computer Algebra viewpoint is that multivalued functions are a thought crime, and we must all agree where the branch cuts are in all the named functions. This just gave me an isolated point singularity in a merely algebraic function that I almost reported as a bug: Evidently, -2 z + (-3 z + 4 z^3 + (1 - 4 z^2) Sqrt[-1 + z^2])^( 1/3) + (-3 z + 4 z^3 + Sqrt[-1 + z^2] (-1 + 4 z^2))^(1/3) is 0 within the semihyperbola Re@z > Sqrt[1/4 + (Im@z)^2/3], discontinuous on the boundary, and smooth elsewhere. But boundary pt z=1/2 is discontinuous with both regions. Almost impossible to find with Plot... --rwg -------- Original Message -------- Date: 2017-03-26 08:43 From: "David Wilson" <davidwwilson(a)comcast.net> To: "'math-fun'" <math-fun(a)mailman.xmission.com> Reply-To: math-fun <math-fun(a)mailman.xmission.com> Apologies if I am seem pedantic I programmed this in C++, and got essentially the same values for c(c(x)) plotted by rwg. For any x < 2, the evaluation of c(c(x)) ultimately ends up computing a^√2 for complex a. Unfortunate, for complex a, a^√2 = exp(√2 (log(a) + 2πi k)) has an infinitude of values (for integer k). For C++, and presumably Mma, log(a) returns the principle value with -π < Im(log(a)) <= π. This happily coincides with real log(a) for positive real a. Regarding the c(c(x)) calculation: If x >= 2, we can restrict calculations to the real realm, take the principle (real) value of a^√2, and end up with c(c(x)) = x^2 -2. If x < 2, however, a^√2 must be evaluated for non-positive-real x, and it is not clear that the principle value is appropriate in any particular calculation. I submit that, when c(c(x)) differs from x^2 - 2, we might restore c(c(x)) = x^2 -2 by using the appropriate (non-principle) value of a^√2 in the appropriate calculations, though it is unclear which value of a^√2 (if any) works for any particular evaluation of c(x). > -----Original Message----- > From: math-fun [mailto:math-fun-bounces@mailman.xmission.com] On > Behalf Of Bill Gosper > Sent: Saturday, March 25, 2017 11:35 PM > To: Wolfram Technical Support > Cc: math-fun(a)mailman.xmission.com > Subject: [math-fun] Brutal FullSimplify challenge II > > In[540]:= $Version > > Out[540]= "11.0.1 for Mac OS X x86 (64-bit) (September 21, 2016)" > > cc[x_] := Nest[((# + √(#^2 - 4))/2)^√2 + ((# - √(#^2 - 4))/2)^√2 &, x, 2] > > In[653]:=FullSimplify@cc@-Sqrt[2 (1 - Sin[√2 π])] == 2 Sin[√2 π] > > Out[653]= > 2^(-1 - Sqrt[ > 2]) (((-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] - > I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^Sqrt[ > 2] + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] + > I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^Sqrt[ > 2] - \[Sqrt](-2^( > 1 + Sqrt[2]) + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] - > I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^( > 2 Sqrt[2]) + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] + > I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^(2 Sqrt[2])))^Sqrt[ > 2] + ((-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] - > I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^Sqrt[ > 2] + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] + > I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^Sqrt[ > 2] + \[Sqrt](-2^( > 1 + Sqrt[2]) + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] - > I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^( > 2 Sqrt[2]) + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] + > I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^(2 Sqrt[2])))^Sqrt[2]) == > 2 Sin[Sqrt[2] \[Pi]] > > In[654]:= Chop@N@# & /@ % > > Out[654]= True > --Bill Gosper

1 0

Re: [math-fun] posits, IEEE floats, asinh numbers
by Henry Baker 26 Mar '17

26 Mar '17

asinh(x) ~ x for |x|<C, C some a priori constant. You can't get much nicer than linear (in this case, the identity function). %i25) taylor(asinh(x),x,0,9); 3 5 7 9 x 3 x 5 x 35 x (%o25)/T/ x - -- + ---- - ---- + ----- + . . . 6 40 112 1152 Thus, for alpha=1/asinh(beta) and beta ~ 2^(-46), round(alpha*asinh(beta*x)) = x for integer |x|<2^32. At 11:45 AM 3/26/2017, Warren D Smith wrote: >Another problem: >While asinh(x) is nice for large x, it is not so nice for very tiny x. >I think that should cause a very bad precision loss in many real computations.

1 0

[math-fun] about a certain François Mendzina Essomba and surprising pi formulas
by Simon Plouffe 26 Mar '17

26 Mar '17

Hello funsters and for some Pi fans, I was contacted by a certain François Mendzina Essomba from Cameroun. He showed to me some formulas for pi, the first one was kind of surprising, then he sent me a couple of others , They are surprising, at first sight : it resembles the ones about the AGM, but I am not certain, you may judge by yourself here, : https://www.facebook.com/photo.php?fbid=1261279953954407&set=gm.13739836826… https://www.facebook.com/photo.php?fbid=1261281097287626&set=pcb.1373984792… and here is the facebook page : https://www.facebook.com/search/top/?q=Fran%C3%A7ois%20Mendzina%20Essomba Does anyhone has ever see any of this ? not me. Best regards, Simon Plouffe

2 1

[math-fun] Brutal FullSimplify challenge II
by Bill Gosper 26 Mar '17

26 Mar '17

In[540]:= $Version Out[540]= "11.0.1 for Mac OS X x86 (64-bit) (September 21, 2016)" cc[x_] := Nest[((# + √(#^2 - 4))/2)^√2 + ((# - √(#^2 - 4))/2)^√2 &, x, 2] In[653]:=FullSimplify@cc@-Sqrt[2 (1 - Sin[√2 π])] == 2 Sin[√2 π] Out[653]= 2^(-1 - Sqrt[ 2]) (((-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] - I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^Sqrt[ 2] + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] + I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^Sqrt[ 2] - \[Sqrt](-2^( 1 + Sqrt[2]) + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] - I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^( 2 Sqrt[2]) + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] + I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^(2 Sqrt[2])))^Sqrt[ 2] + ((-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] - I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^Sqrt[ 2] + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] + I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^Sqrt[ 2] + \[Sqrt](-2^( 1 + Sqrt[2]) + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] - I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^( 2 Sqrt[2]) + (-Sqrt[1 - Sin[Sqrt[2] \[Pi]]] + I Sqrt[1 + Sin[Sqrt[2] \[Pi]]])^(2 Sqrt[2])))^Sqrt[2]) == 2 Sin[Sqrt[2] \[Pi]] In[654]:= Chop@N@# & /@ % Out[654]= True --Bill Gosper

2 2

Re: [math-fun] Beyond Floats: Next Gen Computer Arithmetic
by Leo Broukhis 26 Mar '17

26 Mar '17

On Sat, 25 Mar 2017 09:50:46 -0400, "J.P. Grossman" <jpg(a)alum.mit.edu> wrote: > Could you expand on what "flaws, defects, and failures" you found? Also, > did you use es = 1 or es = 3? > > I can vary size and es arbitrarily. For every operation, my implementation converts posits to IEEE doubles, performs the operation, and converts the result back to a posit by figuring out the number of fraction bits based on the exponent, and rounding the scaled fraction to an integer. For very large numbers, when the number of fraction bits is 0, and the exponent may have to be rounded as well, the results may be wrong. I'll have to look further for that; but I doubt if it would have made any difference for this test. (In the following, I'm quoting tersely, as I'm retyping from my work laptop which is a walled garden, but I've verified the signs of all numbers and exponents). For Posit<32,3>: 27 significant digits found Addition/Subtraction neither rounds nor chops. Sticky bit used incorrectly or not at all. FLAW: lack(s) of guard digits or failure(s) to correctly round or chop. Square root is neither chopped nor correctly rounded. Observed errors run from -5.0e-01 to 8.5e+00 ulps. SERIOUS DEFECT: sqrt gets too many last digits wrong. FAILURE: multiplication gets too many last digits wrong. FLAW: Underflow can stick at an allegedly positive value PseudZero that prints out as 2.37389e-66 [according to Gistafson, the above is not a flaw, we'll discount that - LB] Since comparison denies Z = 0, evaluating (Z+Z)/Z should be safe. What the machine gets for (Z+Z)/Z is 1.0e+00 This is a DEFECT. FAILURE: Comparisons involving +--5.26561e+64, +-1.05312e+65 and +-9.49557e-66 are confused by Overflow. SERIOUS DEFECT: Comparison alleges that Z = -5.265615e+64 is too far from sqrt(Z) ^ 2 (2.49999985098838806e-01). [the above I don't understand; the sign seems to be wrong] DEFECT: Badly unbalanced range; UfThold * V = -5.0e-01 is too far from 1. Using Posit<32,1> adds one defect and one serious defect: SERIOUS DEFECT: Range is too narrow, U1^4 Underflows. [U1 is min x : 1-x not equal to 1] DEFECT: computing 5.0e+00 ^ 1.1e+01 yielded 4.8827904e+07 which compared unequal to correct 4.8828416e+07; they differ by -5.12e+02 Indeed, the precision loss with increasing exponent is too sharp in Posit<32,1>. Leo

1 0