text:
zbMATH — the first resource for mathematics

Fixed points for mappings satisfying cyclical contractive conditions. (English) Zbl 1052.54032
In the present paper the authors extend classical results due to Edelstein, Geraghty, Boyd and Wong, Caristi for mappings of the type $$f:\bigcup^p_{i=1}A_i\to \bigcup^p_{i=1} A_i$$, where $$f(A_i)\subset A_{i+1}$$, $$i=1,\dots,p$$ with $$A_{p+1} = A_1$$, where the contractive assumptions are restricted to pairs $$(x,y)\in A_i\times A_{i+1}$$. The paper concludes with a result about nonexpansive mappings in a Banach space setting.

MSC:
 54H25 Fixed-point and coincidence theorems (topological aspects) 47H10 Fixed-point theorems

format: plain


text:
6. An isosceles triangle has perimeter 30 cm arid each of the equal sides is 12 cm. Find the area of the triangle.

sol: Let $\mathrm{?}ABC$ be an isosceles triangle, in which,
We have, AB = AC = 12cm ...(Given)

Now, AB + AC + BC = 30 ...(Given, perimeter = 30cm)
i.e., 12 + 12 + BC = 30
i.e., BC = 30 - 24
So, BC = 6cm
Now, we know that, $s=\frac{a+b+c}{2}$
Therefore, $s=\frac{30}{2}=15cm$

Now, Area of triangle = $\sqrt{15\left(15?12\right)\left(15?6\right)\left(15?12\right)}$ ...(Since, Heron's formula [area = $\sqrt{s\left(s?a\right)\left(s?b\right)\left(s?c\right)}$])
= $\sqrt{15×3×9×3}$
= $\sqrt{3×5×9×9}$
= $9\sqrt{15}{cm}^{2}$


text: 1. A small firm makes a profit of $-x^3 + 9x^2 - 15$ by producing x ice bars a day. If the firm can't make more then ten ice cream bars a day, how many should be made to maximize profit? [/tex]


text:
# Sub-Riemannian Ricci curvatures and universal diameter bounds for 3-Sasakian manifolds

created by rizzi1 on 28 Sep 2015
modified on 28 Oct 2015

[BibTeX]

Submitted Paper

Inserted: 28 sep 2015
Last Updated: 28 oct 2015

Pages: 33
Year: 2015
Notes:

v2: fixed and clarified the proof of Theorem 7 and some typos

As an application, we consider the sub-Riemannian structure of $3$-Sasakian manifolds, for which we provide explicit curvature formulas. We prove that any complete $3$-Sasakian structure of dimension $4d+3$, with $d>1$, has sub-Riemannian diameter bounded by $\pi$. When $d=1$, a similar statement holds under additional Ricci bounds. These results are sharp for the natural sub-Riemannian structure on $\mathbb{S}^{4d+3}$ of the quaternionic Hopf fibrations: $\mathbb{S}^3 \hookrightarrow \mathbb{S}^{4d+3} \to \mathbb{HP}^d,$ whose exact sub-Riemannian diameter is $\pi$, for all $d \geq 1$.


text:
# a little trick: finding the closest

Let’s say you have a bunch of points and you need to either order them by distance to some fixed point, or find the closest.

Euclidean distance is easy, right?

$\sqrt{{(x_j - x_i)}^2 + {(y_j - y_i)}^2}$

Hold it!  Why are you taking the square root?

If all you need  is to rank by distance,  then ranking by distance squared will give you the same result. Forget getting the square root.

Obviously, this makes no discernible difference for onesie-twosie calculations. But can make a big difference if you have lots to do.

Jus’ sayin’.


text:
Electric field inside perfect conductor with inductance

A constant voltage V is applied at the two ends of a cable which is a perfect conductor (e.g. a superconductor). Since the cable, anyway, has a non zero inductance L, the current inside it is not infinite but it is proportional to time t: i(t) = V/L * t.
In this situation, how much it is the electric field E inside the cable? Is it zero anyway? If it is, how can I reconcile it with the fact there is a finite voltage V at its ends?

--
lightarrow

Maybe my was a naive question but just a bit help?

--
lightarrow

Sorry, but I didn't get much help from that discussion because there no one mentioned the impedance of the superconducting cable. We have: V = Z*I where the voltage V across the superconducting cable, its impedance Z and the current I inside of it are complex numbers. Since Z is non zero (at least because of its inductance: Z = iωL) V is non zero too.
So: is there a non zero electric field inside the cable?

--
lightarrow

marcusl
Gold Member
A SC has AC impedance so it develops a voltage across the circuit (SC coil, for example). The electric field inside the bulk material is still zero beyond a thin penetration depth. BTW, your formula for voltage is incorrect. It should be $$V=-L\frac{dI}{dt}$$

A SC has AC impedance so it develops a voltage across the circuit (SC coil, for example).
"SC" means "superconductor"? "AC" means "alternate current"?
The electric field inside the bulk material is still zero beyond a thin penetration depth.
But I have to grasp this: it's zero because it's the sum of the applied voltage (with a battery, e.g.) and the self-induced voltage with opposite sign?
BTW, your formula for voltage is incorrect. It should be $$V=-L\frac{dI}{dt}$$
This you have written is the self induced voltage, not that the applied one with a battery, is it correct?

--
lightarrow

marcusl
Gold Member
"SC" means "superconductor"? "AC" means "alternate current"?
Yes.
But I have to grasp this: it's zero because it's the sum of the applied voltage (with a battery, e.g.) and the self-induced voltage with opposite sign?
No. A changing current through a SC coil produces a voltage given by the equation I wrote, due to the coil's inductance. In this regard, SC and copper coils behave similarly. Inside of the SC material (wire) itself, however, the field is zero for the same reason that it is zero inside of any perfect conductor: charges arrange themselves to exactly cancel any externally applied fields.
This you have written is the self induced voltage, not that the applied one with a battery, is it correct?
Yes, but they are the same in this case since losses in a SC are (essentially) zero. Integrating this equation allows you to find the time-varying current in terms of a time-varying voltage, so that your equation requires an integral to be correct.

A changing current through a SC coil produces a voltage given by the equation I wrote, due to the coil's inductance. In this regard, SC and copper coils behave similarly. Inside of the SC material (wire) itself, however, the field is zero for the same reason that it is zero inside of any perfect conductor: charges arrange themselves to exactly cancel any externally applied fields.
The applied voltage at the SC ends is different than zero, but the field E inside of it (and so the line integral of E along a path taken inside the SC) is zero. This because E is not conservative in this case, is it correct?
Yes, but they are the same in this case since losses in a SC are (essentially) zero. Integrating this equation allows you to find the time-varying current in terms of a time-varying voltage, so that your equation requires an integral to be correct.
If I apply a voltage V to the SC ends with a device which keeps V constant and we can neglect SC losses, where can we consider applied, along the circuit, the self induced voltage?

--
lightarrow

marcusl
Gold Member
The applied voltage at the SC ends is different than zero,
True for AC (not true for DC, of course)
but the field E inside of it (and so the line integral of E along a path taken inside the SC) is zero. This because E is not conservative in this case, is it correct?If I apply a voltage V to the SC ends with a device which keeps V constant and we can neglect SC losses, where can we consider applied, along the circuit, the self induced voltage?
The field is non-zero on the surface of the conductor, for an alternating current, so the self-induced voltage is the integral of the surface fields.

--
lightarrow

True for AC (not true for DC, of course) The field is non-zero on the surface of the conductor, for an alternating current, so the self-induced voltage is the integral of the surface fields.
The case I mean to discuss is that of a constant voltage V applied to a cable with zero resistance and zero capacitive impedance during the transitory. If the voltage generator ha zero internal resistance (let' neglect other kinds of impedance too), the current inside the cable is not constant: it increases linearly with time; if the voltage generator has a non zero internal resistance Ri (neglecting other forms of impedance) the current increases (at the beginning, almost linearly with time) till it reaches a constant value V/Ri, but what happens, however, at the first instants of times? Here the current it's certainly not continuous, but I don't even define it as "alternate". What happens here?
Thank you.

--
lightarrow

marcusl
Gold Member
In this case you have a simple L-R circuit, where all of the resistance R is internal to the source. This is commonly solved with a differential equation (time domain) or Laplace transform (frequency domain). See Wikipedia "RL circuit," for instance.

In this case you have a simple L-R circuit, where all of the resistance R is internal to the source. This is commonly solved with a differential equation (time domain) or Laplace transform (frequency domain). See Wikipedia "RL circuit," for instance.
I have already solved it in the first post. My question is still the same: How much it is the electric field E inside the SC cable in this situation? If it's zero, why, since the applied voltage at its ends is non zero?

--
lightarrow

marcusl
Gold Member
My answer is the same: E inside the bulk SC material is zero. Fields are excluded from the bulk material, even at DC, by the Meissner effect, which is unique to superconductors.The E field, and hence voltage, is supported on the surface within a small penetration depth, often called the London penetration depth.

The London penetration depth shouldn't refer to magnetic field only?

--
lightarrow

marcusl
Gold Member
No, the electric and magnetic fields are related through the vector potential, which is the real driver of behavior in the SC.

We can examine London's first equation to see what happens if one tries to establish a voltage, hence apply an E field, along an SC: $$\vec{E}=\Lambda \frac{\partial\vec J}{\partial t}$$
where $\Lambda$ is a scale factor. Since a constant voltage quickly ramps the current to infinity, we conclude that one cannot impose a voltage across the bulk part of an SC wire.

No, the electric and magnetic fields are related through the vector potential, which is the real driver of behavior in the SC.

We can examine London's first equation to see what happens if one tries to establish a voltage, hence apply an E field, along an SC: $$\vec{E}=\Lambda \frac{\partial\vec J}{\partial t}$$
where $\Lambda$ is a scale factor. Since a constant voltage quickly ramps the current to infinity, we conclude that one cannot impose a voltage across the bulk part of an SC wire.
Looking up in the net I found for the first London equation:
∂j/∂t = nse2E/m
where 'm' is the electron's mass, 'e' its charge in absolute modulus and ns the number of superconducting carriers per unit volume. To make a little computation I need an approximate value of ns (an order of magnitude would be enough). Do you have any idea?
Thanks.

--
lightarrow

marcusl
Gold Member
You have written 1/Λ. The value of Λ is approximately 2e-21, in SI units.

You have written 1/Λ. The value of Λ is approximately 2e-21, in SI units.
So, with a potential difference of 1V in a 1m of SC cable and so an electric field E = 1V/m, we would have, in theory, approximately 500,000 A of current in 10^(-15) s, independently if the cable is wrapped to form a solenoid, if the electric field were present inside of the cable?

--
lightarrow

marcusl
Gold Member
That's correct--it's nonsense.

Daz
Gold Member
lightarrow: try googling “SC magnet controller” or “SC magnet charging time”. You’ll see plenty of examples where superconducting solenoids have a measurable, macroscopic DC voltage across their (superconducting) terminals for extended periods of time (hours or even days.)

Of course, no one doubts that the field inside the superconductor is zero. It would be nice to see a detailed analysis, but my guess is it’s all down to the back EMF induced by the time-varying magnetic field. I suppose that in this regard there is no practical difference between the situation you describe and the ideal inductor we study in basic electricity.

Thanks to both for the answers.
Regards,

--
lightarrow


text:
TL;DR

I'm not as rusty as I thought I'd be. And YES that kind of challenge has a place in the coding world (see conclusion)

Just like every year, I had a blast banging my head on the Advent of Code calendar. It so happens that this year, I had a lot less brain power to focus on them due to the exam season at school and the ensuing panicky students, but it could also be because my brain isn't up to spec.

Some of my students are/were doing the challenges, so I didn't want to post anything that would help them, but now that the year is almost over, I wanted to go over the puzzles and give out impressions (and maybe hints).

Easing in

Days 1 to 7 were mostly about setting up the stage, getting into the habit of parsing the input and using the right kind of structure to store the data.

Nothing super hard, it was "just" lists, hashmaps, and trees, until day 4. Day 4 was especially funny to me, because I wrote HoledRange / Domain just for that purpose (disjointed ranges and operations on them). Except I decided to do this year's calendar in Julia, and the library I wrote is for Swift. Just for kicks, I rewrote parts of the library, and I might even publish it.

Days 5, 6 and 7 highlighted the use of stacks, strings, and trees again. Nothing too hard.

Getting harder

My next favorite is day 9. It's about a piece of rope you drag the head of, and have to figure out what the tail does. If you've ever played zig-zaging a shoelace you'll know what I mean. String physics are fun, especially in inelastic cases.

Many ways to do that, but once you realize how the tail catches up to the head when the latter is moved, multi-segmented chains are just a recursive application of the same.

I was waiting for a day 10-like puzzle, as there tends to be one every year, and I majored in compilers all those years ago. State machines, yuuuuuusssssssss.

A lot of puzzles involve path finding after that, which isn't my strong suit for some reason. But since the algorithms are already out there (it was really funny to see the spike in google searches for Dijkstra and A*), it's "just" a matter of encoding the nodes and the edges in a way that works.

Day 13 is fun, if only because it can be instantly solved in some language with eval, which will treat the input as a program. I still wrote my own comparison functions, because I like manipulating numbers, lists and inequalities.

Day 14 is "sand simulation", that is grains of sand that settle in a conical shape that keeps expanding laterally. Once you find the landing point on each ledge and the maximum width of the pile, there's a calculable result. Otherwise, running the simulation works too, there aren't that many grains. For part 2, I just counted the holes rather than the grains.

Day 15 is about union and intersections of disjointed ranges again, except in 2D. Which, with the Manhattan distance approximation, gets back to 1D fairly quickly.

Day 16 stumped quite a few people, because of the explosive nature of path searching. Combinatorics are pretty hard to wrap your head around. Personally, I went for "reachability" within the remaining time, constructed my graph, and explored. It was probably non optimal.

Day 17 make me inordinately proud. Nuff said.

Catching up

Because of the aforementioned  workload, I was late by that point, so I decided to take my time and not complete the challenge by Xmas. Puzzles were getting hard, work was time-consuming, so the pressure needed to go down.

Because of the 3D background that I had, I tackled day 18 with raytracing, which is way over-engineered, but reminded me of the good ole times. Part 2 was trickier with that method, because suddenly I had 2 kinds of "inside".

Day 19 was path finding again, the trick being how to prune paths that didn't lead in a good direction. Probably the one that used up the most memory, and therefore the one I failed the most.

Because of my relative newness to Julia, I had to go through many hoops to solve day 20. As it turns out, screw_dog over on mastodon gave me the bit I lacked to solve it simply, although way after I solved it using other means.

Day 21 goes back to my compiler roots and tree optimizations, and Julia makes the huge integer manipulation relatively easy, so, there. Pretty proud of my solution:

Part 1:   3.709 ms (31291 allocations: 1.94 MiB)
Part 2:   4.086 ms (31544 allocations: 1.95 MiB)

Which, on my relatively slow mac mini is not bad at all! Symbolic linear equation solving (degree one, okay) is a fun thing to think about. I even think that the algorithm I devised would work on trees where the unknown appears on both sides of the tree. Maybe I'll test it some day.

Day 22. Aaaaaaaah day 22. Linked lists get you all the way if and only if you know how to fold a cube from a 2D pattern. I don't so, as many of the other participants, I hardcoded the folding. A general solution just eluded me. It's on my todo list of reading for later.

Day 23 is an interesting variant of Conway's Game of Life, and I don't believe there is a way to simplify a straight up simulation, but I fully accept I could be wrong. So I used no trick, and let the thing run for 40s to get the result.

Day 24 was especially interesting for me, for all the wrong reasons. As I mentioned, graph traversal isn't my forte. But the problem was setup in a way that "worked" for me: pruning useless paths was relatively easy, so the problem space didn't explode too quickly. I guess I should use the same method on previous puzzles that I was super clumsy with.

Finally day 25 is a straight up algorithmic base conversion problem that's a lot of fun for my brain. If you remember how carry works when adding or subtracting numbers, it's not a big challenge, but thinking in base 5 can trip you up.

Conclusion

I honestly didn't believe I could hack it this year. I don't routinely do that kind of problem anymore, I have a lot of things going on at school, on top of dealing with the long tail of Covid and its effects on education. Family life was a bit busy with health issues (nothing life threatening, but still time consuming), and the precious little free time that I had was sure to be insufficient for AoC.

I'm glad I persevered, even if it took me longer than I wished it had. I'm glad I learned how to use Julia better. And I'm happy I can still hack it.

I see here and there grumblings about formal computer science. During and after AoC, I see posts, tweets, toots, etc, saying that the "l33t c0d3" is useless in practical, day-to-day, professional development. Big O notation, formal analysis, made up puzzles that take you into voluntarily difficult territories, all these things aren't a reflection of the skills that are needed nowadays to write good apps, to make good websites, and so on.

It's true. Ish.

You can write code that works without any kind of formal training. Today's computing power and memory availability makes optimization largely irrelevant unless you are working with games or embedded systems, or maybe data science. I mean, we can use 4GB of temporary memory for like 1/4 of a second to parse and apply that 100kB json file, and it has close to no impact on the perceived speed of our app, right? Right. And most of the clever algorithms are part of the standard library anyway, or easily findable.

The problem, as usual, is at scale. The proof-of-concept, prototype, or even 1.0 version, of the program may very well work just fine with the first 100 users, or 1000 or whatever the metric is for success. Once everything takes longer than it should, there are only 3 solutions:

• rely on bigger machines, which may work for a time, but ultimately does not address the problem
• scale things horizontally, which poses huge synchronization issues between the shards
• reduce the technical debt, which is really hard

The first two rely on compute power being relatively cheap. And most of us know about the perils of infrastructure costs. That meme regularly makes the rounds.

It's not about whether you personally can solve some artificially hard problem using smart techniques, so that's ok if you can't do every puzzle in AoC or other coding challenges. It's not about flexing with your big brain capable of intuiting the bigO complexity of a piece of code. It's about being able to think about these problems in a way that challenges how you would normally do it. It's about expanding your intuition and your knowledge about the field you decided to work in.

It's perfectly OK for an architect to build only 1 or 2 level houses, there's no shame in it. But if that architect ever wants to build a 20+ stories building, the way to approach the problem is different.

Same deal with computer stuff. Learning is part of the experience.

I've been really interested in Julia for a while now, tinkering here and there with its quirks and capabilities.

This year, I've decided to try and do the whole of Advent of Code using that language.

First impressions are pretty good:
- map, reduce, and list/array management in general are really nice, being first-class citizens. I might even get over the fact that indices start at 1
- automatic multithreading when iterating over collections means that some of these operations are pretty speedy
- it's included in standard jupyterhub images, meaning that my server install gives me access to a Julia environment if I am not at my computer for some reason

Now it's kind of hard to teach old dogs new tricks, so I'm sure I misuse some of the features by thinking in "other languages". We'll see, but 4 days in, I'm still fairly confident.

First part of doing RNN text prediction with TensorfFlow, in Swift

For all intents and purposes, it's about statistics. The question we are trying to solve is either something along the lines of "given an input X, what is the most probable Y?", or along the lines of "given an input X, what is the probability of having Y?"

Of course, simple probability problems have somewhat simple solutions: if you take a game of chess and ask for a next move based on the current board, you can do all the possible moves and sort them based on the probability of having a piece taken off the board, for instance. If you are designing an autopilot of some kind, you have an "ideal" attitude (collection of yaw, pitch and roll angles), and you calculate the movements of the stick and pedals that will most likely get you closer to that objective. If your last shot went left of the target, chances are, you should go right. Etc etc etc.

But the most interesting problems don't have obvious causality. If you have pasta, tomatoes and ground meat in your shopping basket, maybe your next item will be onions, because you're making some kind of bolognese, maybe it will be soap, because that's what you need, maybe it will be milk, because that's the order of the shelves you are passing by.

Machine learning is about taking a whole bunch of hopefully consistent data (even if you don't know for sure that it's consistent), and use it to say "based on this past data, the probabilities for onions, soap and milk are X, Y, and Z, and therefore the most probable is onions.

The data your are basing your predictive model on is really really important. Maybe your next item is consistent with the layout of the shop. Maybe it is consistent with what other customers got. Maybe it's consistent to your particular habits. Maybe it's consistent with people who are in the same "category" as you (your friends, your socio-economic peers, your cultural peers, ... pick one or more).

So you want a lot of data to have a good prediction, but not all the data, because noise (random data) does not reveal a bias (people in the shop tend to visit the shelves in that order) or doesn't exploit a bias (people following receipes want those ingredients together).

Oh yes, there are biases. Lots of them. Because ML uses past data to predict the future, if the data we use was based on bad practices, recommendations won't be a lot better.

There is a branch of machine learning that starts ex nihilo but it is beyond the scope of this introduction, and generates data based on a tournament rather than on actual facts. Its principle is roughly the same, though.

So, to recap:

• We start with a model with random probabilities, and a series of "truths" ( X leads to Y )
• We try with a Z, see what the model predicts
• We compare it to a truth, and fix the probabilities a little bit so that it matches
• Repeat with as many Zs as possible to be fairly confident the prediction isn't too far off

If you didn't before, now you know why ML takes a lot of resources. Depending on the number of possible Xs, Ys and the number of truths, the probability matrix is potentially humongous. Operations (like fixing the probabilities to match reality) on such enormous structures aren't cheap.

If you want a more detailed oriented explanation, with maths and diagrams, you can read my other attempt at explaining how it works.

Swift TensorFlow

There are a few contenders in the field of "ML SDK", but one of the most known is TensorFlow, backed by Google. It also happens to have a Swift variant (almost every other ML environment out there is either Python or R).

And of course, the documentation is really... lacking, making this article more useful than average along the way.

In their "Why Swift?" motivation piece, the architects make a good case, if a little bit technical, as to why swift makes a good candidate for ML.

The two major takeaways you have to know going in are:

• It's a different build of Swift. You cannot use the one that shipped with Xcode (yet)
• It uses a lot of Python interoperability to work, so some ways of doing things will be a bit alien

The performance is rather good, comparable or better than the regular Python TensorFlow for the tasks I threw at it, so there's that.

But the documentation... My oh my.

Let's take an example: Tensor is, as the name of the framework implies, the central feature of the system. Its documentation is here: https://www.tensorflow.org/swift/api_docs/Structs/Tensor

Sometimes, that page greets me in Greek... But hey, why not. There is little to no way to navigate the hierarchy, other than going on the left side, opening the section (good luck if you don't already know if it's a class, a protocol or a struct you're looking for), and if you use the search field, it will return pages about... the Python equivalents of the functions you're looking for.

Clearly, this is early in the game, and you are assumed to know how regular TensorFlow works before attempting to do anything with STF.

But fret not! I will hold your hand so that you don't need to look at the doc too much.

The tutorials are well written, but don't go very far at all. Oh and if you use that triple Dense layers on more than a toy problem (flower classification that is based on numbers), your RAM will fill so fast that your computer will have to be rebooted. More on that later.

And, because the center of ML is that "nudge" towards a better probability matrix (also called a Tensor), there is the whole @differentiable thing. We will talk about it later.

A good thing is that Python examples (there are thousands of ML tutorials in Python) work almost out of the box, thanks to the interop.

Data Preparation

Which Learning will my Machine do?

I have always thought that text generation was such a funny toy example (if a little bit scary when you think about some of the applications): teach the machine to speak like Shakespeare, and watch it spit some play at you. It's also easy for us to evaluate in terms of what it does and how successful it is. And the model makes sense, which helps when writing a piece on how ML works.

A usual way of doing that is using trigrams. We all know than predicting the next word after a single word is super hard. And our brains tend to be able to predict the last word of a sentence with ease. So, a common way of teaching the machine is to have it look at 3 words to predict a 4th.

I am hungry -> because, the birds flew -> away, etc

Of course, for more accurate results, you can extend the number of words in the input, but it means you must have a lot more varied sentence examples.

What we need to do here is assign numbers to these words (because everything is numbers in computers) so that we have a problem like "guess the function f if f(231,444,12)->123, f(111,2,671)->222", which neural networks are pretty good at.

So we need data (a corpus), and we need to split it into (trigram)->result

Now, because we are ultimately dealing with probabilities and rounding, we need the input to be in Float, so that the operations can wriggle the matrices by fractions, and we need the result to be an Int, because we don't want something like "the result is the word between 'hungry' and 'dumb'".

The features (also called input) and the labels (also called outputs) have to be stored in two tensors (also called matrices), matching the data we want to train our model on.

That's where RAM and processing time enter the arena: the size of the matrix is going to be huge:

• Let's say the book I chose to teach it English has 11148 words in it (it's Tacitus' Germany), that's 11148*3-2 trigrams (33442 lines in my matrices, 4 columns total)
• The way neural networks function, you basically have a function parameter per neuron that gets nudged at each iteration. In this example, I use two 512 parameters for somewhat decent results. That means 2 additional matrices of size 33442*512.
• And operations regularly duplicate these matrices, if only for a short period of time, so yea, that's a lot of RAM and processing power.

Here is the function that downloads a piece of text, and separates it into words:

func loadData(_ url: URL) -> [String] {
let sem = DispatchSemaphore(value: 0)
var result = [String]()

let session = URLSession(configuration: URLSessionConfiguration.default)
//     let set = CharacterSet.punctuationCharacters.union(CharacterSet.whitespacesAndNewlines)
let set = CharacterSet.whitespacesAndNewlines
session.dataTask(with: url, completionHandler: { data, response, error in
if let data = data, let text = String(data: data, encoding: .utf8) {
let comps = text.components(separatedBy: set).compactMap { (w) -> String? in
// separate punctuation from the rest
if w.count == 0 { return nil }
else { return w }
}
result += comps
}

sem.signal()
}).resume()

sem.wait()
return result
}

Please note two things: I make it synchronous (I want to wait for the result), and I chose to include word and word, separately. You can keep only the words by switching the commented lines, but I find that the output is more interesting with punctuation than without.

Now, we need to setup the word->int and int->word transformations. Because we don't want to look at all the array of words every time we want to search for one, there is a dictionary based on the hashing of the words that will deal with the first, and because the most common words have better chances to pop up, the array for the vocabulary is sorted. It's not optimal, probably, but it helps makes things clear, and is fast enough.

func loadVocabulary(_ text: [String]) -> [String] {
var counts = [String:Int]()

for w in text {
let c = counts[w] ?? 0
counts[w] = c + 1
}

let count = counts.sorted(by: { (arg1, arg2) -> Bool in
let (_, value1) = arg1
let (_, value2) = arg2
return value1 > value2
})

return count.map { (arg0) -> String in
let (key, _) = arg0
return key
}
}

func makeHelper(_ vocabulary: [String]) -> [Int:Int] {
var result : [Int:Int] = [:]

vocabulary.enumerated().forEach { (arg0) in
let (offset, element) = arg0
result[element.hash] = offset
}

return result
}

Why not hashValue instead of hash? turns out, on Linux, which this baby is going to run on, the values are more stable with the latter rather than the former, according to my tests.

The data we will work on therefore is:

struct TextBatch {
let original: [String]
let vocabulary: [String]
let indexHelper: [Int:Int]
let features : Tensor<Float> // 3 words
let labels : Tensor<Int32> // followed by 1 word
}

We need a way to initialize that struct, and a couple of helper functions to extract some random samples to train our model on, and we're good to go:

extension TextBatch {
public init(from: [String]) {
let h = makeHelper(v)
var f : [[Float]] = []
var l : [Int32] = []
for i in 0..<(from.count-3) {
if let w1 = h[from[i].hash],
let w2 = h[from[i+1].hash],
let w3 = h[from[i+2].hash],
let w4 = h[from[i+3].hash] {
f.append([Float(w1), Float(w2), Float(w3)])
l.append(Int32(w4))
}
}

let featuresT = Tensor<Float>(shape: [f.count, 3], scalars: f.flatMap { $0 }) let labelsT = Tensor<Int32>(l) self.init( original: from, vocabulary: v, indexHelper: h, features: featuresT, labels: labelsT ) } func randomSample(of size: Int) -> (features: Tensor<Float>, labels: Tensor<Int32>) { var f : [[Float]] = [] var l : [Int32] = [] for i in 0..<(original.count-3) { if let w1 = indexHelper[original[i].hash], let w2 = indexHelper[original[i+1].hash], let w3 = indexHelper[original[i+2].hash], let w4 = indexHelper[original[i+3].hash] { f.append([Float(w1), Float(w2), Float(w3)]) l.append(Int32(w4)) } } var rf : [[Float]] = [] var rl : [Int32] = [] if size >= l.count || size <= 0 { let featuresT = Tensor<Float>(shape: [f.count, 3], scalars: f.flatMap {$0 })
let labelsT = Tensor<Int32>(l)
return (featuresT, labelsT)
}
let idx = Int.random(in: 0..<l.count)
rf.append(f[idx])
rl.append(l[idx])
}
}

let featuresT = Tensor<Float>(shape: [f.count, 3], scalars: f.flatMap { $0 }) let labelsT = Tensor<Int32>(l) return (featuresT, labelsT) } func randomSample(splits: Int) -> [(features: Tensor<Float>, labels: Tensor<Int32>)] { var res = [(features: Tensor<Float>, labels: Tensor<Int32>)]() var alreadyPicked = Set<Int>() let size = Int(floor(Double(original.count)/Double(splits))) var f : [[Float]] = [] var l : [Int32] = [] for i in 0..<(original.count-3) { if let w1 = indexHelper[original[i].hash], let w2 = indexHelper[original[i+1].hash], let w3 = indexHelper[original[i+2].hash], let w4 = indexHelper[original[i+3].hash] { f.append([Float(w1), Float(w2), Float(w3)]) l.append(Int32(w4)) } } for part in 1...splits { var rf : [[Float]] = [] var rl : [Int32] = [] if size >= l.count || size <= 0 { let featuresT = Tensor<Float>(shape: [f.count, 3], scalars: f.flatMap {$0 })
let labelsT = Tensor<Int32>(l)
return [(featuresT, labelsT)]
}
let idx = Int.random(in: 0..<l.count)
rf.append(f[idx])
rl.append(l[idx])
}
}

let featuresT = Tensor<Float>(shape: [f.count, 3], scalars: f.flatMap { $0 }) let labelsT = Tensor<Int32>(l) res.append((featuresT,labelsT)) } return res } } In the next part, we will see how to set the model up, and train it. From this list, the gist is that most languages can't process 9999999999999999.0 - 9999999999999998.0 Why do they output 2 when it should be 1? I bet most people who've never done any formal CS (a.k.a maths and information theory) are super surprised. Before you read the rest, ask yourself this: if all you have are zeroes and ones, how do you handle infinity? If we fire up an interpreter that outputs the value when it's typed (like the Swift REPL), we have the beginning of an explanation: Welcome to Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1). Type :help for assistance. 1> 9999999999999999.0 - 9999999999999998.0$R0: Double = 2
2> let a = 9999999999999999.0
a: Double = 10000000000000000
3> let b = 9999999999999998.0
b: Double = 9999999999999998
4> a-b
$R1: Double = 2 Whew, it's not that the languages can't handle a simple substraction, it's just that a is typed as 9999999999999999 but stored as 10000000000000000. If we used integers, we'd have:  5> 9999999999999999 - 9999999999999998$R2: Int = 1

Are the decimal numbers broken? 😱

A detour through number representations

Let's  look at a byte. This is the fundamental unit of data in a computer and  is made of 8 bits, all of which can be 0 or 1. It ranges from 00000000 to 11111111 ( 0x00 to 0xff in hexadecimal, 0 to 255 in decimal, homework as to why and how it works like that due by monday).

Put like that, I hope it's obvious that the question "yes, but how do I represent the integer 999 on a byte?" is meaningless. You can decide that 00000000 means 990 and count up from there, or you can associate arbitrary values to the 256 possible combinations and make 999 be one of them, but you can't have both the 0 - 255 range and 999. You have a finite number of possible values and that's it.

Of  course, that's on 8 bits (hence the 256 color palette on old games). On  16, 32, 64 or bigger width memory blocks, you can store up to 2ⁿ different values, and that's it.

The problem with decimals

While  it's relatively easy to grasp the concept of infinity by looking at  "how high can I count?", it's less intuitive to notice that there is the same amount of numbers between 0 and 1 as there are integers.

So,  if we have a finite number of possible values, how do we decide which  ones make the cut when talking decimal parts? The smallest? The most  common? Again, as a stupid example, on 8 bits:

• maybe we need 0.01 ... 0.99 because we're doing accounting stuff
• maybe we need 0.015, 0.025,..., 0.995 for rounding reasons
• We'll just encode the numeric part on 8 bits ( 0 - 255 ), and the decimal part as above

But that's already  99+99 values taken up. That leaves us 57 possible values for the rest of infinity. And that's not even mentionning the totally arbitrary nature of the  selection. This way of representing numbers is historically the first  one and is called "fixed" representation. There are many ways of  choosing how the decimal part behaves and a lot of headache when coding  how the simple operations work, not to mention the complex ones like  square roots and powers and logs.

