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

Re: underscore in text

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

On Monday, 21 October, 2013 15:36:23 Jonathan Thornburg wrote:
> On Mon, 21 Oct 2013, Ethan A Merritt wrote:
> > Recent cvs defaults to enhanced text mode.
> [[...]]
> > I would have thought that underscores in user-supplied titles and labels
> > were more likely to be intended as subscripts than literals, but I could be wrong.
> > 
> > What would you prefer?
> > Revert the change in default terminal setting?
> > Revert the default state of just the "set title" command?
> > More obvious warnings that something has changed?
> > Some other combination?
> 
> I was (am) under the impression that strings in "double quotes" use
> enhanced mode if it's enabled, while strings in 'single quotes' never
> use enhanced mode.  Is this correct?

No. That has never been true that I recall.

See "help quotes"

	Ethan

Re: underscore in text

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

On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote:
> I'm wondering when this changed, and whether the change was intentional: 
> it used to be that if you did, say,
> 
> set title 'Under_score'
> 
> then (at least when using the wxt and x11 terminals) the text came out 
> shown, with an underscore. Now (recent CVS[*]) The underscore produces a 
> subscript 's' (in wxt and x11).

Recent cvs defaults to enhanced text mode.
We can discuss whether this is a good thing or a bad thing, or a good thing
thing in principle that needs adjustment in practice.

This is not the sort of change in expectations that would be acceptable within
a minor version series (4.2 4.4 4.6)   but seems to me OK to explore as we
head towards a major version 5 release.

The motivation for the change was to support "prettier" default formats for
axis tic labels.  The new default format " %h" produces, for example, 
1.2 x 10^6     as a label rather than   1.2e06
See discussion here:
     https://sourceforge.net/p/gnuplot/patches/637/
and here
     https://sourceforge.net/mailarchive/message.php?msg_id=31498730

It seemed kind of pointless to change the default format without also
enabling the enhanced text mode needed to produce it.

The enhanced/noenhanced attribute can still be applied to everything
 e.g.   set termoption noenhanced
or to an individual plot element
 e.g    set title "under_score" noenhanced

Some plot elements have always defaulted to noenhanced and continue
to do so.  For instance autogenerated key entries default to noenhanced 
so as to preserved underscores in a file name or function name.

Other plot elements, like "set title",  have always defaulted to  enhanced,
though of course this doesn't actually take effect unless enhanced text
mode is globally enabled.  

I would have thought that underscores in user-supplied titles and labels
were more likely to be intended as subscripts than literals, but I could be wrong.

What would you prefer?
Revert the change in default terminal setting?
Revert the default state of just the "set title" command?
More obvious warnings that something has changed?
Some other combination?

FWIW, I've just noticed that the enhanced/noenhanced attribute of the
plot title is sticky, but which I mean that it isn't touched by a "reset" command.
>From the perspective of 4.6, that's a bug.
>From the perspective of your query, maybe it's a feature :-)
That is, you could put "set title noenhanced" in ~/.gnuplot and for your
own sessions it would always be that way unless explicitly changed.


> It seems to me that it's more intuitive to 
> have to do something special to get a superscript than having to do 
> something special to get an underscore when you want one.

Perhaps.  I don't think it is intrinsically more or less intuitive than having to
escape backslashes, tabs, dollar signs, etc.  It's just a matter of what you
are expecting.

	Ethan

underscore in text

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

I'm wondering when this changed, and whether the change was intentional: 
it used to be that if you did, say,

set title 'Under_score'

then (at least when using the wxt and x11 terminals) the text came out 
shown, with an underscore. Now (recent CVS[*]) The underscore produces a 
subscript 's' (in wxt and x11). It seems to me that it's more intuitive to 
have to do something special to get a superscript than having to do 
something special to get an underscore when you want one.

[*] I can't say "current CVS" because when I try updating today I'm 
getting the message:

Fatal error, aborting.
anoncvs_gnuplot: no such system user

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

Re: glitch in cosine

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

[Ooops, forgot to CC the list.]

On 21.10.2013 02:40, sfeam wrote:
> I suspect that despite your large value for "set sample"
> you are still sampling too coarsely by a factor of a thousand or so.
> The smooth curve you see is probably an aliasing artifact.

The setting of "set samples" has no effect on this plot, because the
plot is made from data:

	plot  datafile u (($1)/365.25+1945):(f3($1)) w l

But neither the current CVS version nor 4.6.2 shows the problem here.
The reason for that may very well be that the subset of the data
presented to us is missing one data point (at 22671, transformed x value
2007.07), which might be just where that "peak" is.

Re: glitch in cosine

[<pl...@pi...>]

