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

Re: 30-year time offset reading nonuniform matrix %s input

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

>> In the first case, the year is correctly set to 2013. In the second,
>> it is displayed as 2043. This seems to be a mistake in the nonuniform
>> matrix time input?
>
> This probably fixes it, but the possible consequences elsewhere are not
> certain.  At a minimum it makes all references to the year 2000 in the
> manual incorrect, since it resets the epoch boundary to 1970.

What about adding
 	set datafile epoch 2000
so that the year can be set by the user?

---
PM

Re: 30-year time offset reading nonuniform matrix %s input

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

On Wednesday, April 03, 2013 11:38:27 am Tait wrote:
> 
> Consider these two examples. First:
>   reset
>   set datafile separator ","
>   set xdata time
>   set timefmt "%s"
>   set format x "%Y-%m-%d %H:%M:%S"
>   set view 47,54
>   splot '-' using 1:2:3 with impulses
>   1364987000,50,19
>   1364987000,100,1
>   1364987000,150,0
> 
>   1364990600,50,15
>   1364990600,100,4
>   1364990600,150,1
> 
>   1364942000,50,9
>   1364942000,100,5
>   1364942000,150,7
> 
>   1365001400,50,11
>   1365001400,100,7
>   1365001400,150,2
>   e
> 
> ... and second:
>   reset
>   set datafile separator ","
>   set xdata time
>   set timefmt "%s"
>   set format x "%Y-%m-%d %H:%M:%S"
>   set view 47,54
>   splot '-' nonuniform matrix using 2:1:3 with impulses
>   0,50.00,100.00,150.00
>   1364987000,19,1,0
>   1364990600,15,4,1
>   1364942000,9,5,7
>   1365001400,11,7,2
>   e
>   e
> 
> (I don't understand why the second example requires two 'e's either,
> but I digress...)
> 
> In the first case, the year is correctly set to 2013. In the second,
> it is displayed as 2043. This seems to be a mistake in the nonuniform
> matrix time input?

This probably fixes it, but the possible consequences elsewhere are not
certain.  At a minimum it makes all references to the year 2000 in the
manual incorrect, since it resets the epoch boundary to 1970.

	Ethan


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: 30-year time offset reading nonuniform matrix %s input

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

On Wednesday, April 03, 2013 02:12:55 pm Juhász Péter wrote:
> On Wed, 2013-04-03 at 12:36 -0700, Ethan Merritt wrote:

> > 
> > Does anyone know why, way back in the mists of time, gnuplot decided to 
> > define its own epoch boundary as 1-jan-2000 rather than use the conventional
> > unix epoch boundary 1-jan-1970? 
> >   
> > Did it have something to do with fitting an integer number of seconds 
> > in a 32-bit, or even 16-bit, integer? 
> > 
> > How many things would break if we did away with this 30 year disagreement?
> > 
> > 	Ethan
> > 
> > 
> 
> Currently this disagreement manifests itself even in the user interface:
> the meaning of "%s" is different, depending on whether it was used as an
> input or output spec.
> 
> Doing away with it might break a few scripts that depend on the epoch
> being 2000.0, but on the plus side it would make everything clearer and
> more consistent - both the internal implementation and the user
> documentation, not to mention that it would also be consistent with the
> rest of the (Unix) world.
> 
> I might add that 4.6.0 would have been a good place to make this change.
>
> Peter

Ah, but the major version change 4->5 would be an even better time.
I will add it to my "Things to break in 5.0" list [*].

My current thinking is that a 4.7 snapshot could be put out as a 
release candidate for 5.0 late this year.

	Ethan

[*] "break" in this case means "make no guarantee of backward compatibility"

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: 30-year time offset reading nonuniform matrix %s input

[Juhász P. <pet...@gm...>]

On Wed, 2013-04-03 at 12:36 -0700, Ethan Merritt wrote:
> On Wednesday, April 03, 2013 11:38:27 am Tait wrote:
> > 
> > Consider these two examples. First:
> >   reset
> >   set datafile separator ","
> >   set xdata time
> >   set timefmt "%s"
> >   set format x "%Y-%m-%d %H:%M:%S"
> >   set view 47,54
> >   splot '-' using 1:2:3 with impulses
> >   1364987000,50,19
> >   1364987000,100,1
> >   1364987000,150,0
> > 
> >   1364990600,50,15
> >   1364990600,100,4
> >   1364990600,150,1
> > 
> >   1364942000,50,9
> >   1364942000,100,5
> >   1364942000,150,7
> > 
> >   1365001400,50,11
> >   1365001400,100,7
> >   1365001400,150,2
> >   e
> > 
> > ... and second:
> >   reset
> >   set datafile separator ","
> >   set xdata time
> >   set timefmt "%s"
> >   set format x "%Y-%m-%d %H:%M:%S"
> >   set view 47,54
> >   splot '-' nonuniform matrix using 2:1:3 with impulses
> >   0,50.00,100.00,150.00
> >   1364987000,19,1,0
> >   1364990600,15,4,1
> >   1364942000,9,5,7
> >   1365001400,11,7,2
> >   e
> >   e
> > 
> > (I don't understand why the second example requires two 'e's either,
> > but I digress...)
> > 
> > In the first case, the year is correctly set to 2013. In the second,
> > it is displayed as 2043. This seems to be a mistake in the nonuniform
> > matrix time input?
> 
> Does anyone know why, way back in the mists of time, gnuplot decided to 
> define its own epoch boundary as 1-jan-2000 rather than use the conventional
> unix epoch boundary 1-jan-1970? 
>   
> Did it have something to do with fitting an integer number of seconds 
> in a 32-bit, or even 16-bit, integer? 
> 
> How many things would break if we did away with this 30 year disagreement?
> 
> 	Ethan
> 
> 

