5 views

Skip to first unread message

Dec 18, 2009, 8:28:29 PM12/18/09

to

Once upon a time there was a guy here who wrote things like

"An exact simplification challenge". Maybe he is lost in transition...

"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

Dec 18, 2009, 8:59:12 PM12/18/09

to

"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

Dec 18, 2009, 9:30:11 PM12/18/09

to

>"Nasser M. Abbasi" <n...@12000.org> wrote:

> > "Peter" <peter.lusc...@googlemail.com> wrote in message

> > "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

Message has been deleted

Dec 18, 2009, 10:26:34 PM12/18/09

to

I don't have a set of symbolic simplification steps, but is it equal

to GAMMA(s)?

Dec 18, 2009, 10:33:55 PM12/18/09

to

"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

Dec 18, 2009, 11:07:55 PM12/18/09

to

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.

Dec 18, 2009, 11:19:10 PM12/18/09

to

"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

Dec 18, 2009, 11:46:44 PM12/18/09

to

On Dec 18, 11:19 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:

> "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.

> "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

Dec 18, 2009, 11:52:07 PM12/18/09

to

If you plot h-Gamma[s], you will see the result is 0, modulo roundoff.

the fact that h===Gamma[s] is not telling you anything useful.

Dec 19, 2009, 12:00:13 AM12/19/09

to

"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.

Dec 19, 2009, 12:52:59 AM12/19/09

to

"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

Dec 19, 2009, 1:07:43 AM12/19/09

to

"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

Dec 19, 2009, 1:22:17 AM12/19/09

to

On Dec 19, 12:52 am, "Nasser M. Abbasi" <n...@12000.org> wrote:

> "Richard Fateman" <fate...@cs.berkeley.edu> wrote in message> herehttp://12000.org/tmp/zeta_simplification/N16.png so it is all zero for all> The above screen output is herehttp://12000.org/tmp/zeta_simplification/N.png> The above screen shot is herehttp://12000.org/tmp/zeta_simplification/N.png

>

> Which one is correct? Is this the effect of Mathematica interval arithmetic?

>

> --Nasser

> "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]]?

Dec 19, 2009, 1:31:35 AM12/19/09

to

"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

Dec 19, 2009, 5:31:48 AM12/19/09

to

Nasser M. Abbasi wrote:

> 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.

Dec 19, 2009, 5:48:16 AM12/19/09

to

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 ...

Dec 19, 2009, 8:26:21 AM12/19/09

to

On 19 Dez., 11:48, Axel Vogt <&nore...@axelvogt.de> wrote:

> Peter wrote:

> 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.

Dec 19, 2009, 8:55:35 AM12/19/09

to

> "Nasser M. Abbasi" wrote:

>

> Gamms[s] and h[s] diverge soon:

>

> 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.

Dec 19, 2009, 10:12:02 AM12/19/09

to

A numerical investigation with Maple similar to yours

shows also some strange results. What is going on here?

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

Dec 19, 2009, 5:12:35 PM12/19/09

to

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).

Dec 21, 2009, 5:45:11 AM12/21/09

to

The solution of the simplification challenge is h(s) = GAMMA(s),

as acer rightly observed. acer, how did you find out?

Here I will give a proof in Maple parlance.

----

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?

Dec 21, 2009, 9:09:40 AM12/21/09

to

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}}

Dec 21, 2009, 9:34:23 AM12/21/09

to

Jon McLoone wrote:

....

....

>

> 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.

Dec 21, 2009, 2:53:26 PM12/21/09

to

"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

Dec 21, 2009, 3:13:18 PM12/21/09

to

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.]

Dec 21, 2009, 9:25:19 PM12/21/09

to

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.]

> 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);

Dec 22, 2009, 2:26:55 PM12/22/09

to

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 ...

Dec 22, 2009, 2:37:24 PM12/22/09

to

Peter wrote:

> 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.

> 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]

Dec 22, 2009, 6:32:19 PM12/22/09

to

> Axel Vogt wrote:

> > 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);

> > 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);

> 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."

> [-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!

Dec 22, 2009, 6:51:20 PM12/22/09

to

Peter a �crit :

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

Dec 22, 2009, 7:27:39 PM12/22/09

to

On 23 Dez., 00:51, Raymond Manzoni <raym...@free.fr> wrote:

> Peter a écrit :

> 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

Dec 27, 2009, 8:33:31 PM12/27/09

to

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.

Dec 29, 2009, 6:45:35 PM12/29/09

to

> cliclic... schrieb:

> > Peter 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)

> 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?

Dec 30, 2009, 3:28:15 PM12/30/09

to

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.

Dec 31, 2009, 1:24:39 PM12/31/09

to

> > > cliclic... schrieb:

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!

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu