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

Re: Complex Exponential Integral

[Erik L. <eri...@gm...>]

Apologies - I only sent this to Ethan directly.

---------- Forwarded message ---------

Thank you. I can confirm that this works properly. (I only tried it
with/without ZEXINT and CEXINT) Just two small (cosmetic) points:

* There is a closing parenthesis missing in configure. The corrected
configure.ac is attached

* In my setup, configure detects ZEXINT because I set LIBAMOS_LDFLAGS
(before calling configure), which then gets added automatically to LD_FLAGS:

checking for amos libraries using LDFLAGS:  -L/usr/local/lib -lcerf
-lopenspecfun -lgfortran /usr/local/lib/libzexpint.a ...

checking for library containing zairy_... none required

checking for library containing zexint_... none required


I noticed that configure then adds "-L/home/local/lib64" in LIBS in
the Makefile, which may be specific to your system and not serve a purpose
in other systems? (It is hard-wired in configure.)

Best,

Erik

On Thu, Jul 10, 2025 at 3:52 PM Ethan A Merritt <me...@uw...> wrote:

> I have just pushed changes to the configure script and to amos_airy,c
> so that ZEXINT is used if found during configuration in preference to
> CEXINT.
> I tested configure+build against libraries with or without ZEXINT.
>
> commit dda9e5051d
>
> Since both routines were available for testing, I also sampled the
> real/imaginary
> plane for the difference in output between parallel calls to CEXINT and
> ZEXINT
> for orders 2,3,4, and 5.
> The maximum difference found was on the order of    3 x 10^{-15}
> Pure noise level for double precision would be about  2 x 10^{-16}
> Pure noise level for single precision would be about    1 x 10^{-7}.
>
> cheers,
>         Ethan
>
>
>

Re: Complex Exponential Integral

[Ethan A M. <me...@uw...>]

I have just pushed changes to the configure script and to amos_airy,c
so that ZEXINT is used if found during configuration in preference to CEXINT.
I tested configure+build against libraries with or without ZEXINT.

commit dda9e5051d

Since both routines were available for testing, I also sampled the real/imaginary
plane for the difference in output between parallel calls to CEXINT and ZEXINT
for orders 2,3,4, and 5.
The maximum difference found was on the order of    3 x 10^{-15} 
Pure noise level for double precision would be about  2 x 10^{-16}
Pure noise level for single precision would be about    1 x 10^{-7}.

cheers,
	Ethan

On Wednesday, 9 July 2025 23:55:03 PDT Ethan A Merritt wrote:
> On Wednesday, 9 July 2025 22:12:34 PDT Erik Luijten wrote:
> > I think we are mostly in agreement; I would be happy with "configure" being
> > able to detect ZEXINT and then use the call that I implemented in
> > amos_airy.c (as attached to my earlier email).
> 
> Right.  I'll work on a modification to the configure script.
> 
> > Just for completeness: My concerns with the current situation are that (1)
> > it is not documented (unless I overlooked it) that CEXINT must be compiled
> > in a way that upgrades all floats to double (plus accompanying changes to
> > i1mach/d1mach); 
> 
> [shrug]  I think it's outside the scope of gnuplot documentation to instruct
> people on how to build a math library.   I do bundle build instructions and a
> Makefile together with the libamos source files if anyone asks me for a copy.
> I put this all together quite a while ago, but at the time I found I needed to
> tell the compiler to make REAL*8 and DOUBLE*8 the default for all the
> Amos routines, not just CEXINT.  Makefile attached. 
> 
> > (2) *generally* there is no guarantee that such an
> > "upgrade" would yield the desired precision. I acknowledge that for CEXINT
> > it may work fine, so this is primarily an aesthetic objection.
> 
> I have just done a line-by-line comparison of the ZEXINT and CEXINT code.
> Except for the D vs E declaration of Fortran constant values which I noted
> before, the only differences are the packing/unpacking of real and imaginary
> components into a single COMPLEX variable vs two parallel DOUBLE variables.
> So yes, they two versions of the algorithm have the same precision when
> compiled with the same compiler flags. 
> 
> Note: The 1990 Amos paper documents the accuracy of the algorithm as
> "18 digits" but notes that this may not be achieved on the hardware of
> "some machines".  And indeed this is higher precision than guaranteed
> by IEEE 754 and 64-bits. I suspect anyone who cares about the difference
> between 16-bit and 18-bit accuracy for expint() is not relying on gnuplot
> to provide it :-)
> 
> Digression:   When I modified gnuplot to use 64-bit integers I also looked
> into using gcc extensions so that the floating point calculations could use
> 80-bits rather than 64-bits on architectures that support it.  That turned
> out to be a morass; I dropped the idea pretty fast. 
> 
> > Please let me know once you are ready to let me test the new version of
> > configure.
> 
> Sure.  I'll probably break out and add ZEXINT itself to my library collection
> first so I will be able to make sure the whole thing works here.   
> 
>   cheers
> 	Ethan
> 
> > Best,
> > 
> > Erik
> > 
> > 
> > On Wed, Jul 9, 2025 at 9:30 PM Ethan A Merritt <me...@uw...> wrote:
> > 
> > > On Wednesday, 9 July 2025 06:25:07 PDT Erik Luijten wrote:
> > > >
> > > > - That being said, I think it is not ideal that this configuration option
> > > > then uses a version of cexint that must be modified by the user. Instead,
> > > > the version of amos_airy.c that I sent yesterday uses an unmodified
> > > ZEXINT
> > > > as distributed in Netlib, minimizing confusion (and effort) for anyone
> > > who
> > > > wishes to incorporate it when they compile gnuplot. You clearly
> > > understand
> > > > the potential issues of upgrading a single-precision function to double
> > > > precision, but not everyone does and it also would require the user to
> > > > address a matter that was resolved by the original author from the
> > > outset.
> > >
> > > I am not following your thought there.  What matter is that?
> > >
> > > The biggest change/cleanup/upgrade/whatever is that the original code
> > > was written in an era when hardware floating support varied widely.
> > > The r1mach/d1mach per-installation customization had to deal with
> > > all sorts of setups, whereas now hardware support for IEEE 754 floating
> > > point is nearly universal.
> > >
> > > As described in the 1990 paper, the separate double-precision routine was
> > > needed because at that time Fortran did not support double precision
> > > complex
> > > as an intrinsic type. Since then (Fortran90? Fortran95?μ) this limitation
> > > went away, and so long as the algorithm itself provides sufficient
> > > precision
> > > the use of single vs double precision can be made a compile-time option.
> > >
> > > I do not recall having to change anything in the code to CEXINT itself.
> > > I only replaced the separate machine-dependent routines in favor of
> > > letting the compiler pick up the relevant constants from the system
> > > environment it was compiled on, and the compiler flags used to build it.
> > >
> > > > - By the way, you mention that you found an older version of CEXINT, but
> > > > the text you quote ("REVISION DATE  870515", etc.) is identical in the
> > > ACM
> > > > version https://urldefense.com/v3/__https://www.netlib.org/toms-2014-06-10/683__;!!K-Hz7m0Vt54!iwiffB-qjYH_1hni74sIr0ktLbCn0P2jQlKbCMP8UgcD3GZ7yPj0ouUn2UsTg7d08Hwtnmzu50gBQtiWqElv$  ; there are just
> > > other
> > > > subroutines preceding it in the same file. In fact, I do not think that
> > > the
> > > > copyright situation favors CEXINT; the two functions were created at the
> > > > same time under the same circumstances (ZEXINT also carries the 1987
> > > date).
> > >
> > > Sure.  Both routines were written at the same time.  When the source code
> > > was placed in the TOMS archive someone added the comment lines at the top
> > > citing the 1990 paper.  My only point was that copies of the source code
> > > existed
> > > that predated the TOMS publication thus avoided any implied claim of
> > > license
> > > requirements imposed by the journal.
> > >
> > > > - Regarding concrete compilation: I compile ZEXINT and the other
> > > functions
> > > > it uses into a separate library (unlike you, I use i1mach and d1mach, but
> > > > rely on those being provided in libopenspecfun). I found that if I
> > > specify
> > > > this library in LIBAMOS_LDFLAGS, configure will detect it. Practically
> > > > speaking, I make this a static library so that users of the macOS binary
> > > do
> > > > not need to worry about it (I distribute gnuplot as a single static
> > > > executable).
> > > >
> > > > Depending on your view, the only question is then whether we switch from
> > > > CEXINT to ZEXINT (which would also require a small change in
> > > "configure").
> > >
> > > I wouldn't "switch".  I would have configure search for both and use
> > > whichever
> > > it found first.  I don't care much which one it finds first, unless as you
> > > say there
> > > is the possibility of conflicting symbols in another library.  If I
> > > understand your
> > > plan correctly, that would not be a problem for either of us.
> > >
> > > The autoconf scripts are not my strong point (to say the least), but I'll
> > > see
> > > what I can come up with.
> > >
> > > > Apologies for reviving this old topic!
> > >
> > > No problem - a trip down memory lane.
> > >
> > > By the way, the Julia language project uses a reimplemention in c99 for
> > > the Amos library functions including expint().   I did not pursue using it
> > > because unlike openspecfun it would not be available to users as a standard
> > > linux distribution package.
> > > But if you're already building static libraries yourself, and not under
> > > linux,
> > > that might be of interest to you as an alternative.
> > >
> > >   cheers,
> > >         Ethan
> > >
> > > >
> > > > Erik
> > > >
> > > > On Tue, Jul 8, 2025 at 11:52 PM Ethan A Merritt <me...@uw...> wrote:
> > > >
> > > > > On Tuesday, 8 July 2025 18:55:03 PDT Erik Luijten wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I found the code on
> > > https://urldefense.com/v3/__https://dl.acm.org/doi/abs/10.1145/78928.78934__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUEM2Nmkq6$
> > > ; the
> > > > > > supplementary material contains all the subroutines concatenated
> > > into one
> > > > > > file.
> > > > > > It is also available on
> > > https://urldefense.com/v3/__https://www.netlib.org/toms-2014-06-10/__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUENvigquW$
> > > > > (scroll to
> > > > > > algorithm 683).
> > > > > > The fact that it is on netlib tells me it is likely free to use.
> > > > >
> > > > > At the top of that page is a notice:
> > > > >
> > > > >     Use of ACM Algorithms is subject to the ACM Software Copyright and
> > > > >     License Agreement
> > > > >
> > > > > > However, the ACM TOMS license agreement is here:
> > > > > >
> > > https://urldefense.com/v3/__https://www.acm.org/publications/policies/software-copyright-notice__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUEHrkADU9$
> > > .
> > > > > > I am not sure if this conflicts with Gnuplot's license?
> > > > >
> > > > > The issue is not that it conflicts with gnuplot's license.
> > > > > The issue is that Debian, for example, was concerned that inclusion
> > > > > with gnuplot would make the whole package non-free.
> > > > >
> > > > > Thanks for the link to the ACM site.  They have very much changed
> > > > > their policy since I first looked into this.  And it seems that for
> > > > > software
> > > > > published since 2013 the ACM does not claim any rights.  That's good.
> > > > > Unfortunately it doesn't help.  For older software (the Amos routines
> > > > > are from the 1980s) they state that the terms of the
> > > > > earlier ACM license still apply, which restricts commercial use.
> > > > > If that were true it would make the whole set of Amos routines
> > > > > [as obtained from them] non-free, but see below.
> > > > >
> > > > > > Whether a more permissive license applies to cexint_.f  than to
> > > > > > zexint_.f is also unclear to me.
> > > > >
> > > > > It is my belief that ACM was simplly wrong in ever claiming the right
> > > > > to license or restrict any of these routines.  The were produced at
> > > > > Sandia National Laboratories under US government contract, and as
> > > > > I understand it (I am not a lawyer and all that) that makes them
> > > > > "Works Created by the United States Government" and as such not
> > > > > subject to copyright.
> > > > >
> > > > > But that's only me.  I don't have any sway over what Debian or anyone
> > > > > else considers to be "non-free".  Based on past conversations my
> > > > > understanding is that Debian considers the TOMS license to poison
> > > > > any project that includes it as non-free.  Those conversations were
> > > > > many years ago, so I suppose the issue could be revisited.
> > > > >
> > > > > > An awkward point, to the best of my understanding, is that an
> > > unmodified
> > > > > > version of cexint will not work with the Gnuplot source code, as it
> > > > > expects
> > > > > > single-precision arguments. Yet, changing cexint is not
> > > > > > completely straightforward: Comparing cexint and zexint (and the
> > > > > > accompanying routines cexent and zexent), I noticed the more subtle
> > > point
> > > > > > that cexint uses r1mach.f and zexint uses d1mach.f; moreover, they
> > > use
> > > > > > different constants from i1mach to establish precision (elements
> > > 12,13
> > > > > vs.
> > > > > > 15,16). Also, in zexint all constants are replaced by their
> > > > > > double-precision counterparts.
> > > > >
> > > > > This gets complicated.
> > > > >
> > > > > I have downloaded and had a quick look at the code available through
> > > the
> > > > > netlib site.  It is apparently newer than the code I have here. It
> > > cites
> > > > > the 1990
> > > > > TOMS paper at the top and as you say it concatenates many smaller
> > > routines,
> > > > > whereas the code I have claims to be from 1987 and starts
> > > > > C***BEGIN PROLOGUE  CEXINT
> > > > > C***DATE WRITTEN   870515   (YYMMDD)
> > > > > C***REVISION DATE  870515   (YYMMDD)
> > > > > C***CATEGORY NO.  B5E
> > > > > C***KEYWORDS  EXPONENTIAL INTEGRALS, SINE INTEGRAL, COSINE INTEGRAL
> > > > > C***AUTHOR  AMOS, DONALD E., SANDIA NATIONAL LABORATORIES
> > > > > C***PURPOSE  TO COMPUTE EXPONENTIAL INTEGRALS OF A COMPLEX ARGUMENT
> > > > >
> > > > > There are some code differences elsewhere, but I did not look in detail
> > > > > and don't have anything useful to say about them right now.
> > > > >
> > > > > Beyond that, to the extent that there are precision-sensitive
> > > constants in
> > > > > the
> > > > > code the numerical values seem identical, but they are declared, for
> > > > > example
> > > > > -5.77215664901532861E-01   vs   -5.77215664901532861D-01
> > > > > As I recall in 1987 that difference was necessary to distinguish
> > > single-
> > > > > and
> > > > > double- precision constants, but I don't think current Fortran pays any
> > > > > attention to it when using the constant in a double-precision context.
> > > > > I compile with
> > > > >      gfortran -fdefault-real-8 -fdefault-double-8
> > > > > I.e. everything should be double precision by default.
> > > > > So although you describe cexint() as a single-precision routine,
> > > > > that isn't true when I build it here.  Of course it's always possible
> > > > > I missed something in the code that loses precision, but given that
> > > > > it iterates until convergence I think that would not even matter.
> > > > >
> > > > > > For all these reasons, I would argue that if copyright restrictions
> > > are
> > > > > the
> > > > > > same for cexint and zexint, it would be better to use the latter - a
> > > user
> > > > > > could then directly download this subroutine and use it without
> > > > > > modifications.
> > > > >
> > > > > You may have a point about an end-user who builds from source.
> > > > > But you've been building and making available binaries for MacOS,
> > > right?
> > > > > I think that moves any legal question to "distribution" rather than
> > > "use".
> > > > > You may well agree with me that the code you want to include is not
> > > subject
> > > > > to the TOMS license even though TOMS seems to say it is.  But you
> > > should
> > > > > at least be aware that the question has been raised in the past.
> > > > >
> > > > > > Lastly, a tricky point that is easily overlooked is that i1mach,
> > > r1mach,
> > > > > > d1mach need to be configured for x86. Moreover, since openspecfun is
> > > > > built
> > > > > > as a library, it already contains i1mach and d1mach, opening the
> > > door for
> > > > > > conflicting functions if one gathers cexint/zexint into a separate
> > > > > > library...
> > > > >
> > > > > As to r1mach.f and d1mach.f,  I am not using either of them here.
> > > > > I replaced these with a C-language data block (attached) that I use
> > > > > to build libamos from the Sandia sources for all the Amos routines.
> > > > > I link against that rather than against libopenspecfun.
> > > > >
> > > > > I sent my collection of libamos source to Tatsuro Matsuoka in case
> > > > > he wanted to use them for building Windows packages.
> > > > > I even  considered adding source for all the libamos routines as a
> > > > > separate subdirectory in the gnuplot distribution package.
> > > > > But then I found that many/most linux distros  already provide
> > > > > libopenspecfun so I decided against complicating the gnuplot packaging
> > > > > by having it supply a whole separate library for the sake of a single
> > > > > routine.
> > > > >
> > > > > > I am attaching my modified version of amos_airy.c, in case you are
> > > swayed
> > > > > > by my argument...
> > > > >
> > > > > Are you thinking that the user would build zexint.o as a separate
> > > object
> > > > > module and then add it to the Makefile somehow?
> > > > >
> > > > > I would prefer to make it a configuration option. Not sure how best
> > > > > to capture a single extra source file whose provenance and dependencies
> > > > > we don't control.  I think it would be easier to require that it has
> > > > > already
> > > > > been wrapped into a shared library.
> > > > > Or hey, another alternative is to provide a template for making it
> > > > > a plugin.  The distribution package currently has a demo plugin for
> > > > > uigamma.  Providing a plugin for a Fortran routine might be of
> > > > > interest even apart from filling a gap in special function coverage.
> > > > >
> > > > >       Ethan
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 8, 2025 at 7:26 PM Ethan A Merritt <me...@uw...>
> > > wrote:
> > > > > >
> > > > > > > On Tuesday, 8 July 2025 14:21:01 PDT Erik Luijten wrote:
> > > > > > > > Hi Ethan,
> > > > > > > >
> > > > > > > > In amos_airy.c, you write:
> > > > > > > >
> > > > > > > >  * The cexint_() routine is also from the AMOS collection, but
> > > is not
> > > > > > > part
> > > > > > > >  * of the Bessel function subset and not included in
> > > libopenspecfun.
> > > > > > > >  * I could not find source for a version of the source that
> > > splits
> > > > > the
> > > > > > > >  * real and imaginary parts of the arguments as with the zxxxx.f
> > > > > Bessel
> > > > > > > >  * routines; this one accepts and returns a CMPLX argument rather
> > > > > than
> > > > > > > > separate
> > > > > > > >  * real and imaginary parts.
> > > > > > > >  *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN
> > > > > Subroutine
> > > > > > > >  *             for Exponential Integrals of a Complex Argument
> > > > > > > >  *             ACM Trans. Math. Software 16:178-182 (1990)
> > > > > > > >
> > > > > > > > This confuses me for two reasons:
> > > > > > > > - You invoke CEXINT as a double precision function, even though
> > > this
> > > > > > > > Fortran function is single precision.
> > > > > > >
> > > > > > > > - The algorithm 683 you quote DOES provide a separate double
> > > > > precision
> > > > > > > > function, ZEXINT. Moreover, that function does exactly what you
> > > were
> > > > > > > > looking for, namely taking and returning separate real and
> > > imaginary
> > > > > > > parts.
> > > > > > >
> > > > > > > There is some history behind this due to IMHO over-zealous, or at
> > > least
> > > > > > > overly pessimistic, concern about license contamination with
> > > non-free
> > > > > code.
> > > > > > > I cited a publication in ACM/TMS that describes the implementation.
> > > > > > > However, people have assserted that code obtained through the ACM
> > > > > > > journal is non-free because the journal claims copyright.
> > > > > > > I believe this to be factually incorrect; the published article
> > > may be
> > > > > > > subject
> > > > > > > to copyright but not the code it describes. In any case, rather
> > > than
> > > > > pursue
> > > > > > > the argument I instead used copies of the code obtained from US
> > > > > national
> > > > > > > lab repositories.  I found source there for cexint.f but not for
> > > > > zexint.f,
> > > > > > > so that is what I use myself to build libamos and what I invoked
> > > from
> > > > > the
> > > > > > > gnuplot code.
> > > > > > >
> > > > > > > Even so that was apparently not sufficient by itself to convince
> > > > > hard-core
> > > > > > > "free licenses only" gatekeepers.
> > > > > > > There is an explicit statement of the [non]copyright status of the
> > > code
> > > > > > > in the cited 1985 Sandia National Laboratory report, but that
> > > report
> > > > > > > predated development of the expint routines (1990?) and I did not
> > > find
> > > > > a
> > > > > > > separate Sandia report that mentions them specifically.
> > > > > > > That is probably why neither routine is included in libopenspec,
> > > > > > > and why inclusion in gnuplot is a configuration option.
> > > > > > >
> > > > > > > > I changed f_amos_cexint to use ZEXINT (just for my own
> > > edification)
> > > > > and
> > > > > > > it
> > > > > > > > works properly. However, before submitting it, I wonder what am I
> > > > > > > missing?
> > > > > > >
> > > > > > > Where did you obtain a copy of the source?
> > > > > > > Can you document the relevant claim or non-claim of copyright or
> > > > > > > licensing?
> > > > > > >
> > > > > > > And, out of curiosity, is there anything in the zexint.f code that
> > > > > would
> > > > > > > differentiate it from a single-precision version other than
> > > declaration
> > > > > > > of the variables as Fortran DOUBLE PRECISION?
> > > > > > >
> > > > > > >         Ethan
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thank you,
> > > > > > > >
> > > > > > > > Erik
> > >
> > >
> > >
> > >
> > 
> 
> 
> 