Currently this disagreement manifests itself even in the user interface:
the meaning of "%s" is different, depending on whether it was used as an
input or output spec.

Doing away with it might break a few scripts that depend on the epoch
being 2000.0, but on the plus side it would make everything clearer and
more consistent - both the internal implementation and the user
documentation, not to mention that it would also be consistent with the
rest of the (Unix) world.

I might add that 4.6.0 would have been a good place to make this change.

Peter

Re: [PATCH] volatile-data plots now handle 'reversed' ranges during replots

[Dima K. <gn...@di...>]

Ethan Merritt <merritt@u.washington.edu> writes:

> On Wednesday, April 03, 2013 02:57:01 am Dima Kogan wrote:
>> I'm attaching another patch. This one adds support to the "reverse"
>> ranges setting for replots of volatile data. This is similar to the
>> previous ranging fixes, where the setting was respected for the original
>> plot, but ignored for replots.
>> 
>> I'm also including the test cases I used to validate this. For all the
>> test cases, I made sure that both the original plot and a replot looked
>> good.
>
> I'm not seeing any difference between the patched and the unpatched
> behavior.  Could you give me a specific set of instructions to test,
> inclding any mouse or replot/refresh commands?
>
> Both the patched and unpatched code versions lose track of the "reverse"
> setting after an unzoom operation using the "u" hotkey.

That's odd. I just tried again with a clean checkout, and the patch
seems to work, both through replots ('e' key) and zoom/unzoom (mouse and
'u' key). The tree I'm looking at has both of the patches I sent
yesterday, so the last few commits are titled

 document use of "smooth frequency" to generate and plot a histogram
 Allow level 1 PostScript interpreters to skip large (>64kB) embedded images
 x11 terminal: corrected some sizing inconsistencies
 volatile-data plots now handle 'reversed' ranges during replots

After the tree is checked out, I do

 export GNUPLOT_DRIVER_DIR=$PWD/src
 ./prepare && ./configure && make -j2 && src/gnuplot

Then inside gnuplot, I load one of the testcases

 load "/tmp/testcases/reverse_keywordspec.gp"

Then I press 'e' to replot, do some zooming with the mouse, and press
'u' to unzoom. The right answer is a downward sloping line (reversed y
axis). I see this even through 'e' and zoom/'u'. Before the attached
patch only the initial plot looked right.

dima

Re: 30-year time offset reading nonuniform matrix %s input

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

On Wednesday, April 03, 2013 11:38:27 am Tait wrote:
> 
> Consider these two examples. First:
>   reset
>   set datafile separator ","
>   set xdata time
>   set timefmt "%s"
>   set format x "%Y-%m-%d %H:%M:%S"
>   set view 47,54
>   splot '-' using 1:2:3 with impulses
>   1364987000,50,19
>   1364987000,100,1
>   1364987000,150,0
> 
>   1364990600,50,15
>   1364990600,100,4
>   1364990600,150,1
> 
>   1364942000,50,9
>   1364942000,100,5
>   1364942000,150,7
> 
>   1365001400,50,11
>   1365001400,100,7
>   1365001400,150,2
>   e
> 
> ... and second:
>   reset
>   set datafile separator ","
>   set xdata time
>   set timefmt "%s"
>   set format x "%Y-%m-%d %H:%M:%S"
>   set view 47,54
>   splot '-' nonuniform matrix using 2:1:3 with impulses
>   0,50.00,100.00,150.00
>   1364987000,19,1,0
>   1364990600,15,4,1
>   1364942000,9,5,7
>   1365001400,11,7,2
>   e
>   e
> 
> (I don't understand why the second example requires two 'e's either,
> but I digress...)
> 
> In the first case, the year is correctly set to 2013. In the second,
> it is displayed as 2043. This seems to be a mistake in the nonuniform
> matrix time input?

Does anyone know why, way back in the mists of time, gnuplot decided to 
define its own epoch boundary as 1-jan-2000 rather than use the conventional
unix epoch boundary 1-jan-1970? 
  
Did it have something to do with fitting an integer number of seconds 
in a 32-bit, or even 16-bit, integer? 

How many things would break if we did away with this 30 year disagreement?

	Ethan


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

30-year time offset reading nonuniform matrix %s input

[Tait <gnu...@t4...>]

Consider these two examples. First:
  reset
  set datafile separator ","
  set xdata time
  set timefmt "%s"
  set format x "%Y-%m-%d %H:%M:%S"
  set view 47,54
  splot '-' using 1:2:3 with impulses
  1364987000,50,19
  1364987000,100,1
  1364987000,150,0

  1364990600,50,15
  1364990600,100,4
  1364990600,150,1

  1364942000,50,9
  1364942000,100,5
  1364942000,150,7

  1365001400,50,11
  1365001400,100,7
  1365001400,150,2
  e

