text:
# Recurrence formula for division of a sphere by n great circles

Find the recurrence relation satisfied by $$R_n$$, where $$R_n$$ is the number of regions into which the surface of a sphere is divided by n great circles (which are the intersections of the sphere and planes passing through the center of the sphere), if no three of the great circles go through the same point

From: Rosen Discrete Mathematics textbook

My attempt: I was unable to visualize these greater circles for values of $$n \geq 4$$. So, I launched GeoGebra and made the following plot:

My initial planes were $$x=y$$, $$x=-y$$, and the $$z=0$$ plane. Now, I added a fourth yellow plane $$y=z$$. However, I still find it hard to understand how to calculate what number of new sections are formed. I am able to calculate the number of new sections in this specific case, but, I am unable to arrive at a general formula for the new number of sections, through recurrence.

I visited the following website - Slader - which happens to have a solution, where they mention the addition of $$2(n-1)$$ regions to the existing regions, after the addition of the $$n$$-th plane. However, I am unable to understand why exactly that is true.

• It's $2(n-1),$ not $3(n-1)$. Also, "splitting up into $2(n-1)$ regions" sounds like you end up with just $2(n-1)$ regions after the "splitting," whereas actually they are adding $2(n-1)$ new regions to the ones that already existed. – David K Oct 12 '18 at 10:53
• @DavidK Sorry you're right, I've made the necessary correction. – Gaurang Tandon Oct 12 '18 at 10:56

Why, that's simple: the $$n$$'th great circle intersects each and every one of the previous circles, right? OK, then how many intersection points are on it? Obviously, $$2(n-1)$$, because each pair of circles intersects twice.
Now, the $$2(n-1)$$ intersection points break our circle into as many pieces. Look at one such piece. What good does it do? See, it breaks some region of the sphere in two. In other words, it increments the number of regions by 1.

format: plain


text:
• On an Inequality Concerning the Polar Derivative of a Polynomial

• # Fulltext

https://www.ias.ac.in/article/fulltext/pmsc/117/03/0349-0357

• # Keywords

Zygmund’s inequality; polar derivative; $L_p$-norm inequalities.

• # Abstract

In this paper, we present a correct proof of an $L_p$-inequality concerning the polar derivative of a polynomial with restricted zeros. We also extend Zygmund’s inequality to the polar derivative of a polynomial.

• # Author Affiliations

1. Post Graduate Department of Mathematics, University of Kashmir, Hazratbal, Srinagar 190 006, India

• # Proceedings – Mathematical Sciences

Current Issue
Volume 129 | Issue 5
November 2019

• # Editorial Note on Continuous Article Publication

Posted on July 25, 2019

Click here for Editorial Note on CAP Mode

© 2017-2019 Indian Academy of Sciences, Bengaluru.


text:
# .-...--..---.-...--..... the red-nosed reindeer

Can you recover a sequence of letters from a sequence of dots and dashes? In Morse code, x is represented by -..-, but without the help of spaces, -..---.-... could represent xmas, or dole, or teettteteee, etc.

I took the lyrics from "Rudolph, the Red-Nosed Reindeer" to make the following sequence of letters:

youknowdasheranddancerandprancerandvixencometandcupidanddonnerandblitzenbutdoyourecallthemostfamousreindeerofallrudolphtherednosedreindeerhadaveryshinynoseandifyoueversawityouwouldevensayitglowsalloftheotherreindeerusedtolaughandcallhimnamestheyneverletpoorrudolphjoininanyreindeergamesthenonefoggychristmasevesantacametosayrudolphwithyournosesobrightwontyouguidemysleightonightthenhowthereindeerlovedhimastheyshoutedoutwithgleerudolphtherednosedreindeeryoullgodowninhistory

and then I converted each letter to its Morse code representation to get

-.-----..--.--.---.---...-.........-..--.-..-...--.-.-...-..--.-...--..-..--.-.-...-..--.-.....-..-..-.-.-.-.-----.-.--.-..-.-...-.--...-...--.-..-..----.-...-..--.-..-....-....---...-.-.....---..----.-----..-.-..-.-..-.-...-..-.....-----...-..-..------..-....-....-.-.....-.---..-..-.-...-...-...--..---.-...--.....-......-..-..-.---....-...-....-.-.....-......--...-...-..-.-.--.........-.-.---.---.....--.-......-.-.-----..-....-..-.....-.--..--.-----..-.-----..-.-..-......-.-.....--.--..---..-..---.--....-.-...-..---..-.-.....----......-..-....-.-.....-...-....-..----.-...-..---......--.-..-.-..-.-...-........---..---....-.....-.---.....-..-..-...-.--.------.-..-...--..---.-...--......------..-...-..--.-.--.-....-.-.....-.--..---....-.....-.----....-.-----.--.-.---.-......-......---.-.......-.....--.-.--.-..---.----....--.--.-...--..---.-...--......--..-....-.-----..-.-.-.---.......----....-...--.....-.------.--.-----..---...-..-...---.--....-.....--.....-----...--.....--.....-.....---.---......-....-.-.....-..-..---...-.-........--.-...-.....-.--.......---..--.-..---..--.--..-....--..-.....-...--..---.-...--.....-......-..-..-.---....-...-....-.-.....-.-.-----..-.-...-..--.----..---.---...-..........----.-.-.--

For reference, here are a few Morse code libraries:

a .- b -... c -.-. d -.. e . f ..-. g --. h .... i .. j .--- k -.- l .-.. m -- n -. o --- p .--. q --.- r .-. s ... t - u ..- v ...- w .-- x -..- y -.-- z --..

.- a -... b -.-. c -.. d . e ..-. f --. g .... h .. i .--- j -.- k .-.. l -- m -. n --- o .--. p --.- q .-. r ... s - t ..- u ...- v .-- w -..- x -.-- y --.. z

.- -... -.-. -.. . ..-. --. .... .. .--- -.- .-.. -- -. --- .--. --.- .-. ... - ..- ...- .-- -..- -.-- --..

Write the shortest code that takes as input the sequence of dots and dashes above and one of the Morse code libraries above, and then outputs the sequence of letters above.

Edit 1: Since we are ignoring the letter spaces and word spaces that are typically used in Morse code, this challenge is nontrivial and significantly different from previous challenges involving Morse code. We are implicitly hunting for the relative Kolmogorov complexity of a fixed sequence of letters given the corresponding sequence of dots and dashes. This means your code only needs to run for the fixed inputs provided above, and produce the desired output provided above.

Edit 2: By popular request, I am relaxing the constraint on the Morse code library by providing two alternative libraries. If necessary, I am willing to add reasonable libraries in the future.

# Python 3, 356, 302, 299 bytes

import sys
print(S)

Try it online!

Takes the library followed by a newline followed by the morsecode from the standard input.

The library used is .- -... -.-. -.. . ..-. --. .... .. .--- -.- .-.. -- -. --- .--. --.- .-. ... - ..- ...- .-- -..- -.-- --..

## Explanation:

The majority of the code is a precalculated number of morse widths. A morse caracter in the library is between 1 and 4 dihs and dahs long. In the number i store this as two bits of information. To recall this number i & it with 3 and shift the result over by two bits.

I then read the number of dihs and dahs from the standard input and lookup in the library what the offset of that caracter is from "a". Then repeat and print.

I think the best way to shave of bytes will be to store the number more compactly.

Edit: removed 54 bytes by changing the library format, and storing the number as base36 following the suggestions of A Rex and Chas Brown

Edit: -3 bytes for removing redundant parameter from str.split() - Chas Brown

• Wow, nice first answer! Dec 26 '19 at 15:34
• The question has been updated to allow different formats for the library. I believe this would let you skip the [1::2] in your answer. Dec 26 '19 at 16:03
• 308 by encoding your Magic Number as base 36 and putting the while loop on one line. (And, Welcome to codegolf!) Dec 26 '19 at 21:27
• You can save 3 more by replacing .strip(" ") with .strip(). Dec 27 '19 at 5:47

# APL (Dyalog Extended), 189 188 bytesSBCS

Full program. Prompts for the Morse code. Doesn't need the library. Requires ⎕IO←0

⌊⌂morse⍞⊂⍨∊1↑⍨¨1+4⊤'⍳÷+≠í⍀÷<í∧○Ñ>å/∧∨êî∘ß∧äñ⍀○≠è[*⌷∨[î≠∇è⊂Øî⊃⍀[⌷Éäï\∘∧↑æ=íå⌿∧∨ëäÖ⌿ê/≤⌊∘[Å↓Öï○+Ü÷≥↓≤≥>⌷∘á⊃↑Ü⍳⊣[⌿-Ø↑ä/∧∧≠≠Ñíí+ßÜ+-○é↓↓≥≥×∧↑**⍨↑}∧⍨≥ç⍀∧}×⍀Àëç⍀Ø⍨∧∘[×/∘Å∧~≥○ëâ⊂å∨≥Àäè?'⍳⍨125↓⎕AV

Try it online!

⎕AV the Atomic Vector (the character set)

125↓ drop the first 125

''⍳⍨ the indices in that of these characters

4⊤ To-base four

1+ increment

This gives us the length of each Morse letter.

¨ for each of those lengths:

1↑⍨ take that many elements from 1, padding with zeros when needed

∊ϵnlist (flatten)

⊂⍨ use that as a mask indicating partition-beginnings to cut the following:

⍞ prompt for Morse code

⌂morse convert from Morse code to uppercase text

⌊ lowercase

# APL (Dyalog) + dfns + Jelly's dictionary, 181 175 (172🐌) bytesSBCS

Full program. Requires ⎕IO←0 and ⎕AV redefinition. Doesn't use the challenge's Morse code library.

M←∊∘morse¨D⋄C←∊(7⍴51)⊤246⊥5 17⍴¯7+⎕AV⍳'k%aÏ⍵FþfÅ⍵ìÆ⌶á≥å3¶cÒ⍺\ujü─⍳%S⊣ì⍙ÒÛÙ3ÙpØ,hÇñ⊂┴Ö⍪l∪⍒i1⍵Í:-îà⌽ì≥3€ã(⍝S]ÁGXræ∇O7Uæî'
C↓⍨←≢i↓⍨←≢M⊃⍨w←(⊃C)⌷∊(⍸M⍷⍨⊂)¨⌽,\24↑i
⍞←819⌶w⊃D
→2

Try it online! - 175 byte version, running at decent speed

M←∊∘morse¨D⋄C←∊(7⍴51)⊤246⊥5 17⍴¯7+⎕AV⍳'k%aÏ⍵FþfÅ⍵ìÆ⌶á≥å3¶cÒ⍺\ujü─⍳%S⊣ì⍙ÒÛ─3ÙpØ,hÇñ⊂┴Ö⍪l∪çi1⍵Û:-îà⌽ì≥3€ã(⍟S]ÁôXræ∇O7Uæî'
C↓⍨←≢i↓⍨←≢M⊃⍨w←(⊃C)⌷∊(⍸M⍷⍨⊂)¨⌽,\i
⍞←819⌶w⊃D
→2

Try it online! - 172 byte 🐌 version, taking about 20 times as long to finish (especially slow at beginning)

-3 bytes by packing base 51 into base 246 instead of base 64 into base 256 and losing the apostrophe -3 bytes by ending with an error message instead of cleanly
-3 bytes by running about 20 times more slowly

When I saw this question, I thought that the ultimate solution, the one the question was made for, would involve combining both the Morse code and a dictionary. I was surprised when the only submitted solutions turned out to use a table of letter boundaries. My interest was sparked; I'd take a crack at it myself.

The first step was to look for a suitable dictionary (I tried a few). Then I implemented the first version of the algorithm in C++. This enumerated all the possible words that could be at a given point, numbering them sequentially, until finding the one matching its corresponding value in an array made from running the same algorithm with the words of the song as a reference. This initial version enumerated the words in alphabetical order.

I was rather astonished to see just how ambiguous Morse code is without the inter-letter gaps. I expected it to be somewhat ambiguous, but not to the extent that it actually turns out to be! Some of the alternatives are pretty funny, too. Every time reindeer comes up, for example, it could also be leech. And the entire song can be mapped to completely different words, all the way from start to finish (gibberish, but present in the dictionary).

The dictionaries I tried turned out to be not so well-suited to the task. Either they were missing too many words, requiring them to be added to the dictionary for the algorithm to work, or they were too comprehensive, and the resulting array of "word choices" had elements exceeding 63, meaning it couldn't be packed into 6 bits per word.

