gnuplot-beta — Developers and beta testers of new gnuplot code

Re: changing isosamples messes pm3d ?!

[Dmitri A. S. <das...@gm...>]

On 4/10/07, Ethan A Merritt <merritt@u.washington.edu> wrote:
> On Tuesday 10 April 2007 21:49, Dmitri A. Sergatskov wrote:
> > Setting isosamples to some high numbers messes up pm3d colormap.
> >
> > Terminal type set to 'wxt'
> > gnuplot> set pm3d
> >
> > gnuplot> set isosamples 100
> > gnuplot> splot x+y
> >
> > (the plane all painted red)
>
> It is an artifact of finite line width.
> Each rectangle has a red line around it, and when the boxes become
> very small then all you can see is the bounding line.
>
> Try :
>         set pm3d
>         splot x+y linewidth 0.0001
>

Thanks. I just figured out that "unset surf" helps,
but did not come to the final solution :).

>
> --
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle 98195-7742
>

Regards,

Dmitri.

Re: changing isosamples messes pm3d ?!

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 10 April 2007 21:49, Dmitri A. Sergatskov wrote:
> Setting isosamples to some high numbers messes up pm3d colormap.
> 
> Terminal type set to 'wxt'
> gnuplot> set pm3d
> 
> gnuplot> set isosamples 100
> gnuplot> splot x+y
> 
> (the plane all painted red)

It is an artifact of finite line width.
Each rectangle has a red line around it, and when the boxes become
very small then all you can see is the bounding line.

Try :
	set pm3d
	splot x+y linewidth 0.0001


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

changing isosamples messes pm3d ?!

[Dmitri A. S. <das...@gm...>]

Setting isosamples to some high numbers messes up pm3d colormap.

G N U P L O T
        Version 4.2 patchlevel 0
        last modified March 2007
        System: Linux 2.6.20-1.2933.fc6

......

Terminal type set to 'wxt'
gnuplot> set pm3d
gnuplot> splot x+y

(nicely colored plane with colors corresponding
to the colorbar)

gnuplot> set isosamples 100
gnuplot> splot x+y

(the plane all painted red)

Perhaps I do not understand something here, but it appears to me
as a bug.

Sincerely,

Dmitri.

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Ethan M. <merritt@u.washington.edu>]

It's not clear to me that we need to make this new functionality
visible from the command line at all.  The mouse zooming can call
a new internal routine with no corresponding user command.
Let's get it working first, and only then worry about whether
it is worth adding a new user command.




