Richard Hennessy | 1 Sep 2009 01:23
Picon

Re: unit_step

pw.mac can do this type of problem.  You can get it free from this site.  http://mysite.verizon.net/res11w2yb/id2.html


Rich


On Sun, Aug 23, 2009 at 10:14 AM, Bill Maier <shufflesky <at> hotmail.com> wrote:
Is there a way to get integrate() to work with unit_step()? For example, I can't get this integral to evaluate:
 
pulse(t,t0,t1):= unit_step(t-t0) - unit_step(t-t1);
integrate((t^2)*pulse(t,1,2),t,0,4);
 
Bill Maier
 

Get back to school stuff for them and cashback for you. Try BingT now.

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima


_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Žiga Lenarčič | 1 Sep 2009 12:25
Picon

Re: Comments about FFT PATCH ready


On Aug 31, 2009, at 4:58 PM, Raymond Toy wrote:
>>
>> I'm concerned about the speed of fft on GCL - particularly, does GCL
>> (on windows) compile the code that is loaded with 'load(fft);' in
>> Maxima? Otherwise all 'optimizations' are rather pointless for the  
>> 90%
>> of userbase that runs GCL on Windows.
> load does not normally compile anything.  So it will be rather slow.
>
> Ray
>

Perhaps fft should compile automatically on first load like lapack?  
It's seems reasonable since it's numerical code. Users shouldn't be  
troubled with 'manual' compilation.

Thanks for looking at it.

Regards,
Ziga
Alejandro Jakubi | 1 Sep 2009 01:22
Picon

the argument simp:false

The examples for 'tellsimp' in the manual include the statement

ev (tellsimp (0^0, 1), simp: false);

I am intrigued about this form of argument "simp: false".

The description for the arguments in an 'ev' function call say about
'simp':

"simp causes expr to be simplified regardless of the setting of the switch simp
which inhibits simplification if false."

and I interpret this sentence as describing a situation like:

(%i2) simp : false$
(%i3) ev(1 + 1, simp);
(%o3)         2

rather than the previous one.

So, I wonder whether this argument "simp: false" is undocumented. If so, in
what cases does it work?, meaning, I guess, evaluate but avoiding automatic
simplification. I find that such an option, if available, could be useful
occasionally.

Alejandro Jakubi
Raymond Toy | 1 Sep 2009 15:12

Re: Comments about FFT PATCH ready

Žiga Lenarčič wrote:
>
> On Aug 31, 2009, at 4:58 PM, Raymond Toy wrote:
>>>
>>> I'm concerned about the speed of fft on GCL - particularly, does GCL
>>> (on windows) compile the code that is loaded with 'load(fft);' in
>>> Maxima? Otherwise all 'optimizations' are rather pointless for the 90%
>>> of userbase that runs GCL on Windows.
>> load does not normally compile anything.  So it will be rather slow.
>>
>> Ray
>>
>
> Perhaps fft should compile automatically on first load like lapack?
> It's seems reasonable since it's numerical code. Users shouldn't be
> troubled with 'manual' compilation.
>
Yes, that's probably a good idea.  I certainly expect fft to be
reasonably fast.

Ray

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Stavros Macrakis | 1 Sep 2009 16:32
Picon
Favicon
Gravatar

Re: the argument simp:false

ev is a rather confusing routine, and I won't claim to describe it in detail.  But in brief, in ev(..., XXX), the XXX may be:

* a symbol
**  with a special interpretation (noeval, nouns, expand, ...)
** a variable name with the evflags property, in which case it is bound to true (simp, float, exponentialize, ...)
** a function name, in which case that function is de-nounified within the expression (diff, sum, ...)
** another symbol, in which case it is evaluated; its value should be a list, which is treated as arguments to ev
* an assignment or equation (a:3 or a=3), in which case that variable is bound locally to that value
* a function definition, in which case that function is bound locally to that definition