... and second:
  reset
  set datafile separator ","
  set xdata time
  set timefmt "%s"
  set format x "%Y-%m-%d %H:%M:%S"
  set view 47,54
  splot '-' nonuniform matrix using 2:1:3 with impulses
  0,50.00,100.00,150.00
  1364987000,19,1,0
  1364990600,15,4,1
  1364942000,9,5,7
  1365001400,11,7,2
  e
  e

(I don't understand why the second example requires two 'e's either,
but I digress...)

In the first case, the year is correctly set to 2013. In the second,
it is displayed as 2043. This seems to be a mistake in the nonuniform
matrix time input?

Re: [PATCH] volatile-data plots now handle 'reversed' ranges during replots

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

On Wednesday, April 03, 2013 02:57:01 am Dima Kogan wrote:
> I'm attaching another patch. This one adds support to the "reverse"
> ranges setting for replots of volatile data. This is similar to the
> previous ranging fixes, where the setting was respected for the original
> plot, but ignored for replots.
> 
> I'm also including the test cases I used to validate this. For all the
> test cases, I made sure that both the original plot and a replot looked
> good.

I'm not seeing any difference between the patched and the unpatched
behavior.  Could you give me a specific set of instructions to test,
inclding any mouse or replot/refresh commands?

Both the patched and unpatched code versions lose track of the "reverse"
setting after an unzoom operation using the "u" hotkey.

	Ethan

> 
> Lastly, I'm really not at ease with these patches. Currently there are
> separate code paths for volatile and from-a-file data; these paths get
> out of sync, and issues such as this arise. I'm assuming that where
> reading data from files gnuplot can (and does) take multiple passes
> through the data, which is impossible when reading a pipe. Does anybody
> know why multiple passes are made? Is it a major undertaking to reduce
> this to a single pass, so that all data becomes "volatile" and we can
> get rid of the multiple code paths?
> 
> dima
> 
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: [PATCH] volatile-data plots now handle 'reversed' ranges during replots

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

On Wednesday, 03 April 2013, Dima Kogan wrote:
> I'm attaching another patch. This one adds support to the "reverse"
> ranges setting for replots of volatile data. This is similar to the
> previous ranging fixes, where the setting was respected for the original
> plot, but ignored for replots.

I'll test the patch, but I fear it may break zoom/unzoom.

> Does anybody know why multiple passes are made? 

The volatile path can only handle the simple case of un-transformed data.
This case is common enough to be useful, but it cannot substitute for the
general case treatment.

Consider:

  f(x) = 2*x
  plot 'silver.dat' using (f($1)):2
  f(x) = x/2.
  refresh # redraws the original plot even though f(x) has changed
  replot   # draw a new plot using the new f(x)

The fundamental problem is that gnuplot does not store the original
data values internally.  It only stores the transformed coordinates used
in the plot.   This is particularly annoying in the case of log-scaled axes,
where the log scaling is applied to the data when it is read in rather
than when it is plotted.  So log scaling interferes with the volatile 
data path.

> Is it a major undertaking to reduce this to a single pass, so that all data
> becomes "volatile" and we can get rid of the multiple code paths?

Yes.  You would have to change it so that the original data values are
stored internally so that they can be reused without rereading from
the input file.   That basically isn't possible. 
Consider
      plot "data" using 1: (sum [i=2:100] f(column(i)))
In order to reevaluate this after possibly redefining f() you would
have to store 100 columns of data internally.  As it is now, they
are processed on input and only the resulting sum is stored.

Nevertheless, I have long wanted to do away with the log-scaled axis
code.  Having to log/unlog the data every time you access the
stored values complicates the code throughout the plotting routines.
I would much rather get rid of all that extra code and apply the
log-scale transformation at the time the data is plotted.  
The "set link" command added in 4.7 was designed to take us halfway
to this goal.  The "link" code attaches a scaling function to the axis,
which could in this case be log().  The problem is that there is
a complicated bit of code that generates log-scale tick positions as
a special case, and it's not obvious to me how to replace this
transparently.  On the other hand the existing log-scale tick mark
code has been buggy for 20 years or so; the oldest open bug still
being tracked is "short log axes get bad autotics", added when the
SourceForge tracker was started in 2000.  So maybe throwing it out
and starting over wouldn't be a bad idea anyhow.

     Ethan

> 
> I'm also including the test cases I used to validate this. For all the
> test cases, I made sure that both the original plot and a replot looked
> good.
> 
> Lastly, I'm really not at ease with these patches. Currently there are
> separate code paths for volatile and from-a-file data; these paths get
> out of sync, and issues such as this arise. I'm assuming that where
> reading data from files gnuplot can (and does) take multiple passes
> through the data, which is impossible when reading a pipe. 
> 
> dima
> 
> 

[PATCH] volatile-data plots now handle 'reversed' ranges during replots

[Dima K. <gn...@di...>]

I'm attaching another patch. This one adds support to the "reverse"
ranges setting for replots of volatile data. This is similar to the
previous ranging fixes, where the setting was respected for the original
plot, but ignored for replots.

I'm also including the test cases I used to validate this. For all the
test cases, I made sure that both the original plot and a replot looked
good.

Lastly, I'm really not at ease with these patches. Currently there are
separate code paths for volatile and from-a-file data; these paths get
out of sync, and issues such as this arise. I'm assuming that where
reading data from files gnuplot can (and does) take multiple passes
through the data, which is impossible when reading a pipe. Does anybody
know why multiple passes are made? Is it a major undertaking to reduce
this to a single pass, so that all data becomes "volatile" and we can
get rid of the multiple code paths?