Re: Complex Exponential Integral

[Ethan A M. <me...@uw...>]

On Wednesday, 9 July 2025 22:12:34 PDT Erik Luijten wrote:
> I think we are mostly in agreement; I would be happy with "configure" being
> able to detect ZEXINT and then use the call that I implemented in
> amos_airy.c (as attached to my earlier email).

Right.  I'll work on a modification to the configure script.

> Just for completeness: My concerns with the current situation are that (1)
> it is not documented (unless I overlooked it) that CEXINT must be compiled
> in a way that upgrades all floats to double (plus accompanying changes to
> i1mach/d1mach); 

[shrug]  I think it's outside the scope of gnuplot documentation to instruct
people on how to build a math library.   I do bundle build instructions and a
Makefile together with the libamos source files if anyone asks me for a copy.
I put this all together quite a while ago, but at the time I found I needed to
tell the compiler to make REAL*8 and DOUBLE*8 the default for all the
Amos routines, not just CEXINT.  Makefile attached. 

> (2) *generally* there is no guarantee that such an
> "upgrade" would yield the desired precision. I acknowledge that for CEXINT
> it may work fine, so this is primarily an aesthetic objection.

I have just done a line-by-line comparison of the ZEXINT and CEXINT code.
Except for the D vs E declaration of Fortran constant values which I noted
before, the only differences are the packing/unpacking of real and imaginary
components into a single COMPLEX variable vs two parallel DOUBLE variables.
So yes, they two versions of the algorithm have the same precision when
compiled with the same compiler flags. 

Note: The 1990 Amos paper documents the accuracy of the algorithm as
"18 digits" but notes that this may not be achieved on the hardware of
"some machines".  And indeed this is higher precision than guaranteed
by IEEE 754 and 64-bits. I suspect anyone who cares about the difference
between 16-bit and 18-bit accuracy for expint() is not relying on gnuplot
to provide it :-)

Digression:   When I modified gnuplot to use 64-bit integers I also looked
into using gcc extensions so that the floating point calculations could use
80-bits rather than 64-bits on architectures that support it.  That turned
out to be a morass; I dropped the idea pretty fast. 

> Please let me know once you are ready to let me test the new version of
> configure.

Sure.  I'll probably break out and add ZEXINT itself to my library collection
first so I will be able to make sure the whole thing works here.   

  cheers
	Ethan

> Best,
> 
> Erik
> 
> 
> On Wed, Jul 9, 2025 at 9:30 PM Ethan A Merritt <me...@uw...> wrote:
> 
> > On Wednesday, 9 July 2025 06:25:07 PDT Erik Luijten wrote:
> > >
> > > - That being said, I think it is not ideal that this configuration option
> > > then uses a version of cexint that must be modified by the user. Instead,
> > > the version of amos_airy.c that I sent yesterday uses an unmodified
> > ZEXINT
> > > as distributed in Netlib, minimizing confusion (and effort) for anyone
> > who
> > > wishes to incorporate it when they compile gnuplot. You clearly
> > understand
> > > the potential issues of upgrading a single-precision function to double
> > > precision, but not everyone does and it also would require the user to
> > > address a matter that was resolved by the original author from the
> > outset.
> >
> > I am not following your thought there.  What matter is that?
> >
> > The biggest change/cleanup/upgrade/whatever is that the original code
> > was written in an era when hardware floating support varied widely.
> > The r1mach/d1mach per-installation customization had to deal with
> > all sorts of setups, whereas now hardware support for IEEE 754 floating
> > point is nearly universal.
> >
> > As described in the 1990 paper, the separate double-precision routine was
> > needed because at that time Fortran did not support double precision
> > complex
> > as an intrinsic type. Since then (Fortran90? Fortran95?μ) this limitation
> > went away, and so long as the algorithm itself provides sufficient
> > precision
> > the use of single vs double precision can be made a compile-time option.
> >
> > I do not recall having to change anything in the code to CEXINT itself.
> > I only replaced the separate machine-dependent routines in favor of
> > letting the compiler pick up the relevant constants from the system
> > environment it was compiled on, and the compiler flags used to build it.
> >
> > > - By the way, you mention that you found an older version of CEXINT, but
> > > the text you quote ("REVISION DATE  870515", etc.) is identical in the
> > ACM
> > > version https://urldefense.com/v3/__https://www.netlib.org/toms-2014-06-10/683__;!!K-Hz7m0Vt54!iwiffB-qjYH_1hni74sIr0ktLbCn0P2jQlKbCMP8UgcD3GZ7yPj0ouUn2UsTg7d08Hwtnmzu50gBQtiWqElv$  ; there are just
> > other
> > > subroutines preceding it in the same file. In fact, I do not think that
> > the
> > > copyright situation favors CEXINT; the two functions were created at the
> > > same time under the same circumstances (ZEXINT also carries the 1987
> > date).
> >
> > Sure.  Both routines were written at the same time.  When the source code
> > was placed in the TOMS archive someone added the comment lines at the top
> > citing the 1990 paper.  My only point was that copies of the source code
> > existed
> > that predated the TOMS publication thus avoided any implied claim of
> > license
> > requirements imposed by the journal.
> >
> > > - Regarding concrete compilation: I compile ZEXINT and the other
> > functions
> > > it uses into a separate library (unlike you, I use i1mach and d1mach, but
> > > rely on those being provided in libopenspecfun). I found that if I
> > specify
> > > this library in LIBAMOS_LDFLAGS, configure will detect it. Practically
> > > speaking, I make this a static library so that users of the macOS binary
> > do
> > > not need to worry about it (I distribute gnuplot as a single static
> > > executable).
> > >
> > > Depending on your view, the only question is then whether we switch from
> > > CEXINT to ZEXINT (which would also require a small change in
> > "configure").
> >
> > I wouldn't "switch".  I would have configure search for both and use
> > whichever
> > it found first.  I don't care much which one it finds first, unless as you
> > say there
> > is the possibility of conflicting symbols in another library.  If I
> > understand your
> > plan correctly, that would not be a problem for either of us.
> >
> > The autoconf scripts are not my strong point (to say the least), but I'll
> > see
> > what I can come up with.
> >
> > > Apologies for reviving this old topic!
> >
> > No problem - a trip down memory lane.
> >
> > By the way, the Julia language project uses a reimplemention in c99 for
> > the Amos library functions including expint().   I did not pursue using it
> > because unlike openspecfun it would not be available to users as a standard
> > linux distribution package.
> > But if you're already building static libraries yourself, and not under
> > linux,
> > that might be of interest to you as an alternative.
> >
> >   cheers,
> >         Ethan
> >
> > >
> > > Erik
> > >
> > > On Tue, Jul 8, 2025 at 11:52 PM Ethan A Merritt <me...@uw...> wrote:
> > >
> > > > On Tuesday, 8 July 2025 18:55:03 PDT Erik Luijten wrote:
> > > > > Hi,
> > > > >
> > > > > I found the code on
> > https://urldefense.com/v3/__https://dl.acm.org/doi/abs/10.1145/78928.78934__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUEM2Nmkq6$
> > ; the
> > > > > supplementary material contains all the subroutines concatenated
> > into one
> > > > > file.
> > > > > It is also available on
> > https://urldefense.com/v3/__https://www.netlib.org/toms-2014-06-10/__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUENvigquW$
> > > > (scroll to
> > > > > algorithm 683).
> > > > > The fact that it is on netlib tells me it is likely free to use.
> > > >
> > > > At the top of that page is a notice:
> > > >
> > > >     Use of ACM Algorithms is subject to the ACM Software Copyright and
> > > >     License Agreement
> > > >
> > > > > However, the ACM TOMS license agreement is here:
> > > > >
> > https://urldefense.com/v3/__https://www.acm.org/publications/policies/software-copyright-notice__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUEHrkADU9$
> > .
> > > > > I am not sure if this conflicts with Gnuplot's license?
> > > >
> > > > The issue is not that it conflicts with gnuplot's license.
> > > > The issue is that Debian, for example, was concerned that inclusion
> > > > with gnuplot would make the whole package non-free.
> > > >
> > > > Thanks for the link to the ACM site.  They have very much changed
> > > > their policy since I first looked into this.  And it seems that for
> > > > software
> > > > published since 2013 the ACM does not claim any rights.  That's good.
> > > > Unfortunately it doesn't help.  For older software (the Amos routines
> > > > are from the 1980s) they state that the terms of the
> > > > earlier ACM license still apply, which restricts commercial use.
> > > > If that were true it would make the whole set of Amos routines
> > > > [as obtained from them] non-free, but see below.
> > > >
> > > > > Whether a more permissive license applies to cexint_.f  than to
> > > > > zexint_.f is also unclear to me.
> > > >
> > > > It is my belief that ACM was simplly wrong in ever claiming the right
> > > > to license or restrict any of these routines.  The were produced at
> > > > Sandia National Laboratories under US government contract, and as
> > > > I understand it (I am not a lawyer and all that) that makes them
> > > > "Works Created by the United States Government" and as such not
> > > > subject to copyright.
> > > >
> > > > But that's only me.  I don't have any sway over what Debian or anyone
> > > > else considers to be "non-free".  Based on past conversations my
> > > > understanding is that Debian considers the TOMS license to poison
> > > > any project that includes it as non-free.  Those conversations were
> > > > many years ago, so I suppose the issue could be revisited.
> > > >
> > > > > An awkward point, to the best of my understanding, is that an
> > unmodified
> > > > > version of cexint will not work with the Gnuplot source code, as it
> > > > expects
> > > > > single-precision arguments. Yet, changing cexint is not
> > > > > completely straightforward: Comparing cexint and zexint (and the
> > > > > accompanying routines cexent and zexent), I noticed the more subtle
> > point
> > > > > that cexint uses r1mach.f and zexint uses d1mach.f; moreover, they
> > use
> > > > > different constants from i1mach to establish precision (elements
> > 12,13
> > > > vs.
> > > > > 15,16). Also, in zexint all constants are replaced by their
> > > > > double-precision counterparts.
> > > >
> > > > This gets complicated.
> > > >
> > > > I have downloaded and had a quick look at the code available through
> > the
> > > > netlib site.  It is apparently newer than the code I have here. It
> > cites
> > > > the 1990
> > > > TOMS paper at the top and as you say it concatenates many smaller
> > routines,
> > > > whereas the code I have claims to be from 1987 and starts
> > > > C***BEGIN PROLOGUE  CEXINT
> > > > C***DATE WRITTEN   870515   (YYMMDD)
> > > > C***REVISION DATE  870515   (YYMMDD)
> > > > C***CATEGORY NO.  B5E
> > > > C***KEYWORDS  EXPONENTIAL INTEGRALS, SINE INTEGRAL, COSINE INTEGRAL
> > > > C***AUTHOR  AMOS, DONALD E., SANDIA NATIONAL LABORATORIES
> > > > C***PURPOSE  TO COMPUTE EXPONENTIAL INTEGRALS OF A COMPLEX ARGUMENT
> > > >
> > > > There are some code differences elsewhere, but I did not look in detail
> > > > and don't have anything useful to say about them right now.
> > > >
> > > > Beyond that, to the extent that there are precision-sensitive
> > constants in
> > > > the
> > > > code the numerical values seem identical, but they are declared, for
> > > > example
> > > > -5.77215664901532861E-01   vs   -5.77215664901532861D-01
> > > > As I recall in 1987 that difference was necessary to distinguish
> > single-
> > > > and
> > > > double- precision constants, but I don't think current Fortran pays any
> > > > attention to it when using the constant in a double-precision context.
> > > > I compile with
> > > >      gfortran -fdefault-real-8 -fdefault-double-8
> > > > I.e. everything should be double precision by default.
> > > > So although you describe cexint() as a single-precision routine,
> > > > that isn't true when I build it here.  Of course it's always possible
> > > > I missed something in the code that loses precision, but given that
> > > > it iterates until convergence I think that would not even matter.
> > > >
> > > > > For all these reasons, I would argue that if copyright restrictions
> > are
> > > > the
> > > > > same for cexint and zexint, it would be better to use the latter - a
> > user
> > > > > could then directly download this subroutine and use it without
> > > > > modifications.
> > > >
> > > > You may have a point about an end-user who builds from source.
> > > > But you've been building and making available binaries for MacOS,
> > right?
> > > > I think that moves any legal question to "distribution" rather than
> > "use".
> > > > You may well agree with me that the code you want to include is not
> > subject
> > > > to the TOMS license even though TOMS seems to say it is.  But you
> > should
> > > > at least be aware that the question has been raised in the past.
> > > >
> > > > > Lastly, a tricky point that is easily overlooked is that i1mach,
> > r1mach,
> > > > > d1mach need to be configured for x86. Moreover, since openspecfun is
> > > > built
> > > > > as a library, it already contains i1mach and d1mach, opening the
> > door for
> > > > > conflicting functions if one gathers cexint/zexint into a separate
> > > > > library...
> > > >
> > > > As to r1mach.f and d1mach.f,  I am not using either of them here.
> > > > I replaced these with a C-language data block (attached) that I use
> > > > to build libamos from the Sandia sources for all the Amos routines.
> > > > I link against that rather than against libopenspecfun.
> > > >
> > > > I sent my collection of libamos source to Tatsuro Matsuoka in case
> > > > he wanted to use them for building Windows packages.
> > > > I even  considered adding source for all the libamos routines as a
> > > > separate subdirectory in the gnuplot distribution package.
> > > > But then I found that many/most linux distros  already provide
> > > > libopenspecfun so I decided against complicating the gnuplot packaging
> > > > by having it supply a whole separate library for the sake of a single
> > > > routine.
> > > >
> > > > > I am attaching my modified version of amos_airy.c, in case you are
> > swayed
> > > > > by my argument...
> > > >
> > > > Are you thinking that the user would build zexint.o as a separate
> > object
> > > > module and then add it to the Makefile somehow?
> > > >
> > > > I would prefer to make it a configuration option. Not sure how best
> > > > to capture a single extra source file whose provenance and dependencies
> > > > we don't control.  I think it would be easier to require that it has
> > > > already
> > > > been wrapped into a shared library.
> > > > Or hey, another alternative is to provide a template for making it
> > > > a plugin.  The distribution package currently has a demo plugin for
> > > > uigamma.  Providing a plugin for a Fortran routine might be of
> > > > interest even apart from filling a gap in special function coverage.
> > > >
> > > >       Ethan
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Jul 8, 2025 at 7:26 PM Ethan A Merritt <me...@uw...>
> > wrote:
> > > > >
> > > > > > On Tuesday, 8 July 2025 14:21:01 PDT Erik Luijten wrote:
> > > > > > > Hi Ethan,
> > > > > > >
> > > > > > > In amos_airy.c, you write:
> > > > > > >
> > > > > > >  * The cexint_() routine is also from the AMOS collection, but
> > is not
> > > > > > part
> > > > > > >  * of the Bessel function subset and not included in
> > libopenspecfun.
> > > > > > >  * I could not find source for a version of the source that
> > splits
> > > > the
> > > > > > >  * real and imaginary parts of the arguments as with the zxxxx.f
> > > > Bessel
> > > > > > >  * routines; this one accepts and returns a CMPLX argument rather
> > > > than
> > > > > > > separate
> > > > > > >  * real and imaginary parts.
> > > > > > >  *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN
> > > > Subroutine
> > > > > > >  *             for Exponential Integrals of a Complex Argument
> > > > > > >  *             ACM Trans. Math. Software 16:178-182 (1990)
> > > > > > >
> > > > > > > This confuses me for two reasons:
> > > > > > > - You invoke CEXINT as a double precision function, even though
> > this
> > > > > > > Fortran function is single precision.
> > > > > >
> > > > > > > - The algorithm 683 you quote DOES provide a separate double
> > > > precision
> > > > > > > function, ZEXINT. Moreover, that function does exactly what you
> > were
> > > > > > > looking for, namely taking and returning separate real and
> > imaginary
> > > > > > parts.
> > > > > >
> > > > > > There is some history behind this due to IMHO over-zealous, or at
> > least
> > > > > > overly pessimistic, concern about license contamination with
> > non-free
> > > > code.
> > > > > > I cited a publication in ACM/TMS that describes the implementation.
> > > > > > However, people have assserted that code obtained through the ACM
> > > > > > journal is non-free because the journal claims copyright.
> > > > > > I believe this to be factually incorrect; the published article
> > may be
> > > > > > subject
> > > > > > to copyright but not the code it describes. In any case, rather
> > than
> > > > pursue
> > > > > > the argument I instead used copies of the code obtained from US
> > > > national
> > > > > > lab repositories.  I found source there for cexint.f but not for
> > > > zexint.f,
> > > > > > so that is what I use myself to build libamos and what I invoked
> > from
> > > > the
> > > > > > gnuplot code.
> > > > > >
> > > > > > Even so that was apparently not sufficient by itself to convince
> > > > hard-core
> > > > > > "free licenses only" gatekeepers.
> > > > > > There is an explicit statement of the [non]copyright status of the
> > code
> > > > > > in the cited 1985 Sandia National Laboratory report, but that
> > report
> > > > > > predated development of the expint routines (1990?) and I did not
> > find
> > > > a
> > > > > > separate Sandia report that mentions them specifically.
> > > > > > That is probably why neither routine is included in libopenspec,
> > > > > > and why inclusion in gnuplot is a configuration option.
> > > > > >
> > > > > > > I changed f_amos_cexint to use ZEXINT (just for my own
> > edification)
> > > > and
> > > > > > it
> > > > > > > works properly. However, before submitting it, I wonder what am I
> > > > > > missing?
> > > > > >
> > > > > > Where did you obtain a copy of the source?
> > > > > > Can you document the relevant claim or non-claim of copyright or
> > > > > > licensing?
> > > > > >
> > > > > > And, out of curiosity, is there anything in the zexint.f code that
> > > > would
> > > > > > differentiate it from a single-precision version other than
> > declaration
> > > > > > of the variables as Fortran DOUBLE PRECISION?
> > > > > >
> > > > > >         Ethan
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Thank you,
> > > > > > >
> > > > > > > Erik
> >
> >
> >
> >
> 