On Tuesday 10 April 2007 11:33, Daniel J Sebald wrote:
> Petr Mikulik wrote:
> >>>Based on what kind of oracle are to decide that the "replot" issued for 
> >>>a plot with inline data isn't *meant* to require re-entry of all the 
> >>>data?  Or re-entry of only some of them, even?
> >>>
> >>>Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
> >>>I'm afraid I have to insist that a command doing a different job than 
> >>>"replot" used to do, be given a different name than "replot".
> > 
> > 
> > That I have proposed several times: "Replot". (Or: "redraw")
> 
> Oh, I sort of passed the capital R in the back of my mind as a typing mistake, 
> but yes gnuplot is case sensitive.  But I don't think it is a good idea to 
> introduce capital letter commands as there are currently none and it just isn't 
> very elegant.  (I just imagine one colleague saying to another "just type 
> replot; with a capital R".)  "redraw" would work better as a whole new command.
> 
> 
> >>A new option "autoreload" won't fly?  E.g.,
> >>
> >>   set autoreload off
> >>
> >>and the default is on, i.e., the current behavior?
> > 
> > 
> > set replot {reload|redraw}
> > or
> > set replot {reload|redraw} {both|pipe}
> 
> Yes, something like that.  That's good.  But {file|pipe|all} to cover all bases. 
>   (Avoid using a word like "both" because it implies two.  Who knows what the 
> future might bring?)
> 
> Dan
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>>>Based on what kind of oracle are to decide that the "replot" issued for 
>>>a plot with inline data isn't *meant* to require re-entry of all the 
>>>data?  Or re-entry of only some of them, even?
>>>
>>>Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
>>>I'm afraid I have to insist that a command doing a different job than 
>>>"replot" used to do, be given a different name than "replot".
> 
> 
> That I have proposed several times: "Replot". (Or: "redraw")

Oh, I sort of passed the capital R in the back of my mind as a typing mistake, 
but yes gnuplot is case sensitive.  But I don't think it is a good idea to 
introduce capital letter commands as there are currently none and it just isn't 
very elegant.  (I just imagine one colleague saying to another "just type 
replot; with a capital R".)  "redraw" would work better as a whole new command.


>>A new option "autoreload" won't fly?  E.g.,
>>
>>   set autoreload off
>>
>>and the default is on, i.e., the current behavior?
> 
> 
> set replot {reload|redraw}
> or
> set replot {reload|redraw} {both|pipe}

Yes, something like that.  That's good.  But {file|pipe|all} to cover all bases. 
  (Avoid using a word like "both" because it implies two.  Who knows what the 
future might bring?)

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Petr M. <mi...@mo...>]

> > Based on what kind of oracle are to decide that the "replot" issued for 
> > a plot with inline data isn't *meant* to require re-entry of all the 
> > data?  Or re-entry of only some of them, even?
> > 
> > Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
> > I'm afraid I have to insist that a command doing a different job than 
> > "replot" used to do, be given a different name than "replot".

That I have proposed several times: "Replot". (Or: "redraw")

> A new option "autoreload" won't fly?  E.g.,
> 
>    set autoreload off
> 
> and the default is on, i.e., the current behavior?

set replot {reload|redraw}
or
set replot {reload|redraw} {both|pipe}

---
PM

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
>> Will need to consider the behavior.  I think "replot" reloading 
>> regular files, e.g., 'foo.dat' is sort of convenient.  
> 
> 
> Sometimes it is.  At other times, for other usages, it may not be.  For 
> mousing, e.g., it typically isn't.  For mousing in 3D, this was changed 
> already, for just this reason.
> 
> Based on what kind of oracle are to decide that the "replot" issued for 
> a plot with inline data isn't *meant* to require re-entry of all the 
> data?  Or re-entry of only some of them, even?
> 
> Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
> I'm afraid I have to insist that a command doing a different job than 
> "replot" used to do, be given a different name than "replot".

A new option "autoreload" won't fly?  E.g.,

   set autoreload off

and the default is on, i.e., the current behavior?

Dan

Re: More efficient "dbl_raise"

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> I take that to mean you agree that we have no basis on which to say
> that dbl_raise is "better" than pow.

Other than pow() handles NaN and dbl_raise() hangs for five minutes, right.

> Therefore the comment is correct, and nothing needs to be changed.

"is this really useful?" is a comment?

Dan

Re: More efficient "dbl_raise"

[Ethan M. <merritt@u.washington.edu>]

I take that to mean you agree that we have no basis on which to say
that dbl_raise is "better" than pow.
Therefore the comment is correct, and nothing needs to be changed.
That's the end of it so far as I'm concerned.

	Ethan

On Monday 09 April 2007 16:54, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> 
> > I have no idea, because I can't for the life of me figure out what
> > the issue is here.  What problem are you trying to fix?
> > If there's no problem, just forget the whole thing.
> 
> Repeat:
> 
>  > Anyway, if we think that the dbl_raise() is the preferred route, all that need
>  > be done is remove the comment "FIXME, is this needed?" and give a short
>  > explanation why it is needed.
> 
> This will prevent anyone in the future from looking at this and asking "What 
> needs to be fixed?", i.e., the same question you are asking, "because I can't 
> for the life of me figure out what the issue is here."  That's the trap I fell in.
> 
> Dan
> 

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

Re: More efficient "dbl_raise"

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

> I have no idea, because I can't for the life of me figure out what
> the issue is here.  What problem are you trying to fix?
> If there's no problem, just forget the whole thing.

Repeat:

 > Anyway, if we think that the dbl_raise() is the preferred route, all that need
 > be done is remove the comment "FIXME, is this needed?" and give a short
 > explanation why it is needed.

This will prevent anyone in the future from looking at this and asking "What 
needs to be fixed?", i.e., the same question you are asking, "because I can't 
for the life of me figure out what the issue is here."  That's the trap I fell in.

Dan

Re: More efficient "dbl_raise"

[Ethan M. <merritt@u.washington.edu>]

On Monday 09 April 2007 16:20, Daniel J Sebald wrote:
> > It's not even a question of library functions. It's a consequence of the
> > IEEE floating point format.  Presumably you wouldn't see this on a, say,
> > a VAX if you chose one of the native double precision  representations
> > rather than IEEE. They give you the option of spending more bits on the
> > precision (mantissa) and fewer on the range (exponent).
> > Of course then you'd hit true overflow sooner.  You can't win.
> 
> So this means dbl_raise() implementation is better than pow()?

I have no idea, because I can't for the life of me figure out what
the issue is here.  What problem are you trying to fix?
If there's no problem, just forget the whole thing.

-- 
Ethan A Merritt

Re: More efficient "dbl_raise"

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Monday 09 April 2007 15:35, Daniel J Sebald wrote:
> 
>>>The real problems aren't with pow() vs. dbl_raise() --- pow() would just 
>>>fail in a different way on the [NaN:NaN] range example that re-triggered 
>>>this discussion.
>>
>>In a different way, but also an acceptable way if one looks at the result, a 
>>blank plot.  GIGO, not GIHFFM (garbage in, hang for five minutes).
> 
> 
> Could we please decouple discussion of dbl_raise() from possible
> bugs in parsing 'set xrange'?   If it bothers you that much to have 
> xrange accept NaN on input, then please submit a patch to prevent it. 

What bothers me is a FIXME that is a red herring.  Like I said, I would have 
probably just written a patch to disallow NaN in set.c.  Of course, if like you 
say there are some implementation such as VAX that aren't IEEE standard then 
will checking for a value of 'NaN' even compile on VAX systems?


>>>And that's before we consider that we have exactly zero control over the 
>>>quality of a given C compiler's math library, and thus their pow() 
>>>function.  dbl_raise() may not be the shiniest tool in the shed, but at 
>>>least it's _our_ tool.  Its behaviour may vary a good deal less from one 
>>>platform to the next than that of pow().
>>
>>Assuming the way the compiler handles floating point multiply for large overflow 
>>numbers, as Ethan described, is more consistent than the pow() function, then 
>>yes.
> 
> 
> That is *not* an overflow.  
> "Overflow" is when you exceed the range of numbers that can be represented;
> i.e. not enough bits in the exponent.
> What you are seeing is a limitation of the precision; i.e. not enough
> bits in the mantissa.

OK, mantissa overflow, i.e., precision, is what I meant.


>>On the other hand, I'm not sure it is good practice to second guess  
>>library functions without evidence of a bug.
> 
> 
> It's not even a question of library functions. It's a consequence of the
> IEEE floating point format.  Presumably you wouldn't see this on a, say,
> a VAX if you chose one of the native double precision  representations
> rather than IEEE. They give you the option of spending more bits on the
> precision (mantissa) and fewer on the range (exponent).
> Of course then you'd hit true overflow sooner.  You can't win.

So this means dbl_raise() implementation is better than pow()?

Dan

Re: More efficient "dbl_raise"

[Ethan M. <merritt@u.washington.edu>]

On Monday 09 April 2007 15:35, Daniel J Sebald wrote:
> > The real problems aren't with pow() vs. dbl_raise() --- pow() would just 
> > fail in a different way on the [NaN:NaN] range example that re-triggered 
> > this discussion.
> 
> In a different way, but also an acceptable way if one looks at the result, a 
> blank plot.  GIGO, not GIHFFM (garbage in, hang for five minutes).

Could we please decouple discussion of dbl_raise() from possible
bugs in parsing 'set xrange'?   If it bothers you that much to have 
xrange accept NaN on input, then please submit a patch to prevent it. 
 
> > And that's before we consider that we have exactly zero control over the 
> > quality of a given C compiler's math library, and thus their pow() 
> > function.  dbl_raise() may not be the shiniest tool in the shed, but at 
> > least it's _our_ tool.  Its behaviour may vary a good deal less from one 
> > platform to the next than that of pow().
> 
> Assuming the way the compiler handles floating point multiply for large overflow 
> numbers, as Ethan described, is more consistent than the pow() function, then 
> yes.

That is *not* an overflow.  
"Overflow" is when you exceed the range of numbers that can be represented;
i.e. not enough bits in the exponent.
What you are seeing is a limitation of the precision; i.e. not enough
bits in the mantissa.

> On the other hand, I'm not sure it is good practice to second guess  
> library functions without evidence of a bug.

It's not even a question of library functions. It's a consequence of the
IEEE floating point format.  Presumably you wouldn't see this on a, say,
a VAX if you chose one of the native double precision  representations
rather than IEEE. They give you the option of spending more bits on the
precision (mantissa) and fewer on the range (exponent).
Of course then you'd hit true overflow sooner.  You can't win.

-- 
Ethan A Merritt

Re: More efficient "dbl_raise"

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Bröker wrote:

>> Given gnuplot's behavior, can we come up with a comparison at the 
>> command line the reflects the behavior of C routines?  I've followed 
>> the parsing to internal.c and see that ** operator does in fact use 
>> the C library pow(,) function.
> 
> 
> It's not quite as simple as that.  f_power uses pow() (and some 
> trigonometry) for floating-point arguments, but iterated multiplication 
> for integer**integer.