Floats (IEEE 754)

To  make it simple for chips that perform the actual calculations, floating  point numbers (that's their name) have been defined using two  parameters:

• an integer n
• a power (of base b) p

Such that we can have n x bᵖ, for instance 15.3865 is 153863 x 10^(-4). The question is, how many bits can we use for the n and how many for the p.

The standard is to use 1 bit for the sign (+ or -), 23 bits for n, 8 for p, which use 32 bits total (we like powers of two), and using base 2, and n is actually 1.n.  That gives us a range of ~8 million values, and powers of 2 from -126  to +127 due to some special cases like infinity and NotANumber (NaN).

$$(-1~or~1)(2^{[-126...127]})(1.[one~of~the~8~million~values])$$

In theory, we have numbers from -10⁴⁵ to 1038 roughly, but some numbers can't be represented in that form. For  instance, if we look at the largest number smaller than 1, it's 0.9999999404. Anything between that and 1 has to be rounded. Again, infinity can't be represented by a finite number of bits.

Doubles

The  floats allow for "easy" calculus (by the computer at least) and are  "good enough" with a precision of 7.2 decimal places on average. So when  we needed more precision, someone said "hey, let's use 64 bits instead  of 32!". The only thing that changes is that n now uses 52 bits and p 11 bits.

Coincidentally, double has more a meaning of double size than double precision, even though the number of decimal places does jump to 15.9 on average.

We  still have 2³² more values to play with, and that does fill some  annoying gaps in the infinity, but not all. Famously (and annoyingly),  0.1 doesn't work in any precision size because of the base 2. In 32 bits  float, it's stored as 0.100000001490116119384765625, like this:

(1)(2⁻⁴)(1.600000023841858)

Conversely, after double size (aka doubles), we have quadruple size (aka quads), with 15 and 112 bits, for a total of 128 bits.

Back to our problem

Our value is 9999999999999999.0. The closest possible value encodable in double size floating point is actually 10000000000000000, which should now make some kind of sense. It is confirmed by Swift when separating the two sides of the calculus, too:

2> let a = 9999999999999999.0
a: Double = 10000000000000000

Our  big brain so good at maths knows that there is a difference between  these two values, and so does the computer. It's just that using  doubles, it can't store it. Using floats, a will be rounded to 10000000272564224 which isn't exactly better. Quads aren't used regularly yet, so no luck there.

It's  funny because this is an operation that we puny humans can do very  easily, even those humans who say they suck at maths, and yet those  touted computers with their billions of math operations per second can't  work it out. Fair enough.

The kicker is, there is a litteral infinity of examples such as this one, because trying to represent infinity in a finite number of digits is impossible.


text:
# Leave-one-out error

• Leave-one-out cross-validation (CVloo) Stability An algorithm f has CVloo stability β with respect to the loss function V if the following holds:

${\displaystyle \forall i\in \{1,...,m\},\mathbb {P} _{S}\{\sup _{z\in Z}|V(f_{S},z_{i})-V(f_{S^{|i}},z_{i})|\leq \beta _{CV}\}\geq 1-\delta _{CV}}$

• Expected-to-leave-one-out error (${\displaystyle Eloo_{err}}$) Stability An algorithm f has ${\displaystyle Eloo_{err}}$ stability if for each n there exists a${\displaystyle \beta _{EL}^{m}}$ and a ${\displaystyle \delta _{EL}^{m}}$ such that:

${\displaystyle \forall i\in \{1,...,m\},\mathbb {P} _{S}\{|I[f_{S}]-{\frac {1}{m}}\sum _{i=1}^{m}V(f_{S^{|i}},z_{i})|\leq \beta _{EL}^{m}\}\geq 1-\delta _{EL}^{m}}$, with ${\displaystyle \beta _{EL}^{m}}$and ${\displaystyle \delta _{EL}^{m}}$ going to zero for ${\displaystyle n\rightarrow \inf }$

## Preliminary notations

X and Y ⊂ R being respectively an input and an output space, we consider a training set

${\displaystyle S=\{z_{1}=(x_{1},\ y_{1})\ ,..,\ z_{m}=(x_{m},\ y_{m})\}}$ of size m in ${\displaystyle Z=X\times Y}$ drawn i.i.d. from an unknown distribution D. A learning algorithm is a function ${\displaystyle f}$ from ${\displaystyle Z_{m}}$ into ${\displaystyle F\subset YX}$which maps a learning set S onto a function ${\displaystyle f_{S}}$ from X to Y. To avoid complex notation, we consider only deterministic algorithms. It is also assumed that the algorithm ${\displaystyle f}$ is symmetric with respect to S, i.e. it does not depend on the order of the elements in the training set. Furthermore, we assume that all functions are measurable and all sets are countable which does not limit the interest of the results presented here.

The loss of an hypothesis f with respect to an example ${\displaystyle z=(x,y)}$ is then defined as ${\displaystyle V(f,z)=V(f(x),y)}$. The empirical error of f is ${\displaystyle I_{S}[f]={\frac {1}{n}}\sum V(f,z_{i})}$.

The true error of f is ${\displaystyle I[f]=\mathbb {E} _{z}V(f,z)}$

Given a training set S of size m, we will build, for all i = 1....,m, modified training sets as follows:

• By removing the i-th element

${\displaystyle S^{|i}=\{z_{1},...,\ z_{i-1},\ z_{i+1},...,\ z_{m}\}}$

• By replacing the i-th element

${\displaystyle S^{i}=\{z_{1},...,\ z_{i-1},\ z_{i}',\ z_{i+1},...,\ z_{m}\}}$

## References

• S. Mukherjee, P. Niyogi, T. Poggio, and R. M. Rifkin. Learning theory: stability is sufficient for generalization and necessary and sufficient for consistency of empirical risk minimization. Adv. Comput. Math., 25(1-3):161–193, 2006


text:
# stats 170

(This blog site does not support formatting therefore sometimes there could be errors in the post.)

Hypothesis:
An Assumption of outcome of statistical testing is called as hypothesis. e.g.: Sample is as per required norms according to the given parameter.

Parameter
Parameter is criterion on which sample is accepted or rejected. Parameter could be mean, standard deviation etc.

Estimator.
Estimator is a parameter which is used to estimate the value of the population parameter. An example of an estimator is the sample mean, which is an estimator of the population mean.

Test statistics
Value of the test parameter is known as test statistics.

Null Hypothesis.
It is initial assumption about an outcome before testing. It is denoted by Ho. e.g.: Average strength is as per required norms, which means population mean is same as sample mean. It is written as Ho: Î¼ =

Alternative Hypothesis
Another assumption if null hypothesis is proved to be false. It is denoted by H1 e.g.: Average strength is less than required norms.


text:
How do you solve 9^(x-4)=81?

1 Answer
Feb 12, 2015

9^(x−4) = 81 implies $x = 6$

The only value $p$ for which ${9}^{p} = 81$ is $p = 2$
so
$x - 4 = 2$ $\rightarrow$ $x = 6$


text:
# Portal:Algebra

## Algebra

Algebra is a branch of mathematics concerning the study of structure, relation and quantity. The name is derived from the treatise written by the Persian mathematician, astronomer, astrologer and geographer, Muhammad bin Mūsā al-Khwārizmī titled Kitab al-Jabr al-Muqabala (meaning " The Compendious Book on Calculation by Completion and Balancing"), which provided operations for the systematic solution of linear and quadratic equation

Together with geometry, analysis, combinatorics, and number theory, algebra is one of the main branches of mathematics. Elementary algebra is often part of the curriculum in secondary education and provides an introduction to the basic ideas of algebra, including effects of adding and multiplying numbers, the concept of variables, definition of polynomials, along with factorization and determining their roots.

In addition to working directly with numbers, algebra covers working with symbols, variables, and set elements. Addition and multiplication are viewed as general operations, and their precise definitions lead to structures such as groups, rings and fields.

## Selected article

 The graph of a real-valued quadratic function of a real variable x, is a parabola.

A quadratic equation is a polynomial equation of degree two. The general form is

$ax^2+bx+c=0,\,\!$

where a ≠ 0 (if a = 0, then the equation becomes a linear equation). The letters a, b, and c are called coefficients: the quadratic coefficient a is the coefficient of x2, the linear coefficient b is the coefficient of x, and c is the constant coefficient, also called the free term.

A quadratic equation has two (not necessarily distinct) solutions, which may be real or complex, given by the quadratic formula:

$x = \frac{-b \pm \sqrt {b^2-4ac}}{2a},$

These solutions are roots of the corresponding quadratic function

$f(x) = ax^2+bx+c.\,$
 Image credit: Enoch Lau

## Did you know?

• ...that it is impossible to devise a single formula involving only polynomials and radicals for solving an arbitrary quintic equation?
• ...that it is possible for a three dimensional figure to have a finite volume but infinite surface area? An example of this is Gabriel's Horn.
• ...that the Gudermannian function relates the regular trigonometric functions and the hyperbolic trigonometric functions without the use of complex numbers?
• ...that the classification of finite simple groups was not completed until the mid 1980s?
• ...that a field is an algebraic structure in which the operations of addition, subtraction, multiplication and division (except division by zero) may be performed, and the same rules hold which are familiar from the arithmetic of ordinary numbers?

## subpage

These are all the connected Dynkin diagrams, which classify the irreducible root systems, which themselves classify simple complex Lie algebras and simple complex Lie groups. These diagrams are therefore fundamental throughout Lie group theory.


text:
Thank you for visiting nature.com. You are using a browser version with limited support for CSS. To obtain the best experience, we recommend you use a more up to date browser (or turn off compatibility mode in Internet Explorer). In the meantime, to ensure continued support, we are displaying the site without styles and JavaScript.

# Nanoparticle-insertion scheme to decouple electron injection from laser evolution in laser wakefield acceleration

## Abstract

A localized nanoparticle insertion scheme is developed to decouple electron injection from laser evolution in laser wakefield acceleration. Here we report the experimental realization of a controllable electron injection by the nanoparticle insertion method into a plasma medium, where the injection position is localized within the short range of 100 μm. Nanoparticles were generated by the laser ablation process of a copper blade target using a 3-ns 532-nm laser pulse with fluence above 100 J/cm2. The produced electron bunches with a beam charge above 300 pC and divergence of around 12 mrad show the injection probability over 90% after optimizing the ablation laser energy and the temporal delay between the ablation and the main laser pulses. Since this nanoparticle insertion method can avoid the disturbing effects of electron injection process on laser evolution, the stable high-charge injection method can provide a suitable electron injector for multi-GeV electron sources from low-density plasmas.

## Introduction

Laser wakefield acceleration (LWFA) research has made significant progresses in the last 40 years since it promised a high-gradient acceleration field of 100 GV/m in compact configurations1,2. The blow-out or bubble regime has been confirmed to be a practical scheme to produce high-energy electron bunches3. In the LWFA, an electron injection into a plasma wave is a critical issue to obtain stable and high-quality electron beams. Various electron injection methods have been developed to reproducibly generate high-quality electron bunches with the energy of a few 100’s MeV at high stabilities4,5,6,7,8,9,10, and these electron sources have been successfully applied in producing x-ray radiations11,12,13. For increasing electron energy further, a low-density plasma over a centimeter-long acceleration length is required to mitigate the dephasing effect in the acceleration process14. Several different methods have been proposed to guide the laser pulse over several-centimeter distances in a gas cell or a capillary for multi-GeV electron beam production15,16,17,18,19. To date, the maximum electron bunch energy reached 7.8 GeV, which was produced with a plasma density below 1018 cm−3 based on self-injection and a long acceleration distance of 20 cm19. The self-injection method, however, has a limitation of the deformation of laser propagation during the occurrence of highly nonlinear plasma waves.

A suitable injection scheme is essential for generating a stable multi-GeV electron bunch. Since guiding a laser pulse beyond tens of cm is highly desirable during the electron acceleration process, the required injection method should have minor effects on the laser pulse evolution. Current experiments towards multi-GeV electrons are mostly based on self-injection16,19 or ionization injection method15, which cannot decouple the electron injection process from the laser evolution. A nanoparticle-based electron injection method offers a promising way to solve this problem since the size of nanoparticles is ~ ten’s nanometers and can avoid the modulation of laser pulse evolution from the electron injection process.

The method based on nanometer-sized particles, first proposed in 200720, uses a nanowire to trigger electron injection in plasma. Then nanoparticles are also studied based on multi-dimensional particle-in-cell simulations. These theoretical works showed that high-density ionized electrons from nanowires or nanoparticles induce an intense local electric field, strongly modulate a well-structured plasma wakefield, and thus a large amount of electron charge can be trapped. Moreover, simulations also illustrate that nanoparticle injection in plasma density of 1017 cm−3 can generate 5 GeV peak electron energy with a 1% relative energy spread21, which suggests that a single nanoparticle can trigger electron injection in low-density plasmas. In this paper, a localized nanoparticle insertion method is experimentally demonstrated to induce stable high-charge electron injections. It presents high injection probability over 90% and localized injection position within 100 μm. A 532 nm laser pulse is employed to produce nanoparticles. The fluence of the ablation laser can determine the size and density of nanoparticles, hence the electron beam charge and stability, providing a practical approach to control the beam source as desired. Nanoparticles with size of only a few tens of nanometer cannot cause a noticeable effect on the evolution of the main laser pulse in the plasma medium, but it can induce stable injection with a very high bunch charge. Thus, it decouples the injection process and the laser pulse evolution process, leading to highly collimated stable electron beams with a charge of 100 s’ pC and a large energy spread. This injection method can provide a suitable injector for multi-GeV laser electron accelerators.

## Results

We investigated the laser pulse evolution process for the nanoparticle-induced electron injection in a low-density plasma with 3D particle-in-cell (PIC) simulations and details of simulation parameters are given in “Methods”. When the nanoparticle is inserted into the plasma medium at x = 100 μm, it induces an intense local electric field, modulating the laser-driven plasma wakefield, and thus electrons are injected into the first plasma bubble21, as shown in Fig. 1a,b. The beam charge of these trapped electrons is 16 pC in our simulation condition. To see the laser pulse evolution in plasma, snapshots of laser field Ey lineout along the y-axis with/without the nanoparticle are plotted in Fig. 1c. We look into the deformation of the electric field by enlarging the part near the maximum Ey value along the x-axis at z = 0, as shown in Fig. 1d. The Ey lineouts with/without the nanoparticle at 0.4 ps and 1 ps are almost identical, while a slight difference appears at around the peak of the electric field. When the laser pulse passes through the nanoparticle at t = 0.4 ps, the electric field Ey, marked as the black solid line, shows a small diffraction pattern by the nanoparticle at around y = ±5 μm. The maximum modulation amplitude of the diffraction pattern is about $$\text{0.8}\%$$ of the maximum Ey value and gradually decreases during the laser propagation in plasma. The diffraction pattern vanishes at around 60 $$\upmu \mathrm{m}$$ away from the nanoparticle. When the laser pulse propagates further, no notable difference is seen with/without nanoparticle at t = 1 ps, plotted as the blue dot-dash line and green dashed line, respectively. Since the diffraction pattern of the laser pulse induced by a nanoparticle has a small amplitude and a short lifetime, the effect of the 100 nm nanoparticle on the laser evolution in plasma is negligible. The nanoparticles employed in experiments usually have diameters smaller than 100 nm and the nanoparticle-based injection fundamentally avoids the modulation of the laser pulse from the electron injection process. Thus, it decouples the injection process and the laser pulse evolution process, which can be suitable for multi-GeV electron bunch production that requires the guiding of a laser pulse over 10 cm.

Nanoparticles can be generated by laser ablation of a metal material using an intense laser pulse with duration from femtoseconds to nanoseconds. These metal nanoparticles usually have diameters below 100 nm22,23. Aluminum nanoparticles, generated by a 3-ns 532-nm ablation laser, have been proposed to trigger electron injection in our previous study24. This study demonstrated experimentally that a single nanoparticle is able to trigger electron injection and produce low-divergence electron bunches with a charge of a few pC. In the experimental setup, the aluminum target was set in the bottom of the nozzle and the emitted nanoparticles co-propagated with the gas flow, perpendicular to the main laser pulse, which triggered the electron injection when they met the driving laser pulse. However, in this approach, nanoparticles occupied the whole area of the gas jet, which causes uncertainty in the electron injection position along the laser pulse propagation direction. Lacking in the injection position control limited the generation of stable electron bunches.

When a multi-GeV stable electron bunch is anticipated based on nanoparticle-based injection, the generated nanoparticles must be localized at a fixed position along the main laser propagation direction. In this article, we propose a unique method to overcome the challenge, localizing the nanoparticle position within 100 μm and thus stabilizing electron injection. The experimental realization of this method was performed at CoReLS with a 5-Hz Ti: Sapphire laser that delivers 1.5 J on target with a pulse duration of 25 fs as main laser pulse. A thin copper blade was inserted above the nozzle and a 532-nm, 3-ns laser pulse ablates the top surface of the copper blade to produce a nanoparticle plume, as shown in Fig. 2. This setup assures that the nanoparticle plume occupies a narrow sheet region orthogonal to the main laser pulse. Thus, the main laser pulse meets the nanoparticles within a small distance below 100 μm during its propagation through the plasma medium along the x-axis, which provides a chance to induce a longitudinally localized injection.

The temporal delay between the ablation laser and the main laser pulse is determined by the ablation process for nanoparticle generation and the propagating time from the copper target to the beam path of the main laser. The ablation process of the copper target occurs in several nanoseconds and the expansion velocity $${\text{v}}_{\text{np}}$$ of the nanoparticle plume is 10–30 km/s25. When the plume arrives at the height of the main pulse, electron injection occurs once a nanoparticle within the plume moves into the focal volume of the main laser pulse. Experimental results indicate that the optimal delay between the ablation laser and the main laser is 0.15–0.35 μs, which matches well the estimated value based on nanoparticles velocities, $$\Delta {\text{t}}{=} \Delta {\text{z}}/{\text{v}}_{\text{np}}{=0.17-0.51 \upmu {\rm s}}$$.

The ablation laser fluence is the main factor that determines the nanoparticle size and density inside the plume. The electron bunch barely appeared as the ablation laser energy was below 5 mJ, where the nanoparticles were produced with a very low density such that the possibility for nanoparticles to meet with the focused laser pulse would be small. When the ablation laser energy increased to 12 mJ, i. e. its fluence of 84 J/cm2, the electron bunch signal emerged with a small divergence of 6 mrad as recorded in Lanex 1. Figure 3a displays these electron bunches recorded in Lanex 2 for 10 shots. The electron beams have a narrow energy spread with an average beam charge of 55 pC. Figure 3c plots the lineout of the energy spectrum and shows a single peak at 143 MeV with a relative energy spread of 30%. The energy peak of produced electron bunches stays between 140 and 170 MeV with an average energy of 155 MeV. The observed electron signals in Lanex 1 show that nanoparticles successfully trigger the electron injection. These electron bunches disappeared as the ablation laser was switched off. The stable output of a single energy peak in Lanex 2 implies the advantage of localizing the electron injection process within 100 μm along the main laser propagation axis.

The electron bunches with narrow-energy spread appeared with 23% probability under the ablation laser energy fluence of 84 J/cm2 based on data statistics over 200 shots. When the ablation fluence increased to 110 J/cm2, the injection probability by nanoparticles increased above 50%, as shown in Fig. 3e. It indicates that the nanoparticle density at the propagation path of the main laser pulse propagation is sufficiently high to support reproducible electron injection. Moreover, the bunch charge was raised to beyond 300 pC with broad energy spectra spreading up to 150 MeV, as plotted in Fig. 3b,d. Here we could not observe the electrons with energy below 90 MeV in Lanex 2 due to the limitation of the magnet exit size, but the beam charge was counted for all the accelerated electrons recorded on Lanex 1. Subsequently, the ablation fluence increased to 145 J/cm2, and it is remarkable to find out that the electron bunches were detected with a probability as high as 90% with wide energy spread. One possible reason for the beam charge enhancement is larger nanoparticle size due to the high ablation fluence, which is confirmed by the following nanoparticle characterization in Fig. 5d,e. In virtue of the localized insertion of nanoparticles, the stability and beam charge of e-beams can be controlled by adjusting the fluence of the ablation laser so as to choose the density and the size of nanoparticles, while this flexibility in case of non-localized nanoparticle insertion method can diminish due to the uncertainty of the injection position.

We observed, from the Lanex 1 data, that the average e-beam divergence varied only slightly from 8 to 12 mrad, as plotted in Fig. 4a, although the beam charge increased by almost ten times from about 50 pC to 500 pC. There is no significant increment of beam divergence with larger nanoparticle size because the enlarged size of nanoparticle is a few tens of nanometer, which is several-orders smaller than the plasma wavelength. In either case, we observed a single electron bunch on Lanex 1 as shown in Fig. 4b,c, which indicates that mainly one nanoparticle gets involved in the injection process, even for such0 high-charge beams. When the ablation laser fluence further increased beyond 200 J/cm2, multiple electron bunches were detected on Lanex 1. At this high ablation laser fluence, the nanoparticle density is so high that more than one nanoparticle is involved in the injection process for a single shot, as plotted in Fig. 4d. The multiple electron bunches accelerated to different propagation directions. Thus, the ablation laser fluence sets up a limit for tuning the ablation laser to manipulate the acceleration outcome. Consequently, manipulating the ablation laser fluence is a critical parameter to obtain high-charge low-beam-divergence electron beams.

In order to exclude the effect of gas profile variation by the cooper blade, we simulated the gas profile with the copper blade using the commercial code FLUENT based on a Computational Fluid Dynamics (CFD) modeling26. The chosen nozzle and copper blade geometry was the same as the experimental condition. The simulation results show that the gas flow is divided by the copper blade and merged again after flowing 4 mm above the nozzle exit. The longitudinal density profile has two individual density peaks at h = 3 mm in Fig. 5a, here x = 0 is the center of the gas nozzle. The gas flow starts to combine around 4 mm away from the nozzle exit, and the two density peaks are smeared. The density distribution recovers to an ordinary Gaussian-like profile above h = 6 mm. Figure 5a shows that the gas density profile at the height above 5 mm from the nozzle exit becomes a smooth gas profile, which is already sufficient to exclude the effect of gas disturbance by the cooper blade; consequently, we set the main laser pulse propagation path 6 mm away from the nozzle exit when the ablation laser was turned on. The formation of a smooth plasma channel with a length of about 3 mm was observed from the top-view CCD camera in the experiments.

The experimental results demonstrated that the localized nanoparticle insertion is an essential condition that enables the nanoparticle parameters to optimize the electron beam properties for high-charge stable electron beam. To characterize the copper nanoparticles, we inserted a silicon wafer 18 mm above the top surface of the copper target. The nanoparticles were deposited on the silicon wafer, allowing us to learn the spatial distribution and size of nanoparticles. The silicon wafer was exposed by the nanoparticle flume produced only by the ablation laser with an angle of 5º to the copper target. The copper target also moved with 100 μm step size in the y-axis after every five shots. Figures 5b,c show the scanning electron microscope (SEM) images of nanoparticles on the silicon wafer. The nanoparticles are close each other within a few μm because the wafer collected nanoparticles for 100 shots. In addition, the nanoparticle density reached maximum at x = 0 and dropped significantly as the position shifts by 25 μm either side along the x-axis, as shown in Fig. 5c. The nanoparticle distribution on silicon wafer explicitly shows that the nanoparticles occupy a small region of $$\Delta x<100 \upmu \mathrm{m}$$. In addition, previous numerical study21 also showed that the efficient electron injection can occur when the nanoparticle is located a quarter of laser beam diameter. Therefore, one or few nanoparticles could be involved efficient electron injection at this nanoparticle distribution. The designed setup for nanoparticle generation with a thin copper blade has provided a very localized region along the laser propagation axis for electron injection and thus stable energy output, which is consistent with the experimental observation showing the electron energy between 150 and 170 MeV.

The dependence of nanoparticle size on ablation laser fluence can be obtained from the SEM images of nanoparticle-deposited silicon wafers. Figure 5d–f show the nanoparticle size distribution with different ablation laser fluence after the accumulation of 100 shots. For the ablation laser fluence of 84 J/cm2, the nanoparticle size is in the range of 10–20 nm, with an average size of 19.9 nm. For the laser fluence of 180 J/cm2, the nanoparticle size is distributed between 20 and 40 nm with the average size of 30.8 nm and maximum size up to 90 nm. The electron density of an ionized copper nanoparticle is extremely high and generates an intense local electric field to trigger electron injection. The electric field is linear to the electron charge provided by a nanoparticle, $$Q=4\uppi nq{r}^{3}/3,$$ where n, q, and r are the atomic density, the charge state of copper ions, and the radius of the nanoparticle, respectively. As large-sized nanoparticles provide much stronger modulation of plasma wakefield, more electrons can be injected into a plasma bubble. We observed the electron bunch charge above 400 pC in experiments at the ablation fluence of 145 J/cm2, which is almost ten times higher than that at the ablation laser energy of 84 J/cm2. This indicates that the injected charge depends on the size of nanoparticles that can be controlled by the fluence of the ablation laser, as shown in Fig. 5f. Moreover, the modulation of plasma wakefield for a small-size nanoparticle is weak, and the injection with a small nanoparticle can be more sensitive to the fluctuations of laser conditions compared to the case of a large-size nanoparticle. In the experiment, the probability of triggering electron injection was 23% with the ablation laser fluence of 84 J/cm2, as shown in Fig. 3a, while the output stability increased above 90% as the ablations laser fluence increased to 145 J/cm2. This result showed that the control of ablation laser fluence provided the reliable electron injection from large-size nanoparticles; the electron injection process becomes much less dependent on the self-injection process susceptible to laser fluctuations. Furthermore, nanoparticles with higher material densities can provide higher nanoparticle field with same nanoparticle size, which can offer a chance to generate high-charge electron bunch with quasi-mono-energetic spectrum as expected in previous numerical study21. The localized nanoparticle insertion method can, thus, provide a suitable electron injector for staged LWFA, since the small beam divergence can provide an efficient beam loading in the second wakefield structure27,28.

## Conclusion

The nanoparticle insertion method to trigger electron injection in LWFA was successfully examined to decouple electron injection from laser evolution. The 3D PIC simulation results showed that it induced negligible effects on laser pulse evolution in a plasma. We have experimentally realized this controllable electron injection method using the laser ablation of a thin copper blade, where the injection length was only about 100 μm along the propagation direction of the main laser pulse. We demonstrated the stable generation of electron bunches with a charge of 100 s’ pC, a broad energy spectrum and small divergence angle by optimizing the laser ablation parameters that determine nanoparticle properties. Consequently, the stable high-charge low-beam-divergence electron beams, initiated by localized nanoparticle insertion, can bring significant advantages of efficient electron injection for a long-distance electron acceleration beyond 10 GeV in LWFA and high flux x-ray generations.

## Methods

### Experimental setup

A 5-Hz Ti: Sapphire laser at CoReLS is employed to study the electron acceleration process. The laser pulse was focused by an f/11 spherical mirror into the gas jet with a full-width-half-maximum (FWHM) focal size of 15 μm, corresponding to the peak intensity of 1 × 1019 W/cm2. A pulsed nozzle served as the gas jet and provided a 3-mm-long helium gas target. A copper blade with a thickness of only 0.1 mm and a height of 0.8 mm was inserted above the nozzle as the ablation target for nanoparticle generation, as shown in Fig. 2. The distance between the blade bottom and the nozzle exit was around 100 μm, which allows the copper blade to move freely in the xy plane. A 532-nm, 3-ns laser pulse with an energy density of 80–210 J/cm2 and focal size of 65 μm ablated the top surface of the copper blade to produce a nanoparticle plume. The created nanoparticle plume spreads to the normal direction of the blade top surface, i. e. along the z-axis, as shown in Fig. 2. In this way, nanoparticles pass through the beam path of the main laser pulse and trigger electron injection when they overlap with the focal volume of the main laser pulse. The copper target moved by 100 μm along the y-axis after every 5 shots because the nanoparticle generation and propagation direction strongly depend on the fresh surface of the ablation target29.

The main laser pulse in our experiment was set 6 mm away from the nozzle exit to drive a strong nonlinear plasma wave below the self-injection threshold at the gas pressure of 25 bar (gas density of $$\text{1.5} \times {10}^{18} \, {\text{cm}}^{-{3}}$$). This distance is monitored by a side-view CCD to image the plasma channel. The main laser pulse and the ablation laser pulse were precisely aligned with the help of a top-view CCD to assure their spatial overlap. The electron detection system consisted of one electron spectrometer and two pieces of Lanex screen. The e-beam spectrometer with a dipole magnet of B = 0.996 T was placed 43 cm away from the gas nozzle. Lanex 1, set in front of the spectrometer, was used to measure the bunch divergence, pointing, and beam charge. A 15 μm-thick aluminum foil blocks the laser beam for Lanex 1. The high-energy electrons are dispersed by the spectrometer and reach Lanex 2 behind the magnet exit. Both Lanexes are imaged by CCD cameras (FLIR Microline and GS3-U3-50S5M-C) with lenses (SAMYANG 2.8/100 mm and 1.4/85 mm). The open area of the magnet exit is $$\text{8 mm} \, \times 70\, \text{mm}$$, which allows us to measure the electron energy spectrum above 90 MeV with a full divergence angle of 12 mrad30.

### Simulations

We have performed 3D PIC simulations by the commercial code VORPAL to study laser pulse evolution process for the nanoparticle-induced electron injection in a low-density plasma31. The moving window has the size of 200 × 160 × 160 μm3, divided into 2000 × 800 × 800 cells. The laser pulse, linearly polarized along the y-axis, propagates along the x-axis with a peak intensity of I0 = 2 × 1019 W/cm2, pulse duration of 35 fs and FWHM focal size of 70 μm, which comes from the experimental condition for 7.8 GeV electron bunch generation19. The background electron density is 3.5 × 1017 cm−3 and the ionized nanoparticle is set at $${\text{x}} \, {=} \, \text{100 }\, \upmu \text{m}$$ with diameter of 100 nm and density of 100nc, here nc is the critical density for the laser center wavelength of 800 nm. Each cell contains 1 macro-particle for background electrons and 10,000 macro-particles for the nanoparticle electrons. Another simulation without nanoparticles was also performed for comparison. Both simulations end at x = 300 μm since we are only interested in the laser pulse evolution during the injection process.

## Data availability

The data that support the findings of this study are available from the corresponding author upon reasonable request. All data generated or analysed during this study are included in this published article.

## References

1. Tajima, T. & Dawson, J. M. Laser electron accelerator. Phys. Rev. Lett. 43, 267 (1979).

2. Esarey, E., Schroeder, C. B. & Leemans, W. P. Physics of laser-driven plasma-based electron accelerators. Rev. Mod. Phys. 81, 1229 (2009).

3. Pukhov, A. & Meyer-ter-Vehn, J. Laser wake field acceleration: the highly non-linear broken-wave regime. Appl. Phys. B Lasers Opt. 74, 355 (2002).

4. Faure, J. et al. Controlled injection and acceleration of electrons in plasma wakefields by colliding laser pulses. Nature 444, 737 (2006).

5. McGuffey, C. et al. Ionization induced trapping in a laser wakefield accelerator. Phys. Rev. Lett. 104, 025004 (2010).

6. Pak, A. et al. Injection and trapping of tunnel-ionized electrons into laser-produced wakes. Phys. Rev. Lett. 104, 025003 (2010).

7. Gonsalves, J. et al. Tunable laser plasma accelerator based on longitudinal density tailoring. Nat. Phys. 7, 862–866 (2011).

8. Buck, A. et al. Shock-front injector for high-quality laser-plasma acceleration. Phys. Rev. Lett. 110, 185006 (2013).

9. Xu, J. et al. Dynamics of electron injection in a laser-wakefield accelerator. Phys. Plasmas 24, 083106 (2017).

10. Maier, A. R. et al. Decoding sources of energy variability in a laser-plasma accelerator. Phys. Rev. X 10, 031039 (2020).

11. Fuchs, M. et al. Laser-driven soft-X-ray undulator source. Nat. Phys. 5, 826 (2009).

12. Ta Phuoc, K. et al. All-optical Compton gamma-ray source. Nat. Photon. 6, 308 (2012).

13. Khrennikov, K. et al. Tunable all-optical quasimonochromatic Thomson X-ray source in the nonlinear regime. Phys. Rev. Lett. 114, 195003 (2015).

14. Lu, W. et al. Generating multi-GeV electron bunches using single stage laser wakefield acceleration in a 3D nonlinear regime. Phys. Rev. ST Accel. Beams 10, 061301 (2007).

15. Lu, H. et al. Laser wakefield acceleration of electron beams beyond 1 GeV from an ablative capillary discharge waveguide. Appl. Phys. Lett. 99, 091502 (2011).

16. Wang, X. et al. Quasi-monoenergetic laser-plasma acceleration of electrons to 2 GeV. Nat. Commun. 4, 1988 (2013).

17. Kim, H. T. et al. Stable multi-GeV electron accelerator driven by waveform-controlled PW laser pulses. Sci. Rep. 7, 10203 (2017).

18. Qin, Z. et al. Hybrid capillary discharge waveguide for laser wakefield acceleration. Phys. Plasmas 25, 073102 (2018).

19. Gonsalves, A. J. et al. Petawatt laser guiding and electron beam acceleration to 8 GeV in a laser-heated capillary discharge waveguide. Phys. Rev. Lett. 122, 084801 (2019).

20. Shen, B. et al. Electron injection by a nanowire in the bubble regime. Phys. Plasmas 14, 053115 (2007).

21. Cho, M. H., Pathak, V. B., Kim, H. T. & Nam, C. H. Controlled electron injection facilitated by nanoparticles for laser wakefield acceleration. Sci. Rep. 8, 16924 (2018).

22. Leitz, K. H. et al. Metal ablation with short and ultrashort laser pulses. Phys. Proc. 12, 230 (2011).

23. Kim, M., Osone, S., Kim, T., Higashi, H. & Seto, T. Synthesis of nanoparticles by laser ablation: A review. KONA Powder Part. J. 34, 80 (2017).

24. Aniculaesei, C. et al. Proof-of-principle experiment for nanoparticle-assisted laser wakefield electron acceleration. Phys. Rev. Appl. 12, 044041 (2019).

25. Wang, X. et al. Temporally and spectrally resolved analysis of a copper plasma plume produced by ultrafast laser ablation. Appl. Surf. Sci. 255, 5211 (2009).

26. Liu, J. S. et al. All-optical cascaded laser wakefield accelerator using ionization-induced injection. Phys. Rev. Lett. 107, 035001 (2011).

27. Steinke, S. et al. Multistage coupling of independent laser-plasma accelerators. Nature 530, 190 (2016).

28. Sun, M. et al. Numerical analysis of laser ablation and damage in glass with multiple picosecond laser pulses. Opt. Exp. 21, 7858 (2013).

29. Aniculaesei, C. et al. Electron energy increase in a laser wakefeld accelerator using up-ramp plasma density profiles. Sci. Rep. 9, 11249 (2018).

30. Nieter, C. & Cary, J. R. VORPAL: A versatile plasma simulation code. J. Comput. Phys. 196, 448 (2004).

## Acknowledgements

This work was supported by the Institute for Basic Science, Korea (IBS-R001-D1) and the Strategic Priority Research Program of the Chinese Academy of Sciences (Grant No. XDB16), the National Natural Science Foundation of China (Project Nos. 12175299, 11775287 and 11935008) and the Ministry of Science and Technology of the People’s Republic of China (Grant No. 2016YFA0401102). H. T. K., J. W. Y., J. H. S. and S. K. L. were partially supported by GIST Research Institute (GRI) grant funded by the GIST in 2021. H.T.K. was also partly supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIT) Grant No. NRF-2020R1F1A1070538.

## Author information

Authors

### Contributions

J.X. and H.T.K. designed the experimental setup. J.X., L.B., M.E., S.H.L. and H.T.K. participated in the experiments. J.X. and B.S. performed the PIC simulation. J.X. and H.T.K. prepared the manuscript draft. B.S., L.L.J. and C.H.N. contributed to the manuscript correction and revisions. All authors discussed the results and commented on the manuscript.

### Corresponding authors

Correspondence to Hyung Taek Kim or Baifei Shen.

## Ethics declarations

### Competing interests

The authors declare no competing interests.

### Publisher's note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

## Rights and permissions

Reprints and Permissions

Xu, J., Bae, L., Ezzat, M. et al. Nanoparticle-insertion scheme to decouple electron injection from laser evolution in laser wakefield acceleration. Sci Rep 12, 11128 (2022). https://doi.org/10.1038/s41598-022-15125-6

• Accepted:

• Published:

• DOI: https://doi.org/10.1038/s41598-022-15125-6


text:
Calibri in proTeXt

I am a novice LaTeX user. I am using the proTeXt version.

I am trying to change the font of a document to Calibri (which I have on my machine). Any tips?

-
Welcome to TeX.sx! Usually, we don't put a greeting or a "thank you" in our posts. While it might seem strange at first, it is not a sign of lack of politeness, but rather part of our trying to keep everything very concise. Upvoting is the preferred way here to say "thank you" to users who helped you. –  doncherry Jul 26 '11 at 16:20

General info: proTeXt is a bundle containing, among other things, the MikTeX distribution.

Afaik, there's no way to use Calibri with pdfLaTeX, but you can easily use it with XeLaTeX:

\documentclass{article}

\usepackage{fontspec}

\setmainfont{Calibri}

\begin{document}

Hello World

\end{document}

I recommend not using TeXnicCenter (which comes with proTeXt) for XeLaTeX because TXC doesn't support Unicode. Use e.g. TeXworks instead, which comes with MikTeX, so it should be on your machine as well. For some differences in usage between pdfLaTeX and XeLaTeX take a look at Frequently loaded packages: Differences between pdfLaTeX and XeLaTeX.

-


text:
# Real Analysis: show sequences have the same limit if |Xn-Yn| approaches 0

## Homework Statement

Suppose {Xn}, {Yn} are sequences in ℝ and that |Xn-Yn|→0. Show that either: a) {Xn} and {Yn} are both divergent or b) {Xn} and {Yn} have the same limit.