On 10/21/13 02:40, sfeam wrote:
> On Sunday, 20 October 2013 08:22:51 PM you wrote:
>> Hi,
>>
>> I have a curious glitch in plotting the sum of three cosines.
>>
>> set samples 1700
>>
>>              twopi=2*pi
>>             c1(x)=a1*cos(twopi*(x-yz+ph1)/p1)
>>             c2(x)=a2*cos(twopi*(x-yz+ph2)/p2)
>>             c3(x)=a3*cos(twopi*(x-yz+ph3)/p3)
>>             f3(x)=c1(x)+c2(x)+c0+c3(x)
>>
>>    a1=a2=a3=1; c0=3.; yz=1958; p1=1.0;p2=0.5;p3=.25; ph1=ph2=ph3=.1
>>    a3=1;ph3=0.1;p3=0.25
>>
>> fit f3(x) datafile   u (($1)/365.25+1945):2 via
>> a1,a2,c0,ph1,ph2,p2,p3,a3,ph3
>>
>>    plot  datafile u (($1)/365.25+1945):(f3($1)) w l
>
> I suspect that despite your large value for "set sample"
> you are still sampling too coarsely by a factor of a thousand or so.
> The smooth curve you see is probably an aliasing artifact.
>
> 	Ethan
>
>
>
>
>>
>> data either side of that point seem fine and if I use it directly with
>> plot "-" I don't get the glitch.
>>
>>
>> Closing gnuplot session and repeating the plot from file gives same
>> result seen in attached png flie.
>>
>> For the benefit of the list that don't see the file, it looks like a
>> cosine ranging -0.07 and + 0.014 pk to pk with some small ripple with
>> sporadic spikes ranging from 0.025 to 0.075 , glitches are just single
>> points.
>>
>> Irrespective of the actual data fed in , I fail to see how the sum of
>> cosines can have such glitches.
>>
>>
>> If anyone can explain how that could happen I'd like to know, otherwise
>> it looks like a bug.
>>
>> Thanks, Peter.
>>
>>
>>
>>
>>
>>     plot  "-" u (($1)/365.25+1945):(f3($1)) w l
>>
>> 22629  381.81
>> 22636  381.88
>> 22643  381.65
>> 22650  382.62
>> 22657  382.25
>> 22664  381.37
>> 22678  383.09
>> 22685  383.59
>> 22692  384.19
>> 22699  383.76
>> 22706  383.71
>> 22713  383.64
>> 22720  384.28
>> e
>>
>>
>>
>>
>> Final set of parameters            Asymptotic Standard Error
>> =======================            ==========================
>>
>> a1              = 0.0486237        +/- 0.001654     (3.402%)
>> a2              = 0.0265777        +/- 0.001788     (6.728%)
>> c0              = 0.00416031       +/- 0.001169     (28.1%)
>> ph1             = -0.0557476       +/- 0.005409     (9.703%)
>> ph2             = 0.163801         +/- 0.009924     (6.059%)
>> p2              = 0.49982          +/- 0.0001585    (0.03171%)
>> p3              = 0.258274         +/- 0.0005954    (0.2305%)
>> a3              = -0.00192983      +/- 0.00202      (104.7%)
>> ph3             = -0.923156        +/- 0.06458      (6.996%)
>>
>>    G N U P L O T
>>           Version 4.7 patchlevel 0    last modified 2012-10-16
>>           Build System: Linux i686
>>
>>
>

HI,

aliasing was my first thought too but
  set samples 1700000; replot

same thing.


what I intend to be plotting is

  plot  datafile u (($1)/365.25+1945):(f3($1/365.25+1945)) w l

That works. but while fiddling I saw these glitches and went to see 
where they were coming from.

What looks buggy to me is that _whatever_ numbers I throw at it , the 
sum of three cosines should never have spikes.

Is this some internal underflow/overflow problem?

Thanks Ethan,

Re: glitch in cosine

[sfeam <sf...@us...>]

On Sunday, 20 October 2013 08:22:51 PM you wrote:
> Hi,
> 
> I have a curious glitch in plotting the sum of three cosines.
> 
> set samples 1700
> 
>             twopi=2*pi
>            c1(x)=a1*cos(twopi*(x-yz+ph1)/p1)
>            c2(x)=a2*cos(twopi*(x-yz+ph2)/p2)
>            c3(x)=a3*cos(twopi*(x-yz+ph3)/p3)
>            f3(x)=c1(x)+c2(x)+c0+c3(x)
> 
>   a1=a2=a3=1; c0=3.; yz=1958; p1=1.0;p2=0.5;p3=.25; ph1=ph2=ph3=.1
>   a3=1;ph3=0.1;p3=0.25
> 
> fit f3(x) datafile   u (($1)/365.25+1945):2 via 
> a1,a2,c0,ph1,ph2,p2,p3,a3,ph3
> 
>   plot  datafile u (($1)/365.25+1945):(f3($1)) w l

I suspect that despite your large value for "set sample"
you are still sampling too coarsely by a factor of a thousand or so.
The smooth curve you see is probably an aliasing artifact.

	Ethan




> 
> data either side of that point seem fine and if I use it directly with 
> plot "-" I don't get the glitch.
> 
> 
> Closing gnuplot session and repeating the plot from file gives same 
> result seen in attached png flie.
> 
> For the benefit of the list that don't see the file, it looks like a 
> cosine ranging -0.07 and + 0.014 pk to pk with some small ripple with 
> sporadic spikes ranging from 0.025 to 0.075 , glitches are just single 
> points.
> 
> Irrespective of the actual data fed in , I fail to see how the sum of 
> cosines can have such glitches.
> 
> 
> If anyone can explain how that could happen I'd like to know, otherwise 
> it looks like a bug.
> 
> Thanks, Peter.
> 
> 
> 
> 
> 
>    plot  "-" u (($1)/365.25+1945):(f3($1)) w l
> 
> 22629  381.81
> 22636  381.88
> 22643  381.65
> 22650  382.62
> 22657  382.25
> 22664  381.37
> 22678  383.09
> 22685  383.59
> 22692  384.19
> 22699  383.76
> 22706  383.71
> 22713  383.64
> 22720  384.28
> e
> 
> 
> 
> 
> Final set of parameters            Asymptotic Standard Error
> =======================            ==========================
> 
> a1              = 0.0486237        +/- 0.001654     (3.402%)
> a2              = 0.0265777        +/- 0.001788     (6.728%)
> c0              = 0.00416031       +/- 0.001169     (28.1%)
> ph1             = -0.0557476       +/- 0.005409     (9.703%)
> ph2             = 0.163801         +/- 0.009924     (6.059%)
> p2              = 0.49982          +/- 0.0001585    (0.03171%)
> p3              = 0.258274         +/- 0.0005954    (0.2305%)
> a3              = -0.00192983      +/- 0.00202      (104.7%)
> ph3             = -0.923156        +/- 0.06458      (6.996%)
> 
>   G N U P L O T
>          Version 4.7 patchlevel 0    last modified 2012-10-16
>          Build System: Linux i686
> 
> 

glitch in cosine

[<pl...@pi...>]

Hi,

I have a curious glitch in plotting the sum of three cosines.

set samples 1700

            twopi=2*pi
           c1(x)=a1*cos(twopi*(x-yz+ph1)/p1)
           c2(x)=a2*cos(twopi*(x-yz+ph2)/p2)
           c3(x)=a3*cos(twopi*(x-yz+ph3)/p3)
           f3(x)=c1(x)+c2(x)+c0+c3(x)

  a1=a2=a3=1; c0=3.; yz=1958; p1=1.0;p2=0.5;p3=.25; ph1=ph2=ph3=.1
  a3=1;ph3=0.1;p3=0.25

fit f3(x) datafile   u (($1)/365.25+1945):2 via 
a1,a2,c0,ph1,ph2,p2,p3,a3,ph3

  plot  datafile u (($1)/365.25+1945):(f3($1)) w l


data either side of that point seem fine and if I use it directly with 
plot "-" I don't get the glitch.


Closing gnuplot session and repeating the plot from file gives same 
result seen in attached png flie.

For the benefit of the list that don't see the file, it looks like a 
cosine ranging -0.07 and + 0.014 pk to pk with some small ripple with 
sporadic spikes ranging from 0.025 to 0.075 , glitches are just single 
points.

Irrespective of the actual data fed in , I fail to see how the sum of 
cosines can have such glitches.


If anyone can explain how that could happen I'd like to know, otherwise 
it looks like a bug.

Thanks, Peter.





   plot  "-" u (($1)/365.25+1945):(f3($1)) w l

22629  381.81
22636  381.88
22643  381.65
22650  382.62
22657  382.25
22664  381.37
22678  383.09
22685  383.59
22692  384.19
22699  383.76
22706  383.71
22713  383.64
22720  384.28
e




Final set of parameters            Asymptotic Standard Error
=======================            ==========================

a1              = 0.0486237        +/- 0.001654     (3.402%)
a2              = 0.0265777        +/- 0.001788     (6.728%)
c0              = 0.00416031       +/- 0.001169     (28.1%)
ph1             = -0.0557476       +/- 0.005409     (9.703%)
ph2             = 0.163801         +/- 0.009924     (6.059%)
p2              = 0.49982          +/- 0.0001585    (0.03171%)
p3              = 0.258274         +/- 0.0005954    (0.2305%)
a3              = -0.00192983      +/- 0.00202      (104.7%)
ph3             = -0.923156        +/- 0.06458      (6.996%)

  G N U P L O T
         Version 4.7 patchlevel 0    last modified 2012-10-16
         Build System: Linux i686

Re: filledcurves doesn't work correctly on X11

[Dr. J. Z. <joh...@ze...>]

Hans-Bernhard,

thanks - this helped a lot, works on different versions of gnuplot and
solves my issue.

-- 
Johannes


2013/10/13 Hans-Bernhard Bröker <HBB...@t-...>

> On 13.10.2013 11:32, Dr. Johannes Zellner wrote:
>
>  set term X11
>> set parametric
>> plot sin(t), cos(t) w filledcurves
>>
>> gives the following plot:
>>
> [...]
>
>  is this a bug or did I make something wrong?
>>
>
> Possibly both.  You really should have specified a trange to get a proper
> circle with one turn.  Yours is about 1.6 turns, making it hard to know
> which area is supposed to be filled.  I.e.
>
>         plot [0:2*pi] sin(t), cos(t) w filledcurves
>
> might have worked better (it does here with 4.6.4 on Windows).  And you
> should have mentioned which version of gnuplot you observed this with.
>
>
>
>

Re: filledcurves doesn't work correctly on X11

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

On 13.10.2013 11:32, Dr. Johannes Zellner wrote:

> set term X11
> set parametric
> plot sin(t), cos(t) w filledcurves
>
> gives the following plot:
[...]
> is this a bug or did I make something wrong?

Possibly both.  You really should have specified a trange to get a 
proper circle with one turn.  Yours is about 1.6 turns, making it hard 
to know which area is supposed to be filled.  I.e.

	plot [0:2*pi] sin(t), cos(t) w filledcurves

might have worked better (it does here with 4.6.4 on Windows).  And you 
should have mentioned which version of gnuplot you observed this with.

Re: Feature request: configurable \times/\cdot and a bit about %h

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

On Thu, Oct 10, 2013 at 5:28 PM, sfeam wrote:
> On Thursday, October 10, 2013 02:19:12 PM Mojca Miklavec wrote:
>
>> It's not just about simplicity, but also about configurability. Let's
>> say that a user would want
>>     3×10<sup>6</sup>
>> rather than
>>     3x10<sup>6</sup>
>> even if UTF-8 isn't recognized.
>
> Huh?  How can you select a UTF-8 character if UTF-8 isn't recognized?

1. The character exists in many iso-8859-x encoding, also in
cp1250/cp1252 for example (I didn't try to do extensive checks to see
where else), but it is encoded differently (it's still D7, but it
consists of a single byte rather than two bytes like in UTF-8). So you
actually just reminded me of an additional case where the user might
want to change the sign: to use multiplication sign under a different
encoding (of course the code could also be improved to recognize
different encodings and print the proper character for them).

2. I don't have a clean overview of different terminals, but LaTeX,
ConTeXt & related terminals don't need to set the UTF-8 or any other
encoding for that matter to be usable. Imagine for a while a terminal
that outputs plain text (like LaTeX does), but doesn't set
TERM_IS_LATEX that would substitute the character for "\times". I
often created *.plt scripts in cp1250, I used cp1250-encoded strings
in "set title" and I used "\usepackage[cp1250]{inputenc}" in the main
LaTeX document which included the plot. That created perfectly usable
files with all the non-ascii characters properly encoded, without
setting an explicit encoding in gnuplot. Gnuplot was just piping the
characters through and everything worked. I believe in such a mode
(without explicitly setting some encoding) there is currently no way
to get the proper multiplication sign.

>> > A related question:
>> >
>> > At the moment the new code checks for TERM_IS_LATEX and if so
>> > replaces the default format "%h" with "$%h$".   I.e. it uses the same
>> > format but wraps it in $...$ so that LaTeX uses numerical mode.
>> > Would it be a good idea to _always_ do this?   Or maybe always do
>> > it if the format does not already contain $ signs?
>>
>> What exactly do you mean with "always"? If I use "set title 'some
>> text'" I don't want it to be enclosed in dollar signs for example.
>
> Only for "set format"
>
>> Which cases exactly fall under "alway wrap it in $...$"?
>>
>> In my old scripts I was often using something like (please excuse me
>> if I used the wrong format specifiers here):
>>     set format y "\\m{%t}{%T}"
>> where the master document defined
>>     \def\m#1#2{$#1\cdot10^{#2}$}
>
> That example is way over my head.
> I don't recognize the syntax at all.

I basically achieved the same output as the new code. It is just that
I asked gnuplot to print
    \m{3}{5}
or maybe
    3\E{5}
into the label and LaTeX ended up typesetting
    $3\cdot10^{5}$

Gnuplot saw 6 or 8 characters instead of 14 which made the labels
considerably smaller. (Before LaTeX had its own way of counting
characters which is still not perfect.)

>> I guess this would fail then?
>
> Yes it would.  So maybe it it wasn't a good idea.
> I can revert it to only wrap the default format, not user-defined formats.

The main question is whether it can be reverted easily be the user
(whether user can turn it of it becomes annoying). Another flaw of
always putting the dollar signs around the labels (other than users
putting TeX commands there which add dollar signs themselves - like my
example above) is the use of comma as a decimal separator which
introduces extra space when in text mode (unless instructed
differently). So "$3,5$" basically becomes "3, 5" when typeset.

Now again, gnuplot could try to be "smart enough" to replace "$3,5$"
by "$3{,}5$", the only question is when this all ends and when it
starts interfering with users who know exactly what they are doing. I
need to check what happens with a combination of %h and decimal comma
right now.

Mojca

Re: Feature request: configurable \times/\cdot and a bit about %h

[sfeam <sf...@us...>]

On Thursday, October 10, 2013 02:19:12 PM Mojca Miklavec wrote:
> On Wed, Oct 9, 2013 at 7:36 PM, Ethan A Merritt wrote:
> > On Wednesday, 09 October, 2013 15:26:29 Mojca Miklavec wrote:

> > "set format '%H'" is sufficient.  You don't need to set it separately for 
> > x and y.
> It's not just about simplicity, but also about configurability. Let's
> say that a user would want
>     3×10<sup>6</sup>
> rather than
>     3x10<sup>6</sup>
> even if UTF-8 isn't recognized.

Huh?  How can you select a UTF-8 character if UTF-8 isn't recognized?

> > A related question:
> > 
> > At the moment the new code checks for TERM_IS_LATEX and if so
> > replaces the default format "%h" with "$%h$".   I.e. it uses the same
> > format but wraps it in $...$ so that LaTeX uses numerical mode.
> > Would it be a good idea to _always_ do this?   Or maybe always do
> > it if the format does not already contain $ signs?
> 
> What exactly do you mean with "always"? If I use "set title 'some
> text'" I don't want it to be enclosed in dollar signs for example.

Only for "set format"

> Which cases exactly fall under "alway wrap it in $...$"?
> 
> In my old scripts I was often using something like (please excuse me
> if I used the wrong format specifiers here):
>     set format y "\\m{%t}{%T}"
> where the master document defined
>     \def\m#1#2{$#1\cdot10^{#2}$}

That example is way over my head.
I don't recognize the syntax at all.

> I guess this would fail then?

Yes it would.  So maybe it it wasn't a good idea.
I can revert it to only wrap the default format, not user-defined formats.

	Ethan

Re: Feature request: configurable \times/\cdot and a bit about %h

[Christoph B. <us...@be...>]

Am 09.10.2013 19:36, schrieb Ethan A Merritt:
>
> At the moment the new code checks for TERM_IS_LATEX and if so
> replaces the default format "%h" with "$%h$".   I.e. it uses the same
> format but wraps it in $...$ so that LaTeX uses numerical mode.
> Would it be a good idea to _always_ do this?   Or maybe always do
> it if the format does not already contain $ signs?

You could wrap the format in $...$ only if it contains only formatting 
specifiers (%...), and these mustn't output any letter (the 'e' in the 
scientific notation should by typeset upright etc.).

This would also break, if one uses macros to format the labels.

Christoph

Re: Feature request: configurable \times/\cdot and a bit about %h

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

On Wed, Oct 9, 2013 at 7:36 PM, Ethan A Merritt wrote:
> On Wednesday, 09 October, 2013 15:26:29 Mojca Miklavec wrote:
>>
>> What about something more in the spirit of decimalsign?
>>     set decimalsign ','
>
> That doesn't really seem any easier than "set format".
> Either way you have to specify what you want if it's not already
> the default.
>
>> This would allow a much better flexibility, also because one wouldn't
>> need to change the format at all. With your suggestion one would need
>> to set both
>>     set format x "%H"
>>     set format y "%H"
>> and maybe at some other places displaying numerical values while
>> setting multiplication sign could be done once and for all.
>
> "set format '%H'" is sufficient.  You don't need to set it separately for  x and y.

It's not just about simplicity, but also about configurability. Let's
say that a user would want
    3×10<sup>6</sup>
rather than
    3x10<sup>6</sup>
even if UTF-8 isn't recognized.

If a particular user will want a dot (1.10^12) or a bit of extra space
around the multiplication sign or some other weird character, this
would be easy to do. And you would also pollute less letter space: %H
could be used later for a different meaning.

> A related question:
>
> At the moment the new code checks for TERM_IS_LATEX and if so
> replaces the default format "%h" with "$%h$".   I.e. it uses the same
> format but wraps it in $...$ so that LaTeX uses numerical mode.
> Would it be a good idea to _always_ do this?   Or maybe always do
> it if the format does not already contain $ signs?