dima

[PATCH] some sizing fixes in the x11 terminal

[Dima K. <gn...@di...>]

I'm attaching a patch to fix some sizing errors that were introduced by
some of my earlier X11 fixes. These were mostly confusion between height
and gheight. An observable problem that this patch fixes is plotting
something, and then doing a replot. With the same data file the replot
shouldn't have any visible effects, but there was some geometric
shifting as a result of the errors.

Re: Any last-minute fixes or requests for inclusion in 4.6.2?

[Hans-Bernhard B. <HBB...@t-...>]

On 01.04.2013 21:52, Ethan Merritt wrote:
> On Friday, March 22, 2013 11:34:33 am Bastian Märkisch wrote:
>> Please find a release candidate of a Windows installer and a zip package at
>> http://www.gnuplot.info/development/binaries/
>>
>> Please test them thoroughly so that we can make them available to the
>> public.
>
> What's the status on this - should it be moved/copied to the SourceForge
> download site?

FWIW, it works just fine on my Windows box here.

Re: Any last-minute fixes or requests for inclusion in 4.6.2?

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

On Friday, March 22, 2013 11:34:33 am Bastian Märkisch wrote:
> Please find a release candidate of a Windows installer and a zip package at
> http://www.gnuplot.info/development/binaries/
> 
> Please test them thoroughly so that we can make them available to the 
> public.

What's the status on this - should it be moved/copied to the SourceForge
download site?

	Ethan


> 
>    Bastian
> 
> 
> Am 10.03.2013 07:14, schrieb sfeam (Ethan Merritt):
> > Anyone know of an unresolved 4.6 bug that should be fixed before
> > releasing 4.6.2?   If not, I plan to put the usual source tarball
> > on SourceForge later this week.
> >
> > Any volunteers to prepare a Windows install package?
> >
> > 	Ethan
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >
> > NEWS file for 4.6.2
> >
> >   New features, changes and fixes since gnuplot version 4.6.1
> > ===========================================================
> >
> > * NEW Allow the "bind" command to attach a user command to mouse button 1
> > * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
> > * NEW -d option from command line skips ~/.gnuplot initialization file
> > * NEW plot '<&N' plots from file descriptor N opened during shell invocation
> > * CHANGE "unset term" restores original default terminal (GNUTERM)
> > * CHANGE ignore extraneous trailing comma in a plot command
> > * CHANGE special case code for faster input of uniform binary matrix data
> > * CHANGE test for whether the session should be interactive or non-interactive
> > * CHANGE draw zeroaxis lines in the same layer as the grid and border
> > * CHANGE allow 2-column-only variant of yerrorbars (implicit x coord)
> > * FIX aquaterm rendering of rgbimage plot type
> > * FIX gd terminal fontsize change requested by set_font(",newsize")
> > * FIX qt terminal font metrics
> > * FIX qt terminal mouse tracking and resize events for persistent plots
> > * FIX x11 terminal sometimes failed to reset the line width
> > * FIX -persist mode continued mousing of 3D "set view map" plots
> > * FIX reset parsing state after error in parsing string input
> > * FIX buffer overflow from very long tic label formats
> > * FIX broken handling of formatted input via 'using 1:2 "<format>"'
> > * FIX exit current command file from inside bracketed clause
> > * FIX estimation of space required for rotated x-axis tic labels
> > * FIX partial axis ranges (e.g. xrange [*:MAX]) when refreshing volatile data
> > * FIX -persist option broken if configured without x11
> >
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: Any last-minute fixes or requests for inclusion in 4.6.2?

[Bastian M. <bma...@we...>]

Please find a release candidate of a Windows installer and a zip package at
http://www.gnuplot.info/development/binaries/

Please test them thoroughly so that we can make them available to the 
public.

   Bastian


Am 10.03.2013 07:14, schrieb sfeam (Ethan Merritt):
> Anyone know of an unresolved 4.6 bug that should be fixed before
> releasing 4.6.2?   If not, I plan to put the usual source tarball
> on SourceForge later this week.
>
> Any volunteers to prepare a Windows install package?
>
> 	Ethan
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> NEWS file for 4.6.2
>
>   New features, changes and fixes since gnuplot version 4.6.1
> ===========================================================
>
> * NEW Allow the "bind" command to attach a user command to mouse button 1
> * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
> * NEW -d option from command line skips ~/.gnuplot initialization file
> * NEW plot '<&N' plots from file descriptor N opened during shell invocation
> * CHANGE "unset term" restores original default terminal (GNUTERM)
> * CHANGE ignore extraneous trailing comma in a plot command
> * CHANGE special case code for faster input of uniform binary matrix data
> * CHANGE test for whether the session should be interactive or non-interactive
> * CHANGE draw zeroaxis lines in the same layer as the grid and border
> * CHANGE allow 2-column-only variant of yerrorbars (implicit x coord)
> * FIX aquaterm rendering of rgbimage plot type
> * FIX gd terminal fontsize change requested by set_font(",newsize")
> * FIX qt terminal font metrics
> * FIX qt terminal mouse tracking and resize events for persistent plots
> * FIX x11 terminal sometimes failed to reset the line width
> * FIX -persist mode continued mousing of 3D "set view map" plots
> * FIX reset parsing state after error in parsing string input
> * FIX buffer overflow from very long tic label formats
> * FIX broken handling of formatted input via 'using 1:2 "<format>"'
> * FIX exit current command file from inside bracketed clause
> * FIX estimation of space required for rotated x-axis tic labels
> * FIX partial axis ranges (e.g. xrange [*:MAX]) when refreshing volatile data
> * FIX -persist option broken if configured without x11
>

