Saliya Ekanayake | 3 May 01:24
Picon
Gravatar

Regions Explanation

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@...
http://projectfortress.sun.com/mailman/listinfo/language
David Chase | 16 Mar 20:50
Picon
Favicon

One last (?) Fortress-move announcement


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 -> announce
implementation -> dev
      language -> 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@...
http://projectfortress.sun.com/mailman/listinfo/language

David Chase | 15 Mar 20:19
Picon
Favicon

A reminder -- Fortress repository and mailing lists moved to java.net


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@...
http://projectfortress.sun.com/mailman/listinfo/language

David Chase | 12 Mar 03:12
Picon
Favicon

Project Fortress is moving to Java.net

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@...
http://projectfortress.sun.com/mailman/listinfo/language

David Chase | 8 Mar 22:51
Picon
Favicon

Mailing lists, website, and svn may be intermittently offline in the next two weeks.

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@...
http://projectfortress.sun.com/mailman/listinfo/language

Michael Barker | 1 Mar 17:32
Picon

Parallel String Spitting (from Strange Loop)

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 @ 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) @ 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@...
http://projectfortress.sun.com/mailman/listinfo/language

Damon McCormick | 19 Feb 01:36
Picon

web-based fortify server?

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@...
http://projectfortress.sun.com/mailman/listinfo/language
Francois Retief | 13 Feb 13:50
Picon