Hence why I used 10.0 in the plots.


>> Very strange.  Not concrete proof, but my conjecture about not knowing 
>> which is more accurate, outright multiplying via dbl_raise() vs. 
>> pow(), does seem a pertinent question.
> 
> 
> Not really, because utmost accuracy is at most half the picture here. 
> Trying to "make sure we get exactly the right result for xnorm" is a 
> futile effort, because we a) don't need it exactly right, and b) we 
> can't get it, anyway.

I agree.


> The real problems aren't with pow() vs. dbl_raise() --- pow() would just 
> fail in a different way on the [NaN:NaN] range example that re-triggered 
> this discussion.

In a different way, but also an acceptable way if one looks at the result, a 
blank plot.  GIGO, not GIHFFM (garbage in, hang for five minutes).


>  They're with the overall result of 
> quantize_{normal|duodecimal}_tics(), for inputs that don't quite lie on 
> the integer values the users think they see, because of rounding or 
> sampling inaccuracies that took place before scaling even began.  E.g. 
> if the actual y range is [0:100+epsilon], how should the tic interval 
> and auto-extended range endpoint depend on the sign and magnitude of 
> epsilon, at small values?

This issue has come up before, as part of a bug report.  And I think I have an 
acceptable solution for that situation as part of a patch, although the belief 
seems to be that this is impossible to address.