Then it occurred to me to try Jelly's dictionary. It turned out to be perfect for this. Not every word is in the dictionary, including simple words like a, names, games, and glows, and the contractions won't (wont isn't in it either) and you'll, but I took advantage of the fact that there are no spaces in the output for this challenge, and cheated:

• Blitzenblitz en
• had aHa DA
• glows allglow sall
• names theyNam EST hey
• games thengamest hen
• won't youwon Ty ou
• him as theyHima ST hey
• you'llyou LL

It was a spookily perfect fit for this challenge, even containing all of the proper nouns other than Blitzen. Another cheat was to use compound words to shrink the size of the array of word choices: outwith and godown. As result of all this, the word choice array had 116 elements in it, and with none exceeding 63, the whole thing could be packed into 87 bytes. (This, despite the compromise of encoding then as th en so as not to exceed the value of 63.) Contrast this with the array of Morse codeword boundaries, which takes 119 bytes (118.5 rounded up).

But that leads to the next problem: Although the data size is considerably smaller, the code complexity is ballooned in comparison. I didn't know any golfing languages, and most of them have very limited documentation that's quite hard to use to learn from scratch.

So I worked on refining the algorithm. The next optimization was to iterate through letters from longest Morse codeword length to shortest, still in C++. This actually decreased the maximum index value to 59, meaning that with arithmetic rather than bitwise packing it could use base 60 to fit in 86 bytes. (For illustrative purposes I also ported this one to Java, which was interesting... I learned a little more Java, and was surprised to see it run even faster than the C++ version, using >125% of a CPU core, even though the algorithm is inherently single-threaded. My best guess is that the hash function is multithreaded even for individual look-ups.) This data set would respond better to Huffman encoding than the previous one, though not enough to even break even.

I tried optimizing the C++ code for smaller compiled object code, evaluating if it was worthwhile to attempt hand-coding it in x86-32 assembly. It stubbornly remained way too large; the best I could do was to squeeze it in at just under 256 bytes, not including the data. So it wasn't worth hand-coding in asm (the letter-boundary version beats it by a huge margin).

So it seemed that the only way this algorithm would have justice done to it would be for me to learn a golfing language. Quite daunting, given that I've never used anything like these languages.

And then Adám offered to teach me APL. I jumped at the chance; while APL doesn't usually win challenges where there's also a Jelly or 05AB1E contender, it tends to come pretty close, has a deep and rich past, and formed the basis of or influenced many newer languages. Heck, I knew of it as a child, and was a bit curious about it even then, but never took a crack at learning it until now.

Many thanks to Adám for extensive help in teaching me various aspects of Dyalog APL and golfing down this program – my first APL program.

I initially tried porting the algorithm as it stood to Dyalog APL. It worked, but was very slow, even when compiled; in 60 seconds it only gets up to donner or so. Adám conferred with Marshall at Dyalog, and there wasn't really a way to speed it up any further. But it was suggested that encoding the entire dictionary in Morse code could result in a speedup. And I realized that this strategy could make for much better golf, too.

So the next stage in adapting the algorithm was to translate the entire dictionary to Morse code, and at each point in the encoded song, iterate through possible words in reverse order of their length in Morse dots+dashes (with the longest being 24). Not only is this approach far, far faster in APL (and probably many other languages), and far more concise, but even the data is more lightweight – far more of the "word choice" array elements are 0 or 1, the largest value is just 50, and there are only 115 elements (the then no longer needed or benefited from breaking up), meaning that in languages with arbitrary-precision base conversion, it could be packed in base 51 and take up only 82 bytes. In APL though, the overhead of implementing arbitrary-precision base conversion would override the benefit, and I stuck with packing groups of 7 elements, in base 51, into groups of 5 bytes in base 246 (as log246 517 ≈ 4.999295), taking up 85 bytes. This data set responds even better to Huffman encoding than the previous, but still wouldn't break even: 4 1 2 21 1 13 0 23 0 3 26 1 23 0 26 0 27 15 8 6 0 34 10 0 1 1 7 0 43 23 0 4 37 50 1 0 3 23(24🐌) 22 6 15 6 16 3 2 17 10 12 5 0 9 31 1 3 9 21 0 32 16 9 20 32 8 12 31 5 0 4 27 14 1 7 13 16 0 0(1🐌) 27 4 4 22 10 0 16 5 7 15 3 12 18 4 2 13 1 0 50 4 49 2 1 4 38 20 0 0 19 0 43 23 0 1 6 12 0 38 0

So as it turns out, in APL it still doesn't golf well enough to beat the existing letter-boundary solutions, even if the overhead for unpacking the "word choice" array (24 bytes) and for using Dyalog Unicode instead of Extended (7 bytes) are subtracted (yielding 144 (141🐌) bytes code+data). I still think that it might be possible to make it shorter than 129 bytes in one of the languages more specialized towards golfing, and will likely try that eventually.

Of course, with bigger source material than the song this challenge uses, this dictionary-based approach would win hands-down. Some interesting extensions to it would be: Look 2 or more words ahead, and perhaps use an N-gram frequency table; Look all the way ahead, using a model of most-likely N-grams (probably would be incredibly slow).

## Explanation of the code

Dyalog Unicode is used, even though Dyalog Extended could save 7 bytes (4+3, as described below), because the former allows compiling for speed, whereas the latter is very slow, to the point that it would be impractical for demonstration.

On my system, this version takes about 45 (or 901🐌) seconds to finish (the first 7 seconds of this are taken converting the dictionary into Morse code). On TIO it doesn't quite finish within 60 seconds.

⎕IO←0 - set Index Origin to 0 (for 0-based array indexing)

⎕AVU[62 63 60 93 11 94]←9016 9060 9056 8838 9018 9080 - modify the default Atomic Vector to match the actual Single-Byte Character Set we're using (£¢¥ýɫ· overwritten with ⌸⍤⍠⊆⌺⍸, at each character's respective index within the Atomic Vector)

'morse'⎕CY'dfns' - import the Dyalog APL Morse code dfn – I decided to keep this in the header because Dyalog Extended has it by default

D←1(819⌶)'^\w+ = ''{3}|''{3}\.split$'⎕R''⊃⎕NGET'/usr/local/lib/python3.7/site-packages/jelly/dictionary.py'1  Load Jelly's dictionary, and convert it to lowercase: ⊃⎕NGET'/usr/local/lib/python3.7/site-packages/jelly/dictionary.py'1 - read the file as a set of newline-delimited lines into an array (with empty lines dropped, of which there is one) '^\w+ = ''{3}|''{3}\.split$'⎕R'' - using a regex (PCRE) Replace, remove the Python code that surrounds the dictionary's two word lists (short and long), resulting in a merged list that keeps everything from short before everything from long (but is otherwise in case-insensitive alphabetical order)

1(819⌶) - convert to uppercase, so that the morse dfn will work on it (since it only takes/gives uppercase input/output)

D← - assign to the variable D

∇D R i;C;M;w

Define the tradfn R, taking left argument D (dictionary word list) and right argument i (the input, i.e. the song in undelimited Morse code), and having local variables C (word choice array), M (dictionary translated to Morse code), and w (array listing the indices into the dictionary of what the current word could be). The arguments are passed and the local variables are declared to allow the R to be compiled properly (see footer).

### Code

M←∊∘morse¨D⋄C←∊(7⍴51)⊤246⊥5 17⍴¯7+⎕AV⍳'k%aÏ⍵FþfÅ⍵ìÆ⌶á≥å3¶cÒ⍺\ujü─⍳%S⊣ì⍙ÒÛÙ3ÙpØ,hÇñ⊂┴Ö⍪l∪⍒i1⍵Í:-îà⌽ì≥3€ã(⍝S]ÁGXræ∇O7Uæî'

∊∘morse¨D - compose the two functions ∊ (Enlist - flatten / join) and morse, and apply the composed function to the dictionary D. Without the ∊ composed in, morse returns an array of Morse codewords when given an alphabetical string as input, but we need the Morse-encoded dictionary to leave out inter-letter gaps, thus the ∊ flattening.

M← - assign the result to M, the Morse-encoded dictionary.

⋄ - statement separator

'k%aÏ⍵FþfÅ⍵ìÆ⌶á≥å3¶cÒ⍺\ujü─⍳%S⊣ì⍙ÒÛÙ3ÙpØ,hÇñ⊂┴Ö⍪l∪⍒i1⍵Í:-îà⌽ì≥3€ã(⍝S]ÁGXræ∇O7Uæî' - word choice array, packed into a string using Dyalog APL's updated SBCS. For this to work, the encoding must not contain newlines, i.e. ⎕UCS 10, 12, or 13 (⎕AV[2 3 5]), and any apostrophes must be doubled (but there are none).

⎕AV⍳ - map characters to SBCS indices (in the range 0-255) using the modified Atomic Vector.

¯7+ - add −7 to all SBCS indices. The corresponding addition of 7 was done during the encoding, to avoid occurrences of any of the three types of newlines. Due to use of base 246, this addend is quite flexible, and could range from 6 to 10 and be guaranteed to stay within range regardless of the data; thus it can be adjusted to minimize the number of apostrophes (which would each cost 1 byte, as they need to be doubled in a quoted string). As it happened, it was possible to have zero apostrophes.

5 17⍴ - arrange into a matrix for base conversion; each of the 17 columns will be converted as a unit. (In Dyalog Extended, this could be done as 5 ¯1⍴.)

246⊥ - base-convert the 5 values in each column that range 0-245 (base 246) into a single number ranging 0-900897818975, the top row being most significant, yielding a flat array. (But due to the nature of the underlying data, it will actually range 0-897410677850.)

