Does this happen because of evalhf?

> `&*`:=1:
> f:=(a,b)-> a &* b:
 
> evalf(f(2,2));
                                      1.
 
> evalhf(f(2,2));
                                      4.
 
> evalhf(f[1](2,2));
Error, unable to evaluate function `f[1]` in evalhf

The above shows that the assignment to `&*` is not respected under evalhf. But it is respected under evalf.

Also, the plotting routines attempt to use evalhf, and if that fails then they fall back to evalf. Hence when using f[1] fails under evalhf, the plotting routine falls back to using evalf to generate the plot values.

And, indeed, plot3d(evalf@f,0..1,0..1) seems to behave as expected.

I don't see it mentioned in any help-page that evalhf would use :-`*` for `&*`. Is there some obvious rationale to it?

acer

The tree which identify must search is enormous. By default it also searches for sums, and sums of powers (with coefficients), etc. The tree has to be heavily cut, or else it would take far too long. If you know that sums, etc, are not to be considered then those rules can be excluded. That's not an unreasonable demand, given the tree growth as the basis and digits increase. But even then, an exact quantity like 34459425/(3617Pi^8) has a large number (depending on the digits of input data) of other constants which are quite close to it. In order to pinpoint just that single desired value one might reasonably need to specifiy a large number of digits of input data, and increase the "multiplicative constant basis" by so many new terms that `identify` would take a prohibitively long time.

ps. Plouffe announced a new version of his inverter today, with 2.459e9 constants in it. For fun, I gave 0.0322515344331994891844220526885 = evalf[30](1/Pi^3) to his (current, or new?) inverter and it returned 1/Pi^3*ln(exp(1)) which is curiously delightful. I wasn't able to get it to resolve evalf[n](1/Pi^4) though.

acer

The tree which identify must search is enormous. By default it also searches for sums, and sums of powers (with coefficients), etc. The tree has to be heavily cut, or else it would take far too long. If you know that sums, etc, are not to be considered then those rules can be excluded. That's not an unreasonable demand, given the tree growth as the basis and digits increase. But even then, an exact quantity like 34459425/(3617Pi^8) has a large number (depending on the digits of input data) of other constants which are quite close to it. In order to pinpoint just that single desired value one might reasonably need to specifiy a large number of digits of input data, and increase the "multiplicative constant basis" by so many new terms that `identify` would take a prohibitively long time.

ps. Plouffe announced a new version of his inverter today, with 2.459e9 constants in it. For fun, I gave 0.0322515344331994891844220526885 = evalf[30](1/Pi^3) to his (current, or new?) inverter and it returned 1/Pi^3*ln(exp(1)) which is curiously delightful. I wasn't able to get it to resolve evalf[n](1/Pi^4) though.

acer

Your posts aren't very clear, with respect to the actual goal. Perhaps you might give representative examples, showing explicitly both the input and the expected output. I suggest more than just one example, to get greater coverage of expected functionality.

acer

Your posts aren't very clear, with respect to the actual goal. Perhaps you might give representative examples, showing explicitly both the input and the expected output. I suggest more than just one example, to get greater coverage of expected functionality.

acer

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

acer

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