Strange plot2d behaviour



> When I give the command
> plot2d([f(x),g(x)],[x,-2,2]);
> (where f and g are well defined functions) then the plot is 
> draw nicely, just as I want it. But when I go back to my
> original command and change it to
> plot2d([f(x),g(x)],[x,-0.5,1]);
> it does not work at all (and in fact it seems that Maxima 
> does not work any more).

I'm not able to reproduce the problem.  Could you please give us fuller
information on it?  In particular, what are the definitions of f and g?
What version of Maxima are you running (use build_info() )?

Thanks,

      -s

PS You may find the following guidelines on bug reporting useful.  They
are part of the Maxima FAQ
(http://glue.umd.edu/~milgram/maxima/faq.html).

6.2. What's the preferred way to report bugs? 
Bugs should be entered directly into the bug database at
https://sourceforge.net/tracker/?group_id=4933&atid=104933. This is a
better way of tracking them than reporting them to the mailing list. If
of course you'd like to discuss some issue, then mailing to the list is
useful. 

The cgi interface to the bug database will allow you to submit files
that may be useful in documenting the problem. 

A basic bug report includes enough information to reproduce the problem,
including the version information given by bug_report(). 

A fuller, better better bug report includes: 

A good title summarizing the problem. 
A clear procedure for reproducing the problem. Please verify that your
procedure actually re-creates the problem in a fresh Maxima. If you
can't reproduce it, still file it, but try to include as much
information about what you did before. The simpler and shorter the
procedure, the better. It's always appreciated when the discoverer of a
bug narrows it down to a simple case. Differentials are always good, too
-- that is, cases which are almost the same but DO work. 
If it's not completely obvious, an explanation of why this is the wrong
answer and what the right answer is. 
The exact version number you're running under, as shown by bug_report().

A brief statement of why it's important to solve this problem (to help
prioritize maintenance work), e.g. "almost every user will run into this
insidious bug sooner or later and lose all his work" or "this bug keeps
my group from using Maxima, since this class of matrix is ubiquitous in
population genetics" or "the workaround is fine for now" or "this is an
artifically constructed case, and I'm pretty sure that it will never
affect an ordinary user" (though often bugs in complicated cases turn
out to show up in simple cases as well). 
If you have a work-around (a procedure for avoiding the problem) or a
patch (code to fix the problem), that's nice, but not essential. If you
have a patch, put FIX in the title of the bug report so that maintainers
can incorporate it quickly. 
Some problems may not be bugs, but functional limitations. In this case,
it's interesting to know what other systems do, notably commercial
Macsyma. If you know why this limitation might be there, say so ("Kratov
theory says that this problem is intractable in general"). Also
interesting if you know an algorithm for handling them e.g. "the ODE
package doesn't handle the seventh-order triexponential case, but muPad
29.23 does; I believe the modified Phuoc-Ma`fuz method as implemented by
Odibwa (J.Sym.Alg. 23:5:230) handles this correctly". Even better,
"...and I am implementing it for Maxima 6.0" :-) . 

- Stavros Macrakis