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

Re: More efficient "dbl_raise"

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

On Sunday 08 April 2007 01:52, Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> 
> > gnuplot> print 
> > 10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0 
> > - 1e25
> > -2147483648.0
> 
> And this seems to be accurate:
> 
> gnuplot> print 
> 1e25/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10 
> - 1.0
> 0.0
> 
> Ummmm, so why is the division accurate while the multiplication above appears 
> not to be?  

That is exactly what you should expect.  Sequential division reduces the inaccuracy
of the original number by a factor of 10 at each step.  Simple subtraction exposes
the size of the original discrepancy.

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

Note also that if you care about this level of precision then you also must
pay attention to the IEEE rounding mode.

> Is there something going on with the translation from exponential  
> notation and the machine IEEE float representation somewhere around 10^25?

Yes. That's where you hit the limit of the IEEE representation.
To do better than that you'd have to switch to some other floating point
representation.

There are infinite-precision math libraries available, but gnuplot isn't
using one.

-- 
Ethan A Merritt

replot for plots with "-" inline data

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

I went through the octave-help archive and a message (see its copy at the 
bottom) says that mousing (zooming, and also hotkeys) does no longer work 
with octave 2.9.10. I had a look what this octave version is doing by:

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

and there appears:

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

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

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

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


Does somebody know how to implement it? (Me not.)

---
PM



On Thu, 15 Mar 2007, Petr Mikulik wrote:

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

===

According to:
http://www.cae.wisc.edu/pipermail/help-octave/2007-April/003542.html

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

Re: More efficient "dbl_raise"

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

Daniel J Sebald wrote:

> gnuplot> print 
> 10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0 
> - 1e25
> -2147483648.0
> 
> Very strange.  Not concrete proof, but my conjecture about not knowing which is 
> more accurate, outright multiplying via dbl_raise() vs. pow(), does seem a 
> pertinent question.

And this seems to be accurate:

gnuplot> print 
1e25/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10/10 
- 1.0
0.0

Ummmm, so why is the division accurate while the multiplication above appears 
not to be?  Is there something going on with the translation from exponential 
notation and the machine IEEE float representation somewhere around 10^25?

Dan

Re: More efficient "dbl_raise"

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