(7⍴51)⊤ - base-convert each array element back into a column, with 7 rows, each number in the range 0-50 (base 51). (In Dyalog Extended, this could be done as 51⊤. The number of rows would be autodetected, so if by a coincidence all values were less than 516, this shorthand syntax wouldn't work properly. In this case though, in would work, and would save 4 bytes.)

∊ - flatten the matrix into an array, row by row.

C← - assign to the variable C, the word choice array.

C↓⍨←≢i↓⍨←≢M⊃⍨w←(⊃C)⌷∊(⍸M⍷⍨⊂)¨⌽,\24↑i

This is Line 2 (as referred to by the :GoTo at the end of the loop):

i - take the current value of the input (with the parts of it that have already been processed deleted)

\24↑ - truncate to 24 characters (dots+dashes). That is the length of the longest Morse encodings (rudolph and christmas). This step is omitted in the 🐌 version, which results in almost identical operation, but far slower; the word choice array only needs to be modified in two places (increasing the choice value by 1 at the and in andifyoueversawit and at christmas), meaning that at all other words, no matches for >24 dots+dashes are found in the dictionary.

,\ - make a list of Morse subsequences starting at the beginning of this, ranging from 1 dot/dash long to 24 dots/dashes long (or maximum length, in the 🐌 version), from shortest to longest (e.g., at the very beginning, would be '-' '-.' '-.-' '-.--' '-.---' '-.----' '-.-----' '-.-----.'...'-.-----..--.--.---.---..')

⌽ - reverse that list, so that it goes from longest to shortest (this way of encoding results in smaller element values for the word choice array on average)

(⍸M⍷⍨⊂)¨ - to each item in this list, apply the function ⍸M⍷⍨⊂: ⊂=enclose one level of nesting deeper, to match the nesting of the Morse-encoded dictionary; M⍷⍨=return an array the same size as the dictionary, where values of 0 mean "not found" and 1 means "found", ⍸=convert the list of 0s and 1s into a list of the indices of the 1s. The result is a matrix with 24 rows (ranging from longest to shortest Morse, top to bottom), each of which contains a variable number of columns (minimum zero), listing the indices of all the words in the dictionary that match the Morse sequence from the input of the corresponding length (in alphabetical order, but with Jelly's short dictionary entries preceding its long ones).

∊ - flatten this. The end result is a list of the indices of all the words in the dictionary that match any item in the list of Morse sequences from the input that range from 24 to 1 dots+dashes long, retaining the sorting of longest to shortest (and within each length, entries from Jelly's short come before those from its long, and within that, they're alphabetically ordered).

(⊃C)⌷ - from the resulting list, take the element at the index of the current word choice (⊃=first element of) from the word choice array C. Equivalent to wrapping everything to the right in ( ) and putting [⊃C] to the right of it, but saves 2 bytes.

w← - assign this (the index into the dictionary of the correct current word in the song) to the variable w, returning it as a result

M⊃⍨ - return the wth element of M (the Morse code of the current word), unwrapped. Equivalent ⊃M followed by wrapping everything to the right in [ ], but saves 1 byte.

≢ - return the length of the Morse code of this word (in characters, i.e. dots+dashes). If it had not been unwrapped by ⊃, the result would always be 1.

i↓⍨← - delete that many characters (the length of the word in Morse code) from the beginning of the input i, so that on the next iteration of the loop, the next word will be handled, and return the number of characters deleted as the result

≢ - return the length of the number of characters; since that is a scalar, it will always be 1

C↓⍨← - delete that many (1) characters from the beginning of C, the word choice array, so that on the next iteration of the loop, the next word choice will be ready. This saves 1 byte relative to what a separate statement (C↓⍨←1) would take.

⍞←819⌶w⊃D

w⊃D - Take the wth element of D (the current alphabetical word) and unwrap it, so that when printed, there are no spaces to its left or right. Equivalent to ⊃D[w].

819⌶ - Convert to lowercase. Equivalent to 0(819⌶). (In Dyalog Extended, this could be done as ⌊, saving 3 bytes.)

⍞← - Print the result without a newline. In TIO, this prints to stderr.

→2

:GoTo Line 2 (the beginning of the loop), unconditionally. A line number is used to save the 2 bytes that defining a label (e.g. L:) would cost. The lack of a looping condition results in the program ending with * Command Execution Failed: INDEX ERROR when it tries to access the first element of an empty array (after it has successfully printed the entire song).

If running this program locally, note that the error prevents ]runtime from working. To work around this, the program may be called with :Trap 3...:Else ⋄ :EndTrap wrapping it.

The clean version, avoiding this error, would be →2⊣¨i, meaning :GoTo Line 2 while i is not empty. This would work because 2⊣¨i returns an array of 2s matching the length of i, and the :GoTo goes to the line number of the first value in the array, if one exists.

### Footer

∇ - end the tradfn R

2(400⌶)'R' 'morse' - compile the user tradfn R and the built-in dfn morse. Without this, the program would run far slower.

⍎'D R⍞⋄⍬' - Call tradfn R with dictionary D as its left argument and the input (⍞) as its right argument. This passing of arguments is done only for speed, so that the compile can work properly (it doesn't like global variables, or directly using input). The ⍎ and ⍬ constitute a workaround Adám wrote for me for the way the APLs work currently on TIO. They expect code in the input, but I wanted a clean separation between code and input.

# Jelly, 138 135 bytes

ḲiⱮ“Q®ḃƁ⁼ṇÑ1¿Ọɠ\ƥȥ⁼ṙ⁴EŀƥŒEæʋØ>þ>⁴þʋ[⁾Ƒ]eÞḍ8ß®ⱮȮø⁹ç÷R?g®=,¥ėµ@ØU~"/Xçq®ÆƬ°ɠsṭṭ?dC#Ċ?gÑ¶PÇH5p@ʂEœ⁹½G6ḌƘṪµɦ8€(S¦Ḥ⁸ṫ"ḟḢlṾ¦ƤḃƭẊ@’ḃ4$ÄṬk⁹¤ịØa  Try it online! A dyadic link taking the library as the left argument and the Morse code input as the right argument. Returns a Jelly string of the lyrics. The long integer that takes the majority of the code has the lengths of each Morse code character encoded within it. ## Explanation Ḳ | Split at spaces iⱮ ¤ | Find index of these in each of the following: “Q...@’ | - Base-250-encoded integer 742925387377430937422864458121941352705403867269973650879937105837755604647313120541399315429452997316260711263757137193164236124383957174543961671910365268304120327243209050996915401898167278257845227193061059012165352924148307417330452740236835399667569278751322913192633409885614815 ḃ4$          | - Bijevtive base 4
Ä         | - Cumulative sum
Ṭ        | - Convert to logical list with 1s at the appropriate indices
k⁹      | - Split right argument at those positions
ịØa  | Finally, index into lowercase letters

## Python, 487 bytes

lambda a,b:'youknowdasheranddancerandprancerandvixencometandcupidanddonnerandblitzenbutdoyourecallthemostfamousreindeerofallrudolphtherednosedreindeerhadaveryshinynoseandifyoueversawityouwouldevensayitglowsalloftheotherreindeerusedtolaughandcallhimnamestheyneverletpoorrudolphjoininanyreindeergamesthenonefoggychristmasevesantacametosayrudolphwithyournosesobrightwontyouguidemysleightonightthenhowthereindeerlovedhimastheyshoutedoutwithgleerudolphtherednosedreindeeryoullgodowninhistory'

Takes morse code and any of the three libraries as input, returns the text.

• Heh; I wonder if any language could save anything by packing the string from 8-bit characters down to 5 or 6-bit characters (all lower case letters so 32 code points is sufficient). That would leave ~180 bytes for decompression code with bit-shifts (back to ASCII / UTF-8) for this to break even. Maybe good for assembly language / machine code. I'm assuming we can't justify using a 5 or 6-bit character set for the actual output without also counting the size in 5-bit bytes. Dec 29 '19 at 3:14
• I saw what you did there :-) Dec 29 '19 at 4:11
• @PeterCordes I had a similar idea and took a crack at it. Feel free to suggest improvements!
– Seb
Jan 6 '20 at 0:27

# 05AB1E, 149131 129 bytes

•Nα0Ω¤èGë™jƒć›
Ù¾₂¶É¨=Yàf§ì[ðEÎλ÷¡2Ä|~āΔí¹–4₂≠āó3Tv₁‰[Öò‚S»‰CþEηFA‡γ÷¯¿Þ₃âÖ.³εûV^ÕÜ₄Ú¹þ‘ΘVÅÍÅΘΛ9m|\Ó8g8ì&ÓiUΩÎQ:ÇºZÎgöæ•4в>£I#A‡

-2 bytes thanks to @Grimmy.

Uses the complete morse-string as first input, and the lookup format as second input.

Try it online. (Outputs as a list of characters, so the J in the footer is to join it together to a single string to pretty-print.)

Explanation:

•Nα0...göæ• # Push compressed integer 2178625864988239449532491166807818445418276694861550892023336765049187401437036816274840827319861935617150192366925629812414499033245212320687403711053517272798896860734190937884895522347710320033920004354990136205425279052925026955638024859428057287730519725429748232597858786841294379
4в       # Converted to base-4 as list: [3,2,2,2,1,2,2,2,1,2,3,0,2,1,1,2,2,1,1,3,0,2,1,1,2,3,2,1,1,3,0,2,1,1,2,3,1,3,0,1,3,2,1,0,0,1,1,2,3,2,3,1,2,1,1,2,2,2,1,1,0,2,1,1,2,3,3,1,0,3,0,1,3,2,0,2,2,3,2,2,2,0,3,1,3,3,0,3,0,1,2,2,0,3,1,1,2,2,2,2,0,1,1,2,0,0,2,2,3,1,3,3,2,2,2,2,3,3,3,0,3,0,2,0,2,1,2,2,0,2,2,0,1,1,2,0,0,2,3,1,2,1,3,0,2,3,2,3,1,1,3,1,2,2,0,1,1,2,1,3,3,2,2,0,3,0,2,2,1,2,1,0,3,2,2,2,2,2,3,2,0,3,0,1,2,1,3,1,0,2,3,2,2,2,1,3,3,2,3,0,3,0,2,0,3,0,2,2,0,1,1,2,0,0,2,2,2,0,2,0,2,3,1,2,2,3,1,1,2,3,1,3,3,3,1,1,1,1,1,0,2,0,3,0,3,1,0,3,0,2,3,0,0,3,2,2,2,2,2,2,2,3,3,3,3,2,1,1,1,1,1,1,3,2,0,1,1,2,0,0,2,2,1,1,0,2,0,3,0,1,2,1,0,3,2,2,2,3,3,3,2,1,2,0,1,1,2,0,3,0,2,1,1,0,1,3,1,1,0,0,2,2,1,3,2,2,2,2,3,3,3,2,1,0,3,3,2,2,2,1,2,2,0,2,2,3,2,1,2,3,0,2,2,1,0,3,2,2,2,2,1,2,0,1,3,2,3,0,1,2,3,0,2,1,1,2,3,0,0,3,0,1,3,2,2,0,3,0,2,0,1,1,2,0,0,2,3,2,3,0,2,3,1,1,1,2,0,3,0,3,2,3,2,2,0,0,2,2,2,0,2,1,0,3,2,3,0,0,2,2,2,2,3,3,3,0,3,0,2,0,2,1,2,2,0,2,2,0,1,1,2,0,0,2,3,2,2,3,3,2,2,2,2,2,1,1,1,3,1,2,0,2,2,3]
>      # Increase each value by 1
£     # Split the first (implicit) input-string into parts of that size
I#   # Push the second input-string spit by spaces
A  # Push the lowercase alphabet: "abcdefghijklmnopqrstuvwxyz"
‡ # Transliterate all morse-strings in the list by the characters in the alphabet
# (after which the resulting character-list is output implicitly)

See this 05AB1E tip of mine (sections How to compress large integers? and How to compress integer lists?) to understand how the compression works.

Also, since I was curious what the program length would be if we wouldn't take any input and just use the 05AB1E dictionary to output the string, I created a program for that as well, which is 266 bytes:

’4ƒ€Þßer0–›r0prancer0vixen†„t0ï›id0¥Úner0bÙîØˆ€³€·4¾Î3‚¢£–2€‚€Ÿ13†¾5d2‚†a‚Òshiny5€ƒ€¬4ˆë–æ€•4€ÞƒÎ…è€•é»s€Ÿ€‚3€¶2‚›€„ÇÇ0„Ò„šŒî€»†™†³—‹1…¯€†€Æ2ƒ‚‚½€µÚƒgyŒÎ»ˆš´‹é€„…è1€Ž€ž5€Ê®Á¢²t4„²€¯slŸ¯o†æ‚½€ß32®œ„š€œ€»sh€Äed€Ä€Žgï³13†¾5d24ll‚œ„‹€†„ª’5Ý’€ƒ rudolph reinÆÓ €€ €î ÄÃ’#:

Try it online.

Explanation:

’4ƒ€Þßer0–›r0prancer0vixen†„t0ï›id0¥Úner0bÙîØˆ€³€·4¾Î3‚¢£–2€‚€Ÿ13†¾5d2‚†a‚Òshiny5€ƒ€¬4ˆë–æ€•4€ÞƒÎ…è€•é»s€Ÿ€‚3€¶2‚›€„ÇÇ0„Ò„šŒî€»†™†³—‹1…¯€†€Æ2ƒ‚‚½€µÚƒgyŒÎ»ˆš´‹é€„…è1€Ž€ž5€Ê®Á¢²t4„²€¯slŸ¯o†æ‚½€ß32®œ„š€œ€»sh€Äed€Ä€Žgï³13†¾5d24ll‚œ„‹€†„ª’
5Ý   # Push a list in the range [0,5]: [0,1,2,3,4,5]
’€ƒ rudolph reinÆÓ €€ €î ÄÃ’
# Push dictionary string "and rudolph reindeer the you nose"
#   # Split it on spaces: ["and","rudolph","reindeer","the","you","nose"]
:  # Replace all [0,1,2,3,4,5] with ["and","rudolph","reindeer","the","you","nose"] in the string
# (after which the result is output implicitly)

See the same 05AB1E tip as linked above (but section How to use the dictionary? this time), to understand how the dictionary strings work.

• Why not store the list in base 4 instead of base 5, and add 1 to every element after unpacking it? Surely that wouldn't add 19 bytes to the code, as is wasted by the data by using base 5? Jan 4 '20 at 0:10
• @Deadcode Thanks, that indeed saves quite a few bytes. Jan 4 '20 at 12:53
• Awesome that it only took one byte to do the incrementation by 1! I honestly didn't know, but hoped it would be one byte. Jan 4 '20 at 19:02
• I think you need to add a ,3 to the end of your list. history is being truncated to histor. Jan 4 '20 at 20:32
• k followed by è is just ‡. 129 with •constant•4в>£I#A‡ and swapped inputs (TIO link too long for a comment). Jan 17 '20 at 17:12

# MATLAB R2016a, 290285277266245223 219 bytes (99+119+1)

function r(m,d);[a,b]=ismember(mat2cell(m,1,fread(fopen('j'),474,'bit2')+3),strsplit(d));char(b+96)

The inputs are the Morse code sequence m and the dictionary d in the third format. The function uses a 119-byte file j available here that contains the lengths of the 474 Morse codewords. According to the rules of scoring multiple files, this adds an additional byte to the score.

# Perl 5, 283 244 bytes

$s=<>;$s=~s/..{$_}//+print$s=~/(.) \Q$& / for map{vec unpack('u',q{MJZDYEM98;HWE31N4>Y9:6'Y,BZYRSZ1<JI2@]ZH_(Z8H)7@V[G5*V2NC&:NZM3':XVCLCHY2@(IY>WE\5,L<XK*K^6U5+"5K(9*S^)B5CT07:JK_Q:HINCL:J=23LYEL.T,E*".U[)[HJQ@ZJ/R.F*"6XOJK5B0X}),$_,2}0..473

Try it online!

This corresponds to:

$L = <<''; # length bits in base64 MJZDYEM98;HWE31N4>Y9:6'Y,BZYRSZ1<JI2@]ZH_(Z8H)7@V[G5*V2NC&:NZM3':XVCLCHY2@(IY>WE\5,L<XK*K^6U5+"5K(9*S^)B5CT07:JK_Q:HINCL:J=23LYEL.T,E*".U[)[HJQ@ZJ/R.F*"6XOJK5B0X$s = <>;                              # read inputs
$s =~ s/..{$_}//                      # take current length morse code from start
+ print $s=~/(.) \Q$& /             # ...and print corresponding letter
for map vec(unpack('u',$L),$_, 2), # find morse code lengths of the letters
0..473                          # 474 letters

This could perhaps be further shortened by encoding in base128 or directly in "base256". Huffman encoding the lengths could shorten the length data, but most probably enlarge the rest of the code by too much.

# Charcoal, 145 141 bytes

≔⪪⮌θ¹θＦ”)“1§μX↶)⟧¶»-↘3ω◧i⌊⊞⁸Ｑ9m;T›|ＬDμ…›Ｏ⦄hTYＩO5x÷↶×‹,⟲"yＭLUＣgq.ＢNＥ2⁴⎇c⬤χＮ±⸿↙＆7⟧χ⁰‹Ｙs´ΣC⁼{9ω�Pi＆◧êKσＰDfY9wi⟲f[Φτ³Ｊ‹‴V[^ＷＲEαF[-T^ς”§β⌕⪪η ⭆⊕ι⊟θ

Try it online! Link is to verbose version of code. Edit: Saved 3 4 bytes by using a less inconvenient library format. (Thanks to @Deadcode for pointing out that I'd pasted in the wrong version.) Explanation:

≔⪪⮌θ¹θ

Reverse the sequence and split it into individual characters.

Ｆ...

Loop over the characters of a compressed string which are the digits 0..3 (which compress better than 1..4 for some reason).

§β⌕⪪η ⭆⊕ι⊟θ

For each digit, pop one more than that many characters from the sequence, concatenate them, look them up in the library split in spaces and output the desired character (using the predefined lowercase alphabet).

137 bytes with an even more convenient library format:

≔⪪⮌θ¹θＦ”)“1§μX↶)⟧¶»-↘3ω◧i⌊⊞⁸Ｑ9m;T›|ＬDμ…›Ｏ⦄hTYＩO5x÷↶×‹,⟲"yＭLUＣgq.ＢNＥ2⁴⎇c⬤χＮ±⸿↙＆7⟧χ⁰‹Ｙs´ΣC⁼{9ω�Pi＆◧êKσＰDfY9wi⟲f[Φτ³Ｊ‹‴V[^ＷＲEαF[-T^ς”§η⭆⊕ι⊟θ