> And that's before we consider that we have exactly zero control over the 
> quality of a given C compiler's math library, and thus their pow() 
> function.  dbl_raise() may not be the shiniest tool in the shed, but at 
> least it's _our_ tool.  Its behaviour may vary a good deal less from one 
> platform to the next than that of pow().

Assuming the way the compiler handles floating point multiply for large overflow 
numbers, as Ethan described, is more consistent than the pow() function, then 
yes.  On the other hand, I'm not sure it is good practice to second guess 
library functions without evidence of a bug.

Anyway, if we think that the dbl_raise() is the preferred route, all that need 
be done is remove the comment "FIXME, is this needed?" and give a short 
explanation why it is needed.

Dan

Re: More efficient "dbl_raise"

[<HBB...@t-...>]

Daniel J Sebald wrote:

> Note that this sampling contains both "integers" and "floats".  

Let's try and use clear terminology.  Those aren't integers, they're 
floats with integer values.  Yes, there is a difference.

> But this is not how the innards of the pow(), floor(), etc. functions work:

Again, careful of the wording.  There are two floor() functions you 
could be talking about: the gnuplot operator (standard.c:f_floor()), or 
the C standard library function.  They behave differently, because they 
take arguments of different types.  Our floor() takes actual integers or 
complex floating-point arguments, the C standard function takes doubles.

> The documentation of these C functions might say "largest integer not greater 
> than arg", but that means the math vernacular, not computer vernacular.

Which is why that's not what it says.  What the only documentation we 
can rely on, i.e. the C Standard, says about floor is (C99 7.12.9.2p2):

	The floor functions compute the largest integer value not greater than x.

The key word is "integer value".  This is not an integer, but a 
floating-point number of integer value.

> Given gnuplot's behavior, can we come up with a comparison at the command line 
> the reflects the behavior of C routines?  I've followed the parsing to 
> internal.c and see that ** operator does in fact use the C library pow(,) 
> function.

It's not quite as simple as that.  f_power uses pow() (and some 
trigonometry) for floating-point arguments, but iterated multiplication 
for integer**integer.

> Very strange.  Not concrete proof, but my conjecture about not knowing which is 
> more accurate, outright multiplying via dbl_raise() vs. pow(), does seem a 
> pertinent question.

Not really, because utmost accuracy is at most half the picture here. 
Trying to "make sure we get exactly the right result for xnorm" is a 
futile effort, because we a) don't need it exactly right, and b) we 
can't get it, anyway.

The real problems aren't with pow() vs. dbl_raise() --- pow() would just 
fail in a different way on the [NaN:NaN] range example that re-triggered 
this discussion.  They're with the overall result of 
quantize_{normal|duodecimal}_tics(), for inputs that don't quite lie on 
the integer values the users think they see, because of rounding or 
sampling inaccuracies that took place before scaling even began.  E.g. 
if the actual y range is [0:100+epsilon], how should the tic interval 
and auto-extended range endpoint depend on the sign and magnitude of 
epsilon, at small values?