What exactly do you mean with "always"? If I use "set title 'some
text'" I don't want it to be enclosed in dollar signs for example.
Which cases exactly fall under "alway wrap it in $...$"?

In my old scripts I was often using something like (please excuse me
if I used the wrong format specifiers here):
    set format y "\\m{%t}{%T}"

where the master document defined
    \def\m#1#2{$#1\cdot10^{#2}$}

I guess this would fail then?

The reason why I did this was because specifying
    set format y "$%t\\cdot10^{%T}$"
led to cca. 12 extra characters in calculation of the string length
and I ended up with way too much empty space. I believe this space
calculations is partially fixed now (even though still not perfect).

Mojca

Re: Feature request: configurable \times/\cdot and a bit about %h

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

On Wednesday, 09 October, 2013 15:26:29 Mojca Miklavec wrote:
> 
> What about something more in the spirit of decimalsign?
>     set decimalsign ','

That doesn't really seem any easier than "set format".
Either way you have to specify what you want if it's not already
the default.

> This would allow a much better flexibility, also because one wouldn't
> need to change the format at all. With your suggestion one would need
> to set both
>     set format x "%H"
>     set format y "%H"
> and maybe at some other places displaying numerical values while
> setting multiplication sign could be done once and for all.

"set format '%H'" is sufficient.  You don't need to set it separately for  x and y.  



A related question:

At the moment the new code checks for TERM_IS_LATEX and if so
replaces the default format "%h" with "$%h$".   I.e. it uses the same
format but wraps it in $...$ so that LaTeX uses numerical mode.
Would it be a good idea to _always_ do this?   Or maybe always do
it if the format does not already contain $ signs?

	Ethan

Re: Feature request: configurable \times/\cdot and a bit about %h

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

On Wed, Oct 9, 2013 at 12:41 AM, Ethan A Merritt wrote:
>
>> I always use \cdot instead of \times. Would it be possible to make
>> this configurable?
>
> Yes.
> On the non-LaTeX side  %h differs from %H by the choice of "x" versus ""*".
> It would make sense on the LaTeX side to interpret this as \times versus \cdot.
>
> Obviously only one of these can be the default.
> If you want something other than the default you have to use the
> "set format" command.

What about something more in the spirit of decimalsign?
    set decimalsign ','

So something like
    set multiplicationsign '*'
and the code in TERM_IS_LATEX checking for the value of that
character: if equal to '*', it would replace it with '\cdot', but in
principle users could use anything, from normal dots to '\bigtimes' or
anything else they please to use.

This would allow a much better flexibility, also because one wouldn't
need to change the format at all. With your suggestion one would need
to set both
    set format x "%H"
    set format y "%H"
and maybe at some other places displaying numerical values while
setting multiplication sign could be done once and for all.


>> This is the line in src/util.c that prints the character:
>>     strcpy(&tmp2[j], "\\times");
>>
>> The other "problem" I have if I would use this handy shortcut is that
>> it annoys me to have the y axis labelled "1", "1.5", "2", "2.5", ...
>> Thus I always use something like
>>     set format y "%.1f"
>
> That was one of two issues I had with the patch also.
> See discussion attached to the patch tracker.
>    https://sourceforge.net/p/gnuplot/patches/637/

Thank you. I believe that your comment:
    "I think the only way to get consistent formatting is to look at
all the tic values first and then pick some single format that can be
used for all of them."

expresses the same feelings that I have.

Yes, I hate if the axes are labelled "0.1000", "0.2000", "0.2999",
"0.4000" which might happen with "%f", but users should really have a
way of getting a consistent number of decimal digits. Even if some
people prefer "%g" (I often use %g only because I'm too lazy to
specify how many numbers I want exactly and this usually prints
something that makes more sense than %f), there should be a way to get
"0.00", "0.05", "0.10", "0.15", ... automatically. Yes, using "%.2f"
is a viable workaround, but one needs to hardcode the number of
desired decimal places. I would really love to see that number being
calculated automatically.

Btw: how does the current code deal with cases such as:
a) 0.001, 0.01, 0.1, 1, 10, 100, 1000, 10000
b) 100, 200, 300, ..., 900, 1000, 1100
When does the code decide to use exponential notation and when would
it print a normal "1000" rather than 1x10^3?

> IMHO "%.1f" isn't quite right either. I prefer
>   set format  "%.1tx10^{%T}"
>
> The other side of the argument, and the rationale for the patch
> as written, is Craig DeForest's observation that some people actually
> like the %g format.   That seems fair enough.   I just don't happen to
> be one of those people.

Me neither. And most other programs use a consistent number of decimal
places for axes labeling. The compromise is to allow both, but I don't
know how complex it would be to support that.

>> I would really love to have a setting to turn on the functionality
>> that would automatically calculate the number of needed decimal places
>> and keep it constant on the whole axis. And possibly a similar setting
>> that would also stick with 1.0\times10^{0} to keep the numbers nicely
>> right-aligned when requested.
>
> See discussion.  I'd like that also, but it would require choosing the
> format at the level of the entire axis range, not tic-by-tic.

True, it's needed for the entire range, not just by looking at a
single tick. I don't know enough about gnuplot internals to be able to
judge what changes exactly that would require.

Mojca

Re: Feature request: configurable \times/\cdot and a bit about %h

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

On Tuesday, 08 October, 2013 23:01:33 Mojca Miklavec wrote:
> Dear developers,
> 
> I have just noticed the nice enhancement in gnuplot, defaulting to a
> proper exponential form for numbers. However I have a tiny request.
> 
> I always use \cdot instead of \times. Would it be possible to make
> this configurable?

Yes.
On the non-LaTeX side  %h differs from %H by the choice of "x" versus ""*".
It would make sense on the LaTeX side to interpret this as \times versus \cdot.

Obviously only one of these can be the default.  
If you want something other than the default you have to use the
"set format" command.