N/A

## The Attempt at a Solution

I first prove that lim(Xn-Yn)=lim(Xn)-lim(Yn). I am not completely clear on the validity of this proof.
Since |Xn-Yn|→0, |Xn-Yn-(x-y)|<ε. Now |Xn-Yn-(x-y)|=|(Xn-x)-(Yn-y)|≥|Xn-x|-|Yn-y| (from the triangle inequality).
So, |Xn-x|-|Yn-y|<ε. Therefore, the lim(Xn-Yn)=lim(Xn)-lim(Yn).

So, we have that lim(Xn-Yn)=lim(Xn)-lim(Yn). Then, if I assume Xn→x, then 0=x-lim(Yn). So, lim(Yn)=x. So, they have the same limit. If Xn does not have a limit, then both {Xn} and {Yn} must be divergent.

I would like to know if this is the correct approach to take and if the proof is correct. Thank You.

Related Calculus and Beyond Homework Help News on Phys.org
SammyS
Staff Emeritus
Homework Helper
Gold Member
What you really need to prove are the following:

1) If one of them, say {xn}, converges, then so does the other.

2) If one of them diverges, then so does the other.

You can alternatively prove this by contradiction as follows. Assume one of them converges, and one of them diverges. Then show that this,

Last edited:
But you still have to prove that if both of them converge that they converge to the same value?
I don't quite understand what is implied by limn→∞|xn-yn|=0. Does this mean the lim(xn)→lim(yn)?

