That is a very interesting observation, Alec. Thanks for sharing.

acer

The other recent thread, in which the supposed "map[inline](..)" appeared, contained a few misunderstandings. Are you sure that map[inline] does anything at all? Or is that `inline` instance pretty much ignored, like the `foobar` in map[foobar]?

nb. In that other thread, it appears that map[inplace] was what was really intended, at the juncture that it was introduced.

Don't get me wrong: there is an option inline for procedures, which you may find interesting and useful. I'm adding a note here about only map[inline].

acer

The other recent thread, in which the supposed "map[inline](..)" appeared, contained a few misunderstandings. Are you sure that map[inline] does anything at all? Or is that `inline` instance pretty much ignored, like the `foobar` in map[foobar]?

nb. In that other thread, it appears that map[inplace] was what was really intended, at the juncture that it was introduced.

Don't get me wrong: there is an option inline for procedures, which you may find interesting and useful. I'm adding a note here about only map[inline].

acer

No, that (by itself) is not showing a bug.

The help-page for identify clearly mentions that the default values for BasisProdConst is only [2,3,5,7,Pi,exp(1),ln(2),ln(3),Zeta(3),Zeta(5)]
That should explain why the other values in your sequence were not found. I think that my two posts above illustrated these points (both the cause, and how to accomodate it by extending the basis).

acer

No, that (by itself) is not showing a bug.

The help-page for identify clearly mentions that the default values for BasisProdConst is only [2,3,5,7,Pi,exp(1),ln(2),ln(3),Zeta(3),Zeta(5)]
That should explain why the other values in your sequence were not found. I think that my two posts above illustrated these points (both the cause, and how to accomodate it by extending the basis).

acer

Using the first ten primes and Pi as the basis for product constants gets success for 104=2*3*13 but not for 106=2*53.

> restart:

> Digits:=20:

> S:=seq(ithprime(i),i=1..10);

          S := 2, 3, 5, 7, 11, 13, 17, 19, 23, 29

> seq(printf("%a \n",[[ifactors(N)],
>       identify(evalf(N/Pi^4),
>       BasisProdConst=[S,Pi],ProdConst=true)]),
>     N=100..110);

[[[1, [[2, 2], [5, 2]]]], 100/Pi^4]
[[[1, [[101, 1]]]], 1.0368642077231178541]
[[[1, [[2, 1], [3, 1], [17, 1]]]], 102/Pi^4]
[[[1, [[103, 1]]]], 1.0573961722324865245]
[[[1, [[2, 3], [13, 1]]]], 104/Pi^4]
[[[1, [[3, 1], [5, 1], [7, 1]]]], 105/Pi^4]
[[[1, [[2, 1], [53, 1]]]], 1.0881941189965395300]
[[[1, [[107, 1]]]], 1.0984601012512238652]
[[[1, [[2, 2], [3, 3]]]], 108/Pi^4]
[[[1, [[109, 1]]]], 1.1189920657605925356]
[[[1, [[2, 1], [5, 1], [11, 1]]]], 110/Pi^4]

Extending the basis will make it work for 106/Pi^4 too, but it understandably gets slower. I had to raise Digits again, to get it to work. The dependence on the Digits setting is less clear.

> S:=seq(ithprime(i),i=1..17);
      S := 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59
 
> Digits:=40:
> seq(printf("%a \n",[[ifactors(N)],
>      identify(evalf(N/Pi^4),
>         BasisProdConst=[S,Pi],ProdConst=true)]),N=100..110);

[[[1, [[2, 2], [5, 2]]]], 100/Pi^4]
[[[1, [[101, 1]]]], 1.036864207723117854104431109978988108325]
[[[1, [[2, 1], [3, 1], [17, 1]]]], 102/Pi^4]
[[[1, [[103, 1]]]], 1.057396172232486524482736676513225496608]
[[[1, [[2, 3], [13, 1]]]], 104/Pi^4]
[[[1, [[3, 1], [5, 1], [7, 1]]]], 105/Pi^4]
[[[1, [[2, 1], [53, 1]]]], 106/Pi^4]
[[[1, [[107, 1]]]], 1.098460101251223865239347809581700273176]
[[[1, [[2, 2], [3, 3]]]], 108/Pi^4]
[[[1, [[109, 1]]]], 1.118992065760592535617653376115937661459]
[[[1, [[2, 1], [5, 1], [11, 1]]]], 110/Pi^4]

acer

Using the first ten primes and Pi as the basis for product constants gets success for 104=2*3*13 but not for 106=2*53.

> restart:

> Digits:=20:

> S:=seq(ithprime(i),i=1..10);

          S := 2, 3, 5, 7, 11, 13, 17, 19, 23, 29

