I explained in your last question. NO. You cannot force trapz to give you higher precision. As for trapz giving 30% error here? FLAT OUT WRONG. PERIOD.
If your function is really that smooth and well-behaved, then trapz will not be in that much error.
So your data is pretty uniformly spaced in x, but not perfectly so.
If you think the integral is something significantly different from this:
then however else you have computed the integral is simply wrong.
I'm sorry, but the area under that curve is quite close to 0.2996 (and stuff). It is not 30% different from that.
Of course, if your fuction has a spike in it somewhere, essentially a delta function between two of the data points, that is so narrow that your data does not show the spike, then this is simply fact.
Is this a question of double precision accuracy? Since your data is entirely positive, there is no issue of subtractive cancellation.
Can we do the integration using high precision arithmetic? Well, yes, we could. But the fact is,
So anything you add to y(1) that is less than eps(y(1)) is meaningless.
Is this a problem of the integration does not use those really small values of y? Um, not really. For example, we could do it in 100 decimal digits of precision. I could do that using syms and vpa, but since I wrote HPF, I'll use that facility, as I know exactly what it is doing. You can download HPF from the file exchange for free.
Of course, since we started with double precision numbers, the result will really be little better than trapz.
dx = hx(2:end) - hx(1:end-1);
Now compute a trapezoidal rule. This is trivial to do, as...
sum((hy(1:end-1) + hy(2:end)) .* dx)/2
This computation really is a trapzeoidal rule, done fully in 100 decimal digits of precision. So the high precision tapezoidal rule, done in 100 decimal digits of precision agrees with trapz down to the last few digits reported. Remember, trapz gave us...
One problem is, the values in the vectors x and y have only been stored to essentially 16 significant digits. We cannot get higher precision than that. Yes I suppose I could use a higher order Newton-Cotes rule. Do I really need to do so here? We won't gain that much at all, because your numbers were stored only to roughly 16 digits of precsion.
But you are telling us this result is in error by 30%? I'm sorry, but I'll claim that is flat out wrong. How do you assert that as fact?
I will say that when you do this:
f1 = griddedInterpolant(x,y);
this is a PURELY linear interpolant. As such, any integral based on that can be no better than trapz. And if you just use integral, that forgets you need to set the tolerance. So part of your problem lies in a lack of nderstanding of numerical methods. (I'm sorry, but this is clear.)
We could try this:
f = griddedInterpolant(x,y,'spline');
Here I have forced griddedInterpolant to be a spline. Then I cranked down on the tolerance. The result? A minor difference in the last decimal digit reported from that of a direct integral of a spline interpolant.
So I'm sorry, but to claim that the true integral is 30% different from this value is pure silliness. (I really want to call it worse than that, but I won't.) If you want to claim that the last significant digit or two may be in error, go ahead. But to do better, you need to have a better way to store these numbers than double precision. It still won't help a lot.
If you show HOW the number were computed, then I might be able to suggest using a tool like HPF to compute the integral in slightly better ways, by computing y directly in a high precision form.
But now please stop posting this same question repeatedly.