Re: crash on exit, on OS X

[Ethan A M. <sf...@us...>]

On Wednesday, March 20, 2013 03:25:01 pm Allin Cottrell wrote:
> On Mon, 18 Mar 2013, Allin Cottrell wrote:
> 
> > Sorry if I've missed discussion of this, but I'm seeing a crash on exiting 
> > gnuplot (by typing "quit" or "q" then Enter) when running in Terminal.app on 
> > Mac OS X.
> >
> > This is with current CVS gnuplot, OS X 10.6.8. The message I'm getting is:
> >
> > gnuplot> q
> > gnuplot(19077) malloc: *** error for object 0x71: pointer being freed was not 
> > allocated
> > *** set a breakpoint in malloc_error_break to debug
> > Abort trap
> 
> OK, I now see what's wrong: readline was crossed-up. Gnuplot's 
> configure script found GNU readline under /usr/local but the build 
> linked against Apple's fake readline (libedit.dylib). So bad results 
> may be expected.
> 
> If I either specify --with-readline=bsd or add -L/usr/local/lib to 
> CFLAGS when running configure, I get a consistent build that doesn't 
> crash. I'd forgotten about the fake readline business.
> Allin Cottrell

That's good to know in case someone else runs into the same symptoms.

Note, however, that gnuplot's built-in readline is probably a better option
than the BSD version.  The built-in version was extended during the 4.6
development cycle to include tab-completion.  More to the point, it was 
extended to handle UTF8 encoding, which the BSD version does not support.

	Ethan

Re: crash on exit, on OS X

[Allin C. <cot...@wf...>]

On Mon, 18 Mar 2013, Allin Cottrell wrote:

> Sorry if I've missed discussion of this, but I'm seeing a crash on exiting 
> gnuplot (by typing "quit" or "q" then Enter) when running in Terminal.app on 
> Mac OS X.
>
> This is with current CVS gnuplot, OS X 10.6.8. The message I'm getting is:
>
> gnuplot> q
> gnuplot(19077) malloc: *** error for object 0x71: pointer being freed was not 
> allocated
> *** set a breakpoint in malloc_error_break to debug
> Abort trap

OK, I now see what's wrong: readline was crossed-up. Gnuplot's 
configure script found GNU readline under /usr/local but the build 
linked against Apple's fake readline (libedit.dylib). So bad results 
may be expected.

If I either specify --with-readline=bsd or add -L/usr/local/lib to 
CFLAGS when running configure, I get a consistent build that doesn't 
crash. I'd forgotten about the fake readline business.

Allin Cottrell

Re: crash on exit, on OS X

[Allin C. <cot...@wf...>]

On Wed, 20 Mar 2013, Mojca Miklavec wrote:

> On Tue, Mar 19, 2013 at 2:34 AM, Allin Cottrell wrote:
>> Sorry if I've missed discussion of this, but I'm seeing a crash on
>> exiting gnuplot (by typing "quit" or "q" then Enter) when running in
>> Terminal.app on Mac OS X.
>>
>> This is with current CVS gnuplot, OS X 10.6.8. The message I'm
>> getting is:
>>
>> gnuplot> q
>> gnuplot(19077) malloc: *** error for object 0x71: pointer being
>> freed was not allocated
>> *** set a breakpoint in malloc_error_break to debug
>> Abort trap
>
> Which compiler, which terminal and what libraries did you use
> (MacPorts, Fink, Homebrew or nothing)? I tried it on 10.7 with
> libraries from MacPorts, but I don't experience that problem with a
> couple of simple plotting commands.

Apple's gcc, AquaTerm, other libraries compiled from source on 
the target machine. I'll try a build with debugging enabled 
and see if I can get a better idea of what's happening. In the 
meantime I'm attaching the OS X trace in case it's any help.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: crash on exit, on OS X

[Mojca M. <moj...@gm...>]

On Tue, Mar 19, 2013 at 2:34 AM, Allin Cottrell wrote:
> Sorry if I've missed discussion of this, but I'm seeing a crash on
> exiting gnuplot (by typing "quit" or "q" then Enter) when running in
> Terminal.app on Mac OS X.
>
> This is with current CVS gnuplot, OS X 10.6.8. The message I'm
> getting is:
>
> gnuplot> q
> gnuplot(19077) malloc: *** error for object 0x71: pointer being
> freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> Abort trap

Which compiler, which terminal and what libraries did you use
(MacPorts, Fink, Homebrew or nothing)? I tried it on 10.7 with
libraries from MacPorts, but I don't experience that problem with a
couple of simple plotting commands.

Mojca

crash on exit, on OS X

[Allin C. <cot...@wf...>]

Sorry if I've missed discussion of this, but I'm seeing a crash on 
exiting gnuplot (by typing "quit" or "q" then Enter) when running in 
Terminal.app on Mac OS X.

This is with current CVS gnuplot, OS X 10.6.8. The message I'm 
getting is:

gnuplot> q
gnuplot(19077) malloc: *** error for object 0x71: pointer being 
freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: Prescaling fit parameters

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

On Sun, 10 Mar 2013, sfeam (Ethan Merritt) wrote:

>  On Friday, 08 March 2013, Carl Michal wrote:
>
>  The code in the patch does not do what it is described as doing.
>
>  1)
>  The test of this form will never be true:   (foo == NEARLY_ZERO)
>  You would have to test  (favs(foo) <= NEARLY_ZERO)

I disagree because in fit.c just a couple of lines up, there is this:

    for (i = 0; i < num_params; i++)
 	 if (a[i] == 0)
 	     a[i] = NEARLY_ZERO;

So I tested for NEARLY_ZERO. I think this is nearly the right behaviour, 
because if a parameter is specifically initialized to something 
smaller than NEARLY_ZERO, then prescaling is probably particularly 
important. There is one minor issue though - if the user 
purposefully initializes a variable to the value of NEARLY_ZERO it 
won't prescale but should. I've fixed that.

>
>  2)
>  The description/comment says
>  "If any variables were 0, then don't do it, since it causes more harm than
>  good then."
>  But the actual code applies scaling to all parameters except ones
>  with (foo == NEARLY_ZERO), which aside from being the wrong test is
>  not what is described ("if any ...").
>
>  Also, do you have any reason to believe the current definition of
>  NEARLY_ZERO as 10^{-30} is the right place to make a cutoff?

The comment has been fixed so it now describes the actual behaviour. I 
don't want a cutoff - just not to scale if the variable was set to exactly 
0.

>
>  3)
>  Please make this an option, probably
>    set fit [no]prescale
>
>   Ethan

Done.

This now uses set fit [no]prescale, defaults to off, and is unset in 
unset fit. The value is also displayed by show fit, and is saved in 
save.c.

The documentation describes the new option in help fit, help fit tips, and 
help set fit.

Is there anything I've missed?

I've also picked up a couple of modifications that Bastian Maerkisch made 
to the patch: it preserves the sign of the parameter and also scales the 
outputs of the errors if the errors are saved to variables. There are now 
two versions of the patch at 
https://sourceforge.net/p/gnuplot/patches/507/ one against 4.6.1 and one 
against current CVS.

Thanks for the feedback.

Carl

Re: Prescaling fit parameters

[sfeam (E. Merritt) <eam...@gm...>]

On Friday, 08 March 2013, Carl Michal wrote:
> Hi,
> 
> A couple of years ago (March 2011) I submitted a very small patch against fit.c 
> to improve the way gnuplot's fit function works in cases where fit parameters 
> vary in size dramatically. The problem is that if you are doing fits where some 
> parameters are, say 10^7, but others are 10^-7, the fit routine basically 
> collapses.
> 
> The patch does a trivial rescaling of the parameters by their initial guess 
> values before the meat of the fitting routine is called. With this rescaling 
> these cases don't cause any problems.
> 
> The patch and a description are here:
> http://sourceforge.net/p/gnuplot/patches/507/
> and this still applies cleanly to gnuplot 4.6.
> 
> After applying this patch, most of the examples in fit.dem actually converge in 
> fewer iterations than without it.
> 
> Is there any hope of having this tiny patch (it touches a total of 20 lines) 
> accepted?

The code in the patch does not do what it is described as doing.

1)
The test of this form will never be true:   (foo == NEARLY_ZERO) 
You would have to test  (favs(foo) <= NEARLY_ZERO)

2)
The description/comment says
 "If any variables were 0, then don't do it, since it causes more harm than
  good then."
But the actual code applies scaling to all parameters except ones
with (foo == NEARLY_ZERO), which aside from being the wrong test is
not what is described ("if any ...").

Also, do you have any reason to believe the current definition of 
NEARLY_ZERO as 10^{-30} is the right place to make a cutoff?  

3)
Please make this an option, probably
   set fit [no]prescale

	Ethan


> Thanks,
> 
> Carl

Re: Any last-minute fixes or requests for inclusion in 4.6.2?

[Ethan A M. <eam...@gm...>]

On Sunday, 10 March 2013, Daniel J Sebald wrote:
> On 03/10/2013 04:22 PM, Ethan Merritt wrote:
> > On Sunday, 10 March 2013, Daniel J Sebald wrote:
> >> On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote:
> >>> Anyone know of an unresolved 4.6 bug that should be fixed before
> >>> releasing 4.6.2?   If not, I plan to put the usual source tarball
> >>> on SourceForge later this week.
> >>
> >> The one concern is the description for this new item:
> >>
> >>> * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
> >>
> >> which seems to me like overselling things a bit.  pm3d has always
> >> occluded whatever is behind it, so that is not new.
> >
> > That's not true.  Up until now the non-pm3d lines handled by hidden3d
> > ignored the pm3d surface altogether, so they would appear on top in
> > the rendered image regardless of whether they should have been in front
> > or behind the pm3d surface.  Now the behind portions are correctly
> > not drawn.
> 
> But it is not the pm3d elements that are in the algorithm.  It is the 
> invisible lines that are forcing the behind portions to not be drawn. 

Correct.

> Was there something introduced to the hidden3d algorithm that uses the 
> coordinate-set for the pm3d elements?