And that's before we consider that we have exactly zero control over the 
quality of a given C compiler's math library, and thus their pow() 
function.  dbl_raise() may not be the shiniest tool in the shed, but at 
least it's _our_ tool.  Its behaviour may vary a good deal less from one 
platform to the next than that of pow().

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[<HBB...@t-...>]

Daniel J Sebald wrote:

> Will need to consider the behavior.  I think "replot" reloading regular files, 
> e.g., 'foo.dat' is sort of convenient.  

Sometimes it is.  At other times, for other usages, it may not be.  For 
mousing, e.g., it typically isn't.  For mousing in 3D, this was changed 
already, for just this reason.

Based on what kind of oracle are to decide that the "replot" issued for 
a plot with inline data isn't *meant* to require re-entry of all the 
data?  Or re-entry of only some of them, even?

Replot has a reasonable, well-defined and ancient meaning in gnuplot. 
I'm afraid I have to insist that a command doing a different job than 
"replot" used to do, be given a different name than "replot".

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Petr M. <mi...@mo...>]

> >>Thus, it looks like a strong demand to gnuplot developers to implement
> >>replot for "-".
> > 
> > I am looking into it, but would appreciate help.  See below in particular.
> 
> Will need to consider the behavior.  I think "replot" reloading regular files, 
> e.g., 'foo.dat' is sort of convenient.  That is, a person runs some outside app 
> to create a new set of data and then simply types "replot".  So, should it be 
> automatic reload for disk files and no automatic reload for input streams?  If 
> so, will need to have a variable indicating replot vs plot and a variable 
> indicating '-' vs. 'foo.dat'.  Or should there be some new option setting for 
> gnuplot "automatic reload off/on"?

I would like command "Replot" to replot without reloading. This command 
would be used in the hotkey and mouse management.

There could also be "set replot {no}replot" to have command replot and 
Replot (not) equivalent.


---
PM

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