> This is the line in src/util.c that prints the character:
>     strcpy(&tmp2[j], "\\times");
> 
> The other "problem" I have if I would use this handy shortcut is that
> it annoys me to have the y axis labelled "1", "1.5", "2", "2.5", ...
> Thus I always use something like
>     set format y "%.1f"

That was one of two issues I had with the patch also.
See discussion attached to the patch tracker.
   https://sourceforge.net/p/gnuplot/patches/637/

IMHO "%.1f" isn't quite right either. I prefer
  set format  "%.1tx10^{%T}"

The other side of the argument, and the rationale for the patch
as written, is Craig DeForest's observation that some people actually
like the %g format.   That seems fair enough.   I just don't happen to
be one of those people.  

So %h is a variant of %g with improved markup.
Arguably there is also room for a variant of %f with improved markup.

> I tried if I could use the same notation, "%.1h", but this only leads
> to the undesired removal of dollar signs around the numbers (without
> the desired effect), so I get:
>     2\times10^{43}
> Is this removal of dollar signs intended?

Yes.  The dollar signs are only added automatically in the case of using
the default format, so that the default state works for both LaTeX and 
non-LaTeX terminals.  If you are going to the trouble of specifying an
explicit "set format FOO" command then it's up to you to add whatever
additional markup is needed, including dollar signs.

> I would really love to have a setting to turn on the functionality
> that would automatically calculate the number of needed decimal places
> and keep it constant on the whole axis. And possibly a similar setting
> that would also stick with 1.0\times10^{0} to keep the numbers nicely
> right-aligned when requested.

See discussion.  I'd like that also, but it would require choosing the
format at the level of the entire axis range, not tic-by-tic.

 > But if %h is available it would be really nice if it would at least
> allow the explicit "%.<number>h".

That doesn't work for %h exactly because it doesn't work for %g.

	Ethan

Feature request: configurable \times/\cdot and a bit about %h

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

Dear developers,

I have just noticed the nice enhancement in gnuplot, defaulting to a
proper exponential form for numbers. However I have a tiny request.

I always use \cdot instead of \times. Would it be possible to make
this configurable?

This is the line in src/util.c that prints the character:
    strcpy(&tmp2[j], "\\times");

The other "problem" I have if I would use this handy shortcut is that
it annoys me to have the y axis labelled "1", "1.5", "2", "2.5", ...
Thus I always use something like
    set format y "%.1f"

I tried if I could use the same notation, "%.1h", but this only leads
to the undesired removal of dollar signs around the numbers (without
the desired effect), so I get:
    2\times10^{43}
Is this removal of dollar signs intended?

I would really love to have a setting to turn on the functionality
that would automatically calculate the number of needed decimal places
and keep it constant on the whole axis. And possibly a similar setting
that would also stick with 1.0\times10^{0} to keep the numbers nicely
right-aligned when requested.

But if %h is available it would be really nice if it would at least
allow the explicit "%.<number>h".

Thank you,
    Mojca

Re: Plan to release 4.6.4 next week

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

On 09/30/2013 10:13 PM, sfeam wrote:
> On Monday, 30 September 2013 09:43:46 PM Daniel J Sebald wrote:
>> Sounds good.  I'm just wondering what the status and availability of Qt
>> terminal is.  Is it now compiled and included in gnuplot by default if
>> the necessary Qt development tools are on the system?
>
> It is still a configuration option.
>
> Version 4.6    ./configure --enable-qt
> Version 4.7    ./configure --with-qt      or ./configure --with-qt=qt4
>
> The latter option is there because it will use qt5 if the libraries are present,
> but there is an annoying bug if you link against qt5 so there's an option
> to force qt4 instead.  I'm pretty sure the qt5 bug is something in a qt
> support library rather than in gnuplot code, so I'm hoping that it will be
> fixed in some incremental qt5 release.
>
>> Are most of the popular bundles building gnuplot with Qt terminal?
>
> I don't know.
> It's what I've been using by default for some while now myself.

Same here.  I still use X11 terminal and of course the variety of 
file-base terminals.  Qt does have some small strange effect with 
anti-aliasing on thin plot lines, but that's not gnuplot's fault.

How do others feel about making qt4 terminal compiled by default (if 
developer resources available) with an option for Qt5 --with-qt=qt5?  It 
seems to me that Qt4 is sort of the common version, at least as far as I 
know.

Dan


>
> 	Ethan
>
>>
>> Dan
>>
>>
>> On 09/29/2013 11:07 PM, sfeam wrote:
>>> Hi all,
>>>
>>> I plan to put a tarball for gnuplot-4.6.4 on SourceForge next weekend.
>>> Any last minute bug reports or other issues?
>>> Here's the NEWS section for changes since 4.6.3:
>>>
>>>
>>>    New features, changes and fixes since gnuplot version 4.6.3
>>> ===========================================================
>>>
>>> * NEW Ctrl-Break interrupts fitting run in wgnuplot
>>> * CHANGE treat empty fields in a csv file as "missing" rather than "bad"
>>> * CHANGE allow reference to more than one column header in 'using' or 'title'
>>> * CHANGE install-info is no longer a default "make install" target
>>> * FIX svg and canvas terminal mousing of inverted axis coordinates
>>> * FIX emf failed to initialize font correctly on some systems
>>> * FIX timedata columns can now be referred to via column(N) and column("HEAD")
>>> * FIX qt terminal toggling of enhanced text elements in plot with labels
>>> * FIX color/pattern generated for key entries of columnstacked histograms
>>> * FIX hitting ^C twice forces temination of wxt session hung by lost X-server
>>> * FIX win terminal failed to properly adjust plot border after window resize
>>> * FIX several conditions in which macros were not expanded during command input
>>> * FIX promote a string containing only digits to INTGR rather than CMPLX
>>> * FIX 'set grid front' caused failure to initialize location of axis zero point
>>> * FIX very poor precision in mouse coords reported by x11 in -persist mode
>>> * FIX parsing of $# (the number of arguments in a "call"). It's not a comment!
>>> * FIX memory leak of cropped images using pngcairo terminal
>>> * FIX "lc variable" now iterates over linetype colors (not styles) as documented
>>> * FIX rtics were sometimes drawn with length 0
>>>
>>> 		Ethan Merritt (gnuplot development team)
>>>
>>> ------------------------------------------------------------------------------
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>>> the latest Intel processors and coprocessors. See abstracts and register>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> gnuplot-beta mailing list
>>> gnu...@li...
>>> Membership management via: 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: Plan to release 4.6.4 next week

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

