simplification sought
Peter
"An exact simplification challenge". Maybe he is lost in transition...
I tried Maple (VR5) but Maple failed. I tried Wolfram Alpha and
it computed happily ever after until timeout.
Anyway, here is my problem in Maple parlance.
h := s -> (2*Pi)^s*(1/2*s*Zeta(0,1-s,1)-4^(s-1)*Zeta(0,1-s,1/4)
+4^(s-1)*Zeta(0,1-s,3/4))/((cos(1/2*s*Pi)*s*Zeta(s)-sin(1/2*s*Pi)
*Zeta(0,s,1/4)+sin(1/2*s*Pi)*Zeta(0,s,3/4)));
Like Vladimir I prefer a symbolic answer which shows the processing.
Cheers Peter
Nasser M. Abbasi
"Peter" <peter....@googlemail.com> wrote in message
news:6dd89ee9-0bc4-4492...@c34g2000yqn.googlegroups.com...
I tried it on Maple 12 and Mathematica 7, but no simplification on the
zeta's. I assume by what you say then that there exist some relations
relating to the zeta functions that should have been used to reduce this
more.
For what its worth, Here is the maple and mathematica outputs:
http://12000.org/tmp/zeta_simplification/zeta.png
ps. I did not think Walpha is supposed to have the full Mathematica in it so
I would be surprised if it can't do some things that Mathematica can
--Nasser
Peter
> > "Peter" <peter.lusc...@googlemail.com> wrote in message
Hi Nasser!
> > Anyway, here is my problem in Maple parlance.
> > h := s -> (2*Pi)^s*(1/2*s*Zeta(0,1-s,1)-4^(s-1)*Zeta(0,1-s,1/4)
> > +4^(s-1)*Zeta(0,1-s,3/4))/((cos(1/2*s*Pi)*s*Zeta(s)-sin(1/2*s*Pi)
> > *Zeta(0,s,1/4)+sin(1/2*s*Pi)*Zeta(0,s,3/4)));
> > Like Vladimir I prefer a symbolic answer which shows the processing.
> I tried it on Maple 12 and Mathematica 7, but no simplification on the
> zeta's.
Interesting indeed.
> I assume by what you say then that there exist some relations
> relating to the zeta functions that should have been used to reduce this
> more.
Yeah! Sure. By your negative results I am beginning to
speculate what the reasons are. But it is too early to
go into this. First I will wait for other comments.
> For what its worth, Here is the maple and mathematica outputs:
> http://12000.org/tmp/zeta_simplification/zeta.png
Thanks.
> ps. I did not think Walpha is supposed to have the full Mathematica in it so
> I would be surprised if it can't do some things that Mathematica can
Right. It' the poor man's version. I am a poor man.
Cheers Peter
acer
I don't have a set of symbolic simplification steps, but is it equal
to GAMMA(s)?
Nasser M. Abbasi
"acer" <ma...@rogers.com> wrote in message
news:6ed9dcd2-4559-40ec...@d21g2000yqn.googlegroups.com...
Mathematica 7 says no:
h = ((2*Pi)^s*((1/2)*s*Zeta[1 - s] -
4^(s - 1)*Zeta[1 - s, 1/4] +
4^(s - 1)*Zeta[1 - s, 3/4]))/
(s*Zeta[s]*Cos[(Pi*s)/2] -
Zeta[s, 1/4]*Sin[(Pi*s)/2] +
Zeta[s, 3/4]*Sin[(Pi*s)/2])
In[19]:= h === Gamma[s]
Out[19]= False
--Nasser
acer
I don't really see your reasoning. If FullSimplify cannot ascertain
the equivalence then why would SameQ be expected to be able to do so?
(SameQ is not a probabilistic verifier, is it?)
Anyway, on the verification front: one might consider trying the
simplification under the assumption that s is integer and s>1. I was
not able to succeed in that, but others might.
Nasser M. Abbasi
"acer" <ma...@rogers.com> wrote in message news:0527cb86-5279-4fb5-ac2e-
>>
>> > I don't have a set of symbolic simplification steps, but is it equal
>> > to GAMMA(s)?
>>
>> Mathematica 7 says no:
>>
>> h = ((2*Pi)^s*((1/2)*s*Zeta[1 - s] -
>> 4^(s - 1)*Zeta[1 - s, 1/4] +
>> 4^(s - 1)*Zeta[1 - s, 3/4]))/
>> (s*Zeta[s]*Cos[(Pi*s)/2] -
>> Zeta[s, 1/4]*Sin[(Pi*s)/2] +
>> Zeta[s, 3/4]*Sin[(Pi*s)/2])
>>
>> In[19]:= h === Gamma[s]
>>
>> Out[19]= False
>>
>> --Nasser
>
>
> I don't really see your reasoning. If FullSimplify cannot ascertain
> the equivalence then why would SameQ be expected to be able to do so?
> (SameQ is not a probabilistic verifier, is it?)
>
Code path might be different? If Simplify[h] did not come up to be Gamma,
this is becuase simplification might not have the rule to "see" that? But
if some explicitly say is h-Gamma zero, then this might "help" the system
go throught different code path and say yes.
I think the second test is more strong than the first one.
> Anyway, on the verification front: one might consider trying the
> simplification under the assumption that s is integer and s>1. I was
> not able to succeed in that, but others might.
In[24]:= h
Out[24]= ((2*Pi)^s*((1/2)*s*Zeta[1 - s] -
4^(-1 + s)*Zeta[1 - s, 1/4] +
4^(-1 + s)*Zeta[1 - s, 3/4]))/
(s*Cos[(Pi*s)/2]*Zeta[s] - Sin[(Pi*s)/2]*
Zeta[s, 1/4] + Sin[(Pi*s)/2]*Zeta[s, 3/4])
Assuming[Element[s, Integers] && s > 1, FullSimplify[h]]
Out[25]=
-((2^(-2 + s)*Pi^s*(2*(-1)^s*s*BernoulliB[s] + 4^s*(-BernoulliB[s, 1/4] +
BernoulliB[s,3/4])))/(s*(s*Cos[(Pi*s)/2]*Zeta[s] + Sin[(Pi*s)/2]*(-Zeta[s,
1/4] + Zeta[s, 3/4]))))
--Nasser
acer
> "acer" <ma...@rogers.com> wrote in message news:0527cb86-5279-4fb5-ac2e-
>
> >> > I don't have a set of symbolic simplification steps, but is it equal
> >> > to GAMMA(s)?
>
> >> Mathematica 7 says no:
>
> >> h = ((2*Pi)^s*((1/2)*s*Zeta[1 - s] -
> >> 4^(s - 1)*Zeta[1 - s, 1/4] +
> >> 4^(s - 1)*Zeta[1 - s, 3/4]))/
> >> (s*Zeta[s]*Cos[(Pi*s)/2] -
> >> Zeta[s, 1/4]*Sin[(Pi*s)/2] +
> >> Zeta[s, 3/4]*Sin[(Pi*s)/2])
>
> >> In[19]:= h === Gamma[s]
>
> >> Out[19]= False
>
> >> --Nasser
>
> > I don't really see your reasoning. If FullSimplify cannot ascertain
> > the equivalence then why would SameQ be expected to be able to do so?
> > (SameQ is not a probabilistic verifier, is it?)
>
> Code path might be different? If Simplify[h] did not come up to be Gamma,
> this is becuase simplification might not have the rule to "see" that? But
> if some explicitly say is h-Gamma zero, then this might "help" the system
> go throught different code path and say yes.
>
> I think the second test is more strong than the first one.
Well, I can imagine that FullSimplify[h-Gamma[z]] might get lucky,
perhaps by virtue of a different computation path (due to the presence
of the Gamma).
But for SameQ? If the kind of symbolic simplification (potentially
blowing off branch cuts?) that FullSimplify might do cannot get this,
then a strict test for identical equivalence doesn't have a better
chance, does it?
I don't know whether it's easily possible to restrict PossibleZeroQ to
some range and give it a good chance (on account of roundoff
difficulties).
> > Anyway, on the verification front: one might consider trying the
> > simplification under the assumption that s is integer and s>1. I was
> > not able to succeed in that, but others might.
>
> In[24]:= h
> Out[24]= ((2*Pi)^s*((1/2)*s*Zeta[1 - s] -
> 4^(-1 + s)*Zeta[1 - s, 1/4] +
> 4^(-1 + s)*Zeta[1 - s, 3/4]))/
> (s*Cos[(Pi*s)/2]*Zeta[s] - Sin[(Pi*s)/2]*
> Zeta[s, 1/4] + Sin[(Pi*s)/2]*Zeta[s, 3/4])
>
> Assuming[Element[s, Integers] && s > 1, FullSimplify[h]]
>
> Out[25]=
>
> -((2^(-2 + s)*Pi^s*(2*(-1)^s*s*BernoulliB[s] + 4^s*(-BernoulliB[s, 1/4] +
> BernoulliB[s,3/4])))/(s*(s*Cos[(Pi*s)/2]*Zeta[s] + Sin[(Pi*s)/2]*(-Zeta[s,
> 1/4] + Zeta[s, 3/4]))))
I got something similar with Maple 13.01. My attempts to reduce it
further didn't get far.
>
> --Nasser
Richard Fateman
the fact that h===Gamma[s] is not telling you anything useful.
Nasser M. Abbasi
"acer" <ma...@rogers.com> wrote in message news:94af66b3-0411-4ec9-bb6b-
>
> Well, I can imagine that FullSimplify[h-Gamma[z]] might get lucky,
> perhaps by virtue of a different computation path (due to the presence
> of the Gamma).
>
> But for SameQ?
I see now, yes ofcourse! I was thinking at looking if h-Gamma==0 but ended
up writing h===Gamma for some reason I do not understand now.
I Should have just looked at h-Gamma.
Nasser M. Abbasi
"Richard Fateman" <fat...@cs.berkeley.edu> wrote in message
news:4B2C5BF7...@cs.berkeley.edu...
> If you plot h-Gamma[s], you will see the result is 0, modulo roundoff.
>
This is interesting. I tried the above, one time looking at h[s]-Gamma[s]
with 16 precision and one much larger precision and the numerical result is
amazing. I looked at difference numerically between h[s] and Gamma[s] for s
from 2 to 28, one time doing N[h[s,16] - N[Gamma[s], 16] and another doing
just N[h[s]] - N[Gamma[s] (or some large precision, like 500)
When using N[16], I do get zero (almost).
But when doing large precision, like 500 the difference between h[s] and
Gamma[s] is no longer zero after around s=6 or 7, and it becomes HUGE very
quickly.
So, this seems to mean that h[s] and Gamma[s] are not equal for all s, but
only for small values of s ?
---- 16 precision result ------
In[1]:= h[s_] := ((2*Pi)^s*((1/2)*s*Zeta[1 - s] -
4^(s - 1)*Zeta[1 - s, 1/4] +
4^(s - 1)*Zeta[1 - s, 3/4]))/
(s*Zeta[s]*Cos[(Pi*s)/2] -
Zeta[s, 1/4]*Sin[(Pi*s)/2] +
Zeta[s, 3/4]*Sin[(Pi*s)/2]);
Table[{s, N[h[s], 16] - N[Gamma[s], 16]}, {s, 2, 28}]
{{2, 0``15.698970004336019},
{3, 0``15.397940008672037},
{4, 0``14.920818753952375},
{5, 0``14.318758762624412},
{6, 0``13.619788758288392},
{7, 0``12.841637507904752},
{8, 0``11.99653946789049},
{9, 0``11.093449480898549},
{10, 0``10.139206971459224},
{11, 0``9.139206971459227},
{12, 0``8.097814286301},
{13, 0``7.018633040253375},
{14, 0``5.904689687946537},
{15, 0``4.758561652268301},
{16, 0``3.582470393212618},
{17, 0``2.3783504105566933},
{18, 0``1.1479014891784203},
{19, 0``-0.1073710159248868},
{20, 0``-1.3861246168777157},
{21, 0``-2.687154612541697},
{22, 0``-4.009373907275616},
{23, 0``-5.3517965880978196},
{24, 0``-6.713524424115416},
{25, 0``-8.09373566582702},
{26, 0``-9.491675674499058},
{27, 0``-10.906649022469876},
{28, 0``-12.338012786628864}}
The above is just the plain text formated output of this on the screen shown
here
http://12000.org/tmp/zeta_simplification/N16.png so it is all zero for all
practical purposes.
------ Now do the same just with N[] -----
Table[{s, N[h[s]] - N[Gamma[s]]}, {s, 2, 28}]
{{2, -2.220446049250313*^-16},
{3, 1.9383161742325683*^-11},
{4, -1.7763568394002505*^-15},
{5, -2.2798776200261273*^-7},
{6, 0.025835037231445312},
{7, -0.0033319191857117403},
{8, -9450.},
{9, -131.00361010831693},
{10, 6.13122048*^8},
{11, -2.3784258902238677*^6},
{12, -1.0335232438645441*^15},
{13, -3.097092099180528*^11},
{14, 3.037450899510264*^20},
{15, -1.6228004709998772*^15},
{16, -1.9462218232831778*^26},
{17, 3.279979939345335*^19},
{18, 8.299142684634157*^31},
{19, 6.875359671760806*^23},
{20, 1.9270589789284797*^37},
{21, -5.9559129102509*^27},
{22, -9.57580315670214*^41},
{23, 1.2038656868753728*^32},
{24, -8.043296494871772*^47},
{25, 4.8667353421835787*^36},
{26, 3.1073876193727873*^53},
{27, -4.918553861335889*^40},
{28, -1.78150498721893*^59}}
The above screen output is here
http://12000.org/tmp/zeta_simplification/N.png
---- Now do the same with explicit precision of 500 ----
In[5]:= Block[{$MaxExtraPrecision = 500}, Table[{s, N[h[s]] -
N[Gamma[s]]}, {s, 2, 28}]]
Out[5]= {{2, -2.220446049250313*^-16},
{3, 1.9383161742325683*^-11},
{4, -1.7763568394002505*^-15},
{5, -2.2798776200261273*^-7},
{6, 0.025835037231445312},
{7, -0.0033319191857117403}, {8, -9450.},
{9, -131.00361010831693},
{10, 6.13122048*^8},
{11, -2.3784258902238677*^6},
{12, -1.0335232438645441*^15},
{13, -3.097092099180528*^11},
{14, 3.037450899510264*^20},
{15, -1.6228004709998772*^15},
{16, -1.9462218232831778*^26},
{17, 3.279979939345335*^19},
{18, 8.299142684634157*^31},
{19, 6.875359671760806*^23},
{20, 1.9270589789284797*^37},
{21, -5.9559129102509*^27},
{22, -9.57580315670214*^41},
{23, 1.2038656868753728*^32},
{24, -8.043296494871772*^47},
{25, 4.8667353421835787*^36},
{26, 3.1073876193727873*^53},
{27, -4.918553861335889*^40},
{28, -1.78150498721893*^59}}
The above screen shot is here
http://12000.org/tmp/zeta_simplification/N.png
Which one is correct? Is this the effect of Mathematica interval arithmetic?
--Nasser
Nasser M. Abbasi
"Nasser M. Abbasi" <n...@12000.org> wrote in message
news:VSZWm.1847$yM1....@newsfe11.iad...
> The above screen shot is here
> http://12000.org/tmp/zeta_simplification/N.png
>
The last screen shot should have been
http://12000.org/tmp/zeta_simplification/Np.png
--Nasser
acer
> "Richard Fateman" <fate...@cs.berkeley.edu> wrote in message
>
> Which one is correct? Is this the effect of Mathematica interval arithmetic?
>
> --Nasser
If you want to give Mathematica's numerical computation model a
fighting chance here then shouldn't you be using N[h[s] - Gamma[s]]
instead of N[h[s]] - N[Gamma[s]]?
Nasser M. Abbasi
"acer" <ma...@rogers.com> wrote in message news:9a230ac2-0ede-43fa-9665-
>
> If you want to give Mathematica's numerical computation model a
> fighting chance here then shouldn't you be using N[h[s] - Gamma[s]]
> instead of N[h[s]] - N[Gamma[s]]?
I did actually do that before and found no difference. Gamms[s] and h[s]
diverge soon:
In[1]:= h[s_] := ((2*Pi)^s*((1/2)*s*Zeta[1 - s] -
4^(s - 1)*Zeta[1 - s, 1/4] +
4^(s - 1)*Zeta[1 - s, 3/4]))/
(s*Zeta[s]*Cos[(Pi*s)/2] -
Zeta[s, 1/4]*Sin[(Pi*s)/2] +
Zeta[s, 3/4]*Sin[(Pi*s)/2]);
In[2]:= Block[{$MaxExtraPrecision = 500},
Table[{s, N[h[s] - Gamma[s]]}, {s, 2, 28}]]
Out[2]=
--Nasser
Dave
> ps. I did not think Walpha is supposed to have the full Mathematica in it so
> I would be surprised if it can't do some things that Mathematica can
>
> --Nasser
I suspect you mean the opposite of what you said.
--
I respectfully request that this message is not archived by companies as
unscrupulous as 'Experts Exchange' . In case you are unaware,
'Experts Exchange' take questions posted on the web and try to find
idiots stupid enough to pay for the answers, which were posted freely
by others. They are leeches.
Axel Vogt
After acer's observation and guess that h(s) = Gamma(s) and looking
into older lecture notes, I think this means to prove a functional
equation for this extended Zeta function.
In the common case that is used to extend Zeta to the complex plane,
working with integral presentations for products of Gamma*Zeta (your
trigonometrics may come in through the reflection formula for Gamma).
But that is not formally only, it uses complex analysis by passing
to contour integration (though finally it seems to have been coded
in Maple).
Thus my guessing is you probably partially have to go that route ...
Peter
> Peter wrote:
> > Anyway, here is my problem in Maple parlance.
> > h := s -> (2*Pi)^s*(1/2*s*Zeta(0,1-s,1)-4^(s-1)*Zeta(0,1-s,1/4)
> > +4^(s-1)*Zeta(0,1-s,3/4))/((cos(1/2*s*Pi)*s*Zeta(s)-sin(1/2*s*Pi)
> > *Zeta(0,s,1/4)+sin(1/2*s*Pi)*Zeta(0,s,3/4)));
> > Like Vladimir I prefer a symbolic answer which shows the processing.
> After acer's observation and guess that h(s) = Gamma(s) and looking
> into older lecture notes, I think this means to prove a functional
> equation for this extended Zeta function.
>
> In the common case that is used to extend Zeta to the complex plane,
> working with integral presentations for products of Gamma*Zeta (your
> trigonometrics may come in through the reflection formula for Gamma).
>
> But that is not formally only, it uses complex analysis by passing
> to contour integration (though finally it seems to have been coded
> in Maple).
Excellent Axel.
> Thus my guessing is you probably partially have to go that route ...
Well, there are some well known relations which can be used
to derive the identity in a symbolic way in Maple or any other CAS.
Peter
>
> Gamms[s] and h[s] diverge soon:
Assuming my derivation correct this has to be restated:
Mathematica and reality diverge soon.
Thanks for your interesting investigation.
Peter
shows also some strange results. What is going on here?
seq(numer(h(2*i)/(2*Pi)^(2*i-1))
- numer(GAMMA(2*i)/(2*Pi)^(2*i-1)),i=1..30);
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0,
19802288209643185928499101 Pi -
8644205195683235286768595007647709520704677734375,
Pi Zeta(-51) - 11021361624496124990629958634750829638898464111328125,
-Pi Zeta(-53) -
7593718159277830118544041499343321621201041772705078125,
Pi Zeta(-55) -
11276671466527577726037901626524832607483547032467041015625,
-Pi Zeta(-57) -
4499391915144503512689122748983408210385935265954349365234375,
Pi Zeta(-59) -
7698459566812245510211089023510611447970335240047891763916015625
> seq(evalf(numer(h(2*i)/(2*Pi)^(2*i-1))
- numer(GAMMA(2*i)/(2*Pi)^(2*i-1))),i=1..30);
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0,
-.8644205196 10^49 , -.1102136162 10^53 , -.7593718159 10^55 ,
-.1127667147 10^59 , -.4499391915 10^61 , -.7698459567 10^64
Axel Vogt
I think the 1st means that values are tabled or coded up to 50.
The 2nd smells like a presentation problem: I never want to trust
number = numerator/denominator, if the number has 2 different forms
(sorry for my vague expression): especially if Zeta(-51) is *not*
evaluated to *the rational* number that is likely to fail, since
'numer and 'denom' is not what one expects (now there is no denom).
But it can be healed in those special cases of the test:
Zeta(z) = Pi^(-1/2+z)*GAMMA(1/2-1/2*z)*Zeta(1-z)/GAMMA(1/2*z) as
Maple's command FunctionAdvisor(Zeta) shows (later versions, but
it refuses to confirm that using the 'is' command).
Zeta(1-z)/Zeta(z) = Pi^(1/2)/(Pi^z)/GAMMA(1/2-1/2*z)*GAMMA(1/2*z)
is just a reformulation.
GAMMA(2*i)/(2*Pi)^(2*i) = h(2*i )/(2*Pi)^(2*i);
eval(%, i=30);
% * 2;
gives
someLargeInteger/32/Pi^60 = Zeta(-59)/Zeta(60)
and substituting the above into the RHS with z=60 shows that the
equation is true (i=30 is just an example).
Peter
as acer rightly observed. acer, how did you find out?
Here I will give a proof in Maple parlance.
----
[0] Proposition.
Let zeta := (s,a) -> Zeta(0,s,a): # Hurwitz zeta function
h := s->(2*Pi)^s*(zeta(1-s,1)*s/2-4^(s-1)*(zeta(1-s,1/4)-zeta(1-s,
3/4)))
/((cos(1/2*s*Pi)*s*zeta(s,1)-sin(1/2*s*Pi)*(zeta(s,1/4)-zeta(s,
3/4))));
Then h(s) = GAMMA(s).
[1] Definitions.
e1 := s -> 4^s*(zeta(-s,1/4)-zeta(-s,3/4));
e2 := s -> sin((s+1)*Pi/2)*(zeta(s+1,1/4)-zeta(s+1,3/4))
*GAMMA(s+1)/(2*Pi)^(s+1);
eul1 := s -> `if`(s=-1 or s=0 or s=1,limit(2*e1(t),t=s),2*e1(s));
eul2 := s -> `if`(s=-1 or s=0 or s=1,limit(2*e2(t),t=s),2*e2(s));
b1 := s -> -s*zeta(1-s,1);
b2 := s -> -2*(2*Pi)^(-s)*cos(s*Pi/2)*s!*zeta(s,1);
ber1 := s -> `if`(s=-1 or s=0 or s=1,limit(b1(t),t=s),b1(s));
ber2 := s -> `if`(s=-1 or s=0 or s=1,limit(b2(t),t=s),b2(s));
bereul1 := s -> ber1(s)+eul1(s-1);
bereul2 := s -> ber2(s)+eul2(s-1);
[2] Proof.
(1) e1(s) = e2(s) by the functional equation of Dirichlet beta.
(2) b1(s) = b2(s) by the Riemann functional equation.
(3) eul1(s) = eul2(s) by (1).
(4) ber1(s) = ber2(s) by (2).
(5) bereul1(s) = bereul2(s) by (3) and (4).
(6) Rearranging the terms in the equation
bereul1(s) - bereul2(s) = 0 gives h(s) = GAMMA(s).
<qed>
Here is what Maple gives for simplify(bereul1(s) - bereul2(s));
2^(1-s)*Pi^(-s)*GAMMA(s)*cos(1/2*Pi*s)*s*Zeta(s)
-2^(1-s)*Pi^(-s)*GAMMA(s)*sin(1/2*Pi*s)*Zeta(0,s,1/4)
+2^(1-s)*Pi^(-s)*GAMMA(s)*sin(1/2*Pi*s)*Zeta(0,s,3/4)
-s*Zeta(1-s)+1/2*4^s*Zeta(0,1-s,1/4)-1/2*4^s*Zeta(0,1-s,3/4)
Equating this with 0 expresses the Gamma function by
the zeta function.
<box>
GAMMA(s)
--------- =
(2 Pi)^s
Zeta(1 - s) (s/2) - 4^(s-1)(Zeta(1-s,1/4) - Zeta(1-s,3/4))
-----------------------------------------------------------
Zeta(s) s cos(sPi/2) - sin(sPi/2)(Zeta(s,1/4)-Zeta(s,3/4 ))
</box>
[3] Motivation.
Let n > 1.
(1) eul(n) interpolates the Euler numbers.
(2) ber(n) interpolates the Bernoulli numbers.
(3) bereul(n) interpolates the Euler *and* the Bernoulli numbers.
seq(bereul1(i),i=1..12);
seq(bernoulli(i,1)+euler(i-1),i=1..12);
plot([bereul1(t),-bereul2(t)],t=-2..6); # the Euler-Bernoulli crusher
[4] Bottom line: CAS and the equation h(s) = GAMMA(s).
(1) By symbolic computation: Neither Maple nor Mathematica can
simplify h(s) to GAMMA(s). Nasser: "I tried it on Maple 12
and Mathematica 7, but no simplification on the zeta's."
acer: "I got something similar with Maple 13.01. My attempts
to reduce it further didn't get far."
(2) By numerical computation:
Nasser: "Gamms[s] and h[s] diverge soon." Looking at the
output Nasser provides and assuming Nasser did not make a
mistake, doesn't this imply a major bug in Mathematica's
numerical computation model?
(3) There are only two relations behind all this: the Riemann
functional equation of the zeta function and the functional
equation of Dirichlet's beta. Riemann's equation belongs to
the crown jewels of mathematics since 1859 and Dirichlet's
equation is of similar caliber. Why are the CASs of 2009 not
able to deal with them adequately?
Jon McLoone
Extra working precision provided by $MaxExtraPrecision is not used in
machine arithmetic (N with no second argument). So Nasser's code was
working entirely in machine arithmetic.
Specify any reasonable second argument to N and it copes just fine....
In[26]:= Quiet[Table[{s, N[h - Gamma[s], 50]}, {s, 2, 28}]]
Out[26]= {{2, 0.*10^-95}, {3, 0.*10^-94}, {4, 0.*10^-90}, {5,
0.*10^-89}, {6, 0.*10^-84}, {7, 0.*10^-85}, {8, 0.*10^-79}, {9,
0.*10^-80}, {10, 0.*10^-73}, {11, 0.*10^-76}, {12, 0.*10^-68}, {13,
0.*10^-72}, {14, 0.*10^-62}, {15, 0.*10^-67}, {16, 0.*10^-57}, {17,
0.*10^-63}, {18, 0.*10^-51}, {19, 0.*10^-59}, {20, 0.*10^-46}, {21,
0.*10^-54}, {22, 0.*10^-40}, {23, 0.*10^-50}, {24, 0.*10^-35}, {25,
0.*10^-45}, {26, 0.*10^-29}, {27, 0.*10^-41}, {28, 0.*10^-23}}
Richard Fateman
....
>
> Extra working precision provided by $MaxExtraPrecision is not used in
> machine arithmetic (N with no second argument). So Nasser's code was
> working entirely in machine arithmetic.
> Specify any reasonable second argument to N and it copes just fine....
>
This is hardly surprising.
There's a theorem to the effect that two analytic functions that agree
on a continuous subset of the real line are the same
so my plot that the two functions are the same, not just integer values,
suggested they were the same, function.
Unless at least one of the functions was not analytic.
Nasser M. Abbasi
"Jon McLoone" <jo...@wolfram.co.uk> wrote in message
news:8d0a5784-a6cd-4b36...@e27g2000yqd.googlegroups.com...
"Extra working precision provided by $MaxExtraPrecision is not used in
machine arithmetic (N with no second argument). So Nasser's code was
working entirely in machine arithmetic.
Specify any reasonable second argument to N and it copes just fine....
In[26]:= Quiet[Table[{s, N[h - Gamma[s], 50]}, {s, 2, 28}]]
Out[26]= {{2, 0.*10^-95}, {3, 0.*10^-94}, {4, 0.*10^-90}, {5,
0.*10^-89}, {6, 0.*10^-84}, {7, 0.*10^-85}, {8, 0.*10^-79}, {9,
0.*10^-80}, {10, 0.*10^-73}, {11, 0.*10^-76}, {12, 0.*10^-68}, {13,
0.*10^-72}, {14, 0.*10^-62}, {15, 0.*10^-67}, {16, 0.*10^-57}, {17,
0.*10^-63}, {18, 0.*10^-51}, {19, 0.*10^-59}, {20, 0.*10^-46}, {21,
0.*10^-54}, {22, 0.*10^-40}, {23, 0.*10^-50}, {24, 0.*10^-35}, {25,
0.*10^-45}, {26, 0.*10^-29}, {27, 0.*10^-41}, {28, 0.*10^-23}}
"
Opps. My mistake then. I should have looked more carefully on this.
I read the documentation on $MaxExtraPrecision, where it said:
"$MaxExtraPrecision gives the maximum number of extra digits of precision to
be used in functions such as N."
Then below that it said:
"You can use Block[{$MaxExtraPrecision=n},expr] to reset the value of
$MaxExtraPrecision temporarily during the evaluation of expr. "
So, I went ahead and used it. My fault.
Sorry for any confusion this might have caused.
--Nasser
Axel Vogt
Use log is better (the following Maple command using 14 Digits only
will certainly work in MMA as well), it compares relative errors:
[seq(ln(h(s)) - ln(GAMMA(s)), s= 2 .. 60, 2)]: # steps of 2
evalf[14](%);
[0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
-10
0., 0., 0., 0., 0., 0., 0., 0.1 10 , 0., 0., 0., 0., 0.]
Peter
> Use log is better (the following Maple command using 14 Digits only
> will certainly work in MMA as well), it compares relative errors:
> [seq(ln(h(s)) - ln(GAMMA(s)), s= 2 .. 60, 2)]: # steps of 2
> evalf[14](%);
> [0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
> -10
> 0., 0., 0., 0., 0., 0., 0., 0.1 10 , 0., 0., 0., 0., 0.]
Well, but be aware that the input in your example are all integers,
and they
are evaluated by a different method compared to the general real case.
But what are the values of e1 and e2 at -1, 0, 1?
e1 := s -> 4^(s-1)*(zeta(1-s,1/4)-zeta(1-s,3/4));
e2 := s -> sin(s*Pi/2)*(zeta(s,1/4)-zeta(s,3/4))*GAMMA(s)/(2*Pi)^s;
e1(-1) = 1/16*Psi(1,1/4)-1/16*Psi(1,3/4) = .9159655940
e1(0) = in Zeta singularity encountered
e1(1) = 1/2
From the plot it looks like e1(0) and e2(0) exist as a limiting
values.
plot([1/2,e2(t),e1(t)],t=-1..4);
However, all (!) six limits give 0 (with my Maple VR5),
this means that all limits are false, n'est-ce pas?
limit(e1(t),t=-1);limit(e1(t),t=0);limit(e1(t),t=1);
limit(e2(t),t=-1);limit(e2(t),t=0);limit(e2(t),t=1);
Axel Vogt
Hm ... yes, just meant 'better use log because of magnitudes'.
For the problem with limit: that comes false in Maple 12 as well,
plot([1/2,e2(t)+1e-2,e1(t)],t=-1..4, color=[red,green,blue]);
suggests the limits can not be zero.
But there is help:
zeta := (s,a) -> Zeta(0,s,a); # your notation
with(MultiSeries); # overriding the standard uses better ways
[-1, 0, +1]; # just for more compact notations
map('c -> limit(e1(t), t=c)', %);
map('c -> limit(e2(t), t=c)', %%);
2
Catalan Pi Pi
[------- + --- - 1/16 Psi(1, 3/4), ----, 1/2]
2 16 4
Pi
[-(-2 Zeta(1, -1, 1/4) + 2 Zeta(1, -1, 3/4)) Pi, ----, 1/2]
4
I do not know when the package was introduced (from INRIA, France?)
But since then the help says "The MultiSeries package is still under
development." What a shame ...
Axel Vogt
> On 21 Dez., 21:13, Axel Vogt <&nore...@axelvogt.de> wrote:
>> Use log is better (the following Maple command using 14 Digits only
>> will certainly work in MMA as well), it compares relative errors:
>> [seq(ln(h(s)) - ln(GAMMA(s)), s= 2 .. 60, 2)]: # steps of 2
>> evalf[14](%);
>> [0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
>> -10
>> 0., 0., 0., 0., 0., 0., 0., 0.1 10 , 0., 0., 0., 0., 0.]
>
> Well, but be aware that the input in your example are all integers,
> and they
> are evaluated by a different method compared to the general real case.
... <snipped, just to care for the numerics>
PS: it is not limited to integers (according to your proof)
and it seems that Maple can handle it numerically
[seq(ln(h(-s+0.1)) - ln(GAMMA(-s+0.1)), s= 55 .. 59)]:
evalf[14](%);
-10
[0. + 0. I, 0., 0.1 10 + 0. I, 0., 0. + 0. I]
Peter
> > Peter wrote:
> > But what are the values of e1 and e2 at -1, 0, 1?
> > e1 := s -> 4^(s-1)*(zeta(1-s,1/4)-zeta(1-s,3/4));
> > e2 := s -> sin(s*Pi/2)*(zeta(s,1/4)-zeta(s,3/4))*GAMMA(s)/(2*Pi)^s;
> > e1(-1) = 1/16*Psi(1,1/4)-1/16*Psi(1,3/4) = .9159655940
> > e1(0) = in Zeta singularity encountered
> > e1(1) = 1/2
> > From the plot it looks like e1(0) and e2(0) exist as a limiting
> > values. plot([1/2,e2(t),e1(t)],t=-1..4);
> > However, all (!) six limits give 0 (with my Maple VR5),
> > this means that all limits are false, n'est-ce pas?
> > limit(e1(t),t=-1);limit(e1(t),t=0);limit(e1(t),t=1);
> > limit(e2(t),t=-1);limit(e2(t),t=0);limit(e2(t),t=1);
> [-1, 0, +1]; # just for more compact notations
> map('c -> limit(e1(t), t=c)', %);
> map('c -> limit(e2(t), t=c)', %%);
> 2
> Catalan Pi Pi
> [------- + --- - 1/16 Psi(1, 3/4), ----, 1/2]
> 2 16 4
> Pi
> [-(-2 Zeta(1, -1, 1/4) + 2 Zeta(1, -1, 3/4)) Pi, ----, 1/2]
> 4
> I do not know when the package was introduced (from INRIA, France?)
> But since then the help says "The MultiSeries package is still under
> development."
Great! The MultiSeries package is not available with my old Maple.
Looking at the result: Maple classic: 6 bugs, MultiSeries 6 hits.
I suggest that Maple should outsource more code to INRIA ;)
So I learned today:
Psi(1,1/4) - Psi(1,3/4) = 32*Pi*(Zeta(1,-1,1/4) - Zeta(1,-1,3/4))
= 8*Catalan + Pi^2 - Psi(1,3/4)
= 14.6554495068355
Anyone knows an expression with constants for Psi(1,3/4)?
Thank you Axel!
Raymond Manzoni
Psi(1,3/4)= pi^2-8*Catalan
<http://mathworld.wolfram.com/PolygammaFunction.html>
so that Psi(1,1/4) - Psi(1,3/4) = 16*Catalan
Hoping it helped,
Raymond
Peter
> Peter a écrit :
Oui Monsieur! Merci beaucoup! Alors nous avons :
(Psi(1,1/4) - Psi(1,3/4))/16 = 2*Pi*(Zeta(1,-1,1/4) - Zeta(1,-1,3/4))
= Catalan
= 0.9159655941772190
Merry Chrismas!
Peter
clicl...@freenet.de
Peter schrieb:
A simple way to simplify your expression is to note that the Hurwitz
zeta function appears with first arguments s as well as 1-s, and
therefore to substitute
Z(s,p,q) := 2*GAMMA(1-s)/(2*pi*q)^(1-s)*SUM(SIN(2*pi*k*p/q+pi*s/2)
*ZETA(1-s,k/q),k,1,q)
for the functions zeta(s,p/q) of one type, where p and q must be
integers with 0 < p <= q; this substition mirrors zeta(s,a) at the
critical line Re(s) = 1/2. One obtains, for example:
(2*pi)^s*(1/2*s*ZETA(1-s)-4^(s-1)*ZETA(1-s,1/4)
+4^(s-1)*ZETA(1-s,3/4))/(s*Z(s,1,1)*COS(pi*s/2)
-Z(s,1,4)*SIN(pi*s/2)+Z(s,3,4)*SIN(pi*s/2))
pi/(SIN(pi*s)*(-s)!)
My Derive 6.10 is not able to simplify this result further; we'll have
to wait for version 7.02 to obtain:
GAMMA(s)
automatically.
Martin.
Peter
> > Peter schrieb:
> > GAMMA(s)
> > --------- =
> > (2 Pi)^s
> >
> > Zeta(1 - s) (s/2) - 4^(s-1)(Zeta(1-s,1/4) - Zeta(1-s,3/4))
> > -----------------------------------------------------------
> > Zeta(s) s cos(sPi/2) - sin(sPi/2)(Zeta(s,1/4)-Zeta(s,3/4 ))
> A simple way to simplify your expression is to note that the Hurwitz
> zeta function appears with first arguments s as well as 1-s,
Yes, by construction from the functional equations.
> and therefore to substitute
>
> Z(s,p,q) := 2*GAMMA(1-s)/(2*pi*q)^(1-s)*SUM(SIN(2*pi*k*p/q+pi*s/2)
> *ZETA(1-s,k/q),k,1,q)
>
> for the functions zeta(s,p/q) of one type, where p and q must be
> integers with 0 < p <= q; this substition mirrors zeta(s,a) at the
> critical line Re(s) = 1/2.
Well, but why this restriction to rational values?
GAMMA(s) Zeta(1 - s)
--------- = --------------------------------------------
(2 Pi)^s e^(-I Pi s/2) Zeta(s) + e^(I Pi s/2) Zeta(s)
Zeta(1 - s) (2 Pi)^s
So h(s) = ------------ -------------
Zeta(s) 2 cos(s Pi/2)
> My Derive 6.10 is not able to simplify this result further;
Quel dommage ! Do you happen to know what Maxima gives?
> we'll have to wait for version 7.02 to obtain:
I am puzzled. Didn't you write somewhere that Derive is dead?
clicl...@freenet.de
Peter schrieb:
> > cliclic... schrieb:
> > > Peter schrieb:
>
> > > GAMMA(s)
> > > --------- =
> > > (2 Pi)^s
> > >
> > > Zeta(1 - s) (s/2) - 4^(s-1)(Zeta(1-s,1/4) - Zeta(1-s,3/4))
> > > -----------------------------------------------------------
> > > Zeta(s) s cos(sPi/2) - sin(sPi/2)(Zeta(s,1/4)-Zeta(s,3/4 ))
>
> > A simple way to simplify your expression is to note that the Hurwitz
> > zeta function appears with first arguments s as well as 1-s,
>
> Yes, by construction from the functional equations.
>
> > and therefore to substitute
> >
> > Z(s,p,q) := 2*GAMMA(1-s)/(2*pi*q)^(1-s)*SUM(SIN(2*pi*k*p/q+pi*s/2)
> > *ZETA(1-s,k/q),k,1,q)
> >
> > for the functions zeta(s,p/q) of one type, where p and q must be
> > integers with 0 < p <= q; this substition mirrors zeta(s,a) at the
> > critical line Re(s) = 1/2.
>
> Well, but why this restriction to rational values?
>
> GAMMA(s) Zeta(1 - s)
> --------- = --------------------------------------------
> (2 Pi)^s e^(-I Pi s/2) Zeta(s) + e^(I Pi s/2) Zeta(s)
>
> Zeta(1 - s) (2 Pi)^s
> So h(s) = ------------ -------------
> Zeta(s) 2 cos(s Pi/2)
I am not sure what point you are making here. Perhaps I should explain
my procedure and reasoning in more detail:
A Computer Algebra system that cannot simplify your expression finds no
corresponding simplification path to follow, presumably because it does
not have access to a suitable mathematical rule (or collection of rules)
in suitable form with suitable conditions when to apply it. As far as
Derive is concerned, adding the above general reflection rule to its
knowledge suffices to correct this failure (if we accept a recognizable
equivalent of GAMMA(s) for an answer). I have used the reflection rule
as a "rewrite rule" for ZETA(s,p/q) and have applied it to your
expression by hand, replacing all ZETA(s,p/q) in the denominator by
Z(s,p,q). Subsequent simplification on Derive immediately gives the
(somewhat imperfect) result:
pi/(SIN(pi*s)*(-s)!)
In my eyes, the generality of the above reflection rule makes it well
suited for this kind of use in a CAS; it should then probably be tried
more or less blindly whenever more than one ZETA(s,a) or ZETA(1-s,b)
appears in a rational expression. The rule requires a rational second
ZETA argument p/q because q appears as a summation limit, but this is no
problem for your expression. The requirement 0 < p/q <= 1 is fulfilled
as well (if it were not, another rule could be used to transform p/q
into p/q+1 or p/q-1 as often as needed).
>
> > My Derive 6.10 is not able to simplify this result further;
>
> Quel dommage ! Do you happen to know what Maxima gives?
D�sol�, I don't have Maxima installed. Perhaps somebody else can help?
Would interest me too!
But Derive readily confirms the equivalence of the imperfect result to
GAMMA(s), using the Factor command to force a common denominator:
pi/(SIN(pi*s)*(-s)!) - GAMMA(s)
0
So the knowledge required for this final step is available in principle.
>
> > we'll have to wait for version 7.02 to obtain:
>
> I am puzzled. Didn't you write somewhere that Derive is dead?
Yes, Texas Instruments bought it and considers it more valuable to them
dead than alive. My play with future version numbers is supposed to be
just a small running gag.
Martin.
Peter
Thanks for your explanations.
> > > My Derive 6.10 is not able to simplify this result further;
> > Quel dommage ! Do you happen to know what Maxima gives?
> Désolé, I don't have Maxima installed. Perhaps somebody else can help?
> Would interest me too!
Silence is golden :) So what is the bottom line?
2010-01-01 arrives tonight and if I see it right neither
Maple, Mathematica, Derive or Maxima is able to handle the
Riemann functional equation of the zeta function and the
functional equation of Dirichlet's beta function.
So what are the CAS builders doing? On the webpage of Maplesoft
I found this answer.
/
| "Maplesoft has introduced one of the most exciting concepts
| in math software history: Clickable Math."
\
Ja ticken die denn noch richtig?
Yes ticking the because still correctly? (Translator)
Yes, the tick as still correct?
Oui TIC-TAC du car encore correctement ?
Kyllä ticking koska edelleen oikein?
Sì bomba il perché ancora correttamente?
Happy New Year!