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

Re: defined

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

Ethan A Merritt wrote:
> On Tuesday 30 May 2006 10:04 am, Petr Mikulik wrote:
> 
>>>Subtopic of functions: defined
>>>`defined(X)` returns 1 if a variable named X has been defined, otherwise
>>>it returns 0.
>>
>>I also vote for this convention.
> 
> 
> OK. I found a way to make it work.
> Patch uploaded to SourceForge #1497957.
> I found one corner case that generates a strange error message
> on strange input, but other than that it seems OK.
> 
> Please test.

Is this the strange case you are talking about?

gnuplot> print defined(cos(x))
         unknown type in real()

gnuplot> y = 2
gnuplot> print defined(cos(y))
         unknown type in real()

gnuplot> print defined(cos(pi))
         unknown type in real()

Re: defined

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

Daniel J Sebald wrote:

> /* type_udv() will return 0 rather than type if udv does not exist */
> enum DATA_TYPES {
>     INTGR=1,
>     CMPLX
> #ifdef GP_STRING_VARS
>     , STRING
> #endif
> };

And if you want to make the STRING data type permanent, in the f_isvar() it would be pretty easy to check for the string in the udv linked list (I think the routine already exists) and make

defined(foo)
defined("foo")

behave the same.

Dan

Re: defined

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

Ethan A Merritt wrote:
> On Tuesday 30 May 2006 10:04 am, Petr Mikulik wrote:
> 
>>>Subtopic of functions: defined
>>>`defined(X)` returns 1 if a variable named X has been defined, otherwise
>>>it returns 0.
>>
>>I also vote for this convention.
> 
> 
> OK. I found a way to make it work.
> Patch uploaded to SourceForge #1497957.
> I found one corner case that generates a strange error message
> on strange input, but other than that it seems OK.
> 
> Please test.

In the code is a redundant a.type = 0;

#if (1) /* Flag type a 0 because only the defined/undefined flag means anything */
    a.type = 0;
    if (udv->udv_undef)
        a.v.int_val = 0;
    else
        a.v.int_val = 1;
    a.type = 0;  push(&a);
    return;
#else

but conceptually I think it should be solid.  The one issue is if somewhere an argument is passed in for which a.type was never set to INTGR CMPLX or STRINGS but neither is it a variable that had gone through PUSHV.  Maybe a way to solve that would be to change:

/* type_udv() will return 0 rather than type if udv does not exist */
enum DATA_TYPES {
	INTGR=1,
	CMPLX
#ifdef GP_STRING_VARS
	, STRING
#endif
};

to

/* type_udv() will return 0 rather than type if udv does not exist */
enum DATA_TYPES {
	INTGR=1,
	CMPLX,
        BOOLVAR
#ifdef GP_STRING_VARS
	, STRING
#endif
};

then it would be a.type = BOOLVAR and

if (a.type == BOOLVAR)
    push(Ginteger(&a, a.v.int_val));
else
    push(Ginteger(&a, 0));

[Maybe put an assert() in there to check if ever .type is zero.]

Or is that abusing the DATA_TYPES too much?

...

I see it is possible to have a function and variable of the same name.  I'm OK with that, but this seems a little strange, in that it would bewilder a beginning programmer.  :-)

gnuplot> cos = 5
gnuplot> print cos(cos)
0.283662185463226
gnuplot>


Dan

Re: How to change the heading "gnuplot"

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

renjith padmanabha pillai wrote:
> Sir/Madam,
>  
> I am using GnuPlot to plot experimental data.
> 1) I want to change the heading from "GNUPLOT" to the name of my 
> program. How to do it?

See "help set term x11" and look for 'title'

> 2) Next thing is, if i am using multiplot to draw 3 grids. they are not 
> clearly visible. the grid is very small and the space between the grid 
> is very large. How  can i reduce the space betwee the grids.

See the example under "help multiplot".

Dan

Re: defined

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

On Tuesday 30 May 2006 10:04 am, Petr Mikulik wrote:
> > Subtopic of functions: defined
> > `defined(X)` returns 1 if a variable named X has been defined, otherwise
> > it returns 0.
> 
> I also vote for this convention.

OK. I found a way to make it work.
Patch uploaded to SourceForge #1497957.
I found one corner case that generates a strange error message
on strange input, but other than that it seems OK.

Please test.


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

Re: defined

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

On Tuesday 30 May 2006 10:04 am, Petr Mikulik wrote:
> > Subtopic of functions: defined
> > `defined(X)` returns 1 if a variable named X has been defined, otherwise
> > it returns 0.
> 
> I also vote for this convention.

Fine with me.  Can you see how to implement it?
The best I can come up so far is to give up on treating
defined() as a normal function and make it a special case
token in the command parser.  That would work, but it feels
very inelegant.



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

Re: defined

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

> Subtopic of functions: defined
> `defined(X)` returns 1 if a variable named X has been defined, otherwise
> it returns 0.

I also vote for this convention.

---
PM

Re: defined

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

Ethan A Merritt wrote:
> On Monday 29 May 2006 05:53 pm, Daniel J Sebald wrote:
> 
>>>>gnuplot> print defined("foo")
>>>>141158968
>>>
>>>We don't have a user-visible TBOOLEAN type, 
>>>so any non-zero value represents "TRUE"
>>
>>Right.  The point is that the test and the result are meaningless.  
>>foo was never defined, so if anything the result should be zero.  
> 
> 
> I think you are looking at this the wrong way.
> The defined() operator is to protect you from trying to evaluate
> an expression with an undefined quantity.
> "foo" (with the quotes) is a legal string and hence a legal
> token to place in an expression.  So defined("foo") is TRUE.

OK, I see your perspective now; that the test is if and what the hunk of ascii code means to gnuplot's parser.  What exactly the utility of that is, I don't know.

> 
> This is no stranger than
> 	print defined(42)
> or	print defined(sin(x))
> or for that matter
> 	print (4 || 2)

I think it is stranger.  I mean, 4||2 is part of the language, the math rules.  Nowhere in 4||2 is there any kind of *variable*.  Now reading the documentation, I see:

Subtopic of functions: defined
 `defined(X)` returns 1 if a variable named X has been defined, otherwise
 it returns 0.

specifically "variable named X", key word "variable".

> 
> The problem is not in the syntax of defined(); the problem
> is that you should not be trying to "print" a BOOLEAN.  It would
> be nicer if 'print defined(1)' resulted in printing the string
> TRUE, but I don't see a way to do that. 

I actually think this should be easier; just look in the linked list for a definition matching.  If it is there, the variable is defined (1), otherwise (0).

Here's how Octave behaves:

octave:2> exist("foo")
ans = 0
octave:3> foo = 23
foo = 23
octave:4> exist("foo")
ans = 1
octave:5>

Should everything behave like Octave?  No, but one would think similar in concept, because afterall as in many languages gnuplot has similar concepts like x*y, sin(x)/y, etc.

> 
> If there is a bug lurking anywhere here, it is that 
> 	print defined(0)
> results in 0 rather than 1.
> 

The thing is that "defined()" is currently returning the definition of something, it is not answering the question as to whether something is defined.

I say it is much more than that.  I still don't see anything as to why the defined("foo") vs. defined(foo) should be any less confusing to a marginally familiar user; the programmer's perspective is different from the user's on this I think.  Also, I see little utility in defined("foo") or defined(1) in light of what the gnuplot documentation says.  In the same category as defined(0), there is

gnuplot> print defined(1/0)
               ^
         undefined value

This one is funny because certainly 1/0 has meaning in gnuplot, so why doesn't "defined(1/0)" evaluate to non-zero by it's current interpretation?  Or!  :-)  1/0 means an undefined value, so why doesn't "defined(1/0)" return 0?  Instead, it returns undefined value, which is not the same as

gnuplot> print defined(blah(x))
         undefined function: blah


I'll conclude this like the discussion of a couple weeks ago... Put me in the "if it's a defined variable 1, otherwise 0" camp, for what it's worth.

