http://blog.gmane.org/gmane.comp.lang.fortress.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.fortress.general/867 <pre>Hi All, I am surveying the features of Fortress with other HPCS languages as part of my research work. I got unclear with the idea of Regions as I thought it would be an abstraction to represent the place that the computation occur, but the Fortress language specification mentions a different idea than that. So I would appreciate if some clarification of this could be provided or some pointers to a good explanation. Thank you, Saliya _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Saliya Ekanayake 2011-05-02T23:24:03 http://permalink.gmane.org/gmane.comp.lang.fortress.general/866 <pre>Sorry for delay in replying; I'm catching up on old email. Thanks for reporting these very interesting results. There are actually multiple implementations of List for Fortress (that's one of the goals of Fortress: to support multiple implementations of the same API). If you look in the source-code repository in directory Library, you will find both List.fss and PureList.fss . The comments near the front may be of interest to you. Briefly, List.fss uses an array-based implementation, whereas PureList implements finger trees, a rather complicated self-balancing tree structure. --Guy On Mar 1, 2011, at 11:32 AM, Michael Barker wrote: _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Guy Steele 2011-04-25T21:29:18 http://permalink.gmane.org/gmane.comp.lang.fortress.general/865 <pre> Turns out, non-java.net-users can subscribe (or be subscribed) to java.net email lists, so I'll be automatically transferring according to the following mapping: announce -&gt; announce implementation -&gt; dev language -&gt; users I'll attempt to preserve digest settings, and not double-add anyone who was ambitious enough to move themselves. I hate it when I get autosubscribed to mailing lists, so if anyone is bent out of shape, I completely understand, but I hope this can be regarded as just a transfer. Contributing to the wiki will require some sort of registration, however. and again, the new home of Project Fortress is http://projectfortress.java.net . sources may be accessed read-only with the command hg --config 'web.cacerts=' clone https://www.java.net/hg/projectfortress~sources PF where PF is whatever you want to call the directory, locally. The --config 'web.cacerts=' option causes recent versions of Mercurial (which are very picky about certificates) to ignore the difference between hg.java.net and www.java.net yours, David Chase _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-16T19:50:20 http://permalink.gmane.org/gmane.comp.lang.fortress.general/864 <pre> The machine hosting projectfortress.sun.com should go down at 5pm PDT on Wednesday, and may come back on line at 8am PDT on Friday (it's being moved to another building at the old Sun Menlo Park site; there is no plan for its long-term network connectivity). The source code and recent tickets have been moved, and mailing lists are available there for subscription. The Wiki still needs transferring, and we are working on a home for the blog. see our new home, at http://projectfortress.java.net David _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-15T19:19:19 http://permalink.gmane.org/gmane.comp.lang.fortress.general/863 <pre>David, Dispensing with keeping dependency artefacts in the project filestore in favour of pulling things in from the Maven repository is definitely a good thing. I would suggest investigating Gradle (http://www.gradle.org) to replace Ant or at least switching to Maven. Gradle and, but to a lesser extent, Maven make handling dependencies from the Maven repository -- and indeed elsewhere -- easy. You would then be able to dispense with the jars from the project filestore. An interim would be to use the Maven Ant task to handle the download within an Ant context. It's not as good as switching to Gradle or Maven, but it can work. No problem, a serendipitous adventure. I tend to "hg pull -u" ;-) Compiled successfully. </pre> Russel Winder 2011-03-12T16:50:53 http://permalink.gmane.org/gmane.comp.lang.fortress.general/862 <pre>Russel, You're getting a little ahead of us, since my goal was Monday, but the cause of your problem is that I split out the 3rd party jar files from the repository because - they change rarely - they are large - we hope to move to Maven, which I understand will make pass-by-value unnecessary So on the one hand, you're a bit ahead of me, and on the other, I just tested my plan (separate download), and it doesn't work, because the URL is magic (using cookies and/or referrer, don't know which). So I just now added them locally, tested a build, and committed. Thank you very much for your unintentional beta-testing. "hg pull", "hg up", and it should work . (and I just tested that, end-to-end). David On 2011-03-12, at 5:06 AM, Russel Winder wrote: _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-12T14:23:52 http://permalink.gmane.org/gmane.comp.lang.fortress.general/861 <pre>David, Nice that the repository is now Mercurial and not Subversion, though the announcement didn't point this out ;-) One slight problem. I use the command line: ANT_OPTS="-Xmx1024m -Xss64m" ./ant clean compile on my AMD64 Ubuntu 10.10 box -- the default Ant settings lead to garbage collection thrashing hence the increase in resources to the JVM. This works fine in the Subversion checkout, but fails with: |&gt; ANT_OPTS="-Xmx1024m -Xss64m" ./ant clean compile Buildfile: /home/Checkouts/Mercurial/Fortress/build.xml [taskdef] Could not load definitions from resource scala/tools/ant/antlib.xml. It could not be found. BUILD FAILED /home/Checkouts/Mercurial/Fortress/build.xml:441: taskdef class edu.rice.cs.astgen.AntTask cannot be found using the classloader AntClassLoader[] Total time: 0 seconds in the Mercurial clone. </pre> Russel Winder 2011-03-12T10:06:28 http://permalink.gmane.org/gmane.comp.lang.fortress.general/860 <pre>The new home is: http://projectfortress.java.net/ We're doing this for various reasons. The recent relocation of our facilities and IT equipment requires us to move and consolidate our servers. In the process, Oracle wants us to migrate as much as possible to standard platforms (such as java.net) that are approved and supported by our corporate IT. The fact that the building containing the server was recently sold to Facebook, made this a good time for the change. We are still populating the "project", but the mailing lists have been created and the source repository is in place. We intend for the old site to remain online, till it isn't, and the mailing lists remain active. Write access to the old repository has been disabled. If anyone has outstanding commits, contact me, I am sure I can fix it; the entire old Trac server has been archived in runnable form. NOTE: there's a glitch in the sidebar, probably my fault. If/when you hit missing links there from the Website page, try again from http://java.net/projects/projectfortress yours, David Chase the reluctant webmaster _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-12T02:12:39 http://permalink.gmane.org/gmane.comp.lang.fortress.general/859 <pre>The server running all these things, along with several other servers, will be moved to another building in the near future, and the preparations for this may knock it off the web from time to time. yours, David Chase _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> David Chase 2011-03-08T21:51:53 http://permalink.gmane.org/gmane.comp.lang.fortress.general/858 <pre>Apologies if this is the wrong fourm to discuss this. Hi, I watched the video from the strange loop conference that covered using algebraic properties to construct parallel algorithms, specifically using associativity to build a string splitting algorithm. During a coding dojo a couple of us teamed up to implement the algorithm in Scala as an exercise to explore Scala 2.9's parallel collections. The source code is up on github: https://github.com/mikeb01/jpr11-dojo/blob/master/src/steele/WordState.scala. We ran into some rather interesting results. We had 2 implementations of the algorithm, one that was sequential that used a fold right (the WordState.words method) on the collection of initial WordStates (either a Chunk containing a single character or an empty Segment) and a parallel one (the WordState.wordsParallel method) that uses Scala's wrapper around ParallelArray from the fork/join framework. The 'par' method converts an array into a ParallelArray. I also wrote a simple imperative Java implementation (BruteForce.words). Core 2 Duo laptop, 2 Cores &lt; at &gt; 2.40 GHz == Parallel - opsPerSecond: 6.891798759476223 Sequential - opsPerSecond: 49.813200498132005 Brute Force - opsPerSecond: 1388.888888888889 Intel Xeon Workstation, 8 Cores +HT (16 logical cores) &lt; at &gt; 2.40 GHz == Parallel - opsPerSecond: 120.48192771084338 Sequential - opsPerSecond: 73.26007326007326 Brute Force - opsPerSecond: 1886.7924528301887 I was initially quite surprised that I needed 16 cores to get the parallel implementation close to twice as fast as the sequential one. After some digging, the problem was obvious. My implementation of Segment.assoc(Segment) did not operate in constant time. Scala's default list implementation is immutable and the concatenation operator ':::' works using a copy, which will have O(n) with respect to the length of the list on the left hand side of the operator (the list that must copied). Where as the sequential version using a fold right would always be constant time as was associating a Chunk containing a single char or an empty Segment (on the left hand side) with a Segment (on the right). So the questions are, how does the list implementation in Fortress work? Is it immutable, therefore sharing the same complexity profile as the Scala implementation, unless the concatenation operator could produce a lazily evaluated structure? I.e. it returns a list of partial lists and flattens when evaluated. Is it mutable making the concatenation a simple constant time operation? How does the big (+) operation compare to Scala's 'par' method and use of fork/join ParallelArrays? Is it similar enough to work as a useful investigation of the algorithm? Regards, Michael Barker. _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Michael Barker 2011-03-01T16:32:06 http://permalink.gmane.org/gmane.comp.lang.fortress.general/857 <pre>Has anyone set up a web-based interface to fortify--a page where you can paste code and get back a LaTeX file? It would be useful when using a machine that doesn't have a local fortify install. I know there are web-based LaTeX servers that could go the rest of the way to a pdf or image. Thanks, Damon _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Damon McCormick 2011-02-19T00:36:09 http://permalink.gmane.org/gmane.comp.lang.fortress.general/856 <pre>Thank you! This is very interesting code, and I will read it more closely next week. (It does make me even more enthusiastic about getting the dimensions-and-units part of the language implemented.) It is very nice that you were able to work from the math rather than the C code---that is one of our goals! I notice that the comments are already making use of the Wiki tabular markup; perhaps you would be willing also to put markup around the URLs in the comments. If you enclose them in {{{ }}}, they will be treated verbatim and set in the monospace font. (Maybe eventually the fortify tool will include special URL markup that will result in a hot link.) --Guy On Feb 13, 2011, at 7:50 AM, Francois Retief wrote: _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Guy Steele 2011-02-18T21:45:44 http://permalink.gmane.org/gmane.comp.lang.fortress.general/855 <pre>Hello Fortress developers, I have written up a Fortress implementation of the World Magnetic Model for 2010-2015. (http://www.ngdc.noaa.gov/geomag/WMM). It calculates the field strength of the earth's magnetic field and is wildly used in navigation system. See attached file. This model was chosen because they provide a very nice numerical example which were used to check the results. Most of the formula was taken directly from the technical report, without looking at the C implementation. Only the PlmSchmidt_d1() function was extracted from C code. Fortify tool can process most the code. The urls in the comments seems to cause problems because it tries to create escape characters which later cause LaTeX to break. Anyway, thought you might like it. Feedback is welcome. Cheers Francois component geomag export Executable (* * This is an example of the World Magnetic Model for 2010-2015. * Reference: http://www.ngdc.noaa.gov/geomag/WMM/DoDWMM.shtml *) run() = do println "High-precision numerical example of the WMM2010 model ..." (* * Reference: * [1] "Section 1.5: MODEL EQUATIONS NUMERICAL EXAMPLE", * The US/UK World Magnetic Model for 2010-2015, Technical Report, * http://www.ngdc.noaa.gov/geomag/WMM/data/WMM2010/WMM2010_Report.pdf *) (* High-precision numerical example: * ||-------------------------------------------------|| * || Time || 2012.5000 0000 || yr || * || Height-above-Ellipsoid || 100.0000 0000 || km || * || Latitude || -80.0000 0000 || deg || * || Longitude || 240.0000 0000 || deg || * ||-------------------------------------------------|| *) date = 2012.5 (*) years lat = -80 (*) degrees lon = 240 (*) degrees alt = 100 (*) km geomagnetic(date,lat,lon,alt) (* * ||----------------------------------------------|| * || t || 2012.50000 00000 || yr || * || lambda || 4.18879 02048 || rad || * || phi || -1.39626 34016 || rad || * || h || 1 00000.00000 00000 || m || * || phi-prime || -1.39512 89589 || rad || * || r || 64 57402.34844 73705 || m || * || g(1,0,t) || -29467.60000 00000 || nT || * || g(1,1,t) || -1545.05000 00000 || nT || * || g(2,0,t) || -2426.85000 00000 || nT || * || g(2,1,t) || 3015.10000 00000 || nT || * || g(2,2,t) || 1673.35000 00000 || nT || * || h(1,0,t) || 0.00000 00000 || nT || * || h(1,1,t) || 4879.65000 00000 || nT || * || h(2,0,t) || 0.00000 00000 || nT || * || h(2,1,t) || -2763.95000 00000 || nT || * || h(2,2,t) || -605.60000 00000 || nT || * || Xprime || 5478.08914 74225 || nT || * || Yprime || 14765.37032 43050 || nT || * || Zprime || -50632.17770 56324 || nT || * || Xprime-dot || 20.58517 51801 || nT/yr || * || Yprime-dot || 1.02725 92716 || nT/yr || * || Zprime-dot || 83.50809 72670 || nT/yr || * || X || 5535.52491 48687 || nT || * || Y || 14765.37032 43050 || nT || * || Z || -50625.93054 78794 || nT || * || Xdot || 20.49042 68023 || nT/yr || * || Ydot || 1.02725 92716 || nT/yr || * || Zdot || 83.53139 62281 || nT/yr || * || F || 53024.92848 40226 || nT || * || H || 15768.89967 29956 || nT || * || D || 1.21211 40681 || rad || * || I || -1.26884 21543 || rad || * || Fdot || -77.32705 44552 || nT/yr || * || Hdot || 8.15485 76192 || nT/yr || * || Ddot || -0.00119 38570 || rad/yr || * || Idot || 0.00061 53148 || rad/yr || * ||----------------------------------------------|| *) println "Compare these values with the examples in the code comments." end geomagnetic(date:RR64, lat:RR64, lon:RR64, alt:RR64) = do (* * Reference: * [1] "Section 1.2: RELEVANT MODEL EQUATIONS", * The US/UK World Magnetic Model for 2010-2015, Technical Report, * http://www.ngdc.noaa.gov/geomag/WMM/data/WMM2010/WMM2010_Report.pdf *) (* input variables *) println (date,lat,lon,alt) (*) in years, degrees and kilometers (* (lat,lon,alt) is geodetic coordinates on WGS84 ellipsoid *) (* some useful constants *) pi = acos(-1.0) (* read the magnetic model coefficients from file *) (nmax,gnm,hnm,gnm_dot,hnm_dot,a,t0) = readMagneticModel() (* Set up functions that interpolate coefficients *) G_nm(n:ZZ32,m:ZZ32,t:RR64):RR64 requires { 0 &lt;= m &lt;= n &lt;= nmax } = do k = PlmIndex(n,m) gnm[k] + (t - t0) gnm_dot[k] end H_nm(n:ZZ32,m:ZZ32,t:RR64):RR64 requires { 0 &lt;= m &lt;= n &lt;= nmax } = do k = PlmIndex(n,m) hnm[k] + (t - t0) hnm_dot[k] end G_dot_nm(n:ZZ32,m:ZZ32,t:RR64):RR64 requires { 0 &lt;= m &lt;= n &lt;= nmax } = gnm_dot[PlmIndex(n,m)] H_dot_nm(n:ZZ32,m:ZZ32,t:RR64):RR64 requires { 0 &lt;= m &lt;= n &lt;= nmax } = hnm_dot[PlmIndex(n,m)] (* convert input variables to correct units *) (t, phi,lamda,h) = (date, lat pi/180, lon pi/180, alt 1000) (*) in years, radians, radians and meters (* (phi,lamda,h) is geodetic coordinates on WGS84 ellipsoid *) println "(t,lamda,phi,h) = "(t,lamda,phi,h) (* Step 1: convert to spherical geocentric coordinates *) (* semi-major axis (A) of the earth *) A = 6378137 (*) meters (* reciprocal flattening (1/f) of the earth *) f = 1/298.257223563 (* eccentricity squared (e^2) *) e2 = f(2-f) (* radius of East-West curvature (R_c) *) R_c = A/(SQRT(1 - e2 (sin phi)^2)) p = (R_c + h) cos phi z = (R_c(1 - e2) + h) sin phi r = SQRT(p^2 + z^2) phi_prime = asin(z/r) (* geodetic coordinates: (lamda, phi, h) = (longitude, latitude, altitude) *) (* spherical geocentric coordinates: (lamda, phi_prime, r) *) println "(lamda,phi-prime,r) = "(lamda,phi_prime,r) (* show some coefficients for comparison with example values *) println "Gnm: "(G_nm(1,0,t), G_nm(1,1,t), G_nm(2,0,t), G_nm(2,1,t), G_nm(2,2,t)) println "Hnm: "(H_nm(1,0,t), H_nm(1,1,t), H_nm(2,0,t), H_nm(2,1,t), H_nm(2,2,t)) (* Step 2: Calculate the Schmidt normalized associated Legendre values *) (pp,qq) = PlmSchmidt_d1(nmax, sin phi_prime) P_breve_nm(n:ZZ32,m:ZZ32,mu:RR64) requires { 0 &lt;= m &lt;= n &lt;= nmax, |mu| &lt;= 1.0 } = pp[PlmIndex(n,m)] dP_breve_nm(n:ZZ32,m:ZZ32,mu:RR64) requires { 0 &lt;= m &lt;= n &lt;= nmax, |mu| &lt;= 1.0 } = qq[PlmIndex(n,m)] (* Step 3: Compute the field vector components (equations 10,11,12) *) N = nmax X_prime = -(SUM[n&lt;-1:N]( (a/r)^(n+2) (SUM[m&lt;-0:n]( (G_nm(n,m,t) cos(m lamda) + H_nm(n,m,t) sin(m lamda)) dP_breve_nm(n,m,sin phi_prime) )))) Y_prime = (1/cos(phi_prime)) (SUM[n&lt;-1:N]( (a/r)^(n+2) (SUM[m&lt;-0:n](m((G_nm(n,m,t) sin(m lamda)) - (H_nm(n,m,t) cos(m lamda))) P_breve_nm(n,m,sin phi_prime) )))) Z_prime = -(SUM[n&lt;-1:N]( (n+1) (a/r)^(n+2) (SUM[m&lt;-0:n]( (G_nm(n,m,t) cos(m lamda) + H_nm(n,m,t) sin(m lamda)) P_breve_nm(n,m,sin phi_prime) )))) println "(Xprime,Yprime,Zprime) = "(X_prime, Y_prime, Z_prime) (* Compute the secular variation of the field components (equastions 13,14,15) *) X_dot_prime = -(SUM[n&lt;-1:N]( (a/r)^(n+2) (SUM[m&lt;-0:n]( (G_dot_nm(n,m,t) cos(m lamda) + H_dot_nm(n,m,t) sin(m lamda)) dP_breve_nm(n,m,sin phi_prime) )))) Y_dot_prime = 1/cos(phi_prime) (SUM[n&lt;-1:N]( (a/r)^(n+2) (SUM[m&lt;-0:n]( m (G_dot_nm(n,m,t) sin(m lamda) - H_dot_nm(n,m,t) cos(m lamda)) P_breve_nm(n,m,sin phi_prime) )))) Z_dot_prime = -(SUM[n&lt;-1:N]( (n+1) (a/r)^(n+2) (SUM[m&lt;-0:n]( (G_dot_nm(n,m,t) cos(m lamda) + H_dot_nm(n,m,t) sin(m lamda)) P_breve_nm(n,m,sin phi_prime) )))) println "(Xprime-dot,Yprime-dot,Zprime-dot) = "(X_dot_prime, Y_dot_prime, Z_dot_prime) (* Step 4: rotate geocentric magnetic field vector components into ellipsoidal reference frame *) X = X_prime cos(phi_prime - phi) - Z_prime sin(phi_prime - phi) (*) nT Y = Y_prime (*) nT Z = X_prime sin(phi_prime - phi) + Z_prime cos(phi_prime - phi) (*) nT println "(X,Y,Z) = "(X,Y,Z) X_dot = X_dot_prime cos(phi_prime - phi) - Z_dot_prime sin(phi_prime - phi) (*) nT per year Y_dot = Y_dot_prime (*) nT per year Z_dot = X_dot_prime sin(phi_prime - phi) + Z_dot_prime cos(phi_prime - phi) (*) nT per year println "(Xdot,Ydot,Zdot) = "(X_dot,Y_dot,Z_dot) (* Step 5: Compute magnetic elements H,F,I and D from orthogonal componants *) F = SQRT(X^2 + Y^2 + Z^2) (*) nT H = SQRT(X^2 + Y^2) (*) nT I = atan2(Z,H) (*) radians D = atan2(Y,X) (*) radians println "(F,H,D,I) = "(F,H,D,I) F_dot = (X DOT X_dot + Y DOT Y_dot + Z DOT Z_dot)/F (*) nT per year H_dot = (X DOT X_dot + Y DOT Y_dot)/H (*) nT per year I_dot = (H DOT Z_dot - Z DOT H_dot)/(F^2) (*) radians per year D_dot = (X DOT Y_dot - Y DOT X_dot)/(H^2) (*) radians per year println "(Fdot,Hdot,Ddot,Idot) = " (F_dot,H_dot,D_dot,I_dot) (X,Y,Z, H,I,D, F) end readMagneticModel(): (ZZ32,Array[\RR64,ZZ32\],Array[\RR64,ZZ32\],Array[\RR64,ZZ32\],Array[\RR64,ZZ32\],RR64) = do (* * Reference: * [1] "Section 1.3: THE WMM2010 COEFFICIENTS", * The US/UK World Magnetic Model for 2010-2015, Technical Report, * http://www.ngdc.noaa.gov/geomag/WMM/data/WMM2010/WMM2010_Report.pdf *) (*) Coefficients as read from WMM.COF file (* n m g h g_dot h_dot *) wmm2010data: RR64[90,6] = [ 1 0 -29496.6 0.0 11.6 0.0 1 1 -1586.3 4944.4 16.5 -25.9 2 0 -2396.6 0.0 -12.1 0.0 2 1 3026.1 -2707.7 -4.4 -22.5 2 2 1668.6 -576.1 1.9 -11.8 3 0 1340.1 0.0 0.4 0.0 3 1 -2326.2 -160.2 -4.1 7.3 3 2 1231.9 251.9 -2.9 -3.9 3 3 634.0 -536.6 -7.7 -2.6 4 0 912.6 0.0 -1.8 0.0 4 1 808.9 286.4 2.3 1.1 4 2 166.7 -211.2 -8.7 2.7 4 3 -357.1 164.3 4.6 3.9 4 4 89.4 -309.1 -2.1 -0.8 5 0 -230.9 0.0 -1.0 0.0 5 1 357.2 44.6 0.6 0.4 5 2 200.3 188.9 -1.8 1.8 5 3 -141.1 -118.2 -1.0 1.2 5 4 -163.0 0.0 0.9 4.0 5 5 -7.8 100.9 1.0 -0.6 6 0 72.8 0.0 -0.2 0.0 6 1 68.6 -20.8 -0.2 -0.2 6 2 76.0 44.1 -0.1 -2.1 6 3 -141.4 61.5 2.0 -0.4 6 4 -22.8 -66.3 -1.7 -0.6 6 5 13.2 3.1 -0.3 0.5 6 6 -77.9 55.0 1.7 0.9 7 0 80.5 0.0 0.1 0.0 7 1 -75.1 -57.9 -0.1 0.7 7 2 -4.7 -21.1 -0.6 0.3 7 3 45.3 6.5 1.3 -0.1 7 4 13.9 24.9 0.4 -0.1 7 5 10.4 7.0 0.3 -0.8 7 6 1.7 -27.7 -0.7 -0.3 7 7 4.9 -3.3 0.6 0.3 8 0 24.4 0.0 -0.1 0.0 8 1 8.1 11.0 0.1 -0.1 8 2 -14.5 -20.0 -0.6 0.2 8 3 -5.6 11.9 0.2 0.4 8 4 -19.3 -17.4 -0.2 0.4 8 5 11.5 16.7 0.3 0.1 8 6 10.9 7.0 0.3 -0.1 8 7 -14.1 -10.8 -0.6 0.4 8 8 -3.7 1.7 0.2 0.3 9 0 5.4 0.0 0.0 0.0 9 1 9.4 -20.5 -0.1 0.0 9 2 3.4 11.5 0.0 -0.2 9 3 -5.2 12.8 0.3 0.0 9 4 3.1 -7.2 -0.4 -0.1 9 5 -12.4 -7.4 -0.3 0.1 9 6 -0.7 8.0 0.1 0.0 9 7 8.4 2.1 -0.1 -0.2 9 8 -8.5 -6.1 -0.4 0.3 9 9 -10.1 7.0 -0.2 0.2 10 0 -2.0 0.0 0.0 0.0 10 1 -6.3 2.8 0.0 0.1 10 2 0.9 -0.1 -0.1 -0.1 10 3 -1.1 4.7 0.2 0.0 10 4 -0.2 4.4 0.0 -0.1 10 5 2.5 -7.2 -0.1 -0.1 10 6 -0.3 -1.0 -0.2 0.0 10 7 2.2 -3.9 0.0 -0.1 10 8 3.1 -2.0 -0.1 -0.2 10 9 -1.0 -2.0 -0.2 0.0 10 10 -2.8 -8.3 -0.2 -0.1 11 0 3.0 0.0 0.0 0.0 11 1 -1.5 0.2 0.0 0.0 11 2 -2.1 1.7 0.0 0.1 11 3 1.7 -0.6 0.1 0.0 11 4 -0.5 -1.8 0.0 0.1 11 5 0.5 0.9 0.0 0.0 11 6 -0.8 -0.4 0.0 0.1 11 7 0.4 -2.5 0.0 0.0 11 8 1.8 -1.3 0.0 -0.1 11 9 0.1 -2.1 0.0 -0.1 11 10 0.7 -1.9 -0.1 0.0 11 11 3.8 -1.8 0.0 -0.1 12 0 -2.2 0.0 0.0 0.0 12 1 -0.2 -0.9 0.0 0.0 12 2 0.3 0.3 0.1 0.0 12 3 1.0 2.1 0.1 0.0 12 4 -0.6 -2.5 -0.1 0.0 12 5 0.9 0.5 0.0 0.0 12 6 -0.1 0.6 0.0 0.1 12 7 0.5 0.0 0.0 0.0 12 8 -0.4 0.1 0.0 0.0 12 9 -0.4 0.3 0.0 0.0 12 10 0.2 -0.9 0.0 0.0 12 11 -0.8 -0.2 -0.1 0.0 12 12 0.0 0.9 0.1 0.0 ] (* Note: H and H_dot is undefined for m = 0 *) nmax = 12 sdim = PlmIndex(nmax+1,0) G = array[\RR64\](sdim) H = array[\RR64\](sdim) G_dot = array[\RR64\](sdim) H_dot = array[\RR64\](sdim) (* Not used, but there to fill our packed triangle matrix *) G[0] := 0.0 G[0] := 0.0 G_dot[0] := 0.0 H_dot[0] := 0.0 (* populate our packed triangle matrix *) for row &lt;- 0#90 do k = PlmIndex( wmm2010data[row,0], wmm2010data[row,1] ) G[k] := wmm2010data[row,2] H[k] := wmm2010data[row,3] G_dot[k] := wmm2010data[row,4] H_dot[k] := wmm2010data[row,5] end (* geomagnetic reference radius of the model *) a = 6371200 (*) meters (* base date of the model *) t0 = 2010.0 (*) years (nmax, G, H, G_dot, H_dot, a, t0) end PlmIndex(l: ZZ32, m: ZZ32): ZZ32 requires { 0 &lt;= m &lt;= l } = l(l+1)/2 + m PlmSchmidt_d1(l_max: ZZ32, z: RR64): (Array[\RR64,ZZ32\], Array[\RR64,ZZ32\]) requires { 0 &lt;= l_max &lt;= 16, |z| &lt;= 1 } = do p_size: ZZ32 = PlmIndex(l_max+1, 0) var p: Array[\RR64,ZZ32\] var dp: Array[\RR64,ZZ32\] var schmidtQuasiNorm: Array[\RR64,ZZ32\] do mu = SQRT((1.0-z)(1.0+z)) (* Compute the Gauss-normalized associated Legendre functions *) p := array[\RR64\](p_size) dp := array[\RR64\](p_size) p[0] := 1.0 dp[0] := 0.0 for n &lt;- seq(1:l_max), m &lt;- seq(0:n) do index = PlmIndex(n,m) if n = m then index1 = PlmIndex(n-1,m-1) p[index] := mu p[index1] dp[index] := mu dp[index1] + z p[index1] elif n = 1 AND m = 0 then index1 = PlmIndex(n-1,m) p[index] := z p[index1] dp[index] := z dp[index1] - mu p[index1] elif n &gt; 1 AND n =/= m then index2 = PlmIndex(n-1,m) if m &gt; (n-2) then p[index] := z p[index2] dp[index] := z dp[index2] - mu p[index2] else index1 = PlmIndex(n-2,m) k = ((n-1)^2 - m^2) / ((2 n - 1)(2 n - 3)) p[index] := z p[index2] - k p[index1] dp[index] := z dp[index2] - mu p[index2] - k dp[index1] end else fail "should never happen" end end also do schmidtQuasiNorm := array[\RR64\](p_size) (* * Compute the ration between the Gauss-normalized associated Legendre * functions and the Schmidt quasi-normalized version. This is equivalent * to SQRT((m==0?1:2)*(n-m)!/(n+m!))*(2n-1)!!/(n-m)! *) schmidtQuasiNorm[0] := 1.0 for n &lt;- seq(1:l_max), m &lt;- seq(0:n) do schmidtQuasiNorm[PlmIndex(n,m)] := if m = 0 then schmidtQuasiNorm[PlmIndex(n-1,0)] (2 n - 1) / n else schmidtQuasiNorm[PlmIndex(n,m-1)] (SQRT(((n - m + 1)(if m = 1 then 2 else 1 end)) / (n + m))) end end end (* * Converts the Gauss-normalized associated Legendre * functions to the Schmidt quasi-normalized version using pre-computed * relation stored in the variable schmidtQuasiNorm *) for n &lt;- 1:l_max, m &lt;- 0:n do index = PlmIndex(n,m) p[index] := schmidtQuasiNorm[index] p[index] dp[index] := - schmidtQuasiNorm[index] dp[index] (* The sign is changed since the new WMM routines * use derivative with respect to latitude instead * of co-latitude *) end (p,dp) end end (* component geomag *) _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Francois Retief 2011-02-13T12:50:11 http://permalink.gmane.org/gmane.comp.lang.fortress.general/854 <pre>I know this is not very constructive, but I'll jump on the opportunity to point out that this proposal regarding nat parameters can be considered a special case that could be extended to type parameters, making it similar to C++ partial template specialization. I think someone on this list already had such a suggestion (for type parameters). </pre> Sorin Zsejki 2011-02-03T21:10:33 http://permalink.gmane.org/gmane.comp.lang.fortress.general/853 <pre> On Feb 3, 2011, at 2:59 PM, Diane Lee wrote: Yep. One approach would be to limit ourselves to linear equalities and inequalities, and then hit the problem with the sledgehammer of a general-purpose integer linear programming solver. Two declarations exclude each other if, when you toss all their constraints into a single pot, there is no solution to the combined set of constraints. One could also contemplate detecting when one declaration is more specific than another, but that might require a nonlinear solver (or worse). Certainly simple cases could be supported easily. --Guy _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Guy Steele 2011-02-03T20:21:52 http://permalink.gmane.org/gmane.comp.lang.fortress.general/852 <pre> On Jan 31, 2011, at 11:47 PM, Guy Steele wrote: I guess I should have specified n &gt; 0. What I meant here is that we want an object of type Cons[[S,n &gt; 0]] to be allowed wherever List[[S,n &gt; 0]] is required (and we have done that by declaring Cons[[S, n&gt;0]] extends List[[S,n]]), but at line 10 we also want any object of type List[[S, n &gt; 0]] to be usable as you would a Cons[[S, n]], i.e. to have the same methods. Simply put, we want List[[S,n &gt; 0]] and Cons[[S, n&gt;0]] to have the same interface, visible statically. Furthermore, we want dynamic method dispatch to behave the same for both types. (We also want the same of Empty[[S]] and List[[S,0]] but in this example Empty[[S]] didn't have any methods that List[[S,0]] didn't have so we didn't see any problems. ) I wanted to argue that with this kind of relationship, there isn't any reason that they can not go by the same name. I totally agree, that would be much nicer. I was just suggesting a ready-out-of-the-box solution -- we only need to check arguments against each constraint in order. Doing it like method dispatch would require extra sophistication in the typechecker to check that the nat constraints in each definition named List[[T, nat n]] are disjoint. It's not obvious to me how this would be done/ if it would be easy. This should be valid: Foo[[nat m=0, nat n &gt; 0]] Foo[[nat m=0, nat n = 0]] Foo[[nat m&gt;0, nat n = 0]] Can say disjoint as long as pairwise definitions are disjoint in some parameter. Also need to consider multiple kinds of constraints on one parameter... this problem may overlap with nat parameter constraint solving? I am not going to look any further into this for now. Diane _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Diane Lee 2011-02-03T19:59:28 http://permalink.gmane.org/gmane.comp.lang.fortress.general/851 <pre>On Tue, Feb 1, 2011 at 5:52 PM, Victor Luchangco &lt;victor.luchangco&lt; at &gt;oracle.com&gt; wrote: Agreed, the comprises clause is definitely preferable. I did want to note that with appropriate type declarations, lines 9-10 would typecheck---it's just that they won't satisfy the abstract method declaration in the superclass unless there's a comprises clause AND the right set of comprises checking in place. It looks like there may be a middle ground here between "full-on conditional extension" and "no checking" that would permit the zip example, but might make it tricky to type check stuff like the declaration of adjacentPairs without inserting a dynamic check. I did also want to point out that falling back to dynamic checking is an option in these cases---we can still hang on to *some* static checking even if the type checker isn't powerful enough to catch *every* possible static invariant. -Jan _______________________________________________ language mailing list language&lt; at &gt;projectfortress.sun.com http://projectfortress.sun.com/mailman/listinfo/language </pre> Jan-Willem Maessen 2011-02-02T19:25:02 http://permalink.gmane.org/gmane.comp.lang.fortress.general/850 <pre> On Feb 1, 2011, at 2:48 PM, Jan-Willem Maessen wrote: Why should we want, however, to work around the absence of a comprises clause? Wouldn't it be better to include the comprises clause? Yes, I agree with this, and if we had where clauses to the full extent that we've considered (assuming we can get them to work), then we could do this. But this involves something like the conditional extension that Guy has long suggested, and we have never, to my recollection, worked out the details that such expressivity would imply. - Victor _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Victor Luchangco 2011-02-01T22:52:37 http://permalink.gmane.org/gmane.comp.lang.fortress.general/849 <pre>I've been thinking about how this corresponds to other type systems that let us encode the same kinds of invariants, and how I encoded the invariants in PureList. After whacking at it for about 5 minutes, I realized that expressing "I take another argument that has the same size as me" is difficult at best, and that I ended up throwing in methods that could (statically) return bottom but which (dynamically) never would, effectively moving some of the checking to run time when it was too hard at compile time. This basically meant I'd write a declaration like: 8: object Cons[[T, nat n &gt; 0]](fst:T, rst:List[[T, n-1]]) extends List[[T, n]] 9: zip[[S]](other: Cons[[S,n]]) :Cons[[(T,S), n]] 10: = Cons[[(T,S), n]]((fst, other.fst), zip(rst, other.rst)) 10a: zip[[S]](other: List[[S,n]]): List[[(T,S), n]] = throw "Impossible!" 11: end Effectively I'm working around the absence of a comprises clause by using maximally-specific types and then inserting a catch-all overloading. (Note: I can't say for sure if this'll work in the latest generic-methods-with-overloading story, but it used to, and should give you a general idea at least). We can imagine using the following modified version of your comprises clause (using n &gt; 0) to get rid of line 10a: trait List[[T, nat n]] comprises { Empty[[T]] where n=0, Cons[[T, n]] where n &gt; 0} Now we ought to be able to conclude that the declaration in my line 9 is sufficient: when n &gt; 0, List[[T,n]] comprises Cons[[T,n]]. But note that I had to use the more specific types in the method declaration to get the body to typecheck correctly. Note also that if we remove the declaration of zip in the superclass, and give more specific declarations in terms of Empty and Cons in the subclasses, it works without fancy footwork, but we can't zip a List[[T,n]] anymore. The real thing that's wanted here, it seems, is not List[[T, 0]] and List[[T, n+1]] as separate extendable types -- though that might be nice for the present application, it's not at all obvious it solves the general problem. Instead, it seems like the real problem is to somehow declare that "List[[T, n]] has method Fst() for n &gt; 0". For example, imagine writing the "adjacentPairs" and "adjacentTriples" methods, that return adjacent pairs and triples of elements in the list. Without any of the numbers, and improvising the nat constraints wildly: adjacentPairs[[S, nat n &lt; 2]](xs : List[[S,n]]): List[[S, 0]] = Empty[[S]] adjacentPairs[[S, nat n &gt; 1]](xs : List[[S,n]]): List[[S, n-1]] = Cons((xs.fst, xs.rst.fst), xs.rst) Now, how would you express adjacentPairs as a method of List? My feeling is that it's pretty analogous to zip, and any solution that works for one ought to work for the other. But notice "my" solution for zip, above, doesn't cope particularly well with this either. I can increase the number of subtypes, of course, but that's pretty icky and doesn't really scale: object Empty[[T]] extends List[[T,0]] object Last[[T]] extends List[[T,1]] object Cons[[T, nat n &gt; 1]] extends List[[T, n]] Ultimately any type system is going to have expressivity limits, after which you have to check invariants at run time rather than expressing them at compile time. This seems to be right up against the edge of what Fortress can express, and the question becomes what can be bent to fit and what just doesn't work. -Jan-Willem Maessen _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Jan-Willem Maessen 2011-02-01T19:48:28 http://permalink.gmane.org/gmane.comp.lang.fortress.general/848 <pre> On Jan 31, 2011, at 6:07 PM, Diane Lee wrote: Assuming that List[\ T, nat n \] should really have a comprises { Empty[\T\], Cons[\T,n\] } clause, we could also avoid the type error by making using Cons[\T,n\] as the type of other in the Cons declaration. This requires type checking to be a bit more sophisticated, because it must recognize that the only immediate subtype of List[\T,n\] when n &gt; 0 is Cons[\T,n\], but I think we would want such sophistication in any case. That said, it might be nice to allow the declaration with List[\T,n\] as you have it, and the idea of cutting out the "middle men" of Empty and Cons has some independent attraction. (I agree with Guy's suggestion that the dispatch should be like method dispatch (i.e., without regard to order, but requiring the definitions to satisfy the overloading rules) rather than case/typecase.) - Victor _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Victor Luchangco 2011-02-01T06:09:28 http://permalink.gmane.org/gmane.comp.lang.fortress.general/847 <pre>Thanks for explaining this exercise. I followed it all except for once sentence (see below). On Jan 31, 2011, at 6:07 PM, Diane Lee wrote: Is this last sentence right? Um, we've tried real hard in all parts of the language not to make the order of top-level declarations matter. Rather, it should be like method dispatch. All the rest of this message makes sense and suggests an interesting direction. --Guy _______________________________________________ language mailing list language-EFxYrSp25jGFLKEeoBv638bH8sH8CGPj&lt; at &gt;public.gmane.org http://projectfortress.sun.com/mailman/listinfo/language </pre> Guy Steele 2011-02-01T05:47:58 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.fortress.general