> seq(printf("%a \n",[[ifactors(N)],
>       identify(evalf(N/Pi^4),
>       BasisProdConst=[S,Pi],ProdConst=true)]),
>     N=100..110);

[[[1, [[2, 2], [5, 2]]]], 100/Pi^4]
[[[1, [[101, 1]]]], 1.0368642077231178541]
[[[1, [[2, 1], [3, 1], [17, 1]]]], 102/Pi^4]
[[[1, [[103, 1]]]], 1.0573961722324865245]
[[[1, [[2, 3], [13, 1]]]], 104/Pi^4]
[[[1, [[3, 1], [5, 1], [7, 1]]]], 105/Pi^4]
[[[1, [[2, 1], [53, 1]]]], 1.0881941189965395300]
[[[1, [[107, 1]]]], 1.0984601012512238652]
[[[1, [[2, 2], [3, 3]]]], 108/Pi^4]
[[[1, [[109, 1]]]], 1.1189920657605925356]
[[[1, [[2, 1], [5, 1], [11, 1]]]], 110/Pi^4]

Extending the basis will make it work for 106/Pi^4 too, but it understandably gets slower. I had to raise Digits again, to get it to work. The dependence on the Digits setting is less clear.

> S:=seq(ithprime(i),i=1..17);
      S := 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59
 
> Digits:=40:
> seq(printf("%a \n",[[ifactors(N)],
>      identify(evalf(N/Pi^4),
>         BasisProdConst=[S,Pi],ProdConst=true)]),N=100..110);

[[[1, [[2, 2], [5, 2]]]], 100/Pi^4]
[[[1, [[101, 1]]]], 1.036864207723117854104431109978988108325]
[[[1, [[2, 1], [3, 1], [17, 1]]]], 102/Pi^4]
[[[1, [[103, 1]]]], 1.057396172232486524482736676513225496608]
[[[1, [[2, 3], [13, 1]]]], 104/Pi^4]
[[[1, [[3, 1], [5, 1], [7, 1]]]], 105/Pi^4]
[[[1, [[2, 1], [53, 1]]]], 106/Pi^4]
[[[1, [[107, 1]]]], 1.098460101251223865239347809581700273176]
[[[1, [[2, 2], [3, 3]]]], 108/Pi^4]
[[[1, [[109, 1]]]], 1.118992065760592535617653376115937661459]
[[[1, [[2, 1], [5, 1], [11, 1]]]], 110/Pi^4]

acer

The first line of the help-page ?zip says, " zip together two lists, matrices, or vectors." 

The first line of zip's help-page's Description says, "The function zip applies the binary function f to the components of two data sets..."

How could it be more clear?

acer

The first line of the help-page ?zip says, " zip together two lists, matrices, or vectors." 

The first line of zip's help-page's Description says, "The function zip applies the binary function f to the components of two data sets..."

How could it be more clear?

acer

The point of the original question, I believe, was to crreate a procedure which did that for an arbitrary list. Ie, to make it know both the list and the list's name. Your example has that separation coded right into the seq call explicitly, and thus doesn't generalize as a tool for handling other lists.

acer

The point of the original question, I believe, was to crreate a procedure which did that for an arbitrary list. Ie, to make it know both the list and the list's name. Your example has that separation coded right into the seq call explicitly, and thus doesn't generalize as a tool for handling other lists.

acer

The original data was exact, so it would not be appropriate if Maple were automatically to convert the data to floating-point and then give a corresponding floating-point result (which is what those super fast methods above do).

acer

The original data was exact, so it would not be appropriate if Maple were automatically to convert the data to floating-point and then give a corresponding floating-point result (which is what those super fast methods above do).

acer

That paragraph is in the section covering the zip() function. It's not surprising that sqrt() may not be one of the affected routines. The zip() routine "zips" an action across two parameters, while sqrt() takes the square root of a single parameter.

About the only way I can see to even make zip(sqrt,A,B) valid is for B to be merely an option such as 'symbolic'. But that wouldn't be particularly apt here and would likely not help much in the hardware datatype rtable case, which is also central (but left out, above) to that quoted paragraph covering zip's enhancements..

acer

That paragraph is in the section covering the zip() function. It's not surprising that sqrt() may not be one of the affected routines. The zip() routine "zips" an action across two parameters, while sqrt() takes the square root of a single parameter.

About the only way I can see to even make zip(sqrt,A,B) valid is for B to be merely an option such as 'symbolic'. But that wouldn't be particularly apt here and would likely not help much in the hardware datatype rtable case, which is also central (but left out, above) to that quoted paragraph covering zip's enhancements..

acer