Sharp EL-W506T vs. Sharp EL-W516T

[ijabbott]

(11-16-2019 11:27 AM)Mjim Wrote:  Never saw the TI-30X Pro MathPrint until today. Very much like the design and display...but it doesn't seem to exist outside of Germany, and what is available on ebay is expensive.

I'd recommend getting it from amazon.de. Oh, and make sure it's the "Pro" model rather than the similar-looking "Plus" model.

[Mjim]

(11-16-2019 11:44 AM)ijabbott Wrote:  

(11-16-2019 11:27 AM)Mjim Wrote:  Never saw the TI-30X Pro MathPrint until today. Very much like the design and display...but it doesn't seem to exist outside of Germany, and what is available on ebay is expensive.

I'd recommend getting it from amazon.de. Oh, and make sure it's the "Pro" model rather than the similar-looking "Plus" model.

Thanks! I can see that the Pro is the way to go (the emulator I tried comes with both versions). Unfortunately, it is still very expensive in comparison to the fx-991ex.

[ijabbott]

(11-16-2019 11:27 AM)Mjim Wrote:  TI-30X Pro MathPrint emulator impressions:
[...]
Differentiation seems slightly better than the Sharp EL-W516X; but isn't as good as the Casio fx-991ex and suffers by losing digits (like the Sharp) when you specify smaller epsilons:

d/dx(e^(x^3),x,x=6):

Casio fx-991EX:
6.934766564*10^95 (default epsilon, but accurate for all displayed digits)

Sharp EL-W516X:
6.93477882*10^95 (default epsilon)
6.93568*10^95 (epsilon = 1*10^-10)

TI-30X Pro MathPrint:
6.934767925*10^95 (default epsilon)
6.93475*10^95 (epsilon = 1*10^-10)

It's kind of annoying that it loses digits by specifying a smaller epsilon, but I guess the TI-30X Pro MathPrint still holds it accuracy better than the Sharp.

That's a bit annoying. It's even worse for yet smaller epsilon:

7.0635e95 (epsilon = 1e-11)
6.42e95 (epsilon = 1e-12)
0 (epsilon = 1e-13)

The sweet spot for this particular evaluation seems to be somewhere around epsilon = 1e-6:

6.93476658e95 (epsilon = 1e-6)

but the operator wouldn't necessarily know that!

[ijabbott]

(11-16-2019 12:06 PM)Mjim Wrote:  

(11-16-2019 11:44 AM)ijabbott Wrote:  I'd recommend getting it from amazon.de. Oh, and make sure it's the "Pro" model rather than the similar-looking "Plus" model.

Thanks! I can see that the Pro is the way to go (the emulator I tried comes with both versions). Unfortunately, it is still very expensive in comparison to the fx-991ex.

The fx-991EX is also expensive in Germany, although the native fx-991DE X is significantly cheaper and has a few more features.

At least the TI retains its history when it powers off though.

[rprosperi]

(11-16-2019 11:27 AM)Mjim Wrote:  In fact, I couldn't find a single review on it. It's a very nice looking TI calculator, but I wouldn't even believe it existed if not for the emulator and PDF manual I downloaded for it.

Thanks for sharing all these comments; I would not have guessed there was so much variation between these various models, and especially among the various flavors of TI-30X.

Can you share where you found the emulator you downloaded?

[Mjim]

(11-16-2019 01:44 PM)rprosperi Wrote:  

(11-16-2019 11:27 AM)Mjim Wrote:  In fact, I couldn't find a single review on it. It's a very nice looking TI calculator, but I wouldn't even believe it existed if not for the emulator and PDF manual I downloaded for it.

Thanks for sharing all these comments; I would not have guessed there was so much variation between these various models, and especially among the various flavors of TI-30X.

Can you share where you found the emulator you downloaded?

No Worries!:
https://education.ti.com/en-GB/software/...alculators

I think the key word here is "MathPrint"; I did actually find a bit of a review here (about 1/3 of the way down the page; it is massive article and covers a lot of other calculators as well as calculator apps):
https://ludditus.com/2019/02/10/nostalgi...lculators/

It's a shame though that Sharp is now pretending that the Formula memory feature never existed. Looks like the non-writeview models; EL-506X or EL-506T still support formula memories however, but they make no public mention of this feature so you have to dig through the manuals to find it (though the F1, F2, F3, F4 markings around the navigation buttons are a bit of a clue that they have it).

[rprosperi]