-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Re: Complex Exponential Integral

[Erik L. <eri...@gm...>]

I think we are mostly in agreement; I would be happy with "configure" being
able to detect ZEXINT and then use the call that I implemented in
amos_airy.c (as attached to my earlier email).

Just for completeness: My concerns with the current situation are that (1)
it is not documented (unless I overlooked it) that CEXINT must be compiled
in a way that upgrades all floats to double (plus accompanying changes to
i1mach/d1mach); (2) *generally* there is no guarantee that such an
"upgrade" would yield the desired precision. I acknowledge that for CEXINT
it may work fine, so this is primarily an aesthetic objection.

Please let me know once you are ready to let me test the new version of
configure.

Best,

Erik


On Wed, Jul 9, 2025 at 9:30 PM Ethan A Merritt <me...@uw...> wrote:

> On Wednesday, 9 July 2025 06:25:07 PDT Erik Luijten wrote:
> >
> > - That being said, I think it is not ideal that this configuration option
> > then uses a version of cexint that must be modified by the user. Instead,
> > the version of amos_airy.c that I sent yesterday uses an unmodified
> ZEXINT
> > as distributed in Netlib, minimizing confusion (and effort) for anyone
> who
> > wishes to incorporate it when they compile gnuplot. You clearly
> understand
> > the potential issues of upgrading a single-precision function to double
> > precision, but not everyone does and it also would require the user to
> > address a matter that was resolved by the original author from the
> outset.
>
> I am not following your thought there.  What matter is that?
>
> The biggest change/cleanup/upgrade/whatever is that the original code
> was written in an era when hardware floating support varied widely.
> The r1mach/d1mach per-installation customization had to deal with
> all sorts of setups, whereas now hardware support for IEEE 754 floating
> point is nearly universal.
>
> As described in the 1990 paper, the separate double-precision routine was
> needed because at that time Fortran did not support double precision
> complex
> as an intrinsic type. Since then (Fortran90? Fortran95?μ) this limitation
> went away, and so long as the algorithm itself provides sufficient
> precision
> the use of single vs double precision can be made a compile-time option.
>
> I do not recall having to change anything in the code to CEXINT itself.
> I only replaced the separate machine-dependent routines in favor of
> letting the compiler pick up the relevant constants from the system
> environment it was compiled on, and the compiler flags used to build it.
>
> > - By the way, you mention that you found an older version of CEXINT, but
> > the text you quote ("REVISION DATE  870515", etc.) is identical in the
> ACM
> > version https://www.netlib.org/toms-2014-06-10/683 ; there are just
> other
> > subroutines preceding it in the same file. In fact, I do not think that
> the
> > copyright situation favors CEXINT; the two functions were created at the
> > same time under the same circumstances (ZEXINT also carries the 1987
> date).
>
> Sure.  Both routines were written at the same time.  When the source code
> was placed in the TOMS archive someone added the comment lines at the top
> citing the 1990 paper.  My only point was that copies of the source code
> existed
> that predated the TOMS publication thus avoided any implied claim of
> license
> requirements imposed by the journal.
>
> > - Regarding concrete compilation: I compile ZEXINT and the other
> functions
> > it uses into a separate library (unlike you, I use i1mach and d1mach, but
> > rely on those being provided in libopenspecfun). I found that if I
> specify
> > this library in LIBAMOS_LDFLAGS, configure will detect it. Practically
> > speaking, I make this a static library so that users of the macOS binary
> do
> > not need to worry about it (I distribute gnuplot as a single static
> > executable).
> >
> > Depending on your view, the only question is then whether we switch from
> > CEXINT to ZEXINT (which would also require a small change in
> "configure").
>
> I wouldn't "switch".  I would have configure search for both and use
> whichever
> it found first.  I don't care much which one it finds first, unless as you
> say there
> is the possibility of conflicting symbols in another library.  If I
> understand your
> plan correctly, that would not be a problem for either of us.
>
> The autoconf scripts are not my strong point (to say the least), but I'll
> see
> what I can come up with.
>
> > Apologies for reviving this old topic!
>
> No problem - a trip down memory lane.
>
> By the way, the Julia language project uses a reimplemention in c99 for
> the Amos library functions including expint().   I did not pursue using it
> because unlike openspecfun it would not be available to users as a standard
> linux distribution package.
> But if you're already building static libraries yourself, and not under
> linux,
> that might be of interest to you as an alternative.
>
>   cheers,
>         Ethan
>
> >
> > Erik
> >
> > On Tue, Jul 8, 2025 at 11:52 PM Ethan A Merritt <me...@uw...> wrote:
> >
> > > On Tuesday, 8 July 2025 18:55:03 PDT Erik Luijten wrote:
> > > > Hi,
> > > >
> > > > I found the code on
> https://urldefense.com/v3/__https://dl.acm.org/doi/abs/10.1145/78928.78934__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUEM2Nmkq6$
> ; the
> > > > supplementary material contains all the subroutines concatenated
> into one
> > > > file.
> > > > It is also available on
> https://urldefense.com/v3/__https://www.netlib.org/toms-2014-06-10/__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUENvigquW$
> > > (scroll to
> > > > algorithm 683).
> > > > The fact that it is on netlib tells me it is likely free to use.
> > >
> > > At the top of that page is a notice:
> > >
> > >     Use of ACM Algorithms is subject to the ACM Software Copyright and
> > >     License Agreement
> > >
> > > > However, the ACM TOMS license agreement is here:
> > > >
> https://urldefense.com/v3/__https://www.acm.org/publications/policies/software-copyright-notice__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUEHrkADU9$
> .
> > > > I am not sure if this conflicts with Gnuplot's license?
> > >
> > > The issue is not that it conflicts with gnuplot's license.
> > > The issue is that Debian, for example, was concerned that inclusion
> > > with gnuplot would make the whole package non-free.
> > >
> > > Thanks for the link to the ACM site.  They have very much changed
> > > their policy since I first looked into this.  And it seems that for
> > > software
> > > published since 2013 the ACM does not claim any rights.  That's good.
> > > Unfortunately it doesn't help.  For older software (the Amos routines
> > > are from the 1980s) they state that the terms of the
> > > earlier ACM license still apply, which restricts commercial use.
> > > If that were true it would make the whole set of Amos routines
> > > [as obtained from them] non-free, but see below.
> > >
> > > > Whether a more permissive license applies to cexint_.f  than to
> > > > zexint_.f is also unclear to me.
> > >
> > > It is my belief that ACM was simplly wrong in ever claiming the right
> > > to license or restrict any of these routines.  The were produced at
> > > Sandia National Laboratories under US government contract, and as
> > > I understand it (I am not a lawyer and all that) that makes them
> > > "Works Created by the United States Government" and as such not
> > > subject to copyright.
> > >
> > > But that's only me.  I don't have any sway over what Debian or anyone
> > > else considers to be "non-free".  Based on past conversations my
> > > understanding is that Debian considers the TOMS license to poison
> > > any project that includes it as non-free.  Those conversations were
> > > many years ago, so I suppose the issue could be revisited.
> > >
> > > > An awkward point, to the best of my understanding, is that an
> unmodified
> > > > version of cexint will not work with the Gnuplot source code, as it
> > > expects
> > > > single-precision arguments. Yet, changing cexint is not
> > > > completely straightforward: Comparing cexint and zexint (and the
> > > > accompanying routines cexent and zexent), I noticed the more subtle
> point
> > > > that cexint uses r1mach.f and zexint uses d1mach.f; moreover, they
> use
> > > > different constants from i1mach to establish precision (elements
> 12,13
> > > vs.
> > > > 15,16). Also, in zexint all constants are replaced by their
> > > > double-precision counterparts.
> > >
> > > This gets complicated.
> > >
> > > I have downloaded and had a quick look at the code available through
> the
> > > netlib site.  It is apparently newer than the code I have here. It
> cites
> > > the 1990
> > > TOMS paper at the top and as you say it concatenates many smaller
> routines,
> > > whereas the code I have claims to be from 1987 and starts
> > > C***BEGIN PROLOGUE  CEXINT
> > > C***DATE WRITTEN   870515   (YYMMDD)
> > > C***REVISION DATE  870515   (YYMMDD)
> > > C***CATEGORY NO.  B5E
> > > C***KEYWORDS  EXPONENTIAL INTEGRALS, SINE INTEGRAL, COSINE INTEGRAL
> > > C***AUTHOR  AMOS, DONALD E., SANDIA NATIONAL LABORATORIES
> > > C***PURPOSE  TO COMPUTE EXPONENTIAL INTEGRALS OF A COMPLEX ARGUMENT
> > >
> > > There are some code differences elsewhere, but I did not look in detail
> > > and don't have anything useful to say about them right now.
> > >
> > > Beyond that, to the extent that there are precision-sensitive
> constants in
> > > the
> > > code the numerical values seem identical, but they are declared, for
> > > example
> > > -5.77215664901532861E-01   vs   -5.77215664901532861D-01
> > > As I recall in 1987 that difference was necessary to distinguish
> single-
> > > and
> > > double- precision constants, but I don't think current Fortran pays any
> > > attention to it when using the constant in a double-precision context.
> > > I compile with
> > >      gfortran -fdefault-real-8 -fdefault-double-8
> > > I.e. everything should be double precision by default.
> > > So although you describe cexint() as a single-precision routine,
> > > that isn't true when I build it here.  Of course it's always possible
> > > I missed something in the code that loses precision, but given that
> > > it iterates until convergence I think that would not even matter.
> > >
> > > > For all these reasons, I would argue that if copyright restrictions
> are
> > > the
> > > > same for cexint and zexint, it would be better to use the latter - a
> user
> > > > could then directly download this subroutine and use it without
> > > > modifications.
> > >
> > > You may have a point about an end-user who builds from source.
> > > But you've been building and making available binaries for MacOS,
> right?
> > > I think that moves any legal question to "distribution" rather than
> "use".
> > > You may well agree with me that the code you want to include is not
> subject
> > > to the TOMS license even though TOMS seems to say it is.  But you
> should
> > > at least be aware that the question has been raised in the past.
> > >
> > > > Lastly, a tricky point that is easily overlooked is that i1mach,
> r1mach,
> > > > d1mach need to be configured for x86. Moreover, since openspecfun is
> > > built
> > > > as a library, it already contains i1mach and d1mach, opening the
> door for
> > > > conflicting functions if one gathers cexint/zexint into a separate
> > > > library...
> > >
> > > As to r1mach.f and d1mach.f,  I am not using either of them here.
> > > I replaced these with a C-language data block (attached) that I use
> > > to build libamos from the Sandia sources for all the Amos routines.
> > > I link against that rather than against libopenspecfun.
> > >
> > > I sent my collection of libamos source to Tatsuro Matsuoka in case
> > > he wanted to use them for building Windows packages.
> > > I even  considered adding source for all the libamos routines as a
> > > separate subdirectory in the gnuplot distribution package.
> > > But then I found that many/most linux distros  already provide
> > > libopenspecfun so I decided against complicating the gnuplot packaging
> > > by having it supply a whole separate library for the sake of a single
> > > routine.
> > >
> > > > I am attaching my modified version of amos_airy.c, in case you are
> swayed
> > > > by my argument...
> > >
> > > Are you thinking that the user would build zexint.o as a separate
> object
> > > module and then add it to the Makefile somehow?
> > >
> > > I would prefer to make it a configuration option. Not sure how best
> > > to capture a single extra source file whose provenance and dependencies
> > > we don't control.  I think it would be easier to require that it has
> > > already
> > > been wrapped into a shared library.
> > > Or hey, another alternative is to provide a template for making it
> > > a plugin.  The distribution package currently has a demo plugin for
> > > uigamma.  Providing a plugin for a Fortran routine might be of
> > > interest even apart from filling a gap in special function coverage.
> > >
> > >       Ethan
> > >
> > >
> > > >
> > > >
> > > >
> > > > On Tue, Jul 8, 2025 at 7:26 PM Ethan A Merritt <me...@uw...>
> wrote:
> > > >
> > > > > On Tuesday, 8 July 2025 14:21:01 PDT Erik Luijten wrote:
> > > > > > Hi Ethan,
> > > > > >
> > > > > > In amos_airy.c, you write:
> > > > > >
> > > > > >  * The cexint_() routine is also from the AMOS collection, but
> is not
> > > > > part
> > > > > >  * of the Bessel function subset and not included in
> libopenspecfun.
> > > > > >  * I could not find source for a version of the source that
> splits
> > > the
> > > > > >  * real and imaginary parts of the arguments as with the zxxxx.f
> > > Bessel
> > > > > >  * routines; this one accepts and returns a CMPLX argument rather
> > > than
> > > > > > separate
> > > > > >  * real and imaginary parts.
> > > > > >  *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN
> > > Subroutine
> > > > > >  *             for Exponential Integrals of a Complex Argument
> > > > > >  *             ACM Trans. Math. Software 16:178-182 (1990)
> > > > > >
> > > > > > This confuses me for two reasons:
> > > > > > - You invoke CEXINT as a double precision function, even though
> this
> > > > > > Fortran function is single precision.
> > > > >
> > > > > > - The algorithm 683 you quote DOES provide a separate double
> > > precision
> > > > > > function, ZEXINT. Moreover, that function does exactly what you
> were
> > > > > > looking for, namely taking and returning separate real and
> imaginary
> > > > > parts.
> > > > >
> > > > > There is some history behind this due to IMHO over-zealous, or at
> least
> > > > > overly pessimistic, concern about license contamination with
> non-free
> > > code.
> > > > > I cited a publication in ACM/TMS that describes the implementation.
> > > > > However, people have assserted that code obtained through the ACM
> > > > > journal is non-free because the journal claims copyright.
> > > > > I believe this to be factually incorrect; the published article
> may be
> > > > > subject
> > > > > to copyright but not the code it describes. In any case, rather
> than
> > > pursue
> > > > > the argument I instead used copies of the code obtained from US
> > > national
> > > > > lab repositories.  I found source there for cexint.f but not for
> > > zexint.f,
> > > > > so that is what I use myself to build libamos and what I invoked
> from
> > > the
> > > > > gnuplot code.
> > > > >
> > > > > Even so that was apparently not sufficient by itself to convince
> > > hard-core
> > > > > "free licenses only" gatekeepers.
> > > > > There is an explicit statement of the [non]copyright status of the
> code
> > > > > in the cited 1985 Sandia National Laboratory report, but that
> report
> > > > > predated development of the expint routines (1990?) and I did not
> find
> > > a
> > > > > separate Sandia report that mentions them specifically.
> > > > > That is probably why neither routine is included in libopenspec,
> > > > > and why inclusion in gnuplot is a configuration option.
> > > > >
> > > > > > I changed f_amos_cexint to use ZEXINT (just for my own
> edification)
> > > and
> > > > > it
> > > > > > works properly. However, before submitting it, I wonder what am I
> > > > > missing?
> > > > >
> > > > > Where did you obtain a copy of the source?
> > > > > Can you document the relevant claim or non-claim of copyright or
> > > > > licensing?
> > > > >
> > > > > And, out of curiosity, is there anything in the zexint.f code that
> > > would
> > > > > differentiate it from a single-precision version other than
> declaration
> > > > > of the variables as Fortran DOUBLE PRECISION?
> > > > >
> > > > >         Ethan
> > > > >
> > > > >
> > > > > >
> > > > > > Thank you,
> > > > > >
> > > > > > Erik
>
>
>
>

Re: Complex Exponential Integral

[Ethan A M. <me...@uw...>]

On Wednesday, 9 July 2025 06:25:07 PDT Erik Luijten wrote:
> 
> - That being said, I think it is not ideal that this configuration option
> then uses a version of cexint that must be modified by the user. Instead,
> the version of amos_airy.c that I sent yesterday uses an unmodified ZEXINT
> as distributed in Netlib, minimizing confusion (and effort) for anyone who
> wishes to incorporate it when they compile gnuplot. You clearly understand
> the potential issues of upgrading a single-precision function to double
> precision, but not everyone does and it also would require the user to
> address a matter that was resolved by the original author from the outset.

I am not following your thought there.  What matter is that?

The biggest change/cleanup/upgrade/whatever is that the original code
was written in an era when hardware floating support varied widely.
The r1mach/d1mach per-installation customization had to deal with
all sorts of setups, whereas now hardware support for IEEE 754 floating
point is nearly universal.  

As described in the 1990 paper, the separate double-precision routine was
needed because at that time Fortran did not support double precision complex
as an intrinsic type. Since then (Fortran90? Fortran95?μ) this limitation
went away, and so long as the algorithm itself provides sufficient precision
the use of single vs double precision can be made a compile-time option.

I do not recall having to change anything in the code to CEXINT itself.
I only replaced the separate machine-dependent routines in favor of
letting the compiler pick up the relevant constants from the system
environment it was compiled on, and the compiler flags used to build it.

> - By the way, you mention that you found an older version of CEXINT, but
> the text you quote ("REVISION DATE  870515", etc.) is identical in the ACM
> version https://www.netlib.org/toms-2014-06-10/683 ; there are just other
> subroutines preceding it in the same file. In fact, I do not think that the
> copyright situation favors CEXINT; the two functions were created at the
> same time under the same circumstances (ZEXINT also carries the 1987 date).

Sure.  Both routines were written at the same time.  When the source code
was placed in the TOMS archive someone added the comment lines at the top
citing the 1990 paper.  My only point was that copies of the source code existed
that predated the TOMS publication thus avoided any implied claim of license
requirements imposed by the journal.   

> - Regarding concrete compilation: I compile ZEXINT and the other functions
> it uses into a separate library (unlike you, I use i1mach and d1mach, but
> rely on those being provided in libopenspecfun). I found that if I specify
> this library in LIBAMOS_LDFLAGS, configure will detect it. Practically
> speaking, I make this a static library so that users of the macOS binary do
> not need to worry about it (I distribute gnuplot as a single static
> executable).
> 
> Depending on your view, the only question is then whether we switch from
> CEXINT to ZEXINT (which would also require a small change in "configure").

I wouldn't "switch".  I would have configure search for both and use whichever
it found first.  I don't care much which one it finds first, unless as you say there
is the possibility of conflicting symbols in another library.  If I understand your
plan correctly, that would not be a problem for either of us. 

The autoconf scripts are not my strong point (to say the least), but I'll see
what I can come up with.

> Apologies for reviving this old topic!

No problem - a trip down memory lane.

By the way, the Julia language project uses a reimplemention in c99 for
the Amos library functions including expint().   I did not pursue using it
because unlike openspecfun it would not be available to users as a standard
linux distribution package.
But if you're already building static libraries yourself, and not under linux,
that might be of interest to you as an alternative.

  cheers,
	Ethan

> 
> Erik
> 
> On Tue, Jul 8, 2025 at 11:52 PM Ethan A Merritt <me...@uw...> wrote:
> 
> > On Tuesday, 8 July 2025 18:55:03 PDT Erik Luijten wrote:
> > > Hi,
> > >
> > > I found the code on https://urldefense.com/v3/__https://dl.acm.org/doi/abs/10.1145/78928.78934__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUEM2Nmkq6$  ; the
> > > supplementary material contains all the subroutines concatenated into one
> > > file.
> > > It is also available on https://urldefense.com/v3/__https://www.netlib.org/toms-2014-06-10/__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUENvigquW$ 
> > (scroll to
> > > algorithm 683).
> > > The fact that it is on netlib tells me it is likely free to use.
> >
> > At the top of that page is a notice:
> >
> >     Use of ACM Algorithms is subject to the ACM Software Copyright and
> >     License Agreement
> >
> > > However, the ACM TOMS license agreement is here:
> > > https://urldefense.com/v3/__https://www.acm.org/publications/policies/software-copyright-notice__;!!K-Hz7m0Vt54!jVJeG1oeF8DBF4-meLyPbDTC2nBP2lu0ChoIkfgKeOZGsqFA4LqPWSqtJ5ZK0ZYv1jwibOIAGDbUEHrkADU9$ .
> > > I am not sure if this conflicts with Gnuplot's license?
> >
> > The issue is not that it conflicts with gnuplot's license.
> > The issue is that Debian, for example, was concerned that inclusion
> > with gnuplot would make the whole package non-free.
> >
> > Thanks for the link to the ACM site.  They have very much changed
> > their policy since I first looked into this.  And it seems that for
> > software
> > published since 2013 the ACM does not claim any rights.  That's good.
> > Unfortunately it doesn't help.  For older software (the Amos routines
> > are from the 1980s) they state that the terms of the
> > earlier ACM license still apply, which restricts commercial use.
> > If that were true it would make the whole set of Amos routines
> > [as obtained from them] non-free, but see below.
> >
> > > Whether a more permissive license applies to cexint_.f  than to
> > > zexint_.f is also unclear to me.
> >
> > It is my belief that ACM was simplly wrong in ever claiming the right
> > to license or restrict any of these routines.  The were produced at
> > Sandia National Laboratories under US government contract, and as
> > I understand it (I am not a lawyer and all that) that makes them
> > "Works Created by the United States Government" and as such not
> > subject to copyright.
> >
> > But that's only me.  I don't have any sway over what Debian or anyone
> > else considers to be "non-free".  Based on past conversations my
> > understanding is that Debian considers the TOMS license to poison
> > any project that includes it as non-free.  Those conversations were
> > many years ago, so I suppose the issue could be revisited.
> >
> > > An awkward point, to the best of my understanding, is that an unmodified
> > > version of cexint will not work with the Gnuplot source code, as it
> > expects
> > > single-precision arguments. Yet, changing cexint is not
> > > completely straightforward: Comparing cexint and zexint (and the
> > > accompanying routines cexent and zexent), I noticed the more subtle point
> > > that cexint uses r1mach.f and zexint uses d1mach.f; moreover, they use
> > > different constants from i1mach to establish precision (elements 12,13
> > vs.
> > > 15,16). Also, in zexint all constants are replaced by their
> > > double-precision counterparts.
> >
> > This gets complicated.
> >
> > I have downloaded and had a quick look at the code available through the
> > netlib site.  It is apparently newer than the code I have here. It cites
> > the 1990
> > TOMS paper at the top and as you say it concatenates many smaller routines,
> > whereas the code I have claims to be from 1987 and starts
> > C***BEGIN PROLOGUE  CEXINT
> > C***DATE WRITTEN   870515   (YYMMDD)
> > C***REVISION DATE  870515   (YYMMDD)
> > C***CATEGORY NO.  B5E
> > C***KEYWORDS  EXPONENTIAL INTEGRALS, SINE INTEGRAL, COSINE INTEGRAL
> > C***AUTHOR  AMOS, DONALD E., SANDIA NATIONAL LABORATORIES
> > C***PURPOSE  TO COMPUTE EXPONENTIAL INTEGRALS OF A COMPLEX ARGUMENT
> >
> > There are some code differences elsewhere, but I did not look in detail
> > and don't have anything useful to say about them right now.
> >
> > Beyond that, to the extent that there are precision-sensitive constants in
> > the
> > code the numerical values seem identical, but they are declared, for
> > example
> > -5.77215664901532861E-01   vs   -5.77215664901532861D-01
> > As I recall in 1987 that difference was necessary to distinguish single-
> > and
> > double- precision constants, but I don't think current Fortran pays any
> > attention to it when using the constant in a double-precision context.
> > I compile with
> >      gfortran -fdefault-real-8 -fdefault-double-8
> > I.e. everything should be double precision by default.
> > So although you describe cexint() as a single-precision routine,
> > that isn't true when I build it here.  Of course it's always possible
> > I missed something in the code that loses precision, but given that
> > it iterates until convergence I think that would not even matter.
> >
> > > For all these reasons, I would argue that if copyright restrictions are
> > the
> > > same for cexint and zexint, it would be better to use the latter - a user
> > > could then directly download this subroutine and use it without
> > > modifications.
> >
> > You may have a point about an end-user who builds from source.
> > But you've been building and making available binaries for MacOS, right?
> > I think that moves any legal question to "distribution" rather than "use".
> > You may well agree with me that the code you want to include is not subject
> > to the TOMS license even though TOMS seems to say it is.  But you should
> > at least be aware that the question has been raised in the past.
> >
> > > Lastly, a tricky point that is easily overlooked is that i1mach, r1mach,
> > > d1mach need to be configured for x86. Moreover, since openspecfun is
> > built
> > > as a library, it already contains i1mach and d1mach, opening the door for
> > > conflicting functions if one gathers cexint/zexint into a separate
> > > library...
> >
> > As to r1mach.f and d1mach.f,  I am not using either of them here.
> > I replaced these with a C-language data block (attached) that I use
> > to build libamos from the Sandia sources for all the Amos routines.
> > I link against that rather than against libopenspecfun.
> >
> > I sent my collection of libamos source to Tatsuro Matsuoka in case
> > he wanted to use them for building Windows packages.
> > I even  considered adding source for all the libamos routines as a
> > separate subdirectory in the gnuplot distribution package.
> > But then I found that many/most linux distros  already provide
> > libopenspecfun so I decided against complicating the gnuplot packaging
> > by having it supply a whole separate library for the sake of a single
> > routine.
> >
> > > I am attaching my modified version of amos_airy.c, in case you are swayed
> > > by my argument...
> >
> > Are you thinking that the user would build zexint.o as a separate object
> > module and then add it to the Makefile somehow?
> >
> > I would prefer to make it a configuration option. Not sure how best
> > to capture a single extra source file whose provenance and dependencies
> > we don't control.  I think it would be easier to require that it has
> > already
> > been wrapped into a shared library.
> > Or hey, another alternative is to provide a template for making it
> > a plugin.  The distribution package currently has a demo plugin for
> > uigamma.  Providing a plugin for a Fortran routine might be of
> > interest even apart from filling a gap in special function coverage.
> >
> >       Ethan
> >
> >
> > >
> > >
> > >
> > > On Tue, Jul 8, 2025 at 7:26 PM Ethan A Merritt <me...@uw...> wrote:
> > >
> > > > On Tuesday, 8 July 2025 14:21:01 PDT Erik Luijten wrote:
> > > > > Hi Ethan,
> > > > >
> > > > > In amos_airy.c, you write:
> > > > >
> > > > >  * The cexint_() routine is also from the AMOS collection, but is not
> > > > part
> > > > >  * of the Bessel function subset and not included in libopenspecfun.
> > > > >  * I could not find source for a version of the source that splits
> > the
> > > > >  * real and imaginary parts of the arguments as with the zxxxx.f
> > Bessel
> > > > >  * routines; this one accepts and returns a CMPLX argument rather
> > than
> > > > > separate
> > > > >  * real and imaginary parts.
> > > > >  *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN
> > Subroutine
> > > > >  *             for Exponential Integrals of a Complex Argument
> > > > >  *             ACM Trans. Math. Software 16:178-182 (1990)
> > > > >
> > > > > This confuses me for two reasons:
> > > > > - You invoke CEXINT as a double precision function, even though this
> > > > > Fortran function is single precision.
> > > >
> > > > > - The algorithm 683 you quote DOES provide a separate double
> > precision
> > > > > function, ZEXINT. Moreover, that function does exactly what you were
> > > > > looking for, namely taking and returning separate real and imaginary
> > > > parts.
> > > >
> > > > There is some history behind this due to IMHO over-zealous, or at least
> > > > overly pessimistic, concern about license contamination with non-free
> > code.
> > > > I cited a publication in ACM/TMS that describes the implementation.
> > > > However, people have assserted that code obtained through the ACM
> > > > journal is non-free because the journal claims copyright.
> > > > I believe this to be factually incorrect; the published article may be
> > > > subject
> > > > to copyright but not the code it describes. In any case, rather than
> > pursue
> > > > the argument I instead used copies of the code obtained from US
> > national
> > > > lab repositories.  I found source there for cexint.f but not for
> > zexint.f,
> > > > so that is what I use myself to build libamos and what I invoked from
> > the
> > > > gnuplot code.
> > > >
> > > > Even so that was apparently not sufficient by itself to convince
> > hard-core
> > > > "free licenses only" gatekeepers.
> > > > There is an explicit statement of the [non]copyright status of the code
> > > > in the cited 1985 Sandia National Laboratory report, but that report
> > > > predated development of the expint routines (1990?) and I did not find
> > a
> > > > separate Sandia report that mentions them specifically.
> > > > That is probably why neither routine is included in libopenspec,
> > > > and why inclusion in gnuplot is a configuration option.
> > > >
> > > > > I changed f_amos_cexint to use ZEXINT (just for my own edification)
> > and
> > > > it
> > > > > works properly. However, before submitting it, I wonder what am I
> > > > missing?
> > > >
> > > > Where did you obtain a copy of the source?
> > > > Can you document the relevant claim or non-claim of copyright or
> > > > licensing?
> > > >
> > > > And, out of curiosity, is there anything in the zexint.f code that
> > would
> > > > differentiate it from a single-precision version other than declaration
> > > > of the variables as Fortran DOUBLE PRECISION?
> > > >
> > > >         Ethan
> > > >
> > > >
> > > > >
> > > > > Thank you,
> > > > >
> > > > > Erik

