I have found that multiplication on my 84+ is faster when the number with fewer digits of precision is on the right. I have tested this with real variables and lists, finance variables, and immediate values on each side of the multiplication.

My timing program (rounds down; times include 3s loop overhead):

startTmr:Repeat checkTmr(Ans:End

For(n,1,5ᴇ3

[code]

End

checkTmr(T+1

For example, when N=cos(1) (many digits of precision):

2N once takes 4.2 ms; N2 takes 2.8 ms. Similar results when 2 is replaced with 1, .2, 7ᴇ80, a variable that equals 2, or when N is replaced with a real variable, π, etc.

N{1,2,3} takes 7.2 ms; {1,2,3}N takes 11.2 ms. Same when the list is in L₁ rather than immediate, and switched if N has few digits of precision and the list has many.

N.12345678901234 and .12345678901234N take 3.0 and 2.8 ms respectively. Not much difference here.

When there are an intermediate number of digits (say, five), the timings are in between those above; it is again slightly faster to have the number with more digits of precision on the left.

Using this optimization on a very simple SQUFOF algorithm I had lying around on my calculator resulted in a ~2% overall speedup. Am I correct in concluding that the number of digits of precision is what affects speed, or is there something I'm overlooking?

My timing program (rounds down; times include 3s loop overhead):

startTmr:Repeat checkTmr(Ans:End

For(n,1,5ᴇ3

[code]

End

checkTmr(T+1

For example, when N=cos(1) (many digits of precision):

2N once takes 4.2 ms; N2 takes 2.8 ms. Similar results when 2 is replaced with 1, .2, 7ᴇ80, a variable that equals 2, or when N is replaced with a real variable, π, etc.

N{1,2,3} takes 7.2 ms; {1,2,3}N takes 11.2 ms. Same when the list is in L₁ rather than immediate, and switched if N has few digits of precision and the list has many.

N.12345678901234 and .12345678901234N take 3.0 and 2.8 ms respectively. Not much difference here.

When there are an intermediate number of digits (say, five), the timings are in between those above; it is again slightly faster to have the number with more digits of precision on the left.

Using this optimization on a very simple SQUFOF algorithm I had lying around on my calculator resulted in a ~2% overall speedup. Am I correct in concluding that the number of digits of precision is what affects speed, or is there something I'm overlooking?