So
   ev( ..., simp) is equivalent to ev( ..., simp:true), which is (roughly) equivalent to block([simp:true], ...)

and
   ev( ..., simp:false) is (roughly) equivalent to block([simp:false], ...)

This is all documented in ? ev, though the documentation may be hard to understand.

Recall that the *value* of the ev expression will be simplified with the value of simp *outside* the ev expression.

For example:

        print( ev(  print( 1 + 1 ), simp: false ));

prints

        1 + 1               the unsimplified inner result
        2                     gets simplified when ev returns its value

Hope this helps.

            -s

On Mon, Aug 31, 2009 at 7:22 PM, Alejandro Jakubi <jakubi <at> df.uba.ar> wrote:
The examples for 'tellsimp' in the manual include the statement

ev (tellsimp (0^0, 1), simp: false);

I am intrigued about this form of argument "simp: false".

The description for the arguments in an 'ev' function call say about
'simp':

"simp causes expr to be simplified regardless of the setting of the switch simp
which inhibits simplification if false."

and I interpret this sentence as describing a situation like:

(%i2) simp : false$
(%i3) ev(1 + 1, simp);
(%o3)         2

rather than the previous one.

So, I wonder whether this argument "simp: false" is undocumented. If so, in
what cases does it work?, meaning, I guess, evaluate but avoiding automatic
simplification. I find that such an option, if available, could be useful
occasionally.

Alejandro Jakubi












_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Robert Dodier | 1 Sep 2009 17:40
Picon

Re: the argument simp:false

On Mon, Aug 31, 2009 at 5:22 PM, Alejandro Jakubi<jakubi <at> df.uba.ar> wrote:

> The examples for 'tellsimp' in the manual include the statement
>
> ev (tellsimp (0^0, 1), simp: false);

That example unnecessarily introduces a question about ev,
which is something of a mess ... it would be simpler to understand
like this:

(%i2) simp:false;
(%o2)                                false
(%i3)  tellsimp (0^0, 1);
(%o3)                         [^rule1, simpexpt]
(%i4) simp:true;
(%o4)                                true
(%i5) 0^0;
(%o5)                                  1

It's often necessary to bind simp to false when constructing
simplification rules. Otherwise the existing rules can interfere
with the one you are trying to define.

> "simp causes expr to be simplified regardless of the setting of the switch simp
> which inhibits simplification if false."
>
> and I interpret this sentence as describing a situation like:
>
> (%i2) simp : false$
> (%i3) ev(1 + 1, simp);
> (%o3)         2
>
> rather than the previous one.

Yes, you're right.

> So, I wonder whether this argument "simp: false" is undocumented.

Well, ev(expr, foo:bar) or equivalently ev(expr, foo=bar) just means
to evaluate expr while foo is temporarily bound to bar.

Some flags (the so-called evflags; ? evflag tells about that) have the
property that ev(expr, foo) is equivalent to ev(expr, foo=true).

ev has accumulated a lot of disparate functionality over the years.

best

Robert Dodier
Stavros Macrakis | 1 Sep 2009 19:38
Picon
Favicon
Gravatar

Re: the argument simp:false

On Tue, Sep 1, 2009 at 4:24 PM, Alejandro Jakubi <jakubi <at> df.uba.ar> wrote:
However, at least in the case of 'simp', I do not find it working that way:

(%i2) simp : false$
(%i3) ev(1 + 1, simp = true);
(%o3)            2
(%i4) simp : true$
(%i5) ev(1 + 1, simp = false);
(%o5)            2

as I would have expected 1+1 in the last case.

I.e. the local binding for 'simp' does not seem to be working here the same
way as in ev(tellsimp (0^0, 1), simp: false).

Could you clarify on this point?

As I said in my previous email, the *result* of the EV is simplified again.  ev(...) returns the unsimplified expression 1+1, and then that is simplified to 2.

That is, whenever Maxima performs an evaluation, the result is simplified unless simp=false.

                -s
_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima
Robert Dodier | 1 Sep 2009 19:53
Picon

