dataesr/scientific-paragraphs-categorization huggingface dataset:
QUANTIFICATION AND STATISTICAL ANALYSIS The quantification of the response of the BCM/HCI PDX models to therapy was assessed biweekly with calipers and reported as the log2 fold change relative to the volume before treatment (full details in the methods section). gpGrouper  122  was used to determine the expression of both human and murine proteins and iBAQ values were used to compare samples. Xenome was used to separate and quantify the murine and human expression in each PDX model, and the expression values were upper quantile normalized to account for varying sequencing depth. CopywriteR 115 and GISTIC2. 0  116  were used to determine copy number information. To determine the predictive power of each of the feature selection methods (full details in the methods sections) in the PDX dataset, we trained each model on 70% of the data and determined its accuracy (mean absolute error and root mean squared error) on the 30% test set.
ACKNOWLEDGMENTS This work was supported by  NIH/NCI  grants  U54 CA224076  (to A. L. W, B. E. W, and M. T. L. ),  U24 CA226110 , (to M. T. L. ),  P50 CA186784  (to C. K. O and M. T. L. ),  Dan L. Duncan Cancer Center  ( P30   Cancer Center Support  Grant  NCI-CA125123 ) (to C. K. O. ), a grant from the  Common Fund of the National Institutes of Health (NIH)  ( 5U54 DA036134 ) (to A. M) and the  Henry and Emma Meyer Chair in Molecular Genetics  (to A. M), and by grant  T32 CA203690  from the  Translational Breast Cancer Research Training Program  (to J. T. L. ). This work was also supported by a  Core Facility grant  from the  Cancer Prevention and Research Institute of Texas  ( CPRIT Core Facilities Support Grant   RP170691 ), a grant from the  V Foundation , and a generous gift from the  Korell  family for the study of triple-negative breast cancer.
B. Z. is a  CPRIT Scholar in Cancer Research , and this work was supported by  CPRIT  award  RR160027. This work was further supported by the  Stand Up to Cancer Dream Team Translational Research Grant  ( SU2C-AACR-DT0209 (GMW) ),  DF/HCC Specialized Program of Research Excellence (SPORE) in Breast Cancer, NIH  Grant  P50 CA168504  (GMW) and the  Breast Cancer Research Foundation. Work performed by BCM Mass Spectrometry Proteomics Core was supported by the  Dan L. Duncan Comprehensive Cancer Center Award  ( P30 CA125123 ) and  CPRIT Core Facility Awards  ( RP170005  and  RP210227 ).
Data and code availability d All the code and inputs necessary to recreate the analyses in this manuscript have been deposited at GitHub: https://github. com/vpetrosyan/biomarkers_chemotherapy. DOI: https://doi. org/10. 5281/ zenodo. 7140873 and are publicly available as of the date of publication. d All data required to recreate the BCM/HCI analysis has been deposited at GEO: GSE183187. The PDX Portal: https://pdxportal. research. bcm. edu/ also allows the user to easily query both patient and PDX data. d All data required to recreate the validation analysis is available from: GEO: GSE142767, GSE18864, GSE164458, or the Curie Institute upon reasonable request. d Any additional information is available from the lead contact upon request.
Processing, segmentation, tracking and database generation Raw stacks were projected, corrected for illumination artifacts, and stitched using PreMosa  (Blasse et al. , 2017). The stitched images of individual timepoints were cropped to fit the wing size, registered using the Fiji plugin "Descriptor-based series registration (2D/3D + t)" and converted to 8 bit with Fiji  (Schindelin et al. , 2012). The segmentation was performed with the Fiji plugin TissueAnalyzer  (Schindelin et al. , 2012; Aigouy et al. , 2010; Aigouy et al. , 2016). Segmentation errors were identified and manually corrected by looking at the cell divisions and deaths masks. Subsequent processing and quantifications were performed using TissueMiner  Etournay et al. (2016). Before generating the relational database, we rotated the movies so that the angle formed by a manually drawn line connecting the sensory organs would be 0.
We manually defined the regions of interest, such as the blade, hinge and the anterior and posterior regions, using the last frame of the movie. Next, we generated the relational database containing information about the cellular dynamics during morphogenesis using TissueMiner  (Etournay et al. , 2016). We queried and worked with the data using the Dockerized version of RStudio  (Nickoloff, 2016) , which loads all packages and functions required to work with TissueMiner. Movies were aligned by the peak of cell elongation by fitting a quadratic function around the cell elongation values 40 frames before and after the absolute maximum of cell elongation in the blade region for each movie. The maximum of this curve was identified and set as the timepoint 0 h.
Quantification of the PD component of cell elongation Q xx Prior to all laser ablation experiments, we acquired a stack of 50 µm thick that was projected using PreMosa  (Blasse et al. , 2017). We cropped a region that enclosed the region that was ablated, segmented cells using TissueAnalyzer  (Aigouy et al. , 2010,1)  and generated a relational database with TissueMiner  (Etournay et al. , 2016). The definition of cell elongation was first presented in  (Aigouy et al. , 2010)  and it describes the angle and magnitude of the tensor. The cell elongation tensor is given by     ϵ xx ϵ xy ϵ xy -ϵ xx     , (2) where ϵ xx = 1 A c cos(2ϕ) dA (3) and ϵ xy = 1 A c sin(2ϕ) dA. ( 4 ) Cell elongation is normalized by the cell area (A c ) of each cell. The magnitude of cell elongation is: ϵ = (ϵ 2 xx + ϵ 2 xy ) 1 /2 (5) 28 Here we plot ϵ xx as Q xx , which we describe as the PD component of cell elongation.
Acknowledgements We thank  Stephan Grill  for giving us access to the microscope used for laser ablation. We thank the  Light Microscopy Facility , the  Computer Department , and the Fly Keepers of the  MPI-CBG  for their support and expertise. We would like to thank  Christian Dahmann  and  Jana Fuhrmann  for comments on the manuscript prior to publication. This work was funded by  Germany 's Excellence Strategy -EXC-2068 -390729961-Cluster of  Excellence Physics of Life of TU Dresden , as well as grants awarded to SE from the  Deutsche Forschungsgemeinschaft  ( SPP1782 ,  EA4/10-1 ,  EA4/10-2 ) and core funding of the  Max-Planck Society  to SE. NAD additionally acknowledges funding from the  Deutsche Krebshilfe  ( MSNZ P2  Dresden). AK and RPG were funded through the  Elbe PhD program. FSG was supported by a  DOC Fellowship of the Austrian Academy of Sciences.
CD acknowledges the support of a postdoctoral fellowship from the  LabEx  " Who Am I?"  ( ANR-11-LABX-0071 ) and the  Université Paris Cité IdEx  ( ANR-18-IDEX-0001 ) funded by the  French Government through its "Investments for the Future". We dedicate this work to our coauthor  Prof. Dr. Suzanne Eaton , who tragically passed away before the finalization of the project.
Proofs of Retrievability are protocols which allow a Client to store data remotely and to efficiently ensure, via audits, that the entirety of that data is still intact. Dynamic Proofs of Retrievability (DPoR) also support efficient retrieval and update of any small portion of the data. We propose a novel protocol for arbitrary outsourced data storage that achieves both low remote storage size and audit complexity. A key ingredient, that can be also of intrinsic interest, reduces to efficiently evaluating a secret polynomial at given public points, when the (encrypted) polynomial is stored on an untrusted Server. The Server performs the evaluations and also returns associated certificates. A Client can check that the evaluations are correct using the certificates and some pre-computed keys, more efficiently than re-evaluating the polynomial.
Our protocols support two important features: the polynomial itself can be encrypted on the Server, and it can be dynamically updated by changing individual coefficients cheaply without redoing the entire setup. Our methods rely on linearly homomorphic encryption and pairings, and our implementation shows good performance for polynomial evaluations with millions of coefficients, and efficient DPoR with terabytes of data. For instance, for a 1TB database, compared to the state of art, we can reduce the Client storage by 5000x, communication size by 20x, and client-side audit time by 2x, at the cost of one order of magnitude increase in server-side audit time.
Introduction With a constant growth in the amount of produced data, it becomes more and more important to use remote facilities to store this data. Users and organizations using such outsourcing need to ensure the integrity of their data. In this setting, a Client wishes to store her data on an untrusted Server, then verify (without full retrieval) that the Server still stores the data intact. The crucial protocol is an Audit, wherein the Client issues some challenge to the Server, then verifies the response using some pre-computed information to prove that the original data is still recoverable in its entirety. This is the field of Proofs of Retrievability (PoR), somewhat overlapping with the problem of Provable Data Possession (PDP)  [40, 6]. A variety of tools have been employed to develop efficient PoR and PDP protocols, see for instance  [40, 6, 60, 22, 61, 5]  and references therein.
Retrievability is proven when any sequence of successful audits can, with high probability, be used to recover the original data, e. g. , by polynomial interpolation; thus any Server with a good chance to pass a single random audit must hold the entire data intact. Note that this recovery mechanism is not actually crucial except to prove the soundness of the audit protocol; the important feature is how cheaply the audits can be performed by a Server and resource-constrained Client. Some of these protocols are based on verifiable computing, so that a PoR audit consists of some verified computation over the stored data  [36]. Generally speaking, verifiable computing consists in delegating the computation of a function to an untrusted Server. This Server returns the result as well as a proof of its correctness, and verifying a result should be less expensive than computing it directly.
Existing VPE protocols usually do not consider dynamicity, at least not efficiently: even for the modification of a single coefficient, most of the time the whole protocol has to be reinitialized. Also, previous PoR protocols would either have a low audit complexity but a storage size several times that of the database; or have low remote storage but a less scalable audit complexity. In this paper, we propose a novel protocol for arbitrary outsourced dynamic data storage that achieves both low remote storage size and audit complexity. A key ingredient of our protocol is to be able to perform a dynamic VPE, in order to efficiently handle updates of the database. A verifiable polynomial evaluation scheme is conventionally composed of three main algorithms. First, a Client runs SetuppP q to compute some public representation of the (potentially secret) polynomial P (which may be stored on the Server) as well as some private information which will be used to verify later evaluations.
In the simplest case, the considered polynomial P is static and stored in cleartext by both the Server and the Client. But constraints can then be added to this framework, when needed: • Polynomial outsourcing. When the Client device has limited storage, or to facilitate evaluations for multiple Clients, both the polynomial storage and its computation must be externalized. Besides evaluation and verification, an additional Read protocol is often provided to allow random access to some polynomial coefficients. The challenge is for the Client to obtain the polynomial evaluation while minimizing the communication costs required to verify it. • Secret polynomial. To guarantee data privacy, the polynomial could be hidden from the Server, or the Client, or both. Typically, the polynomial will be stored under a fully-or partially-homomorphic encryption scheme, in such a way that the Server can still compute the (necessarily encrypted) evaluation and certificate for verification.
When the polynomial (as well as any update) needs to be hidden from the Server, the difficulty is in general to preserve both secrecy and verifiability while allowing those efficient partial updates. The importance of allowing efficient updates is motivated by our application to verifiable data storage, where a Client outsourcing storage of a large database wishes to make small changes efficiently. • Private/public verification. The verification protocol is said to be private when only the party which holds the secrets derived during Setup can verify evaluations. That is, any potential Verifiers (sometimes called readers) must be trusted not to divulge secret information to the untrusted Server. Sometimes, it is desirable also to have untrusted Verifiers, who can check the result of an evaluation without knowing any secrets.
The efficiency of our protocols is measured by the computational complexity of the Server-side Eval algorithm, the volume of persistent Client storage, and the amount of communication and Client-side complexity to perform a Verify. Improving on previously-known results, our VPEs protocols all have O(d) (parallelizable) Server-side computation, O(1) communication and Client-side computation time, and O(1) Client-side persistent storage. We include some practical timings in Sections 5. 4 and 6. 3 and Appendix D. In addition, our new dynamic proofs of retrievability require only o(d) extra Server space. This improves on  [61]  in terms of Server storage and on  [5]  in terms of communication and Client computation complexity for Audit. For instance on a 1TB size database, with a Server extra storage lower than 0.
In fact, efficiency, linearity, dynamicity and encryption, are all four of paramount importance for instance for our particular application, as detailed next. Proof of retrievability (PoR) and Provable data possession (PDP) protocols also have an extensive literature  [6, 28, 40, 59, 60, 63, 22, 61, 21, 5]. PDPs, first introduced by Ateniese et al. , generally optimize Server storage and efficiency at the cost of soundness: a PDP audit only guarantees (probabilistically) that a large fraction of the data was not altered; a single block deletion or alteration is likely to go undetected in an audit. PoRs have stronger soundness guarantees, but at the expense of larger and more complicated Server storage, often based on erasure codes and/or ORAM techniques. PoR methods based on block erasure encoding are a class of methods which guarantee with a high probability that the client's entire data can be retrieved.
The idea is to check the authenticity of a number of erasure encoding blocks during the data recovery step but also during the audit algorithm. Those approaches will not detect a small amount of corrupted data. But the idea is that if there are very few corrupted blocks, they could be easily recovered via the error correcting code  [46]. Now, state-of-the-art, dynamic, PoR protocols either incur a constant-factor blowup in Server storage with poly-logarithmic audit cost  [22, 21, 61] , or use negligible extra Server storage space but require polynomial-time audits on the Client and Server  [60, 5]. We refer, e. g. , to  [5, § 7]  for a more detailed comparison between PoR and PDP schemes. In fact, a lower bound argument from  [5, Theorem 4]  proves that some time/space tradeoff is inherent.
• {pst 1 C , st 1 V , st 1 S q, reject} Ð Updatepi, p 1 i , st C , st V , st S q: On input of an index i P 0. d, data p 1 i , the Client/Verifier/Server states st C /st V /st S , outputs new Client/Verifier/Server states st C '/ st V '/ st S ', representing the polynomial P `pp 1 ipi qX i , or reject. A variant of this algorithm, δUpdate, takes as input the difference data δ " p 1 ipi instead of p 1 i. • {ζ, ξ} Ð Evalpst S , rq: On input of the Server state st S and an evaluation point r, outputs ζ the encrypted value of P prq and a proof ξ. • {z, reject} Ð Verifypst V , r, ζ, ξq: On input of the Verifier state st V , the evaluation point r, the encrypted value ζ of P prq and the proof ξ, outputs a successful evaluation z " P prq or reject. The Client may use random coins for any algorithm.
Merkle trees for logarithmic Client storage In order to avoid storing the polynomial coefficients on the Client side, we thus use a Merkle hash tree  [51, 45, 5]. Then it is sufficient to store the root of the Merkle tree: under the CRHF assumption, a malicious Server cannot give back different polynomial coefficients. For our purpose, an implementation of such trees must just provide the following algorithms: • T Ð MTTreepXq creates a Merkle hash tree from a database X. • r Ð MTRootpXq computes from scratch the root of the Merkle hash tree of the whole database X. • L Ð MTUnclespi, T q retrieves a list of "uncle" node hashes along the path in the tree to index i. • r Ð MTpathRootpi, a, Lq computes the root of the Merkle hash tree from a leaf element a and the associated path of uncles L. • T 1 Ð MTupdLeafpi, a, T q updates the whole Merkle tree T by changing the i-th leaf to be a.
The correctness requirements are that, for any index i and databases X, Y which are identical except possibly for the i'th index index (i. e. , @j ‰ i, x j " y j ), we have MTRootpXq " MTpathRoot (i, x i , MTUncles (i, MTTreepXq)) (8) MTTreepXq " MTupdLeafpi, x i , Y q (9) And the soundness requirement is that no P. P. T. adversary can compute a tuple pX, i, b, Lq such that x i ‰ b and MTRootpXq " MTpathRootpi, b, Lq. (10).
Experiments To assess the efficiency of our protocol, we implemented Table  12  using the following libraries 3  : gmp-6. 2. 1 for modular operations, fflas-ffpack-2. 4. 3 for linear algebra, relic-0. 6. 0 for Paillier's cryptosystem and pairings (we used a "bn-p254" pairing), libsnark (commit 2af4402) for baseline polynomial evaluation verification. Our source code to perform these experiments is available via the following GitHub repository: https://github. com/jgdumas/vespo. To observe the effect of the chosen homomorphic systems (Paillier with an RSA modulus size of 2048 bits and the pairing), we ran the experiments, on a single core of an intel Gold 6126 2. 6GHz for the Client and Horner computations and on one or four cores for the Server (the parallelization of the prefix-like Server part of Algorithm 6 is given in Appendix D).
If each audit has o(log N ) cost (and thus transcript size), then the total number of possible transcripts is o(N ), which is a contradiction with the definition of retrievability; not every N -bit database could be recoverable via independent audit transcripts. O(N ) O(log N ) O(log N ) O(1) O(log N ) [5] o(N ) N `o(N ) O √ N O(1) O √ N Here o(N ) N `o(N ) O(log N ) O(1) O(log N ) M P Z mˆn p γ $ Ð Z p , u Ð rγ i s m´1 i"0 P Z m p v Ð u M P Z n p § ¦ ¤ ¥ δSetup ÐÝÝÝÝÝÝÝÝÝÝÝÝ V ect2P olypvq 4 st S ÐÝÝÝÝÝÝÝÝÝÝÝÝ ÝÝÝÝÝÝÝÝÝÝÝÝÑ st C T M Ð MTTreepM q M r M Ð MTRootpM q Output: st S , M, T M Output: st C , γ, r M Write L Mik Ð MTUnclespk `i¨n, M, T M q i, k Input: i, k, M 1 ik M ik , L Mik , w k r M ? " MTpathRootpk `i¨n, M ik , L Mik q δ Ð γ i pM 1 ik ´Mik q st S ÝÝÝÝÝÝÝÝÝÝÝÝÑ § ¦ ¤ ¥ δUpdate ÐÝÝÝÝÝÝÝÝÝÝÝÝ δ, st C st S ÐÝÝÝÝÝÝÝÝÝÝÝÝ ÝÝÝÝÝÝÝÝÝÝÝÝÑ st C M ik Ð M 1 ik , T M Ð MTupdLeafpk `i¨n, M 1 ik , T M q M 1 ik r M Ð MTpathRootpk `i¨n, M 1 ik , L Mik q Output: st S , M, T M Output: st C , r M or reject Audit form x Ð rr k s n´1 k"0 P Z n p , then y Ð M x r r $ Ð Z p s.
To perform an Audit, the Client and Server engage in a 1-round protocol: 1. Client chooses a random vector x dimension n, and sends x 2. Server computes y " M x and sends the dimension-m vector y back to Client. 3. Client computes two dot products u y and v x, and checks that they are equal. The proof of retrievability relies on the fact that observing several successful audits allows, with high probability, recovery of the correct matrix M , and therefore of the entire database. The communication costs are O(n) and O(m) in steps 1 and 2 respectively, and the Client computation in step 3 is O(m `n), resulting in Op √ N q total communication and Client computation when optimizing the matrix dimensions to roughly m " n " √ N. While this square-matrix setup is the basic protocol presented by  [5] , the authors also discuss a potential improvement in communication complexity.
Experiments We now compare our modification of the DPoR protocol with the one in  [5]. Table  10  has three blocks of experiments, each for four database sizes ranging from 1GB to 1TB. The first block of experiments is a run of the original statistically secure DPoR protocol with two dotproducts for the verification, considering the matrix as 56 bits elements modulo a 57-bits prime. The second block of experiments is our new modification, but still using close to square matrices. Subject now to computational security, we have to use a larger coefficient domain, namely here a 254-bits prime (with associated bilinear groups and a 2048-bits Paillier modulus, both estimated equivalent to a 112-bit computational security). We separate the timings of the Write phase in two phases, the remaining linear algebra phase and the new polynomial evaluation phase (δUpdate).
In the third block of experiments we use a more rectangular matrix, trying to reduce communications while not increasing too much the Server computational effort. Overall, we see first in Table  10 , that changing the coefficient domain size increases the computational effort of the Server in the linear algebra phase. Still, reducing the dimension of the dotproduct for the Client, as shown in he third block, allows the Client to be faster for databases larger than 100GB. In any case, the Client audit computational effort is never larger than a few milliseconds and thus the dominant part is most certainly communications. On this aspect, we see that our modification allows for large reductions in both the Client storage (even with square matrices) and the overall communications. Indeed, the Client private state is the vector dimension, the Paillier's private key, twelve group elements and two Merkle tree roots; while the communications are mostly one vector of modular integers in the smallest dimension.
Proof. For the sake of simplicity, we here only consider the case t " 1, that is a single control vector. Correctness. Assume that all the parties are honest. After each update phase, thanks to the correctness of the Merkle hash tree algorithms, we have w " Epu M q and K " epg 1 ; g vσ 2 q. To see this, suppose a modification of the database at indices i and k, and let M 1 " M `pM 1  ik ´Mik qE ik where E ik is the single entry matrix with 1 at position pi, kq. We have u M 1 " u M `u pM 1 ik ´Mik qE ik " u M `γi e k pM 1 ik ´Mik q where e k is the k-th canonical vector. Thus, v 1 " v `γi pM 1 ik ´Mik qe k " v `δe k satisfies u M 1 " v 1. Only the k-th coefficients are different in v and v 1 , and in w and w 1 as well. For the latter, w 1 k " Epv 1 k q " Epv k `δq " Epv k qEpδq " w k Epδq. The Server thus computes w 1 such that w 1 " Epu M 1 q.
D Parallel prefix-like algorithm for the Server We here provide the parallelization we used for the Server audits in our experiments. For the DPoR, the matrix-vector product part was already parallelized in  [5, Table 6 ], a Server auditing the 1TB database in a few minutes. For the polynomial part, as the dimensions become more rectangular, as we can see in Table  10 , the Server's polynomial part is sometimes not negligible anymore, thus also benefits from some parallelization. For this, we would need to parallelize both the homomorphic dot-product and the Horner-like pairings. On the one hand, the former operations, line 1 in Algorithm 6, can be blocked in independent exponentiations and final multiplications in a binary tree. On the other hand, for the latter operations, a standard "baby steps / giant steps" approach can be employed for the iteration of lines 3-6 in Algorithm 6: • First, for steps of size k, compute t r k , then t r kj for j " 1.