Fortress example of WMM2010

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 <= m <= n <= 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 <= m <= n <= 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 <= m <= n <= nmax }
        = gnm_dot[PlmIndex(n,m)]

        H_dot_nm(n:ZZ32,m:ZZ32,t:RR64):RR64
        requires { 0 <= m <= n <= 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 <= m <= n <= nmax, |mu| <= 1.0 }
        = pp[PlmIndex(n,m)]

        dP_breve_nm(n:ZZ32,m:ZZ32,mu:RR64)
        requires { 0 <= m <= n <= nmax, |mu| <= 1.0 }
        = qq[PlmIndex(n,m)]

        (* Step 3: Compute the field vector components (equations 10,11,12) *)

        N = nmax

        X_prime = -(SUM[n<-1:N]( (a/r)^(n+2) (SUM[m<-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<-1:N]( (a/r)^(n+2) (SUM[m<-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<-1:N]( (n+1) (a/r)^(n+2) (SUM[m<-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<-1:N]( (a/r)^(n+2) (SUM[m<-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<-1:N]( (a/r)^(n+2) (SUM[m<-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<-1:N]( (n+1) (a/r)^(n+2) (SUM[m<-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 <- 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 <= m <= l }
    = l(l+1)/2 + m

    PlmSchmidt_d1(l_max: ZZ32, z: RR64): (Array[\RR64,ZZ32\], Array[\RR64,ZZ32\])
    requires { 0 <= l_max <= 16, |z| <= 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 <- seq(1:l_max), m <- 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 > 1 AND n =/= m then
                    index2 = PlmIndex(n-1,m)
                    if m > (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 <- seq(1:l_max), m <- 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 <- 1:l_max, m <- 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@...
http://projectfortress.sun.com/mailman/listinfo/language
Diane Lee | 1 Feb 00:07
Picon
Favicon

nat parameters in variant structures

There are some issues with defining nat parameters in variant types when the variants have different functions. I propose a (nontrivial) language change that would solve the problem. Take a look:

Last week Eric and Victor introduced me to nat parameters, and as an exercise we implemented a cons list with a nat parameter for the length. 

At first glance this looked ok:

1:  trait List[[T, nat n]]
2:      zip[[S]](other: List[[S,n]]) :List[[(T,S), n]]
3:  end
 
4:  object Empty[[T]] extends List[[T,0]]
5:      zip[[S]](other: List[[S,0]]) :List[[(T,S), n]]
6:          = Empty[[(T,S)]]
7:  end

8:  object Cons[[T, nat n > 0]](fst:T, rst:List[[T, n-1]]) extends List[[T, n]]
9:      zip[[S]](other: List[[S,n]]) :List[[(T,S), n]]
10:         = Cons[[(T,S), n]]((fst, other.fst), zip(rst, other.rst))
11: end

But this fails static checks at line 10 because it is not guaranteed that other:List[[S,n]] will have fst defined. 

Usually if we don't care to know statically that the argument to zip has the right constructor, we have a couple ways around this:
- check dynamically with a typecase
- cast other to type Cons[[S, n]] at line 10

We know that these won't actually ever result in dynamic errors, seeing that any object that passed the typecheck as List[[S, n]] when n>0 can only have ilk Cons[[S, n]]. But the typechecker doesn't know this, so it kind of defeats the whole purpose of using nat parameters.

We want to somehow share this knowledge with the typechecker, say with a comprises clause:

trait List[[T, nat n]] comprises { Empty[[T]] where n=0, Cons[[T, n]] where n!=0}

But, what we really want to say is that Cons[[S, n]] <: List[[S, n]] and List <: Cons[[S, n]]. Wouldn't it be nice to just cut out Cons and Empty then?

It would be nice to write:

object List[[T, nat n = 0]]
    zip[[S]] (other:List[[T, n]]) = ...
object List[[T, nat n > 0]] (fst: T, rst:List[[T, n-1]])
    zip[[S]] (other: List[[T, n]]) = ...

(This could work kind of like case expressions do, catching the first definition that matches, error if no matching case)

We would probably need to be able to define the most general requirements of a list type like:

___ List[[T, nat n >= 0]]
    zip[[S]] (other: List[[T, n]]) 
 
This is practically an interface. The difference is that we can select implementing objects depending on nat parameters, and resolve this statically. 

There is no issue with non-variant types like vectors, matrices, the supposed target of nat parameters. But something to consider. 


_______________________________________________
language mailing list
language@...
http://projectfortress.sun.com/mailman/listinfo/language
Diane Lee | 19 Jan 07:57
Picon
Favicon

Typecase expression: No binding in else clause?

I'm getting a syntax error when I try to bind to an identifier in the else clause as such:
...
    typecase eval(t2, env) of
        v2:Value ⇒ eval(v1.abs.body, Env(v1.abs.x, v2, v1.env))
        stuck:else ⇒ TmApp(v1, stuck)
    end
...

I would argue in favor of supporting such syntax. Otherwise, the user is forced to work around this by binding outside the typecase.

    The only way I can get my code to compile:

...
    e2=eval(t2,env)                                                                                                                   ...
    typecase e2 of                                                 
        v2:Value ⇒ eval(v1.abs.body, Env(v1.abs.x, v2, v1.env))    
        else ⇒ TmApp(v1, e2)                                       
    end 
...

    Notice that other than introducing intermediate variables, in my case I also lost the opportunity to give my expression a meaningful name for the else case

This wasn't an issue with the old typecase syntax (as in spec 1.0) when binding was done before "of"; it looks like support for binding in the else case got lost in the move.

Cheers,
Diane

_______________________________________________
language mailing list
language@...
http://projectfortress.sun.com/mailman/listinfo/language
Francois Retief | 13 Jan 20:51
Picon

Tail call recursive in also do blocks

Hello everyone,

I have been working on some code that I am trying to make as parallel as
possible. It creates a triangular matrix. The each diagonal element is
dependent on the previous column's diagonal value and each value in a
column is only dependent on the value above it in the column.

So the algorithm can be made parallel by splitting each column into a
separate work unit. My result can be summarised in the pseudo Fortress
code below.

My problem is that I am assuming that recursing inside a "also do" block
yields a tail call? Is this correct?

If not, how efficient would this be at depths of up to 2700?

PlmSchmidt(lmax: ZZ32, z: RR64): Array[\RR64,ZZ32\]
requires { 0 < lmax <= 2700, |z| <= 1.0 }
= do
  (* pre-calculations here *)

  P: Array[\RR64,ZZ32\] := ...

  CalculateAndFillArray(a_in: RR64, m: ZZ32):()
  = do
    a = a_in + ... (* make use of previous column's value *)
    (* initial work on first element of column *)
    do
      (* more work on other elements of column *)
    also do
      if (m+1) < lmax then
        (* recurse to next column *)
        CalculateAndFillArray(a, m+1)  (* <-- Is this a tail call? *)
      else
        (* work on last column *)
      end
    end
  end
  CalculateAndFillArray(1.0, 0)

  (* post-calculations here *)

  P
end

Cheers
  Francois

_______________________________________________
language mailing list
language@...
http://projectfortress.sun.com/mailman/listinfo/language


Gmane