Dan

Re: defined

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

On Monday 29 May 2006 05:53 pm, Daniel J Sebald wrote:
> >>
> >>gnuplot> print defined("foo")
> >>141158968
> > 
> > We don't have a user-visible TBOOLEAN type, 
> > so any non-zero value represents "TRUE"
> 
> Right.  The point is that the test and the result are meaningless.  
> foo was never defined, so if anything the result should be zero.  

I think you are looking at this the wrong way.
The defined() operator is to protect you from trying to evaluate
an expression with an undefined quantity.
"foo" (with the quotes) is a legal string and hence a legal
token to place in an expression.  So defined("foo") is TRUE.

This is no stranger than
	print defined(42)
or	print defined(sin(x))
or for that matter
	print (4 || 2)

The problem is not in the syntax of defined(); the problem
is that you should not be trying to "print" a BOOLEAN.  It would
be nicer if 'print defined(1)' resulted in printing the string
TRUE, but I don't see a way to do that. 

If there is a bug lurking anywhere here, it is that 
	print defined(0)
results in 0 rather than 1.

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

How to change the heading "gnuplot"

[renjith p. p. <ren...@ya...>]

Sir/Madam,
   
  I am using GnuPlot to plot experimental data. 
  1) I want to change the heading from "GNUPLOT" to the name of my program. How to do it?
   
  2) Next thing is, if i am using multiplot to draw 3 grids. they are not clearly visible. the grid is very small and the space between the grid is very large. How  can i reduce the space betwee the grids.
   
  Please help me at the earliest.

		
---------------------------------
Feel free to call! Free PC-to-PC calls. Low rates on PC-to-Phone.  Get Yahoo! Messenger with Voice

Re: defined

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

Ethan A Merritt wrote:
> On Monday 29 May 2006 03:28 pm, Daniel J Sebald wrote:
> 
>>This seems like a bug, even though the syntax is incorrect... but a user might think the syntax is correct if gnuplot doesn't complain but rather returns a non-zero value that will always test positive.
>>
>>gnuplot> print defined("foo")
>>141158968
> 
> 
> We don't have a user-visible TBOOLEAN type, 
> so any non-zero value represents "TRUE"

Right.  The point is that the test and the result are meaningless.  foo was never defined, so if anything the result should be zero.  But this is not proper syntax.  Proper syntax is

 `defined(X)` returns 1 if a variable named X has been defined, otherwise
 it returns 0.

so,

gnuplot> print defined(foo)
0

which is correct.  However, the user could unknowingly be typing

defined("foo")

oblivious to the fact that it is meaningless.


>>Also, would it be useful to extend defined() from just variables to functions as well?  
>>Say, return 1 if user defined variable, 2 if internal variable, 3 if user defined function, 
>>4 if internal function.  
> 
> 
> What would you do with this information?

Pretty much any kind of test one would do similar to checking for variables, I would guess.


> That comment is confusing to me already.  My reading of the
> code leads me to believe that gnuplot will always provide a
> lgamma() function.  Again there is a question of whether this
> came from a system library or not.  But either way you can
> use the function.

Yes, I kind of concluded that too.  Just toss the comments and make life easy.  Even still, defined() on functions might have a purpose.

Dan

Re: defined

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

On Monday 29 May 2006 03:28 pm, Daniel J Sebald wrote:
> This seems like a bug, even though the syntax is incorrect... but a user might think the syntax is correct if gnuplot doesn't complain but rather returns a non-zero value that will always test positive.
> 
> gnuplot> print defined("foo")
> 141158968

We don't have a user-visible TBOOLEAN type, 
so any non-zero value represents "TRUE"
 
> Also, would it be useful to extend defined() from just variables to functions as well?  
> Say, return 1 if user defined variable, 2 if internal variable, 3 if user defined function, 
> 4 if internal function.  

What would you do with this information?

> That way, the defined() function could be used inside stat.inc as
> 
> if (defined(gamma)!=3) gamma(x) = exp(lgamma_nat(x))

But that will always be true.
The conditional compilation is set during configuration so that you
always get a gamma function.  The only question is whether you get
one from a system library or whether you get one from gnuplot's 
inline code.

> then get rid of these comments like:
> 
> # If you have the lgamma() function compiled into gnuplot

> As soon as someone starts uncommenting/commenting code it becomes confusing.

That comment is confusing to me already.  My reading of the
code leads me to believe that gnuplot will always provide a
lgamma() function.  Again there is a question of whether this
came from a system library or not.  But either way you can
use the function.





> , you can use 
> # alternate definitions for some PDFs. For larger arguments this will result
> # in more efficient evalution. Just uncomment the definitions containing the
> # string `lgamma', while at the same time commenting out the originals.
> # NOTE: In these cases the recursive definition for lgamma() is NOT sufficient!
> 
> 
> 
> Last, how about an internally defined 'eps' or something similar to represent float machine precision?
> 
> 
> Oh, one other thing.  Any interest in a complex version of the gamma function?
> 

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

defined

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

This seems like a bug, even though the syntax is incorrect... but a user might think the syntax is correct if gnuplot doesn't complain but rather returns a non-zero value that will always test positive.

gnuplot> print defined("foo")
141158968
gnuplot> print defined("foo")
141159440
gnuplot> print defined("foo")
141159544
gnuplot> print defined("foo")
141159880
gnuplot> print defined("foo")
141160112
gnuplot> print defined("foo")
141160216


Also, would it be useful to extend defined() from just variables to functions as well?  Say, return 1 if user defined variable, 2 if internal variable, 3 if user defined function, 4 if internal function.

That way, the defined() function could be used inside stat.inc as

if (defined(gamma)!=3) gamma(x) = exp(lgamma_nat(x))

then get rid of these comments like:

# If you have the lgamma() function compiled into gnuplot, you can use
# alternate definitions for some PDFs. For larger arguments this will result
# in more efficient evalution. Just uncomment the definitions containing the
# string `lgamma', while at the same time commenting out the originals.
# NOTE: In these cases the recursive definition for lgamma() is NOT sufficient!

As soon as someone starts uncommenting/commenting code it becomes confusing.


Last, how about an internally defined 'eps' or something similar to represent float machine precision?


Oh, one other thing.  Any interest in a complex version of the gamma function?


Dan

Re: [ 1496624 ] bug manifested in internal function commands

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

Ethan A Merritt wrote:
> On Monday 29 May 2006 04:06 am, Hans-Bernhard Br=F6ker wrote:
>=20
>>The problem is in 'reset': that command is not supposed to as much as=20
>>*look* at the user-defined variables in the first place, much less=20
>>remove any of them, whether they're in limbo or not.
>=20
>=20
> It only removes undefined variables. This is only garbage-collection
> mechanism we have for such space, so if you remove it we will end
> up with the opposite problem of a memory leak.
>=20
> The issue is that the parsing code uses add_udv(), which results in=20
> space allocation for every variable mentioned, whether or not it is
> a correctly defined variable. For example:
> 	print nonsense
> allocates space for a variable "nonsense" before reporting that it
> is undefined.  This space will only be released if you later define
> "nonsense" properly, or do a reset.=20
>=20
>=20
>>gnuplot> f(x) =3D x+a
>>gnuplot> g(x) =3D x+b
>>gnuplot> plot f(x)
>>        undefined variable: a
>=20
> I am inclined to say that the definition of f(x) should fail if there=20
> is no previously-defined variable 'a'.

Well, that is an alternative.  It's the same thing as I was just looking =
at for checking that the number of input variables to a function match.  =
(A very useful feature, BTW.)  At first my thinking was that gnuplot shou=
ld complain if it tries to use a function that hasn't been defined and do=
esn't have the correct number of input variables.

But then I saw that gnuplot seems to be set up to not check/verify anythi=
ng until interpretation.  I personally wouldn't get into a programming ha=
bit of using variables I haven't defined, but I can live with that philos=
ophy.