SammyS
Staff Emeritus
Homework Helper
Gold Member
But you still have to prove that if both of them converge that they converge to the same value?
I don't quite understand what is implied by limn→∞|xn-yn|=0. Does this mean the lim(xn)→lim(yn)?
No, you do.

limn→∞(xn-yn)=0 means |Xn-Yn|→0

I meant you as a general you, meaning whoever is doing the proof, meaning me. Anyway, I'm not looking for answers so calm down. I'm just trying to understand the steps of the proof. Does limn→∞(xn-yn)=0 mean that xn and yn converge to the same value (namely, that x=y)?

Also, I don't understand what would be wrong with proving lim(xn-yn)=lim(xn)-lim(yn) [which I now figured out how to prove correctly], and then say that assuming xn→x then 0=x-lim(yn) and lim(yn)=x. Otherwise, if xn does not approach x, then of course yn is also divergent.

nyr:

Assume for a moment that the difference xn-yn is always positive, or nonnegative. What can you then say about Limn→∞|xn-yn|? Consider then all other possible cases re the difference xn-yn


text:
# American Institute of Mathematical Sciences

May  2010, 27(2): 441-486. doi: 10.3934/dcds.2010.27.441

## Mathematical strategies for filtering turbulent dynamical systems

 1 Department of Mathematics and Center for Atmosphere and Ocean Science, Courant Institute for Mathematical Sciences, New York University, New York, NY 10012-1110, United States, United States 2 Depatment of Mathematics, North Carolina State University, Raleigh, NC 27695, United States