>                  if (*tp_ptr)
>                      this_plot = *tp_ptr;
>                      *tp_ptr = NULL;
>                  else {          /* no memory malloc()'d there yet */

Ah, but can't just set *tp_ptr to NULL because it is in the list and taking it 
out of the list messes up the list.  (Hence linked-list management routines to 
make things a bit simpler.)

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

> I think you are missing the worrisome point.  The routine cp_free() works
> its way through a linked list of plots, freeing all dynamically allocated
> space as it goes.  The comment warns that this may fail if there was a call
> to int_error() while one of those dynamically allocated plot structures 
> was in the process of being filled in.  That would hypothetically leave
> invalid links in the linked list, or struct entries that are supposedly
> pointers but contain random garbage.   This really shouldn't happen if 
> everything is initialized in the correct order, but the comment suggests
> that may not be the case. 

Oh, that explains what "first_plot" means.  Also, the "first_plot" is a global. 
  Inside set.c is some strange code.  It doesn't appear to be a bug but I don't 
understand why the f_p and f_3dp had to be used.  Is there a chance cp_free() 
and sp_free() might fail?  If so, the routines shouldn't do that:

     else {
	struct curve_points *f_p = first_plot;
	struct surface_points *f_3dp = first_3dplot;

	first_plot = NULL;
	first_3dplot = NULL;
	cp_free(f_p);
	sp_free(f_3dp);

	iso_samples_1 = tsamp1;
	iso_samples_2 = tsamp2;
     }

Anyway, what I sent last time still applies but at a narrower scope.  For example:

                 if (*tp_ptr)
                     this_plot = *tp_ptr;
                 else {          /* no memory malloc()'d there yet */
                     this_plot = cp_alloc(MIN_CRV_POINTS);
                     *tp_ptr = this_plot;
                 }

"this_plot" shouldn't be moved into the list until after a success.  I.e., move 
the line *tp_ptr = this_plot to the end of the routine.  E.g. (?)

		if (this_plot)
		  cp_free(this_plot);

                 if (*tp_ptr)
                     this_plot = *tp_ptr;
                     *tp_ptr = NULL;
                 else {          /* no memory malloc()'d there yet */
                     this_plot = cp_alloc(MIN_CRV_POINTS);
                 }

		[snip]

                 *tp_ptr = this_plot;


This is a bit messy.  (Little linked-list maintenance routines are always good.) 
  But see what you can do.

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 08 April 2007 19:46, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > 
> > I have prepared and attached a patch that switches the calls to cp_free()
> > from late in the routine to the front (where the above comment now sits).
> > The comment seems to warn this will break things if there is an inconvenient
> > int_error() from the plot command.
> 
> Well, the patch could probably be moved into CVS right away as it seems like a 
> memory leak and what you've done is a fairly safe way of programming.
> It's safe right now because there is no conditional and memory is always freed
> at that point if some was assigned.

I think you are missing the worrisome point.  The routine cp_free() works
its way through a linked list of plots, freeing all dynamically allocated
space as it goes.  The comment warns that this may fail if there was a call
to int_error() while one of those dynamically allocated plot structures 
was in the process of being filled in.  That would hypothetically leave
invalid links in the linked list, or struct entries that are supposedly
pointers but contain random garbage.   This really shouldn't happen if 
everything is initialized in the correct order, but the comment suggests
that may not be the case. 
 
> But the issue with regard to replotting and retaining the plot structure with 
> data (which isn't to be reloaded) is just what the above message says.  If there 
> is a failure along the way, the plot pointer is valid, but the information in 
> the structure may not be valid.

Exactly.  But we should try to insure that cannot happen.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: More efficient "dbl_raise"

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

> Note that 2147483648.0, although a large number in absolute terms, corresponds
> to an error in the 15th decimal place of the decimal representation of 10^25.
> More to the point, that corresponds to about 50 bits of precision.
> Since double-precision IEEE format only provides 52 bits of precision in the
> mantissa, this is within one bit of the expected rounding error.
> (And that one bit may be my mistake; I'm doing this on my fingers, as it were).

Right, the example

powint(base,power) = power==0 ? 1.0 : base * powint(base,power - 1)
powdiff(base,power) = (base**power / powint(base,power)) - 1.0
set samples 61 ; plot [0:60] powdiff(10,x)

suggests that.  I guess my feeling is to not discount the pow() function off 
hand, unless someone has seen some awful implementations out there.  It is a 
standard library function, you'd think designers would put effort into its 
accuracy and users would complain otherwise.

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Sunday 08 April 2007 13:36, Petr Mikulik wrote:
> 
> 
>>octave does no longer use temporary data files but switched 
>>to inline data. That's a nice improvement. Unfortunately, gnuplot
>>ignores "replot" for plots with "-", and consequently mousing+hotkeys do
>>not work.
>>
>>Thus, it looks like a strong demand to gnuplot developers to implement
>>replot for "-". This matter was discussed recently, see below...
>>
>>Does somebody know how to implement it?
> 
> 
> I am looking into it, but would appreciate help.  See below in particular.
> 

Will need to consider the behavior.  I think "replot" reloading regular files, 
e.g., 'foo.dat' is sort of convenient.  That is, a person runs some outside app 
to create a new set of data and then simply types "replot".  So, should it be 
automatic reload for disk files and no automatic reload for input streams?  If 
so, will need to have a variable indicating replot vs plot and a variable 
indicating '-' vs. 'foo.dat'.  Or should there be some new option setting for 
gnuplot "automatic reload off/on"?


> The first thing that is needed is to change the order of allocating/freeing
> the plot structures in eval_plots().  If we are to use the previously stored
> data values, they must not be freed until an entirely new plot command 
> replaces them.  Right now the plot structures are freed immediately after
> drawing the plot.  We must change this so that they are freed only on 
> re-entry to eval_plots().   There is a comment at the head of the routine
> that suggests somebody tried this and ran into problems:
> 
>     /* Reset first_plot. This is usually done at the end of this function.
>      * If there is an error within this function, the memory is left allocated,
>      * since we cannot call cp_free if the list is incomplete. Making sure that
>      * the list structure is always valid requires some rewriting */
> 
> I have prepared and attached a patch that switches the calls to cp_free()
> from late in the routine to the front (where the above comment now sits).
> The comment seems to warn this will break things if there is an inconvenient
> int_error() from the plot command.

Well, the patch could probably be moved into CVS right away as it seems like a 
memory leak and what you've done is a fairly safe way of programming.  (BTW, 
where is first_plot assigned?  I don't see that immediately.)  It's safe right 
now because there is no conditional and memory is always freed at that point if 
some was assigned.

But the issue with regard to replotting and retaining the plot structure with 
data (which isn't to be reloaded) is just what the above message says.  If there 
is a failure along the way, the plot pointer is valid, but the information in 
the structure may not be valid.

Eventually there will be a conditional along the way like "if replot don't free 
memory, but if plot then free memory".  So, I would suggest a couple pointers 
here, one a "temporary" pointer (first_plot_temp) but still static, and one a 
static global pointer (first_plot).  Something like (haven't though this through 
and I'm not really what exactly "first_plot" means, but it should get the 
concept across):

   if (first_plot && auto_reload) {
     cp_free(first_plot);
     first_plot = NULL;
   }

   if (!first_plot)

     if (first_plot_temp) {
       cp_free(first_plot_temp);
       first_plot_temp = NULL;
     }

     [snip, get_data()?]

     first_plot = first_plot_temp;
     first_plot_temp = NULL;
   }

Dan

Re: gnuplot zoom not functioning anymore in octave 2.9.10

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 08 April 2007 13:36, Petr Mikulik wrote:

> octave does no longer use temporary data files but switched 
> to inline data. That's a nice improvement. Unfortunately, gnuplot
> ignores "replot" for plots with "-", and consequently mousing+hotkeys do
> not work.
> 
> Thus, it looks like a strong demand to gnuplot developers to implement
> replot for "-". This matter was discussed recently, see below...
>
> Does somebody know how to implement it?

I am looking into it, but would appreciate help.  See below in particular.

The first thing that is needed is to change the order of allocating/freeing
the plot structures in eval_plots().  If we are to use the previously stored
data values, they must not be freed until an entirely new plot command 
replaces them.  Right now the plot structures are freed immediately after
drawing the plot.  We must change this so that they are freed only on 
re-entry to eval_plots().   There is a comment at the head of the routine
that suggests somebody tried this and ran into problems:

    /* Reset first_plot. This is usually done at the end of this function.
     * If there is an error within this function, the memory is left allocated,
     * since we cannot call cp_free if the list is incomplete. Making sure that
     * the list structure is always valid requires some rewriting */

I have prepared and attached a patch that switches the calls to cp_free()
from late in the routine to the front (where the above comment now sits).
The comment seems to warn this will break things if there is an inconvenient
int_error() from the plot command.

==>   Everyone please apply the attached patch, then try to find and
==>   document any error cases so that we can fix them.   

Once the revised code in eval_plots() is stable again, we can experiment with
adding a short-cut path that calls eval_plots() directory without re-parsing
the command line and re-reading all the data.

	Ethan




> 
> Thu, 15 Mar 2007, gnuplot-beta <gnu...@li...>
> 
> > > Furthermore, it would be possible to do a more efficient job
> > > of "replot" in the core code that would benefit all terminals.
> > > Perhaps I am overlooking something, but I don't see any hard
> > > requirement to re-read the original data from a file on each
> > > replot command.  Yes, this is sometimes exactly what you want
> > > because you know the data has changed.  But more often you
> > > just want to redraw the plot with a different plot option,
> > > or zoom or view angle.  In these cases there should be enough,
> > > or almost enough, information already stored in the data structures
> > > from the previous plot.  Why re-read the data file when it is
> > > just storing the same information all over again?  This would in
> > > particular be of  plot '-', where it is very annoying to type in
> > > the same data all over again.
> >
> > Mousing in 3D -- rotating by mouse -- does not reread the data, but
> > uses those in the memory. It would be useful for those "-" to do the
> > same.
> >
> > Thus there could be two replots, e.g. replot and Replot, where the
> > second would not reread the data from disk.
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

gnuplot zoom not functioning anymore in octave 2.9.10

[Petr M. <mi...@ph...>]

Thread: www.cae.wisc.edu/pipermail/help-octave/2007-April/003542.html

>Wed Apr 4 09:33:03 CDT 2007
>| until version 2.9.9, it was possible to enable zoom with the
>| "set mouse" command (e.g. in ~/.gnuplot). After changing to
>| version 2.9.10, this does not function anymore.
>
>It still works for me with gnuplot 4.0.
>
>With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots
>does not work for me when gnuplot is called from Octave.  It does work
>when I run gnuplot directly.  I don't know what the proper fix is.  In
>any case, the changes you make with the mouse will still not be
>reflected in the axes settings seen by Octave as the communication
>with gnuplot is still a simple one way pipe.

I had a look what octave 2.9.10 is doing by:

        octave> gnuplot_binary('tee a.log | gnuplot');

and there appears:

plot "-" using ($1):($2) title "" with lines linestyle 1;
-20 -20
-19 -19
-18 -18

Therefrom, octave does no longer use temporary data files but switched
to inline data. That's a nice improvement. Unfortunately, gnuplot
ignores "replot" for plots with "-", and consequently mousing+hotkeys do
not work.

Thus, it looks like a strong demand to gnuplot developers to implement
replot for "-". This matter was discussed recently, see below...

Note: 3D plots, e.g.
        octave> mesh(hilb(9))
which produces
        splot "-" using ($1):($2):($3) title "" with line palette;
        1 1 1
        1 2 2
can be rotated by mouse, because gnuplot reuses the loaded 3D data in
this case (no reload -- fast rotation); but hotkeys relying on replot do
not work again.

Does somebody know how to implement it?

---
PM

*********

Thu, 15 Mar 2007, gnuplot-beta <gnu...@li...>

> > Furthermore, it would be possible to do a more efficient job
> > of "replot" in the core code that would benefit all terminals.
> > Perhaps I am overlooking something, but I don't see any hard
> > requirement to re-read the original data from a file on each
> > replot command.  Yes, this is sometimes exactly what you want
> > because you know the data has changed.  But more often you
> > just want to redraw the plot with a different plot option,
> > or zoom or view angle.  In these cases there should be enough,
> > or almost enough, information already stored in the data structures
> > from the previous plot.  Why re-read the data file when it is
> > just storing the same information all over again?  This would in
> > particular be of  plot '-', where it is very annoying to type in
> > the same data all over again.
>
> Mousing in 3D -- rotating by mouse -- does not reread the data, but
> uses those in the memory. It would be useful for those "-" to do the
> same.
>
> Thus there could be two replots, e.g. replot and Replot, where the
> second would not reread the data from disk.

gnuplot zoom not functioning anymore in octave 2.9.10

[Petr M. <mi...@ph...>]

Thread: www.cae.wisc.edu/pipermail/help-octave/2007-April/003542.html

>Wed Apr 4 09:33:03 CDT 2007
>| until version 2.9.9, it was possible to enable zoom with the
>| "set mouse" command (e.g. in ~/.gnuplot). After changing to
>| version 2.9.10, this does not function anymore.
>
>It still works for me with gnuplot 4.0.
>
>With gnuplot 4.2 I can rotate and zoom 3d plots, but zooming 2d plots
>does not work for me when gnuplot is called from Octave.  It does work
>when I run gnuplot directly.  I don't know what the proper fix is.  In
>any case, the changes you make with the mouse will still not be
>reflected in the axes settings seen by Octave as the communication
>with gnuplot is still a simple one way pipe.

I had a look what octave 2.9.10 is doing by:

        octave> gnuplot_binary('tee a.log | gnuplot');

and there appears:

plot "-" using ($1):($2) title "" with lines linestyle 1;
-20 -20
-19 -19
-18 -18

Therefrom, octave does no longer use temporary data files but switched
to inline data. That's a nice improvement. Unfortunately, gnuplot
ignores "replot" for plots with "-", and consequently mousing+hotkeys do
not work.

Thus, it looks like a strong demand to gnuplot developers to implement
replot for "-". This matter was discussed recently, see below...

Note: 3D plots, e.g.
        octave> mesh(hilb(9))
which produces
        splot "-" using ($1):($2):($3) title "" with line palette;
        1 1 1
        1 2 2
can be rotated by mouse, because gnuplot reuses the loaded 3D data in
this case (no reload -- fast rotation); but hotkeys relying on replot do
not work again.

Does somebody know how to implement it?

---
PM

*********

Thu, 15 Mar 2007, gnuplot-beta <gnu...@li...>

> > Furthermore, it would be possible to do a more efficient job
> > of "replot" in the core code that would benefit all terminals.
> > Perhaps I am overlooking something, but I don't see any hard
> > requirement to re-read the original data from a file on each
> > replot command.  Yes, this is sometimes exactly what you want
> > because you know the data has changed.  But more often you
> > just want to redraw the plot with a different plot option,
> > or zoom or view angle.  In these cases there should be enough,
> > or almost enough, information already stored in the data structures
> > from the previous plot.  Why re-read the data file when it is
> > just storing the same information all over again?  This would in
> > particular be of  plot '-', where it is very annoying to type in
> > the same data all over again.
>
> Mousing in 3D -- rotating by mouse -- does not reread the data, but
> uses those in the memory. It would be useful for those "-" to do the
> same.
>
> Thus there could be two replots, e.g. replot and Replot, where the
> second would not reread the data from disk.
`