If that is the concept, then neither functions (as is currently the case)=
 nor variables can be removed even if they are undefined, unless intentio=
nally removed.

Whatever the case, both functions and variables should behave the same wa=
y.

As for cleaning up the variable space, an eventual 'reset' or 'unset' to =
do that would be good.

I would say that having the function argument keep track of the memory po=
inter as well as the linked list of variables is marginal programming pra=
ctice.  Pointers in lists are something that should only be used temporar=
ily on the fly, and not stored in multiple places.  I see the issue, howe=
ver, which is speed.  Can the pointers be looked up at the time of the pl=
ot command, used in the command, and then discarded?  [Keep in mind I don=
't understand the code too well, that's why I punted.]


> Alternatively, the code that creates an evaluation stack for 'f(x)'
> could initialize a to 0 rather than leaving it undefined.

That I don't think is acceptable.  If I define a function involving some =
variable I've not defined and gnuplot assumes it equals zero, that wouldn=
't be good.  I could never know the difference in some instances of compl=
icated functions I'm not familiar with.

Dan

Re: [ 1496624 ] bug manifested in internal function commands

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

On Monday 29 May 2006 04:06 am, Hans-Bernhard Br=F6ker wrote:
>=20
> The problem is in 'reset': that command is not supposed to as much as=20
> *look* at the user-defined variables in the first place, much less=20
> remove any of them, whether they're in limbo or not.

It only removes undefined variables. This is only garbage-collection
mechanism we have for such space, so if you remove it we will end
up with the opposite problem of a memory leak.

The issue is that the parsing code uses add_udv(), which results in=20
space allocation for every variable mentioned, whether or not it is
a correctly defined variable. For example:
	print nonsense
allocates space for a variable "nonsense" before reporting that it
is undefined.  This space will only be released if you later define
"nonsense" properly, or do a reset.=20

> gnuplot> f(x) =3D x+a
> gnuplot> g(x) =3D x+b
> gnuplot> plot f(x)
>         undefined variable: a
I am inclined to say that the definition of f(x) should fail if there=20
is no previously-defined variable 'a'.

Alternatively, the code that creates an evaluation stack for 'f(x)'
could initialize a to 0 rather than leaving it undefined.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: no duplicated lines for GNU readline history

[Peter W. <pe...@we...>]

>>> No, it is not that. I want to remove duplicates in the history. E.g.
>>> entering commands
>>>    set grid
>>>    history
>>>    set grid
>>>    history
>>>    set grid
>>>    history
>>>    set grid
>>>    history
>>>
>>> will result in the above sequence, but with the gnuplot's readline it will
>>> have always just these two entries:
>>>    set grid
>>>    history
>>> as all the previous history duplicates will be removed.
>>>
>>> Can the same be achieved with GNU readline? (It is more user friendly ...
>>> no need to browse so long to find a command. The exact history is useless.)
>>
>> I don't think so. Duplicate removal in GNU readline only removes subsequent
>> entries, i.e.
>>
>> ls
>> ls
>> ls
>>
>> is condensed into one.

That already happens AFAICS.

> Then it would be great it this feature could implemented by somebody. I see 
> in ChangeLog that the last hack to GNU readline is
> 
> 2005-05-20  SF Patch [981476] "Get history functions working with GNU readline"

Shouldn't be too difficult to add the feature you want, so that no
duplicate entry gets added to the history. I might be able to take a
look at this in the next days. (But I always say that and then it it
weeks before I get to it if nobody reminds me.)

   Peter.

Re: [ 1496624 ] bug manifested in internal function commands

[<br...@ph...>]

Daniel J Sebald wrote:
> gnuplot> f(x) = x+a
> gnuplot> g(x) = x+b
> gnuplot> plot f(x)
>         undefined variable: a
> gnuplot> reset
> gnuplot> plot f(x)
>         undefined variable: 4

The problem is in 'reset': that command is not supposed to as much as 
*look* at the user-defined variables in the first place, much less 
remove any of them, whether they're in limbo or not.

[ 1496624 ] bug manifested in internal function commands

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