Re: Complex Exponential Integral

[Erik L. <eri...@gm...>]

Dear Ethan,

Thank you for the detailed response. To keep things organized, let me
respond point by point:

- I share your view that cexint and zexint are products that are not
subject to copyright. To get true clarity about this, I contacted ACM. We
will see if/when I hear back. At this point, I have no hesitation to
distribute compiled versions of Gnuplot that contain this code (even the
ACM license permits this). However, I also respect that distributors (like
Debian) take a stricter view, so the gnuplot source code should be
distributed without cexint and only use it as a configurable option.

- That being said, I think it is not ideal that this configuration option
then uses a version of cexint that must be modified by the user. Instead,
the version of amos_airy.c that I sent yesterday uses an unmodified ZEXINT
as distributed in Netlib, minimizing confusion (and effort) for anyone who
wishes to incorporate it when they compile gnuplot. You clearly understand
the potential issues of upgrading a single-precision function to double
precision, but not everyone does and it also would require the user to
address a matter that was resolved by the original author from the outset.

- By the way, you mention that you found an older version of CEXINT, but
the text you quote ("REVISION DATE  870515", etc.) is identical in the ACM
version https://www.netlib.org/toms-2014-06-10/683; there are just other
subroutines preceding it in the same file. In fact, I do not think that the
copyright situation favors CEXINT; the two functions were created at the
same time under the same circumstances (ZEXINT also carries the 1987 date).

- Regarding concrete compilation: I compile ZEXINT and the other functions
it uses into a separate library (unlike you, I use i1mach and d1mach, but
rely on those being provided in libopenspecfun). I found that if I specify
this library in LIBAMOS_LDFLAGS, configure will detect it. Practically
speaking, I make this a static library so that users of the macOS binary do
not need to worry about it (I distribute gnuplot as a single static
executable).

Depending on your view, the only question is then whether we switch from
CEXINT to ZEXINT (which would also require a small change in "configure").

Apologies for reviving this old topic!

Erik

On Tue, Jul 8, 2025 at 11:52 PM Ethan A Merritt <me...@uw...> wrote:

> On Tuesday, 8 July 2025 18:55:03 PDT Erik Luijten wrote:
> > Hi,
> >
> > I found the code on https://dl.acm.org/doi/abs/10.1145/78928.78934 ; the
> > supplementary material contains all the subroutines concatenated into one
> > file.
> > It is also available on https://www.netlib.org/toms-2014-06-10/
> (scroll to
> > algorithm 683).
> > The fact that it is on netlib tells me it is likely free to use.
>
> At the top of that page is a notice:
>
>     Use of ACM Algorithms is subject to the ACM Software Copyright and
>     License Agreement
>
> > However, the ACM TOMS license agreement is here:
> > https://www.acm.org/publications/policies/software-copyright-notice.
> > I am not sure if this conflicts with Gnuplot's license?
>
> The issue is not that it conflicts with gnuplot's license.
> The issue is that Debian, for example, was concerned that inclusion
> with gnuplot would make the whole package non-free.
>
> Thanks for the link to the ACM site.  They have very much changed
> their policy since I first looked into this.  And it seems that for
> software
> published since 2013 the ACM does not claim any rights.  That's good.
> Unfortunately it doesn't help.  For older software (the Amos routines
> are from the 1980s) they state that the terms of the
> earlier ACM license still apply, which restricts commercial use.
> If that were true it would make the whole set of Amos routines
> [as obtained from them] non-free, but see below.
>
> > Whether a more permissive license applies to cexint_.f  than to
> > zexint_.f is also unclear to me.
>
> It is my belief that ACM was simplly wrong in ever claiming the right
> to license or restrict any of these routines.  The were produced at
> Sandia National Laboratories under US government contract, and as
> I understand it (I am not a lawyer and all that) that makes them
> "Works Created by the United States Government" and as such not
> subject to copyright.
>
> But that's only me.  I don't have any sway over what Debian or anyone
> else considers to be "non-free".  Based on past conversations my
> understanding is that Debian considers the TOMS license to poison
> any project that includes it as non-free.  Those conversations were
> many years ago, so I suppose the issue could be revisited.
>
> > An awkward point, to the best of my understanding, is that an unmodified
> > version of cexint will not work with the Gnuplot source code, as it
> expects
> > single-precision arguments. Yet, changing cexint is not
> > completely straightforward: Comparing cexint and zexint (and the
> > accompanying routines cexent and zexent), I noticed the more subtle point
> > that cexint uses r1mach.f and zexint uses d1mach.f; moreover, they use
> > different constants from i1mach to establish precision (elements 12,13
> vs.
> > 15,16). Also, in zexint all constants are replaced by their
> > double-precision counterparts.
>
> This gets complicated.
>
> I have downloaded and had a quick look at the code available through the
> netlib site.  It is apparently newer than the code I have here. It cites
> the 1990
> TOMS paper at the top and as you say it concatenates many smaller routines,
> whereas the code I have claims to be from 1987 and starts
> C***BEGIN PROLOGUE  CEXINT
> C***DATE WRITTEN   870515   (YYMMDD)
> C***REVISION DATE  870515   (YYMMDD)
> C***CATEGORY NO.  B5E
> C***KEYWORDS  EXPONENTIAL INTEGRALS, SINE INTEGRAL, COSINE INTEGRAL
> C***AUTHOR  AMOS, DONALD E., SANDIA NATIONAL LABORATORIES
> C***PURPOSE  TO COMPUTE EXPONENTIAL INTEGRALS OF A COMPLEX ARGUMENT
>
> There are some code differences elsewhere, but I did not look in detail
> and don't have anything useful to say about them right now.
>
> Beyond that, to the extent that there are precision-sensitive constants in
> the
> code the numerical values seem identical, but they are declared, for
> example
> -5.77215664901532861E-01   vs   -5.77215664901532861D-01
> As I recall in 1987 that difference was necessary to distinguish single-
> and
> double- precision constants, but I don't think current Fortran pays any
> attention to it when using the constant in a double-precision context.
> I compile with
>      gfortran -fdefault-real-8 -fdefault-double-8
> I.e. everything should be double precision by default.
> So although you describe cexint() as a single-precision routine,
> that isn't true when I build it here.  Of course it's always possible
> I missed something in the code that loses precision, but given that
> it iterates until convergence I think that would not even matter.
>
> > For all these reasons, I would argue that if copyright restrictions are
> the
> > same for cexint and zexint, it would be better to use the latter - a user
> > could then directly download this subroutine and use it without
> > modifications.
>
> You may have a point about an end-user who builds from source.
> But you've been building and making available binaries for MacOS, right?
> I think that moves any legal question to "distribution" rather than "use".
> You may well agree with me that the code you want to include is not subject
> to the TOMS license even though TOMS seems to say it is.  But you should
> at least be aware that the question has been raised in the past.
>
> > Lastly, a tricky point that is easily overlooked is that i1mach, r1mach,
> > d1mach need to be configured for x86. Moreover, since openspecfun is
> built
> > as a library, it already contains i1mach and d1mach, opening the door for
> > conflicting functions if one gathers cexint/zexint into a separate
> > library...
>
> As to r1mach.f and d1mach.f,  I am not using either of them here.
> I replaced these with a C-language data block (attached) that I use
> to build libamos from the Sandia sources for all the Amos routines.
> I link against that rather than against libopenspecfun.
>
> I sent my collection of libamos source to Tatsuro Matsuoka in case
> he wanted to use them for building Windows packages.
> I even  considered adding source for all the libamos routines as a
> separate subdirectory in the gnuplot distribution package.
> But then I found that many/most linux distros  already provide
> libopenspecfun so I decided against complicating the gnuplot packaging
> by having it supply a whole separate library for the sake of a single
> routine.
>
> > I am attaching my modified version of amos_airy.c, in case you are swayed
> > by my argument...
>
> Are you thinking that the user would build zexint.o as a separate object
> module and then add it to the Makefile somehow?
>
> I would prefer to make it a configuration option. Not sure how best
> to capture a single extra source file whose provenance and dependencies
> we don't control.  I think it would be easier to require that it has
> already
> been wrapped into a shared library.
> Or hey, another alternative is to provide a template for making it
> a plugin.  The distribution package currently has a demo plugin for
> uigamma.  Providing a plugin for a Fortran routine might be of
> interest even apart from filling a gap in special function coverage.
>
>       Ethan
>
>
> >
> >
> >
> > On Tue, Jul 8, 2025 at 7:26 PM Ethan A Merritt <me...@uw...> wrote:
> >
> > > On Tuesday, 8 July 2025 14:21:01 PDT Erik Luijten wrote:
> > > > Hi Ethan,
> > > >
> > > > In amos_airy.c, you write:
> > > >
> > > >  * The cexint_() routine is also from the AMOS collection, but is not
> > > part
> > > >  * of the Bessel function subset and not included in libopenspecfun.
> > > >  * I could not find source for a version of the source that splits
> the
> > > >  * real and imaginary parts of the arguments as with the zxxxx.f
> Bessel
> > > >  * routines; this one accepts and returns a CMPLX argument rather
> than
> > > > separate
> > > >  * real and imaginary parts.
> > > >  *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN
> Subroutine
> > > >  *             for Exponential Integrals of a Complex Argument
> > > >  *             ACM Trans. Math. Software 16:178-182 (1990)
> > > >
> > > > This confuses me for two reasons:
> > > > - You invoke CEXINT as a double precision function, even though this
> > > > Fortran function is single precision.
> > >
> > > > - The algorithm 683 you quote DOES provide a separate double
> precision
> > > > function, ZEXINT. Moreover, that function does exactly what you were
> > > > looking for, namely taking and returning separate real and imaginary
> > > parts.
> > >
> > > There is some history behind this due to IMHO over-zealous, or at least
> > > overly pessimistic, concern about license contamination with non-free
> code.
> > > I cited a publication in ACM/TMS that describes the implementation.
> > > However, people have assserted that code obtained through the ACM
> > > journal is non-free because the journal claims copyright.
> > > I believe this to be factually incorrect; the published article may be
> > > subject
> > > to copyright but not the code it describes. In any case, rather than
> pursue
> > > the argument I instead used copies of the code obtained from US
> national
> > > lab repositories.  I found source there for cexint.f but not for
> zexint.f,
> > > so that is what I use myself to build libamos and what I invoked from
> the
> > > gnuplot code.
> > >
> > > Even so that was apparently not sufficient by itself to convince
> hard-core
> > > "free licenses only" gatekeepers.
> > > There is an explicit statement of the [non]copyright status of the code
> > > in the cited 1985 Sandia National Laboratory report, but that report
> > > predated development of the expint routines (1990?) and I did not find
> a
> > > separate Sandia report that mentions them specifically.
> > > That is probably why neither routine is included in libopenspec,
> > > and why inclusion in gnuplot is a configuration option.
> > >
> > > > I changed f_amos_cexint to use ZEXINT (just for my own edification)
> and
> > > it
> > > > works properly. However, before submitting it, I wonder what am I
> > > missing?
> > >
> > > Where did you obtain a copy of the source?
> > > Can you document the relevant claim or non-claim of copyright or
> > > licensing?
> > >
> > > And, out of curiosity, is there anything in the zexint.f code that
> would
> > > differentiate it from a single-precision version other than declaration
> > > of the variables as Fortran DOUBLE PRECISION?
> > >
> > >         Ethan
> > >
> > >
> > > >
> > > > Thank you,
> > > >
> > > > Erik
> > > >
> > >
> > >
> > >
> > >
> >
>
>

Re: Complex Exponential Integral

[Ethan A M. <me...@uw...>]

On Tuesday, 8 July 2025 18:55:03 PDT Erik Luijten wrote:
> Hi,
> 
> I found the code on https://dl.acm.org/doi/abs/10.1145/78928.78934 ; the
> supplementary material contains all the subroutines concatenated into one
> file.
> It is also available on https://www.netlib.org/toms-2014-06-10/  (scroll to
> algorithm 683).
> The fact that it is on netlib tells me it is likely free to use.

At the top of that page is a notice:

    Use of ACM Algorithms is subject to the ACM Software Copyright and
    License Agreement

> However, the ACM TOMS license agreement is here:
> https://www.acm.org/publications/policies/software-copyright-notice.
> I am not sure if this conflicts with Gnuplot's license? 

The issue is not that it conflicts with gnuplot's license.
The issue is that Debian, for example, was concerned that inclusion
with gnuplot would make the whole package non-free.

Thanks for the link to the ACM site.  They have very much changed
their policy since I first looked into this.  And it seems that for software
published since 2013 the ACM does not claim any rights.  That's good.
Unfortunately it doesn't help.  For older software (the Amos routines
are from the 1980s) they state that the terms of the
earlier ACM license still apply, which restricts commercial use.
If that were true it would make the whole set of Amos routines
[as obtained from them] non-free, but see below.

> Whether a more permissive license applies to cexint_.f  than to
> zexint_.f is also unclear to me.

It is my belief that ACM was simplly wrong in ever claiming the right
to license or restrict any of these routines.  The were produced at
Sandia National Laboratories under US government contract, and as
I understand it (I am not a lawyer and all that) that makes them
"Works Created by the United States Government" and as such not
subject to copyright.   

But that's only me.  I don't have any sway over what Debian or anyone
else considers to be "non-free".  Based on past conversations my
understanding is that Debian considers the TOMS license to poison
any project that includes it as non-free.  Those conversations were
many years ago, so I suppose the issue could be revisited.

> An awkward point, to the best of my understanding, is that an unmodified
> version of cexint will not work with the Gnuplot source code, as it expects
> single-precision arguments. Yet, changing cexint is not
> completely straightforward: Comparing cexint and zexint (and the
> accompanying routines cexent and zexent), I noticed the more subtle point
> that cexint uses r1mach.f and zexint uses d1mach.f; moreover, they use
> different constants from i1mach to establish precision (elements 12,13 vs.
> 15,16). Also, in zexint all constants are replaced by their
> double-precision counterparts.

This gets complicated.

I have downloaded and had a quick look at the code available through the
netlib site.  It is apparently newer than the code I have here. It cites the 1990
TOMS paper at the top and as you say it concatenates many smaller routines,
whereas the code I have claims to be from 1987 and starts
C***BEGIN PROLOGUE  CEXINT
C***DATE WRITTEN   870515   (YYMMDD)
C***REVISION DATE  870515   (YYMMDD)
C***CATEGORY NO.  B5E
C***KEYWORDS  EXPONENTIAL INTEGRALS, SINE INTEGRAL, COSINE INTEGRAL
C***AUTHOR  AMOS, DONALD E., SANDIA NATIONAL LABORATORIES
C***PURPOSE  TO COMPUTE EXPONENTIAL INTEGRALS OF A COMPLEX ARGUMENT

There are some code differences elsewhere, but I did not look in detail
and don't have anything useful to say about them right now.

Beyond that, to the extent that there are precision-sensitive constants in the
code the numerical values seem identical, but they are declared, for example 
-5.77215664901532861E-01   vs   -5.77215664901532861D-01
As I recall in 1987 that difference was necessary to distinguish single- and
double- precision constants, but I don't think current Fortran pays any
attention to it when using the constant in a double-precision context.
I compile with 
     gfortran -fdefault-real-8 -fdefault-double-8
I.e. everything should be double precision by default.
So although you describe cexint() as a single-precision routine,
that isn't true when I build it here.  Of course it's always possible
I missed something in the code that loses precision, but given that
it iterates until convergence I think that would not even matter.

> For all these reasons, I would argue that if copyright restrictions are the
> same for cexint and zexint, it would be better to use the latter - a user
> could then directly download this subroutine and use it without
> modifications.

You may have a point about an end-user who builds from source. 
But you've been building and making available binaries for MacOS, right?
I think that moves any legal question to "distribution" rather than "use".
You may well agree with me that the code you want to include is not subject
to the TOMS license even though TOMS seems to say it is.  But you should
at least be aware that the question has been raised in the past.

> Lastly, a tricky point that is easily overlooked is that i1mach, r1mach,
> d1mach need to be configured for x86. Moreover, since openspecfun is built
> as a library, it already contains i1mach and d1mach, opening the door for
> conflicting functions if one gathers cexint/zexint into a separate
> library...

As to r1mach.f and d1mach.f,  I am not using either of them here.
I replaced these with a C-language data block (attached) that I use
to build libamos from the Sandia sources for all the Amos routines.
I link against that rather than against libopenspecfun.

I sent my collection of libamos source to Tatsuro Matsuoka in case
he wanted to use them for building Windows packages.
I even  considered adding source for all the libamos routines as a
separate subdirectory in the gnuplot distribution package.
But then I found that many/most linux distros  already provide
libopenspecfun so I decided against complicating the gnuplot packaging
by having it supply a whole separate library for the sake of a single routine.

> I am attaching my modified version of amos_airy.c, in case you are swayed
> by my argument...

Are you thinking that the user would build zexint.o as a separate object
module and then add it to the Makefile somehow?

I would prefer to make it a configuration option. Not sure how best
to capture a single extra source file whose provenance and dependencies
we don't control.  I think it would be easier to require that it has already
been wrapped into a shared library.
Or hey, another alternative is to provide a template for making it
a plugin.  The distribution package currently has a demo plugin for
uigamma.  Providing a plugin for a Fortran routine might be of
interest even apart from filling a gap in special function coverage.

      Ethan