Received  October 2009 Revised  February 2010 Published  February 2010

The modus operandi of modern applied mathematics in developing very recent mathematical strategies for filtering turbulent dynamical systems is emphasized here. The approach involves the synergy of rigorous mathematical guidelines, exactly solvable nonlinear models with physical insight, and novel cheap algorithms with judicious model errors to filter turbulent signals with many degrees of freedom. A large number of new theoretical and computational phenomena such as "catastrophic filter divergence" in finite ensemble filters are reviewed here with the intention to introduce mathematicians, applied mathematicians, and scientists to this remarkable emerging scientific discipline with increasing practical importance.
Citation: Andrew J. Majda, John Harlim, Boris Gershgorin. Mathematical strategies for filtering turbulent dynamical systems. Discrete & Continuous Dynamical Systems - A, 2010, 27 (2) : 441-486. doi: 10.3934/dcds.2010.27.441
 [1] Håkon Hoel, Gaukhar Shaimerdenova, Raúl Tempone. Multilevel Ensemble Kalman Filtering based on a sample average of independent EnKF estimators. Foundations of Data Science, 2020  doi: 10.3934/fods.2020017 [2] Siyang Cai, Yongmei Cai, Xuerong Mao. A stochastic differential equation SIS epidemic model with regime switching. Discrete & Continuous Dynamical Systems - B, 2020  doi: 10.3934/dcdsb.2020317 [3] Jiaquan Liu, Xiangqing Liu, Zhi-Qiang Wang. Sign-changing solutions for a parameter-dependent quasilinear equation. Discrete & Continuous Dynamical Systems - S, 2020  doi: 10.3934/dcdss.2020454 [4] Alberto Bressan, Wen Shen. A posteriori error estimates for self-similar solutions to the Euler equations. Discrete & Continuous Dynamical Systems - A, 2021, 41 (1) : 113-130. doi: 10.3934/dcds.2020168 [5] Zhiyan Ding, Qin Li, Jianfeng Lu. Ensemble Kalman Inversion for nonlinear problems: Weights, consistency, and variance bounds. Foundations of Data Science, 2020  doi: 10.3934/fods.2020018 [6] Aihua Fan, Jörg Schmeling, Weixiao Shen. $L^\infty$-estimation of generalized Thue-Morse trigonometric polynomials and ergodic maximization. Discrete & Continuous Dynamical Systems - A, 2021, 41 (1) : 297-327. doi: 10.3934/dcds.2020363 [7] Xin Guo, Lei Shi. Preface of the special issue on analysis in data science: Methods and applications. Mathematical Foundations of Computing, 2020, 3 (4) : i-ii. doi: 10.3934/mfc.2020026 [8] Shenglan Xie, Maoan Han, Peng Zhu. A posteriori error estimate of weak Galerkin fem for second order elliptic problem with mixed boundary condition. Discrete & Continuous Dynamical Systems - B, 2020  doi: 10.3934/dcdsb.2020340 [9] Marion Darbas, Jérémy Heleine, Stephanie Lohrengel. Numerical resolution by the quasi-reversibility method of a data completion problem for Maxwell's equations. Inverse Problems & Imaging, 2020, 14 (6) : 1107-1133. doi: 10.3934/ipi.2020056 [10] Dan Zhu, Rosemary A. Renaut, Hongwei Li, Tianyou Liu. Fast non-convex low-rank matrix decomposition for separation of potential field data using minimal memory. Inverse Problems & Imaging, , () : -. doi: 10.3934/ipi.2020076 [11] Zhenzhen Wang, Tianshou Zhou. Asymptotic behaviors and stochastic traveling waves in stochastic Fisher-KPP equations. Discrete & Continuous Dynamical Systems - B, 2020  doi: 10.3934/dcdsb.2020323 [12] Peizhao Yu, Guoshan Zhang, Yi Zhang. Decoupling of cubic polynomial matrix systems. Numerical Algebra, Control & Optimization, 2021, 11 (1) : 13-26. doi: 10.3934/naco.2020012 [13] Lorenzo Zambotti. A brief and personal history of stochastic partial differential equations. Discrete & Continuous Dynamical Systems - A, 2021, 41 (1) : 471-487. doi: 10.3934/dcds.2020264 [14] Ilyasse Lamrani, Imad El Harraki, Ali Boutoulout, Fatima-Zahrae El Alaoui. Feedback stabilization of bilinear coupled hyperbolic systems. Discrete & Continuous Dynamical Systems - S, 2020  doi: 10.3934/dcdss.2020434 [15] Felix Finster, Jürg Fröhlich, Marco Oppio, Claudio F. Paganini. Causal fermion systems and the ETH approach to quantum theory. Discrete & Continuous Dynamical Systems - S, 2020  doi: 10.3934/dcdss.2020451 [16] Xiyou Cheng, Zhitao Zhang. Structure of positive solutions to a class of Schrödinger systems. Discrete & Continuous Dynamical Systems - S, 2020  doi: 10.3934/dcdss.2020461 [17] Laurence Cherfils, Stefania Gatti, Alain Miranville, Rémy Guillevin. Analysis of a model for tumor growth and lactate exchanges in a glioma. Discrete & Continuous Dynamical Systems - S, 2020  doi: 10.3934/dcdss.2020457 [18] Laurent Di Menza, Virginie Joanne-Fabre. An age group model for the study of a population of trees. Discrete & Continuous Dynamical Systems - S, 2020  doi: 10.3934/dcdss.2020464 [19] Yuri Fedorov, Božidar Jovanović. Continuous and discrete Neumann systems on Stiefel varieties as matrix generalizations of the Jacobi–Mumford systems. Discrete & Continuous Dynamical Systems - A, 2020  doi: 10.3934/dcds.2020375 [20] Xuhui Peng, Rangrang Zhang. Approximations of stochastic 3D tamed Navier-Stokes equations. Communications on Pure & Applied Analysis, 2020, 19 (12) : 5337-5365. doi: 10.3934/cpaa.2020241

