Unidirectional Composite Ansys

tool on the task of synthesizing backward computations. CCS Concepts: • Software and its engineering →Domain specific languages; Programming by exam- ple; Functional languages.

Additional Key Words and Phrases: program synthesis, bidirectional transformation

Acm Reference Format:

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang. 2021. Synbit: Synthesizing Bidi- rectional Programs using Unidirectional Sketches. Proc. ACM Program. Lang. 5, OOPSLA, Article 105 (Octo-

Ntroduction

Transforming data from one format to another is a common task of programming: compilers trans- form program text into syntax trees, manipulate the trees and then generate low-level code; database queries transform base relations into views; model-driving software engineering transforms one model into another. Very often, such transformations will benefit from being bidirectional, allowing changes to the targets to be mapped back to the sources too (for example the view-update problem in databases (Bancilhon and Spyratos 1981, Hegner 1990), bidirectional model transformation (Stevens 2008), and so on).

As a response to this need, programming-language researchers started to design specialized programming languages for writing bidirectional transformations. In particular as pioneered by Pierce’s group at Pennsylvania, a bidirectional transformation (BX), also known as a lens (Foster ∗Currently at Fujitsu.

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).

© 2021 Copyright held by the owner/author(s).

:2

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang et al. 2007), is modeled as a pair of functions between source and view data objects, one in each direction. The forward function get :: 𝑆→𝑉maps a source onto a view, and the corresponding backward function put :: 𝑆× 𝑉→𝑆reflects any changes in the view back to the source. Note that get is not necessarily injective. Accordingly put, in addition to the updated view, also takes the original source as an argument. This makes it possible to recover some of the source data that is not present in the view. Of course, not all pairing of get/put forms are valid BX; they must be related by specific properties known as round-tripping.

(Consistency)

for all 𝑠,𝑠′ ∈𝑆and 𝑣∈𝑉. Here, Acceptability states that no changes to the source happen if there is no change to the view, and Consistency states that all changes to the view must be captured in the updated source.

A BX language allows the transformations in both directions to be programmed together and is expected to guarantee round-tripping by construction. This is a challenging problem for language design, and consequently compromises had to be made (in particular to usability) in favor of guaranteeing round-tripping. In the original lens design (Foster et al. 2007), lenses can only be composed by stylized lens combinators, which is inconvenient to program with. A lot of research has gone into this area since, for example Bohannon et al. (2008), Matsuda et al. (2007), Matsuda and Wang (2018b), Pacheco et al. (2014), Voigtländer (2009), and the state of the art has progressed a long way since. This includes a language HOBiT (Matsuda and Wang 2018b), which follows a line of research (Matsuda et al. 2007, Matsuda and Wang 2015a,b, Voigtländer 2009) that aims to produce BX code that is close in structure to how one will program the get function alone in a conventional unidirectional language. Despite the progresses in language design, BX programming is still considerably more difficult than conventional programming, especially when sophisticated backward behaviors are required. This complexity is largely inherent as one is asked to do more in less: defining behaviors in both directions in a single definition. Even in a language like HOBiT, where programmers are allowed (and indeed encouraged) to approach BX programming from the convenience of conventional unidirectional programming, there are still (necessary) additional code components that need to be added to the basic program structure to specify non-trivial backward behaviors.

Unidirectional Program as Sketch. In this paper we introduce Synbit, a program synthesis system that makes BX programming more approachable to mainstream programmers. In particular, we propose using unidirectional code (i.e., a definition of get in a Haskell-like language) as a sketch of the bidirectional program (which embodies both get and put). Consequently, programmers familiar with unidirectional programming can obtain bidirectional programs from unidirectional ones and input/output examples. In the neighboring field of software verification, expressing specifications (in our case sketches) as normal code has the effect of boosting the adoption of formal tools in industry (Chong et al. 2020), something that bidirectional programming research as a whole may benefit from.

It is not hard to see that this program sketch idea fits well with the language HOBiT. Unlike most BX languages, HOBiT is designed to keep bidirectional code as similar in structure as possible to how one may program the unidirectional get. Consequently, it is able to benefit from such a sketch and allow the synthesis process to mostly focus on parts of the code that specially handle intricate bidirectional behaviors. This is an attractive solution. On one hand, the specifications are intuitive: users simply write normal unidirectional programs (together with a few input/output examples). On the other hand, the specifications as sketches are useful in the synthesis process Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches

:3

because they reduce the search space. Moreover, this design supports gradual “bidirectionalization” done by incrementally converting existing unidirectional programs into bidirectional ones. As it will be shown in a comprehensive evaluation in Section 4, our system is highly effective and able to produce high-quality bidirectional programs in a wide range of scenarios.

Off-the-shelf synthesis is a non-solution. Before diving into the details of our proposed solution, we would like to take a step back and answer a question that may already be in some readers’ minds: will program synthesis completely replace the need for bidirectional languages? That is, how about using generic synthesizers to derive a put from an existing get in a standard unidirectional language? After all, there already exist bidirectionalization techniques (Matsuda et al. 2007, Voigtländer 2009) that are able to derive a put from a get though in restricted situations.

When applied naively, this approach does not work. As an experiment, we tried using the state-of- the-art program synthesizer Smyth (Lubin et al. 2020) to generate the put from concrete examples and appropriate sketches. To simplify the problem, we ignored the round-tripping property between get and put, and tried to generate any put (even one that violates the laws). However, even in this simplified scenario, the synthesizer failed to find a put for simple examples (see Section 4.3 for more details).

This is not surprising because, while powerful, program synthesis is very hard due to the vast search space. The most common ways in which existing synthesis techniques circumvent this are by picking a reduced domain specific language to generate programs in (Gulwani 2011) and by seeding the program search with a sketch representing the program structure (Solar-Lezama 2009).

In this paper, we are interested in synthesizing general purpose programs and therefore we do not adopt the first strategy.

Ontributions:

• We present an application of program synthesis to the area of bidirectional programming. In particular, we provide an automated technique for generating bidirectional transformations in the language HOBiT (Section 3). The inputs to our procedure are the corresponding unidirectional code and a few concrete examples describing the backward transformation (Section 3.2).

• We exploit bidirectional programming properties, domain-specific knowledge of HOBiT and type information to efficiently prune the search space. In particular, we generate specialized program sketches from the unidirectional code (Section 3.3), which are then filled in a modular manner by separating the solving of dependent synthesis tasks (Sections 3.4 and 3.5).

• We present a classification of bidirectional programming benchmarks based on the amount of information from the source that is being lost through the forward transformation (Sec- tion 4.1). We believe that such a classification is valuable for evaluating the capabilities of our bidirectional synthesis technique.

• We implemented our bidirectional synthesis technique in a tool called Synbit, and used it to generate bidirectional programs for the set of benchmarks discussed above (Section 4). The prototype implementation of Synbit is available in the artifact 1 or the repository2.

Background: The Hobit Language

HOBiT (Matsuda and Wang 2018b) is a state-of-the-art higher-order bidirectional programming language. A distinct feature of HOBiT is its support of a programming style that is close to the conventional unidirectional programming. The design of the language largely separates the core

:4

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang structure of programs (which can be shared with the unidirectional definition of get) from the specification of backward behaviors that are specific to bidirectional programming. In this section, we will introduce the core features of HOBiT with a focus on demonstrating its suitability as a target of sketch-based program synthesis. Curious readers who are interested in the full expressiveness power of HOBiT and the formal systems are encouraged to read the original paper (Matsuda and Wang 2018b).

A Simple Example

Before getting into HOBiT programs, we start with a familiar definition in Haskell below.

𝑎: 𝑥→𝑎: Append 𝑥ys

In the definition, we use explicit case branching (instead of syntax sugar in Haskell) to highlight the structure of the code. Now, for a forward function (get) defined as append, let us investigate what will be suitable behaviors of its put. We denote the put by a HOBiT function appendB :: B[𝑎] →B[𝑎] →B[𝑎].

The B-annotated types (highlighted in blue) are bidirectional types in HOBiT, representing data that are subject to bidirectional computation. B-typed values are manipulated only by operations that satisfy the round-tripping laws, which is enough to ensure the round-tripping property of a whole program (Matsuda and Wang 2018b). As we will see in the sequel, bidirectional types can be mixed with normal unidirectional types to support flexible programming and greater expressiveness.

Bidirectional functions of type B𝜎→B𝜏can be executed as bidirectional transformations between 𝜎and 𝜏in HOBiT’s interactive environment (or, read-eval-print loop) via :get and :put.

[1, 2, 3, 4]

and backwards. > :put (uncurryB appendB) ([1, 2], [3, 4]) [5, 6, 7, 8]

([5, 6], [7, 8])

Note that we have uncurried appendB before execution by uncurryB :: (B𝑎→B𝑏→B𝑐) → B(𝑎,𝑏) →B𝑐so that it fits the pattern of B𝜎→B𝜏for bidirectional execution. Specifically (uncurryB appendB) has type B([𝑎], [𝑎]) →B[𝑎], and its put has type ([𝑎], [𝑎]) →[𝑎] → ([𝑎], [𝑎]).

Now we are ready to explore bidirectional behaviors. Simple Backward Behavior. The simplest behavior of put, as adopted in Voigtländer (2009), is to only allow in-place update of views. In the case of appendB, it means that the changes to the length of the view list will result in an error.

> :put (uncurryB appendB) ([1, 2], [3, 4]) [5, 6, 7, 8]

([5, 6], [7, 8])

> :put (uncurryB appendB) ([1, 2], [3, 4]) [1, 2, 3] Error: ... Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches

:5

To achieve this behavior, a definition in HOBiT reads the following.

𝑎: 𝑥→𝑎: Appendb 𝑥ys

As one can see, this definition is almost identical to that of append with only the language constructs such as case and data constructors being replaced by their bidirectional counterparts (underlined and highlighted in blue) that handle values of bidirectional types.

This simplicity comes from the design of HOBiT, as well as the modesty of the scenario. Given that the function is parametric in the list elements, in-place updates mean that the backward execution may simply trace back exactly the same control flow of the original forward execution.

This can be achieved by recursing according to the original source (the first argument of put) and only using the updated view (the second argument of put) as a supplier of element values. Therefore, no additional specification is required in the code.

Branch Switching. HOBiT is not limited to such simple behaviors. Its bidirectional language constructs seen above set us up for more sophisticated cases. Let’s say that we now want to handle structural updates in the view, allowing the list length to vary.

([5, 6], [7, 8])

> :put (uncurryB appendB) ([1, 2], [3, 4]) [5, 6, 7, 8, 9]

(, [ ])

When the length of the view list changes, we try to change the second list of the source to accommodate that. If the length becomes shorter than that of the first source list, the second source list will be empty and the first source list will also change accordingly.

As one can see, this behavior can no longer be achieved by simply tracing back the original control flow of the forward execution. The backward execution will have to recurse a different number of times from the original, and how this is done will need to be additionally specified in the code. Here enters a definition in HOBiT that does exactly this.

𝑎: 𝑥→𝑎: Appendb 𝑥ys With Not ◦Null By 𝜆𝑠.𝜆.𝑠

The code is longer than the last version, as expected, but the program structure remains the same: the additional specification for more sophisticated backward behavior is modularly grouped at the end of each case branch. Recall that we plan to use the unidirectional code as sketches to synthesize bidirectional code; this resemblance to the unidirectional code means that the synthesizing effort may now concentrate on the part specifying bidirectional behaviors, increasing its effectiveness.

In the above code, we used two distinctive HOBiT features known as exit conditions (marked by the with keyword) and reconciliation functions (marked by the by keyword). Both are for the purpose of controlling the backward behavior, especially when it no longer follows the original control flow (a behavior we call branch switching).

:6

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang Exit conditions. An exit condition is an over-approximation of the forward-execution result of the branch, which always evaluates to True if the branch is taken (dynamically checked in HOBiT).

Hence, an exit condition in a case expression has type 𝜏→Bool if the whole case expression has type B𝜏. The exit conditions are then used as branching conditions in the backward execution. For example, in the above case of appendB, an empty list as view will choose the first branch, as the view does not match the condition not ◦null of the second branch. Exit conditions often overlap; when multiple branches match, the original branch used in the forward execution is preferred. If impossible (as the exit condition of that branch does not hold), the topmost branch will be taken.

Like the case of the in-place update we saw previously, if the view-list length is not changed, then in the backward execution of appendB, the exit conditions of the original branches (now used as branching conditions) are always satisfied, and therefore the original branches are always taken.

