plotting problem with trigonometric functions

I'm opposed to it too. I don;t like trying very to work around
other people's problems, and I don't like throwing away information.

Incidentally I got latest Gnuplot from CVS (version 4.7 to be)
and it doesn't have this problem. Instead I get a warning about
"range too small for machine precision" or something like that,
which seems appropriate, and a graph is drawn.

best,
Robert Dodier

On 3/15/12, Raymond Toy <toy.raymond at gmail.com> wrote:
> On Wed, Mar 14, 2012 at 12:46 PM, Jaime Villate <villate at fe.up.pt> wrote:
>
>> On 03/14/2012 04:50 PM, Raymond Toy wrote:
>>
>>> Hmm.  I see a similar thing, but it's not maxima.  Maxima returns almost
>>> instantly, but gnuplot is sucking up 100% cpu plotting a (mostly)
>>> constant.
>>>  Not sure why that is because plot2d(1,[x,-1,1]) brings up a plot
>>> instantly.
>>>
>>> So it's not a maxima problem per se.
>>>
>> Right.
>> plot2d(sec(x)*cos(x),[x,-1,1],**[plot_format,xmaxima]) works fine.
>>
>> But even being a Gnuplot issue, this suggests that we could use something
>> such as fpprintprec: 14
>> when creating the data file for Gnuplot. In any case no graphic display
>> will be able to use more than 14 digits for a plot (I think!).
>>
>
> That's true, but consider this particular example.  sec(x)*cos(x) isn't
> always exactly 1 because of numerical issues in computing sec and cos.
> Sometimes it's nice to be able to see that in a plot.  If you make maxima
> only print 14 digits, this difference goes a way.  (Yes, it might be better
> to plot sec(x)*cos(x)-1, but that adds yet another round-off.)
>
>
>>
>> Is anyone against that I go ahead and do  such change in plot2d?
>>
>
> So, I guess I'm (slightly) opposed to this change.  It's definitely not a
> maxima problem, and we should let the gnuplot folks know about it.  Or
> recommend a version of gnuplot that doesn't seem to have this problem (if
> possible).
>
> Ray
>