Re: the argument simp:false

On Tue, Sep 1, 2009 at 2:24 PM, Alejandro Jakubi<jakubi <at> df.uba.ar> wrote:

> I find that such a listing of the admisible syntaxes would clarify very much
> the manual section for 'ev'.

> In particular, I have not seen an explicit mention that an assignment or
> equation (foo:bar or foo=bar) are equivalent forms for a local/temporary
> binding.

Well, it's there. Just not very clear, sorry about that.

> I.e. the local binding for 'simp' does not seem to be working here the same
> way as in ev(tellsimp (0^0, 1), simp: false).
>
> Could you clarify on this point?

(%i3) trace(ev);
(%o3)                                [ev]
(%i4) ev(1+1,simp=false);
1 Enter ev [ev(1 + 1, simp = false)]
1 Exit  ev 1 + 1
(%o4)                                  2
(%i5) ev(1+1,simp=true);
1 Enter ev [ev(1 + 1, simp = true)]
1 Exit  ev 2
(%o5)                                  2

Note that when simp=false, ev indeed returns 1 + 1,
as Stavros explained.

Robert Dodier
Richard Fateman | 1 Sep 2009 19:53
Picon
Favicon

Strengthening solve

looking at making Maxima's solve program more robust, maybe along the
lines of Mathematica's Reduce, I came up with this simple problem,
solve((x-%pi)/sin(x)=0, x)

which Maxima says has the solution x=%pi,

which is (a) false in that it reduces to 0/0=0 by substitution, and
         (b) false in the limit as x->%pi, since it is then -1=0.

Mathematica 6.0 gives a warning in that a potential solution was 
"possibly discarded by verifier" and
should be check by hand. May require use of limits.  
It also warns that inverse functions are being used by Solve, and 
suggests using Reduce.

RJF
Stavros Macrakis | 1 Sep 2009 21:04
Picon
Favicon
Gravatar

Re: the argument simp:false

The following code will produce an expression that Maxima *thinks* is simplified even if it is not:

(%i1) :lisp (defun $pseudosimp (x) (cond ((atom x) x) (t (cons (append (car x) '(simp)) (cdr x)))))
(%i2) block([simp:false],pseudosimp(1+1));
(%o2)                                                                  1 + 1

If this is useful to you, fine... but remember that Maxima is not designed to work with expressions like this and may well behave in peculiar ways.  See below.

(%i9) block([simp:false],pseudosimp(x+y+1));
(%o9)                                                                1 + y + x
(%i10) block([simp:false],pseudosimp(x+y+1))-x;
(%o10)                                                                 1 + y
(%i11) block([simp:false],pseudosimp(x+y+1))-y;
(%o11)                                                                 1 + x
(%i12) block([simp:false],pseudosimp(x+y+1))-1;
(%o12)                                                             1 + y + x - 1
(%i13) block([simp:false],pseudosimp(x+y+1))-x-y;
(%o13)                                                                   1
(%i14) block([simp:false],pseudosimp(x+y+1))-x-1;
(%o14)                                                               1 + y - 1

To undo the effect of pseudosimp, use expand(XXX,1,1)

           -s

On Tue, Sep 1, 2009 at 5:32 PM, Alejandro Jakubi <jakubi <at> df.uba.ar> wrote:
Stavros and Robert

Thank you for these explanations.

Now, the real question. I understand that most commands assume that the global
flag 'simp' is set to 'true', so that in general it is safer to keep it in its
default value. However, in some particular cases, the result of the automatic
simplification on an expression is not what I may want to get. I.e. at some
steps I may like to get higher control of the computation path.

So I wonder how to keep the global 'simp' set to 'true' and preserve the
result of ev(...,simp=false) from the "outer" simplification.

Alejandro Jakubi









_______________________________________________
Maxima mailing list
Maxima <at> math.utexas.edu
http://www.math.utexas.edu/mailman/listinfo/maxima

Gmane