On Tue, 1 Oct 2013, Ethan A Merritt wrote:

> On Tuesday, 01 October, 2013 07:58:35 Allin Cottrell wrote:
>> On Sun, 29 Sep 2013, sfeam wrote:
>>
>>> I plan to put a tarball for gnuplot-4.6.4 on SourceForge next weekend.
>>> Any last minute bug reports or other issues?
>>> Here's the NEWS section for changes since 4.6.3 [...]
>>
>> Just wondering. I didn't see a mention of the changes in CVS that support
>> a 64-bit Windows build of gnuplot. Any chance of those changes making it
>> into 4.6.4?
>
> You are refering to these patches that were applied to 4.7?
>
> 2013-08-16  Allin Cottrell  <cot...@wf...>
>
>        * src/internal.c (GP_MATHERR): 1st part of win64 compatibility patch.
>        The matherr() mechanism is not used by win64. It's also not used by
>        current linux but it doesn't hurt to leave it in place for now.

[etc.]

Yes. If I can find the time I'll backport them but if not they can wait 
till the next iteration.

Allin Cottrell

Re: Plan to release 4.6.4 next week

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

On Tuesday, 01 October, 2013 12:43:30 Christoph Bersch wrote:
> Am 30.09.2013 06:07, schrieb sfeam:
> >
> > * FIX "lc variable" now iterates over linetype colors (not styles) as documented
> 
> Did you apply also the last patch of 
> http://sourceforge.net/p/gnuplot/bugs/1281/ ?

Oops. That one slipped through a crack.  Applied now.

	thanks,

		Ethan


> That fixes the variable linecolor of the points drawn with the label 
> plotting style.
> 
> Christoph
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Plan to release 4.6.4 next week

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

On Tuesday, 01 October, 2013 07:58:35 Allin Cottrell wrote:
> On Sun, 29 Sep 2013, sfeam wrote:
> 
> > I plan to put a tarball for gnuplot-4.6.4 on SourceForge next weekend.
> > Any last minute bug reports or other issues?
> > Here's the NEWS section for changes since 4.6.3 [...]
> 
> Just wondering. I didn't see a mention of the changes in CVS that support
> a 64-bit Windows build of gnuplot. Any chance of those changes making it 
> into 4.6.4?

You are refering to these patches that were applied to 4.7?