2019 Impact Factor: 1.338

## Metrics

• PDF downloads (45)
• HTML views (0)
• Cited by (46)

## Other articlesby authors

• on AIMS
• on Google Scholar

[Back to Top]


text:
An investor is in the 33 percent tax bracket and

An investor is in the 33 percent tax bracket and pays long-term capital gains taxes of 15 percent. What are the taxes owed (or saved in the cases of losses) in the current tax year for each of the following situations?
a) Net short-term capital gains of $3,000; net long-term capital gains of$4,000
b) Net short-term capital gains of $3,000; net long-term capital losses of$4,000
c) Net short-term capital losses of $3,000; net long-term capital gains of$4,000
d) Net short-term capital gains of $3,000; net long-term capital losses of$2,000
e) Net short-term capital losses of $4,000; net long-term capital gains of$3,000
f) Net short-term capital losses of $1,000; net long-term capital losses of$1,500
g) Net short-term capital losses of $3,000; net long-term capital losses of$2,000

Ashish C

Introduction:

The question requires us to calculate the amount of tax owed/ saved by an investor who is in the 33 percent tax bracket in different situations as given in the question. Also, it is given that Long Term Capital Gains are taxable @ 15%.

Basics:

Before attempting the solution let us understand the basics of ‘set-off and carry forward’ in relation to Capital Gains/ Capital Losses.

Short Term Capital Losses (STCL) arising to the investor in a particular year is allowed to be set-off against Long Term Capital Gains (LTCG) of that year. Therefore, tax will be required to be paid on the amount after netting off STCL from LTCG. In case, the amount of STCL exceeds LTCG, no tax shall be payable and the balance STCL shall be carried forward to the next year.

However, it must be noted that though STCL is allowed to be set-off against LTCG, the converse do not follow, i.e. Long Term Capital Loss (LTCL) cannot be set off against Short Term Capital Gains (STCG) of that year. In this case, the entire LTCL will be carried forward to the next year and tax will be payable on entire STCG as per the tax bracket of the Investor.

Why So?  This is because STCG is chargeable as per the tax bracket of the Investor, i.e. in this case, 33%....


text:
## microscopic cross-section, $$\sigma$$

https://doi.org/10.1351/goldbook.M03911
A measure of the @P04855@ of a specified interaction or reaction between an incident radiation and a target particle or system of particles. It is the reaction rate per target particle for a specified process divided by the @F02461@ of the incident radiation. In general, a specification is added of the type of radiation (e.g. @N04116@, photon), the @E02102@ of the incident radiation (e.g. thermal, epithermal, fast) and the type of interaction of reaction (e.g. @A00103@, @N04229@, @S05487@).
See also:
macroscopic cross-section
Sources:
Orange Book, 2nd ed., p. 217 [Terms] [Book]
PAC, 1994, 66, 2513. (Nomenclature for radioanalytical chemistry (IUPAC Recommendations 1994)) on page 2517 [Terms] [Paper]


text:
# If-statement consolidation

I often face the problem of stacked if-statements that look repetitive, but usually can't find an easy way to simplify it.

    if (keyState[BOTTOM]){
dig_direction = BOTTOM;
startDig(SIZE / 2 - x % SIZE, DIG_DEPTH);
} else if (keyState[RIGHT] && isTouching[RIGHT]){
dig_direction = RIGHT;
startDig(DIG_DEPTH, 0);
} else if (keyState[LEFT] && isTouching[LEFT]){
dig_direction = LEFT;
startDig(-DIG_DEPTH, 0);
}

-
Your code could probably be prettified, but not locally — there just isn't much material to work with here. We would need to take a look at the big picture. I encourage you to post a more comprehensive sample for review — probably as a separate question. –  200_success Aug 15 at 7:44

You want Replace Conditional with Polymorphism : "Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract."

Your conditional from the example could then look like this :

digPosition.startDig()

digPosition being an instance of an interface DigPosition which has three implementations : BottomDigPosition, RightDigPosition and LeftDigPosition.

-
My bad! I'm using JavaScript not Java. –  John Aug 15 at 7:13
Ok, nevertheless, the pattern is applicable in javascript just as well I'd say. –  bowmore Aug 15 at 7:15
@bowmore I wouldn't be quite so sure about that. At least it's unproportionally more effort needed in JavaScript than in Java.... –  Vogel612 Aug 15 at 10:22
@Vogel612 well, I'm not familiar enough with javascript to judge that. But the amount of effort needed, does not invalidate the benefits of using the pattern. Of course we shouldn't blindly apply patterns, for the sake of having patterns. But if this same if structure (bottom/left/right) is repeated several times throughout the code, then the pattern is probably worthwhile. If it's just this one occurrence, then even in Java it would be overkill. –  bowmore Aug 15 at 12:15


text:
JessiaLee9
2

Given the volume of a cube is 8 cubic meters, find the distance from any vertex to the center point inside the cube. (A) 1 m (B) √2 m (C) 2√2 m (D) 2√3 m (E) √3 m

$V=8m^3\\\\V=a^3\\\\a^3=8m^3\to a=\sqrt[3]{8m^3}=2m\\\\diagonal\ of\ a\ cube:D=a\sqrt3\\\\D=2\sqrt3m\\\\Distance\ from\ any\ vertex\ to\ the\ center\ point\ inside\ the\ cube\\is\ a\ half\ of\ a\ diagonal:\\2\sqrt3:2=\sqrt3\ (m)\\\\Answer:E$


text:
# Q. The volume strength of 1.5 NH$_2O_2$ is

IIT JEEIIT JEE 1990Some Basic Concepts of Chemistry

Solution:

## Volume strength ofH$_2O_2$=Normality $\times$5.6= 1.5 $\times$ 5.6=8.4V

You must select option to get answer and solution

## 1. The aqueous solution of the following salts will be coloured in case of

The d-and f-Block Elements

Manipal 2009

## 1. An acidic buffer solution can be prepared by mixing the solution of

IIT JEE 1981 Equilibrium

## 2. A mixture of benzaldehyde and formaldehyde on heating with aqueous NaOH solution gives

IIT JEE 2001 Aldehydes Ketones and Carboxylic Acids

## 3. Which of the following solutions will have pH close to 1.0 ?

IIT JEE 1992 Equilibrium

## 4. Acetone is mixed with bleaching powder to give

AFMC 2004 Aldehydes Ketones and Carboxylic Acids

## 5. 75% of a first order reaction was completed in 32 minutes. When was 50% of the reaction completed

COMEDK 2010 Chemical Kinetics

## 6. The radii of $Na^+$ and $Cl^{-1}$ ions are 95 pm and 181 pm respectively. The edge length of NaCl unit cell is

KCET 2006 The Solid State


text:
# Increase in per capita GDP always means GDP is growing?

This question was asked in very popular civil services examination.

Question is : Whether the following statement is correct or not? Statement : If a country is experiencing increase in its per-capita GDP, its GDP must necessarily be growing?

The approach I applied is that, in a country like Syria, if mass emigration happens then population will decrease and at the same time GDP might not decrease with same rate. so this statement will be false.

• What do you mean your assumption is not correct? Jun 6, 2017 at 13:56
• I'm not good in such questions/topics, so I'm just afraid if this is right way to think or not. Moreover I didn't want this particular assumption to prevent better examples coming from more qualified people here. Jun 6, 2017 at 14:01
• I am not sure I understand what you are asking, but if $G_p = G/(population)$ is the per-capita GDP then $G_p$ increases if the population shrinks or the GDP grows, as you pointed out. So the statement is not correct. Jun 6, 2017 at 14:33
• OP, your logic is correct, The statement is false, because the increase in GDP per capita could be due to a population decrease. Jun 6, 2017 at 14:34
• Possible duplicate of Calculating rate of growth of per capita income Jun 6, 2017 at 15:59