rhs( x = 5 );

rhs( x = 5 );

well, for me the classical is the standard (that enforced de-naming reminded me to read again old Marcuse [political]), it is a mess, but becomes a bit better if using 1D

even if I understand some (commercial) needs - no

one can not even convert those shee to classical, all the posts at the application center are spoiled by that attitude, what a shame

ok, a bit off topic ...

well, for me the classical is the standard (that enforced de-naming reminded me to read again old Marcuse [political]), it is a mess, but becomes a bit better if using 1D

even if I understand some (commercial) needs - no

one can not even convert those shee to classical, all the posts at the application center are spoiled by that attitude, what a shame

ok, a bit off topic ...

I was not aware of time[real] and can not find it in the help ... anyway:

if the condition is met, than the time almost does not change when it is satisfied next (millisecond), hence it will print ...

May be the follwoing is what you want (but I guess calling the time function slows down, except the loop is expensive itself):

  st:=trunc(time[real]()):
 `initial time`=st;
 st0:=st:
 while time[real]() < st + 6 do
   st1:=trunc(time[real]());
   if modp(st1,2)=0 and st0 < st1 then print(`current time`=st1); st0:=st1; end if
 end do:
 `final time`=trunc(time[real]());
 

                        initial time = 1229
                         current time = 1230
                         current time = 1232
                         current time = 1234
                          final time = 1235

I was not aware of time[real] and can not find it in the help ... anyway:

if the condition is met, than the time almost does not change when it is satisfied next (millisecond), hence it will print ...

May be the follwoing is what you want (but I guess calling the time function slows down, except the loop is expensive itself):

  st:=trunc(time[real]()):
 `initial time`=st;
 st0:=st:
 while time[real]() < st + 6 do
   st1:=trunc(time[real]());
   if modp(st1,2)=0 and st0 < st1 then print(`current time`=st1); st0:=st1; end if
 end do:
 `final time`=trunc(time[real]());
 

                        initial time = 1229
                         current time = 1230
                         current time = 1232
                         current time = 1234
                          final time = 1235

Sergey,

Thanks, I will try that.

Sergey,

Thanks, I will try that.

I think it just does what I said: the command prints (like lprint), but does not return a result that way.

Just try it in a sheet before

  v:=CodeGeneration[C](2*x^3,resultname = y);
  v;
  lprint(v);

The firts command assigns NULL to v. While the following may give you a start
to process the results by working with strings:

  v:=CodeGeneration[C](2*x^3,resultname = y,output=string);

  v := "y = 0.2e1 * pow(x, 0.3e1);
        "

Have not tried examples, since I have not set my IDE to use Maple.

PS: seems to me, that in the past you may have used an undocumented feature,
which can not be expected to work over releases

Sergey,

Interesting, thank you!

Since searching at that site is a mess(except using Google from out:
the link is http://www.maplesoft.com/applications/view.aspx?SID=33406

A question: it is 'Standard' interface with Maple 13 ... not all seems to work
with Maple 12 (graphics) ... do you have it in the good, classical interface
as well?

BTW: I appreciated your optimizer ...

Sergey,

Interesting, thank you!

Since searching at that site is a mess(except using Google from out:
the link is http://www.maplesoft.com/applications/view.aspx?SID=33406

A question: it is 'Standard' interface with Maple 13 ... not all seems to work
with Maple 12 (graphics) ... do you have it in the good, classical interface
as well?

BTW: I appreciated your optimizer ...

CodeGeneration[C] prints its result, not sure whether you can re-direct that into a variable holding the text string(s).

Not sure what you by RHS and LHS here ...

However you must be aware that approximating introduces errors and you have to do it carefully (or be quite sure, that nothing ugly happens). Otherwise you should have some error estimates (which may be not easy because of your polylog)

The very problem of your integral is at 0 and if you do not start there you will miss it.

So I think you should take my suggestion to start your own work, it requires certainly more than just proper handling Maple and typing in commands. I may even be that your current formulation does not admit results to be trusted in usaul double precision.

BTW: for me it is not quite clear, why the integral exist ...

Edited:

For example: the polynom in will not be a problem towards 0. But you
have expressions like 10*sin(13/10*ln(1/10*r))/r^(1/2) (to have some
readible stuff). For r ~ 0 log will go to - infinity, thus sin will be
between +1 and -1 and dividing by sqrt(r) makes it between +- infinity.
Hence exp(...) is between 0 and +infinity and will take any value there.

So you have to work out why these problems cancel out and have to make
sure that a numerical routine is not disturbed by that behaviour.
 

Not sure what you by RHS and LHS here ...

However you must be aware that approximating introduces errors and you have to do it carefully (or be quite sure, that nothing ugly happens). Otherwise you should have some error estimates (which may be not easy because of your polylog)

The very problem of your integral is at 0 and if you do not start there you will miss it.

So I think you should take my suggestion to start your own work, it requires certainly more than just proper handling Maple and typing in commands. I may even be that your current formulation does not admit results to be trusted in usaul double precision.

BTW: for me it is not quite clear, why the integral exist ...

Edited:

For example: the polynom in will not be a problem towards 0. But you
have expressions like 10*sin(13/10*ln(1/10*r))/r^(1/2) (to have some
readible stuff). For r ~ 0 log will go to - infinity, thus sin will be
between +1 and -1 and dividing by sqrt(r) makes it between +- infinity.
Hence exp(...) is between 0 and +infinity and will take any value there.

So you have to work out why these problems cancel out and have to make
sure that a numerical routine is not disturbed by that behaviour.
 

See answer at www.mapleprimes.com/forum/codeline