Yes.  The same work-around in the hidden2d demo (draw invisble lines
for the same surface as the pm3d version) was moved into the code
itself.

> After running the hidden2.dem demo, type:

The point is that the manual work-around in the the hidden2 demo
is no longer required.  The code does it for you.
It is true that the work-around is still not perfect, whether 
manual or automatic.

> set hidden3d back
> replot
> 
> and it is clear that the difference is the order in which pm3d surface 
> and hidden3d elements are drawn.

The invisible lines approach only works for "set hidden3d front".

> > [snip]
> >> What would really be desirable is the ability to specify which surfaces
> >> should occlude and which shouldn't.  I actually think that is a very
> >> useful feature to have.
> >
> > That would be the existing "nohidden" keyword, if I'm understanding
> > you correctly.
> 
> Maybe, I'm not sure.  I type "help nohidden" which displays the help for 
> "set hidden3d".  So "hidden" is the same as "hidden3d"?  And "set 
> nohidden3d" means to turn off hidden3d?

 set hidden3d
 splot A, B nohidden, C
means to include A and C in the hidden3d calculations but treat
B without regard to hidden3d.

	Ethan

> I would say it is not the same.  "nohidden3d" will just show every mesh 
> line.  What I'm suggesting is that each plot "surface" or "mesh" can 
> have its hiding capability controlled separately.  That would be doable 
> if we have full and complete hidden 3D capability.
> 
> This raises another interesting question.  Say we were to integrate 
> surfaces into the hidden3d capability.  Right now hidden3d removes the 
> mesh pieces that are hidden.  Could it be possible to keep those mesh 
> pieces and somehow combine them with the alpha-mixing of the surface 
> elements?  Might make for an interesting plot.
> 
> Dan
> 
> 
> 
> >
> > 	Ethan
> >
> >
> >
> >> That way one could specify an interior surface
> >> that should always show through, which is what the hidden2d example
> >> effectively doing as observed.  So, here might be how that works:
> >>
> >> set hidden3d
> >> f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5)
> >> splot f(x,y) with pm3d solid, \
> >>         x*x-y*y with lines lt 1 lc rgb "#000000" transparent
> >>
> >>
> >> Well, in summary, rather than describing this as a pm3d-related feature,
> >> how about
> >>
> >>    * NEW hidden3d invisible lines for simulated surface occlusion (as in
> >> hidden2.dem)
> >>
> >> Dan
> >>
> >> ------------------------------------------------------------------------------
> >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> >> endpoint security space. For insight on selecting the right partner to
> >> tackle endpoint security challenges, access the full report.
> >> http://p.sf.net/sfu/symantec-dev2dev
> >> _______________________________________________
> >> gnuplot-beta mailing list
> >> gnu...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >>
> >
> >
> > ------------------------------------------------------------------------------
> > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> > endpoint security space. For insight on selecting the right partner to
> > tackle endpoint security challenges, access the full report.
> > http://p.sf.net/sfu/symantec-dev2dev
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 
> 


-- 
Tradition is not the worship of ashes, but the preservation of fire.
  - Gustav Mahler

Re: Any last-minute fixes or requests for inclusion in 4.6.2?

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

On 03/10/2013 04:22 PM, Ethan Merritt wrote:
> On Sunday, 10 March 2013, Daniel J Sebald wrote:
>> On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote:
>>> Anyone know of an unresolved 4.6 bug that should be fixed before
>>> releasing 4.6.2?   If not, I plan to put the usual source tarball
>>> on SourceForge later this week.
>>
>> The one concern is the description for this new item:
>>
>>> * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
>>
>> which seems to me like overselling things a bit.  pm3d has always
>> occluded whatever is behind it, so that is not new.
>
> That's not true.  Up until now the non-pm3d lines handled by hidden3d
> ignored the pm3d surface altogether, so they would appear on top in
> the rendered image regardless of whether they should have been in front
> or behind the pm3d surface.  Now the behind portions are correctly
> not drawn.

But it is not the pm3d elements that are in the algorithm.  It is the 
invisible lines that are forcing the behind portions to not be drawn. 
Was there something introduced to the hidden3d algorithm that uses the 
coordinate-set for the pm3d elements?

After running the hidden2.dem demo, type:

set hidden3d back
replot

and it is clear that the difference is the order in which pm3d surface 
and hidden3d elements are drawn.

It's a creative way of simulating what we actually want, which is true 
hidden surface behavior.  But if it becomes too manually configurable 
and meticulous, the user will likely find other ways to accomplish the 
same thing via function definitions or whatnot.

All I'm saying is that I think this is more of a hidden3d feature than 
it is a pm3d feature.  The hidden3d -2 surface is creating a hole in the 
mesh to allow whatever is behind it to show through.  It requires the 
user to think through things a bit.


> [snip]
>> What would really be desirable is the ability to specify which surfaces
>> should occlude and which shouldn't.  I actually think that is a very
>> useful feature to have.
>
> That would be the existing "nohidden" keyword, if I'm understanding
> you correctly.

Maybe, I'm not sure.  I type "help nohidden" which displays the help for 
"set hidden3d".  So "hidden" is the same as "hidden3d"?  And "set 
nohidden3d" means to turn off hidden3d?

I would say it is not the same.  "nohidden3d" will just show every mesh 
line.  What I'm suggesting is that each plot "surface" or "mesh" can 
have its hiding capability controlled separately.  That would be doable 
if we have full and complete hidden 3D capability.