2013-08-16  Allin Cottrell  <cot...@wf...>

        * src/internal.c (GP_MATHERR): 1st part of win64 compatibility patch.
        The matherr() mechanism is not used by win64. It's also not used by
        current linux but it doesn't hurt to leave it in place for now.

        * src/win/wprinter.c src/win/winmain.c src/win/wtext.c src/win/wmenu.c
        src/win/wpause.c src/win/wgraph.c:
        2nd part of win64 compatability patch.  All changes are #ifdef _WIN64.

        src/win/wgnuplot.rc src/win/wgnuplot.exe.manifest64:
        The file win/wgnuplot.exe.manifest specifies the processorArchitecture
        as "X86". For an x86_64 build this must be changed to "amd64"
        (or wgnuplot.exe won't start). The manifest file is included by
        win/wgnuplot.rc. The modified wgnuplot.rc includes an alternative file
        wgnuplot.exe.manifest64 if the symbol _WIN64 is defined. This file
        simply substitutes "amd64" for "X86" in two places.

The first of those (to src/internal.c) applies without error to 4.6 also.
But the rest of it would need to be re-spun for 4.6

[51] patch -p0 --dry-run < ../../oldpatches/win64_part1.patch
checking file win/wprinter.c
Hunk #3 FAILED at 219.
Hunk #4 succeeded at 246 with fuzz 1.
Hunk #5 FAILED at 324.
2 out of 5 hunks FAILED
checking file win/winmain.c
Hunk #1 FAILED at 526.
1 out of 1 hunk FAILED
checking file win/wtext.c
Hunk #1 succeeded at 287 (offset 7 lines).
Hunk #2 succeeded at 1024 (offset 7 lines).
Hunk #3 succeeded at 1106 (offset 7 lines).
Hunk #4 succeeded at 1207 (offset 7 lines).
Hunk #5 succeeded at 1880 (offset 7 lines).
Hunk #6 succeeded at 2169 (offset 7 lines).
checking file win/wmenu.c
Hunk #1 succeeded at 827 (offset 3 lines).
Hunk #2 succeeded at 1052 (offset 4 lines).
checking file win/wpause.c
Hunk #2 succeeded at 255 with fuzz 2 (offset 6 lines).
Hunk #3 succeeded at 281 with fuzz 2 (offset 6 lines).
Hunk #4 FAILED at 308.
1 out of 4 hunks FAILED
checking file win/wgnuplot.rc
Hunk #1 succeeded at 3 with fuzz 2.
checking file win/wgraph.c
Hunk #1 succeeded at 433 (offset -2 lines).
Hunk #2 succeeded at 576 (offset -4 lines).
Hunk #3 succeeded at 2631 (offset -350 lines).
Hunk #4 succeeded at 2892 (offset -447 lines).
Hunk #5 succeeded at 2958 (offset -447 lines).
Hunk #6 succeeded at 3142 (offset -446 lines).
Hunk #7 succeeded at 3227 (offset -449 lines).
Hunk #8 succeeded at 3745 (offset -460 lines).
checking file win/wgnuplot.exe.manifest64

If you send me a patch set backported to apply against 4.6 I'd
be happy to apply it.  But please test it first, as I'm not set up
to build under windows here.

	Ethan


> 
> Allin Cottrell
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Plan to release 4.6.4 next week

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

On Sun, 29 Sep 2013, sfeam wrote:

> I plan to put a tarball for gnuplot-4.6.4 on SourceForge next weekend.
> Any last minute bug reports or other issues?
> Here's the NEWS section for changes since 4.6.3 [...]

Just wondering. I didn't see a mention of the changes in CVS that support
a 64-bit Windows build of gnuplot. Any chance of those changes making it 
into 4.6.4?

Allin Cottrell

Re: Plan to release 4.6.4 next week

[Christoph B. <us...@be...>]

Am 30.09.2013 06:07, schrieb sfeam:
>
> * FIX "lc variable" now iterates over linetype colors (not styles) as documented

Did you apply also the last patch of 
http://sourceforge.net/p/gnuplot/bugs/1281/ ?
That fixes the variable linecolor of the points drawn with the label 
plotting style.

Christoph

Re: Plan to release 4.6.4 next week

[sfeam <sf...@us...>]

On Monday, 30 September 2013 09:43:46 PM Daniel J Sebald wrote:
> Sounds good.  I'm just wondering what the status and availability of Qt 
> terminal is.  Is it now compiled and included in gnuplot by default if 
> the necessary Qt development tools are on the system?  

It is still a configuration option.

Version 4.6    ./configure --enable-qt
Version 4.7    ./configure --with-qt      or ./configure --with-qt=qt4

The latter option is there because it will use qt5 if the libraries are present,
but there is an annoying bug if you link against qt5 so there's an option
to force qt4 instead.  I'm pretty sure the qt5 bug is something in a qt
support library rather than in gnuplot code, so I'm hoping that it will be
fixed in some incremental qt5 release.

> Are most of the popular bundles building gnuplot with Qt terminal?

I don't know.
It's what I've been using by default for some while now myself.

	Ethan

> 
> Dan
> 
> 
> On 09/29/2013 11:07 PM, sfeam wrote:
> > Hi all,
> >
> > I plan to put a tarball for gnuplot-4.6.4 on SourceForge next weekend.
> > Any last minute bug reports or other issues?
> > Here's the NEWS section for changes since 4.6.3:
> >
> >
> >   New features, changes and fixes since gnuplot version 4.6.3
> > ===========================================================
> >
> > * NEW Ctrl-Break interrupts fitting run in wgnuplot
> > * CHANGE treat empty fields in a csv file as "missing" rather than "bad"
> > * CHANGE allow reference to more than one column header in 'using' or 'title'
> > * CHANGE install-info is no longer a default "make install" target
> > * FIX svg and canvas terminal mousing of inverted axis coordinates
> > * FIX emf failed to initialize font correctly on some systems
> > * FIX timedata columns can now be referred to via column(N) and column("HEAD")
> > * FIX qt terminal toggling of enhanced text elements in plot with labels
> > * FIX color/pattern generated for key entries of columnstacked histograms
> > * FIX hitting ^C twice forces temination of wxt session hung by lost X-server
> > * FIX win terminal failed to properly adjust plot border after window resize
> > * FIX several conditions in which macros were not expanded during command input
> > * FIX promote a string containing only digits to INTGR rather than CMPLX
> > * FIX 'set grid front' caused failure to initialize location of axis zero point
> > * FIX very poor precision in mouse coords reported by x11 in -persist mode
> > * FIX parsing of $# (the number of arguments in a "call"). It's not a comment!
> > * FIX memory leak of cropped images using pngcairo terminal
> > * FIX "lc variable" now iterates over linetype colors (not styles) as documented
> > * FIX rtics were sometimes drawn with length 0
> >
> > 		Ethan Merritt (gnuplot development team)
> >
> > ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> > the latest Intel processors and coprocessors. See abstracts and register>
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >
> 
> 

Re: Plan to release 4.6.4 next week

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

Sounds good.  I'm just wondering what the status and availability of Qt 
terminal is.  Is it now compiled and included in gnuplot by default if 
the necessary Qt development tools are on the system?  Are most of the 
popular bundles building gnuplot with Qt terminal?

Dan


On 09/29/2013 11:07 PM, sfeam wrote:
> Hi all,
>
> I plan to put a tarball for gnuplot-4.6.4 on SourceForge next weekend.
> Any last minute bug reports or other issues?
> Here's the NEWS section for changes since 4.6.3:
>
>
>   New features, changes and fixes since gnuplot version 4.6.3
> ===========================================================
>
> * NEW Ctrl-Break interrupts fitting run in wgnuplot
> * CHANGE treat empty fields in a csv file as "missing" rather than "bad"
> * CHANGE allow reference to more than one column header in 'using' or 'title'
> * CHANGE install-info is no longer a default "make install" target
> * FIX svg and canvas terminal mousing of inverted axis coordinates
> * FIX emf failed to initialize font correctly on some systems
> * FIX timedata columns can now be referred to via column(N) and column("HEAD")
> * FIX qt terminal toggling of enhanced text elements in plot with labels
> * FIX color/pattern generated for key entries of columnstacked histograms
> * FIX hitting ^C twice forces temination of wxt session hung by lost X-server
> * FIX win terminal failed to properly adjust plot border after window resize
> * FIX several conditions in which macros were not expanded during command input
> * FIX promote a string containing only digits to INTGR rather than CMPLX
> * FIX 'set grid front' caused failure to initialize location of axis zero point
> * FIX very poor precision in mouse coords reported by x11 in -persist mode
> * FIX parsing of $# (the number of arguments in a "call"). It's not a comment!
> * FIX memory leak of cropped images using pngcairo terminal
> * FIX "lc variable" now iterates over linetype colors (not styles) as documented
> * FIX rtics were sometimes drawn with length 0
>
> 		Ethan Merritt (gnuplot development team)
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register>
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 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