(11-16-2019 08:12 PM)Mjim Wrote:  No Worries!:
https://education.ti.com/en-GB/software/...alculators

Thanks very much. A goldmine of TI downloads...

[Pjwum]

(11-15-2019 01:50 AM)Mjim Wrote:  I tried this myself, but I kept getting different results.

Xcas: 6.25630506563*10^10
Casio fx-9750GII: 6.256305066*10^10
Casio fx-570MS (upgraded temporarily from a fx-82MS): Throws math error.
Sharp EL-W516X:
-Default divisions: 1.54840203*10^17
-1024 divisions: 6.694153651*10^10
-4096 divisions: 6.258289041*10^10
-32768 divisions: 6.251558833*10^10 (This took a very...very long time)

Not sure if these results are right; might of made a mistake with some units somewhere.

Mjim, your result is correct. I messed up km and m.

(Of course 1/r^2 converges and so does the indefinite integral over 1/r^2 from rE to inf. Express the energy to bring a mass probe from Earth to infinity in space as kinetic energy at rE and you get the so called escape velocity which is independant from the mass probe (11.2 km/s for our planet)).

1/r^2 drops really fast and is reduced to 1/10th at about 1/20th the distance to the moon or 0.05 light seconds from Earth. Poor EL-W506 takes its default Simpson n=100 and averages the first trapezoid over a distance of 1/100 ly = 315360 light seconds, which results in a huge error right from the start.

As far as I have seen the Sharp doesn't offer default settings for its integration algorithm, as Bob asked. You have to - optionally - make an educated guess for n every time you start an integration instead of specifying your required eps. Of course this is beyond any high school level.

Patrick

[klesl]

Some emulators of Sharp calcs (with the their top model el-9950g) are available on
http://www.sharp-calculators.com/en/cont...-downloads

[rprosperi]

(11-19-2019 04:19 PM)Pjwum Wrote:  As far as I have seen the Sharp doesn't offer default settings for its integration algorithm, as Bob asked. You have to - optionally - make an educated guess for n every time you start an integration instead of specifying your required eps. Of course this is beyond any high school level.

When I was learning this stuff, it was hammered into me that you need to consider both the numbers and the nature of the 'stuff' you are calculating, in order to make informed and hopefully proper decisions about things like number of iterations, epsilon for determining you've gone 'far enough' and there is no point in continuing, etc.

One of the examples used then was not too dissimilar from the above (i.e. space calculations of some type) just to see if people would use the nominal 1E-07 as epsilon as is typically taught, clearly inappropriate for situations involving millions or billions of units, but bait just waiting for the student to plug-in the same values he/she used the last time. Caught me and taught a good lesson.

As you say, this is all well past what a high school student should be expected to understand or even spend time on, but it is interesting the various manufacturers implement different approaches to insulate users from having to think about this stuff and just bang in the equation and hit RUN.

This has been an interesting and insightful thread, who would have guessed. Thanks to those who contributed and by all means keep the discussion going.

[Mjim]

(11-19-2019 04:19 PM)Pjwum Wrote:  Mjim, your result is correct. I messed up km and m.

(Of course 1/r^2 converges and so does the indefinite integral over 1/r^2 from rE to inf. Express the energy to bring a mass probe from Earth to infinity in space as kinetic energy at rE and you get the so called escape velocity which is independant from the mass probe (11.2 km/s for our planet)).

1/r^2 drops really fast and is reduced to 1/10th at about 1/20th the distance to the moon or 0.05 light seconds from Earth. Poor EL-W506 takes its default Simpson n=100 and averages the first trapezoid over a distance of 1/100 ly = 315360 light seconds, which results in a huge error right from the start.

As far as I have seen the Sharp doesn't offer default settings for its integration algorithm, as Bob asked. You have to - optionally - make an educated guess for n every time you start an integration instead of specifying your required eps. Of course this is beyond any high school level.

Patrick

To be honest I've been stuck teaching myself calculus II (stuck on the center of mass section for several weeks now), so the Simpson integration method, error function, convergence...well they're relatively fresh in my head. As they're new concepts, I still find them pretty interesting and challenging, even if they are part of an introductory level to Calculus.

The question about working out the energy of an object traveling in space was very helpful in a way as it was a fairly practical application of many new concepts I had learned.

As you pointed out having 1/100 intervals over 1 light year (each would be 3.6525 light days), is worthless in this case, since just about all the energy required for the entire trip happens within the first interval giving rise to the huge inaccuracies. I know the Casio fx-570ms/991ms will at least alter the number of divisions based on the integral and it's interval, but I'm guessing it doesn't break up the integral into multiple pieces since it refused to solve this problem ('math error').