The situation becomes more interesting when the view update does change the length of the list, for example by making it shorter. In this case, the view list will be exhausted before the original number of recursions are completed. As a result, the backward execution will now see [ ] as its view input and a non-empty list as its source input. This means that the original branch at this point is the second branch, but the exit condition of that does not hold, which forces the first branch to be taken—a branch switch.

Reconciliation functions. We have seen that exit conditions may force branches to switch, which is crucial for handling interesting changes to the view. However, it only solves half of the problem; naive branch switching typically results in run-time failure. The reason is simple: when branch switching happens, the two arguments of put are in an inconsistent state for the branch; e.g., for append, having an non-empty source list (and an empty view list) is inconsistent for the branch [] →ys. Reconciliation functions are used to fix this inconsistency. Basically, they are functions that take the inconsistent sources and views and produce new sources that are consistent with the branch taken. For example, in the definition above, the first branch will have [ ] as the new source, because a switch to this branch means an empty view and the branch expects the source to be the empty list for further put execution of the branch body. In general, a reconciliation function in a case expression is a function of type 𝜎→𝜏→𝜎, provided that the whole case expression has type B𝜏, with its scrutinee of type B𝜎.

An interesting observation of this particular example of append is that the reconciliation function of the cons branch (i.e., 𝜆𝑠.𝜆.𝑠above) is actually never used. Recall that branch switching only happens when the backward execution tries to follow the original branch but the exit condition of the branch is not satisfied by the updates to the view. This will never happen in the nil branch above with the exit condition const True, which is always satisfied. In other words, regardless of the view update there will not be branch switching to the cons branch and therefore its reconciliation function is never executed. This behavior matches the behavior of append which recurses on the first source list: when the view list is updated to be shorter than the first source list, the recursion will need to be cut short (thus branch switching to the nil branch); but when the view list is updated to be longer, the additional elements will simply be added to the second source list, which does not affect the recursion (and thus no need of branch switching).

In summary, with reconciliation functions, the backward execution may recover from inconsistent states and resume with a new source. This is key to successful branch switching and the handling of structural updates to the view.

Round-tripping. It is also worth noting that branch switching in HOBiT does not threaten the round-tripping properties. Intuitively, the key principle of round-tripping is that a branch taken in a forward/backward execution should also be taken in a subsequent backward/forward execution (Foster et al. 2007, Hu and Ko 2016, Ko et al. 2016, Lutz 1986, Matsuda and Wang 2018b, Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches

:7

Yokoyama et al. 2011). When a brach switches in the backward execution, the new branch will produce a source value that matches the pattern of the new branch, ensuring that a subsequent forward execution will take the same branch. Since the exit conditions are checked as valid post conditions, this correspondence of forward/backward branchings is established, and consequently it guarantees round-tripping. An inappropriate reconciliation function will make the backward execution fail but not break round-tripping. More details can be found in the original paper (Matsuda and Wang 2018b). In this paper, we not only rely on the fact that HOBiT programs always satisfy round-tripping, but we also leverage the principle for effective synthesis (Section 3.5.2).

One can also observe that the exit conditions and reconciliation functions in appendB are quite simple themselves. However, their interaction with the rest of the code is intricate. Programmers who write them are therefore required to have a good understanding of how backward execution works and how it can be influenced, which may not come naturally. This combination of simplicity in form and complication in behavior makes it a fertile ground for program synthesis, which we set out to explore in this paper.

Mixing Bidirectional and Unidirectional Programming. We end this section with another example of variants of append’s backward behavior and its implementation in HOBiT. The example also demonstrates a feature of HOBiT that supports a mixture of unidirectional and bidirectional programming for greater expressiveness. Let us consider the following definition.

Length Ys By 𝜆.𝜆(𝑣: ). [𝑣]

Noticeably, the type of the function is a mixture of bidirectional and unidirectional types, with the second argument as a normal list. Recall that bidirectional types represent data that are updatable; this type means that the second list is fixed with respect to backward execution. We will look at a few sample runs before going into the details of the definition. Note that since the second argument is constant in backward execution, there is no longer the need to uncurry the function; one can simply partially apply it as shown below.

"Apple;"

> :put (𝜆xs. appendBc xs ";") "apple" "pineapple;"

"Plum"

In this case, the second list is ";" and changes in the view can only affect the first list. Any attempt to change the last part of the view will (rightly) fail.

> :Put (𝜆xs. Appendbc Xs ";") "Apple" "Apple."

Error: ... Now let us go back to the definition. The fact that the second argument ys is now of a normal (non-bidirectional) type means that it can be used in the exit conditions and reconciliation functions (which only involve unidirectional terms). During backward execution, the exit conditions dictate that the recursion will terminate (the first branch taken) when the view list is the same length as the original ys. In addition, since ys has a normal type, it will need to be lifted (as a constant) to the bidirectional world by ! so that the case expression becomes well typed. We again refer interested

:8

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang The mixture of unidirectional and bidirectional programming is a challenge to program synthesis as the search space has become much larger. Still, the fundamental has not changed: a definition of

Sketches

In this section, we describe our technique for synthesizing bidirectional programs in HOBiT. Throughout the section, we will use the familiar case of append as the running example.

Overview

Before presenting the technical details, we start with an informal overview of the synthesis process. Synbit takes in a unidirectional program (written in a subset of Haskell) and a small number of input/output examples of the required backward behavior, and produces a HOBiT program that behaves like the input unidirectional program in the forward direction and is guaranteed to satisfy the round-tripping laws and conform to the given examples in the backward direction. More details on the guarantees of our system are given later in Section 3.7.

As an example, in the case of append, we provide the following specification to Synbit.

Append :: [Int] →[Int] →[Int]

append = 𝜆xs. 𝜆ys. case xs of {[ ] →ys; (𝑎: 𝑥) →𝑎: append 𝑥ys} :put (uncurryB appendB) ([1, 2, 3], [4, 5]) [6, 2] = ([6, 2], [ ]) The definition of append above is completely standard. The user-provided input/output example specifies that the view list may be updated to a smaller length. As we have seen in Section 2, append needs to be uncurried before bidirectional execution, which is also reflected in the input/output example above where the source is a pair of lists. One interesting observation is that this bidirectional execution provides a call context of the function to be synthesized, which speeds up the synthesis process by narrowing down the choices of appendB’s type.

For the given specification, Synbit produces the following result.

𝜆𝑠.𝜆𝑣. Case 𝑣of {𝑧: Zs →𝑠}}

As one can see, this program is equivalent to the hand-written definition in Section 2; the only difference is that the synthesized version does not use library functions such as const and null.3 Roughly speaking, the synthesis process that produces the above result involves two major components: the generation of a suitable sketch with holes and the filling of the holes. We will look at the main steps below.

Generation of sketches. The sketch is expected to be largely similar in structure to the uni- directional definition (thanks to the design of HOBiT), but there are a few details to be ironed out. First of all, one needs to decide the type of the target function. Recall that HOBiT is a pow- erful language that supports the mixing of unidirectional and bidirectional programming. Thus, for a type such as append’s, there are several possibilities such as B[Int] →B[Int] →B[Int], 3Obvious cosmetic simplification could be made to part of the code for readability. But that is an orthogonal concern.

Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches

:9

B[Int] →[Int] →B[Int], [BInt] →B[Int] →B[Int], and so on. It is therefore crucial to narrow down the choices to control the search space. The call context in the input/output example(s) in the specification is useful for this step, as it can effectively restrict its type. We will discuss more details on this in Section 3.3. For now, it is sufficient to know that for the specification given in this example, the only viable type is appendB :: B[Int] →B[Int] →B[Int].

The next step is to build a sketch based on the unidirectional definition given in the specification. The type we have from above straightforwardly implies that the case construct in append’s definition is to be replaced by the bidirectional case, which expects exit conditions and reconciliation functions to be added (as holes (□) in the sketch).

𝑎𝑝𝑝𝑒𝑛𝑑𝐵= 𝜆xs. 𝜆ys. case xs of {[ ] →ys with □by □;

(𝑎: 𝑥) →𝑎: Appendb 𝑥ys With □By □}

Both the exit conditions and reconciliation functions are simply unidirectional functions. Thus in theory, one can try to use a generic synthesizer to generate them. However, this naive method will miss out on a lot of information that we know about these functions. Recall that, given a case branch p →e, its corresponding exit condition must return true for all possible evaluations of e; similarly, the results of its reconciliation function must match p and the second argument of the reconciliation function must be an evaluation result of e. We therefore capture such knowledge with specialized sketches, which make use of two types of specialized holes that are parameterized with additional information: exit-condition hole (□e(e)), and reconciliation-function hole (□r(𝑝,𝑒)).

This results in the following sketch for this example. 𝑎𝑝𝑝𝑒𝑛𝑑𝐵= 𝜆xs. 𝜆ys. case xs of {[ ] →ys with □e(ys) by □r([ ], ys);

□R((𝑎: 𝑥),𝑎: Append 𝑥ys)}

In the spirit of component-based synthesis (Feng et al. 2017, Jha et al. 2010), we generate code by composing components from a library that includes case and case expressions, Bool constructors and operators, as well as list and tuple constructors. As we will explain in Section 3.2, this library can be augmented with auxiliary components provided by the user.

In this example, the sketch generation is quite deterministic. In general, especially when multiple functions must be synthesized together and auxiliary components are provided, there could be multiple candidate sketches. In such a case, we use a lazy approach that nondeterministically tries exploring one candidate and generating any other.

Sketch completion step I: shape-restricted holes. With the sketch ready, we can proceed to fill the holes. As a first step in the sketch completion process, we make use of the information captured by the specialized holes to generate some parts of the code for exit conditions and reconciliation functions. This step does not involve any search.

