Even if your code seems to structured enough I have to give up in following it
(and cleaning it such that it does not write to my machine too much).

But have some suggestions.

1.
More or less 

  'Int(F(t), t=b..c)';
  Change(%, t = x*f0, x): simplify(%);
  # subs(b=20,c=2500,f0=215, %); # to see the bounds

is what is needed to simplify and for F(t) = g(t)/S(t) you may see what I mean,
in the special case g(t) = t^a it simplifies more (pulling out f0^a).

One can optimize the integrand a bit (similar to what I did) to avoid fractional
exponents (saving some computational time).

But it should be good enough to feed it to Ooura's integrator directly.

2.
You seem to use 'simplify' after you provided *floating point* values. This is
not a good idea, if not done carefully (it can result in extreme magnitudes),
I would avoid it in those cases if not being sure.


This way you _may_ avoid calling the integrator several times for each summand,
which would be quite expensive (may be only for t^a for large a ?).

But as said I did not follow you code in detail [please do not send me some
blackboard or video instead :-) ].

Even if your code seems to structured enough I have to give up in following it
(and cleaning it such that it does not write to my machine too much).

But have some suggestions.

1.
More or less 

  'Int(F(t), t=b..c)';
  Change(%, t = x*f0, x): simplify(%);
  # subs(b=20,c=2500,f0=215, %); # to see the bounds

is what is needed to simplify and for F(t) = g(t)/S(t) you may see what I mean,
in the special case g(t) = t^a it simplifies more (pulling out f0^a).

One can optimize the integrand a bit (similar to what I did) to avoid fractional
exponents (saving some computational time).

But it should be good enough to feed it to Ooura's integrator directly.

2.
You seem to use 'simplify' after you provided *floating point* values. This is
not a good idea, if not done carefully (it can result in extreme magnitudes),
I would avoid it in those cases if not being sure.


This way you _may_ avoid calling the integrator several times for each summand,
which would be quite expensive (may be only for t^a for large a ?).

But as said I did not follow you code in detail [please do not send me some
blackboard or video instead :-) ].

Salvo,

more or less I understand, but miss the blackboard ...

If I understand it correct, then finally you have a sum as integrand (not quite clear
whether the integration bounds are the same).

One could do the following (have no Maple here, but essentially it should work):

expr;                 # = your sum(mands)
[op(expr)];           # if it is a sum, then this is the list of summands
map( integrator, % ); # apply the integration to each
convert(%, `+`);      # adding them

If the bounds are all the same then one should be able to use the integrator for all
the summands without decomposing.

May be you can upload a sheet containing the very task?

Salvo,

more or less I understand, but miss the blackboard ...

If I understand it correct, then finally you have a sum as integrand (not quite clear
whether the integration bounds are the same).

One could do the following (have no Maple here, but essentially it should work):

expr;                 # = your sum(mands)
[op(expr)];           # if it is a sum, then this is the list of summands
map( integrator, % ); # apply the integration to each
convert(%, `+`);      # adding them

If the bounds are all the same then one should be able to use the integrator for all
the summands without decomposing.

May be you can upload a sheet containing the very task?

Thank you for nailing it down (have not seen it ...)

Thank you for nailing it down (have not seen it ...)

The short answer is "no, it is just you using floats and ignoring periodics"

The correct answer might be "such an x (in the minimal real range) equals 0 and beyond comes through periodics, where floating point range reductions steps in in the non-symbolic case, which enforces inexactness in representations"

The short answer is "no, it is just you using floats and ignoring periodics"

The correct answer might be "such an x (in the minimal real range) equals 0 and beyond comes through periodics, where floating point range reductions steps in in the non-symbolic case, which enforces inexactness in representations"

Here it means 100 times the 'unit of the last place', so it is just to say:
up to the last 2 decimal places.

May be the following makes it a bit understandable:

  Digits:=10:
  tan(sqrt(2)*Pi): y0:=evalf(%):

  'tan(x)=y0';   # set up an equation
  x0:=solve(%);  # solve it

                          y0 := 3.620218565

                             tan(x) = y0

                          x0 := 1.301290284

Now check that:

  'verify'(tan(x0),y0,float(2));
  %;
              verify(3.620218559, 3.620218565, float(2))

                          [false, 6., ulps ]

I asked to compare up to 2 ulps, Maple says 'no, not true, they differ
by 6 ulps' ...565 - ...559 = 6.

You also may check the help on the command.


PS: pagan, thx for remembering that command ...

Here it means 100 times the 'unit of the last place', so it is just to say:
up to the last 2 decimal places.

May be the following makes it a bit understandable:

  Digits:=10:
  tan(sqrt(2)*Pi): y0:=evalf(%):

  'tan(x)=y0';   # set up an equation
  x0:=solve(%);  # solve it

                          y0 := 3.620218565

                             tan(x) = y0

                          x0 := 1.301290284

Now check that:

  'verify'(tan(x0),y0,float(2));
  %;
              verify(3.620218559, 3.620218565, float(2))

                          [false, 6., ulps ]

I asked to compare up to 2 ulps, Maple says 'no, not true, they differ
by 6 ulps' ...565 - ...559 = 6.

You also may check the help on the command.


PS: pagan, thx for remembering that command ...

As already said in the above mentioned: I would be interested to hear about it from some Maple guy ...

If one 'looks into' the DLLs (both mpfr and gmp) a lot seems to be present. Can one use it from Maple or should one look for other sources?

The (modified) original was about Int(t^a/S(t), t) where I gave some stuff.

Now you ask for variants like Int(t^2*ln(t)/S(t), t), i.e. t^a instead of
you also want t^2*ln(t) and relatives?

Is it that? If so: the integrand would be different, the method is the same
and transforming is always x = t/f0 (but have to finish now for today; let
me know, whether it is enough for working it out or if you want more input).

The (modified) original was about Int(t^a/S(t), t) where I gave some stuff.

Now you ask for variants like Int(t^2*ln(t)/S(t), t), i.e. t^a instead of
you also want t^2*ln(t) and relatives?

Is it that? If so: the integrand would be different, the method is the same
and transforming is always x = t/f0 (but have to finish now for today; let
me know, whether it is enough for working it out or if you want more input).

.

.