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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(3) 
_{Oct}
(17) 
_{Nov}
(5) 
_{Dec}
(1) 

2010 
_{Jan}

_{Feb}
(3) 
_{Mar}
(1) 
_{Apr}

_{May}
(7) 
_{Jun}
(2) 
_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}
(6) 
_{Oct}

_{Nov}

_{Dec}

2011 
_{Jan}

_{Feb}
(14) 
_{Mar}

_{Apr}

_{May}
(18) 
_{Jun}

_{Jul}

_{Aug}
(6) 
_{Sep}
(2) 
_{Oct}
(1) 
_{Nov}
(3) 
_{Dec}

2012 
_{Jan}

_{Feb}

_{Mar}
(4) 
_{Apr}
(10) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}
(1) 
_{Oct}

_{Nov}
(3) 
_{Dec}

2013 
_{Jan}
(2) 
_{Feb}
(1) 
_{Mar}
(3) 
_{Apr}
(1) 
_{May}

_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: Randall Britten <r.britten@au...>  20130809 02:17:30

Hi The FieldML v0.5 format specification is now publicly available via this paper: Britten, Randall D., G. Richard Christie, Caton Little, Andrew K. Miller, Chris Bradley, Alan Wu, Tommy Yu, Peter Hunter, and Poul Nielsen. "FieldML, a proposed open standard for the Physiome project for mathematical model representation." Medical & biological engineering & computing (2013): 117. DOI: 10.1007/s1151701310977 It is open access, and available from either here: http://link.springer.com/article/10.1007/s1151701310977 Or here: http://physiomeproject.org/software/fieldml/about The second link is probably more useful at the moment since the Springer system is currently experiencing problems with electronic supplementary material. Regards, Randall 
From: Andrew Miller <ak.miller@au...>  20130408 02:28:53

Hi, I have looked at a range of recent computational biology papers and tried to summarise the modelling techniques used so that when we reduce the scope of what is supported in FieldML as requested by Peter Hunter today, we can base that scope on the modelling requirements of the community. I attach some brief notes I made while looking at 6 papers that describe models that we might want to represent in FieldML (or to represent the results in FieldML), from a range of disciplines within computational biology. Best wishes, Andrew 
From: Randall Britten <r.britten@au...>  20130308 06:46:49

Hi all I've collected together some notes on mathematical terminology relevant to FieldML, so that we have them handy as a reference. We can add to this in future as we go along, but it is a start. Nothing here is meant to be set in stone, so we can opt for other definitions if we prefer. It is available to view or download at https://docs.google.com/file/d/0B9GLg94KQqpYSE5Kbms1S3pMNzQ/edit?pli=1 Regards, Randall 
From: Andrew Miller <ak.miller@au...>  20130303 23:17:00

Hi all, I think that there are several options in my FieldML language prototype for how parts of the model could be identified as corresponding to a particular biological function, without needing to introduce significant new concepts: 1: Annotate domains to say 'this domain corresponds to this biological function' (e.g. heart). 1a: Annotate deconstructive domains. Start with a domain like 3D cartesian reference coordinates, or a 4D cartesian spacetime coordinate system. Create domain objects for those specific subdomains of that domain, and annotate those subdomains. Advantages: Can annotate arbitrary regions of space. Annotations can overlap (e.g. one bit of physical space might be both 'heart' and 'vascular system'). Disadvantages: Need to map everything to RC to identify what domain they belong to. Doesn't extend well as new dimensions added. 1b: Annotate constructive domains. Create domains representing, e.g. mesh coordinates in the heart, mesh coordinates in the lungs, and annotate those constructive parts. Then create a new domain for mesh coordinates in the entire body by taking a disjoint union of all the parts. Advantages: Extends well as new dimensions added. Disadvantages: There is one hierarchy, so no overlapping annotations. 2: Annotate namespaces. Advantages: Structures model according to annotations, like CellML components. Can use imports to group things into multiple import hierarchies, allowing for multiple overlapping views. Disadvantages: Any kind of identified object can go in a namespace, so very unstructured  you probably can't do much automatically using the annotations. 3: Use domain classes for annotation (and possibly annotate them with further metadata). Advantages: Structured biological information can be captured  for example, an instance of the Organ domain class might have to provide a domain function instance for the boundaries of the domain in spacetime, and a number of fields providing information about the organ, making processing easier. With multiparametric domain classes, the same domain could belong to multiple organs. Using domainlevel tag domains for organs, different domains over the same organ could be identified as the same. I think that option 3, with additional more freeform annotations (e.g. linking a type tag for heart to an ontological term for heart) is probably biologically the best fit. Best wishes, Andrew 
From: Andrew Miller <ak.miller@au...>  20130303 19:48:53

