You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(58) 
_{Nov}
(95) 
_{Dec}
(55) 

2002 
_{Jan}
(205) 
_{Feb}
(106) 
_{Mar}
(36) 
_{Apr}
(25) 
_{May}
(34) 
_{Jun}
(36) 
_{Jul}
(161) 
_{Aug}
(66) 
_{Sep}
(100) 
_{Oct}
(62) 
_{Nov}
(77) 
_{Dec}
(172) 
2003 
_{Jan}
(101) 
_{Feb}
(202) 
_{Mar}
(191) 
_{Apr}
(97) 
_{May}
(27) 
_{Jun}
(21) 
_{Jul}
(16) 
_{Aug}
(55) 
_{Sep}
(155) 
_{Oct}
(166) 
_{Nov}
(19) 
_{Dec}
(134) 
2004 
_{Jan}
(569) 
_{Feb}
(367) 
_{Mar}
(81) 
_{Apr}
(62) 
_{May}
(124) 
_{Jun}
(77) 
_{Jul}
(85) 
_{Aug}
(80) 
_{Sep}
(66) 
_{Oct}
(42) 
_{Nov}
(20) 
_{Dec}
(133) 
2005 
_{Jan}
(192) 
_{Feb}
(143) 
_{Mar}
(183) 
_{Apr}
(128) 
_{May}
(136) 
_{Jun}
(18) 
_{Jul}
(22) 
_{Aug}
(33) 
_{Sep}
(20) 
_{Oct}
(12) 
_{Nov}
(80) 
_{Dec}
(44) 
2006 
_{Jan}
(42) 
_{Feb}
(38) 
_{Mar}
(17) 
_{Apr}
(112) 
_{May}
(220) 
_{Jun}
(67) 
_{Jul}
(96) 
_{Aug}
(214) 
_{Sep}
(104) 
_{Oct}
(67) 
_{Nov}
(150) 
_{Dec}
(103) 
2007 
_{Jan}
(111) 
_{Feb}
(50) 
_{Mar}
(113) 
_{Apr}
(19) 
_{May}
(32) 
_{Jun}
(34) 
_{Jul}
(61) 
_{Aug}
(103) 
_{Sep}
(75) 
_{Oct}
(99) 
_{Nov}
(102) 
_{Dec}
(40) 
2008 
_{Jan}
(86) 
_{Feb}
(56) 
_{Mar}
(104) 
_{Apr}
(50) 
_{May}
(45) 
_{Jun}
(64) 
_{Jul}
(71) 
_{Aug}
(147) 
_{Sep}
(132) 
_{Oct}
(176) 
_{Nov}
(46) 
_{Dec}
(136) 
2009 
_{Jan}
(159) 
_{Feb}
(136) 
_{Mar}
(188) 
_{Apr}
(189) 
_{May}
(166) 
_{Jun}
(97) 
_{Jul}
(160) 
_{Aug}
(235) 
_{Sep}
(163) 
_{Oct}
(46) 
_{Nov}
(99) 
_{Dec}
(54) 
2010 
_{Jan}
(104) 
_{Feb}
(121) 
_{Mar}
(153) 
_{Apr}
(75) 
_{May}
(129) 
_{Jun}
(63) 
_{Jul}
(61) 
_{Aug}
(27) 
_{Sep}
(93) 
_{Oct}
(63) 
_{Nov}
(40) 
_{Dec}
(102) 
2011 
_{Jan}
(52) 
_{Feb}
(26) 
_{Mar}
(61) 
_{Apr}
(27) 
_{May}
(33) 
_{Jun}
(43) 
_{Jul}
(37) 
_{Aug}
(53) 
_{Sep}
(58) 
_{Oct}
(63) 
_{Nov}
(67) 
_{Dec}
(16) 
2012 
_{Jan}
(97) 
_{Feb}
(34) 
_{Mar}
(6) 
_{Apr}
(18) 
_{May}
(32) 
_{Jun}
(9) 
_{Jul}
(17) 
_{Aug}
(78) 
_{Sep}
(24) 
_{Oct}
(101) 
_{Nov}
(31) 
_{Dec}
(7) 
2013 
_{Jan}
(44) 
_{Feb}
(35) 
_{Mar}
(59) 
_{Apr}
(17) 
_{May}
(29) 
_{Jun}
(38) 
_{Jul}
(48) 
_{Aug}
(46) 
_{Sep}
(74) 
_{Oct}
(140) 
_{Nov}
(94) 
_{Dec}
(177) 
2014 
_{Jan}
(94) 
_{Feb}
(74) 
_{Mar}
(75) 
_{Apr}
(63) 
_{May}
(24) 
_{Jun}
(1) 
_{Jul}
(7) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(4) 
2
(3) 
3
(2) 
4
(1) 
5
(4) 
6
(2) 
7
(9) 
8
(3) 
9
(2) 
10
(4) 
11
(7) 
12
(6) 
13
(7) 
14
(15) 
15
(3) 
16
(2) 
17
(3) 
18
(4) 
19
(15) 
20
(1) 
21
(2) 
22
(1) 
23
(1) 
24
(4) 
25

26
(9) 
27
(2) 
28
(6) 
29
(11) 
30

31
(14) 






From: Arjen Markus <arjen.markus@wl...>  20080810 11:24:27