This raises another interesting question.  Say we were to integrate 
surfaces into the hidden3d capability.  Right now hidden3d removes the 
mesh pieces that are hidden.  Could it be possible to keep those mesh 
pieces and somehow combine them with the alpha-mixing of the surface 
elements?  Might make for an interesting plot.

Dan



>
> 	Ethan
>
>
>
>> That way one could specify an interior surface
>> that should always show through, which is what the hidden2d example
>> effectively doing as observed.  So, here might be how that works:
>>
>> set hidden3d
>> f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5)
>> splot f(x,y) with pm3d solid, \
>>         x*x-y*y with lines lt 1 lc rgb "#000000" transparent
>>
>>
>> Well, in summary, rather than describing this as a pm3d-related feature,
>> how about
>>
>>    * NEW hidden3d invisible lines for simulated surface occlusion (as in
>> hidden2.dem)
>>
>> Dan
>>
>> ------------------------------------------------------------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: Any last-minute fixes or requests for inclusion in 4.6.2?

[Ethan M. <eam...@gm...>]

On Sunday, 10 March 2013, Daniel J Sebald wrote:
> On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote:
> > Anyone know of an unresolved 4.6 bug that should be fixed before
> > releasing 4.6.2?   If not, I plan to put the usual source tarball
> > on SourceForge later this week.
> 
> The one concern is the description for this new item:
> 
> > * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)
> 
> which seems to me like overselling things a bit.  pm3d has always 
> occluded whatever is behind it, so that is not new.

That's not true.  Up until now the non-pm3d lines handled by hidden3d
ignored the pm3d surface altogether, so they would appear on top in
the rendered image regardless of whether they should have been in front
or behind the pm3d surface.  Now the behind portions are correctly
not drawn.

[snip]
> What would really be desirable is the ability to specify which surfaces 
> should occlude and which shouldn't.  I actually think that is a very 
> useful feature to have.  

That would be the existing "nohidden" keyword, if I'm understanding 
you correctly.

	Ethan



> That way one could specify an interior surface 
> that should always show through, which is what the hidden2d example 
> effectively doing as observed.  So, here might be how that works:
> 
> set hidden3d
> f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5)
> splot f(x,y) with pm3d solid, \
>        x*x-y*y with lines lt 1 lc rgb "#000000" transparent
> 
> 
> Well, in summary, rather than describing this as a pm3d-related feature, 
> how about
> 
>   * NEW hidden3d invisible lines for simulated surface occlusion (as in 
> hidden2.dem)
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
> endpoint security space. For insight on selecting the right partner to 
> tackle endpoint security challenges, access the full report. 
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Any last-minute fixes or requests for inclusion in 4.6.2?

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

On 03/10/2013 12:14 AM, sfeam (Ethan Merritt) wrote:
> Anyone know of an unresolved 4.6 bug that should be fixed before
> releasing 4.6.2?   If not, I plan to put the usual source tarball
> on SourceForge later this week.

The one concern is the description for this new item:

> * NEW hidden3d can handle occlusion by pm3d surfaces (as in hidden2.dem)

which seems to me like overselling things a bit.  pm3d has always 
occluded whatever is behind it, so that is not new.  The example 
actually has the pm3d surface on the bottom layer.

What's new is the invisible line type (-2) for hidden surface mesh.  In 
the example, the invisible line type partially covers up the axes which 
doesn't look good.  To see this, after the hidden2.dem demo, type

splot x*x-y*y with lines lt 1 lc rgb "#000000", \
       f(x,y) with lines lt -2 notitle

Also, the meshes don't occlude the pm3d surfaces (the surfaces show 
through the mesh), so that too isn't doing any type of occlusion.  It's 
like going backward from hidden3d.  What would be nice (and something 
I've wanted to work on but can't find the time) is an actual hidden 3D 
surface feature using the mesh sectioning as a starting point.

I'm not saying that plot example isn't something that someone wouldn't 
want to do.  I realize gnuplot doesn't work this way, but there has been 
discussion about making the range specification within the plot command 
apply to just the plot that follows it.  If that were the case, one 
could create a plot similar to hidden2d.dem with the following

unset hidden3d
set zrange [-100:100]
splot [][][-110:0] x*x-y*y with lines lt 1 lc rgb "#000000", \
       f(x,y) with pm3d, \
       [][][0:100] x*x-y*y with lines lt 1 lc rgb "#000000" notile

But even that isn't the best solution (actually bad, but if needing a 
plot from a particular angle, it would do) because if one were to rotate 
the plot to look from a "underneath", the order of plots would no longer 
be correct.

What would really be desirable is the ability to specify which surfaces 
should occlude and which shouldn't.  I actually think that is a very 
useful feature to have.  That way one could specify an interior surface 
that should always show through, which is what the hidden2d example 
effectively doing as observed.  So, here might be how that works:

set hidden3d
f(x,y) = sin(-sqrt((x+5)**2+(y-7)**2)*0.5)
splot f(x,y) with pm3d solid, \
       x*x-y*y with lines lt 1 lc rgb "#000000" transparent


Well, in summary, rather than describing this as a pm3d-related feature, 
how about

  * NEW hidden3d invisible lines for simulated surface occlusion (as in 
hidden2.dem)

Dan