Ethan A Merritt wrote:
> On Saturday 07 April 2007 21:28, you wrote:
> 
>>Ethan A Merritt wrote:
>>
>>>On Saturday 07 April 2007 15:58, Daniel J Sebald wrote:
>>>
>>>
>>>>Move the patch into CVS or dump it?  (Discussing things and not resolving them,
>>>>even for as trivial a patch as this, isn't productive.)
>>>
>>>
>>>Was there a real problem that this was supposed to solve?
>>>If not, drop it.
>>
>>Recap:  The patch mimics dbl_raise() behavior, but uses an existing library 
>>function pow() that is probably more efficient
> 
> 
> I was not paying close attention, but didn't HBB show that your
> proposed "more efficient" alternative function could be off by
> 15 orders of magnitude  in the worst case?

Well, I'm not sure.  This might be an apples and oranges kind of thing.  Here is 
the script HBB suggested:

     powdiff(base,power) = (base**power / exp(power*log(base))) - 1.0
     set samples 301 ; plot [0:60] powdiff(10,x)

Note that this sampling contains both "integers" and "floats".  What we are 
ultimately interested in our use of pow(,) or dbl_raise() is raising an integer 
value (speaking math-wise, not computer-wise) to an integer power (again, 
math-wise), but that is getting off course.  Let's pause to look at the behavior 
of gnuplot on some simple examples, say 10^10:

gnuplot> print 10**10
1410065408
gnuplot> print 10**10.0
10000000000.0
gnuplot> print 10.0**10
10000000000.0
gnuplot> print exp(10*log(10))
10000000000.0

pow(base,power) = base**power

gnuplot> print pow(10,10)
1410065408
gnuplot> print pow(10,10.0)
10000000000.0

OK, so we see that gnuplot treats integers (computer-wise) with integer math 
which is much more limiting in size compared to floating point math.

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

#include <math.h>
   double floor( double arg );

The documentation of these C functions might say "largest integer not greater 
than arg", but that means the math vernacular, not computer vernacular.  That is 
why I say apples and oranges.

Given gnuplot's behavior, can we come up with a comparison at the command line 
the reflects the behavior of C routines?  I've followed the parsing to 
internal.c and see that ** operator does in fact use the C library pow(,) 
function.  So we've got that.  The expression exp(power*log(base)) loses 
accuracy, but that isn't really related to the use of pow() I've applied in the 
range application.  So let's not look at that any further.

Try this:

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

You may see something different than what I'm seeing, but what I see is that 
near x=25 there appears to be some discrepancy.  So let's pick a few points there:

gnuplot> print 10.0**23 - powint(10.0,23)
0.0
gnuplot> print 10.0**24 - powint(10.0,24)
0.0
gnuplot> print 10.0**25 - powint(10.0,25)
2147483648.0
gnuplot> print 10.0**26 - powint(10.0,26)
17179869184.0
gnuplot> print 10.0**27 - powint(10.0,27)
137438953472.0
gnuplot> print 10.0**28 - powint(10.0,28)
0.0
gnuplot> print 10.0**29 - powint(10.0,29)
0.0

So, something does become flaky here.  Let's see if we can figure out where 
exactly the discrepancy is:

gnuplot> print 10.0**23 - 1e23
0.0
gnuplot> print 10.0**24 - 1e24
0.0
gnuplot> print 10.0**25 - 1e25
0.0
gnuplot> print 10.0**26 - 1e26
0.0
gnuplot> print 10.0**27 - 1e27
0.0
gnuplot> print 10.0**28 - 1e28
0.0
gnuplot> print powint(10.0,23.0) - 1e23
0.0
gnuplot> print powint(10.0,24.0) - 1e24
0.0
gnuplot> print powint(10.0,25.0) - 1e25
-2147483648.0
gnuplot> print powint(10.0,26.0) - 1e26
-17179869184.0
gnuplot> print powint(10.0,27.0) - 1e27
-137438953472.0
gnuplot> print powint(10.0,28.0) - 1e28
0.0
gnuplot>

Now that' odd.  It would seem that the power function is correct and multiplying 
isn't.  Let's go one step further to confirm this:

gnuplot> print 
10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0
1e+25
gnuplot> print 
10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0*10.0 
- 1e25
-2147483648.0

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

I was long winded, Ethan, but the answer to your question is "I don't think so."

Dan

Re: More efficient "dbl_raise"

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

Ethan A Merritt wrote:
> On Saturday 07 April 2007 15:58, Daniel J Sebald wrote:
> 
>>Move the patch into CVS or dump it?  (Discussing things and not resolving them,
>>even for as trivial a patch as this, isn't productive.)
> 
> 
> Was there a real problem that this was supposed to solve?
> If not, drop it.

Recap:  The patch mimics dbl_raise() behavior, but uses an existing library 
function pow() that is probably more efficient than a multiplicative loop and 
handles the NaN value for which gnuplot appears to hang for five minutes.  E.g., 
slightly cleaner code and handles NaN.  Feel free to close the patch, but at the 
same time please remove

/* FIXME HBB 20000426: is this really useful? */

which only invites people to investigate suggesting there is a problem.

Dan

Re: More efficient "dbl_raise"

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

On Saturday 07 April 2007 15:58, Daniel J Sebald wrote:
> Move the patch into CVS or dump it?  (Discussing things and not resolving=
 them,
> even for as trivial a patch as this, isn't productive.)

Was there a real problem that this was supposed to solve?
If not, drop it.

	Ethan


>=20
> Dan
>=20
>=20
> Daniel J Sebald wrote:
> > Hans-Bernhard Br=F6ker wrote:
> >=20
> >>Daniel J Sebald wrote:
> >>
> >>
> >>>Hans-Bernhard Br=F6ker wrote:
> >>>
> >>>
> >>>>Daniel J Sebald wrote:
> >>
> >>
> >>>>>In some way it also removes the question that Hans raised in the=20
> >>>>>code.  I'm sure you can't recall that far back, Hans, but a question=
=20
> >>>>>I have is just exactly was this approach supposed to achieve? =20
> >>
> >>
> >>>>Basically, it's that pow() isn't required to treat integer exponents=
=20
> >>>>specially, so it can easily destroy more precision than dbl_raise()=20
> >>>>in its existing form does.
> >>
> >>
> >>>Right.  But the premise, I guess, is that for the application in=20
> >>>question we're interested in raising an integer to an integer power,=20
> >>>which results in an integer. =20
> >>
> >>
> >>No. We're interested in raising a double to an integer power, which=20
> >>results in a double.  For simple cases, the input and output doubles=20
> >>will have integer values, but they're not integers by design.
> >=20
> >=20
> > This equation
> >=20
> >      double power =3D dbl_raise(10.0, floor(log10(arg)));
> >=20
> > from a purely mathematical standpoint, is raising an integer, 10, to an=
 integer,=20
> > floor(), power.  Generally, that's a rational number.  Now, looking mor=
e closely=20
> > at dbl_raise(x,y), we have
> >=20
> >      int i =3D abs(y);
> >=20
> > An integer raised to a positive integer power is an integer.  (I forgot=
 to=20
> > clarify it is a positive integer power last time, maybe that's where th=
e=20
> > confusion is.)
> >=20
> > We are free to round the value and remove any finite math effects.
> >=20
> >=20
> >  >  If we
> >  > only had to worry about cases where the power is small enough for the
> >  > result to be integer, a table of all 10 powers-of-ten from 10^0 to 1=
0^9
> >  > would suffice.  But that's not the case.
> > [snip]
> >  > As good as it can be.  It's still likely to be better than that of t=
he
> >  > typical naive implementation of pow(x,y):
> >=20
> > If the ultimate result can't be represented with a binary float, that's=
 a=20
> > different matter.  But I'm saying that isn't unique to pow() because ne=
ither can
> >=20
> > 10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10=
*10
> >=20
> > be contained in binary float.  It reaches a point along the way in the=
=20
> > multiplication loop that the ability to represent the large integer is =
gone and=20
> > each multiplication results in poorer and poorer resolution relative to=
 the=20
> > increasing product.  Who knows?  Perhaps the pow() function has better =
numerical=20
> > behavior and ends up being more accurate in some circumstances.
> >=20
> >=20
> >=20
> >>For the fun of it, be sure to make some plots of this function:
> >>
> >>    powdiff(base,power) =3D (base**power / exp(power*log(base))) - 1.0
> >>
> >>E.g.
> >>
> >>    set samples 301 ; plot [0:60] powdiff(10,x)
> >>
> >>to see just how badly wrong this can go.
> >>
> >>
> >>>floor(log10(arg))
> >=20
> >=20
> > Interesting plot, and that is the issue at hand.
> >=20
> >=20
> >=20
> >>>We aren't guaranteed that will come out to be exactly the exponent=20
> >>>desired. =20
> >>
> >>
> >>No, we're not.  Which is why this result is used only as a guide, not a=
s=20
> >>the single piece of information, by quantize_tics.  There's a reason=20
> >>that there are cases of that switch outside the expected range of [2:20=
].
> >>
> >>
> >>>Maybe the best we could hope for is some kind of internal consistency=
=20
> >>>between log10() and pow(), by which I mean it would be nice that if
> >>>
> >>>  E =3D floor(log10(arg))
> >>>
> >>>then
> >>>
> >>>  pow(10,E) <=3D arg < pow(10,E+1)
> >>>
> >>>is always true. =20
> >>
> >>
> >>No, the best we can do is avoid having to rely on such assumptions.  Th=
e=20
> >> code in quantize_tics() does that.
> >=20
> >=20
> > You're looking at this in one level broader scope than I am.  I'm just =
focused=20
> > on getting xnorm to be accurate given whatever the value of arg is, i.e=
=2E, the=20
> > correct value of the exponent E rather than possibly being off by one..=
=2E which=20
> > is a little subjective in itself meaning that E being one less than the=
=20
> > mathematically correct value won't result in overly bad number of tics =
anyway.
> >=20
> > Dan
> >=20
> > -----------------------------------------------------------------------=
=2D-
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share=
 your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=
=3DDEVDEV
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >=20
>=20
>=20

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

Re: More efficient "dbl_raise"

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

Move the patch into CVS or dump it?  (Discussing things and not resolving them,
even for as trivial a patch as this, isn't productive.)

Dan


Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:
> 
>>Daniel J Sebald wrote:
>>
>>
>>>Hans-Bernhard Bröker wrote:
>>>
>>>
>>>>Daniel J Sebald wrote:
>>
>>
>>>>>In some way it also removes the question that Hans raised in the 
>>>>>code.  I'm sure you can't recall that far back, Hans, but a question 
>>>>>I have is just exactly was this approach supposed to achieve?  
>>
>>
>>>>Basically, it's that pow() isn't required to treat integer exponents 
>>>>specially, so it can easily destroy more precision than dbl_raise() 
>>>>in its existing form does.
>>
>>
>>>Right.  But the premise, I guess, is that for the application in 
>>>question we're interested in raising an integer to an integer power, 
>>>which results in an integer.  
>>
>>
>>No. We're interested in raising a double to an integer power, which 
>>results in a double.  For simple cases, the input and output doubles 
>>will have integer values, but they're not integers by design.
> 
> 
> This equation
> 
>      double power = dbl_raise(10.0, floor(log10(arg)));
> 
> from a purely mathematical standpoint, is raising an integer, 10, to an integer, 
> floor(), power.  Generally, that's a rational number.  Now, looking more closely 
> at dbl_raise(x,y), we have
> 
>      int i = abs(y);
> 
> An integer raised to a positive integer power is an integer.  (I forgot to 
> clarify it is a positive integer power last time, maybe that's where the 
> confusion is.)
> 
> We are free to round the value and remove any finite math effects.
> 
> 
>  >  If we
>  > only had to worry about cases where the power is small enough for the
>  > result to be integer, a table of all 10 powers-of-ten from 10^0 to 10^9
>  > would suffice.  But that's not the case.
> [snip]
>  > As good as it can be.  It's still likely to be better than that of the
>  > typical naive implementation of pow(x,y):
> 
> If the ultimate result can't be represented with a binary float, that's a 
> different matter.  But I'm saying that isn't unique to pow() because neither can
> 
> 10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10
> 
> be contained in binary float.  It reaches a point along the way in the 
> multiplication loop that the ability to represent the large integer is gone and 
> each multiplication results in poorer and poorer resolution relative to the 
> increasing product.  Who knows?  Perhaps the pow() function has better numerical 
> behavior and ends up being more accurate in some circumstances.
> 
> 
> 
>>For the fun of it, be sure to make some plots of this function:
>>
>>    powdiff(base,power) = (base**power / exp(power*log(base))) - 1.0
>>
>>E.g.
>>
>>    set samples 301 ; plot [0:60] powdiff(10,x)
>>
>>to see just how badly wrong this can go.
>>
>>
>>>floor(log10(arg))
> 
> 
> Interesting plot, and that is the issue at hand.
> 
> 
> 
>>>We aren't guaranteed that will come out to be exactly the exponent 
>>>desired.  
>>
>>
>>No, we're not.  Which is why this result is used only as a guide, not as 
>>the single piece of information, by quantize_tics.  There's a reason 
>>that there are cases of that switch outside the expected range of [2:20].
>>
>>
>>>Maybe the best we could hope for is some kind of internal consistency 
>>>between log10() and pow(), by which I mean it would be nice that if
>>>
>>>  E = floor(log10(arg))
>>>
>>>then
>>>
>>>  pow(10,E) <= arg < pow(10,E+1)
>>>
>>>is always true.  
>>
>>
>>No, the best we can do is avoid having to rely on such assumptions.  The 
>> code in quantize_tics() does that.
> 
> 
> You're looking at this in one level broader scope than I am.  I'm just focused 
> on getting xnorm to be accurate given whatever the value of arg is, i.e., the 
> correct value of the exponent E rather than possibly being off by one... which 
> is a little subjective in itself meaning that E being one less than the 
> mathematically correct value won't result in overly bad number of tics anyway.
> 
> Dan
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Proposed restructuring of gnuplot's LC_NUMERIC locale code

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

Bug #1692541  points out an error in the current locale processing.

The current logic is the following:

  - "set decimal locale" causes gnuplot to reset it's numerical
    formatting according to the value of LC_NUMERIC in the current
    environment.  The LC_NUMERIC settings include the decimal point
    character, the thousands separator character, and the grouping
    of digits in long number strings. This affects all libc
    formatting functions, in particular printf() and sprintf().

  - These settings remain in effect until explicitly cancelled,
    e.g. by "unset decimal" or "set decimal locale 'C'".  All
    string output that uses the C library routines therefore
    uses the new decimal point, thousands separator, etc.

  - However, the program itself temporarily resets the locale to "C"
    in various  save_<foo>()  show_<foo>()  and other routines that
    result in executable commands.  

  - Unfortunately the locale setting also affects terminal driver
    output as well as the core routines.  This was unintended.

It's probably my fault, but before I mess things up any further I
thought I would open the issue for discussion.  There are two obvious
approaches to fixing this.

(1) Temporarily revert to locale "C" inside the affected terminal
    drivers, just as we are currently doing in the core routines.

(2) Invert the logic everywhere:  Leave the locale as "C" by default
    and temporarily switch to the requested environment locale when
    writing axis labels, tick labels, user labels, titles, and
    probably some other things I am not thinking of. 

Approach (1) has the advantage of leaving the core code unchanged.
However it is unpleasant to think of potentially setting/resetting
the locale for every point or line segment plotted.  I don't like
this option.

Approach (2) is more obviously correct, but involves changing the
core routines.

As a point of reference, here are the affected terminals:

>>> grep -c '%\.[0-9]f' *.trm | grep -v :0
ai.trm:15
aquaterm.trm:1
cairo.trm:2
corel.trm:14
fig.trm:2
hpgl.trm:27
latex.trm:12
metapost.trm:22
mif.trm:6
next.trm:7
openstep.trm:7
pdf.trm:2
post.trm:16
pslatex.trm:5
pstricks.trm:7
svg.trm:19
tgif.trm:125
x11.trm:1

And here are the core routines whose current logic
would need to be inverted:
>> grep -c LC_NUM *.c | grep -v :0
command.c:8
gplt_x11.c:1
mouse.c:6
save.c:1
scanner.c:3
set.c:2
show.c:6
unset.c:1

I don't have a list yet of the core routines that would need
new code to set/reset the locale during operation.
Perhaps the list contains only write_multiline() and gprintf()?

-- 
Ethan A Merritt

Re: 99 bottles of beer

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

> I couldn't resist.  Here is a working version that correctly starts
> at 99 and counts down to "No bottles of beer".

Looks like a cold candidate for "useful scripts" on gnuplot's web page.

---
PM

Re: More efficient "dbl_raise"

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

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
>> Hans-Bernhard Bröker wrote:
>>
>>> Daniel J Sebald wrote:
> 
> 
>>>> In some way it also removes the question that Hans raised in the 
>>>> code.  I'm sure you can't recall that far back, Hans, but a question 
>>>> I have is just exactly was this approach supposed to achieve?  
> 
> 
>>> Basically, it's that pow() isn't required to treat integer exponents 
>>> specially, so it can easily destroy more precision than dbl_raise() 
>>> in its existing form does.
> 
> 
>> Right.  But the premise, I guess, is that for the application in 
>> question we're interested in raising an integer to an integer power, 
>> which results in an integer.  
> 
> 
> No. We're interested in raising a double to an integer power, which 
> results in a double.  For simple cases, the input and output doubles 
> will have integer values, but they're not integers by design.

This equation

     double power = dbl_raise(10.0, floor(log10(arg)));

from a purely mathematical standpoint, is raising an integer, 10, to an integer, 
floor(), power.  Generally, that's a rational number.  Now, looking more closely 
at dbl_raise(x,y), we have

     int i = abs(y);

An integer raised to a positive integer power is an integer.  (I forgot to 
clarify it is a positive integer power last time, maybe that's where the 
confusion is.)

We are free to round the value and remove any finite math effects.


 >  If we
 > only had to worry about cases where the power is small enough for the
 > result to be integer, a table of all 10 powers-of-ten from 10^0 to 10^9
 > would suffice.  But that's not the case.
[snip]
 > As good as it can be.  It's still likely to be better than that of the
 > typical naive implementation of pow(x,y):

If the ultimate result can't be represented with a binary float, that's a 
different matter.  But I'm saying that isn't unique to pow() because neither can

10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10*10

be contained in binary float.  It reaches a point along the way in the 
multiplication loop that the ability to represent the large integer is gone and 
each multiplication results in poorer and poorer resolution relative to the 
increasing product.  Who knows?  Perhaps the pow() function has better numerical 
behavior and ends up being more accurate in some circumstances.


> For the fun of it, be sure to make some plots of this function:
> 
>     powdiff(base,power) = (base**power / exp(power*log(base))) - 1.0
> 
> E.g.
> 
>     set samples 301 ; plot [0:60] powdiff(10,x)
> 
> to see just how badly wrong this can go.
> 
>> floor(log10(arg))

Interesting plot, and that is the issue at hand.


>>
>> We aren't guaranteed that will come out to be exactly the exponent 
>> desired.  
> 
> 
> No, we're not.  Which is why this result is used only as a guide, not as 
> the single piece of information, by quantize_tics.  There's a reason 
> that there are cases of that switch outside the expected range of [2:20].
> 
>> Maybe the best we could hope for is some kind of internal consistency 
>> between log10() and pow(), by which I mean it would be nice that if
>>
>>   E = floor(log10(arg))
>>
>> then
>>
>>   pow(10,E) <= arg < pow(10,E+1)
>>
>> is always true.  
> 
> 
> No, the best we can do is avoid having to rely on such assumptions.  The 
>  code in quantize_tics() does that.

You're looking at this in one level broader scope than I am.  I'm just focused 
on getting xnorm to be accurate given whatever the value of arg is, i.e., the 
correct value of the exponent E rather than possibly being off by one... which 
is a little subjective in itself meaning that E being one less than the 
mathematically correct value won't result in overly bad number of tics anyway.

Dan

Re: More efficient "dbl_raise"

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

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:
>> Daniel J Sebald wrote:

>>> In some way it also removes the question that Hans raised in the 
>>> code.  I'm sure you can't recall that far back, Hans, but a question 
>>> I have is just exactly was this approach supposed to achieve?  

>> Basically, it's that pow() isn't required to treat integer exponents 
>> specially, so it can easily destroy more precision than dbl_raise() in 
>> its existing form does.

> Right.  But the premise, I guess, is that for the application in 
> question we're interested in raising an integer to an integer power, 
> which results in an integer.  

No. We're interested in raising a double to an integer power, which 
results in a double.  For simple cases, the input and output doubles 
will have integer values, but they're not integers by design.  If we 
only had to worry about cases where the power is small enough for the 
result to be integer, a table of all 10 powers-of-ten from 10^0 to 10^9 
would suffice.  But that's not the case.

> Your statement may be true for relatively small numbers.  To confirm 
> that for larger numbers, one would have to look at the pow() code.  I 
> mean, the way gnuplot is programmed, what if someone enters numbers on 
> the order of 1e30? What's the precision of 10*10*...*10*10 as a floating 
> point number?  

As good as it can be.  It's still likely to be better than that of the 
typical naive implementation of pow(x,y):

	exp(y*log(x))

For the fun of it, be sure to make some plots of this function:

	powdiff(base,power) = (base**power / exp(power*log(base))) - 1.0

E.g.

	set samples 301 ; plot [0:60] powdiff(10,x)

to see just how badly wrong this can go.

> floor(log10(arg))
> 
> We aren't guaranteed that will come out to be exactly the exponent 
> desired.  

No, we're not.  Which is why this result is used only as a guide, not as 
the single piece of information, by quantize_tics.  There's a reason 
that there are cases of that switch outside the expected range of [2:20].

> Maybe the best we could hope for is some kind of internal consistency 
> between log10() and pow(), by which I mean it would be nice that if
> 
>   E = floor(log10(arg))
> 
> then
> 
>   pow(10,E) <= arg < pow(10,E+1)
> 
> is always true.  

No, the best we can do is avoid having to rely on such assumptions.  The 
  code in quantize_tics() does that.

Re: ***[Possible UCE]*** Re: More efficient "dbl_raise"

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

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
> 
>>The issue in dbl_raise is a multiplying loop for raising a value to an integer 
>>power.  I'm guessing the library function pow() does such a thing more 
>>efficiently in addition to handling the pathological NaN.  
> 
> 
> Maybe so, but at the same time, there's a solid probability that it is 
> just too inaccurate to work.
> 
> Tics generation is extremely sensitive to rounding error, mainly in 
> extreme cases: very large or small arguments, arguments already slightly 
> distrubed by earlier rounding errors.
> 
> A while ago we had a long-standing bug where tic generation was broken 
> just by turning on -O2 in GCC, but only on some platforms.  Suffice it 
> to say that this is a kind of problem I'd rather not have to face again.
> 
> 
>>In some way it also removes the question that Hans raised in the code.  I'm sure 
>>you can't recall that far back, Hans, but a question I have is just exactly was 
>>this approach supposed to achieve?  
> 
> 
> Basically, it's that pow() isn't required to treat integer exponents 
> specially, so it can easily destroy more precision than dbl_raise() in 
> its existing form does.

Right.  But the premise, I guess, is that for the application in question we're 
interested in raising an integer to an integer power, which results in an 
integer.  So, we are free to round the pow() result to an integer and can feel 
fairly certain the result is the same as dbl_raise().

Your statement may be true for relatively small numbers.  To confirm that for 
larger numbers, one would have to look at the pow() code.  I mean, the way 
gnuplot is programmed, what if someone enters numbers on the order of 1e30? 
What's the precision of 10*10*...*10*10 as a floating point number?  It's beyond 
the largest value the mantissa can hold so we know some precision is likely lost 
since the underlying math is binary floating point.

Also, there may even be something about the existing code that is questionable, 
but probably the log10() function behaves nicely in this regard.  This bit:

floor(log10(arg))

We aren't guaranteed that will come out to be exactly the exponent desired.  Say 
the argument is 1e15 for which we'd expect the resulting value to be 15.  But, 
if by chance because of the way the particular log10() function is implemented 
in a library, it comes out to 14.9999992, the floor() would produce the 
incorrect result.  We can't round in this case.

This kind of precision issue probably works best if the number system is binary 
float.  Then we could use frexp() and ldexp() and get the exponent directly and 
do highly accurates tests and checks.  But I don't see any creative way of 
changing the problem into that realm.

Maybe the best we could hope for is some kind of internal consistency between 
log10() and pow(), by which I mean it would be nice that if

   E = floor(log10(arg))

then

   pow(10,E) <= arg < pow(10,E+1)

is always true.  For what it is worth, this extra test:

exponent = floor(log10(arg));
if (pow(10,exponent+1) <= arg)
     exponent++;

does nothing to change the PostScript results.

Dan

Re: 99 bottles of beer

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

On Saturday 31 March 2007 08:09, Ethan A Merritt wrote:
> On Saturday 31 March 2007 01:58, Bastian M=C3=A4rkisch wrote:
> > I just noticed that gnuplot does not have it's own version of the
> > famous 99 bottles of beer song (http://99-bottles-of-beer.net/).

> Surely gnuplot should produce plotted output!
> Here's my go at it.  It doesn't quite work for the last 2 conditions,
> but maybe it will inspire you to new heights.

I couldn't resist.  Here is a working version that correctly starts
at 99 and counts down to "No bottles of beer".

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

Re: 99 bottles of beer

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

On Saturday 31 March 2007 01:58, Bastian M=C3=A4rkisch wrote:
> I just noticed that gnuplot does not have it's own version of the
> famous 99 bottles of beer song (http://99-bottles-of-beer.net/).

A shocking oversight. Why has no one reported this bug before?
=20
> Here I present my version for discussion before I submit it.

gnuplot> load '99bottles.gp'
         "99bottles.gp", line 8: undefined variable: bottles

=46ix:
# Create and initialize the bottles counter
=2Dif (!defined(bottles)) bottles =3D max + 1
+if (!exists("bottles")) bottles =3D max + 1

> On the site it is stated that "Your example should demonstrate the
> main advantages and features of the language". I would appreciate
> suggestions to improve the script with respect to this.

Surely gnuplot should produce plotted output!
Here's my go at it.  It doesn't quite work for the last 2 conditions,
but maybe it will inspire you to new heights.


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

Re: More efficient "dbl_raise"

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

Daniel J Sebald wrote:

> The issue in dbl_raise is a multiplying loop for raising a value to an integer 
> power.  I'm guessing the library function pow() does such a thing more 
> efficiently in addition to handling the pathological NaN.  

Maybe so, but at the same time, there's a solid probability that it is 
just too inaccurate to work.

Tics generation is extremely sensitive to rounding error, mainly in 
extreme cases: very large or small arguments, arguments already slightly 
distrubed by earlier rounding errors.

A while ago we had a long-standing bug where tic generation was broken 
just by turning on -O2 in GCC, but only on some platforms.  Suffice it 
to say that this is a kind of problem I'd rather not have to face again.

> In some way it also removes the question that Hans raised in the code.  I'm sure 
> you can't recall that far back, Hans, but a question I have is just exactly was 
> this approach supposed to achieve?  

Basically, it's that pow() isn't required to treat integer exponents 
specially, so it can easily destroy more precision than dbl_raise() in 
its existing form does.

> One thing I wonder about is the following.  Say I modify the above code to be:
[...]
> Wouldn't you think that this is a better formulation in terms of precision? 
> That is, we've a direct division in one case, and avoid a double division in 
> another case.  But if I run this version of gnuplot on all.dem, the result is 
> differences other than just the times and dates.  

Well, you've just proved that it's not a better formulation, haven't you?

99 bottles of beer

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

I just noticed that gnuplot does not have it's own version of the
famous 99 bottles of beer song (http://99-bottles-of-beer.net/).

Here I present my version for discussion before I submit it.
On the site it is stated that "Your example should demonstrate the
main advantages and features of the language". I would appreciate
suggestions to improve the script with respect to this.

Bastian

Re: "wxt on Mac": news

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

On Friday 30 March 2007 10:41, Timoth=C3=A9e Lecomte wrote:
>=20
> - I tried on the sample app what is the second most important aspect of
> the wxt implementation: putting the event loop in a separate thread. And
> bingo ! I get the same problem as with wxt... Although the separate thread
> and its event loop are running, the latter does not process the window
> events. It turns out that this is a limitation of Cocoa app (MacOS
> programming toolkit):
> "The main thread of the application is responsible for handling events.
> The main thread is the one blocked in the run method of NSApplication,
> usually invoked in an application=C2=92s main function. "
> (http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading=
/articles/CocoaSafety.html)

Hmm. I'm not sure I read that document the same way you do. It says:

Events
The main thread of the application is responsible for handling events.
The main thread is the one blocked in the run method of NSApplication,
usually invoked in an application=E2=80=99s main function. While the Applic=
ation
Kit continues to work if other threads are involved in the event path,
operations can occur out of sequence. For example, if two different
threads are responding to key events, the keys could be received out of ord=
er.
By letting the main thread process events, you achieve a more consistent us=
er
experience. Once received, events can be dispatched to secondary threads for
further processing if desired. You can call the postEvent:atStart: method of
NSApplication from a secondary thread to post an event to the main thread=
=E2=80=99s
event queue. Order is not guaranteed with respect to user input events, how=
ever.
The main thread of the application is still responsible for handling events
in the event queue.

Note the phrase: "if two different threads are responding to key events,
the keys could be received out of order".  To me that implies that it is
indeed possible to do event handling in the daughter threads.  It is just
warning you that the sequence of handling is not guaranteed, which is not
surprising.

> I've searched for this "run" method in the wxWidgets code, but could not
> find it. MacOS development involves a mixture of layers called Foundation,
> Cocoa and Carbon (like GLib, Cairo, GTK and friends) and I'm afraid this
> 'run' method is in fact hidden somewhere else.

Perhaps section 4.2.2 of this document is useful?

    developer.imendio.com/files/ developer/Porting-Gtk-MacOSX.pdf=20



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

Re: "wxt on Mac": news

[<tim...@en...>]

> On Friday 30 March 2007 12:49, Timothée Lecomte wrote:
>> > On Friday 30 March 2007 10:41, Timothée Lecomte wrote:
>> >> So there is one remaining thing to try, but this will involve more
>> >> work on my part: changing the way wxt works on Unix and Mac and
>> >> arrange it so that the main thread runs the event loop while the
>> >> usual gnuplot command-line loop runs in the separate thread.
>> >
>> > Sounds to me that Cocoa is broken by design.
>> > Given this design limitation,
>> > I suspect it would be easier/better to use the gnuplot+gnuplot_x11
>> model.
>> > Instead of running wxt as a daughter thread, spawn a separate process
>> > for which it is the main thread.
>>
>> That's an option, with its own issues
>> (locating the executable,
>   should not be an issue on OSX
>
>> using an interprocess communication mechanism
>   already works on OSX for x11 terminal; this should be no worse

right

>
>> - pipes are not available on Windows
>   not relevant to OSX, surely?
>

My point is that I want to share code/implementation for as more platforms
as possible.

>> -, bottlenecks in this mechanism, etc.).
>   This one is a real issue, however.
>   One my linux machines, the wxt terminal is somewhat slower than x11,
>   and x11 is already limited partly by the pipe throughput between
>   gnuplot and gnuplot_x11.
>   The question is: would the slowdown due to limited pipe throughput
>   be additive with the slowdown due to using wxt, or is it partially
>   masked by it?  I.e. does the pipe transfer overlap with the execution
>   of drawing commands?  If so, then the additional slowdown due to
>   piping may be minimal in practice.
>

You're right, in the current situation of cairo performance, the
bottleneck would be the drawing. But the current situation is using only
software rendering, whereas Cairo can also draw directly to native
"surfaces" (it's what is done in wxt on Windows, and the rendering is
indeed faster than with linux, where the rendering is done purely in
software) and such a performance gain may put the pipe as the bottleneck
again.

But still, if it's really more practical to have a separate process, it
may be worth it.

>
> Other possible solution:
>
> Some quick googling led me to some pages that seem to imply that
> apps have a choice between using carbon or cocoa.  If this problem is
> due to a mis-feature in cocoa, do we have the option of using carbon
> instead?  (I've never done development on OSX, and have only a vague
> idea what the difference between the two is, other than historically).
>

Unfortunately, _wxWidgets_ already uses both, and apart from dropping
wxWidgets, I don't see a solution (FYI the MacOS port of GTK+ seems to do
the same, i.e. use both Cocoa and Carbon for fine-tuning).
Cocoa is object-oriented, written in "Objective-C", whereas Carbon is pure
C. The object-oriented approach is supposed to be more adapted for GUI
development.

Best regards,

Timothée

Re: "wxt on Mac": news

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

On Friday 30 March 2007 12:49, Timoth=E9e Lecomte wrote:
> > On Friday 30 March 2007 10:41, Timoth=E9e Lecomte wrote:
> >> So there is one remaining thing to try, but this will involve more
> >> work on my part: changing the way wxt works on Unix and Mac and
> >> arrange it so that the main thread runs the event loop while the
> >> usual gnuplot command-line loop runs in the separate thread.
> >
> > Sounds to me that Cocoa is broken by design.
> > Given this design limitation,
> > I suspect it would be easier/better to use the gnuplot+gnuplot_x11 mode=
l.
> > Instead of running wxt as a daughter thread, spawn a separate process
> > for which it is the main thread.
>=20
> That's an option, with its own issues=20
> (locating the executable,=20
  should not be an issue on OSX

> using an interprocess communication mechanism
  already works on OSX for x11 terminal; this should be no worse

> - pipes are not available on Windows=20
  not relevant to OSX, surely?

> -, bottlenecks in this mechanism, etc.).
  This one is a real issue, however.
  One my linux machines, the wxt terminal is somewhat slower than x11,
  and x11 is already limited partly by the pipe throughput between=20
  gnuplot and gnuplot_x11.
  The question is: would the slowdown due to limited pipe throughput
  be additive with the slowdown due to using wxt, or is it partially
  masked by it?  I.e. does the pipe transfer overlap with the execution
  of drawing commands?  If so, then the additional slowdown due to=20
  piping may be minimal in practice.


Other possible solution:

Some quick googling led me to some pages that seem to imply that
apps have a choice between using carbon or cocoa.  If this problem is
due to a mis-feature in cocoa, do we have the option of using carbon
instead?  (I've never done development on OSX, and have only a vague
idea what the difference between the two is, other than historically).



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

Re: "wxt on Mac": news

[<tim...@en...>]

>> On Friday 30 March 2007 10:41, Timothée Lecomte wrote:
>
> My thinking is more than gnuplot was bit designed for this kind of things.

s/than/that
s/bit/not

>
> Timothée
>
>

Re: "wxt on Mac": news

[<tim...@en...>]

> On Friday 30 March 2007 10:41, Timothée Lecomte wrote:
>> So there is one remaining thing to try, but this will involve more work
>> on
>> my part: changing the way wxt works on Unix and Mac and arrange it so
>> that
>> the main thread runs the event loop while the usual gnuplot command-line
>> loop runs in the separate thread.
>
> Won't this prevent switching to another interactive terminal type?
>
> Sounds to me that Cocoa is broken by design.

Well, X11 is more flexible, but has its own little problems ;) Note that
Windows has the same limitation (GUI loop in the main thread).
My thinking is more than gnuplot was bit designed for this kind of things.
I have put a lot of thoughts into a better design, I'm not quite there
yet, but we never know ... (it's quite close to our problem with "keep
processing terminal events even when it's not the current one" for which
we have an entry in the tracker).

> Given this design limitation,
> I suspect it would be easier/better to use the gnuplot+gnuplot_x11 model.
> Instead of running wxt as a daughter thread, spawn a separate process
> for which it is the main thread.
>
> 	Ethan

That's an option, with its own issues (locating the executable, using an
interprocess communication mechanism - pipes are not available on Windows
-, bottlenecks in this mechanism, etc.).

Timothée

Re: "wxt on Mac": news

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

On Friday 30 March 2007 10:41, Timoth=E9e Lecomte wrote:
> So there is one remaining thing to try, but this will involve more work on
> my part: changing the way wxt works on Unix and Mac and arrange it so that
> the main thread runs the event loop while the usual gnuplot command-line
> loop runs in the separate thread.

Won't this prevent switching to another interactive terminal type?

Sounds to me that Cocoa is broken by design.  Given this design limitation,
I suspect it would be easier/better to use the gnuplot+gnuplot_x11 model.
Instead of running wxt as a daughter thread, spawn a separate process
for which it is the main thread.

	Ethan

> Dear Mojca, Joe, and all gnuplot enthusiasts,
>=20
> Here are some news about the availability of the wxt terminal for the
> MacOS platform. I have had the chance to get my hands on my MacBook and I
> have worked a little bit on the issues you got when trying to use the wxt
> terminal.
>=20
> To sum up where we were last time we talked about it:
>=20
> - building seems to be ok. The most painful part is to build recent enough
> (i.e. using Fink) glib, cairo, pango & wxWidgets. Fortunately, this is
> almost to be done the Unix way, 'configure; make; make install'. The
> exceptions are to disable features for cairo so that it doesn't ask for
> Freetype or fontconfig (useless here).
>=20
> - executing gnuplot and trying to use wxt, you successfully get plot
> windows, but those seem to be "dead". The mouse changes to a colorful
> pinwheel, the buttons on the top (close, minimize, maximize) are grayed
> out, and you cannot grab the window to move it.
>=20
> - from my researches, "bundling" is necessary, but it didn't seem to
> change anything when done on gnuplot.
>=20
> So, I've investigated regarding this problem:
> - bundling is indeed necessary. I wrote a sample wxWidgets app, and tried
> to launch it without bundling it. It doesn't get the focus. BUT the mouse
> cursor stays the same, and the buttons on the top bar do work. So it's not
> really the root of the problem with the wxt terminal.
>=20
> - I tried on the sample app what is the second most important aspect of
> the wxt implementation: putting the event loop in a separate thread. And
> bingo ! I get the same problem as with wxt... Although the separate thread
> and its event loop are running, the latter does not process the window
> events. It turns out that this is a limitation of Cocoa app (MacOS
> programming toolkit):
> "The main thread of the application is responsible for handling events.
> The main thread is the one blocked in the run method of NSApplication,
> usually invoked in an application=92s main function. "
> (http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading=
/articles/CocoaSafety.html)
>=20
> I've searched for this "run" method in the wxWidgets code, but could not
> find it. MacOS development involves a mixture of layers called Foundation,
> Cocoa and Carbon (like GLib, Cairo, GTK and friends) and I'm afraid this
> 'run' method is in fact hidden somewhere else. Anyway, I tried to do as
> much initialization as I could in the separate thread, but it didn't work
> either.
>=20
> So there is one remaining thing to try, but this will involve more work on
> my part: changing the way wxt works on Unix and Mac and arrange it so that
> the main thread runs the event loop while the usual gnuplot command-line
> loop runs in the separate thread. The challenge is to do that only when
> wxt_init() is called, not before (doing it at startup time is easy, but I
> don't feel like it would be the right way).
> (note that on Windows we don't have this problem because the fake terminal
> already has the event loop and runs gnuplot command loop inside it)
> (as far as aquaterm is concerned, it has another design again, something
> like the X11 terminal: the GUI is in a different program with its own loop
> and talking with gnuplot through some interprocess communication
> mechanism)
>=20
> If some of you feel some inspiration regarding this issue, I would
> appreciate to listen to them !
>=20
> Best regards,
>=20
> Timoth=E9e Lecomte
>=20
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20

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

"wxt on Mac": news

[<tim...@en...>]

Dear Mojca, Joe, and all gnuplot enthusiasts,

Here are some news about the availability of the wxt terminal for the
MacOS platform. I have had the chance to get my hands on my MacBook and I
have worked a little bit on the issues you got when trying to use the wxt
terminal.

To sum up where we were last time we talked about it:

- building seems to be ok. The most painful part is to build recent enough
(i.e. using Fink) glib, cairo, pango & wxWidgets. Fortunately, this is
almost to be done the Unix way, 'configure; make; make install'. The
exceptions are to disable features for cairo so that it doesn't ask for
Freetype or fontconfig (useless here).

- executing gnuplot and trying to use wxt, you successfully get plot
windows, but those seem to be "dead". The mouse changes to a colorful
pinwheel, the buttons on the top (close, minimize, maximize) are grayed
out, and you cannot grab the window to move it.

- from my researches, "bundling" is necessary, but it didn't seem to
change anything when done on gnuplot.

So, I've investigated regarding this problem:
- bundling is indeed necessary. I wrote a sample wxWidgets app, and tried
to launch it without bundling it. It doesn't get the focus. BUT the mouse
cursor stays the same, and the buttons on the top bar do work. So it's not
really the root of the problem with the wxt terminal.

- I tried on the sample app what is the second most important aspect of
the wxt implementation: putting the event loop in a separate thread. And
bingo ! I get the same problem as with wxt... Although the separate thread
and its event loop are running, the latter does not process the window
events. It turns out that this is a limitation of Cocoa app (MacOS
programming toolkit):
"The main thread of the application is responsible for handling events.
The main thread is the one blocked in the run method of NSApplication,
usually invoked in an application’s main function. "
(http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/articles/CocoaSafety.html)

I've searched for this "run" method in the wxWidgets code, but could not
find it. MacOS development involves a mixture of layers called Foundation,
Cocoa and Carbon (like GLib, Cairo, GTK and friends) and I'm afraid this
'run' method is in fact hidden somewhere else. Anyway, I tried to do as
much initialization as I could in the separate thread, but it didn't work
either.

So there is one remaining thing to try, but this will involve more work on
my part: changing the way wxt works on Unix and Mac and arrange it so that
the main thread runs the event loop while the usual gnuplot command-line
loop runs in the separate thread. The challenge is to do that only when
wxt_init() is called, not before (doing it at startup time is easy, but I
don't feel like it would be the right way).
(note that on Windows we don't have this problem because the fake terminal
already has the event loop and runs gnuplot command loop inside it)
(as far as aquaterm is concerned, it has another design again, something
like the X11 terminal: the GUI is in a different program with its own loop
and talking with gnuplot through some interprocess communication
mechanism)

If some of you feel some inspiration regarding this issue, I would
appreciate to listen to them !

Best regards,

Timothée Lecomte

Re: More efficient "dbl_raise"

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

Daniel J Sebald wrote:
>>But if I run this version of gnuplot on all.dem, the result is 
>>differences other than just the times and dates.  So which is the preferred 
>>result formulation?
> 
> 
> Hold on a bit, I may have overlooked a small change...

Yeah, changing the return value to

     if (exponent < 0)
	return (tics / power);
     else
	return (tics * power);

results in the same exact PostScript results for all.dem.  So there apparently 
is not consequence of

     if (exponent < 0)
         power = 1 / power;

in terms of precision.

Dan

Re: More efficient "dbl_raise"

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

> But if I run this version of gnuplot on all.dem, the result is 
> differences other than just the times and dates.  So which is the preferred 
> result formulation?

Hold on a bit, I may have overlooked a small change...