>> On 20080801 22:24+0100 Andrew Ross wrote: >> >> I also noticed the integer(16) and did not like it since in fortran 77 >> at >> least integer*8 would correspond to 64 bits and integer*16 to 128 bits. >> Arjen, do you know about this? >> >>> Can you test again with my fix and see what happens? >> >> The f95 example build errors are gone now. Also, the resulting C and >> f95 >> results agree exactly now. So your change appears to be a good fix >> for the 64bit problem I found. >> > > KIND numbers in Fortran 95 do not have to indicate the number of bytes > (despite the fact that many compilers do use that number to indicate > the KIND). I am not sure why you get a kind 16  I will have to look > into that, but I suspect that the way to generate the KIND number in > CMakeLists.txt is not quite correct (or there is a problem in the > compiler). > > I will look into this one. > I found the cause: z'xxx' returns an integer whose kind is not related to the actual number but is some predefined compilerdependent value. See this little program: program longint integer, parameter :: z7 = kind(z'70000000') integer, parameter :: z8 = kind(z'80000000') write(*,*) "z'0': ",z'0', kind(z'0') write(*,*) "z'70000000': ",z'70000000', kind(z'70000000'), z7 write(*,*) "z'80000000': ",z'80000000', kind(z'80000000'), z8 end program The result on a 32bits PC with some version of gfortran (under Cygwin) is: z'0': 0 8 z'70000000': 1879048192 8 8 z'80000000': 2147483648 8 8 and with some version of g95 (under MinGW): z'0': 0 4 z'70000000': 1879048192 4 4 z'80000000': 2147483648 4 4 So, depending on the compiler, z'xxxx' gives a default integer (g95, this version) or an integer that is larger than that (gfortran; quite possibly the largest integer kind that is supported). If the compiler on a 64bits platform behaves like gfortran in my case, then the result is very likely to be a 16bytes integer. My suggestion is to use: integer, parameter :: plunicode = selected_int_kind( 10 ) This will give a kind number for kinds just large enough to fit a number like 2**32, actually 10**10 will fit too. On most platforms (certainly the popular ones) this leads to a 64bits integer. I have not changed the CMakeLists.txt file yet, because I first want to make sure that this is an acceptable solution. Regards, Arjen 
From: Arjen Markus <arjen.markus@wl...>  20080810 08:18:24

> On 20080805 09:59+0100 Andrew Ross wrote: > >> Alan, >> >> A first initial look at the postscript shows differences even on the >> first page, suggesting perhaps a slightly different random distribution >> of numbers to start with. I've made a few of the constants in the >> example explicitly of kind plflt, including the max / min values for the >> range. This might make a difference. Can you check? If I can elimiate >> these differences it might make a difference to the subsequent pages. If >> not, at least I have narrowed down the options. > > Hi Andrew: > > Your instincts were absolutely right. As the result of your f95 changes > the > f95 and C results for example 21 now agree exactly! You should also make > the corresponding changes in the f77 example (which currently agrees with > the old f95 version done without your recent change). > Hi Andrew, Alan, this is a "gotcha" one easily gets into: In Fortran literal numbers are treated in the precision they appear in, not in the precision of the result: double precision :: x = 1.2, y = 1.2d0 write(*,*) xy will give a number _not_ equal to zero. This is because the literal 1.2 is single precision and the literal 1.2d0 is double precision. So to be sure that the precision is what you want it to be always use _plflt (or d0 in the case of FORTRAN 77). Regards, Arjen 
From: Arjen Markus <arjen.markus@wl...>  20080810 08:07:09

> On 20080801 22:24+0100 Andrew Ross wrote: > > I also noticed the integer(16) and did not like it since in fortran 77 at > least integer*8 would correspond to 64 bits and integer*16 to 128 bits. > Arjen, do you know about this? > >> Can you test again with my fix and see what happens? > > The f95 example build errors are gone now. Also, the resulting C and f95 > results agree exactly now. So your change appears to be a good fix > for the 64bit problem I found. > KIND numbers in Fortran 95 do not have to indicate the number of bytes (despite the fact that many compilers do use that number to indicate the KIND). I am not sure why you get a kind 16  I will have to look into that, but I suspect that the way to generate the KIND number in CMakeLists.txt is not quite correct (or there is a problem in the compiler). I will look into this one. Regards, Arjen 
From: Arjen Markus <arjen.markus@wl...>  20080810 07:56:16

> > I've been working on implementing plgfci and plsfci in the fortran > bindings, starting with f95. Unfortunately fortran does not support > unsigned integers so PLUNICODE has to be cast to an 64 bit integer in > fortran. I've created a plunicode type, similar to plflt, to make this > transparent in fortran 95. The conversion is done in the C code and > current works if C long is 64 bit (ok on most platforms, but not > guaranteed). Ideally I would use int64_t but this is none standard. > > Does anyone have a neater solution to this problem? If not I'll try and > do the same for the f77 bindings. My implementation works fine with > gfortran but I'd be keen to know it is ok with other compilers. Example > 23 tests these functions out. > > I've been banging my head against the wall with these unsigned issues > for several languages. With hindsight it maybe wasn't the best design > decision given the number of languages we support and the number of > those which don't have unsigned integers. It would even be ok if we > didn't use the highest bit since we could just ignore the sign then. > It's a bit late to change things now though. > For Fortran 95 a solution might be to create a userdefined type like: type UNSIGNED integer :: value end type and define appropriate operations for it. That way you can hide the complications in the PLplot library. But it will not solve the problems for FORTRAN 77 (or for other languages that do not support unsigned integers). Could a workaround be to use double precision reals instead? The precision is large enough to hold any 32bits unsigned integer exactly. Regards, Arjen 