I wrote up a bug report on a bad pointer which manifests itself as stuff like this:

Terminal type set to 'x11'
gnuplot> f(x) = x+a
gnuplot> g(x) = x+b
gnuplot> plot f(x)
         undefined variable: a
gnuplot> reset
gnuplot> plot f(x)
         undefined variable: 4

The 4 is just some random gibberish and will sometimes crash.

I'd rather someone else fix this one because the solution will be quite involved, but I've described in detail in the bug report exactly where/why it is crashing.

Dan

Re: discontinuity feature worthwhile?

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

Daniel J Sebald wrote:

> I still think
> 
> plot [-1:1-eps,1:3] pareto(x), [-1:4] cos(x)
> 
> would be nicer.  Granted, parametric works.

Well, after thinking about this, a slight change of heart.  The above syntax would be convenient.  The thing is, if the function has not just a discontinuity, but also a singularity then often one wants a higher density sampling near the singularity.  To get a non-uniform sampling requires parametric mode.

Dan

Re: discontinuity feature worthwhile?

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

Hans-Bernhard Br=F6ker wrote:

>> The only problem is choosing the plot range and samples correctly so=20
>> that the discontinuity ends up being selected. =20
>=20
>=20
> No.  The problem is that tuning of equidistant sampling can typically=20
> only be done to match *one* discontinuity --- but there's no way of=20
> telling how many discontinuities a plotted function might have in the=20
> plotted range, or where they'll be.

I had in mind each subrange could be treated with the same number of poin=
ts and not get too elaborate.  If it is oversampling on one region, so be=
 it.  (In essence, pretty much the same behavior of the parametric mode e=
xample you give.)

>=20
>> OK, well, then here is something else that would make plotting=20
>> discontinuities a little nicer.  Say f(x) is defined as above
>>
>> f(x) =3D x<1?0:1/x
>>
>> and I were able to plot subranges in my plot
>>
>> plot [x=3D-1:1-epsilon] f(x) with lines lc rgb "red", [x=3D1+epsilon:4=
]=20
>> f(x) with lines lc rgb "red"
>=20
>=20
> You *are* able to do that, once you switch to parametric mode.
>=20
>     set parametric
>     set trange [0:1-epsilon]
>      x1(t)=3D-1+2*t
>     x2(t)=3D1+3*t
>     plot x1(t),f(x1(t)),   x2(t), f(x2(t))

Oh yeah, parametric mode.  (All the possibilities!)  I will include this =
for a couple examples then, thanks.

I still think

plot [-1:1-eps,1:3] pareto(x), [-1:4] cos(x)

would be nicer.  Granted, parametric works.