Try it online! Link is to verbose version of code. Explanation:

≔⪪⮌θ¹θ

Reverse the sequence and split it into individual characters.

Ｆ...

Loop over the characters of a compressed string which are the digits 0..3 (which compress better than 1..4 for some reason).

§η⭆⊕ι⊟θ

For each digit, pop one more than that many characters from the sequence, concatenate them, look them up in the library and output the desired character.

• Shame. I at least managed to golf a byte off the code to read the inconvenient output...
– Neil
Dec 26 '19 at 11:37
• It appears the question has been relaxed to allow some other library formats. How much does that help you? Dec 26 '19 at 16:21
• @A.Rex I originally thought it would only save me a byte but I managed to golf a couple of further bytes off.
– Neil
Dec 26 '19 at 18:40
• There's a typo in your current 142 byte version. When fixed, it's actually 141 bytes: Try it online! Jan 1 '20 at 7:56
• @Deadcode Bah, I remember fixing that, I don't know how I managed to paste in the wrong version...
– Neil
Jan 1 '20 at 16:47

# JavaScript (Node.js),  270  269 bytes

Takes input as (string)(lookup), where lookup is in the 3rd format.

s=>t=>(B=Buffer)("SNB6>B5>V]@a5U)McAQ>@a/;3bRD7;2?R:1P_Sb7K@22MHO5V?O:AWZPATRV4A/VBW[0K:1PJQ?Fg=-ZD46TRRgC=]:1P-ZLYRgN<Z@9?H^RfCdRQPC6BTR1U;6>64UZ0MHc=ZTSH2.cHRg4JQP<*VfRB]1b").map(n=>[0,2,4].map(i=>o+=B([97+t.split .indexOf(s.slice(p++,p+=n-40>>i&3))])),o=p='')&&o

Try it online!

### How?

For each character in the data string, we take the ASCII code minus $$\40\$$ to get a 6-bit value holding the lengths of the next 3 morse codes.

Example:

"S" --> ASCII code 83 --> 43 --> 101011 --> 10 10 11
|  |  |
|  |  +--> 3+1 = 4 -> -.-- (y)
|  +-----> 2+1 = 3 -> ---  (o)
+--------> 2+1 = 3 -> ..-  (u)

# Python 3, 265261 259 bytes

Uses the same base-256-in-a-string data-encoding method as my other Python answer, but actually uses the Morse code input. Like many of the other answers, encodes the lengths of the 474 Morse codewords into 119 bytes using base 4. The Morse stage of the decoding is based on steviestickman's answer, with some further golfing.

Takes the Morse library and representation as two lines from stdin and outputs to stdout:

#coding=L1