> 
> 
> 
> On Tue, Jul 8, 2025 at 7:26 PM Ethan A Merritt <me...@uw...> wrote:
> 
> > On Tuesday, 8 July 2025 14:21:01 PDT Erik Luijten wrote:
> > > Hi Ethan,
> > >
> > > In amos_airy.c, you write:
> > >
> > >  * The cexint_() routine is also from the AMOS collection, but is not
> > part
> > >  * of the Bessel function subset and not included in libopenspecfun.
> > >  * I could not find source for a version of the source that splits the
> > >  * real and imaginary parts of the arguments as with the zxxxx.f Bessel
> > >  * routines; this one accepts and returns a CMPLX argument rather than
> > > separate
> > >  * real and imaginary parts.
> > >  *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN Subroutine
> > >  *             for Exponential Integrals of a Complex Argument
> > >  *             ACM Trans. Math. Software 16:178-182 (1990)
> > >
> > > This confuses me for two reasons:
> > > - You invoke CEXINT as a double precision function, even though this
> > > Fortran function is single precision.
> >
> > > - The algorithm 683 you quote DOES provide a separate double precision
> > > function, ZEXINT. Moreover, that function does exactly what you were
> > > looking for, namely taking and returning separate real and imaginary
> > parts.
> >
> > There is some history behind this due to IMHO over-zealous, or at least
> > overly pessimistic, concern about license contamination with non-free code.
> > I cited a publication in ACM/TMS that describes the implementation.
> > However, people have assserted that code obtained through the ACM
> > journal is non-free because the journal claims copyright.
> > I believe this to be factually incorrect; the published article may be
> > subject
> > to copyright but not the code it describes. In any case, rather than pursue
> > the argument I instead used copies of the code obtained from US national
> > lab repositories.  I found source there for cexint.f but not for zexint.f,
> > so that is what I use myself to build libamos and what I invoked from the
> > gnuplot code.
> >
> > Even so that was apparently not sufficient by itself to convince hard-core
> > "free licenses only" gatekeepers.
> > There is an explicit statement of the [non]copyright status of the code
> > in the cited 1985 Sandia National Laboratory report, but that report
> > predated development of the expint routines (1990?) and I did not find a
> > separate Sandia report that mentions them specifically.
> > That is probably why neither routine is included in libopenspec,
> > and why inclusion in gnuplot is a configuration option.
> >
> > > I changed f_amos_cexint to use ZEXINT (just for my own edification) and
> > it
> > > works properly. However, before submitting it, I wonder what am I
> > missing?
> >
> > Where did you obtain a copy of the source?
> > Can you document the relevant claim or non-claim of copyright or
> > licensing?
> >
> > And, out of curiosity, is there anything in the zexint.f code that would
> > differentiate it from a single-precision version other than declaration
> > of the variables as Fortran DOUBLE PRECISION?
> >
> >         Ethan
> >
> >
> > >
> > > Thank you,
> > >
> > > Erik
> > >
> >
> >
> >
> >
> 

Re: Complex Exponential Integral

[Erik L. <eri...@gm...>]

Hi,

I found the code on https://dl.acm.org/doi/abs/10.1145/78928.78934; the
supplementary material contains all the subroutines concatenated into one
file (https://dl.acm.org/doi/suppl/10.1145/78928.78934/suppl_file/683.gz).
It is also available on https://www.netlib.org/toms-2014-06-10/ (scroll to
algorithm 683).
The fact that it is on netlib tells me it is likely free to use. However,
the ACM TOMS license agreement is here:
https://www.acm.org/publications/policies/software-copyright-notice . I am
not sure if this conflicts with Gnuplot's license? Whether a more
permissive license applies to cexint_.f  than to zexint_.f is also unclear
to me.

An awkward point, to the best of my understanding, is that an unmodified
version of cexint will not work with the Gnuplot source code, as it expects
single-precision arguments. Yet, changing cexint is not
completely straightforward: Comparing cexint and zexint (and the
accompanying routines cexent and zexent), I noticed the more subtle point
that cexint uses r1mach.f and zexint uses d1mach.f; moreover, they use
different constants from i1mach to establish precision (elements 12,13 vs.
15,16). Also, in zexint all constants are replaced by their
double-precision counterparts.

For all these reasons, I would argue that if copyright restrictions are the
same for cexint and zexint, it would be better to use the latter - a user
could then directly download this subroutine and use it without
modifications.

Lastly, a tricky point that is easily overlooked is that i1mach, r1mach,
d1mach need to be configured for x86. Moreover, since openspecfun is built
as a library, it already contains i1mach and d1mach, opening the door for
conflicting functions if one gathers cexint/zexint into a separate
library...

I am attaching my modified version of amos_airy.c, in case you are swayed
by my argument...

Best,

Erik







On Tue, Jul 8, 2025 at 7:26 PM Ethan A Merritt <me...@uw...> wrote:

> On Tuesday, 8 July 2025 14:21:01 PDT Erik Luijten wrote:
> > Hi Ethan,
> >
> > In amos_airy.c, you write:
> >
> >  * The cexint_() routine is also from the AMOS collection, but is not
> part
> >  * of the Bessel function subset and not included in libopenspecfun.
> >  * I could not find source for a version of the source that splits the
> >  * real and imaginary parts of the arguments as with the zxxxx.f Bessel
> >  * routines; this one accepts and returns a CMPLX argument rather than
> > separate
> >  * real and imaginary parts.
> >  *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN Subroutine
> >  *             for Exponential Integrals of a Complex Argument
> >  *             ACM Trans. Math. Software 16:178-182 (1990)
> >
> > This confuses me for two reasons:
> > - You invoke CEXINT as a double precision function, even though this
> > Fortran function is single precision.
>
> > - The algorithm 683 you quote DOES provide a separate double precision
> > function, ZEXINT. Moreover, that function does exactly what you were
> > looking for, namely taking and returning separate real and imaginary
> parts.
>
> There is some history behind this due to IMHO over-zealous, or at least
> overly pessimistic, concern about license contamination with non-free code.
> I cited a publication in ACM/TMS that describes the implementation.
> However, people have assserted that code obtained through the ACM
> journal is non-free because the journal claims copyright.
> I believe this to be factually incorrect; the published article may be
> subject
> to copyright but not the code it describes. In any case, rather than pursue
> the argument I instead used copies of the code obtained from US national
> lab repositories.  I found source there for cexint.f but not for zexint.f,
> so that is what I use myself to build libamos and what I invoked from the
> gnuplot code.
>
> Even so that was apparently not sufficient by itself to convince hard-core
> "free licenses only" gatekeepers.
> There is an explicit statement of the [non]copyright status of the code
> in the cited 1985 Sandia National Laboratory report, but that report
> predated development of the expint routines (1990?) and I did not find a
> separate Sandia report that mentions them specifically.
> That is probably why neither routine is included in libopenspec,
> and why inclusion in gnuplot is a configuration option.
>
> > I changed f_amos_cexint to use ZEXINT (just for my own edification) and
> it
> > works properly. However, before submitting it, I wonder what am I
> missing?
>
> Where did you obtain a copy of the source?
> Can you document the relevant claim or non-claim of copyright or
> licensing?
>
> And, out of curiosity, is there anything in the zexint.f code that would
> differentiate it from a single-precision version other than declaration
> of the variables as Fortran DOUBLE PRECISION?
>
>         Ethan
>
>
> >
> > Thank you,
> >
> > Erik
> >
>
>
>
>

Re: Complex Exponential Integral

[Ethan A M. <me...@uw...>]

On Tuesday, 8 July 2025 14:21:01 PDT Erik Luijten wrote:
> Hi Ethan,
> 
> In amos_airy.c, you write:
> 
>  * The cexint_() routine is also from the AMOS collection, but is not part
>  * of the Bessel function subset and not included in libopenspecfun.
>  * I could not find source for a version of the source that splits the
>  * real and imaginary parts of the arguments as with the zxxxx.f Bessel
>  * routines; this one accepts and returns a CMPLX argument rather than
> separate
>  * real and imaginary parts.
>  *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN Subroutine
>  *             for Exponential Integrals of a Complex Argument
>  *             ACM Trans. Math. Software 16:178-182 (1990)
> 
> This confuses me for two reasons:
> - You invoke CEXINT as a double precision function, even though this
> Fortran function is single precision.

> - The algorithm 683 you quote DOES provide a separate double precision
> function, ZEXINT. Moreover, that function does exactly what you were
> looking for, namely taking and returning separate real and imaginary parts.

There is some history behind this due to IMHO over-zealous, or at least
overly pessimistic, concern about license contamination with non-free code.
I cited a publication in ACM/TMS that describes the implementation.
However, people have assserted that code obtained through the ACM
journal is non-free because the journal claims copyright.
I believe this to be factually incorrect; the published article may be subject
to copyright but not the code it describes. In any case, rather than pursue
the argument I instead used copies of the code obtained from US national
lab repositories.  I found source there for cexint.f but not for zexint.f,
so that is what I use myself to build libamos and what I invoked from the
gnuplot code.

Even so that was apparently not sufficient by itself to convince hard-core
"free licenses only" gatekeepers.
There is an explicit statement of the [non]copyright status of the code
in the cited 1985 Sandia National Laboratory report, but that report
predated development of the expint routines (1990?) and I did not find a
separate Sandia report that mentions them specifically. 
That is probably why neither routine is included in libopenspec,
and why inclusion in gnuplot is a configuration option.

> I changed f_amos_cexint to use ZEXINT (just for my own edification) and it
> works properly. However, before submitting it, I wonder what am I missing?

Where did you obtain a copy of the source?
Can you document the relevant claim or non-claim of copyright or
licensing?

And, out of curiosity, is there anything in the zexint.f code that would
differentiate it from a single-precision version other than declaration
of the variables as Fortran DOUBLE PRECISION?

	Ethan


> 
> Thank you,
> 
> Erik
> 

Complex Exponential Integral

[Erik L. <eri...@gm...>]

Hi Ethan,

In amos_airy.c, you write:

 * The cexint_() routine is also from the AMOS collection, but is not part
 * of the Bessel function subset and not included in libopenspecfun.
 * I could not find source for a version of the source that splits the
 * real and imaginary parts of the arguments as with the zxxxx.f Bessel
 * routines; this one accepts and returns a CMPLX argument rather than
separate
 * real and imaginary parts.
 *             D. E. Amos, ALGORITHM 683  A Portable FORTRAN Subroutine
 *             for Exponential Integrals of a Complex Argument
 *             ACM Trans. Math. Software 16:178-182 (1990)

This confuses me for two reasons:
- You invoke CEXINT as a double precision function, even though this
Fortran function is single precision.
- The algorithm 683 you quote DOES provide a separate double precision
function, ZEXINT. Moreover, that function does exactly what you were
looking for, namely taking and returning separate real and imaginary parts.

I changed f_amos_cexint to use ZEXINT (just for my own edification) and it
works properly. However, before submitting it, I wonder what am I missing?

Thank you,

Erik

Binaries for Windows on ARM

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

MSYS2/CLANG64 & CLANG64ARM environments support cross-compilation on 
Windows for Windows on ARM. I have just uploaded a first testing binary 
of gnuplot for Windows on ARM to the "testing" folder in the files 
section on SF (indicated by -woa). Please note that this is **completely 
untested** as I have no machine to test on. This version has no support 
(yet) for wxt, qt, gd terminals, and does not provide functions which 
rely on the openspecfun or cerf libraries and does not come with an 
installer. The 7zip-compressed archive should include all necessary 
DLLs, though. So far no ARM-specific changes were necessary.

Any feedback is very much appreciated, either via the list or at 
https://sourceforge.net/p/gnuplot/feature-requests/582/

   Bastian

Re: OK to use anonymous union (C11 feature)? Opinions wanted

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

Am 01.07.2025 um 08:31 schrieb Ethan A Merritt:

> The basic issue is that different code is needed if color is represented by
> a signed integer (e.g. "plot foo lt 2") or by an unsigned 32-bit ARGB value
> (e.g. "splot foo with pm3d fillstyle transparent solid 0.25").

I should, in theory, be about equally easy to shift the values of the 
enum up into the unsigned range, by way of an offset.  But that will of 
course lead to some level of confusion between the numeric value 
presented to the user, and the actual numbers seen in, e.g., a debug 
session.

OTOH, looking at that union in a debugger might be equally confusing. 
Mileage will vary.

That said, I'm kind-a surprised that this only shows up now.  Surely 
gnuplot has been running on countless ARM Macs, Raspberry PIs and 
similar things for ages.  And yet this was never seen before?  To me 
that feels like a hint that the actual problem may be not what we 
currently think it is.

> However IMO a cleaner approach is to modify the t_colorspec structure
> using an anonymous union to distinguish between the two cases:

I'm not quite convinced that an _anonymous_ union is really better than 
a named one, for this purpose, but the difference is small enough to be 
ignored.

> So the question is, is it worth adding a requirement for C compiler that supports
> C11 or at least supports anonymous unions?

Setting aside whether anonymous unions are sufficient reason to do it 
right now, the switch itself is probably a good idea anyway.

Re: OK to use anonymous union (C11 feature)? Opinions wanted

[Erik L. <eri...@gm...>]

Hi Ethan,

There is no objection from the macOS side: The compiler I use to generate
universal binaries defaults to c17/c++17.
Let me know if you wish me to try out a development version.

Best,

Erik



On Tue, Jul 1, 2025 at 1:32 AM Ethan A Merritt <me...@uw...> wrote:

> Bug reports 2812 and 2813 report and diagnose a problem with color-handling
> that manifests on ARM architectures but not on x86.  More detail is
> attached
> to bug 2812 if you want gory details.
>
> The basic issue is that different code is needed if color is represented by
> a signed integer (e.g. "plot foo lt 2") or by an unsigned 32-bit ARGB value
> (e.g. "splot foo with pm3d fillstyle transparent solid 0.25").
>
> It is possible to modify the code by inserting an appropiate cast to either
>    color.lt = (int)value     or    color.lt = (unsigned int)value
> everywhere that it matters.
>
> However IMO a cleaner approach is to modify the t_colorspec structure
> using an anonymous union to distinguish between the two cases:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>   typedef struct t_colorspec {
>       colortype type;                 /* TC_<type> definitions below */
>       union {
>           int lt;                               /* used for TC_LT,
> TC_LINESTYLE */
>           unsigned rgbcolor;      /* used for TC_RGB */
>       };
>       double value;                    /* used for TC_CB and TC_FRAC */
>   } t_colorspec;
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> That allows to write code like
>     if (color.type == TC_RGB)
>         color.rgbcolor = value;
>     else
>         color.lt = value;
> I have a tested this out in a private git branch and it works as intended.
>
> HOWEVER, anonymous unions were only added to the C standard in C11,
> although both gcc and clang already supported them well before that.
>
> So the question is, is it worth adding a requirement for C compiler that
> supports
> C11 or at least supports anonymous unions?
> As of gnuplot version 6 we're requiring c99 (version 5 was ok with c89).
> MSVisualStudio claims to support c11 as of 2019.   I don't know what other
> compilers people might be using, or what their level of support might be.
>
> What do you think?
> Add it to the development version and back it out if compiler problems
> are reported?   What about the stable version?
>
>         Ethan
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: OK to use anonymous union (C11 feature)? Opinions wanted

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

I fully support making use of a 14-year-old standard. 
https://gcc.gnu.org/projects/c-status.html  lists that gcc actually 
supports anonymous unions since version 4.6, with some support since 
version 3. Official builds for Windows use a modern gcc and build nicely 
with clang as well. DJGPP has gcc 14 cross-compilers and the last 
official OS/2 build used gcc 3, but gcc 9.0 or gcc 11.4 are available. 
MSVC has full support since 2016 version 16.8

In summary, c11 should not be an issue for any of the Windows, DJGPP, 
OS/2 platforms. Backing-out in case of issues on certain platforms seems 
like a reasonable approach.

gnuplot requires c99 since quite a while actually. See e.g. the 
discussion in https://sourceforge.net/p/gnuplot/patches/484/ due to old 
versions of MSVC only supporting c89. That patch is from 2010!

While at it: can we also now use the // comments which are part of c99?

   Bastian

Am 01.07.2025 um 08:31 schrieb Ethan A Merritt:
> Bug reports 2812 and 2813 report and diagnose a problem with color-handling
> that manifests on ARM architectures but not on x86.  More detail is attached
> to bug 2812 if you want gory details.
>
> The basic issue is that different code is needed if color is represented by
> a signed integer (e.g. "plot foo lt 2") or by an unsigned 32-bit ARGB value
> (e.g. "splot foo with pm3d fillstyle transparent solid 0.25").
>
> It is possible to modify the code by inserting an appropiate cast to either
>     color.lt = (int)value     or    color.lt = (unsigned int)value
> everywhere that it matters.
>
> However IMO a cleaner approach is to modify the t_colorspec structure
> using an anonymous union to distinguish between the two cases:
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>    typedef struct t_colorspec {
>        colortype type;                 /* TC_<type> definitions below */
>        union {
>            int lt;                               /* used for TC_LT, TC_LINESTYLE */
>            unsigned rgbcolor;      /* used for TC_RGB */
>        };
>        double value;                    /* used for TC_CB and TC_FRAC */
>    } t_colorspec;
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> That allows to write code like
>      if (color.type == TC_RGB)
> 	color.rgbcolor = value;
>      else
> 	color.lt = value;
> I have a tested this out in a private git branch and it works as intended.
>
> HOWEVER, anonymous unions were only added to the C standard in C11,
> although both gcc and clang already supported them well before that.
>
> So the question is, is it worth adding a requirement for C compiler that supports
> C11 or at least supports anonymous unions?
> As of gnuplot version 6 we're requiring c99 (version 5 was ok with c89).
> MSVisualStudio claims to support c11 as of 2019.   I don't know what other
> compilers people might be using, or what their level of support might be.
>
> What do you think?
> Add it to the development version and back it out if compiler problems
> are reported?   What about the stable version?
>
> 	Ethan
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