On 03/03/13 16:30, Peter Hunter wrote: > Hi Andrew, > > For our discussion tomorrow, would you be able to extend your stdlib > example to show what a FieldML file defining a small number of 2D > elements would look like  i.e. an actual example that is complete > with (arbitrary) x,y coords for the say 9 nodes of 2x2 element mesh. > It would be good if you could do this in a way that showed how this > would scale up to a large number of elements. I appreciate your > arguments for generality and avoiding constructs that deal with > specific types of field data if they can be build from more general > constructs, but remember that 99% of all field parameterisation in the > bioengineering modelling field have shown that finite elements are by > far the most successful way of handling these problems so we do need > to be careful that we don't alienate the target community. I imagine that the actual coordinates would reside in an external data source like HDF5, and that it would be possible to import something from the library that tells the system that it needs to read from an HDF5 file. The original example didn't have any fields, it merely defined the structure of the domain without describing how it is embedded in a global coordinate system. Assuming that, in an HDF5 file "meshparams.h5", there is the following: nodalpos indexed by node (size 9) and axis (size 3) Axis Node X Y 1 0 1 2 3 4 3 6 7 4 9 10 5 12 13 6 15 16 7 18 19 8 21 22 9 24 25 localtoglobal indexed by element (size 4) and localnode (size 4  it's a square mesh): Localnode Element TopLeft TopRight BottomLeft BottomRight 1 1 2 3 4 2 2 5 4 6 3 3 4 7 8 4 4 6 8 9 The FieldML file might then look like the following (this is close to the syntax supported by the prototype I am currently working on): # stdlib and h5 are arbitrary, but standardlibrary.fml and hdf5.fml are part of # the standard library. import "standardlibrary.fml" as stdlib import "hdf5.fml" as h5 # Make MeshTag, a unique domainlevel identifier. domain MeshTag = clone () domain Element = ensemble 1..4 domain GlobalNode = ensemble 1..9 # Because there is no 'clone' constructor, this just makes an alias to an # existing domain defined in the library. domain GlobalRC = stdlib.TwoDCartesianReferenceCoordinates # Define the mesh domain. domain MyMesh = stdlib.SquareMesh2D[Element, MeshTag] # Define a ConnectedDomain instance in terms of MeshTag. This is used in standardlibrary to # define the actual connectivity used on the domain. instance stdlib.ConnectedDomain MeshTag where # This example only does point connectivitiy (but the language allows for more). let == isSamePoint (\ (_x, _y) > # We try to take the two (element ID, xi) coordinates x and y onto # (element ID, local node). This is only valid at corners, so unitSqToCorner # maps square xi coordinates onto a mixed domain that either returns a special # point Nothing indicating that it is not a corner, or Just(stdlib.LocalNode) # giving the local node. Also note the lookup  that is extracting the chart # field from x, which is a stdlib.SquareMesh2D, a square mesh. case (stdlib.unitSqToCorner(lookup(stdlib.Mesh.chart, _x)), stdlib.unitSqToCorner(lookup(stdlib.Mesh.chart, _y))) of # If both _x and _y are corners, map the local node and elem to a global node # and compare  if the global nodes match, it is the same point. (Just _xc, Just _yc) > == localToGlobal((<localNode: _xc, element: lookup(stdlib.Mesh.elem, _x)>)) localToGlobal((<localNode: _yc, element: lookup(stdlib.Mesh.elem, _y)>)) _ > False) # These are used as labels... ensemble { localNode, element } # Here we actually define the existence of the localToGlobal field... val localToGlobal :: (< localNode: stdlib.LocalNodeSquare, element: Element >) > GlobalNode # This is a constraint on the field  localToGlobal is completely constrained # by the contents of the HDF5 file. let == localToGlobal (\ (< localNode: _ln, element: _el >) > (h5.lookup2("meshparams.h5", "localtoglobal", ln, el))) val nodalPosition :: GlobalNode > GlobalRC let == nodalPosition (\ _globalNode > (< stdlib.axes.x: h5.lookup2("meshparams.h5", "nodalposition", stdlib.axes.x, _globalNode), stdlib.axes.y: h5.lookup2("meshparams.h5", "nodalposition", stdlib.axes.y, _globalNode) >) ) # Now we can also define an embedding from MyMesh to GlobalRC instance stdlib.EmbeddedIn GlobalRC MyMesh where let == forwardMap (\_pp > stdlib.bilinearLagrangeInterpolator ( \_localNode > nodalPosition(localToGlobal(< localNode: _localNode, element: lookup(stdlib.Mesh.elem, _p) >)) ) # < The result of the partial application to here is an # interpolator that maps xi coordinate to GlobalRC for # this particular element. ( lookup(stdlib.Mesh.chart, _p) ) # which we then apply to get the global coordinates for _p. ) Best wishes, Andrew > Cheers, > Peter > > On 25/02/2013 3:31 p.m., Andrew Miller wrote: >> Hi, >> >> We recently agreed to a process for making decisions in relation to >> FieldML issues where we struggle to find consensus: >> 1. Discuss and try to find consensus. If no consensus can be found: >> 2. Write up the arguments for each side and see if consensus can be >> reached. If no consensus can be found: >> 3. Peter Hunter makes a decision based on the arguments made. >> >> Today, we (Randall, Poul, Chris and I) discussed whether or not >> future versions of FieldML should have built in concepts for elements >> and meshes, or whether we should make FieldML more general and allow >> for elements and meshes to be defined from these more general concepts. >> >> The majority (Randall, Poul, and I) believed that we shouldn't have a >> built in element / mesh concept, with Chris believing that we should, >> and no consensus was reached. >> >> To continue the process to step 2 on this issue, I attach a >> justification for the 'no' view point on this. Please feel free to >> join this statement or to write your own alternative view / >> justification on the issue. >> >> Best wishes, >> Andrew >> > 
From: Andrew Miller <ak.miller@au...>  20130225 02:31:57

Hi, We recently agreed to a process for making decisions in relation to FieldML issues where we struggle to find consensus: 1. Discuss and try to find consensus. If no consensus can be found: 2. Write up the arguments for each side and see if consensus can be reached. If no consensus can be found: 3. Peter Hunter makes a decision based on the arguments made. Today, we (Randall, Poul, Chris and I) discussed whether or not future versions of FieldML should have built in concepts for elements and meshes, or whether we should make FieldML more general and allow for elements and meshes to be defined from these more general concepts. The majority (Randall, Poul, and I) believed that we shouldn't have a built in element / mesh concept, with Chris believing that we should, and no consensus was reached. To continue the process to step 2 on this issue, I attach a justification for the 'no' view point on this. Please feel free to join this statement or to write your own alternative view / justification on the issue. Best wishes, Andrew 
From: Andrew Miller <ak.miller@au...>  20130105 23:06:05

On 06/01/13 12:01, Chris Bradley wrote: > Hi all, > Happy New Year. Just wondering if there is a FieldML meeting on Monday > or is everybody still on holiday? I am at work tomorrow, and I have heard a few other people will be, but not everyone. Best wishes, Andrew 
From: Chris Bradley <c.bradley@au...>  20130105 23:01:59

Hi all, Happy New Year. Just wondering if there is a FieldML meeting on Monday or is everybody still on holiday? Cheers Chris  Chris Bradley Auckland Bioengineering Institute, University of Auckland, Private Bag 92019, New Zealand. Tel: +64 9 373 7599 xtn 89924 Fax: +64 9 367 7157 
From: Andrew Miller <ak.miller@au...>  20121113 20:44:22

On 14/11/12 09:15, Richard Christie wrote: > Hi Andrew, > Good ideas. Can't the external toNode and toDerivative can surely be ParameterEvaluators with the actual mapping? I would be happy if we did something like that, avoiding the need for special implementation of the external evaluator in tools that don't need it for metadata; it does potentially make pattern matching on it slightly harder than just looking for a specific external evaluator string (it requires working out whether a given imported file is the library, for example). <DataResource name="parameters.3d.unit.tricubicHermite.toNode.resource"> <DataResourceDescription> <DataResourceString> 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 8 8 8 8 8 8 8 8 </DataResourceString> </DataResourceDescription> <ArrayDataSource name="parameters.3d.unit.tricubicHermite.toNode.source" rank="1" location="0"> <RawArraySize>64</RawArraySize> </ArrayDataSource> </DataResource> <DataResource name="parameters.3d.unit.tricubicHermite.toDerivative.resource"> <DataResourceDescription> <DataResourceString> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 </DataResourceString> </DataResourceDescription> <ArrayDataSource name="parameters.3d.unit.tricubicHermite.toDerivative.source" rank="1" location="0"> <RawArraySize>64</RawArraySize> </ArrayDataSource> </DataResource> <ParameterEvaluator name="parameters.3d.unit.tricubicHermite.component.toNode" valueType="localNodes.3d.cube2x2x2"> <Arguments> <Argument name="parameters.3d.unit.tricubicHermite.component.argument"/> </Arguments> <DenseArrayData data="parameters.3d.unit.tricubicHermite.toNode.source"> <DenseIndexes> <IndexEvaluator evaluator="parameters.3d.unit.tricubicHermite.component.argument"/> </DenseIndexes> </DenseArrayData> </ParameterEvaluator> <ParameterEvaluator name="parameters.3d.unit.tricubicHermite.component.toDerivative" valueType="parameters.3d.unit.tricubicHermite.derivative.type"> <Arguments> <Argument name="parameters.3d.unit.tricubicHermite.component.argument"/> </Arguments> <DenseArrayData data="parameters.3d.unit.tricubicHermite.toDerivative.source"> <DenseIndexes> <IndexEvaluator evaluator="parameters.3d.unit.tricubicHermite.component.argument"/> </DenseIndexes> </DenseArrayData> </ParameterEvaluator> > Also there's potential to share the node ensemble with the linear lagrange basis of the same dimension. Agreed. > Cheers, > Richard > > Original Message > From: Andrew Miller [mailto:ak.miller@...] > Sent: Tuesday, 13 November 2012 4:06 p.m. > To: fieldmldevelopers@... > Subject: [FieldMLdevelopers] Proposal for incremental change to FieldML 0.5 library for cubic Hermite parameters > > Hi all, > > I have been looking into the easiest way to get tools like cmgui, which have existing internal data structures that constrain how a model is put together, to be able to easily process FieldML models making use of cubic Hermite parameters. > > I think it would be good to make it easy for such tools to be able to detect how the arguments to such parameter evaluators break down into local nodes, derivatives, and versions. > > I therefore propose that the FieldML library be extended as follows: > For each Hermite interpolator, add something like the below (adjusted as applicable for the dimensionality): > <! Identifies a local node used in a Hermite interpolation > <EnsembleType name="parameters.3d.unit.tricubicHermite.localNode.type"> > <Members> > <MemberRange min="1" max="8"/> > </Members> > </EnsembleType> > <! Identifies a derivative at a local node. > <EnsembleType name="parameters.3d.unit.tricubicHermite.derivative.type"> > <Members> > <! 0 = no derivative. > 1 = d/dxi_1 > 2 = d/dxi_2 > 3 = d^2/dxi_1dxi2 > 4 = d/dxi_3 > 5 = d^2/dxi_1dxi_3 > 6 = d^2/dxi_2dxi_3 > 7 = d^3/dxi_1dxi_2dxi_3 > > > <MemberRange min="0" max="7"/> > </Members> > </EnsembleType> > <! Arguments for local node and derivative. > <ArgumentEvaluator name="parameters.3d.unit.tricubicHermite.localNode.argument" > valueType="parameters.3d.unit.tricubicHermite.localNode.type"/> > <ArgumentEvaluator > name="parameters.3d.unit.tricubicHermite.derivative.argument" > valueType="parameters.3d.unit.tricubicHermite.derivative.type"/> > <ExternalEvaluator > name="parameters.3d.unit.tricubicHermite.component.toNode" > valueType="parameters.3d.unit.tricubicHermite.localNode.type"> > <Arguments> > <Argument name="parameters.3d.unit.tricubicHermite.component.argument"/> > </Arguments> > </ExternalEvaluator> > <ExternalEvaluator > name="parameters.3d.unit.tricubicHermite.component.toDerivative" > valueType="parameters.3d.unit.tricubicHermite.derivative.type"> > <Arguments> > <Argument name="parameters.3d.unit.tricubicHermite.component.argument"/> > </Arguments> > </ExternalEvaluator> > > Tools that need to know how a parameter evaluator is indexed can then look for a reference evaluator that binds the parameter vector for the interpolator to an aggregate evaluator (from a parameter evaluator) over parameters.3d.unit.tricubicHermite.component, and binds parameters.3d.unit.tricubicHermite.localNode.argument to parameters.3d.unit.tricubicHermite.component.toNode, and parameters.3d.unit.tricubicHermite.derivative.argument to parameters.3d.unit.tricubicHermite.component.toDerivative. > > Best wishes, > Andrew > >  > Monitor your physical, virtual and cloud infrastructure from a single web console. Get indepth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > FieldMLdevelopers mailing list > FieldMLdevelopers@... > https://lists.sourceforge.net/lists/listinfo/fieldmldevelopers > >  > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get indepth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > FieldMLdevelopers mailing list > FieldMLdevelopers@... > https://lists.sourceforge.net/lists/listinfo/fieldmldevelopers 
From: Richard Christie <r.christie@au...>  20121113 20:16:15

Hi Andrew, Good ideas. Can't the external toNode and toDerivative can surely be ParameterEvaluators with the actual mapping? Also there's potential to share the node ensemble with the linear lagrange basis of the same dimension. Cheers, Richard Original Message From: Andrew Miller [mailto:ak.miller@...] Sent: Tuesday, 13 November 2012 4:06 p.m. To: fieldmldevelopers@... Subject: [FieldMLdevelopers] Proposal for incremental change to FieldML 0.5 library for cubic Hermite parameters Hi all, I have been looking into the easiest way to get tools like cmgui, which have existing internal data structures that constrain how a model is put together, to be able to easily process FieldML models making use of cubic Hermite parameters. I think it would be good to make it easy for such tools to be able to detect how the arguments to such parameter evaluators break down into local nodes, derivatives, and versions. I therefore propose that the FieldML library be extended as follows: For each Hermite interpolator, add something like the below (adjusted as applicable for the dimensionality): <! Identifies a local node used in a Hermite interpolation > <EnsembleType name="parameters.3d.unit.tricubicHermite.localNode.type"> <Members> <MemberRange min="1" max="8"/> </Members> </EnsembleType> <! Identifies a derivative at a local node. > <EnsembleType name="parameters.3d.unit.tricubicHermite.derivative.type"> <Members> <! 0 = no derivative. 1 = d/dxi_1 2 = d/dxi_2 3 = d^2/dxi_1dxi2 4 = d/dxi_3 5 = d^2/dxi_1dxi_3 6 = d^2/dxi_2dxi_3 7 = d^3/dxi_1dxi_2dxi_3 > <MemberRange min="0" max="7"/> </Members> </EnsembleType> <! Arguments for local node and derivative. > <ArgumentEvaluator name="parameters.3d.unit.tricubicHermite.localNode.argument" valueType="parameters.3d.unit.tricubicHermite.localNode.type"/> <ArgumentEvaluator name="parameters.3d.unit.tricubicHermite.derivative.argument" valueType="parameters.3d.unit.tricubicHermite.derivative.type"/> <ExternalEvaluator name="parameters.3d.unit.tricubicHermite.component.toNode" valueType="parameters.3d.unit.tricubicHermite.localNode.type"> <Arguments> <Argument name="parameters.3d.unit.tricubicHermite.component.argument"/> </Arguments> </ExternalEvaluator> <ExternalEvaluator name="parameters.3d.unit.tricubicHermite.component.toDerivative" valueType="parameters.3d.unit.tricubicHermite.derivative.type"> <Arguments> <Argument name="parameters.3d.unit.tricubicHermite.component.argument"/> </Arguments> </ExternalEvaluator> Tools that need to know how a parameter evaluator is indexed can then look for a reference evaluator that binds the parameter vector for the interpolator to an aggregate evaluator (from a parameter evaluator) over parameters.3d.unit.tricubicHermite.component, and binds parameters.3d.unit.tricubicHermite.localNode.argument to parameters.3d.unit.tricubicHermite.component.toNode, and parameters.3d.unit.tricubicHermite.derivative.argument to parameters.3d.unit.tricubicHermite.component.toDerivative. Best wishes, Andrew  Monitor your physical, virtual and cloud infrastructure from a single web console. Get indepth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ FieldMLdevelopers mailing list FieldMLdevelopers@... https://lists.sourceforge.net/lists/listinfo/fieldmldevelopers 
From: Andrew Miller <ak.miller@au...>  20121113 03:05:51

Hi all, I have been looking into the easiest way to get tools like cmgui, which have existing internal data structures that constrain how a model is put together, to be able to easily process FieldML models making use of cubic Hermite parameters. I think it would be good to make it easy for such tools to be able to detect how the arguments to such parameter evaluators break down into local nodes, derivatives, and versions. I therefore propose that the FieldML library be extended as follows: For each Hermite interpolator, add something like the below (adjusted as applicable for the dimensionality): <! Identifies a local node used in a Hermite interpolation > <EnsembleType name="parameters.3d.unit.tricubicHermite.localNode.type"> <Members> <MemberRange min="1" max="8"/> </Members> </EnsembleType> <! Identifies a derivative at a local node. > <EnsembleType name="parameters.3d.unit.tricubicHermite.derivative.type"> <Members> <! 0 = no derivative. 1 = d/dxi_1 2 = d/dxi_2 3 = d^2/dxi_1dxi2 4 = d/dxi_3 5 = d^2/dxi_1dxi_3 6 = d^2/dxi_2dxi_3 7 = d^3/dxi_1dxi_2dxi_3 > <MemberRange min="0" max="7"/> </Members> </EnsembleType> <! Arguments for local node and derivative. > <ArgumentEvaluator name="parameters.3d.unit.tricubicHermite.localNode.argument" valueType="parameters.3d.unit.tricubicHermite.localNode.type"/> <ArgumentEvaluator name="parameters.3d.unit.tricubicHermite.derivative.argument" valueType="parameters.3d.unit.tricubicHermite.derivative.type"/> <ExternalEvaluator name="parameters.3d.unit.tricubicHermite.component.toNode" valueType="parameters.3d.unit.tricubicHermite.localNode.type"> <Arguments> <Argument name="parameters.3d.unit.tricubicHermite.component.argument"/> </Arguments> </ExternalEvaluator> <ExternalEvaluator name="parameters.3d.unit.tricubicHermite.component.toDerivative" valueType="parameters.3d.unit.tricubicHermite.derivative.type"> <Arguments> <Argument name="parameters.3d.unit.tricubicHermite.component.argument"/> </Arguments> </ExternalEvaluator> Tools that need to know how a parameter evaluator is indexed can then look for a reference evaluator that binds the parameter vector for the interpolator to an aggregate evaluator (from a parameter evaluator) over parameters.3d.unit.tricubicHermite.component, and binds parameters.3d.unit.tricubicHermite.localNode.argument to parameters.3d.unit.tricubicHermite.component.toNode, and parameters.3d.unit.tricubicHermite.derivative.argument to parameters.3d.unit.tricubicHermite.component.toDerivative. Best wishes, Andrew 
From: Randall Britten <r.britten@au...>  20120913 23:54:20

Hi The second edition of John M. Lee's book "Introduction to Smooth Manifolds" is available online if your institution subscribes to Springer's "Graduate Texts in Mathematics" series (which Auckland University does). See http://www.math.washington.edu/~lee/Books/ISM/ I have read the first edition in detail, and I can highly recommend this book, it gives a good foundation on a lot of topics of relevance to FieldML and related projects, and explains and uses modern notation. The appendix has a bitesized summary of the required background on topological manifolds, and the companion book, "Introduction to Topological Manifolds" is also available online (http://www.math.washington.edu/~lee/Books/ITM/). John M. Lee is very willing to respond to queries by email, which can be really helpful when working through the books (even though they are quite selfexplanatory). Regards, Randall 
From: Randall Britten <r.britten@au...>  20120813 08:08:19

Hi The latest version of the FieldML prototype that I have been working on is now public: https://github.com/codecurve/FieldMLHaskell01 This is still very much a workinprogress. I would like to acknowledge the contribution of the other members of the FieldML design work group: the ideas represented in this prototype have come out of countless hours of discussions with them, and many of these ideas were formed years before I even started thinking about FieldML, although I have definitely have added my own spin in many places. Regards, Randall 
From: Randall Britten <r.britten@au...>  20120503 06:06:40

Hi all On behalf of the FieldML design working group, I am pleased to announce that the FieldML 0.5 specification (as XSD) and API have been released. * The FieldML API version 0.5 is provided as source code, a zip file is available from GitHub<http://github.com/FieldML/FieldMLAPI/zipball/FieldML_0.5>;. * The API programmers' documentation (Doxygen) can be generated from the source code, or browsed at http://fieldml.sourceforge.net/files.html * The FieldML 0.5 XML format is described by the XML Schema<http://www.fieldml.org/resources/xml/0.5/FieldML_0.5.xsd>;. Regards, Randall 
From: Richard Christie <r.christie@au...>  20120422 21:49:14

On 20/04/12 16:25, Andrew Miller wrote: > Ensemble domain > =============== > I don't think we need an explicit ensemble type  and if we do, it > should be sugar, not a new fundamental concept. > > You can define a domain which has only one possible value as a product > domain that does not have any components. You can define a domain which > has n possible values as a union of clones of the domain with only one > possible value. Therefore, ensemble is not strictly necessary (at least > not if union is powerful enough). If union is a tagged union that allows > the same domain to be used twice, each time creating a different set of > points labelled by the union tag, even the clone becomes unnecessary. > This seems much cleaner and more general than building in an explicit > ensemble type. > > Alternatively, an ensemble could just be a clone of a subset of integer. The important thing is to ensure homogeneity of the collection, in this case simply 0D points. It's not a subset of integer; it's a set of points with labels, integer or other. The ensemble is more like an enumeration. OTOH, regarding products with no factors, perhaps we need a way to make a point domain equivalent to the domain of a CellML lumped parameter model. > Clone: Deep copy > ================ > I don't think clone should be 'deep' with respect to the main domain > being cloned, because that makes it harder to work with the domain later > unnecessarily. > > The ideal semantics should be that it just creates a 'tag' around the > domain, to make it a different domain, but without changing any of the > details of the domain itself (possibly equivalent to creating a product > domain with only one component). I think that in terms of the namespace, > it should just create references to the members of the namespace. > > Example: > Let BasicCartesianCoordinates be a product of domain > BasicCartesianCoordinates:X labelled x, with > BasicCartesianCoordinates:Y labelled y. > Let BasicCartesianCoordinates:X and BasicCartesianCoordinates:Y be > different different clones of Real1. > Let MyCartesianCoordinates be a clone of BasicCartesianCoordinates. > > Then I think the best semantics are: > The domain MyCartesianCoordinates is 'wrapped' version of > BasicCartesianCoordinates, meaning that it is a different domain to > BasicCartesianCoordinates, but it is possible to manually add the > wrapper to a domain value to convert a BasicCartesianCoordinates > domain value to a MyCartesianCoordinates domain value, and it is > possible to manually (or automatically?) remove the wrapper to convert > MyCartesianCoordinates to BasicCartesianCoordinates. > > The corresponding namespace MyCartesianCoordinates works by > creating references (*not* clones) of the members. So > MyCartesianCoordinates:X is an alias for BasicCartesianCoordinates:X, > and MyCartesianCoordinates:Y is an alias for > BasicCartesianCoordinates:Y. > > There is no need for any overload semantics  type variables would be a > cleaner way to achieve the same thing if we need that. > > Making namespace members references rather than clones (i.e. doing a > shallow clone) means that converting a BasicCartesianCoordinates to a > MyCartesianCoordinates requires only a single rewrapping. > I regret using the term 'deep copy' since I only meant that for clones of power domains, the index is also cloned. What I mean by clone is very similar to what you have written. A clone declares a new space independent of the original space, but if the common data is just referenced then all is well. There are some rules though: A field defined on a clone is not defined on the original domain. However, a field defined on the original domain can be inherited on the clone. > Power product vs field type > =========================== > > There is little difference in the information carried by (D^n) (a domain > type such that each value has n values of D) and ({1..n} > D) (a > function type that takes a number from 1 to n onto a value of the domain). > > Randall mentioned that he thinks that D^n provides more topological > information, but I'm not sure that the power product always implies the > topological information either. > > The information we want to convey is something like the following: that > if N(x) is the neighbourhood of point x, then x' in N(x) and y' in N(y) > implies (x', y') in N(x, y). > > D^2 could just mean we have two values of D that are unrelated > topologically. > > I therefore don't think there is a good justification for introducing > the power product. Topology of the domain is important  that IS what is being communicated. You need to define this 'function type' more concretely. > Union semantics > =============== > > I think tagged unions are cleaner semantically  you can split off all > the cases in a branching construct, and the cases are disjoint. This may > be what you intended, but you didn't mention discriminator labels, so it > isn't clear. > > I'm not sure 'same dimensionality' is strictly necessary  what if you > have a mesh, and different parts of the mesh have different dimensions, > due to different schemes for labelling the points in different parts of > the mesh. I left out further details of the union. In my opinion it exists to mop up nasty inhomogeneous cases. > Bounds vs subsets > ================= > > You have bounds as a property of every domain. Why not just a subset > domain? That would also work for domains acting as ensembles. > You can provide bounds on a reference to the ensemble. > On 20/04/12 14:26, Richard Christie wrote: >> Hi All, >> >> I've rationalised my thoughts about domains, fields etc. for FieldML 0.6 >> and put them together into a short, hopefully readable document, >> attached here. >> >> I've incorporated (adapted?) the idea from Andrew that multiple >> References to the same domain in a product act like multiple values from >> that domain. Doing so removes any restriction about where any domain >> type can be used, and allows us to describe functions of multiple >> locations in a domain. I like it, and it doesn't make simpler cases any >> less convenient. >> >> Note I'm still being strict about the different between a Clone and a >> Reference: a Clone forms a new space, a Reference references an existing >> space (plus its special role as representing independent values from the >> same domain). >> >> cheers, >> Richard >> > >  > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in UltraFine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundaryd2dvs2 > _______________________________________________ > FieldMLdevelopers mailing list > FieldMLdevelopers@... > https://lists.sourceforge.net/lists/listinfo/fieldmldevelopers 
From: Randall Britten <r.britten@au...>  20120420 05:50:08

Hi Andrew Regarding your comment on whether all mesh elements need to have the same dimension (see below), please see the tracker item: https://tracker.physiomeproject.org/show_bug.cgi?id=2601 Regards, Randall > I'm not sure 'same dimensionality' is strictly necessary  what if you > have a mesh, and different parts of the mesh have different dimensions, > due to different schemes for labelling the points in different parts of > the mesh. [] 
From: Randall Britten <r.britten@au...>  20120420 05:29:10

Hi Andrew Regarding the topology of the power product: The point I made was that traditionally the cartesianproduct(D, D, D, ... ,D) i.e. the same factor D repeated n times, has a topology, consistent with the ndimensional equivalent of your statement: " x' in N(x) and y' in N(y) implies (x', y') in N(x, y) "; whereas cartesianproduct({1..n}, D) has n disconnected components (assuming if D is a single connected topological space). I think power product is just syntactic sugar for cartesianproduct(D, D, D, ... ,D). I don't know if ({1..n} > D) traditionally has a topology, but I think I agree with you that it conveys the same meaning as cartesianproduct({1..n}, D). I don't think we've really worked out yet whether FieldML needs to care about some of the finer points of topology, so perhaps it won't be relevant. Regards, Randall > > Power product vs field type > =========================== > > There is little difference in the information carried by (D^n) (a domain > type such that each value has n values of D) and ({1..n} > D) (a > function type that takes a number from 1 to n onto a value of the domain). > > Randall mentioned that he thinks that D^n provides more topological > information, but I'm not sure that the power product always implies the > topological information either. > > The information we want to convey is something like the following: that > if N(x) is the neighbourhood of point x, then x' in N(x) and y' in N(y) > implies (x', y') in N(x, y). > > D^2 could just mean we have two values of D that are unrelated > topologically. > > I therefore don't think there is a good justification for introducing > the power product. > [] 
From: Andrew Miller <ak.miller@au...>  20120420 04:52:10

On 20/04/12 15:36, Richard Christie wrote: > Consider the bounds function for a subdomain. > It requires a truth condition, for which you either need to understand a > Boolean value, or buildin an equality (or inequality or other logical) > expression. > This is what I mean by true/false semantics, not two equivalent values > that happen to be labelled "true" and "false". Good point  if we need built in parts of the language to depend on boolean, the language needs to recognise that type. However, it doesn't mean it can't have the normal semantics for a union domain  it just means that we have to define a library that is so fundamental that parts of the library have special meaning in certain constructs within the language itself. Equality and inequality operators can still be defined separately from the core of the FieldML language, although the bounds function is an example where you need to refer to Boolean from the language definition itself. I think the best way to do this is to define boolean in the core library, and then allow references to the core library from the core language specification in cases where it is needed. That way, the extent of the magic needed for boolean is limited  you can do most stuff using the standard union domain facilities, except that it is special cased in a few very limited places, as opposed to it being a completely new type of fundamental domain. Best wishes, Andrew > > cheers, > Richard > > > On 20/04/12 15:07, Andrew Miller wrote: >> I haven't read the whole document yet, what I've read so far mostly >> looks good, but one point I don't understand is this: >> >> "Boolean is needed because a 2member ensemble can't give true/false >> semantics; alternatively logical operators would need to be inbuilt". >> I don't think this is true  you just need to define a 0D (R^0) domain, >> and then a union of two clones ('True' and 'False'). >> >> We already are going to need an operator that lets you handle values >> differently depending on which of the unioned domains their value comes >> from, and this could be used to implement logical operators. >> >> Haskell does this, so provides a good example of how it can be done (it >> has no builtin concept of boolean in the language data model itself, >> except for the if construct, which is syntactic sugar around case, >> although compilers obviously specialcase boolean operations for >> efficiency). >> >> data Bool = True  False  Like a union domain of two parts, True and >>  False. >> let a&& b = case a of >> False > False >> True > b >> let a  b = case a of >> True > True >> False > b >> >> None of this is magic  I could equally well define a tristate boolean >> or some other type in the same way using the same fundamental language >> constructs. >> >> I am therefore not convinced we need to build boolean into the language, >> and I'm not convinced we need to build logical operators in to the >> language either. >> >> Best wishes, >> Andrew >> >>  >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in UltraFine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundaryd2dvs2 >> _______________________________________________ >> FieldMLdevelopers mailing list >> FieldMLdevelopers@... >> https://lists.sourceforge.net/lists/listinfo/fieldmldevelopers > > >  > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in UltraFine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundaryd2dvs2 > _______________________________________________ > FieldMLdevelopers mailing list > FieldMLdevelopers@... > https://lists.sourceforge.net/lists/listinfo/fieldmldevelopers 
From: Andrew Miller <ak.miller@au...>  20120420 04:25:55

Ensemble domain =============== I don't think we need an explicit ensemble type  and if we do, it should be sugar, not a new fundamental concept. You can define a domain which has only one possible value as a product domain that does not have any components. You can define a domain which has n possible values as a union of clones of the domain with only one possible value. Therefore, ensemble is not strictly necessary (at least not if union is powerful enough). If union is a tagged union that allows the same domain to be used twice, each time creating a different set of points labelled by the union tag, even the clone becomes unnecessary. This seems much cleaner and more general than building in an explicit ensemble type. Alternatively, an ensemble could just be a clone of a subset of integer. Clone: Deep copy ================ I don't think clone should be 'deep' with respect to the main domain being cloned, because that makes it harder to work with the domain later unnecessarily. The ideal semantics should be that it just creates a 'tag' around the domain, to make it a different domain, but without changing any of the details of the domain itself (possibly equivalent to creating a product domain with only one component). I think that in terms of the namespace, it should just create references to the members of the namespace. Example: Let BasicCartesianCoordinates be a product of domain BasicCartesianCoordinates:X labelled x, with BasicCartesianCoordinates:Y labelled y. Let BasicCartesianCoordinates:X and BasicCartesianCoordinates:Y be different different clones of Real1. Let MyCartesianCoordinates be a clone of BasicCartesianCoordinates. Then I think the best semantics are: The domain MyCartesianCoordinates is 'wrapped' version of BasicCartesianCoordinates, meaning that it is a different domain to BasicCartesianCoordinates, but it is possible to manually add the wrapper to a domain value to convert a BasicCartesianCoordinates domain value to a MyCartesianCoordinates domain value, and it is possible to manually (or automatically?) remove the wrapper to convert MyCartesianCoordinates to BasicCartesianCoordinates. The corresponding namespace MyCartesianCoordinates works by creating references (*not* clones) of the members. So MyCartesianCoordinates:X is an alias for BasicCartesianCoordinates:X, and MyCartesianCoordinates:Y is an alias for BasicCartesianCoordinates:Y. There is no need for any overload semantics  type variables would be a cleaner way to achieve the same thing if we need that. Making namespace members references rather than clones (i.e. doing a shallow clone) means that converting a BasicCartesianCoordinates to a MyCartesianCoordinates requires only a single rewrapping. Power product vs field type =========================== There is little difference in the information carried by (D^n) (a domain type such that each value has n values of D) and ({1..n} > D) (a function type that takes a number from 1 to n onto a value of the domain). Randall mentioned that he thinks that D^n provides more topological information, but I'm not sure that the power product always implies the topological information either. The information we want to convey is something like the following: that if N(x) is the neighbourhood of point x, then x' in N(x) and y' in N(y) implies (x', y') in N(x, y). D^2 could just mean we have two values of D that are unrelated topologically. I therefore don't think there is a good justification for introducing the power product. Union semantics =============== I think tagged unions are cleaner semantically  you can split off all the cases in a branching construct, and the cases are disjoint. This may be what you intended, but you didn't mention discriminator labels, so it isn't clear. I'm not sure 'same dimensionality' is strictly necessary  what if you have a mesh, and different parts of the mesh have different dimensions, due to different schemes for labelling the points in different parts of the mesh. Bounds vs subsets ================= You have bounds as a property of every domain. Why not just a subset domain? That would also work for domains acting as ensembles. On 20/04/12 14:26, Richard Christie wrote: > Hi All, > > I've rationalised my thoughts about domains, fields etc. for FieldML 0.6 > and put them together into a short, hopefully readable document, > attached here. > > I've incorporated (adapted?) the idea from Andrew that multiple > References to the same domain in a product act like multiple values from > that domain. Doing so removes any restriction about where any domain > type can be used, and allows us to describe functions of multiple > locations in a domain. I like it, and it doesn't make simpler cases any > less convenient. > > Note I'm still being strict about the different between a Clone and a > Reference: a Clone forms a new space, a Reference references an existing > space (plus its special role as representing independent values from the > same domain). > > cheers, > Richard > 
From: Richard Christie <r.christie@au...>  20120420 03:36:40

Consider the bounds function for a subdomain. It requires a truth condition, for which you either need to understand a Boolean value, or buildin an equality (or inequality or other logical) expression. This is what I mean by true/false semantics, not two equivalent values that happen to be labelled "true" and "false". cheers, Richard On 20/04/12 15:07, Andrew Miller wrote: > I haven't read the whole document yet, what I've read so far mostly > looks good, but one point I don't understand is this: > > "Boolean is needed because a 2member ensemble can't give true/false > semantics; alternatively logical operators would need to be inbuilt". > I don't think this is true  you just need to define a 0D (R^0) domain, > and then a union of two clones ('True' and 'False'). > > We already are going to need an operator that lets you handle values > differently depending on which of the unioned domains their value comes > from, and this could be used to implement logical operators. > > Haskell does this, so provides a good example of how it can be done (it > has no builtin concept of boolean in the language data model itself, > except for the if construct, which is syntactic sugar around case, > although compilers obviously specialcase boolean operations for > efficiency). > > data Bool = True  False  Like a union domain of two parts, True and >  False. > let a&& b = case a of > False > False > True > b > let a  b = case a of > True > True > False > b > > None of this is magic  I could equally well define a tristate boolean > or some other type in the same way using the same fundamental language > constructs. > > I am therefore not convinced we need to build boolean into the language, > and I'm not convinced we need to build logical operators in to the > language either. > > Best wishes, > Andrew > >  > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in UltraFine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundaryd2dvs2 > _______________________________________________ > FieldMLdevelopers mailing list > FieldMLdevelopers@... > https://lists.sourceforge.net/lists/listinfo/fieldmldevelopers 
From: Andrew Miller <ak.miller@au...>  20120420 03:08:02

I haven't read the whole document yet, what I've read so far mostly looks good, but one point I don't understand is this: "Boolean is needed because a 2member ensemble can't give true/false semantics; alternatively logical operators would need to be inbuilt". I don't think this is true  you just need to define a 0D (R^0) domain, and then a union of two clones ('True' and 'False'). We already are going to need an operator that lets you handle values differently depending on which of the unioned domains their value comes from, and this could be used to implement logical operators. Haskell does this, so provides a good example of how it can be done (it has no builtin concept of boolean in the language data model itself, except for the if construct, which is syntactic sugar around case, although compilers obviously specialcase boolean operations for efficiency). data Bool = True  False  Like a union domain of two parts, True and  False. let a && b = case a of False > False True > b let a  b = case a of True > True False > b None of this is magic  I could equally well define a tristate boolean or some other type in the same way using the same fundamental language constructs. I am therefore not convinced we need to build boolean into the language, and I'm not convinced we need to build logical operators in to the language either. Best wishes, Andrew 
From: Andrew Miller <ak.miller@au...>  20120418 04:01:27

On 17/04/12 19:12, Randall Britten wrote: > Hi Andrew > > Here are some possible minor corrections, I know you said you still plan to proof read it, so this is hopefully just help with that. And then some more general discussion follows. > > "Every field a type signature with two slots" > +"Every field has a type signature with two slots" > > "performing function transformations them using a pointfree style" > +"performing function transformations on them using a pointfree style" > > Also, twice you use cd="productDomain1", I think you meant cd="fieldml1"? I might have missed it, but I couldn't find any that were in the wrong cd. The idea is that those symbols related to product domains (listed on page 4) can potentially be reused outside of FieldML, and so are in the productDomain1 content dictionary, while the remaining symbols are in the fieldml1 content dictionary, defined in the bulleted list on pages 5 and 6. > > I think lambdas are meant to be done as in this sequence: bind, lambda, bvars, expressioninbvars (http://www.w3.org/TR/MathML/chapter4.html#contm.lambda). Your link was to a nonstrict to strict transformation rule, which doesn't show the only way to represent things. However, you are right, the RNC definitions in Appendix A are orderdependent, so the bvars must come after the operator and before the operand. > > Some more general comments: > I'd prefer "disjoint union" rather than "discriminated union" (http://en.wikipedia.org/wiki/Discriminated_union), but perhaps I have not fully understood what you mean. Perhaps "tagged union" conveys it better  it implies that if you can make a tagged union domain with components "Real with label x" and "Real with label y", and that x:10 and y:10 are different values on the domain. If we just called it a disjoint union, it might appear that it is not possible to union two Real domains because they are not disjoint. However, this is irrelevant if it is always used with clones. > > For the "castClone", I think we would perhaps also need "castFromSubset", or perhaps just a cast that can be used for either case? Agreed with need something  but it would probably be castToSubset if we treat a subset as the specialised case and the superset as the generalised case  going from the specialised case to the general case always succeeds, but going from the general case to the specialised case might fail if a value isn't actually the special case, and so needs a cast (for example, under HindleyMilner, we could automatically allow 'an integer from 0 to 10' to be applied to a field that expects 'an integer', but the user would need to ask to go from an integer to an integer from 0 to 10, because they either need to declare that they have proved that the value can't be outside of the range (e.g. it is not possible for the value to be 11), or somehow specify what to do if it is outside the range). > > I think it's worth noting that we discussed a third avenue: using the order of tuple members and the order of the factors in Cartesian products, as is standard in mathematics. The main objection was that projections have to refer to tuple members by position, but the main advantage is that allows for more direct use of traditional mathematical style, which perhaps will mean better support from general purpose MathML software. For example, your proposal introduces " productConstruct", whereas "cartesian_product" already exists in an official content dictionary ("set1"). Agreed that a positionbased approach would probably simplify things and fit more cleanly with existing maths. However, I think that Poul and Richard feel strongly that we should have orderindependent product domains, we need to move on, and for me at least, there are probably more important battles to pick. Best wishes, Andrew 
From: Randall Britten <r.britten@au...>  20120417 07:13:18

Hi Andrew Here are some possible minor corrections, I know you said you still plan to proof read it, so this is hopefully just help with that. And then some more general discussion follows. "Every field a type signature with two slots" +"Every field has a type signature with two slots" "performing function transformations them using a pointfree style" +"performing function transformations on them using a pointfree style" Also, twice you use cd="productDomain1", I think you meant cd="fieldml1"? I think lambdas are meant to be done as in this sequence: bind, lambda, bvars, expressioninbvars (http://www.w3.org/TR/MathML/chapter4.html#contm.lambda). Some more general comments: I'd prefer "disjoint union" rather than "discriminated union" (http://en.wikipedia.org/wiki/Discriminated_union), but perhaps I have not fully understood what you mean. For the "castClone", I think we would perhaps also need "castFromSubset", or perhaps just a cast that can be used for either case? I think it's worth noting that we discussed a third avenue: using the order of tuple members and the order of the factors in Cartesian products, as is standard in mathematics. The main objection was that projections have to refer to tuple members by position, but the main advantage is that allows for more direct use of traditional mathematical style, which perhaps will mean better support from general purpose MathML software. For example, your proposal introduces " productConstruct", whereas "cartesian_product" already exists in an official content dictionary ("set1"). Here's a snippet of how this might look for the Cartesian to polar example: <Domain name="My2DSpaceB"> <math xmlns="http://www.w3.org/1998/Math/MathML/">; <apply> <csymbol cd="set1">cartesian_product</csymbol> <csymbol cd="setname1">R</csymbol> <csymbol cd="setname1">R</csymbol> </apply> </math> </Domain> <Domain name="My2DPolarSpaceB"> <math xmlns="http://www.w3.org/1998/Math/MathML/">; <apply> <csymbol cd="set1">cartesian_product</csymbol> <csymbol cd="setname1">R</csymbol> <csymbol cd="setname1">R</csymbol> </apply> </math> </Domain> <Field name="cartesianAsPolarB" domain="My2DSpaceB" codomain="My2DPolarSpaceB"> <math xmlns="http://www.w3.org/1998/Math/MathML/">; <bind> <csymbol cd="fns1">lambda</csymbol> <bvar><ci>x</ci></bvar> <bvar><ci>y</ci></bvar> <apply> <csymbol cd="linalg2">vector</csymbol> <apply> <csymbol cd="arith1">root</csymbol> <apply> <csymbol cd="arith1">plus</csymbol> <apply> <csymbol cd="arith1">power</csymbol> <ci>x</ci> <cn>2</cn> </apply> <apply> <csymbol cd="arith1">power</csymbol> <ci>y</ci> <cn>2</cn> </apply> </apply> <cn>2</cn> </apply> <apply> <csymbol cd="transc2">arctan</csymbol> <ci>y</ci> <ci>x</ci> </apply> </apply> </bind> </math> </Field> Regards, Randall > Original Message > From: Andrew Miller [mailto:ak.miller@...] > Sent: Tuesday, 17 April 2012 2:04 p.m. > To: fieldmldevelopers@... > Subject: [FieldMLdevelopers] Proposal for a Content MathML 3 based > FieldML with named field parameters and strong, static HindleyMilner type > inference > > Hi all, > > I've put together a proposal (attached) for a Content MathML 3 based > FieldML with named field parameters and strong, static HindleyMilner > type inference. > > I think this proposal achieves most of what we want from FieldML. It > took a while to put together and I haven't yet proofread it closely. > > There are a few glaring things which I have left out that might make > modelling using it easier and more powerful: > * The ability to define userspecified parametric types and > typeclasses  something which HindleyMilner Type Inference would allow > us to do. This would mean fields could sometimes be valid over more than > one domain, but in a controlled way with no runtime polymorphism. > * The ability to define type signatures that are anything other than > a domain. > * Let syntax to locally bind variables, as in Haskell. In the > examples, I have simulated this by immediately applying a lambda, but it > looks very messy. > * NonXML syntax  possibly just as an input format that is > translated to MathML. This would make things a lot more readable when > doing examples. > > Best wishes, > Andrew 
From: Andrew Miller <ak.miller@au...>  20120417 02:04:01

Hi all, I've put together a proposal (attached) for a Content MathML 3 based FieldML with named field parameters and strong, static HindleyMilner type inference. I think this proposal achieves most of what we want from FieldML. It took a while to put together and I haven't yet proofread it closely. There are a few glaring things which I have left out that might make modelling using it easier and more powerful: * The ability to define userspecified parametric types and typeclasses  something which HindleyMilner Type Inference would allow us to do. This would mean fields could sometimes be valid over more than one domain, but in a controlled way with no runtime polymorphism. * The ability to define type signatures that are anything other than a domain. * Let syntax to locally bind variables, as in Haskell. In the examples, I have simulated this by immediately applying a lambda, but it looks very messy. * NonXML syntax  possibly just as an input format that is translated to MathML. This would make things a lot more readable when doing examples. Best wishes, Andrew 
From: Richard Christie <r.christie@au...>  20120322 01:38:18

Hi All, Thanks Andrew for writing that up. I have essentially the same view of a domain as consisting of a set of coordinate labels identifying the material points, some of which may be identified by more than one label. I also agree that you don't want to be allowed to retrospectively change the connectivity of a doman, e.g. the real line, so I agree that embedding relationships must be part of the definition of a new domain. I see the key parts making up a userdefined domain as: 1. Label set building operation (clone, product, union, subset) 2. Optional bounds function (expressed as boolean field) to restrict valid label set. 3. Optional connectivity/embedding/immersion relationships to explain commonality of material points. The optional bounds function on any domain constructor allows modellers to make a bounded space without exposing a fictitious unbounded space. I consider this as a practical requirement for the language. I am still mulling the presentation of connectivity (point 3 above). We require domains to have multiple point and other connectivity relationships since they exist in FE datasets (but we expect them to be consistent otherwise it is invalid). It also opens questions about whether interdomain embedding ever makes sense or whether it belongs as 'connectivity data' of a domain collecting together subdomains; e.g. relating 2 coordinate systems in mutual embedding vs. forming a union of the two coordinate systems and relating them via connectivity 'in the context of the union'. Keeping on thinking... cheers, Richard On 21/03/12 14:51, Andrew Miller wrote: > Hi all, > > As discussed at today's meeting, I've put together a summary of my > views on how we should resolve the need to provide connectivity > information; I've put forward two approaches, one using embeds (and a > justification on why I think they should be embeds and not > immersions), and the other using an association map. > > I think that the semantics become a lot clearer when we define a > domain as having two spaces, a coordinate space and a point space, > rather than conflating the two  see the document for more details. > > Please let me know what you think. > > Best wishes, > Andrew > > >  > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2dmsazure > > > _______________________________________________ > FieldMLdevelopers mailing list > FieldMLdevelopers@... > https://lists.sourceforge.net/lists/listinfo/fieldmldevelopers 