(contains C1 control characters, forbidden by HTML5, thus the above can't be copied to clipboard and is for illustration purposes only)
Try it online! (can't use the actual coding header, since TIO only accepts UTF-8)
Try it on repl.it (demonstrates the actual 259 byte source code file)

-4 bytes by using the alias 437 for cp437
-2 bytes by using L1 instead of 437

Here's a Python program (TIO) to generate the full program with choice of string encoding.

# Pyth, 142 bytesSBCS

Like many of the other answers, and my Python answer, encodes the lengths of the 474 Morse codewords into 119 bytes using base 4. Shares many similarities with my Pyth + Jelly's dictionary answer.

My primary reason for posting this answer is to show that in Pyth, apparently the 474-codeword-lengths method does not beat the 115-Jelly-dictionary-word-indices method!

Takes the Morse representation and library as two lines from stdin and outputs to stdout:

Kcwdsm@GxK<~>zddhMjC"¦¦Éir[%·AnÙjR[Ó+¨ß1£Z¡ú¯Ì¢ÙËµÚ~¦NªãÒê~Ì¡¨k[UHÍ2Ãª«þU^
R1«ùu
z¯äú+):¦ÆÉl1èÈX.ËV3º
;
¯Ì¢ëê¥v+"4

(contains C1 control characters, forbidden by HTML5, thus the above can't be copied to clipboard and is for illustration purposes only)
Try it online!

## Explanation of the code

Kcwd

The Morse code version of the song has already been read from input implicitly, as z = input().

Read the Morse code look-up table from input. Equivalent to K = input().split(' ').

hMjC"¦¦Éir[%·AnÙjR[Ó+¨ß1£Z¡ú¯Ì¢ÙËµÚ~¦NªãÒê~Ì¡¨k[UHÍ2Ãª«þU^
R1«ùu
z¯äú+):¦ÆÉl1èÈX.ËV3º
;
¯Ì¢ëê¥v+"4

Unpack the array that stores the Morse code width (in dots+dashes) of each letter of the song (474 elements), packed in base 4 (with 1 subtracted from each element) in an 119 byte base 256 encoded string. Luckily there happened to be no characters that needed escaping.

C"..." - convert the base 256 encoded string into an arbitrary-precision integer
j...4 - convert the base 4 integer into a list of integers
hM - add 1 to all elements

sm@GxK<~>zdd

m - map each element d of the list decoded above through the following lambda:

~>zd - z = z[d:] - remove the first d dots+dashes from the input (z), and return the previous value of z (let's call it ʐ)

@GxK<ʐd - string.ascii_lowercase[K.index(ʐ[:d])] - alphabetical letter decoded from the first d dots+dashes from the input

s - join the resulting list of characters into a string

# Pyth + Jelly's dictionary, 135134131130 129 (126🐌) bytesSBCS

The algorithm and data in this answer were originally implemented in this APL answer, and their explanation is there. But as implemented there, it failed in its entire purpose, which was to beat the previously lowest-scoring submission to this challenge, Kevin Cruijssen's 129 byte 05AB1E answer. Here, it finally succeeds in its very purpose for existing, and just barely manages to beat that answer's length. I learned Pyth to do this; it was a promising choice with very good documentation. It's unclear if any of the other golfing languages would be able to implement an imperative algorithm like this in fewer bytes.

With a longer Morse code message this algorithm would win by a significantly larger margin.

Kcwd=bmsm@KxGkdTVjC"êêVÞøA?cUqg´§¼F¦e~zEºÊú[!Áw¶uQå´çý½Ê*¤jrkIæwÐó*S.(4áëÌöÅ×¹ñp.ÑQÐgBê "51=>zl@bJ@sxRb_._<z24Np@TJ

(contains C1 control characters, forbidden by HTML5, thus the above can't be copied to clipboard and is for illustration purposes only)
Try it online! - 129 byte version, running at decent speed

Kcwd=bmsm@KxGkdTVjC"êêVÞøA?cUqg´§¼F¦e~zEºÊúvMÇìý÷¼]¾I/||ÊÁê,Ømø×i]Z8©b¤0åé'½bIý>ä
lGùUK½"51=>zl@bJ@sxRb_._zNp@TJ

(contains C1 control characters, forbidden by HTML5, thus the above can't be copied to clipboard and is for illustration purposes only)
Try it online! - 126 byte 🐌 version, taking about 20 times as long to finish (especially slow at beginning)

## Explanation of the code

 $exec('  Anything in $...$ is evaled as Python code. Open an exec block here (since statements can't be executed in eval). The leading space suppresses imp_print. def Pprint(a): print(a, end="", flush=True); return a  On my system, this program takes 46.4 (or 921🐌) seconds to finish, but on TIO, it is on the very edge between not finishing in 60 seconds or just barely finishing. If it didn't manage to finish, no output would be shown. If it was manually interrupted before finishing, the incomplete output would be shown – so it appears TIO sends a SIGINT (Ctrl+C) to the process for this, but something more powerful (perhaps even SIGKILL) when reaching the 60 second limit. By default, Python only flushes its standard output on newlines. The -u command line argument forces stdout (and stderr) to be unbuffered, but TIO does not provide a way to send arguments to the host Python process that spawns Pyth. This header line redefines Pyth's Pprint() macro to flush its output, so that if the program does not finish within 60 seconds, the incomplete output will still be shown. It's the next best thing to -u. Funnily enough, forcing each individual print to flush seems to actually make it run faster on TIO; it was able to finish in under 58 seconds with this, whereas in my tests on TIO the 134 byte version never finished without this. _imp_print = imp_print; def imp_print(a): globals()["imp_print"] = globals()["_imp_print "]; return a  Work around the newline inserted by TIO between the Header and Code sections, which would trigger an imp_print() on the first expression otherwise. Suppress only the very first imp_print that happens next, and then allow all subsequent ones. ')$

End the exec block.

=TrL0$exec('from jelly import dictionary') or dictionary.short + dictionary.long$

Import Jelly's dictionary and assign the concatenation of its short and long dictionaries, changed to all-lowercase, to the Pyth variable T. Equivalent to:

from jelly import dictionary
T = list(map(lambda arg:arg.lower(), dictionary.short + dictionary.long))

### Code

Kcwd

The Morse code version of the song has already been read from input implicitly, as z = input().

Read the Morse code look-up table from input. Equivalent to K = input().split(' ').

=bmsm@KxGkdT

Translate Jelly's dictionary into Morse code, with the inter-letter gaps deleted. Equivalent to:
b = list(map(lambda d:''.join(map(lambda k:K[string.ascii_lowercase.index(k)], d)), T))

(The outer lambda uses d as its argument, whereas the inner lambda automatically advances to using k as its argument.)

jC"êêVÞøA?cUqg´§¼F¦e~zEºÊú[!Áw¶uQå´çý½Ê*¤jrkIæwÐó*S.(4áëÌöÅ×¹ñp.ÑQÐgBê "51
jC"êêVÞøA?cUqg´§¼F¦e~zEºÊúvMÇìý÷¼]¾I/||ÊÁê,Ømø×i]Z8©b¤0åé'½bIý>ä␊lGùUK½"51 🐌
(contains C1 control characters, forbidden by HTML5, thus the above can't be copied to clipboard and is for illustration purposes only)
Unpack the word choice array (115 elements), packed in base 51 in an 82 byte base 256 encoded string. Luckily there happened to be no characters that needed escaping.

C"..." - convert the base 256 encoded string into an arbitrary-precision integer
j...51 - convert the base 51 integer into a list of integers

V...=>zl@bJ@sxRb_._<z24Np@TJ
V...=>zl@bJ@sxRb_._zNp@TJ 🐌

Main loop.

V... - for N in ...: - for each element N of the list decoded above, execute all of the following statements:

_._<z24 - reverse(list(map(lambda arg1:z[:arg1], range(1, 24+1)))) - make a list of Morse subsequences starting at the beginning of input (z), ranging from 24 to 0 dots/dashes long (from longest to shortest)
_._z 🐌 - reverse(list(map(lambda arg1:z[:arg1], range(1, len(z))))) - make a list of Morse subsequences starting at the beginning of input (z), ranging from maximum length to 0 dots/dashes long (from longest to shortest)

J@sxRb...N - J = sum(map(lambda arg2:index(arg2,b), ...), [])[N], where index(arg2,b) finds all occurrences of arg2 in b - enumerate all words that match the Morse code at the current position in the input, up to 24 dots+dashes, and store this list of dictionary indices (which apply to both b and T) in J

=>zl@bJ - z = z[len(b[J]):] - remove the processed Morse code from the beginning of the input

p@TJ - print(T[J]) - look up this word in the dictionary and print it

# Python 3, 381375 372 bytes

Just like Seb's answer and ScoopGracie's answer, gracefully takes the Morse code representation and any of the three libraries as input, blithely ignores them and gives you the output.

Takes Seb's strategy a step further, encoding the text in base 26 in an integer encoded in base 256 in a string (as opposed to Seb's which encodes in base 32 in base 128 in a string). Both of our solutions are confined by not being able to contain the bytes NUL (0x00) or CR (0x0D), which Python interprets as end-of-file and LF (0x0A), respectively, even when found in a triple-quoted raw string literal. CR+LF is also interpreted as LF. Backslash escape codes are interpreted (unless the raw prefix r is used). Backslash followed by any kind of newline is treated as nothing, stripping both the backslash and the newline. And the string can't end in a backslash. (So it's really sort of a slightly-less-than-base-254 masquerading with the help of luck as base 256.)

To work around this problem I had to complicate the encoding a bit. Neither ASCII-97 nor 122-ASCII, nor using base 27 instead of 26 (and optionally adding 1), avoided containing these bytes or sequences, so I settled upon adding 1 to the encoded integer before each multiplication by 26, which luckily costs only 3 bytes (compare i//=26 to i=i//26-1). With significantly larger text, the luck would have to be incredible, or every NUL, CR, and \ would have to be replaced with \0, \r, and \\ respectively. On the other hand, with better luck, newlines might be absent altogether, meaning single-quoting could be used instead of double-quoting.

The #coding=L1 costs 11 bytes (without this it'd be 361 bytes), but this beats the cost of using base 128 (which would take 319 bytes for the string, whereas base 256 takes 279 bytes, and thus would cost 40 bytes instead of 11, not counting the different Python code that would be needed to decode it). An alternative coding is 437, which would cost a further 2 bytes, since the encoding name is used twice. Note that the disadvantage of using L1 instead of 437 is that ISO 8859-1 doesn't map as cleanly to UTF-8, and there may be difficulty faithfully copying and/or pasting it in some software.

This standalone program, written in the ISO 8859-1 codepage, ignores the Morse code representation and library taken as command-line parameters, and prints the output to stdout:

#coding=L1
while i:print(end=chr(i%26+97));i=i//26-1

(contains C1 control characters, forbidden by HTML5, thus the above can't be copied to clipboard and is for illustration purposes only)
Try it online! (can't use the actual coding header, since TIO only accepts UTF-8)
Try it on repl.it (demonstrates the actual 372 byte source code file)

-6 bytes by using L1 instead of cp437
-3 bytes by using i=i//26-1 instead of i=i//26^4, resulting in no newlines, allowing single-quoting

Here's a Python program (TIO) to generate the full program with choice of string encoding.

If it absolutely has to be a function and not a program, then it's 382 bytes (not counting the #coding=L1):

def R(a,b):
s='';i=int.from_bytes('…'.encode('L1'),'big')
while i:s+=chr(i%26+97);i=i//26-1
return s

Try it online!

If it has to be a lambda, 391 bytes (not counting the #coding=L1):

lambda a,b,i=int.from_bytes('…'.encode('L1'),'big'):exec("global s;s=''\nwhile i:s+=chr(i%26+97);i=i//26-1")or s - Try it online!

If it has to be a lambda that doesn't modify any globals, 395 bytes (not counting the #coding=L1):

lambda a,b,l={'i':int.from_bytes('…'.encode('L1'),'big')}:exec("s=''\nwhile i:s+=chr(i%26+97);i=i//26-1",l)or l['s'] - Try it online!

# Python 3, 452 bytes

lambda a,b:''.join([chr(96+int(''.join([f'{ord(c):07b}'for c in'''ezVswP,A8BpeH	A82dDY
po4ZqVHDw,A8AMa+!ezd(a1J+/NCkuN"Rq'LJRdQd)>2I)8BK3!2ssIY>Rl,StiKu]zX!6iCJ4Go,1s(A/Qe)8BK3J5\0\ a1DkA4YhA98[R_Uv BO%d\YHT\!%HpZ,t Wq&<sr&:eXYBuK#s*#lAS">Y|eMq$IhRw]&/TzR!-f6 IhQw:Q\CwQd*.RdcvDh3QsVBH}4];*H{"D $9yJ\$E%b
,Y>V;d>wr	N'''])[i:i+5],2))for i in range(0,2346,5)])+'tory'

Try it online!

Same morse-ignoring, hardcoding approach as ScoopGracie's answer, but with each character's 5 LSB concatenated and re-encoded in printable ASCII (i.e. 7 free bits out of each byte).

This shortens the string from 474 to 339 bytes, not counting delimiters (which need to be multiline for the encoded string) and an escape sequence in place of a NUL byte. I also cut the string off at the last clean byte boundary (to not deal with partial bytes) so I had to hardcode the final four characters.

Then there's not-insignificant overhead for the decoding process, so it's not much shorter this way. Improvement suggestions welcome!

Using the standard library instead to compress the lyrics with base64.b64encode(gzip.compress(...)) actually saves 2 bytes:

# Python 3, 450 bytes

lambda a,b:decompress(b64decode('H4sIAAaPGF4C/3WQ0XbsIAhFv5UJRG2VkyU41n79xdzJY19cBE62WxbGt2IyWZZOykx63MXVn+pdfkQPNPH4OMZVeOegek9ftfiv6Gs4Y2F0OahWz9JgflLDsC5FWaTjjEkfjHrlCHRhhQk/40xMb+nLctG1JwEvZyAlukazeNQTo3I01GgVTxXTAoozeNjMBzYC7Kg0Ut7SkcmlKTWxSC3dyCp+Af0j9IWiRUnXQ0ifsELlRErryL2YN7L42Uidjkg4QuSDCMO8N7DdDa9eUvYJ3dppFJa2rMpuQve52Rnz3sT/KyvewuFJt6RlDBeOY4NT3a/6a3dxRa0JjBmPyKGJvv4BRj4fyNoBAAA=')).decode('ascii')
from gzip import*
from base64 import*

Try it online!

{{i}}{ii}ic{d}ciiiiiic{d}ciiicic{i}ddc{dd}icdddc{ii}ddc{d}dcdddc{i}iiic{dd}iiic{i}iiic{d}ccdddc{i}iiic{d}dciic{i}iiic{dd}iiic{i}iiic{d}c{i}iiciic{dd}iiic{i}iiic{d}dciic{i}iiic{dd}iiic{i}iiic{d}c{ii}ddc{d}dddc{i}iiiiic{dd}ic{i}dc{d}dc{i}iicddc{d}iic{i}iiiiic{dd}ic{i}iiic{d}cdc{ii}ddcdddddc{d}iiicdddddcdddc{i}iiic{d}cc{i}icdcc{d}ic{i}iiic{dd}iiic{i}iiic{d}cddc{i}cdddc{i}iciiiiiic{dd}dc{i}dc{d}ddc{ii}dcdc{d}ddddddc{i}ic{i}c{d}ciiiiiicdddc{d}dddcddcddc{i}icc{i}ddc{d}ddcdddc{i}ddciiciiiicic{d}ddddcdddddc{i}iiciiciiiiiicddcdc{d}dddciiiiciiiiic{d}cicc{i}iiicdddc{d}icdddddc{i}icciiiiiiciiic{dd}iiic{i}icdddciiiic{d}iic{i}iic{d}ddcdddc{i}iiic{d}dddcdc{i}ciciiiic{d}ddddcdc{i}iiiic{d}dddciiiiciiiiic{d}cicc{i}iiic{d}c{d}iiiciiicdddc{ii}ic{dd}iiic{i}iiic{i}dddcddddddc{d}dciciiiiic{i}ic{d}dciciiiic{d}ddddcddddc{i}iiic{d}ciiiiicdddc{ii}dc{d}ciiiiiic{d}ddddddc{ii}dddc{dd}iiic{i}iiicic{dd}iic{ii}iic{d}ddddc{i}iciiiiic{d}ciiiiiiciic{d}iiciiiiiic{d}ic{d}iicic{ii}dddc{dd}iiic{i}dciiiiic{dd}iic{ii}iiiic{d}ddddddc{i}ic{d}dddciiiiiciiic{i}ddcddddc{dd}iic{i}icciiic{d}ic{i}iiiic{d}ddcdddc{i}ciiiiic{d}ddcdddc{i}iiicc{d}dddciiiiciiiiic{d}cicc{i}iiiciiicddc{d}ddddcdc{i}iiiiiicdddddcdddc{d}dc{ii}c{d}ddddcic{d}iiic{i}iiic{d}cdcddc{i}iccddddciciiiicic{d}dddc{i}iic{d}iic{i}iiiicic{d}ddcdddc{ii}c{d}dc{d}ic{ii}dddc{dd}iiic{i}iiicddddddc{d}iiic{i}iiiiicddddcdcciiicciiic{dd}iiic{i}icdddciiiic{d}iiciiciiiiicddddddciiiiicdddddciiiiic{d}dddc{i}iiic{i}ic{d}iiic{d}dddciiiiciiiiic{d}cicc{i}iiic{d}dcddddddc{i}iic{d}iic{i}iiiicic{d}ddcdddc{i}dcicdc{d}icic{i}dc{d}iicc{ii}ddc{dd}ddciiiiic{i}c{d}ic{i}cic{d}iiic{d}ddc{ii}ddc{d}ddddc{ii}dddc{dd}iiic{i}iiiic{dd}iic{i}iiiciiiiiic{dd}iciicddc{i}iic{d}iic{i}iiiiicdddddciiiic{dd}iic{ii}iiiic{d}iiiciiic{dd}iiic{i}icdddciiiic{d}iic{i}iiiiic{d}ddddc{i}ic{d}ddc{ii}dddc{d}ciiiiiicdddcddddciciiiic{d}ddddc{i}iiiicddddc{d}dddc{i}iiiiiic{d}icddcic{i}iiciiic{d}iicdciiiiiiciiiiic{d}ciiiiiic{d}ddddc{i}iiiic{d}ddcdddddcic{i}ddc{i}iicddddddc{d}iiic{d}iiiciiiicddcic{i}iicdddddcdcdddddcddcic{i}iicc{d}ddcdddc{i}dcddddddc{i}dddc{i}ddcdddc{d}ddcdddc{i}iiic{d}dddciiiiciiiiic{d}cicc{i}iiicddddddciiic{i}dddc{dd}iiicdciiiiciciiiic{d}ddc{ii}ddcic{d}ddcdddc{ii}cddddddc{d}dc{i}dddciiiiiicdc{d}dddddcdc{i}iciiiiiicdciiic{d}ddddc{i}ic{d}ddcdciiiiic{d}iiicc{i}iiiciiic{dd}iiic{i}icdddciiiic{d}iic{i}iic{d}ddcdddc{i}iiic{d}dddcdc{i}ciciiiic{d}ddddcdc{i}iiiic{d}dddciiiiciiiiic{d}cicc{i}iiic{i}dddc{d}ciiiiiic{d}iccdddddc{i}ddc{d}dc{i}ic{i}ddc{d}icdddddciiiiicddddddcic{i}cicdddddciiic{i}dddc
`


text:
# How to categorize a continuous variable based on its correlation with another continuous variable?

Two continuous variables are correlated but not in linear relation. How can I categorize the Independent variable to make two or more groups based on the correlation. For example age is correlated with depression. How can I split age in a way to find the highest depressed age group. I tried this using R and iris dataset, but looping take time and don't give me what I really want.

attach(iris)
cor(Sepal.Length,Sepal.Width)

a<-integer()
for (i in Sepal.Width){
b<-cor(Sepal.Length[Sepal.Width>i],Sepal.Width[Sepal.Width>i])
a<-c(a,b)
}
sort(a)


text:
# Fundamental group as a functor

Is it right to consider assigning a fundamental group to a topological space the same as having a functor from $\mathbf{Top}$ to $\mathbf{Grp}$ ? Are there any other examples of such functors ?

-

Assigning the fundamental group to a topological space is definitely a functor. But you have to keep in mind that a fundamental group is always taken with respect to a base point, and hence the functor assigns a pair $(X,x_0)$ consisting of a topological space $X$ and a point $x_0\in X$ to its fundamental group $\pi_1(X,x_0)$. As such, the functor goes from $\mathbf{Top}_\ast$ to $\mathbf{Grp}$.

In more detail, the fundamental group $\pi_1(X,x_0)$ is the group of homotopy classes of loops starting and ending in the base point $x_0$. It is not so hard to show that the map $[\gamma]\mapsto[f\circ\gamma]$ is well-defined for each loop $\gamma$ from $x_0$ to $x_0$ and each morphism $f:(X,x_0)\to(Y,y_0)$ of the category $\mathbf{Top}_\ast$; we take this map to be $\pi_1(f)$. Roughly, this is a definition by post-composition, so it is immediate that this functor respects identity morphisms and compositions.

This is a side remark, because you have been asking about the fundamental group explicitly. But I feel it is in place here because it is natural to consider a functor with domain $\mathbf{Top}$ that is `like taking the fundamental group'.

Instead of $\mathbf{Top}_\ast\to\mathbf{Grp}$, one could also work with a functor $\mathbf{Top}\to\mathbf{Grpd}$, where the category $\mathbf{Grpd}$ is the category of groupoids (categories in which all morphisms are isomorphisms). The functor sends a topological space $X$ to the groupoid which has the points of $X$ as objects and between two points $x$ and $y$ of $X$ the morphisms are the homotopy classes of paths from $x$ to $y$. This gives you the fundamental groupoid rather than the fundamental group.

There are many more examples of functors from $\mathbf{Top}$ or related categories. An important one is the singular functor to the category $\mathbf{Sset}$ of simplicial sets. The category if simplicial sets is defined as follows: first you consider the category $\Delta$ consisting of an object $[n]$ for each natural number $n$, where $[n]$ is the partial ordered set $\{0,\ldots,n\}$ with the usual order; the morphisms are the order preserving maps. Then $\mathbf{Sset}$ is the category of contravariant functors from $\Delta$ to $\mathbf{Set}$.

For each natural number $n$, there is the topological space $$|\Delta^n|:=\big\{(t_0,\ldots,t_n)\in[0,1]^{n+1}:\textstyle\sum_{i=0}^n t_i=1\big\},$$ which is called the standard $n$-simplex. To test your understanding of these definitions, you can show that the map $[n]\mapsto|\Delta^n|$ is a functor from $\Delta$ to $\mathbf{Top}$. Now we can define the functor $S:\mathbf{Top}\to\mathbf{Sset}$, which is called the singular functor, by assigning to each topological space $X$ the functor $$n\mapsto\mathbf{Top}(|\Delta^n|,X)$$ It turns out that the simplicial sets $S(X)$ have very nice properties. One of them is that they really are $\infty$-groupoids. Also, the set $\mathbf{Top}(|\Delta^n|,X)$ is used to define the $n$-th homology group of $X$, which is gives yet another functor from the category of topological spaces. All of these functors have been (and are) important for the investigation of topological spaces.

-
Thanks, this is very nice... I cannot upvote apparently but I would if I could –  JeanThiviers Jun 3 '12 at 17:12
@JeanThiviers: it's a bit strange that you can't upvote it, but don't worry about it :) I included a link to the n-lab page where you can learn more about fundamental groupoids. –  Egbert Jun 3 '12 at 17:16
Lovely answer, thank you. By the way, this reminds me of a question that came up recently, but I couldn't find the answer online: is the fundamental group functor continuous and cocontinuous? I mean, I think I know it's cocontinuous, that's given by the Seifert-van Kampen theorem. And I know it preserves products. But what about general inverse limits? –  Joe Hannon Jun 4 '12 at 1:38

Sort of. Technically, a fundamental group is assigned to a pointed topological space, that is a topological space with a distinguished point (the basepoint of your loops). The category of such spaces is denoted $\textbf{Top}_\ast$, and to make a functor from there to $\textbf{Grp}$, you not only need to assign a group to each space (i.e. the fundamental group) but also assign to each morphism in $\textbf{Top}_\ast$ a morphism in $\textbf{Grp}$, in a way that is compatible with composition of morphisms and sends the identity to the identity.

In this context, this means assigning to each continuous map $f$ that preserves basepoints (i.e. maps the basepoint of one space to the basepoint of the other) a homomorphism $f_*$ of the corresponding fundamental groups, such that $\operatorname{id}_* = \operatorname{id}$ and $(f\circ g)_* = f_* \circ g_*$. We can do this by saying, if $[u]$ is the homotopy class of the path $[u]$, then $f_*[u] = [f\circ u]$. Hence we can define a functor using the fundamental group.

The homology groups are also functors, this time from triangulable topological spaces (not pointed!) to abelian groups (modulo some complications; see the comments).

-
Technically, you need to work in the category of pointed spaces. –  user641 Jun 3 '12 at 9:28
@SteveD oh right, yes. My category theory knowledge is a bit scattered – is there a standard notation for that category? (feel free to edit my answer if you think you can make it more correct) –  Ben Millwood Jun 3 '12 at 9:31
@benmachine I edited your answer to clarify that one needs to work in the category of pointed topological spaces; I hope this is OK. –  Amitesh Datta Jun 3 '12 at 11:12
Standard notation is $\textbf{Top}_*$, actually. –  Zhen Lin Jun 3 '12 at 11:44
@ZhenLin Yes, I wanted to write that but I forgot the LaTeX code for it. The closest symbol to that for which I knew the LaTeX code was $\bigodot$ which is why I used $\bigodot$ instead. –  Amitesh Datta Jun 3 '12 at 12:16


text:
TikZ figure renders different when changing document class

When using standalone or article class, my TikZ figure renders as it should. But when changing to tufte-handout, I get some misalignments. Why is this? How can I solve it?

The code of the figure in the following MWE is taken from the answer of @Tarass to this other question: Dimensioning of a technical drawing in TikZ. At first I thought it was a problem with his \Cote command (as the cotes appeared to be completely messed), but removing all but the figure, revealed this misalignment with the circle.

\documentclass[twoside,a4paper]{tufte-handout}
%\documentclass{article} %uncomment this to see what's happening
\usepackage{tikz}

\begin{document}
\begin{tikzpicture}
\small
\draw[thick,blue,fill=blue!25]
(0,1) coordinate (A)
--  (3,1) coordinate (B)
--  (5,2) coordinate (C)
--  (5,4) coordinate (D)
--  (3,4) coordinate (E)
--  (2.5,3) coordinate (F)
--  (2,4) coordinate (G)
--  (0,4) coordinate (H)
--cycle ;

\draw[red,fill=red!25] (2.5,3.9) circle (.39) ;

\end{tikzpicture}
\end{document}

• Remove \small... – Paul Gaborit Nov 23 '14 at 8:54
• Or put \small before \begin{tikzpicture} , not inside it. – user11232 Nov 23 '14 at 9:04
• Thanks. This \smallwas not so inoffensive at all... – Pablo B. Nov 23 '14 at 9:06
• This looks very much like a bug in tufte-handout: try inverting the order in which the \draw commands are issued (keeping \small). – egreg Nov 23 '14 at 11:30
• @egreg Inverting the drawcommands results even worse. – Pablo B. Nov 23 '14 at 15:30

1 Answer

the class apparently sets up \small to set \spaceskip which seems wrong in general and is a disaster inside a tikzpicture You can avoid the problem by moving \small or you can reset \spaceskip:

\documentclass[twoside,a4paper]{tufte-handout}
%\documentclass{article} %uncomment this to see what's happening
\usepackage{tikz}

\begin{document}

\begin{tikzpicture}
\small
\spaceskip0pt
\draw[thick,blue,fill=blue!25]
(0,1) coordinate (A)
--  (3,1) coordinate (B)
--  (5,2) coordinate (C)
--  (5,4) coordinate (D)
--  (3,4) coordinate (E)
--  (2.5,3) coordinate (F)
--  (2,4) coordinate (G)
--  (0,4) coordinate (H)
--cycle ;

\draw[red,fill=red!25] (2.5,3.9) circle (.39) ;

\end{tikzpicture}
\end{document}


text:
## Logic – How can we know for sure which "assertion" meta level is?

Probably this is a very naïve question, but I could not find a correct answer to this question when surfing the internet. That's why I'm asking this question here. In this book, the authors write:

The concept of consequence, however, belongs to the metalanguage of logic
Discourse. If the couple $$langle F, vdash rangle$$ is taken as the definition of a logic that elements in $$F$$The sentences (or formal strings belonging to the alphabet, the well-formed formulas) fall within the object-level entities during the relationship $$vdash$$This is a relationship between a subset $$X$$ from $$F$$ and an element $$α$$ from $$F$$, belongs to the metalanguage. $$X vdash α$$if spelled correctly, will $$“ X " vdash“ α "$$What an assertion is, namely. the wff
called $$“ alpha "$$ is a consequence of the amount of said WFFs $$“ X '$$, This claim speaks a little about certain object language elements $$X$$ and $$α$$, So that's a metalinguistic claim.

I agree with the analysis here, but the analysis here is specific to the way we see it $$vdash$$, I wonder, is it Got to Is it the case that the concept of logical consequence can only be expressed in the metalanguage? Why so? More specifically, how can we be sure that the concept of logical consequence can not be expressed in the object language?

## Bluetooth – Reset Samsung Level u Pro

I have a Samsung Pro and the problem is that the sound balance in the left and right ears is not the same, it has nothing to do with software or anything else.

In fact, there was a similar situation before, and someone simply reset the device by holding down a few buttons on the device and balancing it again.

Now the problem is back and I can not figure out how to solve it.
The headset has three buttons for calling and for increasing and decreasing the volume. and a toggle button with 3 off, on and peel mode situations.
I appreciate any help to solve the problem.

## dnd 3.5e – Which spells below magic level 6 in EACH spell list offer protection from harmful effects of enemy aircraft environments?

Well, to begin Avoid planar effects would not help, as the spell description says

The effects of […] alignment properties […] are not negated by Avoid planar effects.1

It means that Employment form and Eben tolerance from the same sources are also not helpful, as they only allow use Avoid planar effects on more creatures or for a longer duration.

Planar bubble from Planar manual and Spell Compendium would help, but it is a 7th level spell. However, if you are planning a short, one-time trip, a Scroll of the planar bubble Perhaps your best bet – for 2,275 gp, you'll get more than two hours of perfect aircraft protection for your entire group, as you're still considered to be on the material plane. If you spend a lot of time with this plane, you may invest in a scepter2 the planar bubblebut at 68.250 gp you really need the time there.

Resist the planar alignment is an abbreviation of the first level and as expected protects against alignment effects, but the protection is not perfect: it overcomes the disadvantages of low-leveled levels and halves the disadvantages of highly-aligned levels. Its effect, if anything, against special effects like disintegration is not specified and is probably due to the DM.

Unfortunately, there seem to be no other spells that protect against planar effects. You may be able to use undetectable orientation. Misrepresent alignment.2 and or Mind empty3 to prevent the layer from recognizing your alignment, but it's pretty much undefined whether planar effects use fortune telling to determine your alignment and apply the appropriate effects – ask your DM.

1. Yes, all three releases from Avoid planar effects add this clause; I checked.

2. Scepters are items that are triggered by spells Lost Realms of Faerûn These work like wands, but can also deal with spells of higher levels.

3. Wrong orientation is an illusion Race from Eberron; 2nd level for bards, sorcerers and wizards and 3rd level for ministers.

4. Not that Mind empty The level is low enough to be cast. It is the eighth level in every list in which it is displayed.

## Python – Keras GaussianNoise level no effect?

I wanted to add some Gaussian noise to my pictures in the CNN with the Keras functional API, but when testing a few different stddev values, I noticed that the Gaussian plane has nothing to do with the input data.
I used the following code for testing:

``````import tensorflow as tf
import numpy as np
import cv2

stddev = 0.1
image = (image.astype('float32') - 127.5) / 127.5

input_layer = tf.keras.layers.Input(shape=(128,128,3))
gaus = tf.keras.layers.GaussianNoise(stddev)(input_layer)
model = tf.keras.models.Model(inputs=input_layer, outputs=gaus)

noisy_image = model(image)

print(f'Pixel value at 0,0: {image(0,0)}')
print(f'Pixel value at 0,0: {noisy_image.numpy()(0,0)}')
# Output
# Pixel value at 0,0: ( 0.09803922 -0.30980393 -0.56078434)
# Pixel value at 0,0: ( 0.09803922 -0.30980393 -0.56078434)
``````

It does not matter what value I use stddev (tried everything from 0.001 to 10000). I expected the values to be slightly different (or strong if stddev = 1000). Am I doing something wrong?

## pathfinder 2e – What is the expected damage / hit / saving throw / DC per level?

When reading through monster statistics and old adventures, I noticed that players should eventually deal 2Dx instead of just 1Dx damage, otherwise an adequate monster will pose a serious threat to the entire group and is almost unbeatable.

So I wonder with the already existing mosnter statistics and a few adventures of what I have seen. Do we have a listener level that specifies the expected number of damage rolls, bonus, saving throw bonus, and class DC per level?

## PHP – How to test and what kinds of test to write for request handlers that use repository level?

Consider the following class:

``````class FillTestBySerialHandler
{

/**
*
* @var FillTestBySerialRepository
*/
private \$fillTestBySerialRepository;

function __construct(FillTestBySerialRepository \$fillTestBySerialRepository)
{
\$this->fillTestBySerialRepository = \$fillTestBySerialRepository;
}

function handle(): ResponseInterface
{
\$serial = filter_var(\$_GET('serial'), FILTER_VALIDATE_INT);

if (is_int(\$serial))
\$row = \$this->fillTestBySerialRepository->getDataBySerial(\$serial);
else
\$row('error') = 'Error: Invalid serial number.';

return new JsonResponse(\$row);
}
}
``````

This is a request handler that receives a serial number, verifies that it is an integer, and sends the command `\$serial` Repository layer to get some data.

The data is returned in an array form, compiled in JSON, and sent back to the caller.

This may be confusing, but my use case is for a Web "test", where "test" is the name for the business logic. Do not confuse the use case "Test" with the component test!

I want to write tests for this class. Which tests should be written if I want to test the class and want to be sure that it is a real problem that needs to be investigated if the tests are interrupted?

I do the following now – I wrote two tests.

I mocked that `FillTestBySerialRepository` Class with fake data and uses it to test the `FillTestBySerialHandler`, This means that even if my real database fails or the structure or data changes, my test will NOT fail and still pass because `FillTestBySerialRepository` is ridiculed.

After writing this test, I thought well of how I know the database is broken. So I wrote another test to test that `FillTestBySerialRepository`, That is, only mocked data is compared to those retrieved from the real database at the time of the test. If this breaks, I know that the database has changed and is the cause of the error.

But then I thought if I'm doing that, why am I mocking up the database data? Why not just rewrite the first test with real data without mockups.

At this point, I think I need advice on testing my handlers, and I'm here. Please help! What types of tests are normally written for handlers with repository layers? (Handler belongs to the same class as Controller / Action in PHP Framework).

## Unit – How can I increase my score with each level?

in unity, all behaviors and functional classes are derived mono behave However, data can be a static class.

``````public static PlayerData
{
public static int Score=0;
}
``````

then in you monobehaviour:

``````     void Awake()
{
PlayerData.Score+=100;
PlayerPrefs.SetInt("score", PlayerData.Score);
scoretext.text = ("" + PlayerData.Score);
PlayerPrefs.SetInt("score", PlayerData.Score);
}
``````

So you can work in all scenes with shared data.

## Programming Challenge – LeetCode: Binary Tree Zigzag Level Order Traversal C #

https://leetcode.com/explore/interview/card/top-interview-questions-medium/108/trees-and-graphs/787/

For a given binary tree, return the zigzag-level order traversal of it
Node values. (ie from left to right, then from right to left for the
next level and alternately between).

For example:

``````Given binary tree (3,9,20,null,null,15,7),
3
/
9  20
/
15   7
``````

Return the traverse of the zigzag plane as follows:

``````(
(3),
(20,9),
(15,7)
)
``````
``````///
/// https://leetcode.com/explore/interview/card/top-interview-questions-medium/108/trees-and-graphs/787/
///

(TestClass)
public class ZigzagLevelOrderTest
{
(TestMethod)
public void TestZigZag()
{
/*     3
/
9  20
/
15   7
*/
TreeNode root = new TreeNode(3);
root.left = new TreeNode(9);
root.right = new TreeNode(20);
root.right.left = new TreeNode(15);
root.right.right = new TreeNode(7);
IList> res = ZigzagLevelOrderClass.ZigzagLevelOrder(root);
CollectionAssert.AreEqual(new List { 3 }, res(0).ToList());
CollectionAssert.AreEqual(new List { 20, 9 }, res(1).ToList());
CollectionAssert.AreEqual(new List { 15, 7 }, res(2).ToList());
}

(TestMethod)
public void FailedTest()
{
/*     1
/
2   3
/
4      5
*/

TreeNode root = new TreeNode(1);
root.left = new TreeNode(2);
root.right = new TreeNode(3);
root.left.left = new TreeNode(4);
root.right.right = new TreeNode(5);
IList> res = ZigzagLevelOrderClass.ZigzagLevelOrder(root);
CollectionAssert.AreEqual(new List { 1 }, res(0).ToList());
CollectionAssert.AreEqual(new List { 3, 2 }, res(1).ToList());
CollectionAssert.AreEqual(new List { 4, 5 }, res(2).ToList());
}

}

public class ZigzagLevelOrderClass
{
public static IList> ZigzagLevelOrder(TreeNode root)
{
List> result = new List>();
if (root == null)
{
return result;
}
Stack currentLeveL = new Stack();
Stack nextLevel = new Stack();
currentLeveL.Push(root);
while (currentLeveL.Count > 0 || nextLevel.Count > 0)
{
var nodes = new List();
while (currentLeveL.Count > 0)
{
var curr = currentLeveL.Pop();
if (curr.left != null)
{
nextLevel.Push(curr.left);
}

if (curr.right != null)
{
nextLevel.Push(curr.right);
}
}

if (nodes.Count > 0)
{
}
nodes = new List();
while (nextLevel.Count > 0)
{
var curr = nextLevel.Pop();
if (curr.right != null)
{
currentLeveL.Push(curr.right);
}
if (curr.left != null)
{
currentLeveL.Push(curr.left);
}
}

if (nodes.Count > 0)
{
}
}

return result;
}
}
``````

Please check for the performance. This is the second time I have solved this question.
I think I've done a better job now.

## Drawing level sets of the form f (x, y, c) == 0

I have a problem creating contour maps of the form $$f (x, y, c) = 0$$ works well with Mathematica, where c defines the level set. For example, the lemniscate $$(x ^ 2 + y ^ 2) ^ 2 – c (x ^ 2 – y ^ 2) = 0$$, Obviously rewrite as $$frac {(x ^ 2 + y ^ 2) ^ 2} {(x ^ 2 – y ^ 2)} = c$$ will cause some problems for somewhere $$x ^ 2 = y ^ 2$$, When I try to draw several curves

``````ContourPlot(Evaluate@Table((x^2 + y^2)^2 - m (x^2 - y^2) == 0, {m, 0,4}),
{x, -2, 2}, {y, -2, 2})
``````

This works, but I lose the nice shading between the curves and hover over information about the sets of levels, as shown in this example:

``````ContourPlot(x^2 + y^2, {x, -2, 2}, {y, -2, 2})
``````

The best I can do is:

``````lemniscates =
Table(
RegionPlot({(x^2 + y^2)^2 - m (x^2 - y^2) < 0}, {x, -2,
2}, {y, -2, 2}, PerformanceGoal -> "Quality",
BoundaryStyle -> None,
PlotStyle -> {ColorData({"RedBlueTones", {0, 7}})(m)}), {m, 0,
5})
Show(Reverse@lemniscates,
Prolog -> {ColorData({"RedBlueTones", {0, 7}})(7),
Rectangle(Scaled({0, 0}), Scaled({1, 1}))})
``````

But that looks terrible compared to the standard contour diagram and I still lose the set information. How do I get my lemniscate plans to look like this? `ContourPlot` the circles example?

Thanks a lot!

## dnd 5e – How difficult is a Deva boss fight for two level 10 characters?

I am planning a one shot for two level 10 characters and I would like to have a challenging boss fight for the end. The plan at the moment is that they will fight a corrupted deva in the grave of a beholder god. The Deva will take the values of Deva from the monster handbook, and the partially revived Beholder God has a 1/4 chance to fire one random eye-beam (again values taken from Beholder's monster handbook) on one of the characters. I've never had such a boss fight before, and no experience with level 10 or higher characters (I did DMing for a few years, but usually for lower groups up to level 7-8). Any advice would be great, as I would hate it if the fight was too easy or unreasonably difficult.

The characters are:

Level 10 Minion Cleric


text:
# Notice on POW 2022-02

POW 2022-02 is still open. Anyone who first submits a correct solution will get the full credit.

GD Star Rating

# Notice: Change on the due

This semester, the rule is changed so that the solutions are due next Friday at 3PM, i.e., exactly a week after the post of the problem.

GD Star Rating

# Notice on POW 2021-19

POW 2021-19 is still open. Anyone who first submits a correct solution will get the full credit.

GD Star Rating

# Notice on POW 2021-17, 2021-18

POW 2021-17 and 2021-18 are still open. For each problem, anyone who first submits a correct solution will get the full credit.

GD Star Rating

# Notice on 2021-16

POW 2021-16 remains open, as we found gaps in the submitted solutions. Anyone who first submits a correct solution will get the full credit.

GD Star Rating

# Notice on POW 2021-14

POW 2021-14 is still open and anyone who first submits a correct solution will get the full credit.

GD Star Rating

# Notice on 2021-14

Please check that POW 2021-14 is slightly changed; there is an additional assumption that $$X \times Y$$ is Hausdorff.

GD Star Rating

# Notice on POW 2021-08

POW 2021-08 is still open and anyone who first submits a correct solution will get the full credit.

GD Star Rating

# Notice: Mid-term break

POW will resume on Apr. 30.

GD Star Rating


text:
0
Research Papers

# An Axisymmetric Boundary Element Model for Determination of Articular Cartilage Pericellular Matrix Properties In Situ via Inverse Analysis of Chondron Deformation

[+] Author and Article Information
Eunjung Kim1

Department of Mathematics, North Carolina State University, Raleigh, NC 27695

Farshid Guilak

Department of Surgery, and Department of Biomedical Engineering, Duke University Medical Center, Durham, NC 27710

Mansoor A. Haider2

Department of Mathematics, North Carolina State University, Raleigh, NC 27695m_haider@ncsu.edu

1

Present address: Department of Mathematics, University of Notre Dame, Notre Dame, IN 46556.

2

Corresponding author.

J Biomech Eng 132(3), 031011 (Feb 17, 2010) (13 pages) doi:10.1115/1.4000938 History: Received September 02, 2009; Revised November 03, 2009; Posted January 04, 2010; Published February 17, 2010; Online February 17, 2010

## Abstract

The pericellular matrix (PCM) is the narrow tissue region surrounding all chondrocytes in articular cartilage and, together, the chondrocyte(s) and surrounding PCM have been termed the chondron. Previous theoretical and experimental studies suggest that the structure and properties of the PCM significantly influence the biomechanical environment at the microscopic scale of the chondrocytes within cartilage. In the present study, an axisymmetric boundary element method (BEM) was developed for linear elastic domains with internal interfaces. The new BEM was employed in a multiscale continuum model to determine linear elastic properties of the PCM in situ, via inverse analysis of previously reported experimental data for the three-dimensional morphological changes of chondrons within a cartilage explant in equilibrium unconfined compression (Choi, , 2007, “Zonal Changes in the Three-Dimensional Morphology of the Chondron Under Compression: The Relationship Among Cellular, Pericellular, and Extracellular Deformation in Articular Cartilage  ,” J. Biomech., 40, pp. 2596–2603). The microscale geometry of the chondron (cell and PCM) within the cartilage extracellular matrix (ECM) was represented as a three-zone equilibrated biphasic region comprised of an ellipsoidal chondrocyte with encapsulating PCM that was embedded within a spherical ECM subjected to boundary conditions for unconfined compression at its outer boundary. Accuracy of the three-zone BEM model was evaluated and compared with analytical finite element solutions. The model was then integrated with a nonlinear optimization technique (Nelder–Mead) to determine PCM elastic properties within the cartilage explant by solving an inverse problem associated with the in situ experimental data for chondron deformation. Depending on the assumed material properties of the ECM and the choice of cost function in the optimization, estimates of the PCM Young's modulus ranged from $∼24 kPa$ to 59 kPa, consistent with previous measurements of PCM properties on extracted chondrons using micropipette aspiration. Taken together with previous experimental and theoretical studies of cell-matrix interactions in cartilage, these findings suggest an important role for the PCM in modulating the mechanical environment of the chondrocyte.

<>

## Figures

Figure 9

BEM simulations of deformed chondron shapes for estimated parameter values in the case of a two-parameter optimization using the cost function of Eq. 12. Computational predictions (dots) are compared with deformed and undeformed shapes of the chondron based on Table 1 for the cases of Table 4: (a) case VI and (b) case VII.

Figure 1

Confocal microscopy images of in situ chondron deformation within the ECM of a cylindrical porcine articular cartilage explant under static unconfined compression (reprinted from Ref. 36, with permission from Elsevier). (Left) cartilage explants were fixed at 0% and 10% compression and immunolabeled for type VI collagen to quantify the boundaries of the chondrocyte and PCM. (Right) 3D reconstructions were made of chondrons in control and compressed tissue explants.

Figure 2

Illustration of the two-scale axisymmetric continuum model of in situ deformation of chondrons in the middle zone of a cylindrical cartilage explant subjected to static unconfined compression. (a) A single chondron is located at 50% depth (middle zone), along the symmetry axis of a cylindrical explant. (b) The unconfined compression analytical solution for a homogeneous cylinder of ECM is used to formulate boundary conditions for a three-zone (cell-PCM-ECM) interface problem at the microscopic scale of the chondrocyte.

Figure 3

The local environment of a single chondron is represented as a three-zone domain in an axisymmetric BEM model of the coupled cell-PCM-ECM deformation in articular cartilage

Figure 4

Verification of the three-zone BEM model in the case νECM=νPCM=νCell=0.2 and EECM=EPCM=ECell=2.0 kPa by comparison to known analytical solutions from linear elasticity theory. Deformed displacement profiles for the BEM model (circles) are compared with each analytical solution (solid lines) on the cell-PCM and PCM-ECM interfaces for the following: (a) plane stress, (b) plane strain, (c) confined compression, and (d) unconfined compression.

Figure 5

Illustration of convergence for the BEM model when an identical number of elements are used on ICP, IPE, and ΓE. Errors were calculated as a least-squares sum comparing (a) radial and (b) axial deformed coordinates of the BEM model at all nodes of ICP to corresponding values for the unconfined compression analytical solution.

Figure 6

Verification of the three-zone BEM model against an independent finite element solution. Deformed profiles for the BEM simulations (solid circles) and finite element simulations (open circles) are compared along the cell-PCM and PCM-ECM interfaces for the cases of macroscopic: (a) plane stress, (b) plane strain, (c) confined compression, and (d) unconfined compression. Note that the undeformed chondron was centered at z/h=0.5 and its deformed shape is a combination of an axial translation and deformation.

Figure 7

BEM simulations of deformed chondron shapes for estimated parameter values in the case of a one-parameter optimization using the cost function of Eq. 11. Computational predictions (dots) are compared with deformed and undeformed shapes of the chondron based on Table 1 for the cases of Table 2: (a) case I, (b) case II, and (c) case III.

Figure 8

BEM simulations of deformed chondron shapes for estimated parameter values in the case of a two-parameter optimization using the cost function of Eq. 11. Computational predictions (dots) are compared with deformed and undeformed shapes of the chondron based on Table 1 for the cases of Table 3: (a) case IV and (b) case V.

## Errata

Some tools below are only available to our subscribers or users with an online account.

### Related Content

Customize your page view by dragging and repositioning the boxes below.

Topic Collections


text:
# Sequential space

2010 Mathematics Subject Classification: Primary: 54A20 [MSN][ZBL]

A topological space $X$ such that if $A\subset X$ and $A\neq[A]$ (that is, the set $A$ is not closed), then there is a sequence $x_k$, $k=1,2,\dots,$ of points of $A$ that converges to a point of $[A]\setminus A$. If $x\in[A]\subset X$ always implies that there is a sequence $x_k$ of points from $A$ that converges to $x$, then $X$ is called a Fréchet–Urysohn space.


text:
## The cost of having a window fixed is $175 plus$30 per hour of labor. Using h for the number of hours of labor, write an expression that rep

Question

The cost of having a window fixed is $175 plus$30 per hour of labor. Using h for the number of hours of labor, write an expression that represents the total cost.

in progress 0
2 months 2021-07-31T01:55:37+00:00 2 Answers 3 views 0

175 + 30h

Step-by-step explanation:

Hope this helps


text:
[Update: In this post, I remark on some differences seen between Chrome and other browsers in alpha blending computations, but it seems that the most recent version of Chrome (18) behaves the same way as other browsers in this respect. The comments here regarding fading trails are still relevant. I have found that the color-blending behavior of various browsers is unpredictable, and can even change with browser updates; open up the examples here in various browsers to observe the differences.]

I’m a big fan of particles. I’ve created quite a number of particle effects in Flash, and have posted many examples at flashandmath.com. So naturally I am drawn to particles while undertaking my new experiments in HTML5 Canvas. Animating lots of particles can create a heavy load on the CPU, but to my surprise the greatest bottleneck I have encountered is not in drawing the particles, but rather in getting them to fade out gradually. Click here or on the screenshot below to see the effect, and then stick around to read my observations on browser differences and resulting issues with fading trails.

A slightly nicer version of the effect (larger and with more particles) is here. It looks lovely in Chrome, but the trails do not fade in the desired way in IE9 or FireFox. The reason for the differences will be explained below.

Included in the source code are three versions of this effect which use three different methods for fading trails, which will be explained below: ParticlesFading.zip

I won’t explain all the details behind the code, but rather will focus on the fading trail methods being used. The particle animation code is fairly well optimized, with particles stored in a linked list rather than an array. (For an excellent introduction to linked lists, see this tutorial by Michael Baczynski). There may be a few opportunities for optimization remaining in the code, but in my testing I found that the greatest bottleneck in performance is caused by the method I am using for fading out the picture gradually as new particles are drawn to the screen.

### The particle motion

The particles are drawn as filled in circles, and they evolve over time. The way they evolve over time is controlled by some “envelope” time parameters: attack, hold, and decay. (These terms are borrowed from the audio synthesis world, where the attack, decay, sustain, and release parameters control how a tone changes over time while a key is pressed and held.) During these different time stages, a particle’s size will change from its initial size to its “hold” size, then decay back to a final size. Each particle has an age parameter which records how long the particle has been on the screen, to keep track of the time stage for the particle.

When particles either reach the end of their lifespan or go off the boundaries of the display area, they are removed from the list of active particles. However, they can be reused, so they are stored in a recycle bin (also a linked list) for future use when more particles need to be added to the screen. (The proper name for the recycle bin is an “object pool”.) This is an optimization technique which avoids the creation of new Objects.

Each particle has a Boolean parameter right, which controls whether the particle tends to turn to the right or to the left as it flies in the plane. The turning is controlled by changing the acceleration of the particle with randomized amounts, and always in a direction perpendicular to the direction of motion.

On every refresh of the screen, the particles are moved to new positions and then must be redrawn. If we simply want to see the new particles in their new positions, we should wipe out the screen by drawing a filled rectangle over the entire canvas before drawing the particles. But a more interesting effect is created by simply darkening the previous image and drawing the newly positioned particles over the top of the display. We then see a fading trail behind each particle as it flies through the plane.

But this is easier said than done in the HTML5 Canvas. One fading method is to draw a black rectangle over the whole display, but with a very low alpha value. To see this in action, click here, but be aware that this looks great in Chrome but doesn’t achieve the desired effect in IE9 or Firefox (you can check other browsers). The problem is that as the previous images fade out, they never reach color component values at zero, resulting in permanent gray marks as seen in the image below.

This effect is no doubt due to the way color component values are stored as integers ranging from 0 to 255, manipulated as floats, and then stored again as integers. Interestingly, Chrome seems to handle this arithmetic differently from the other browsers.

Here is what seems to be happening. If we draw a black rectangle with alpha 0.1 over an image, then the pixels behind the rectangle should darken to 90% of their previous value. But if the previous value was 5, then 0.9*5 = 4.5, which gets rounded back up to 5. In other words, the value will not change. The effect is more drastic if we wish for a slower fade: if we draw a black rectangle with alpha 0.01 over an image, then color component values at 50 will stay at 50 (because 0.99*50 = 49.5).

I can’t say for sure what is happening in Chrome, but I suspect that color component values are always rounded down to the nearest integer. So for example, when we darken a color component value of 5 by 10%, the resulting value of 4.5 is rounded down to 4. Because of the rounding down operation, colors eventually fade to black.

So how can we achieve a consistent look across browsers? One idea is to copy the current image to another canvas, and then redraw it to the screen with a lower alpha value, by adjusting the globalAlpha value prior to redrawing. But this essentially causes a similar kind of pixel arithmetic as in the black rectangle method, and we again see the gray trails (click here for an example using this method).

To create the desired effect, we have to realize that we really need to be subtracting a constant value from the alpha channel of previous pixels, rather than multiplying by a number less than one. Coming from a background in ActionScript, I am accustomed to using color transforms or color matrix filters for this type of effect. But in JavaScript, we have to manipulate the pixels ourselves, and unfortunately I have found that this creates a bit of a drag on the CPU. But I slightly lowered the number of particles, reduced the size of the display, and have been able to achieve fairly swift frame rates as a result. The final result is here.

Here is the code used for this alpha subtraction method. First we get the image data from the current display and access its pixel data:

var lastImage = context.getImageData(0,0,theCanvas.width,theCanvas.height);
var pixelData = lastImage.data;

We then iterate through the pixel data and lower the alpha channel of each pixel by 3, which creates a very slow fade:

var i;
var len=pixelData.length;
for (i=3; i<len; i += 4) {
pixelData[i] -= 3;
}

Note that pixels are stored in groups of four numbers representing red, green, blue, and alpha channels, so the alpha channel of each pixel is stored in every fourth entry of the pixel data array. Finally, we put the image data back into the canvas context:

context.putImageData(lastImage,0,0);

After this, we can now draw the particles over the display in their new positions.

Looping through each pixel in the display and accessing the pixel data array repeatedly is time consuming, and takes more CPU resources than drawing a single rectangle over the whole display. Of course, in the internal workings of the browser, some similar kind of arithmetic must occur when blending the low alpha rectangle with the underlying display, but this is of course a more optimized process compared to the Javascript execution.

### Final thoughts

So for consistency across browsers, we ended up requiring some code which directly accessed the pixels of the display and altered them to our liking. This is clearly the type of operation that would benefit from hardware acceleration, and to be sure this will become easier to do in the near future. I would be pleased to hear from you if you have any more thoughts on how to achieve this fading effect in an efficient manner!


text:
# Behavioral approach to system theory

Lecturer

Ivan Markovsky, Catalan Institution for Research and Advanced Studies

Web Page

Schedule and place

This 15-hour course will take place in 6 sessions over six days on November 14,16,18 and December 5,7,9 2022

Schedule and rooms in ESAT:

• November 14: from 10:00 to 12:45 - Room 00.57
• November 16: from 10:00 to 12:45 - Room 01.57
• November 18: from 10:00 to 12:45 - Room 01.57
• December 05: from 10:00 to 12:45 - Room 01.60
• December 07: from 10:00 to 12:45 - Room 01.57
• December 09: from 10:00 to 12:45 - Room 01.35

Including a 15-minute coffee break in each session

Parking The Molen, Celestijnenlaan, Heverlee

There is a daily code for the parking : The code should be used to enter and leave the parking.

14/11/22: 3407#

16/11/22: 3298#

18/11/22: 5542#

05/12/22: 3538#

07/12/22: 7344#

09/12/22: 1160#

Teaching method: Face-to-face

Abstract

The behavioral approach to systems theory, put forward 40 years ago by Jan C. Willems, remained till recently an esoteric niche of research. The renewed interest in the last years is because of its unique suitability for the newly emerged data-driven paradigm, specifically the representation-free perspective on dynamical systems as sets of trajectories. A result derived in the behavioral setting that became known as the fundamental lemma started a new class of subspace-type data-driven methods. The fundamental lemma gives conditions for a non-parametric representation of a linear time-invariant system by the image of a Hankel matrix constructed from raw time series data. This course reviews the fundamental lemma, its generalizations, and related data-driven analysis, signal processing, and control methods. A prototypical signal processing problem considered in the course is interpolation and approximation of trajectories. It includes simulation, state estimation, and output tracking control as special cases. The theory leads to computationally tractable methods. Regularized version of the methods is robust to noise and model assumptions. Participants will get hands-on experience with the methods via Matlab exercises and individual work on mini-projects.

Description

The course consists of six 2.5-hour sessions. A session starts with an introduction, followed by questions-and-answers and exercises. After the third session, students will choose mini-projects to work on.

The course will not cover a fixed curriculum and will be adapted as much as possible to the need and interests of the participants. An indicative outline of topics that will be discussed in the course is:

• Dynamical systems as sets of trajectories
• Complexity of a linear time-invariant system
• Parametric representations of a bounded complexity linear time-invariant system
• Controllability and control in the behavioral setting
• Data-driven non-parametric model representation
• The fundamental lemma
• Identifiability and the most powerful unfalsified model
• Generalizations of the fundamental lemma
• Data-driven interpolation and approximation of trajectories
• Existence and uniqueness of an exact interpolant
• Mixed interpolation and approximation
• Recursive computation
• Dealing with inexact/noisy data
• Naive approach: using the pseudo-inverse
• Structured low-rank pre-processing
• Nuclear-norm and $$\ell_1$$-norm regularization
• Generalizations to nonlinear systems
• Polynomial time-invariant systems
• Hammerstein, finite-lag Volterra, and bilinear systems
• Linear time-invariant embedding
• Applications
• Input estimation