OK to use anonymous union (C11 feature)? Opinions wanted

[Ethan A M. <me...@uw...>]

Bug reports 2812 and 2813 report and diagnose a problem with color-handling
that manifests on ARM architectures but not on x86.  More detail is attached
to bug 2812 if you want gory details.

The basic issue is that different code is needed if color is represented by
a signed integer (e.g. "plot foo lt 2") or by an unsigned 32-bit ARGB value
(e.g. "splot foo with pm3d fillstyle transparent solid 0.25").

It is possible to modify the code by inserting an appropiate cast to either
   color.lt = (int)value     or    color.lt = (unsigned int)value
everywhere that it matters.

However IMO a cleaner approach is to modify the t_colorspec structure
using an anonymous union to distinguish between the two cases:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  typedef struct t_colorspec {
      colortype type;                 /* TC_<type> definitions below */
      union {
          int lt;                               /* used for TC_LT, TC_LINESTYLE */
          unsigned rgbcolor;      /* used for TC_RGB */
      };
      double value;                    /* used for TC_CB and TC_FRAC */
  } t_colorspec;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

That allows to write code like
    if (color.type == TC_RGB)
	color.rgbcolor = value;
    else
	color.lt = value;
I have a tested this out in a private git branch and it works as intended.

HOWEVER, anonymous unions were only added to the C standard in C11,
although both gcc and clang already supported them well before that.

So the question is, is it worth adding a requirement for C compiler that supports
C11 or at least supports anonymous unions?
As of gnuplot version 6 we're requiring c99 (version 5 was ok with c89).
MSVisualStudio claims to support c11 as of 2019.   I don't know what other
compilers people might be using, or what their level of support might be. 

What do you think?
Add it to the development version and back it out if compiler problems
are reported?   What about the stable version?  

	Ethan

Re: How to color ALL the axis elements?

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

OK. Thanks.

Re: How to color ALL the axis elements?

[Ethan A M. <me...@uw...>]

On Sunday, 15 June 2025 10:45:54 PDT Dima Kogan wrote:
> 
> I've a question/feature request. I often plot stuff against the
> non-default axes, and it's really helpful to make it visually clear
> which axes the different parts of the plot reference.
> 
> Something like this works:
> 
>   set ylabel "line"      textcolor linetype 1
>   set ytics              textcolor linetype 1
>   set y2label "parabola" textcolor linetype 2
>   set y2tics             textcolor linetype 2
> 
>   plot x   with lines, \
>        x*x with lines axis x1y2
> 
> So I plotted two things with different colors, and I want to color the
> axes with the appropriate colors too. Each axis has 4 things that I'd
> want to color, but here only two of those are colored; it's not clear if
> gnuplot can do the other two:
> 
> - The axis label text. I can color this
> - The tic label text. I can color that too
> - The tics themselves. I can NOT color that, and I don't see anything in
>   the docs about doing it. "set ytics textcolor" probably should control
>   those too?
> 
> - The axis line itself. This is a part of "set border". We can set the
>   color of the whole thing, but not of its separate elements, right?

Correct.

> Can we fix this?

My personal opinion is that this is not something you should do.
It makes the plot really ugly and (again IMO) distracts from the data,
which is where the focus of attention should be.
And what color would you make the x axis?

If for some reason you really need to do this, I would say it's one of the
rare cases where using multiplot to superimpose two plots is the
preferred answer.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    set margins screen 0.1, screen 0.9
    unset key

    set multiplot
      unset tics; set ytics nomirror
      set border 2 lt 1
      set xzeroaxis
      plot x with lines lt 1

      unset tics; set y2tics nomirror
      set border 8 lt 2
      plot x*x with lines axes x1y2 lt 2

      unset tics; set xtics axis -8,2,8
      set border 0 lt black
      plot 0 lc "black" notitle
   unset multiplot
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

> What kind of patch would be acceptable here?

> Also, it'd be real nice if there was ONE command to set the color of ALL
> the axis elements together.
> 
> Thanks
> 

      Ethan

How to color ALL the axis elements?

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

Hello!

I've a question/feature request. I often plot stuff against the
non-default axes, and it's really helpful to make it visually clear
which axes the different parts of the plot reference.

Something like this works:

  set ylabel "line"      textcolor linetype 1
  set ytics              textcolor linetype 1
  set y2label "parabola" textcolor linetype 2
  set y2tics             textcolor linetype 2

  plot x   with lines, \
       x*x with lines axis x1y2

So I plotted two things with different colors, and I want to color the
axes with the appropriate colors too. Each axis has 4 things that I'd
want to color, but here only two of those are colored; it's not clear if
gnuplot can do the other two:

- The axis label text. I can color this

- The tic label text. I can color that too

- The tics themselves. I can NOT color that, and I don't see anything in
  the docs about doing it. "set ytics textcolor" probably should control
  those too?

- The axis line itself. This is a part of "set border". We can set the
  color of the whole thing, but not of its separate elements, right?

Can we fix this? What kind of patch would be acceptable here?

Also, it'd be real nice if there was ONE command to set the color of ALL
the axis elements together.

Thanks

Re: Gnuplot Release 6.0.3

[Erik L. <eri...@gm...>]

The macOS (ARM and Intel; fully self-contained) binaries are available in
the usual location:
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_macOS

I compiled the ARM version on a new Mac, so let me know if you encounter
any issues. Compared to earlier versions, I now also included the WebP
terminal.

Erik

On Sat, Jun 7, 2025 at 10:13 PM Ethan A Merritt <me...@uw...> wrote:

> The release tarball for gnuplot version 6.0 patchlevel 3 is now available
> on SourceForge
>
>
> https://sourceforge.net/projects/gnuplot/files/gnuplot/6.0.3/gnuplot-6.0.3.tar.gz
>
> Release Notes here
>    Gnuplot 6.0.3 <https://gnuplot.sourceforge.net/ReleaseNotes_6_0_3.html>
>
> The release tarball differs from the testing tarball by a fix to report
> the correct
> version on the splashpage (stupid mistake on my part, sorry!).  Thanks to
> everyone
> who tested the pre-release package.
>
> There is nothing very exciting in this release, but it does include a few
> minor features back-ported from the development version:
>
> • In previous gnuplot versions all 3D polygons, objects, and filled areas
> shared
>   a single border color and linewidth taken from "set pm3d".
>   This limitation is now removed; border properties can be specified
> per-plot or
>   per-object. This change affects any scripts that expected "set pm3d" to
> affect
>   the borders of 3D polygons and boxes.
>
> • splot ... "with contourfill at base"   ("at base" is new)
>
> • Input data to plot and splot can be filtered through a conditional
> expression
>   outside the "using" section.  For example:
>       plot DATA using 2:3 with boxes if (stringcolumn(1) eq "ABC")
>
> • New command "save changes" is equivalent to the old contributed external
> script
>   gpsavediff. This command saves only the program settings, variables, and
>   functions that distinguish the current state from the program state at
> the start
>   of the current gnuplot session.
>
> • Revised wxt terminal driver (linux) with more robust threading and error
> recovery.
>
> happy gnuplotting
>
>     Ethan
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Gnuplot Release 6.0.3

[Tatsuro M. <tma...@ya...>]

I have uploaded Windows binary packages of 6.0.3.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnuplot beta list" <gnu...@li...>
> Date: 2025/06/08 日 12:13
> Subject: Gnuplot Release 6.0.3
> 
> 
> The release tarball for gnuplot version 6.0 patchlevel 3 is now available
> on SourceForge
> 
> https://sourceforge.net/projects/gnuplot/files/gnuplot/6.0.3/gnuplot-6.0.3.tar.gz
> 
> Release Notes here
>    Gnuplot 6.0.3 <https://gnuplot.sourceforge.net/ReleaseNotes_6_0_3.html>
> 
> The release tarball differs from the testing tarball by a fix to report the correct
> version on the splashpage (stupid mistake on my part, sorry!).  Thanks to everyone
> who tested the pre-release package.
> 
> There is nothing very exciting in this release, but it does include a few
> minor features back-ported from the development version:
> 
> • In previous gnuplot versions all 3D polygons, objects, and filled areas shared
>   a single border color and linewidth taken from "set pm3d".
>   This limitation is now removed; border properties can be specified per-plot or
>   per-object. This change affects any scripts that expected "set pm3d" to affect
>   the borders of 3D polygons and boxes.
> 
> • splot ... "with contourfill at base"   ("at base" is new)
>  
> • Input data to plot and splot can be filtered through a conditional expression
>   outside the "using" section.  For example:
>       plot DATA using 2:3 with boxes if (stringcolumn(1) eq "ABC")
> 
> • New command "save changes" is equivalent to the old contributed external script
>   gpsavediff. This command saves only the program settings, variables, and
>   functions that distinguish the current state from the program state at the start
>   of the current gnuplot session.
> 
> • Revised wxt terminal driver (linux) with more robust threading and error recovery.
> 
> happy gnuplotting
> 
>     Ethan
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Gnuplot Release 6.0.3

[Ethan A M. <me...@uw...>]

The release tarball for gnuplot version 6.0 patchlevel 3 is now available
on SourceForge

https://sourceforge.net/projects/gnuplot/files/gnuplot/6.0.3/gnuplot-6.0.3.tar.gz

Release Notes here
   Gnuplot 6.0.3 <https://gnuplot.sourceforge.net/ReleaseNotes_6_0_3.html>

The release tarball differs from the testing tarball by a fix to report the correct
version on the splashpage (stupid mistake on my part, sorry!).  Thanks to everyone
who tested the pre-release package.

There is nothing very exciting in this release, but it does include a few
minor features back-ported from the development version:

• In previous gnuplot versions all 3D polygons, objects, and filled areas shared
  a single border color and linewidth taken from "set pm3d".
  This limitation is now removed; border properties can be specified per-plot or
  per-object. This change affects any scripts that expected "set pm3d" to affect
  the borders of 3D polygons and boxes.

• splot ... "with contourfill at base"   ("at base" is new)
 
• Input data to plot and splot can be filtered through a conditional expression
  outside the "using" section.  For example:
      plot DATA using 2:3 with boxes if (stringcolumn(1) eq "ABC")

• New command "save changes" is equivalent to the old contributed external script
  gpsavediff. This command saves only the program settings, variables, and
  functions that distinguish the current state from the program state at the start
  of the current gnuplot session.

• Revised wxt terminal driver (linux) with more robust threading and error recovery.

happy gnuplotting

    Ethan

Re: Testing version of gnuplot 6.0.3

[Ethan A M. <me...@uw...>]

Sigh.  Quite right.   Trivial fix but it will of course mean the tarball
has a different hash sum.

Thanks for testing.

    Ethan

On Sat, Jun 7, 2025 at 7:03 AM Erik Luijten <eri...@gm...> wrote:

> It may be slightly pedantic, but I just noticed that gnuplot 6. 0. 3
> states (upon start-up): "Version 6. 0. 3 patchlevel 3 last modified
> 2025-06-01" while 6. 0. 2 stated (more logically, in my opinion): "Version
> 6. 0 patchlevel 2"
> ZjQcmQRYFpfptBannerStart
> This Message Is From an Untrusted Sender
> You have not previously corresponded with this sender.
> See https://itconnect.uw.edu/email-tags for additional information.
> Please contact the UW-IT Service Center, he...@uw... 206.221.5000, for
> assistance.
>
> ZjQcmQRYFpfptBannerEnd
> It may be slightly pedantic, but I just noticed that gnuplot 6.0.3 states
> (upon start-up):
>
> "Version *6.0.3* patchlevel 3    last modified 2025-06-01"
>
> while 6.0.2 stated (more logically, in my opinion):
>
> "Version 6.0 patchlevel 2"
>
> Erik
>
> On Thu, Jun 5, 2025 at 3:50 PM Erik Luijten <eri...@gm...>
> wrote:
>
>> This compiles properly on macOS, both with wxt and with Qt5.
>>
>> Erik
>>
>> On Tue, Jun 3, 2025 at 9:29 PM Ethan A Merritt <me...@uw...> wrote:
>>
>>> I have placed a tarball for release 6.0.3 in the "testing" folder on
>>> SourceForge
>>>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>>> <https://urldefense.com/v3/__https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/__;!!K-Hz7m0Vt54!lH9cGC0w2qdoOf5ZhlYyhW2qgZZa-6cMWuUOcrtVPrlVskQbr2DJ7erPTsvmc9dNWD_Lg9vStgQkj5eXHV3v$>
>>>
>>> Please report any build problems or other issues you find with the test
>>> package.
>>> If no problems arise I plan to use the same files for a release
>>> announcement
>>> next weekend.
>>>
>>> Release note appended below, or see
>>>
>>>     gnuplot.sourceforge.net/ReleaseNotes_6_0_3.html
>>> <https://urldefense.com/v3/__http://gnuplot.sourceforge.net/ReleaseNotes_6_0_3.html__;!!K-Hz7m0Vt54!lH9cGC0w2qdoOf5ZhlYyhW2qgZZa-6cMWuUOcrtVPrlVskQbr2DJ7erPTsvmc9dNWD_Lg9vStgQkj1HGSp7Q$>
>>>
>>> - Ethan
>>>
>>>                 Gnuplot Version 6.0.3 Release Notes
>>>                 ===================================
>>>
>>> This is the third incremental release for gnuplot stable version 6.0.
>>> It contains several new features and improvements back-ported from the
>>> development version.
>>>
>>> NEW (backported from development version)
>>> -----------------------------------------
>>>
>>> * NEW    "contourfill {at base} {fs {no}border}"
>>> * NEW    "save changes <filename>"
>>>          This variant saves only the differences between the current
>>> program
>>>          state and the state at the start of the session.
>>> * NEW    "plot <data> ... if (filter_condition)"
>>>          Input lines of data that satisfy the if condition are processed
>>> as usual.
>>>          Lines that fail are essentially ignored.
>>> * NEW    backport watchpoint improvements from 6.1
>>>          Each watch target can have its own label, generated by a user
>>> function.
>>>          Any real-valued function is legal as a watchpoint target.
>>>          Current x, y, and z values are available inside a watchpoint
>>> target function.
>>>          Watchpoints are possible for splot in "set view map" projection.
>>>          See
>>>             * https://gnuplot.info/demo_6.0/watch_contours.html
>>> <https://urldefense.com/v3/__https://gnuplot.info/demo_6.0/watch_contours.html__;!!K-Hz7m0Vt54!lH9cGC0w2qdoOf5ZhlYyhW2qgZZa-6cMWuUOcrtVPrlVskQbr2DJ7erPTsvmc9dNWD_Lg9vStgQkj6PGpJ3N$>
>>> * NEW    Continued work on multiplot replot and mousing
>>>
>>> CHANGES
>>> -------
>>>
>>> * CHANGE 3D polygon objects can have per-object fill border properties.
>>>          The restriction that all 3D polygons share a single set of
>>>          properties from "set pm3d" remains true for "splot with
>>> polygons".
>>> * CHANGE The configuration option --with-wx-multithreaded has been
>>> removed.
>>>          The multi-thread code has not worked under linux for quite a
>>> while.
>>>          This change does not affect the Windows version of the wxt
>>> terminal,
>>> * CHANGE "with hsteps" takes default width from "set boxwidth".
>>> * CHANGE column(0) returns an integer (not complex) value
>>> * CHANGE win: dll function loading altered for compatibility with gcc15
>>>
>>> FIXES
>>> -----
>>>
>>> * FIX    Support for combined hidden3d + pm3d depthorder back-ported
>>> from 6.1
>>>          This allows placing contours on a depth-sorted pm3d surface
>>> * FIX    qt: opaque key caused incorrect interactive toggling of final
>>> plot
>>> * FIX    6.0.2 regression in "splot ... using 1:2:3:4 lc palette"
>>> * FIX    placement of category labels along x-axis of boxplots
>>> * FIX    qt, cairo: "set colorbox invert" produced empty colorbox
>>> * FIX    placement of minor tics along logscale axis with narrow range
>>> * FIX    OK to have missing corners in an image from a sparse matrix
>>> * FIX    error handling for various corner cases involving function
>>> blocks
>>>
>>>
>>> KNOWN ISSUES
>>> ------------
>>>
>>> - Redefining a global array variable inside a user function or function
>>> block
>>>   may lead to memory corruption and/or a program crash.  The development
>>> version
>>>   now handles this cleanly, but the necessary framework has not yet been
>>>   back-ported to verion 6.0.  The current version may issue the
>>> confusing error
>>>   message "non-numeric array index" and leave the corrupted array in
>>> place.
>>>
>>> - Font handling by the cairo/pango libraries supporting some gnuplot
>>> terminals
>>>   (pdf, png, wxt, ...) on both Windows and MacOS are sensitive to the
>>>   enviromental variable PANGOCAIRO_BACKEND.  If you are having font
>>> problems,
>>>   try setting this to
>>>         PANGOCAIRO_BACKEND=fc
>>>
>>> - Support for replot and pan/zoom mouse operations in multiplot mode is
>>> still
>>>   incomplete. Expect further improvement in subsequent releases.
>>>
>>> - TeXLive2024 pdflatex does not like some of the UTF-8 characters in the
>>> user manual.
>>>   The distribution includes a pre-built copy of gnuplot.pdf but if you
>>> want
>>>   to rebuild it from the source in docs/gnuplot.doc please use lualatex
>>> instead.
>>>   You can either replace the definition PDFLATEX=pdflatex with
>>> PDFLATEX=lualatex
>>>   in the Makefile or provide this in the environment during configuration
>>>         PDFLATEX=lualatex ./configure
>>>
>>> Gnuplot development is tracked in a git repository on SourceForge.
>>> You can generate a complete history of changes using "git log"
>>> after downloading:
>>>
>>> <pre>
>>>     git clone -b branch-6-0-stable git://
>>> git.code.sf.net/p/gnuplot/gnuplot-main
>>> <https://urldefense.com/v3/__http://git.code.sf.net/p/gnuplot/gnuplot-main__;!!K-Hz7m0Vt54!lH9cGC0w2qdoOf5ZhlYyhW2qgZZa-6cMWuUOcrtVPrlVskQbr2DJ7erPTsvmc9dNWD_Lg9vStgQkj49IONLU$>
>>>     git log
>>> </pre>
>>>
>>> Release Notes date:  03 June 2025
>>>
>>>
>>>
>>> --
>>> Ethan A Merritt
>>> Department of Biochemistry
>>> University of Washington, Seattle
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gnuplot-beta mailing list
>>> gnu...@li...
>>> Membership management via:
>>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lH9cGC0w2qdoOf5ZhlYyhW2qgZZa-6cMWuUOcrtVPrlVskQbr2DJ7erPTsvmc9dNWD_Lg9vStgQkj9FtiR3w$>
>>>
>> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!lH9cGC0w2qdoOf5ZhlYyhW2qgZZa-6cMWuUOcrtVPrlVskQbr2DJ7erPTsvmc9dNWD_Lg9vStgQkj9FtiR3w$
>