>=20
>> the plotting process 1-epsilon is basically cast to 1.0.  (BTW, why=20
>> does putting the range in the plot override the "set xrange [#,#]"=20
>> command? =20
>=20
>=20
> Because that's what _all_ optional elements of a 'plot' command do, in=20
> gnuplot: they override whatever the default for some property of the=20
> plot might be.  'with <style>' overrides 'set style function' or 'set=20
> style data', 'linetype <n>' overrides the colour, and a range overrides=
=20
> the corresponding 'set *range'.

Well, that was my line of thinking.  When I say

plot x ls 4, x**2

the line style of 4 applies *only* to the first graph.  It does not apply=
 to all the graphs on the plot.  But I guess since {xrange} is before all=
 the functions it could be argued it should apply to all functions.

Dan

Re: discontinuity feature worthwhile?

[<br...@ph...>]

Daniel J Sebald wrote:
> I've been tweaking the examples in prob.dem to be a little more accurate 
> and mathematically correct visually.  And it occurs to me that it might 
> be nice for gnuplot to handle discontinuities in an elegant way.

Would be nice if it were actually possible, but it isn't.  Seriously.

The only way for gnuplot to distinguish a true discontinuity from a mere 
fast variation in a plotted function would be to add a full analytical 
maths engine.  And that's before you consider that for data plots the 
whole concept of continuity doesn't exist in the first place.

If people want an analytic maths engine that understands calculus, I 
hope they'll know where to find MuPAD, Maple, Mathematica or something 
like them.

> But on second thought, why shouldn't a plotting program be able to
> leave out the line connecting the left and right limits of a
> discontinuity?

Because it can't really know whether that's discontinuity or not.

> The only problem is choosing the plot range and samples correctly so 
> that the discontinuity ends up being selected.  

No.  The problem is that tuning of equidistant sampling can typically 
only be done to match *one* discontinuity --- but there's no way of 
telling how many discontinuities a plotted function might have in the 
plotted range, or where they'll be.

> OK, well, then here is something else that would make plotting 
> discontinuities a little nicer.  Say f(x) is defined as above
> 
> f(x) = x<1?0:1/x
> 
> and I were able to plot subranges in my plot
> 
> plot [x=-1:1-epsilon] f(x) with lines lc rgb "red", [x=1+epsilon:4] f(x) 
> with lines lc rgb "red"

You *are* able to do that, once you switch to parametric mode.

	set parametric
	set trange [0:1-epsilon]
  	x1(t)=-1+2*t
	x2(t)=1+3*t
	plot x1(t),f(x1(t)),   x2(t), f(x2(t))

> the plotting process 1-epsilon is basically cast to 1.0.  (BTW, why does 
> putting the range in the plot override the "set xrange [#,#]" command?  

Because that's what _all_ optional elements of a 'plot' command do, in 
gnuplot: they override whatever the default for some property of the 
plot might be.  'with <style>' overrides 'set style function' or 'set 
style data', 'linetype <n>' overrides the colour, and a range overrides 
the corresponding 'set *range'.

discontinuity feature worthwhile?

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

I've been tweaking the examples in prob.dem to be a little more accurate and mathematically correct visually.  And it occurs to me that it might be nice for gnuplot to handle discontinuities in an elegant way.

When a person is writing on a chalk board or scribbling on paper, a lot of time we just treat a discontinuity as though it is some kind of sharp transition, i.e., we connect the left and right limits and take it as understood as a discontinuity.  But on second thought, why shouldn't a plotting program be able to leave out the line connecting the left and right limits of a discontinuity?

Here's an example and a couple thoughts.  Here's an attempt to plot a function for which f(x) = 0 for x < 1 and f(x) = 1/x for x >= 1; first with a plot for such a definition and second in a piecewise fashion that works, but some might consider a hack:

f(x) = x<1?0:1/x
set xrange [-1:4]
set yrange [-0.1:1.1]
set samples (4-(-1))*50 + 1
set term x11 1
plot f(x)
set term x11 2
plot x<1?f(x):x==1?0:1/0 with lines lc rgb "red", x>=1?f(x):1/0 with lines lc rgb "red"

Notice that in the above I set the number of samples and limits so that x=1.0, the discontinuity is selected as a plot point.

Wouldn't it be nice if one could somehow define some function g(x) so that

plot g(x)

produced just what the second plot did?  (This may not work... so bear with me.)  For example, say that one could attach left and right limits to the value 1/0.  (I'll do this with some concocted syntax for now.)

g(x) = x<1?0:x>1?1/x:(1/0,0,1/x)

which means that if the value x==1 is encountered in this case the point is treated as 0 connecting the point to the left and 1/1 = 1 when connecting the point to the right.  The f(x) as defined at top would still plot the way it currently does, and if one simply put 1/0 rather than (1/0,<left limit>,<right limit>) things would still plot the way they currently do.

I'm not sure what the container class looks like in general, but with all the extra fields in gnuplot, you'd think that when the value is 1/0 and other fields like xhigh and xlow make no sense, they could be use instead for left and right limits.

The only problem is choosing the plot range and samples correctly so that the discontinuity ends up being selected.  So in some sense, this might not be a feature that any but the most informed users would be able to figure out.  Maybe we can conclude defining discontinuities as part of a function is a bad idea, I don't know.

OK, well, then here is something else that would make plotting discontinuities a little nicer.  Say f(x) is defined as above

f(x) = x<1?0:1/x

and I were able to plot subranges in my plot

plot [x=-1:1-epsilon] f(x) with lines lc rgb "red", [x=1+epsilon:4] f(x) with lines lc rgb "red"

where epsilon is either a constant defined to be the resolution of real numbers or it is command syntax meaning the same thing.  The evaluation of f(1-epsilon) would of course be 0, but when all is said in done in the plotting process 1-epsilon is basically cast to 1.0.  (BTW, why does putting the range in the plot override the "set xrange [#,#]" command?  You'd think if it were autoscale, then yes override, but otherwise why should it?)

Alright, well can this be improved upon?  Could the syntax of a plot range be extended as, say,

plot [x=-1:1-epsilon:1+epsilon:4] f(x)

?  Which means to draw two red segments, one from -1 to 1-epsilon and from 1+epsilon to 4.  That way we get rid of the multiple sections of "lc "red"" stuff.

But that too is limiting, let's say we want two functions with discontinuities.  I'd say combine the previous two suggestions and you'd get

plot [x=-1:1-epsilon:1+epsilon:4] f(x), [x=-1:2-epsilon:2+epsilon:4] f(x-1)

being a red function with a discontinuity and a green, delayed function with a discontinuity.  [I say delayed because in engineering we usually think of the x axis as time and f(x-D) as a delay of D.]

Two discontinuities?

plot [x=-1:1-eps:1+eps:2-eps:2+eps:4] ff(x)

and so on.  I kind of like the latter syntax now that I write it.

Dan

Re: no duplicated lines for GNU readline history

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

>> No, it is not that. I want to remove duplicates in the history. E.g.
>> entering commands
>>    set grid
>>    history
>>    set grid
>>    history
>>    set grid
>>    history
>>    set grid
>>    history
>>
>> will result in the above sequence, but with the gnuplot's readline it will
>> have always just these two entries:
>>    set grid
>>    history
>> as all the previous history duplicates will be removed.
>>
>> Can the same be achieved with GNU readline? (It is more user friendly ...
>> no need to browse so long to find a command. The exact history is useless.)
>
> I don't think so. Duplicate removal in GNU readline only removes subsequent
> entries, i.e.
>
> ls
> ls
> ls
>
> is condensed into one.

Then it would be great it this feature could implemented by somebody. I see 
in ChangeLog that the last hack to GNU readline is

2005-05-20  SF Patch [981476] "Get history functions working with GNU readline"

---
PM

Re: no duplicated lines for GNU readline history

[Lars H. <lhe...@us...>]

> 
> No, it is not that. I want to remove duplicates in the history. E.g. 
> entering commands
>    set grid
>    history
>    set grid
>    history
>    set grid
>    history
>    set grid
>    history
> 
> will result in the above sequence, but with the gnuplot's readline it will 
> have always just these two entries:
>    set grid
>    history
> as all the previous history duplicates will be removed.
> 
> Can the same be achieved with GNU readline? (It is more user friendly ... 
> no need to browse so long to find a command. The exact history is useless.)

 I don't think so. Duplicate removal in GNU readline only removes subsequent
 entries, i.e.

 ls
 ls
 ls

 is condensed into one.

Re: no duplicated lines for GNU readline history

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

>> Gnuplot's own readline does not keep duplicated lines in the history, so
>> browsing the command line is much faster than with GNU readline. Does
>> someone know whether the latter can be switched to behave the same way?
>
> Completion Variables
> --------------------
> ..
> - Variable: int rl_ignore_completion_duplicates
>     If non-zero, then duplicates in the matches are removed.  The
>     default is 1.

No, it is not that. I want to remove duplicates in the history. E.g. 
entering commands
    set grid
    history
    set grid
    history
    set grid
    history
    set grid
    history

will result in the above sequence, but with the gnuplot's readline it will 
have always just these two entries:
    set grid
    history
as all the previous history duplicates will be removed.

Can the same be achieved with GNU readline? (It is more user friendly ... no 
need to browse so long to find a command. The exact history is useless.)

---
PM