I tried breaking up the integral and managed to get a better result on the Sharp using the default sample rate of n=100:

(C = G*mE*1000 = 3.98589*10^17, r = distance to center of earth (and what we are integrating with respect to), c = speed of light)

integral(C/r^2, 6.371*10^6, c/10) +
integral(C/r^2, c/10, c) +
integral(C/r^2, c, 10c) +
integral(C/r^2, 10c, 100c) +
integral(C/r^2, 100c, 1000c) +
integral(C/r^2, 1000c, 3600c) + (3600c = 1 light hour)
integral(C/r^2, 3600c, 3600c*24) + (3600c*24 = 1 light day)
integral(C/r^2, 3600c*24, 3600c*24*10) +
integral(C/r^2, 3600c*24*10, 3600c*24*100)+
integral(C/r^2, 3600c*24*100, 3600c*24*365.25) (3600c*24*365.25 = 1 light year)
= 6.256305944*10^10

So 2000 divisions (10 integrals of n=100 (which is 200 divisions) ) will give a better result than 32,768 divisions if you concentrate the samples where most of the change is happening (at the start).

Really interesting stuff, which shows just how important good algorithm design is for calculators.

EDIT:
Oh, wow, just reread your first point, plugging this into the formula E=1/2*m*v^2 (m=1000kg, E = Energy required to travel 1ly from the earth) does give the escape velocity (11,186m/s is what I got). Great to see how these fit together (I don't have a general physics background, so seeing how these equations fit together is educational; thanks!).

[Albert Chan]

(11-20-2019 12:25 AM)Mjim Wrote:  I tried breaking up the integral and managed to get a better result on the Sharp using the default sample rate of n=100:

(C = G*mE*1000 = 3.98589*10^17, r = distance to center of earth (and what we are integrating with respect to), c = speed of light)

integral(C/r^2, 6.371*10^6, c/10) +
integral(C/r^2, c/10, c) +
integral(C/r^2, c, 10c) +
integral(C/r^2, 10c, 100c) +
integral(C/r^2, 100c, 1000c) +
integral(C/r^2, 1000c, 3600c) + (3600c = 1 light hour)
integral(C/r^2, 3600c, 3600c*24) + (3600c*24 = 1 light day)
integral(C/r^2, 3600c*24, 3600c*24*10) +
integral(C/r^2, 3600c*24*10, 3600c*24*100)+
integral(C/r^2, 3600c*24*100, 3600c*24*365.25) (3600c*24*365.25 = 1 light year)
= 6.256305944*10^10

Of course, easiest way is ∫ C/r^2 dr = -C/r + constant
With C=3.98589196e+17, and dr integral limit, a=6.371e6, b=9.4607304725808e+15

∫ (C/r^2 dr, r=a to b) = (-C/b) - (-C/a) ≈ 62563050656

Simpson's rule using your idea, we can automate it:

r = e^x → dr = e^x dx

∫ C/r^2 dr = ∫ C/e^x dx

dx integral (evenly spaced points) = dr integral (exponential scaled points).

Code:

n   Simpson's rule: ∫ C/e^x dx, x = log(a) to log(b)
2      220230813472
4      112353290079
8       71413173487
16      63433168508
32      62625715827
64      62567118731
128     62563307380
256     62563066741
512     62563051662
1024    62563050719

[Mjim]

(01-30-2020 02:44 PM)Albert Chan Wrote:  Of course, easiest way is ∫ C/r^2 dr = -C/r + constant
With C=3.98589196e+17, and dr integral limit, a=6.371e6, b=9.4607304725808e+15

∫ (C/r^2 dr, r=a to b) = (-C/b) - (-C/a) ≈ 62563050656

Simpson's rule using your idea, we can automate it:

r = e^x → dr = e^x dx

∫ C/r^2 dr = ∫ C/e^x dx

dx integral (evenly spaced points) = dr integral (exponential scaled points).

Code:

n   Simpson's rule: ∫ C/e^x dx, x = log(a) to log(b)
2       220230813472
4       112353290079
8       71413173487
16      63433168508
32      62625715827
64      62567118731
128     62563307380
256     62563066741
512     62563051662
1024    62563050719

Many thanks for this neat little work around for calculators using the Simpson algorithm. It finally allows my humble fx-991W to return 6.25631*10^10 instead of throwing a math error (n=9 which is 2^9 = 512 divisions).

I thought I would try an even steeper exponential to see what would happen:
r = e^(x^2) -> dr = 2xe^(x^2) dx

integral(C/r^2, a, b) = integral(2Cx/e^(x^2), sqrt[ln(a)], sqrt[ln(b)] )

Code:

n
2      173988570100
4       91592348100
8       66372559190
16      62867878800
32      62583408450
64      62564344640
128     62563131870
256     62563055740
512     62563050970
1024    62563050680

It's pretty messy though compared to just e^x, though it does allow me to get an additional digit of accuracy on the fx-991W (6.256305 x 10^10). The Casio Simpson integration algorithm on the W/MS series has a built-in error bound checker which trims the digits it's unsure of. Don't really know how they do it, but it means I can trust the fx-991W Simpson integration, but not the Sharp EL-W516X Simpson integration.

I guess though if you are going through this much effort, you might as well just integrate the equation and solve it yourself, but this is a cool idea. Would love to be able to somehow automate a general algorithm on the EL-W516X, though without programability I'm not sure it is possible, and for the graphing calculators I have that can, they have Gauss-Kronrod algorithms removing much of the point of it.

[Albert Chan]

(01-31-2020 12:21 AM)Mjim Wrote:  I thought I would try an even steeper exponential to see what would happen:
r = e^(x^2) -> dr = 2xe^(x^2) dx

integral(C/r^2, a, b) = integral(2Cx/e^(x^2), sqrt[ln(a)], sqrt[ln(b)] )

How about shifting the curve, for any integrand, say f(x)

\(\int _a ^b f(x) dx = \int _1 ^{b-a+1} f(y + (a-1)) dy = \int _0 ^{\log(b-a+1)} f(e^z + (a-1)) e^z dz \)

XCas> [a, b, c] := [6.371e6, 9.4607304725808e15, 3.98589196e17]
XCas> f(r) := c/r^2
XCas> integrate(f(e^z + (a-1)) * e^z, z = 0 .. log(b-a+1))         → 62563050656.3

Try plotting this. It look like normal distribution curve !

Code:

n       simpsons
2       88521044629
4       23319253438
8       55920947081
16      66807272619
32      62510235388
64      62563085106
128     62563050656
256     62563050656
512     62563050656
1024    62563050656

[Mjim]

(01-31-2020 12:46 PM)Albert Chan Wrote:  How about shifting the curve, for any integrand, say f(x)

\(\int _a ^b f(x) dx = \int _1 ^{b-a+1} f(y + (a-1)) dy = \int _0 ^{\log(b-a+1)} f(e^z + (a-1)) e^z dz \)

XCas> [a, b, c] := [6.371e6, 9.4607304725808e15, 3.98589196e17]
XCas> f(r) := c/r^2
XCas> integrate(f(e^z + (a-1)) * e^z, z = 0 .. log(b-a+1))         → 62563050656.3

Try plotting this. It look like normal distribution curve !

Code:

n       simpsons
2       88521044629
4       23319253438
8       55920947081
16      66807272619
32      62510235388
64      62563085106
128     62563050656
256     62563050656
512     62563050656
1024    62563050656

It took me a bit of time to see why what you did resulted in a much better result. Looks like a pretty good fit for this equation, and I'm guessing any big number integral where you have a sharp downward slope near the start.

I found this pretty educational, so thanks for the work you did!

My fx-CG50 got it's first real usage since purchasing it December last year:


Just if anyone else is interested (and also to help myself process it a bit better), this is my take on why these changes Albert made worked so well.

First the graphs don't look like what you expect (well the 2nd one especially), because Albert used substitution of the integral to turn the x-axis logarithmic instead of linear. Both of these graphs give a much better result than the original equation, but I'll look at why I think the 2nd log equation does much better than the 1st log equation.

The shaded areas represent the energy required to lift a 1000kg mass from the surface of the earth to 2 radius's out (0 -> 6371km above the surface), assuming a really simple model with no atmosphere or any other forces aside from the gravity of earth. If we were to shade the pink graph in fully and the green graph from 15.667 to the end, this would represent the energy needed to move that mass ~ 1 light year.

The green shaded area represents the e^x integral substitution without shifting the equation, while the pink shaded area represents the e^x integral substitution after first shifting the graph to the left so that 0 represents being on the surface, rather than 6,371km (Earth's radius).

As can be seen shifting the graph results in a normal distribution looking curve, but as a nice benefit the pink area, is spread out over a much larger domain (0 -> 15.667), than the same area of green (15.667 -> 16.36), meaning that more Simpson integration divisions cover the same amount of area on pink, improving the algorithms accuracy with this problematic equation.

I *think* that the big change in the pink (aka shifted) graph is mostly due to moving the earths radius (equivalent to e^15.667) into the denominator and squaring it. Since we are starting at 0, e^x starts at 1 initially. This makes the denominator much larger and so the output from this equation is much smaller than the green graph (which goes well above and out of view of what is shown here). By the time you get to ~20 on the x-axis (or a bit further than the moon), the e^15.667 that is squared is no longer a significant contributor in the denominator compared to e^x squared, so we see both graphs become more and more similar towards the end.

From this you can see why this equation is a problem for the Simpson method of integration used in the Sharp. Most of the energy is needed during a very small portion of the overall distance, and so using the Simpson algorithm results in a very low accuracy if we use say, 512 divisions over 1 light year, which equates to a single division being used to cover the distance travelled from the surface of the earth to ~3x the distance of Pluto, leading to those crazy figures that were many magnitudes off, as seen on some of the earlier posts in this thread.

Both equations integrate to around 36/37 (this is the natural log of 1 light year in metres), the reason there isn't much variation at the end is that subtracting the earth's radius and adding 1 metre doesn't make much of a dent on 1 light year.

The shifted equation though starts at 0 though instead of 15.667 (natural log of earths radius). Technically you are spreading the divisions used for the Simpson algorithm over nearly twice the integration length, but it appears to me likely that if you were to squash that area into the same integration length as the first green area equation, the peak would still only probably reach about half the height of the non-shifted equation, and the area would still be better distributed.

I'm still not quite sure exactly how it all fits together, this is just my own explanation to myself of what is happening, so errors are expected as well as mistakes and misinterpretations!

[Albert Chan]

(02-01-2020 12:20 PM)Mjim Wrote:  The shifted equation though starts at 0 though instead of 15.667 (natural log of earths radius). Technically you are spreading the divisions used for the Simpson algorithm over nearly twice the integration length, but it appears to me likely that if you were to squash that area into the same integration length as the first green area equation, the peak would still only probably reach about half the height of the non-shifted equation, and the area would still be better distributed.

"Integration length" does not matter. Only the shape of curve matters.
In other words, with the same shape, scaling does nothing to area convergence.

For fair comparison, we should normalize the plots with same base, say 0 to 1.

\(\int _a ^b f(x) dx = \int _0 ^1 (b-a) f(a + (b-a)x) dx \)

XCas> t(f, low, high) := (high-low) * f(low + x*(high-low))
XCas> t1 := t(x -> c/e^x, log(a), log(b))
XCas> t2 := t(x -> c*e^x / (e^x+a-1)^2, 0, log(b-a+1))
XCas> [a, b, c] := [6.371e6, 9.4607304725808e15, 3.98589196e17]
XCas> plot([t1,t2], x=0..1, color=[green, magenta])

If done correctly, both curve plots should have the same area.

My guess t2 converge faster is because it is flatter, curve get better quadratic fit.

[Mjim]

(02-01-2020 09:38 PM)Albert Chan Wrote:  "Integration length" does not matter. Only the shape of curve matters.
In other words, with the same shape, scaling does nothing to area convergence.

I guess what I was trying to get at was that the newer pink graph would still require a bigger change in x to cover the same area as green (that was what I was trying to show in the first picture), so you would have the same area spread over more Simpson divisions which should improve the accuracy.

Though the scaling thing you mentioned is something I wasn't aware of until you bought it up. After a few tests on the Sharp (\(\large e^\frac{x}{2}, e^{10x} \) and the normalized versions) I can see what you mean. Stretching, compressing or normalizing the graph doesn't change the algorithm accuracy at all. That came as a surprise, though makes more sense now seeing as the Simpson n-divisions still have the exact same portion of the graph regardless of the scaling on the x-axis.

Anyway, I appreciate the correction, I'll need to figure out what to do with the original post, or just mark the bits that are wrong or not clear.

(02-01-2020 09:38 PM)Albert Chan Wrote:  For fair comparison, we should normalize the plots with same base, say 0 to 1.

\(\int _a ^b f(x) dx = \int _0 ^1 (b-a) f(a + (b-a)x) dx \)

XCas> t(f, low, high) := (high-low) * f(low + x*(high-low))
XCas> t1 := t(x -> c/e^x, log(a), log(b))
XCas> t2 := t(x -> c*e^x / (e^x+a-1)^2, 0, log(b-a+1))
XCas> [a, b, c] := [6.371e6, 9.4607304725808e15, 3.98589196e17]
XCas> plot([t1,t2], x=0..1, color=[green, magenta])

If done correctly, both curve plots should have the same area.

My guess t2 converge faster is because it is flatter, curve get better quadratic fit.

I'm trying out that forum mathprint here after looking at your posts

Variables:
\(a = 6.371*10^{6} m \)

\(b = 9.4607304725808*10^{15} m \)

\(C = 3.98589196*10^{17} \frac{kg*m^3}{s^2} (1000kg*Earths.mass*Gravity.constant ) \)

Original equation: \(\large \int_a^b \frac{C}{r^2} dr \)

1st log scale version: \(\large \int_{ln(a)}^{ln(b)} \frac{C}{e^x} dx \)

2nd (shifted) log scale version: \(\large \int_{0}^{ln(b-a+1)} \frac{C*e^x}{(e^x+(a-1))^2} dx \)

Normalized versions:

Original: \(\large \int_0^1 \frac{C(b-a)}{(a+z(b-a))^2} dz \)

1st log scale version: \(\large \int_{0}^{1} \frac{C(ln(b)-ln(a))}{e^{ln(a)+z(ln(b)-ln(a))}} dz \)

2nd (shifted) log scale version: \(\large \int_{0}^{1} \frac{C*ln(b-a+1)*e^{z*ln(b-a+1)}}{(e^{z*ln(b-a+1)}+(a-1))^2} dz \)

And here is the normalized graphs for the original equation, and the 1st and 2nd log versions (yeah, the first equation (black line) is a super thin and very tall):

Since the height of the normalized original equation can't be seen, I got it's numerical value of the peak from x=0, which you can see at the bottom.

When placing the graphs like this, it still looks like the red graph (shifted & normalized) has its area a bit better spread out (which I think will still help a bit with the number of Simpson divisions required to converge), though with how quickly your second equation converges, it does makes sense that the quadratic curves used in the Simpson algorithm may fit the second graph a lot better, meaning less Simpson divisions are required to get similar accuracy.

If it seems like I'm finding this more interesting than expected, it is because I'm still learning, so it's all pretty new (I'm only a small way through Calculus 2). I didn't know how to normalize integrals until you showed me how to...and as a result I have a better understanding of what is actually meant by "normalizing".

Thanks once again for your input!

[Albert Chan]

From the plot, it is hard to tell which converge area faster.
(assuming we do not know the simpson numbers ahead of time)

I tried a u-transformed t1 (blue curve), and compare against t2 (red curve).
u-transformed t1 is both flatter and wider then t2, yet simpsons converge slower.

To apply u-transformation to integral, keeping integral limit from 0 to 1, use this:

\(\int _0 ^ 1 f(x) dx = \int _0 ^1 6u(1-u) f(u^2(3-2u))du \)

My revised guess is bell-shaped curve accelerated convergence.

Think Trapezoids.
Note: Simpson's rule is trapezoids with corrections, S_2n = T_2n + (T_2n-T_n)/3

Bell-shaped curve have inflection point at µ ± σ
Within this region, trapezoids will under-estimate area
Outside this region, trapezoids will over-estimate area.
Summing all trapezoids will thus suppress overall errors.

If the guess is right, all we needed is half a bell curve.
Instead of shifting all the way to 1, say the shift is k

\(\large \int _a ^ b {c \over r^2} dr = \int _{\log(a-k)} ^{\log(b-k)} {c\;e^x \over (e^x + k)^2} dx\)

Solve for k so that integrand at x=log(a-k) is flat.

XCas> s := numer(diff(c*e^x/(e^x+k)^2))     → (-c)*exp(x)^2+c*k*exp(x)
XCas> x := log(a-k)
XCas> solve(s=0, k)                                       → [a/2, a]

Since x=log(a-a) = -∞, we have k=a/2

Here is the trapezoid and simpson numbers for k=a/2
It converge so fast that 64 intervals have both numbers converged !

Code:

n       trapezoids       simspons 
2     170601681322   113751147000
4      88198771695    60731135152
8      63864757960    55753420048
16     62564915758    62131635024
32     62563050657    62562428956
64     62563050656    62563050656

Due to error cancellations, trapezoids numbers actually converge slightly faster