[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Modeling matrices in an XML environment

Subject: Re: Modeling matrices in an XML environment
From: "David Birnbaum djbpitt@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 13 Jul 2020 22:23:02 -0000
Re:  Modeling matrices in an XML environment
Thanks, Liam. This is very helpful. I had used schema-aware processing,
*@as*, and *@type* attributes when I tried the *<cell row="x" col="y">*
approach in the hope of avoiding unwanted type instability. But even when
that works, I hadn't thought about the overhead of the invisible unwanted
properties, and neither had I thought of using maps, which are, I now
realize, a lighter-weight alternative to the *<cell>* elements, with the
same advantages.

On Mon, Jul 13, 2020 at 5:58 PM Liam R. E. Quin liam@xxxxxxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> On Mon, 2020-07-13 at 17:26 +0000, David Birnbaum djbpitt@xxxxxxxxx
> wrote:
> > Dear XSL-list,
> >
> > Roger's question invites a tangential one (for which reason I have
> > changed
> > the subject line): How might we usefully think about representing
> > matrices
> > in an XML environment?
>
> bit dependsbbfor performance in XPath/XQuery/XSLT/Xcetera ibd
probably
> use arrays or, for sparse matrices, maps. This is because the
> individual elements in mathematical matrices do not have intrinsic
> significance beyond the positional.
>
> For situations in which the elements _do_ have significant, there are
> obvious (to this crows) benefits to using XML names, or maps with named
> components,
>    "x" : 4.2, "y" : 7.2, "z" : 9
>
>
> The benefit to using maps or arrays over elements in XSLT or XQuery is
> that element nodes are too heavyweight, and too prone to turning their
> content back into strings. In XQuery in particular, constructors by
> default do a terrible and dismal thing: <x>3</x> makes a text node
> inside an x element. And XDM element nodes have a ton of properties,
> such as next, previous, parent, schema type, is_happy, none  of which
> are needed for a matrix of numbers.
>
> This is entirely separate from the MathML apprach, of course, whether
> content or presentational.
>
> For performance i'd consider also a single flat array,
>   [ r0c0 r0c1 .... r1c0.... ]
> with accessor functions my:mget($matrix, $row, $col) or whatever.
>
> It depends on the sort of manipulations you do.
>
> Liam
>
> --
> Liam Quin, https://www.delightfulcomputing.com/
> Available for XML/Document/Information Architecture/XSLT/
> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.