appendB = 𝜆xs. 𝜆ys. case xs of {[ ] →ys with 𝜆𝑣. case 𝑣of {𝑥→□;

𝜆𝑠.𝜆𝑣. Case 𝑣of {𝑧: Zs →□(𝑎: 𝑥)}}

The specialized holes are replaced with 𝜆-abstractions with case structures. The result involves a different type of holes we call shape-restricted holes (□(𝑝)); such holes can only be filled with expressions that may match the pattern 𝑝. For example, for □(𝑎: 𝑥), the empty list is not a valid

:10

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang candidate. A generic hole (□) is a special case where the pattern is a wildcard that matches every term.

For exit conditions, the translation used the information encoded by exit condition holes to figure out when False should be returned—recall that, for a case branch p →e, exit conditions should return False for any results that cannot be produced by e. In the case of appendB, this means that for the second branch in the sketch, the exit condition must return False for any empty list. (Here, z and zs are fresh variables.) For the first branch, this information does not help us eliminate any candidates. (Again, x is a fresh variable.) The case construct generation uses all the information encoded by the exit condition holes. Consequently, the holes left in the sketch are generic ones.

For reconciliation functions, the newly generated shape-restricted holes capture the fact that for a case branch p →e, the result of the reconciliation function must match 𝑝. Thus, the first branch of appendB has □([ ]) while the second one □(𝑎: 𝑥). We further know that the second argument of the reconciliation function must be a result of e, which allows us to generate the case structure shown in the sketch.

Sketch completion step II: search and filtering. The last step is to fill the remaining shape- restricted holes. At this point, we leave off using the information in the unidirectional input program, and turn our attention to the input/output example(s). To fill the holes, we generate 𝛽-normal forms where functions are 𝜂-expanded, and filter the candidates by checking against the examples(s).

A problem with using the example(s) to filter out incorrect candidates is that it is for the whole program, which includes several holes. A naive use of the example(s) means that filtering has to be delayed until late in the synthesis process when all the holes are filled. This is inefficient.

Conversely, our ideal goal is to have a modular filtering process, where we can simultaneously check candidate exit conditions and reconciliation functions independently of each other. For this purpose, our solution is to leverage domain-specific knowledge of HOBiT. Specifically, we make use of the fact that put (𝑠, 𝑣) and get (put (𝑠, 𝑣)) must follow the same execution trace in terms of taken branches, as explained in the discussion on round-tripping in HOBiT (see the corresponding paragraph in Section 2). This enables us to fix the control flow of the put behavior for the given input/output example(s) without referring to exit conditions, so that we can separate the search for exit conditions from reconciliation functions. We will discuss this in more detail later in the overview, as well as in Section 3.5.

Moreover, the use of the trace information also enables us to address the issue of non-terminating put executions. In a naive generate-and-test synthesis approach, some of the generated candidates may be non-terminating, which poses issues for the testing phase. As we assume that the put Here, we assumed that the input/output unidirectional program is terminating for the original and updated sources of the input/output examples. More details on this will be presented in Section 3.5.2.

Filtering of exit conditions based on branch traces. We continue with the partially filled sketch for appendB above (reproduced below), with the holes numbered for easy reference. appendB = 𝜆xs. 𝜆ys. case xs of {[ ] →ys with 𝜆𝑣. case 𝑣of {𝑥→□1;

𝜆𝑠.𝜆𝑣. Case 𝑣of {𝑧: Zs →□(𝑎: 𝑥)4}}

What are the constraints on the holes that we can derive from the input/output example below? :put (uncurryB appendB) ([1, 2, 3], [4, 5]) [6, 2] = ([6, 2], []) Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches

:11

As mentioned above, :put (𝑢𝑛𝑐𝑢𝑟𝑟𝑦𝐵𝑎𝑝𝑝𝑒𝑛𝑑𝐵) ([1, 2, 3], [4, 5]) [6, 2] must choose the branches chosen by :get (uncurryB appendB) ([6, 2], []). We shall call a history of chosen branches a branch trace. For :get (uncurryB appendB) ([6, 2], []), the branch trace is:

(Ii) The Cons Branch (Where Xs Is ),

(iii) the nil branch (where xs is []). We now follow the same trace for :put ((𝑢𝑛𝑐𝑢𝑟𝑟𝑦𝐵𝑎𝑝𝑝𝑒𝑛𝑑𝐵) ([1, 2, 3], [4, 5]) [6, 2]) and each step will give rise to a constraint on the exit condition of the branch.

(i) 𝑎: append 𝑥ys (and therefore the 𝑣) has the value of the updated view [6, 2], and □2 must evaluate to True in this context. Therefore, □2[6/𝑧, /zs, [6, 2]/𝑣] ≡True. (ii) 𝑎: append 𝑥ys (and therefore the 𝑣) has the value of the updated view , and □2 must evaluate to True in this context. Therefore, □2[2/𝑧, [ ]/zs, /𝑣] ≡True.

(iii) ys (and therefore the 𝑣) has the value of [ ], and □1 must evaluate to True in this context. Therefore, □1[[ ]/𝑥, [ ]/𝑣] ≡True. These constraints are useful in generating the exit conditions independently. As a matter of fact, in the case of appendB both □1 and □2 are simply filled by the expression True which satisfies all the constraints.

There are no trace constraints generated for holes 3 and 4 though. So they will be generated according to the shape restrictions only. Hole 3 must be [ ] while Hole 4 can be filled by a non-empty list. Recall that, in this example, the reconciliation functions of the cons branch are never used.

And therefore, arbitrary default terms will fill Hole 4 just fine, which produces the output we saw at the beginning of this subsection. Filtering of reconciliation functions based on branch traces. The branch traces are also used to filter reconciliation functions. (This is not needed in this example as the nil branch was already fixed in the filling of shape-restricted holes and the cons branch can be arbitrary.) The important insight here is that reconciliation functions can be filtered independently from the exit conditions, resulting in significant efficiency gain. The reason is that the branch traces carry all the information that is needed to test reconciliation functions (recall that the exit conditions are only for determining branching in backward execution; and since the branching is known in the branch traces there is no need for exit conditions.). We will see examples of this in Section 3.5.2.

In the rest of this section, we will go through each step of the synthesis process in detail.

Nput To Our Method

Remember from the overview that our technique takes as input some typed unidirectional code and a set of input/output examples illustrating the backward transformation. Formally, this translates

To The Following 4-Tuple 𝐼= (𝑃, Γ, 𝑓1, E):

• 𝑃= {𝑓𝑖= 𝑒𝑖}𝑖is a program in the unidirectional fragment of HOBiT, where 𝑓𝑖= 𝑒𝑖stands for a function/value definition of 𝑓𝑖by the value of 𝑒𝑖. • Γ = {𝑓𝑖: 𝐴𝑖}𝑖is a typing environment for 𝑃; i.e., each 𝑒𝑖has type 𝐴𝑖under Γ.

• 𝑓1 is the entry point function, whose type is expected to have the form 𝜎1 →𝜏1;4 this is used to prune the search space as explained in Section 3.3. 4We use metavariables 𝐴, 𝐵, . . for types in general and 𝜎,𝜏, . for those that can be sources or views. In Matsuda and Wang (2018b), the latter kind of types do not contain B and →, but their implementation does not distinguish the two (which in fact is safe). Thus, we do not strictly respect the restriction on 𝜎-types in our technical development.

:12

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang

• E = {(𝑠𝑘, 𝑣𝑘,𝑠′

𝑘)}𝑘is a (finite) set of well-typed input/output examples for a bidirectional version of the entry point 𝑓1; for the 𝑘-th example, 𝑠𝑘is the original source, 𝑣𝑘is the updated

View And 𝑠′

𝑘is the updated source. The input program 𝑃may contain functions that are not reachable from the entry point but can be used during program generation. We call such functions auxiliary functions and add them to our library of default synthesis components. As mentioned earlier in Section 3.1, the default library includes case and case expressions, Bool constructors and operators, as well as list and tuple constructors.

Example 3.1 (append). For the appendB example, the input is formally expressed as: 𝑃app = {appendB = 𝜆xs. 𝜆ys. case xs of {[ ] →ys; (𝑎: 𝑥) →𝑎: appendB 𝑥ys, uncurryB = . . }} Γapp = {appendB : [Int] →[Int] →[Int], uncurryB : . }

𝑓1App = Uncurryb Appendb

Eapp = {(([1, 2, 3], [4, 5]), [6, 2], ([6, 2], []))}. Here, we omit the definition and the type of uncurryB but state it is a part of the input program.

Generation Of Sketches

As shown in the overview, we start by generating bidirectional sketches from the unidirectional code. The basic idea of the sketch generation is to replace unidirectional constructs with bidirectional ones nondeterministically: when case is replaced with case, exit conditions and reconciliation functions are left as holes. Interestingly, replacing all unidirectional constructs (if they have corresponding bidirectional ones) may not be the best solution; as demonstrated in appendBc :: B[𝑎] →[𝑎] → B[𝑎] in Section 2, we sometimes need to leave some parts unidirectional to achieve the given bidirectional behavior.

The starting point of sketch generation is deciding the type of the target function. We expect the unidirectional code to contain an entry point function 𝑓1 : 𝜎1 →𝜏1 (e.g., uncurry append in Example 3.1). This helps us reduce the number of generated type signatures as we know that the target entry point function to be synthesized must have type B𝜎1 →B𝜏1. Also, we further prune the search space by eliminating type signatures that do not obey the call context in the input/output examples.

Type signature generation. We first define the relation 𝐴{ 𝐴′ as: 𝐴′ is the type obtained from 𝐴 by replacing an arbitrary number of sub-components 𝜎in 𝐴by B𝜎nondeterministically, as long as 𝜎 does not contain function types. We do not replace 𝜎containing function types to avoid generating apparently non-useful types such as B(Int →Int) and B[Int →Int]. Next, we provide the typing environment generation relation Γ { Γ′, where Γ′ is the typing environment corresponding to the bidirectional program.

Definition 3.2 (Generation of Typing Environment). For Γ = {𝑓1 : 𝜎1 →𝜏1} ∪{𝑓𝑖: 𝐴𝑖}𝑖>0, the typing environment generation relation Γ { Γ′ is defined if Γ′ = {𝑓1 : B𝜎1 →B𝜏1} ∪{𝑓𝑖: 𝐴′

□

Type-directed sketch generation. Once we have (a candidate) typing environment Γ′, the next step is to generate corresponding sketches in a type-directed manner. Very briefly, the type system in HOBiT (Matsuda and Wang 2018b) uses a dual context system (Davies and Pfenning 2001). The typing relation can be written as Γ; Δ ⊢𝑒: 𝐴, where Γ and Δ respectively are called unidirec- tional and bidirectional typing environments, and hold variables introduced by unidirectional and bidirectional contexts respectively. See Appendix A.2 for the concrete typing rules.

:13

The sketch generation is done by using a relation Γ′; Δ′;𝐴′ ⊲Γ ⊢𝑒: 𝐴{ 𝑒′, which reads that, from a term-in-context Γ; ∅⊢𝑒: 𝐴, sketch 𝑒′ is generated according to the given target typing environments Γ′ and Δ′, and target type 𝐴′ so that Γ′; Δ′ ⊢𝑒′ : 𝐴′ holds after the sketch has been completed (i.e., no unfilled holes) in a type-preserving way. Notice that Γ′, Δ′ and 𝐴′ are also a part of the input in Γ′; Δ′;𝐴′ ⊲Γ ⊢𝑒: 𝐴{ 𝑒′; i.e., its outcome is only 𝑒′. We omit the concrete generation rules in the main text but put them in Fig. 5 in Appendix A.3, because they are technical but straightforward.

We note that the rules are overlapping (i.e., several may be applicable at a given step), which makes sketch generation nondeterministic. The sketch generation is defined formally as below. Definition 3.3 (Type-Directed Sketch Generation). Suppose that Γ { Γ′. Then, for 𝑃= {𝑓𝑖: 𝑒𝑖}𝑖, the sketch generation relation 𝑃{ 𝑃′ is defined if 𝑃′ = {𝑓𝑖: 𝑒′

Sketch Completion Step I: Shape-Restricted Holes

In general, there will be several possible sketches for a given unidirectional program. As mentioned in Section 3.1, in such a case, we use a lazy approach that nondeterministically tries exploring one candidate and generating any other. In this section we describe the sketch exploration process. In particular, we start by using the information captured by the specialized holes to generate parts of the code for exit conditions and reconciliation functions.

Handling Exit Condition Holes. Remember that an exit condition matching a hole □e(e) should return False for any results that cannot be produced by e. Then, our idea here is to generate code that returns False for values that are obviously not the result of 𝑒. For example, for □e(𝑎: append x ys), we generate code returning False for the empty list.

Let us write P(𝑒) for a pattern that represents an obvious shape of 𝑒, defined as follows (where

Otherwise (𝑥: Fresh)

For example, we have P(𝑎: append x ys) = P(𝑎) : P(𝑎𝑝𝑝𝑒𝑛𝑑𝑥𝑦𝑠) = 𝑧: zs, where 𝑧and zs are fresh, conforming to the second case above. It is quite apparent that any result of 𝑒matches with P(𝑒); in other words, values that do not match with P(𝑒) cannot be a result of 𝑒. Using P(𝑒), we concretize exit-condition holes as below.

Definition 3.4 (Partial completion of exit condition holes). Let 𝑝𝑒be a pattern P(𝑒). Then, the exit-condition-hole partial completion relation □e(𝑒) { 𝑒′, which reads hole □e(𝑒) is filled by 𝑒′,

□

Note that the resulting sketch will contain a generic hole □, whose shape is no longer constrained. For example, □e(𝑎: append x ys) is converted as follows

→False}

Handling Reconciliation Function Holes. Remember that the role of a reconciliation function associated with a branch is to reconcile the original source with the branch by producing a new “original source” matching the branch (Section 2). Thus, when the branch has the form 𝑝→𝑒, the reconciliation function must return a value of the form 𝑝[𝑣/𝑥] where {𝑥} = fv(𝑝). Hence, a natural approach is to generate reconciliation functions of the form 𝜆𝑠.𝜆P(𝑒).𝑝[𝑒/𝑥].

:14

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang However, only considering expressions of the aforementioned form limits the use of user-specified auxiliary functions in reconciliation functions. Instead, we generate reconciliation functions of the form 𝜆𝑠.𝜆P(𝑒).□(𝑝). Recall that the shape-restricted hole □(𝑝) will be filled by expressions shaped 𝑝. This idea is formally written as below.

Definition 3.5 (Partial completion of reconciliation function holes). Let 𝑝𝑒be a pattern P(𝑒). Then, the partial completion relation for the reconciliation function hole, □r(𝑝,𝑒) { 𝑒′, which reads hole

Sketch Completion Step Ii: Search And Filtering

The last step is to fill the remaining shape-restricted and generic holes. This process involves type-directed generation of candidates and filtering based on user-provided input/output examples. For simplicity of presentation, we do not explicitly capture the type of the code to be generated in the shape-restricted holes; instead, we recover it from the sketch and typing environment Γ.

Generating Candidates for Shape Restricted Holes. In this section, we describe the process of filling in shape restricted holes □(𝑝). To achieve this, we generate terms of shape p in 𝛽-normal forms where functions are 𝜂-expanded. Specifically, we produce expressions 𝑈𝑝in the following

𝑛

(𝑝= C 𝑝1 . . 𝑝𝑛or 𝑝, 𝑝1, . , 𝑝𝑛are all variables) To simplify the presentation, we omit 𝑝and write 𝑉or 𝑈if 𝑝is a variable. In this grammar, the purpose of 𝑈is to have cases in the outermost positions (but inside 𝜆); a case in a context 𝐾[case 𝑒of {𝑝𝑖→𝑒𝑖}𝑖] can be hoisted as case 𝑒of {𝑝𝑖→𝐾[𝑒𝑖]}𝑖, which is a transformation known as commuting conversion. If 𝑝is not a variable, we can only generate constructors as specified by 𝑝(𝑝= C 𝑝1 . 𝑝𝑛or (𝑝, 𝑝1, . , 𝑝𝑛) are all variables). Otherwise, if 𝑝is a variable, the only knowledge we assume about it is its type. Thus, any of the productions for 𝑉𝑝would be considered. Note that 𝑥/𝐶are drawn from the current context; i.e., they may be components provided by users.

Types are used for two purposes in this type-directed generation. The rather obvious purpose is to limit the search space for 𝑥and C; notice that, since we know their types, we also know the types of their arguments allowing us to perform type-directed synthesis for them as well. The other purpose is to reduce redundancy with respect to 𝜂-equivalence by only generating 𝜆𝑥.𝑈for function types and cases only for non-function types. A caveat is the generation of 𝑥𝑉1 . . 𝑉𝑛at the scrutinee position of case, which cannot be done in a type-directed way as its type is not given a priori; instead, its type is synthesized by using the type of 𝑥.

Filtering Based on Branch Traces. As explained in the discussion on round-tripping in HOBiT (see the corresponding paragraph in Section 2), we leverage the fact that put (𝑠, 𝑣) and get (put (𝑠, 𝑣)) must follow the same execution trace in terms of taken branches. This enables us to fix the control flow of the put behavior for the given input/output example(s) without referring to exit conditions, making it possible to separate dependent synthesis tasks.

While the example appendB in Section 3.1 only showed how filtering works for exit conditions, we provide next one example illustrating filtering based on branch traces for both exit conditions and reconciliation functions. We conclude with a discussion on pruning away programs that would Synbit: Synthesizing Bidirectional Programs using Unidirectional Sketches

:15

otherwise cause non-terminating put executions. We shall refer interested readers to the extended version (Yamaguchi et al. 2021) of this paper for the formal description of this trace-based filtering process.

Example of filtering exit conditions and reconciliation functions based on branch traces. Consider

𝑓𝑥= Case 𝑥of {Left 𝑥→True; Right 𝑥→False}

that comes with two input/output examples that negate the view and cause the sources to flip: E = {(Left 42, False, Right 42), (Right 42, True, Left 42)}. Suppose that from the given unidirectional code, we obtain the following candidate before any filtering is done.

𝜆𝑠.𝜆𝑣.Case 𝑣of {True →□2};

Right 𝑥→False with 𝜆𝑣.case 𝑣of {False →□3; True →False}

𝜆𝑠.𝜆𝑣.Case 𝑣of {False →□4}}

We first discuss filtering of exit conditions. For the first example, :get f (Right 42) takes the second branch, meaning that we obtain the constraint □3[False/𝑣] ≡True. For the second example, :get f (Left 42) takes the first branch, generating the constraint □1[True/𝑣] ≡True. A solution for these constraints is □1 = True and □3 = True.

Now, let us focus on the reconciliation functions. If we consider the branch trace generated by the get and evaluate the put for the given examples, we obtain the following constraints: • For :put f (Left 42) False, we must switch branches to the second branch, meaning that the reconciliation function corresponding to the second branch gets triggered, generating the constraint: :put f (□4[False/𝑣]) False = Right 42.

• For :put f (Right 42) True, we must switch branches to the first branch, meaning that the reconciliation function corresponding to this branch gets triggered, generating the constraint: :put f (□2[True/𝑣]) True = Left 42.

From these constraints, one possible solution is □2 = Left 42 and □3 = Right 42. While this solution obeys the given example, a better one would be □2 = case 𝑠of {Left 𝑥→𝑠; Right 𝑦→Left 𝑦} and □3 = case 𝑠of {Left 𝑥→Right 𝑥; Right 𝑦→𝑠}; each 𝑠in the branch bodies in □2 and □3 can be arbitrary, as they will never be used. The suboptimal solution could be filtered out by our synthesis engine if other examples such as :put f (Left 37, False) = Right 37 were provided by the user.

As a note, for both the previous example and the running example appendB in Section 3.1, we only generate positive constraints (i.e., that evaluate to True) for the holes in exit conditions. However, in certain cases, negative constraints (i.e., that evaluate to False) may also be generated. This happens when branch switching implies that the original branch’s exit condition evaluates to False. We encountered such situations for lengthTail and reverse in Section 4. In such a case, the choice of reconciliation functions may affect the generated constraints as they specify new sources.

Discussion on pruning non-terminating programs based on branch traces. Using branch traces also helps us prune away programs that would cause non-terminating put executions. It is known that synthesis of recursive functions is a challenging problem (Albarghouthi et al. 2013), especially for programming-by-examples, because a synthesized function may diverge for a given example.

Waiting for a timeout is inefficient and there is no clear way to set an appropriate time limit. In our approach, assuming that the given get execution is terminating for the input/output examples, we whose put execution follows the finite branch trace of the get, and are thus terminating.

Heuristics

In this section, we discuss some heuristics we found effective when exploring the search space. Assigning costs to choices. Our generation is prioritized by assigning a positive cost to each nondeterministic choice in the sketch generation. Programs with lower costs are generated earlier than those with higher costs. An advantage of this approach is that it is easy to integrate with lazy nondeterministic generation methods (Fischer et al. 2011), which is the core of our prototype implementation. Another advantage is that smaller programs naturally have higher priority (i.e., lower costs), as the generation of large programs usually involves many choices, reflecting our belief that smaller programs are typically preferable.

Canonical forms of Bool-typed expressions. Generation of Bool-typed expressions is a common task, especially in our context as exit conditions always return Bool values. However, a naive generation of Bool-typed expressions may lead to redundancies, for example, True && 𝑒and 𝑒may be considered two distinct expressions during the search. So when filling holes of type Bool, we generate expressions in disjunctive normal form, in which atomic propositions are expressions of the form 𝑥𝑉1 . . 𝑉𝑛with 𝑥: 𝐴1 →· · · →𝐴𝑛→Bool ∈Γ. While this eliminates redundancy due to distributivity, associativity and zero and unit elements, it does not address commutativity and idempotence. Provided that there is a strict total order ≺on expressions, both sorts of redundancy could be addressed easily by generating 𝑒2 after 𝑒1 so that 𝑒1 ≺𝑒2 holds. Currently we do not do this in our implementation in order to avoid the additional overhead of checking 𝑒1 ≺𝑒2.

Other effective improvements. In addition to the heuristics mentioned above, we make use of some simple but effective techniques. For example, for case with a single branch, we do not try to synthesize exit conditions or reconciliation functions. An exit condition 𝜆.True and a reconciliation function 𝜆𝑠.𝜆𝑣.𝑠suffice for such a branch. We do not generate redundant case expressions such as 𝜆𝑠.𝜆𝑣.case 𝑣of{𝑧→· · · }. When the pattern 𝑝of a branch does not contain any variables, we deterministically choose 𝜆.𝜆.𝑝as its reconciliation function. For a case whose patterns {P(𝑒𝑖)}𝑖 do not overlap, we do not leave holes in exit conditions as replacing them with True is sufficient.

Soundness And Incompleteness

Our proposed method is sound for the given input/output examples in the sense that it synthesizes a bidirectional transformation such that its put behavior is consistent with the input/output examples, and its get behavior coincides with the given get program for the sources that appear in the examples.

This is obvious because we check the conditions in the last step (i.e., filtering) in our synthesis. It is worth noting that the get behavior of a synthesized function may be less defined than a given get program, because our method may synthesize exit conditions that are not postconditions; recall that they are checked dynamically in HOBiT (Section 2). We heuristically try to avoid this by prioritizing True over False in the synthesis of exit conditions, which works effectively for all the cases discussed in Section 4 but is not a guarantee, especially with components. We could address this by inferring postconditions and using them as exit conditions, which is left for future work.

In contrast, our proposed method is incomplete. This is due to the use of the sketches obtained from the unidirectional code to prune the search space. While this makes our approach efficient, it may remove potential solutions. Such situations are captured by the examples lines and lookup, where the solutions do not follow the sketches, in the experimental evaluation in Section 4.1.

Experiments

We implemented the proposed idea as a proof-of-concept system, Synbit, in Haskell5. Synbit is given as an extension to the original HOBiT implementation (Matsuda and Wang 2018b). We measure the effectiveness of our proposed method in the following three experiments.

• Microbenchmarks, classified in terms of information loss (Section 4.1). • More realistic problems including XML transformations and string parsing (Section 4.2). • Comparisons with the other state-of-the-art synthesis methods (Section 4.3).

The experiments were conducted on a Windows Subsystem for Linux (WSL) 2 running on a laptop PC with 2.30 GHz Intel(R) Core(TM) i7-4712HQ CPU and 16 GB memory, 13 GB out of OS was Ubuntu 20.04.1 LTS. We used GHC 8.6.5 to compile Synbit with the optimization flag -O2. Execution times were measured by Criterion6, a popular library in Haskell for benchmarking, which estimates the true execution time by the least-squares method. Any case running longer than 10 minutes was reported as a timeout.

Icrobenchmarks Classified By Information-Loss

To construct the microbenchmarks, we classify programming problems according to the level of difficulty. Recall that the main challenge of BX is to incorporate the information that is in the source but absent in the view in order to create an updated source. For structure rich data represented by algebraic datatypes, this includes the structure of the source data, especially the part that the get function recurs on. With that, we arrive at the following classes.

Class 1 All information of the recursion structure is present in the view (e.g., map). Class 2 Some information of the recursion structure is present in the view (e.g., append). Class 3 No information of the recursion structure is present in the view (e.g., lookup).

The rule of thumb is that the more information is present in the view, the easier is it to define a put that handles structural changes to the view. Take map as an example, the function is bijective in terms of the list structure. As a result, a put function can share the recursion structure of the get, mapping whatever structural changes from the view back to the source. This becomes harder with the loss of structure information in the view. Take append as an example. The boundary between the first source list, which get recurs on, and the second source list is gone in the view. As a result, if a put function is to share the recursive structure of the get, the backward execution will always try to replenish the first source list first before leaving the remaining view elements as the second source list7. This is what appendB does. Any divergence from this behavior will require a different recursive structure for put, which drastically increases the search space as it loses the guidance of the get-based sketch.

We thus expect that the performance of Synbit varies according to the difficulty classes. For Class-1 problems, synthesis is likely to be successful for any given input/output examples (thus handling any structural changes); for Class-2 problems, synthesis is likely to be successful for some given input/output examples; and for Class-3 problems, synthesis is only possible for input/output examples that are free from structural changes.

The benchmark programs and the synthesis results are summarized in Table 1, which should be read together with Table 2 where the input/output examples used for the experiments are shown (which can also be used as a reference for the forward execution behaviors of the input functions).

Https://Hackage.Haskell.Org/Package/Criterion

7unless we know that the second list is fixed as in appendBc

:18

Masaomi Yamaguchi, Kazutaka Matsuda, Cristina David, and Meng Wang Table 1. The results of experiments for categorized examples

-

Also, we used the following auxiliary functions: equality over natural numbers for lengthTail, reverse and appendBc, and length in addition for the latter two. The definitions of all the functions listed and the full synthesis results can be found in the artifact 8 or the repository9 together with the implementation.

Class 1. As we can see, Synbit handles programs in this class with ease. An interesting case is reverse. On the conceptual level, the function is embarrassingly bijective and should be straight- forward to invert. However, in practice the story is much more complicated, especially for the linear-time accumulative list reversal (the naive non-accumulative implementation has quadratic complexity in a functional language). It is well known in the program inversion literature (Mat- suda et al. 2012, Nishida and Vidal 2011) that tail recursive functions (which are often needed for accumulation) are challenging to handle due to overlapping branch bodies. The reverse definition we use in the benchmark includes a small fix: it takes an additional parameter that represents the length of the list in the accumulation parameter. It is sufficient to guarantee the success of Synbit.

Class 2. As we can see, Synbit also performs well for this class. But as explained above, the success is conditional on the input/output examples that the put is required to satisfy. Take append as an example, if the following example is included, which demands the second list being filled before the original first list is fully reconstructed, the synthesis will fail, as a solution must have a different recursion structure from that of the sketch.

(, )

An interesting case is lines, which splits a string by ’\n’ to produce a list of strings. The synthesis becomes a lot harder when the examples (as seen in Table 2) require the preservation of the existence of the newline in the last position. This combined with structural changes to the view list cannot be captured by the recursion structure of the sketch, which explains the failure.

Class 3. Functions such as lookup completely lose the source structures. Consequently, Synbit will not be able to handle any example of structural changes. In the case of lookup, a structural

:19

Table 2. Input/output examples: for readability, we shall write 𝑛for S𝑛Z (integer constants are also used in snoc, reverse, mapFst and append), and st𝑛/pr𝑛/pr′𝑛for Student "st𝑛"/Professor "pr𝑛"/Professor "pr𝑛’".

([(1, 10), (2, 200), (3, 33)], 3)

change means that the view value is changed to another value associated to a different key in the source (as seen in Table 2). Just for demonstration, if only non-structural changes are considered, as in the following example where the changed view does not switch to a different key, Synbit will be able to successfully generate a program.

([(1, 10), (2, 10), (3, 33)], 2)

However, this is not interesting as the strength of HOBiT lies in its ability to handle structural changes through branch switching.

Arger And More Involved Example

Next, we evaluate Synbit on some larger examples, which are closer to realistic use cases. In particular, we look at two types of transformations: XML queries and string parsing. XML Transformations. We examined six queries from XML Query Use Cases10 (“TREE” Use Case). Table 3 provides brief explanations for these queries and Figure 1 shows the skeleton of the XML document used as the original source for them. Such XML documents are represented in HOBiT by a rose-tree datatype. We ignored Document Type Definitions for simplicity—we could

Serge AbiteboulPeter BunemanDan Suciu

. . .

. .

. .

Fig. 1. An XML document used as an original source for Queries Q1 to Q6. Table 3. Explanations of the examined XML queries: the descriptions are quoted from XML Query Use Case, where “Book1” refers the source XML.

Q1

“Prepare a (nested) table of contents for Book1, listing all the sections and their titles. Preserve the original attributes of each

element, if any.”

Q2

“Prepare a (flat) figure list for Book1, listing all the figures and their titles. Preserve the original

Q3

“How many sections are in Book1, and how many figures?”

Q5

“Make a flat list of the section elements in Book1. In place of its original attributes, each section element should have two attributes, containing the title of the section and the number of figures

Q6

“Make a nested list of the section elements in Book1, preserving their original attributes and hierarchy. Inside each section element, include the title of the section and an element that includes the number of figures immediately contained in the section.” handle such constraints by fusing a partial identity function checking them to a get function. We also provided the constant “title” as an auxiliary component to our synthesis engine.

Table 4 contains the results of this experiment. Column “Updates” indicates the updates of the source query triggered by the given input/output examples, whereas columns “LOCin” and “LOCsyn” denote the number of lines of code in the original and the synthesized query, respectively. The AST nodes synthesised ranges from 73 (for Q4) to 471 (for Q5), corresponding to 17 lines of code for Q4 and 80 for Q5. (The programs are too large to be displayed in the main body of this paper. See Appendix A.5 for the concrete input and output of Synbit for Q1, which serves as a representative of the six to illustrate their complexity.) The reason Q6 takes significantly more time than the rest is that it assumes that each section has a title element. Consequently, when handling insertion of sections, the generated reconciliation function needs to construct a section with a title.

Authors:

Peder EZ Larson 1, 2,* , Jenna ML Bernard1, James A Bankson 3, Nikolaj Bøgh 4, Robert A Bok1, Albert P. Chen 5, Charles H Cunningham 6,7, Jeremy Gordon1, Jan-Bernd Hövener 8, Christoffer Laustsen 4, Dirk Mayer 9,10, Mary A McLean11 12, Franz Schilling13, James Slater1, Jean-Luc Vanderheyden5, 14, Cornelius von Morze 15, Daniel B Vigneron1, 2, Duan Xu1, 2, and the HP 13C

94143, Usa.

Denmark. 5 GE Healthcare, Menlo Park, California, USA. 6 Physical Sciences, Sunnybrook Research Institute, Toronto, Ontario, Canada.

8 Section Biomedical Imaging, Molecular Imaging North Competence Center (MOIN CC), Medicine, Baltimore, MD, USA. Cambridge, United Kingdom.

14Jlvmi Consulting Llc, Dousman, Wi, Usa

#See Acknowledgements for a list of all HP 13C MRI Consensus Group Members This work was supported by the ISMRM Hyperpolarized Media MR Study Group, the ISMRM Hyperpolarization Methods & Equipment Study Group, and the Hyperpolarized MRI Technology Resource Center (NIH/NIBIB grant P41EB013598).

Abstract

MRI with hyperpolarized (HP) 13C agents, also known as HP 13C MRI, can measure processes such as localized metabolism that is altered in numerous cancers, liver, heart, kidney diseases, and more. It has been translated into human studies during the past 10 years, with recent rapid growth in studies largely based on increasing availability of hyperpolarized agent preparation methods suitable for use in humans. This paper aims to capture the current successful practices for HP MRI human studies with [1-13C]pyruvate - by far the most commonly used agent, which sits at a key metabolic junction in glycolysis. The paper is divided into four major topic areas: (1) HP 13C-pyruvate preparation, (2) MRI system setup and calibrations, (3) data acquisition and image reconstruction, and (4) data analysis and quantification. In each area, we identified the key components for a successful study, summarized both published studies and current practices, and discuss evidence gaps, strengths, and limitations. This paper is the output of the “HP 13C MRI Consensus Group” as well as the ISMRM Hyperpolarized Media MR and Hyperpolarized Methods & Equipment study groups. It further aims to provide a comprehensive reference for future consensus building as the field continues to advance human studies with this metabolic imaging modality.

Keywords: Hyperpolarized MRI, metabolic imaging, carbon-13, pyruvate, dissolution dynamic

Introduction

MRI with hyperpolarized 13C agents, also known as hyperpolarized (HP) 13C MRI, has shown great potential as a novel imaging modality, particularly for its ability to probe metabolic processes in real time. The first human studies with HP [1-13C]pyruvate were performed in 2011 in prostate cancer patients (1).

Since then, there have been over 60 papers published with imaging results of human subjects from 13 different sites, with applications including prostate cancer, brain tumors, breast cancer, kidney cancer, pancreatic cancer, metastatic disease, liver disease, ischemic heart disease, diabetes and cardiomyopathies. The vast majority of these studies used [1-13C]pyruvate (1–63), where [2-13C]pyruvate (64) and 13C-urea (56) have been demonstrated too.

As clinical HP 13C MRI advances, there is a growing need to build consensus for best practices, which are critical for comparing data across sites, performing multi-site trials,deploying methods to new sites, partnering with vendors, and potentially for obtaining broader regulatory approvals.

In March 2022, we initiated an effort to build consensus within the HP 13C MRI community with this opportunity in mind, and it was greeted with strong enthusiasm. The “HP 13C MRI Consensus Group”, containing over 55 members from 27 sites, identified the area of greatest need and opportunity for consensus building to be HP [1-13C]pyruvate human

●

Pyruvate is the most mature and widely used HP agent and has the most significant translational evidence emphasizing the potential clinical impact.

●

Clinical trials, particularly multi-site trials, have the strongest need for consensus methods to ensure that data can be combined across sites. This work is a Position Paper for which the goal is to describe current successful practices and study methods for HP [1-13C]pyruvate human studies along with justification to support those practices. This is divided into four major topic areas: (1) HP 13C-pyruvate preparation, (2) MRI system setup and calibrations, (3) data acquisition and image reconstruction, and (4) data analysis and quantification (Fig. 1). The current successful practices and study methods include a literature review of published peer-reviewed journal papers showing human HP [1-13C]pyruvate study data, up to September 2022 (1–63), as well as new unpublished information from surveys of HP 13C study sites. Based on this information, we also highlight the evidence gaps, strengths, and limitations of current practices which are summarized at the end of each section.

Figure 1: Illustration of the HP 13C MRI human study process, including the 4 major areas covered in this paper: Hyperpolarized 13C-pyruvate preparation, MRI system setup and calibration, Acquisition and Reconstruction, and Data Analysis and Quantification.

Figure 2: Anatomical targets of HP [1-13C]pyruvate MRI human studies published up to September 2022.

Hyperpolarized 13C-Pyruvate Preparation

This section covers the processes for creating the HP agent, 13C pyruvate, and will include many aspects and considerations that are needed to safely and effectively prepare doses for metabolic imaging studies in human subjects. These include material, personnel, equipment and facility, fluid path preparation, quality control, and release.

It is helpful to understand that the specifications of a dose of 13C pyruvate suitable for in vivo MR HP metabolic imaging were shaped in part by early preclinical studies performed by GE HealthCare summarized in Ref. (65). In short, the safety of the two novel drug components, 13C pyruvate and the electron paramagnetic agent (EPA) AH111501, were demonstrated in those studies. The more precise formulation of the dose suitable for human use was then determined from clinical studies (66) that included two Phase 1 clinical trials in young and elderly healthy volunteers without hyperpolarization of the 13C nuclei and another Phase 1/2a dose escalation and imaging feasibility study with HP 13C pyruvate in 31 prostate cancer patients at the With the exception of the first HP 13C imaging clinical trial, which utilized a prototype device in a cleanroom (1), all HP 13C studies performed in humans to date have utilized the SPINlab polarizer (manufactured by GE HealthCare). Consequently all doses of the HP 13C pyruvate delivered by SPINlab have been produced using the “SPINlab Pharmacy Kit” that serves as the container-closure system for the various drug components (13C pyruvic acid and EPA mixture, dissolution medium, and neutralization and dilution medium) during sample polarization, dissolution and quality control (QC) processes. Thus many aspects of the HP sample preparation considerations discussed below are related to the SPINlab instrument and the consumables designed to be used with it (67).

General Considerations

While more than 860 patients or healthy subjects having been injected with HP 13C pyruvate as of January 2022 without reports of any serious adverse events (68), HP 13C pyruvate injection remains an investigational MR contrast agent and can only be administered by those with Investigational New Drug (IND) exemption from the Food and Drug Administration (FDA) in the USA, a Clinical Trial Application (CTA) in Canada, approval from National Research Ethics Committee Services in the UK, or approval from the relevant local regulatory body. Thus, methods and processes involved to produce a dose should have patient safety as the first priority. Since utilizing dissolution dynamic nuclear polarization (dissolution-DNP) for human use is still a relatively new development, there are no existing published regulatory guidelines specifically for this method.

There are two major production styles that determine how various sites approach the agent preparation. In the US, the most common approach is to rely on a sterilizing filter (“Terminal Sterilization”) to ensure sterility of the final product, akin to PET tracer production, where a starting molecule with a radioisotope is processed using various other ingredients to make the final, desired and injectable contrast agent within a necessarily short amount of time (69). For these sites, sterilization of the components and accessories upstream of this filter are not required, although many of them were manufactured and tested following Good Manufacturing Practice (GMP) or Good Laboratory Practice (GLP) requirements. The filling process is usually performed under an ISO 5 laminar flow hood, but a clean room or an isolator is not required.

This approach is typically accompanied by testing the integrity of the sterilizing filter prior to release of the dose for injection. Typically, post release endotoxin and sterility tests are performed using an aliquot reserved from each released dose.

In the UK and EU, the most common approach is to more-closely follow sterile pharmaceutical compounding guidelines (70), where all components and ingredients are required to be sterile or manufactured under GMP guidelines and are assembled and filled within a clean room environment or an isolator system (“Sterile Preparation”). Typically a batch of Pharmacy Kits for HP 13C pyruvate injection are prepared together. The sterility of the final dose is also ensured by batch validation testing, in addition to the sterility of the ingredients and the sterile compounding process. The endotoxin and sterility testing are performed for the process validation but are not performed for each injected dose.

Some institutions fill and assemble the Pharmacy Kit required for a specific study on the same day or the day prior to polarization, dissolution, and patient administration, but others have also demonstrated the feasibility of preparing a batch of kits, keeping them in a -20ºC freezer and using them over a period of a few months.

Beyond the obvious requirements that the process and the facility has to ultimately produce a dose that is safe to inject into a human, regulatory authorities will also focus on the question “Are you in control of your processes?”. To be in control of your process requires an in-depth and broad understanding of all processes involved in pre, post, and during the production process.

Personnel

It is typical and may be required to have licensed personnel involved in the production process depending on local regulations.Typically a pharmacist, radiopharmacist or other similarly qualified person (QP), in charge of the facility where the Pharmacy Kit filling and preparation is taking place, is responsible for the overall process and the release of the injectable dose.

Qualified cleanroom technicians are often involved in the Pharmacy Kit filling under the supervision of the pharmacist or QP. As is required for pharmaceutical compounding or PET tracer production, training requirements and training records for all personnel need to be maintained and available for audit by the FDA or equivalent.

Equipment And Facility

The facility and all equipment need to have standard operating procedures (SOPs) that describe how equipment is used, maintained, and calibrated to comply with relevant legislation. Currently, almost all the filling of the Pharmacy Kit takes place within a compounding laminar flow hood or isolator (typically ISO 5). At some sites, the filling is conducted within a cleanroom, while at others, it is conducted in a dedicated non-cleanroom space, reflecting differences in cleanroom approach and specifications between regulators worldwide (71). Some equipment or facilities, such as the compounding hood or cleanroom, may require external certified laboratories for testing.

Material Handling

Material handling guidelines (69,70) require SOPs detailing a system to track all of the materials involved in the HP production process for a particular patient dose, similar to current good manufacturing practice (cGMP) requirements for material handling for drug compounding. This includes acceptance standards, storage conditions, amount used in the patient dose for each ingredient and materials used in the assembly of the fluid path and Pharmacy Kit. Currently some users choose to open and inspect and sometimes modify the Pharmacy Kits upon arrival, but some users keep them in the sealed packaging until they are required for dose preparation.

Pharmacy Kit Filling And Assembling

As required by an IND or its equivalent, the preparation of the doses of HP 13C agent are detailed in the Chemistry, Manufacturing, and Control (CMC) section of an applicable regulatory submission; an example of this has been made available (72). It describes the processes of filling the Pharmacy Kit with the different components that make up the final drug product, and of assembling the final kit for either storage or immediate use in the polarizer. Special attention should be given to the laser welding process in order to satisfy installation qualification (IQ) and operational qualification (OQ). Typically, the final developed process is validated by process qualification (PQ) runs, during which 3 or more Pharmacy Kits are filled and used and the final HP 13C products are tested for endotoxin and sterility and to confirm that they meet the dose specifications for injections (usually including pyruvate concentration, residual EPA concentration, pH, liquid state polarization level and dose temperature). The data from 3 consecutive PQ runs are submitted as part of the IND submission (or its equivalent), and are often also reviewed by the Institutional Review Board (IRB) where the studies are conducted.

Quality Control And Dose Release

The quality control (QC) and dose release can be separated into two aspects: one is the QC and release of the filled Pharmacy Kit, and second is the QC and release of the HP 13C agent for injection, after polarization and dissolution. For institutions filling a batch of kits and storing them to use over a period of time, typically the batch can be released based on initial validation, environmental monitoring data from the day of kit production, and if filters are used during preparation of any of the components, filter integrity testing. But in some cases one or more kits are used for validation before the batch of kits are released for future use. For institutions that fill only the kits required for specific studies shortly before the experiment, the filled kits often do not go through separate release tests before they are used.

The quality control of the HP 13C pyruvate solution post dissolution is primarily performed to ensure that the agent meets the dose specifications (Table 1) before it is administered to the subject. These specifications target both safety (pH, residual EPA, temperature) and efficacy (pyruvate concentration, polarization, volume). Typically, the pyruvate concentration, residual EPA concentration, pH, dose temperature, dose volume, and liquid state polarization are measured by the QC accessory associated with the SPINlab polarizer. Some users perform a secondary measurement for one of the parameters, such as pH, using a different instrument or pH paper. For sites that do not go through a separate release testing process for batch filled kits, the integrity of the sterilization assurance filter, a part of the Pharmacy Kit, is typically tested as a part of the dose release. It is also common for these users to preserve an aliquot of the final HP 13C pyruvate solution for post-release endotoxin and sterility testing. This testing cannot be completed fast enough to test an individual dose prior to injection, but this is why other processes such as PQ runs and validation testing are done to minimize the chance a subject could be injected with a contaminated dose.

The Final Dose Release And Injection

should be done under the supervision of a licensed professional, based on local regulations.

Some Key Challenges

Many of the challenges associated with HP 13C pyruvate preparation can be attributed to the conditions required for the dissolution-DNP method of high magnetic field (~3-7 T) and very low temperature (~1 K) during polarization, with pressurized and superheated water necessary for the rapid dissolution event. These extreme conditions are quite challenging for the design of the container-closure and fluid path system. In particular, the cryogenic temperature in the polarizer requires special attention to any moisture or ambient (moist) air introduced into that portion of the fluid path, which can form an ice block at ~1 K. This ice can lead to flow restriction during the dissolution event and reduce the strength of the laser welded bond between the cryovial and its cap. This can ultimately produce failures in the dissolution step, including variations in final pyruvate concentration and pH that may fail to meet QC release criteria as well as fluid path ruptures that provide no available dose and result in polarizer down-time.

The polarization of the HP 13C pyruvate sample decays quickly over the span of a few minutes after dissolution, and thus the process of dissolution, QC for release, and injection should be completed as fast as possible to preserve the high polarization level achieved. Any delays in the preparation process, such as transportation time or equipment malfunction, can significantly reduce the final polarization and result in lower quality imaging data.

Current Practices

A summary of data collected from all sites performing clinical trials with HP 13C-pyruvate is shown in Fig. 3 and Table 1, including the specification of the final dose and how the quality control and release of the final dose are performed. There is a split in the Production Style, described in the General Considerations section above, with 8/13 sites using Sterile Preparation versus 5/13 using Terminal Sterilization. While many of the dose specifications show notable differences in acceptable ranges, all of these variations listed in tables have been successfully and safely been used to perform HP 13C pyruvate studies in humans. Their differences depend on the institutions’ preferences, resources and their particular regulatory situation. There is high similarity in pyruvate ranges, temperature ranges, EPA limits, and volume limits. There is modest variability in pH ranges and large variability in the endotoxin test limit. There is a 3-fold difference in acceptable polarization levels, which are measured to ensure a futile dose is not injected since the polarization is directly proportional to SNR. This reflects the decision by several sites to believe that useful data can be still be obtained with suboptimal polarizations.

Figure 3: Hyperpolarized agent preparation methods reported by sites currently performing HP

In House

Table 1: HP 13C-pyruvate preparation parameters, methods, and dose specifications used for quality control testing and release as well as validation. These were obtained from a survey of all sites performing clinical trials with HP [1-13C]pyruvate. The parameters used for product release are noted in bold text, otherwise these parameters are measured for batch validation or other QC measurements. The endotoxin and sterility testing are performed during process validation of the batch and/or post-injection, and largely depends on the agent production approach.

Summary

The overall safety record of HP 13C-pyruvate has been very strong, and the SPINlab hyperpolarizer has proven to provide high polarizations at human sized doses while meeting numerous QC and release criteria. A weakness remains the failure modes of the SPINlab Phamacy Kits (e.g. ice blocks, path ruptures), which are placed under extreme requirements particularly during dissolution. The preparation process still requires a high degree of expertise.

Therefore, there is a significant need to improve the reliability, robustness, and ease of operation for generating HP 13C-pyruvate doses for human studies. Furthermore, there is a divide between manufacturing and sterile compounding style preparation as well as other site-specific practices, resulting in variations in SOPs and justification required to relevant regulatory bodies. There have also been no comparisons between these approaches. It is also unclear what release criteria and QC parameters are truly required to ensure patient safety.

However, all of the reported methods are acceptable and approved by the appropriate regulatory authorities, and have led to the rapid expansion of successful human studies in recent years.

Mri System Setup And Calibrations

This section covers the MRI system setup, including the imaging system, RF coils, phantoms, and prescan calibration methods.

Imaging System

The main prerequisite for a given MRI scanner to be capable of supporting studies with HP 13C is its “broadband” capability to transmit and receive radiofrequency (RF) signal at the frequency of 13C, which is around 4 times lower than 1H. This does not come as a default on clinical MR devices. The transmit power of the broadband amplifier should also be sufficient to support the intended flip angle and RF pulse shape with the employed transmission RF coil(s) for 13C. Most studies to date use relatively low flip angles (< 90 degrees) for HP 13C in order to preserve polarization for time-resolved imaging. The capability to receive 13C signal on multiple channels is also desirable to increase SNR, as discussed further in the “RF coils” section.

The choice of magnetic field strength is primarily dependent on the metabolites’ frequency separation due to chemical shift dispersion and 1H imaging. High field strengths do not enhance hyperpolarized 13C signal as they do for 1H because the signal strength in a HP experiment relies on manipulating the population of quantum energy states outside of the MRI scanner.

However, the injected HP 13C-pyruvate and its metabolic products have greater frequency separation at higher fields, and it may thus be easier to separate and quantify these resonances at higher fields. This comes at the cost of a reduction in the achievable T2* and often reduced T1. As the initial polarization is independent of the imaging field strength it has been proposed that the increased T2* at 1.5T can potentially be exploited to increase SNR by adapting the acquisition bandwidth or reduce off-resonance imaging effects in cases when the decay of the transverse magnetization is dominated by T2* (73). In practice, 3T has been used in all published human 13C-pyruvate studies surveyed (Supporting Table S1), and comprises the majority of scanners currently in use for human studies (Table 3). A field strength of 3T is well-suited for 1H MRI anatomical reference and correlative imaging.

Stronger and more rapidly slewing magnetic field gradients support more rapid spatial encoding, particularly for metabolite-specific single-shot imaging using echo-planar imaging (EPI) or spiral imaging (See “Acquisition and Reconstruction”). Although the spatial resolution acquired for HP 13C imaging is typically much coarser than for 1H MRI, the factor of ~4 in gyromagnetic ratio leads to the same reduction factor in performance of the gradient system, so 13C experiments are potentially more limited by gradient hardware performance. To date, all human studies have used the commercially-available integrated gradient systems provided in clinical MRI scanners.

Optimization of scanner design has understandably focused on minimization of artifacts in 1H MRI, where devices such as room lights, the gradient amplifiers, and the motors driving the patient bed are checked to ensure that they do not produce RF interference at the 1H frequency, but artifacts may arise at other frequencies. Eddy current compensation is also not always appropriately adjusted for nuclei at other frequencies (74). In order to optimize for 13C, many sites have performed checks on phantoms for RF interference, gradient artifacts, and eddy currents (74), including the use of post-hoc gradient impulse response function characterisation and correction, and some vendors have fixed these issues as well.

Rf Coils

For HP 13C imaging studies in humans, RF coils for both 1H and 13C nuclei are needed, with 1H MRI providing an anatomical reference for registration and optional additional multiparametric MRI readouts. At the Larmor frequency of 13C nuclei, the relative contributions from coil noise compared to sample noise increase compared to 1H (73,75), although sample noise still is likely the dominant contributor for human-sized coils at 32.1MHz - the resonance frequency of 13C nuclei at 3T.

The key requirement for human 13C-pyruvate RF coils are that the coil geometry and sensitive volume must cover the volume of interest in the subject. Table 2 and Figure 4 shows coil configurations that have been used and optimized for applications in different anatomic regions.

Volume resonators are most commonly used for transmit, as they surround the subject to

Provide B1 Transmit Across The Fov (B1

+). While 1H relies on a large birdcage (“body”) coil built into the scanner, 13C transmit coils must be placed inside the bore. This takes up valuable space within the magnet, and also has led to the use of designs with relatively inhomogeneous

B1

+. Many human studies have used Helmholz pair resonators for transmit, including the “clamshell coil”, which has a notably inhomogeneous B1

+ Profile But Has Been Used Because Of

relatively easy integration into the scanner bore. B1

+ Variation Results In Variations In The Flip

angles that control the use of the hyperpolarized magnetization and creates errors in common HP metrics (9,76). The exception are head coils, where birdcage designs with highly

Homogeneous B1

+ can be placed around the head while easily fitting inside the bore. As with 1H MRI, higher SNR can typically be achieved by smaller receive coil elements, such as surface coils or phased arrays, and the majority of 13C receive coils used have layouts similar to 1H phased arrays.

RF coil quality control is important to ensure proper functioning of the coils to provide consistent imaging quality, especially with limited natural abundance 13C signal in vivo. It typically involves 1) a physical integrity check of the coil cables and connectors and 2) phantom SNR tests to check the coil’s performance and to monitor it over time (see Phantoms below). An useful reference for RF coil quality control is outlined in the MRI accreditation program of the American College of Radiology (77) and can be adapted for 13C coils.

Notably, configurations for brain and prostate studies used dual-tuned 1H/13C coil designs, which greatly simplify workflow and registration of 1H and 13C images, as no switching of coils is needed.

(1)

Table 2: RF coil configurations reported for human HP [1-13C]pyruvate studies.

Tx = Transmit

coil, RX = receive coil. The commonly used “clamshell” TX coil is a Helmholz pair design. For 1H RF configurations, all used the Body coil for TX unless otherwise noted, and “repositioned” indicates the 13C coil was removed for 1H imaging. One representative reference is listed for each configuration. The RF coil configurations reported in the reviewed papers are shown in Supporting Table S1.

Figure 4: Examples of RF coil configurations used for human HP [1-13C]pyruvate brain studies. (A,B) 13C Clamshell TX (Helmholz pair) and 2× 4-channel paddle RX arrays. (C) 13C Birdcage volume TX and 32-channel RX array (RX array slides into TX coil). (D) 13C Birdcage volume TX and 24-channel RX array, combined with a 1H 8-channel RX array. Image reproduced with permission from Ref (16).

Phantoms

Since hyperpolarized magnetization is non-renewable, phantoms containing 13C nuclei are important to: 1) test the multi-nuclear capabilities of the imaging system, including all parts of the signal excitation and receive chain; 2) perform calibration measurements before a scan with hyperpolarized nuclei; and 3) perform necessary pre-scan adjustments (see “Prescan Calibration” section). The phantoms currently in use are listed in Table 3. Their composition must provide sufficient 13C signal, with additional considerations of conductivity, stability, chemical shift(s) present, potential for dynamic imaging, and cost. The phantom geometries are typically either compact, in order to be used alongside the subject during a HP scan, or large enough to mimic the inner volume of a RF coil for system testing.

One popular compact design contains enriched 13C-urea at high concentration, typically 8 M, which provides a single resonance, placed inside a small container ~1 mL. The most common recipe mixes 13C-urea in a 90% water/10% glycerol solution, with glycerol used to increase the urea solubility and doping with a Gd-based contrast agent to shorten T1 which increases the potential SNR per unit time. For example, when Dotarem is added at a 3:1000 volume ratio the 13C-urea T1 is around 500 ms and T2 is around 100 ms. However, when testing pulse sequences influenced by T1 and T2, doping should be used carefully. This phantom is suitable for frequency calibration, transmit gain calibration, sequence testing, and as a fiducial marker when placed next to a patient. However, enriched 13C-urea has a relatively high cost compared to natural abundance compounds.

For larger volumes (>100 ml), the phantoms most often used contain undiluted ethylene glycol, glycerol, or dimethyl silicone. These compounds have sufficiently high carbon concentrations to provide sufficient 13C signal even with the 1.1% natural abundance of 13C. These larger phantoms matching the inner volume of an RF coil are useful for coil testing, including transmit

+) And Receive (B1

-) coil profile mapping, as well as to mimic acquisitions using in vivo FOV requirements. In this case, size and conductivity should match the expected subject size in order to mimic coil loading and get a realistic estimation of B1+. Large-volume natural abundance urea phantoms have also been used by some sites, but suffer from higher conductivity compared to biological tissues. Typically, it is easier to increase the conductivity and hence coil loading of the non-conductive phantom by adding NaCl to match physiological loading (16,78).

Dynamic phantoms that aim to mimic metabolite kinetics have also been developed (79–81), and have the potential to more closely mimic the HP experiment, but so far these are not widely used.

Prescan Calibration

Prior to performing an MRI acquisition, the so-called prescan procedure is used to set the shim parameters to maximize B0 homogeneity over the field of view (FOV) or a specific region of interest (ROI), the scanner center frequency (CF), the RF transmit gain, and the receiver gain.

While this calibration procedure is usually automated for 1H, the lack of sufficient natural abundance 13C signal prevents use of automated methods. (Although natural abundance 13C lipid signal has been detected, there are so far no reports on using this signal for prescan.) Table 3 shows current practices across sites.

Maximizing B0 homogeneity is independent of the nucleus and is therefore performed prior to 13C imaging using the 1H water signal and existing shimming tools, such as by a standard automated process (“Auto Shimming”) or using high order shimming routines. Similarly, the 13C CF can be calculated from the 1H CF using a predetermined scaling factor that depends on the target chemical shift (82). Another common approach used is to have a small, high-concentration 13C phantom, e.g. 8M 13C-urea, integrated in the RF coil or placed next to the scan subject (1). The reference frequency can also be based on real-time measurements after the HP injection but prior to imaging (83). Both the CF and B0 shimming are critical when using spectrally-selective RF pulses, as inmetabolite-specific imaging methods, where the desired excitation bandwidths are typically very narrow and frequency offsets can lead to a failure mode that is only apparent after injection.

The calibration of the RF transmit power is typically performed on a small, high-concentration 13C phantom placed near the region of interest during the scan or on a large 13C phantom of similar size and coil loading as the subject, prior to the subject scan. Reference power is often done by sweeping the power in a pulse-acquire sequence (53,62), or the Bloch-Siegert method (52,84). When using a small phantom, the location of the phantom, B1

+ Inhomogeneity As Well

as any shielding effects, e.g., when the phantom is integrated into a coil (1), may degrade the accuracy. Other methods include real-time Bloch-Siegert method measurements after the HP injection (83), and using the stronger natural abundance 23Na signal that is close enough to the 13C resonance frequency to be detected by 13C coils (82).

The receiver gain is predetermined, either systematically based on independent phantom measurements and assuming the dose and polarization of the HP compound is known prior to injection, or based on past HP imaging studies.

Power [Kw]

Phantom(s) - during study Phantom(s) - before study 13C Frequency

8

13C-bicarbonate doped with dimethyl silicone, various

Power [Kw]

Phantom(s) - during study Phantom(s) - before study 13C Frequency

Maximum Values

Table 3: Summary of the imaging systems, phantoms, and prescan procedures used at sites currently performing HP 13C-pyruvate human studies. These were obtained from a survey of all sites performing clinical trials with HP [1-13C]pyruvate. *Previously performed studies with a Siemens 3T Tim Trio. The imaging systems, phantoms, and prescan procedures reported in the reviewed papers are shown in Supporting Table S1.

Summary

Commercially available 3T MRI systems are by far the most commonly used for human HP 13C-pyruvate studies, although a systematic investigation of the impact of B0 has only recently been investigated (73). The multi-nuclear RF transmit and receive chain has proven sufficient for current acquisition strategies, although many sites have observed artifacts due to RF interference, gradient interference, and residual eddy currents when operating at the 13C frequency. A variety of 13C RF coils, tailored for numerous anatomical targets, have been successfully demonstrated, with the main limitation that most transmit coils take up a lot of additional space inside the bore and provide relatively inhomogeneous B1

+ Profiles. The

phantoms used have converged into generally 2 categories - small phantoms containing 13C-enriched compounds that can be used during the study and human-sized phantoms containing compounds with high carbon concentrations but without 13C enrichment that are used to test and calibrate the coils. There are no standardized compositions or geometry, and dynamic phantoms that recapitulate in vivo kinetics would be desirable but are still an emerging area. Prescan calibration procedures were not well defined in most publications, so we surveyed individual sites to determine current practices. Calibration procedures for the B0 field (13C CF and shimming) for most sites take advantage of 1H signal and methods, while methods

For Calibration Of B1

+ is more variable across sites, likely a reflection of remaining challenges in how to perform this calibration. Standardization of both phantoms and calibration procedures would synergistically improve the robustness and reproducibility of HP 13C studies.

Acquisition And Reconstruction

Data acquisition strategies in human HP [1-13C]pyruvate MRI studies must account for multiple chemical shifts, efficiently utilize the non-renewable HP magnetization, and acquire data quickly relative to metabolism and relaxation decay processes. These studies require spectral encoding to separate metabolites, necessitating pulse sequences that efficiently encode up to 5D data (3 spatial + 1 spectral + 1 temporal dimension). RF pulses must efficiently sample without immediately saturating the non-renewable HP magnetization, and sequences must acquire data quickly and be robust to both experimental and physiologic variation (e.g. B1

+ Inhomogeneity,

variation in perfusion) to ensure reproducibility and minimize scan-to-scan variability. This section covers current successful practices for data acquisition in human [1-13C]pyruvate studies, and accompanying 1H imaging, from different anatomic regions, including scan parameters and image reconstruction.

Acquisition And Reconstruction Methods

The acquisition methods used in human [1-13C]pyruvate studies can be classified into 3 categories: 1) MR spectroscopy or MR spectroscopic imaging (“MRS/I”), 2) chemical shift encoding methods, and 3) metabolite-specific imaging (Fig. 5).

Mrs/I Methods Specifically

resolve a spectrum that can be analyzed to extract expected as well as unexpected resonances, making this approach very robust. It was used in many initial studies (1).

Chemical Shift

encoding methods, most commonly the Iterative Decomposition of water and fat with Echo Asymmetry and Least-squares estimation (IDEAL) method, use imaging sequences acquired with multiple TEs and rely on a model-based separation of expected chemical shifts (85).

Metabolite-specific imaging methods use specialized RF pulses that are spatially and spectrally selective to excite individual metabolites which are then typically imaged with fast k-space trajectories such as echo planar imaging (EPI) or spirals (86).

Their Application To Different

organ systems is described below. The image reconstruction methods used in human [1-13C]pyruvate studies have typically been conventional methods (e.g. FFT, non-uniform FFT, or equivalent). The incorporation of accelerated imaging and advanced reconstruction methods including parallel imaging (4,57,87) and compressed sensing (7) has also been applied in human studies for improved spatial resolution, temporal resolution and coverage, but have the potential for additional artifacts as well as SNR losses due to ill-conditioning of the reconstruction (e.g. g-factor).

The Majority Of

published studies do not use accelerated imaging indicating the resolution and coverage achievable without acceleration is currently adequate for successful data collection. Performing coil combination, even with fully sampled data has also been shown to have specific challenges for HP human images: using naive sum-of-squares methods suffer from high noise amplification in the relatively low SNR regime of HP [1-13C]pyruvate (compared to 1H), motivating several HP 13C-specific methods that include data-driven coil sensitivity estimation which have shown obvious improvements over sum-of-squares (11).

More recently denoising techniques have been applied as post-processing of human HP data(41,42,44). The techniques applied are based on spatial-temporal singular value decomposition for unsupervised estimation of signal and noise components. They have shown improvements in apparent SNR in the brain and liver, while care must be taken to choose parameters such as the rank threshold to avoid oversmoothing and overfitting to the estimated signal components.

Prostate Studies

Prostate cancer was the first human application of HP [1-13C]pyruvate (1), and data was acquired with MRS/I methods: 1D dynamic MRS, single-slice 2D dynamic echo-planar spectroscopic imaging (EPSI), and single time point 3D EPSI. Advances in imaging strategies led to the development and application of new acquisition schemes, including undersampled 3D EPSI with compressed-sensing (7), model-based chemical shift encoding methods that use a priori information (47,59), and metabolite-specific EPI (10), all of which can provide volumetric whole-organ coverage and dynamic acquisitions.

The pyruvate bolus arrival in the prostate can vary by ± 10 s between patients, necessitating dynamic imaging to reliably and consistently capture the pyruvate bolus (18). For this reason, all currently ongoing studies acquire dynamic data. While MRS/I, chemical shift encoding, and metabolite-specific imaging can all achieve dynamic imaging, chemical shift encoding and metabolite-specific imaging provide greater dynamic and volumetric coverage (85). For scan prescriptions, the FOV is designed to provide full prostate coverage and typically to match the orientation of the anatomic imaging used for registration. Flip angles used in current studies are constant through time, as quantification with a variable-through-time flip scheme is highly sensitive to bolus timing (8) and errors in the RF transmit (B1 +) field (76).

Heart Studies

Data acquisition methods for 13C imaging in the heart must be designed to meet the demands of significant cardiac motion and blood flow. To cope with the periodic cardiac motion, most human heart studies to date used gating to the diastolic window, the longest cardiac cycle interval, which has reduced motion (2,22,28,30,35,36,38,45,52). The duration of the diastolic window limits the available data sampling time, making cardiac acquisitions the most time-constrained of the HP 13C MRI applications. The most common acquisition approach is metabolite-specific imaging with spiral k-space trajectories (2). Their single-shot imaging capability makes these methods particularly robust to motion effects. Furthermore, spiral k-space trajectories provide rapid k-space coverage and relatively benign flow and motion artifacts. The majority of studies have used 2D multi-slice acquisitions, but 3D encoding has also been used successfully (35).

Brain Studies

For HP 13C MRI of the human brain, the majority of studies have also used 2D (slice selective) acquisitions (10–12,14,16,28,33,40,41,44,51,53,60), with a trend toward volumetric coverage using 2D multi-slice metabolite-specific imaging. 3D metabolite-specific imaging of the whole brain, with phase encoding of the slice direction (34,57), has been shown to provide similar SNR efficiency (88) compared with multislice imaging. A number of studies have employed MRS/I (5,6,29,31–33,50,55) resulting in a spectrum from each voxel, which has the advantage of not requiring a priori information about which peaks to encode. This was important in early brain studies when it was not known which peaks would be detectable. Chemical shift encoding, using a set of images with different echo times and an iterative reconstruction of the individual resonances (i.e. the IDEAL approach (85)), has also been used (12,49,54), with the drawback that coverage in the slice direction was limited due to the time required to acquire multiple echo time images.

Abdomen And Breast Studies

The fundamental approaches to data acquisition and reconstruction in the abdomen and breast are largely similar to the aforementioned applications, but demand attention to particular challenges associated with these anatomic regions, especially relating to respiratory motion.

Although it has been shown that a basic 2D MRSI approach based on phase encoding and FID readout can be successfully applied for HP 13C imaging in breast (15) and kidney (13), major advantages in terms of spatiotemporal resolution and coverage have been realized using tailored approaches based on metabolite-specific imaging (43,62) and chemical shift encoding (43), which have facilitated multi-slice or 3D dynamic acquisitions over large FOVs in the abdomen (4,37,46).

The significant respiratory motion encountered in these regions can directly blur 13C images, and has further favored these rapid acquisition strategies. Motion also degrades B0 homogeneity, which can shift frequency-selective excitation profiles and introduce artifacts into rapid imaging readouts. This makes accurate determination of the acquisition center frequency and shimming essential in these regions which often cover large FOVs. (See “Prescan Calibration” section for more information). In some studies, breath-holding was used to minimize motion effects and enforce frame-to-frame data consistency (42). A pragmatic and reasonably effective approach for dealing with respiratory motion during 13C data acquisition is an initial breath-hold (as long as can be tolerated), followed by free-breathing (46,62).

1H Imaging

Collection of 1H imaging data is essential both for prescribing the 13C acquisition and for interpretation of the resulting 13C data. Multi-planar 1H scouts are acquired prior to 13C acquisition to enable graphical prescription of the 13C imaging region. All human HP 13C-pyruvate imaging studies acquire conventional MRI scans (e.g. T1- and T2-weighted volumes) for anatomic reference, aiming to cover at least the full 13C FOV. Acquiring these anatomic scans as close as possible to the time of 13C imaging (immediately before or after) minimizes potential misregistration between the data sets. Depending on the application, other advanced 1H sequences are also acquired (e.g. diffusion-weighted imaging for cancer imaging).

When contrast-enhanced data is acquired, it is done after 13C imaging, as paramagnetic contrast agents will accelerate 13C relaxation.

Reported Study Parameters

Figures 5 and 6, and Supporting Table S2 shows the reported acquisition study parameters for human HP [1-13C]pyruvate studies published as of September 2022. Figure 5 shows a mixture of MRS/I, metabolite-specific imaging, and chemical shift encoding methods have been successfully used, where spectroscopy-based methods have become less prevalent in recent studies. Figure 6 shows the acquisition timing, including the important start time and interval/temporal resolution, is quite variable across studies.

Figure 5: Acquisition methods used in published HP [1-13C]pyruvate human studies published up to September 2022, classified into: MR spectroscopy and spectroscopy imaging (MRS/I); chemical shift encoding methods, such as IDEAL, that use multiple TEs and model-based reconstructions; and metabolite-specific imaging methods that use spectrally-selective excitation to image a single resonance at a time.

Figure 6: Temporal acquisition characteristics reported in HP [1-13C]pyruvate human studies published up to September 2022. (a) Reported referencing of acquisition start times.

(B)

Acquisition start times reported when using dynamic imaging and when timing was reported relative to the end of the injection. (c) Temporal resolutions. “Not Applicable” indicates dynamic imaging was not used.

Summary

Three general categories of acquisition strategies have been used successfully for human HP 13C-pyruvate studies: MRS/I, model-based chemical shift encoding (e.g. IDEAL) methods, and metabolite-specific imaging methods. These have enabled successful studies in the prostate, heart, brain, abdomen, and breast. Recent studies increasingly have used the imaging-based strategies of metabolite-specific imaging and chemical shift encoding which are the fastest methods, although a heads-to–head comparison between techniques has not been performed.

Metabolite-specific imaging is quite popular because of its speed and compatibility with single-shot imaging, but is sensitive to B0 field variations and thus requires careful calibrations. Nearly all studies surveyed acquired data dynamically, allowing measurement of the bolus and metabolite kinetics. The exact timings and associated flip angles vary quite widely across reported studies, with no consensus yet as to how to choose these parameters. Image reconstruction is typically done directly using Fourier Transform methods, and accelerated imaging strategies are uncommon.

Data Analysis And Quantification

This section covers the analysis of data from human HP [1-13C]pyruvate studies, including modeling and metrics, visualization, as well as considerations for how to store data and metadata. Depending on study design, the analysis may need to give quantitative or semi-quantitative output reflecting a biological process or may just reflect a contrast between different regions of interest for quantitative evaluation.

Metrics

Figure 7: HP [1-13C]pyruvate raw data (A) have typically been quantified using four categories of metrics depending on the acquisition. Data acquired as a single time point are often quantified using normalized metabolite images or metabolite ratios (B). Dynamic data can be quantified using normalized metabolite images or metabolite ratios (B), or with metabolite timings such as time-to-peak (TTP) or pharmacokinetic (PK) models (C). The latter two require the data to be time-resolved. [1-13C]alanine and 13C-bicarbonate are analyzed similarly to [1-13C]lactate but omitted here for display.

Metabolite images are commonly used as summary metrics for HP MRI data, often including some form of normalization as well as summed over time as an area under the time curve (AUC) (17). These are analogous to the visual evaluation that is most used for routine clinical work (89,90). In these metabolite images, we expect that the [1-13C]pyruvate AUC signal is predominantly weighted towards perfusion and uptake, while [1-13C]lactate, [1-13C]alanine and 13C-bicarbonate AUCs represent metabolic conversion. The strength of this approach lies in its simplicity and relatively few underlying assumptions. Limitations to the use of single-metabolite images or AUCs include sensitivity to inhomogeneous coil profiles (57,87,91), the acquisition strategy and acquisition parameters, pyruvate polarization and concentration level, and signal relaxation rates (92). Further, the reader must be careful to interpret all the images in conjunction to better understand the underlying biology; for example, increased [1-13C]lactate in the presence of decreased [1-13C]pyruvate delivery can have a very different meaning compared to increased [1-13C]lactate with increased [1-13C]pyruvate delivery.

In an attempt to address variations in coil sensitivity, polarization level, and pyruvate delivery, AUC images are often computed by normalizing to a specified parameter, such as the maximum pyruvate or average lactate signals, or presented as a ratio such as lactate/pyruvate or divided by “total Carbon” - the sum total of HP 13C signal observed across all metabolites. The AUC ratios between metabolites and pyruvate are proportional to the corresponding forward kinetic rates (81,93), but are not directly comparable to rate constants when magnetization loss rates (e.g. relaxation and losses due to signal excitation) differ between studies. Similarly, the ratios between the produced metabolites (e.g. bicarbonate/lactate) can reflect the balance between downstream metabolic pathways (12,55). Care must be taken to consider how AUC images are calculated and normalized before comparing values between studies.

To further quantify the interpretation, pharmacokinetic (PK) modeling approaches were developed to compute the apparent kinetics of pyruvate-to-metabolite exchange (92,94–99). These yield semi-quantitative to quantitative apparent rate constants, given in s-1. Some models require a vascular input function, while others avoid this requirement (95). PK models can explicitly account for acquisition-specific details such as excitation angle and repetition time, and thus may reduce the effects of these details on quantification. An input-less model, provided in the Hyperpolarized-MRI-Toolbox (https://github.com/LarsonLab/hyperpolarized-mri-toolbox) (100) and thus frequently employed for human data, has been shown to fit well and robustly to prostate and brain data (8,20). PK models are quantitative in nature, arguably provide more relevant biological information (8,20), and appear to be reproducible across sites (51). However, rate constants derived from PK models are still apparent rates, and likely do not reflect a single biological characteristic.

Some additional considerations include whether complex or magnitude data is used, as the noise behaviors will impact the analysis differently. Additionally, cut-off thresholds or other criteria may be used to identify and avoid voxels with insufficient SNR before analysis to improve robustness (20,41).

Regardless of the analysis approach, the underlying biology is not always clearly represented by the data; instead, the metrics may be influenced by perfusion, barrier permeability, intercellular shuttles, enzyme activities, co-substrate concentrations, or combinations thereof, depending on the organ and disease of interest (19,43,94,101–103). This may be addressed by incorporating complementary information. As an example, HP 13C pyruvate data is influenced by perfusion, and thus addition of perfusion MRI could be important for interpretation (98,104,105).

All the methods outlined above have been explored in clinical studies, described in Supporting Table 3 and summarized in Figure 8. As of September 2022, approximately 52% of studies involving human subjects report rate constants derived from a PK model with a few different models reported. A nearly equal fraction (51%) of the studies report AUC ratio values.

Approximately 66% of these studies report metabolite-specific images or AUC values. About 40% report SNR values; this metric is particularly frequent in manuscripts that describe technical developments for clinical HP MRI. Approximately 16% of these studies summarize model-free metrics, and 10% report measurements from a single timepoint. Most studies report a combination of quantities.

Figure 8: Reported metrics used for analysis in HP [1-13C]pyruvate human studies published up to September 2022.

Visualization

A wide variety of approaches have been used for visualizing data from human HP 13C-MRI studies. The challenges and practical considerations are: 1) choosing the appropriate metrics to display, 2) how to encode the parameters (e.g. the colormap), and 3) choosing how to provide anatomical context and other multi-parametric data. The choice of visualization also depends on the goal which could be for diagnostic interpretation, but also quality control, reproducibility among readers and publication.

Metrics

The choice of HP 13C metrics is described in detail above. At this stage in HP 13C development where there is no standardized metric, often a combination of metabolite images and ratios or PK model parameters are shown.

Parameter Encoding

The mapping function chosen should provide an adequate, often quantitative, impression of the parameter mapped. There is a consensus in the visualization field that perceptually uniform maps are best suited to visualize continuous parameters, like the greyscale typically used by radiologists as well as other monochrome (black to blue) and color ranges (fire-type, rainbow-type) (106,107). Multi-color heatmaps have been the most frequently employed method for HP 13C data, while greyscale has infrequently been used but it ensures there is no coloring-based bias as well as facilitating later reuse (Fig. 9a). Among the color schemes employed in the clinical HP 13C literature, fire-type scheme seems to be the most common [similar to “Plasma” or “Inferno” in matplotlib.org]. Next most commonly employed is the rainbow-type scheme [similar to “Rainbow” in matplotlib.org].

Anatomical Context

HP MRI faces the challenge that it does not necessarily depict the anatomical features, similar to PET, and thus requires an anatomical reference. Most often, a grayscale anatomical image is overlaid with a HP colormap (Fig. 9c,d). This approach is very intuitive, but can skew perception as the grey-scale anatomical reference may affect the brightness of the HP data (e.g. signal in the skull). This bias does not occur when showing adjacent maps (Fig. 9a, b). Here, anatomical outlines may help to provide reference (Fig. 9b).

Related Journal Articles & DOI Links

Selected peer-reviewed publications relevant to 12 Lead ECG Acquisition. Click the DOI to access the full paper (may require institutional access).

Why Choose Us?

Bangalore guidance for robotics, Spectre and autonomous systems projects.