-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Re: Testing version of gnuplot 6.0.3

[Erik L. <eri...@gm...>]

It may be slightly pedantic, but I just noticed that gnuplot 6.0.3 states
(upon start-up):

"Version *6.0.3* patchlevel 3    last modified 2025-06-01"

while 6.0.2 stated (more logically, in my opinion):

"Version 6.0 patchlevel 2"

Erik

On Thu, Jun 5, 2025 at 3:50 PM Erik Luijten <eri...@gm...> wrote:

> This compiles properly on macOS, both with wxt and with Qt5.
>
> Erik
>
> On Tue, Jun 3, 2025 at 9:29 PM Ethan A Merritt <me...@uw...> wrote:
>
>> I have placed a tarball for release 6.0.3 in the "testing" folder on
>> SourceForge
>>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>>
>> Please report any build problems or other issues you find with the test
>> package.
>> If no problems arise I plan to use the same files for a release
>> announcement
>> next weekend.
>>
>> Release note appended below, or see
>>
>>     gnuplot.sourceforge.net/ReleaseNotes_6_0_3.html
>>
>> - Ethan
>>
>>                 Gnuplot Version 6.0.3 Release Notes
>>                 ===================================
>>
>> This is the third incremental release for gnuplot stable version 6.0.
>> It contains several new features and improvements back-ported from the
>> development version.
>>
>> NEW (backported from development version)
>> -----------------------------------------
>>
>> * NEW    "contourfill {at base} {fs {no}border}"
>> * NEW    "save changes <filename>"
>>          This variant saves only the differences between the current
>> program
>>          state and the state at the start of the session.
>> * NEW    "plot <data> ... if (filter_condition)"
>>          Input lines of data that satisfy the if condition are processed
>> as usual.
>>          Lines that fail are essentially ignored.
>> * NEW    backport watchpoint improvements from 6.1
>>          Each watch target can have its own label, generated by a user
>> function.
>>          Any real-valued function is legal as a watchpoint target.
>>          Current x, y, and z values are available inside a watchpoint
>> target function.
>>          Watchpoints are possible for splot in "set view map" projection.
>>          See
>>             * https://gnuplot.info/demo_6.0/watch_contours.html
>> * NEW    Continued work on multiplot replot and mousing
>>
>> CHANGES
>> -------
>>
>> * CHANGE 3D polygon objects can have per-object fill border properties.
>>          The restriction that all 3D polygons share a single set of
>>          properties from "set pm3d" remains true for "splot with
>> polygons".
>> * CHANGE The configuration option --with-wx-multithreaded has been
>> removed.
>>          The multi-thread code has not worked under linux for quite a
>> while.
>>          This change does not affect the Windows version of the wxt
>> terminal,
>> * CHANGE "with hsteps" takes default width from "set boxwidth".
>> * CHANGE column(0) returns an integer (not complex) value
>> * CHANGE win: dll function loading altered for compatibility with gcc15
>>
>> FIXES
>> -----
>>
>> * FIX    Support for combined hidden3d + pm3d depthorder back-ported from
>> 6.1
>>          This allows placing contours on a depth-sorted pm3d surface
>> * FIX    qt: opaque key caused incorrect interactive toggling of final
>> plot
>> * FIX    6.0.2 regression in "splot ... using 1:2:3:4 lc palette"
>> * FIX    placement of category labels along x-axis of boxplots
>> * FIX    qt, cairo: "set colorbox invert" produced empty colorbox
>> * FIX    placement of minor tics along logscale axis with narrow range
>> * FIX    OK to have missing corners in an image from a sparse matrix
>> * FIX    error handling for various corner cases involving function blocks
>>
>>
>> KNOWN ISSUES
>> ------------
>>
>> - Redefining a global array variable inside a user function or function
>> block
>>   may lead to memory corruption and/or a program crash.  The development
>> version
>>   now handles this cleanly, but the necessary framework has not yet been
>>   back-ported to verion 6.0.  The current version may issue the confusing
>> error
>>   message "non-numeric array index" and leave the corrupted array in
>> place.
>>
>> - Font handling by the cairo/pango libraries supporting some gnuplot
>> terminals
>>   (pdf, png, wxt, ...) on both Windows and MacOS are sensitive to the
>>   enviromental variable PANGOCAIRO_BACKEND.  If you are having font
>> problems,
>>   try setting this to
>>         PANGOCAIRO_BACKEND=fc
>>
>> - Support for replot and pan/zoom mouse operations in multiplot mode is
>> still
>>   incomplete. Expect further improvement in subsequent releases.
>>
>> - TeXLive2024 pdflatex does not like some of the UTF-8 characters in the
>> user manual.
>>   The distribution includes a pre-built copy of gnuplot.pdf but if you
>> want
>>   to rebuild it from the source in docs/gnuplot.doc please use lualatex
>> instead.
>>   You can either replace the definition PDFLATEX=pdflatex with
>> PDFLATEX=lualatex
>>   in the Makefile or provide this in the environment during configuration
>>         PDFLATEX=lualatex ./configure
>>
>> Gnuplot development is tracked in a git repository on SourceForge.
>> You can generate a complete history of changes using "git log"
>> after downloading:
>>
>> <pre>
>>     git clone -b branch-6-0-stable git://
>> git.code.sf.net/p/gnuplot/gnuplot-main
>>     git log
>> </pre>
>>
>> Release Notes date:  03 June 2025
>>
>>
>>
>> --
>> Ethan A Merritt
>> Department of Biochemistry
>> University of Washington, Seattle
>>
>>
>>
>>
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> Membership management via:
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>

Re: Testing version of gnuplot 6.0.3

[Erik L. <eri...@gm...>]

This compiles properly on macOS, both with wxt and with Qt5.

Erik

On Tue, Jun 3, 2025 at 9:29 PM Ethan A Merritt <me...@uw...> wrote:

> I have placed a tarball for release 6.0.3 in the "testing" folder on
> SourceForge
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>
> Please report any build problems or other issues you find with the test
> package.
> If no problems arise I plan to use the same files for a release
> announcement
> next weekend.
>
> Release note appended below, or see
>
>     gnuplot.sourceforge.net/ReleaseNotes_6_0_3.html
>
> - Ethan
>
>                 Gnuplot Version 6.0.3 Release Notes
>                 ===================================
>
> This is the third incremental release for gnuplot stable version 6.0.
> It contains several new features and improvements back-ported from the
> development version.
>
> NEW (backported from development version)
> -----------------------------------------
>
> * NEW    "contourfill {at base} {fs {no}border}"
> * NEW    "save changes <filename>"
>          This variant saves only the differences between the current
> program
>          state and the state at the start of the session.
> * NEW    "plot <data> ... if (filter_condition)"
>          Input lines of data that satisfy the if condition are processed
> as usual.
>          Lines that fail are essentially ignored.
> * NEW    backport watchpoint improvements from 6.1
>          Each watch target can have its own label, generated by a user
> function.
>          Any real-valued function is legal as a watchpoint target.
>          Current x, y, and z values are available inside a watchpoint
> target function.
>          Watchpoints are possible for splot in "set view map" projection.
>          See
>             * https://gnuplot.info/demo_6.0/watch_contours.html
> * NEW    Continued work on multiplot replot and mousing
>
> CHANGES
> -------
>
> * CHANGE 3D polygon objects can have per-object fill border properties.
>          The restriction that all 3D polygons share a single set of
>          properties from "set pm3d" remains true for "splot with polygons".
> * CHANGE The configuration option --with-wx-multithreaded has been removed.
>          The multi-thread code has not worked under linux for quite a
> while.
>          This change does not affect the Windows version of the wxt
> terminal,
> * CHANGE "with hsteps" takes default width from "set boxwidth".
> * CHANGE column(0) returns an integer (not complex) value
> * CHANGE win: dll function loading altered for compatibility with gcc15
>
> FIXES
> -----
>
> * FIX    Support for combined hidden3d + pm3d depthorder back-ported from
> 6.1
>          This allows placing contours on a depth-sorted pm3d surface
> * FIX    qt: opaque key caused incorrect interactive toggling of final plot
> * FIX    6.0.2 regression in "splot ... using 1:2:3:4 lc palette"
> * FIX    placement of category labels along x-axis of boxplots
> * FIX    qt, cairo: "set colorbox invert" produced empty colorbox
> * FIX    placement of minor tics along logscale axis with narrow range
> * FIX    OK to have missing corners in an image from a sparse matrix
> * FIX    error handling for various corner cases involving function blocks
>
>
> KNOWN ISSUES
> ------------
>
> - Redefining a global array variable inside a user function or function
> block
>   may lead to memory corruption and/or a program crash.  The development
> version
>   now handles this cleanly, but the necessary framework has not yet been
>   back-ported to verion 6.0.  The current version may issue the confusing
> error
>   message "non-numeric array index" and leave the corrupted array in place.
>
> - Font handling by the cairo/pango libraries supporting some gnuplot
> terminals
>   (pdf, png, wxt, ...) on both Windows and MacOS are sensitive to the
>   enviromental variable PANGOCAIRO_BACKEND.  If you are having font
> problems,
>   try setting this to
>         PANGOCAIRO_BACKEND=fc
>
> - Support for replot and pan/zoom mouse operations in multiplot mode is
> still
>   incomplete. Expect further improvement in subsequent releases.
>
> - TeXLive2024 pdflatex does not like some of the UTF-8 characters in the
> user manual.
>   The distribution includes a pre-built copy of gnuplot.pdf but if you want
>   to rebuild it from the source in docs/gnuplot.doc please use lualatex
> instead.
>   You can either replace the definition PDFLATEX=pdflatex with
> PDFLATEX=lualatex
>   in the Makefile or provide this in the environment during configuration
>         PDFLATEX=lualatex ./configure
>
> Gnuplot development is tracked in a git repository on SourceForge.
> You can generate a complete history of changes using "git log"
> after downloading:
>
> <pre>
>     git clone -b branch-6-0-stable git://
> git.code.sf.net/p/gnuplot/gnuplot-main
>     git log
> </pre>
>
> Release Notes date:  03 June 2025
>
>
>
> --
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Testing version of gnuplot 6.0.3

[Tatsuro M. <tma...@ya...>]

I have tested build of testing version of 6.0.3 on mingw64.
Build went well

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Date: 2025/06/04 水 11:29
> Subject: Testing version of gnuplot 6.0.3
> 
> 
> I have placed a tarball for release 6.0.3 in the "testing" folder on SourceForge
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
> 
> Please report any build problems or other issues you find with the test package.
> If no problems arise I plan to use the same files for a release announcement
> next weekend.
> 
> Release note appended below, or see
> 
>     gnuplot.sourceforge.net/ReleaseNotes_6_0_3.html
> 
> - Ethan
> 
>                 Gnuplot Version 6.0.3 Release Notes
>                 ===================================
> 
> This is the third incremental release for gnuplot stable version 6.0.
> It contains several new features and improvements back-ported from the
> development version.
> 
> NEW (backported from development version)
> -----------------------------------------
> 
> * NEW    "contourfill {at base} {fs {no}border}"
> * NEW    "save changes <filename>"
>          This variant saves only the differences between the current program
>          state and the state at the start of the session.
> * NEW    "plot <data> ... if (filter_condition)"
>          Input lines of data that satisfy the if condition are processed as usual.
>          Lines that fail are essentially ignored.
> * NEW    backport watchpoint improvements from 6.1
>          Each watch target can have its own label, generated by a user function.
>          Any real-valued function is legal as a watchpoint target.
>          Current x, y, and z values are available inside a watchpoint target function.
>          Watchpoints are possible for splot in "set view map" projection.
>          See
>             * https://gnuplot.info/demo_6.0/watch_contours.html
> * NEW    Continued work on multiplot replot and mousing
> 
> CHANGES
> -------
> 
> * CHANGE 3D polygon objects can have per-object fill border properties.
>          The restriction that all 3D polygons share a single set of
>          properties from "set pm3d" remains true for "splot with polygons".
> * CHANGE The configuration option --with-wx-multithreaded has been removed.
>          The multi-thread code has not worked under linux for quite a while.
>          This change does not affect the Windows version of the wxt terminal,
> * CHANGE "with hsteps" takes default width from "set boxwidth".
> * CHANGE column(0) returns an integer (not complex) value
> * CHANGE win: dll function loading altered for compatibility with gcc15
> 
> FIXES
> -----
> 
> * FIX    Support for combined hidden3d + pm3d depthorder back-ported from 6.1
>          This allows placing contours on a depth-sorted pm3d surface
> * FIX    qt: opaque key caused incorrect interactive toggling of final plot
> * FIX    6.0.2 regression in "splot ... using 1:2:3:4 lc palette"
> * FIX    placement of category labels along x-axis of boxplots
> * FIX    qt, cairo: "set colorbox invert" produced empty colorbox
> * FIX    placement of minor tics along logscale axis with narrow range
> * FIX    OK to have missing corners in an image from a sparse matrix
> * FIX    error handling for various corner cases involving function blocks
>          
> 
> KNOWN ISSUES
> ------------
> 
> - Redefining a global array variable inside a user function or function block
>   may lead to memory corruption and/or a program crash.  The development version
>   now handles this cleanly, but the necessary framework has not yet been 
>   back-ported to verion 6.0.  The current version may issue the confusing error
>   message "non-numeric array index" and leave the corrupted array in place.
> 
> - Font handling by the cairo/pango libraries supporting some gnuplot terminals
>   (pdf, png, wxt, ...) on both Windows and MacOS are sensitive to the
>   enviromental variable PANGOCAIRO_BACKEND.  If you are having font problems,
>   try setting this to
>         PANGOCAIRO_BACKEND=fc
> 
> - Support for replot and pan/zoom mouse operations in multiplot mode is still
>   incomplete. Expect further improvement in subsequent releases.
> 
> - TeXLive2024 pdflatex does not like some of the UTF-8 characters in the user manual.
>   The distribution includes a pre-built copy of gnuplot.pdf but if you want
>   to rebuild it from the source in docs/gnuplot.doc please use lualatex instead.
>   You can either replace the definition PDFLATEX=pdflatex with PDFLATEX=lualatex
>   in the Makefile or provide this in the environment during configuration
>         PDFLATEX=lualatex ./configure
> 
> Gnuplot development is tracked in a git repository on SourceForge.
> You can generate a complete history of changes using "git log"
> after downloading:
> 
> <pre>
>     git clone -b branch-6-0-stable git://git.code.sf.net/p/gnuplot/gnuplot-main
>     git log
> </pre>
> 
> Release Notes date:  03 June 2025
> 
> 
> 
> -- 
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>