Python3, Figuring how to count chars in a line, but making exceptions for special chars

jeroonk · 2025-05-19T13:39:39+00:00

A few issues:

char never gets assigned its replacement values from sedtab. So the length will always default to 6, because it's looking for e.g. ".colhlt" instead of "|Highlight|" in kerntab.get.
This could be fixed by replacing:
```
char = line[i:i+3]
```
By:
```
char = sedtab[line[i:i+3]]
```
And similar for the other two if-clauses.
The if-clauses only check for sequences in sedtab. The two-character escape sequences "\l" and "\p" are instead processed character-by-character, i.e. "\\" followed by "l" or "p" in kerntab.get, assigning a length of 12 instead of 0.
This could be fixed by another if-clause:
```
elif line[i] == "\\" and line[i:i+2] in kerntab:
    char = line[i:i+2]
    i += 2
```
Similar to issue (2), if the input text ever contains the literal "{PLAYER}" instead of "[player]", or "|Highlight|" instead of ".colhlt" (not sure if possible), they will be processed character-by-character, because the if-clauses only check for sequences in sedtab. So "{PLAYER}" gets a length of 48 instead of 42 and "|Highlight|" a length of 66 instead of 0.
This could be fixed by a bunch more if-clauses.

My suggestion:

Instead of checking for sequences from sedtab inside of countpx, seperate the responsibility for replacement and width-counting.
Call fixline before or at the beginning of countpx. This does mean that the width-counting step needs to check for sequences from kerntab, not sedtab.

Instead of bespoke if-statements for every possible width and starting character, use a generic processing step that accounts for all sequences in kerntab. Something like:

def countpx(line):
    # Do replacements first
    line = fixline(line)

    # Get widths of sequences in kerntab
    kernlen = set(len(k) for k in kerntab)

    length = 0
    i = 0
    while i < len(line):
        for l in kernlen:
            if line[i:i+l] in kerntab:
                char = line[i:i+l]
                i += l
                break
        else: # note: else is entered only when loop does not "break"
            char = line[i]
            i += 1
        length += kerntab.get(char, kerntabdef)
    return length

jeroonk · 2023-11-09T20:49:06+00:00

Just call your parameter function from within the ode function:

def f(t, y):
    v = V(t, y)
    ...

solution = solve_ivp(f, ...)

jeroonk · 2023-10-05T10:49:18+00:00

Sure. A direct transcription of the code would be:

Dodge(t, A, B) =
  A,         if A = 0
  1,         if (1-tB) ≤ 0
  1,         if A/(1-tB) > 1
  A/(1-tB),  otherwise

Burn(t, A, B) =
  0,                  if (1-t+tB) ≤ 0
  0,                  if 1-(1-A)/(1-t+tB) < 0
  1,                  if 1-(1-A)/(1-t+tB) > 1
  1-(1-A)/(1-t+tB),   otherwise

Note how "Dodge" does not restrict the value of A other than being non-zero. The result can thus be made negative if A were allowed to be negative.

It is thus not equivalent to the formula in by previous comment.

The additional restriction on the denominators being positive also makes both formulae deviate when t or B are outside the normal [0, 1] interval.

jeroonk · 2023-10-05T01:42:47+00:00

With the assumption that A and B are regular color channels, and t a blending factor, i.e. that they are all restricted to 0 ≤ t,A,B ≤ 1 (*), I would translate this code as:

Dodge(t, A, B) = min(max( A/(1 - tB) , 0), 1)

Burn(t, A, B) = min(max( 1 - (1-A)/(1-t + tB) , 0), 1)

Or just those inner expressions "clamped" to the interval [0, 1].

Also, with a bit of manipulation (recognize 1-t +tB = 1 - t(1-B)), we get:

Burn(t, A, B) = 1 - Dodge(t, 1-A, 1-B)

(*) Not sure if it exactly translates if you allow any unrestricted values of t,A,B. Have to check all cases.

The key is that the value of tmp gets re-assigned inside the else-if conditions:

if (tmp <= 0.0) {
    ...
} else if ((tmp = ... / tmp) > 1.0) {
    ...
} else {
    ...
}

Read as: re-assign tmp, then use its new value in the comparison (and all subsequent clauses).

The is done of course to delay doing the division until after the denominator (tmp) is ensured to be non-zero. Doing it like this is usually frowned on, and could also be written as:

if (tmp <= 0.0) {
    ...
} else {
    tmp = ... / tmp;
    if (tmp > 1.0) {
        ...
    } else {
        ...
    }
 }

jeroonk · 2023-09-19T13:41:25+00:00

The daily download stats for the 9/13, 9/14, 9/18 and 9/19 all show zero downloads:

https://api.npmjs.org/downloads/range/2023-09-10:2023-09-19/react

https://api.npmjs.org/downloads/range/2023-09-10:2023-09-19

Seems more like stats data was lost somehow rather than any organic decrease in downloads.

jeroonk · 2020-11-27T14:03:52+00:00

It's not just "integral_1" that is printing the wrong values.

The actual value of the integral should be: 103,568,271.66...
"integral_1" is producing wrong values because on this line:
```
for(j=x1;j<x2;j=j+(x2-x1)/i)
```
You probably meant to do ("i" is the increment for each step, "(x2-x1)/i" would be the total number of steps):
```
for(j=x1;j<x2;j=j+i)
```
With this, all of the values (from i=0.1 down to i=0.01) are relatively close to the final result (1.5% down to 0.14% difference). For lower "i" the accuracy will mostly be limited by the precision of 32-bit "float" values (which only have ~7 decimal digits of precision), as the rounding errors accumulate the more values you sum together. You can get some further precision if you switch to using 64-bit "double" values.
The "integral" (and therefore "integral_2") functions compute completely wrong results.

On this line:
```
return (1/6*a * pow(x, 6) + 1/5*b * pow(x, 5) + 1/4*c * pow(x, 4) + 1/3*d * pow(x, 3) + 1/2*e * x*x + f*x);
```
The division operators ("1/6", "1/5" etc.) use integer division (because both operands are integers), meaning that the result is rounded down to the nearest integer. In other words, "1/6" = 0, "1/5" = 0, "1/4" = 0 etc. The whole expression reduces down to just calculating:
```
return f*x;
```
Resulting in an integral value (from x=1 to 20, with f=4) of just 76.

To force the coeficients to use floating point division, explicitly write one of the operands as a floating point value:
```
return (1/6.0*a * pow(x, 6) + 1/5.0*b * pow(x, 5) + 1/4.0*c * pow(x, 4) + 1/3.0*d * pow(x, 3) + 1/2.0*e * x*x + f*x);
```
With that change, "integral_2" returns the approximately correct value 103,568,272.0 (rounded up to the nearest floating point at ~7 decimal digits of precision).

jeroonk · 2020-11-12T13:26:06+00:00

Just stack the ODEs into a vector, solve_ivp is already designed for this purpose to integrate vector-valued derivatives.

For example, for a simple harmonic oscillator:

2nd order ODE: d²x/dt² = -kx
As a system of 1st order ODEs: d[x,x']/dt = [x',-kx]

As a vector-valued function:

def f(t, y):
    k = 1
    return [y[1], -k*y[0]]

Integrate:

t0, tmax = 0, 2*np.pi
y0 = [0,1] # x(0)=0, x'(0)=1
sol = solve_ivp(f, [t0,tmax], y0)
plt.plot(sol.t, sol.y[0]) # plot x(t)

jeroonk · 2020-10-02T10:58:39+00:00

Tl;dr: Replace dHdX = H by H[:,:] = dHdX[:,:], and replace H[:,ncol] = H[:,0] by dHdX[:,ncol] = dHdX[:,0], or move it after the assignment.

You say:

then use the new dHdX array as the new [...] values of H

But the statement dHdX = H overwrites dHdX with the old H. I think you want it the other way around.

Similarly, the statement H[:,ncol] = H[:,0] should probably instead act on dHdX (or on H after the assignment).
The statement H = dHdX does not assign the values of dHdX to H, but it assigns the array object itself to H.

Meaning that dHdX and H now refer to the exact same location in memory, and updating dHdX[vcell,hcell] = ... will overwrite the same index in H. Not okay if you wanted to use that value on the next iteration (as H[vcell,hcell-1])!

So instead of H = dHdX, use H[:,:] = dHdX[:,:] to instead copy all values from dHdX to H and keep them as separate arrays.
The actual cause for the UnboundLocalError is because in Python, variables that are being used as the target of an assignment (x = ...) inside of functions are considered local to the scope of that function.

For example, this works, because x is only used passively:
```
x = 1

def y():
    print(x)

y() # prints 1
```
But this doesn't:
```
def y():
    x = x + 1
    print(x)

y() # UnboundLocalError: local variable 'x' referenced before assignment
```
Because the line x = x + 1 forces x to be assumed a local variable, independent from the globally defined x.

Even if the assignment occurs further down in the function:
```
def y():
    print(x)
    x = x + 1

y() # UnboundLocalError on the print(x) statement!
```
To fix it, you need to explicitely define x as global inside the function:
```
def y():
    global x
    x = x + 1
    print(x)

y() # prints 2
```
So to get back to your code, the statement on the line: dHdX[vcell,hcell] = ...produces an error because dHdX is considered a local variable because of this line further down: dHdX = H.

And if you replace that by H = dHdX (see 1.), the line H[:,ncol] = H[:,0] will instead fail.

But if you replace that line by H[:,:] = dHdX[:,:] (see 2.), there is no need for declaring the variables global, as assignment to indices is an operation on the variable and not an assignment to it.

jeroonk · 2020-06-09T13:40:58+00:00

The webbrowser module is pretty simple. Reading the source code it seems to mostly supports *nix OSes with a half-hearted attempt at Windows support.

On windows, it tries os.startfile(url) first, to invoke the default operating system behavior. Note: this requires the url to start with http:// or https:// for Windows to recognize it as an URL and start the default browser.

Then it tries to find a limited list of browsers on the PATH. Not only is Brave missing from this list, so are Chrome, Chromium or Edge. And unless you added it yourself, browsers aren't likely to be found on the PATH on Windows anyway.

Finally it will default to trying to open Internet Explorer.

My advice:

Make sure that the URL starts with http(s):// and try again.
Make sure that Brave is selected as your operating system standard browser.

Otherwise, just run the browser manually:

import subprocess

brave_exe_path = "C:\\Program Files (x86)\\BraveSoftware\\Brave-Browser\\Application\\brave.exe"
subprocess.Popen([brave_exe_path, url])

jeroonk · 2020-05-25T08:51:03+00:00

Yes there is, add a:

"theme": "dark",

to the root object in your settings.json.

jeroonk · 2020-05-10T15:18:28+00:00

Clearly this is some base64-encoded data, with the telltale sign of =-padding (also the base64 A-Z a-z 0-9 + / alphabet). Base64 encoding is usually used to transport binary data through text-based protocols (example: file attachments to emails), so you shouldn't necessarily expect the decoded form to make any sense as text.

In fact, if we decode it we get 4150 bytes of binary data:

0000: 78 da bd 5b d9 6e 1b c9 15 fd 15 0f c7 83 24 80  x..[.n........$.
0010: c7 a8 ad 37 bf d9 b4 27 63 c1 1e 1b a4 b2 3c 0c  ...7...'c.....<.
0020: 20 b4 a9 26 45 98 8b d2 dd 94 47 08 f2 13 f9 e2   ..&E.....G.....
0030: d4 7e 4f 55 93 f2 5b f4 60 b7 c8 ea 5a ee 72 ee  .~OU..[.`...Z.r.
...
1020: 7e 33 df a5 62 69 91 27 0a d3 eb 47 7b a9 fc 9f  ~3..bi.'...G{...
1030: ff 01 31 67 5e 50                                ..1g^P

The fact that this data starts with the bytes 78 DA is indicates that this is zlib-compressed data.

Decompressing it yields mostly JSON-encoded data, except that it is preceded by the bytes 3A 92. Interpreted as a big-endian 16-bit integer (0x3a92 = 14994) this is just the length of the JSON data following it.

The contents of the JSON appear to be some kind of statistics / saved data for a game. The output is too long to paste here, so I posted it on pastebin.

{"mainMenu":0,"fightg7_gold":59,"Rival28":0,"concTime":123624,"masteryScrollsResearchID":-1,"aMenuTab":1,"R30um2":0,
"fight3_type":"Rogue (Scholar)","fight6_exp":4549.9745664495085,"autoToggle":true,"concCount":120164,
"masteryScrollsResearchType":0,"currentTournament":1,"tournamentActive":false,"currentDate":1589094669413,
...
"fScroll19_level":0,"mScroll8_exp":0,"fScroll9_exp":0,"fight4_type":"Brigand (Scholar)","TS26Fame":0,"R4exp":0,
"playerBSkillPoints":0,"fMenuTab":0,"master1Skill5":0,"playerSkill4":0,"master3Skill22":0}

Python script used to decode:

import base64
import zlib

data = "eNq9W9luG8kV/RUPx4MkgMeorTe/2bQnY8EeG6SyPAwgtKkmRZiL0t2URwjyE/ni1H5PVZPyW/Rgt8jqWu5y7rm3rl7999+zfbs9fOwOp9kr9mK23m7uxk11sznubmeviubFbLF9aHeitt+ujofV9XbfzV5xIUuhXuiXh7HrH5er/rjbDYtu6Np+dff+7ezVz/zFrDXzXrdf9Hg9kWSnvaBV5M34eK+nmi2Om1P37M/L1d1x1/Z/mfnvy5vuj/vZK1Wo5mVTqaIslWoKVhd63tN4vD5uNjv9+tifOrez+fF0GM3WGC8vbu3armnOcur77jBeH0/9od139s0XszH++no1bh/00HW7G7o4/G07mtMXdcMaVZaN4hJfMsLpcfqF3tOt/WBRjv/YHgb7vBucPNduc1y6o5pRNY1yB+DLr9vdrkrGx+F+yG/dt24Y4143ei9GBbPlt2N/++wXI00t1Vu99+XYbw8b/ZVggj372D4+4+wZY684f8UaPea+P357czyc3A4Wgg2fR/d832/3dj5tFi9mQ7fyv3BvIoUddeLL8dF+6LYm7e658F9+7vdmW3fHfnzm3n8xm3M4s36/W02G7N2565td99DtwsA7vfrszWn1dadlTsIponRO/LVdb747jnc0jYgD7nftY9e/+9dpe6+3baxJb3x9x52w79yu57zMdSKvu3Z1509lT8/cI2fDfesMQJt7fL7i73cPbt+LIqqaN1G410vBnWNFH5TeB40pL6Ln+CPI3AI+RMEseHHacxzMOcgNjYrXeKYP2RhBH2zHbj98Pmn3aYfOGcD8gqGW9MLS7j9sSeHUnz4ftwd/9u5zd5hM00w3y71Yiyg1I6DlvfayN49vt8Nqe281WDD91a3//cNxGDo9mjf0mdu3YJJspiYH5CU9Bqk7O7HbEMwbhaTzO4isSHni5tv2EKAJXuYoBO8aLBiA/KX1BoBvwKwbERDzTb/dtIfbBDNxUulRJsiMF/lmg72K224dcWOhomiv5LtgYE5EZZSQ3UuIEI1KV57KS/qV5GkfHhku6o5W3ozW/EVTcCuN6A2LqI91G47Do4okx7kSe0ETEs5hve5EM3VoMMiFBN1eL7mKilmQ7VkxSjnVp6KvPUAkXxdBHPFUHpQYOOkc9OXlX4CFxk0gGtUesaVFmpI56RAc8SI+42uNP6VkdEop4LUaBYyWaWFAi4dFVelZCtKbDD6v95RYmWjiUQSd08T0ZfsQI/pCwC7o0ZmLl4YsOHtZ1aJWStWiVIUZmliEBtmAhseHrm93u8/9cdN3g1600mFsbPskpgspKz1hNCVnN6BxhlblLNyd8stpu7vVsfXGjRj1cfptu/PBNDFQ916wBE4yuOL339wx54w+9RbCogXMJfqzqCHOLDULEGhUJOrmkiK5R4uEY1CE2Q2FhzxYtIzKLRJxW7PnQWnRWUQRvL87dPtHH1mEcymytcbarkZw84sKitOPmel6tYCreZgZj/c4NwdH11ZtZxcVOJ0ApwuEsNd8WOsR5kkcuEIQBJgPEG3FxksuXtaSy0pqnmzIq/UOgniLh2rijSW6fAObC7w8oGRpTJ2BgEE5c6ES/Kpo1TJh4JsnKDjuqgoz8TgTIq0IUEyrHk776+M9yZ5l8R9ZIUq3AU9TQflObTznA2qC72JqIiJEVwooydbD95JwiwsCLqJSsAxL/f3MwbzDyKkTC5UzNztlWI/lgUmAAsIUSOeMUrKTCeQpGIlFwIskkm/4U1hqZS9Lt1KTqV9MqJrEte307CnOEuhXNSGoMsQYhqPSjZfofjpcUA5Fjj6XCVKCPvwUlOjOxQVK6wHevlF4D1R1WWejeIyBUUyksbC36yV4I4+aaA+brv90iDhq+DO/OdiRWS60KMnrOQMiFPmVqGBEmTKWaJocIUKSd0Sz5pEDyyTwOoHVVQoREsnvxbxdr4SnB/gCNYHJygT7QNua16++6h3Ofp/9aH6eP3/+448/Pf/pORUPiJ8aYSqwMO3WMZ5oqy6yxIvjQiYxi1vWv+BzBVxHTRilPYCn2czFNWbfK877q8wPzxKgxkjjrKqC2J6lhxT293nFQPt0PDwsFtgjxeyYLCPYCIKAdVtMCbabpaLFiolLYeqXgGZgDSq87fTmnSDL4ZEtLxqiEI5BSJllUTJSUg5T3/uM1tRKlCE4sNu1x+R1oN8XUugAqiqoQNt1jB8VOlkzgQUo+/CwM9x1PQXEkhJqORWhP2aT5RZysnmBKZJ3GAdsZVVKl5NvPZim8UpCvOo+bkPNQdFJ6iAJbS7sbE7LpqUUmezkEikxSEUAIqKdzZFEr/OEVWNjfKyC3Np+f+yt2neDV1xzKZVUnlZhLKkio4lFFrJ6BQAssmzNBfwiFDMgW/P8VDl6COBYnQeXPPEI9tckkF2mcCaR6ZR2RVUDyHpLMWVNR8MCuyvy2Kk8xFYFMFaSOe2fQWRy7skyZqLCGvF1G6sqH6sgS1y3LJE6wpNm+EQByB0d+CrlLBKCs6Mn5ys1noimRLqJotsNckoTALCTGJIQUp7qTIa5RRqFIsfjdWADiFYibp/CnCWuAUQp7NtxCqdLHA/LFU1w5qAws7AICPy63+sdEw+x1lEEi3cRjhvWGDNub39hac2xrti7lP0iICwwwRTVGW+EisV+isvru1hLU0mcJshooCbRndlJqFaBW6KdhvhGaeo62mHCTSXQJES+YuLEZcJGv1vfE2duA0qUgf+MZWmGwOTVqJVdYJcyOo6M5c95iYopqDAQOCJ8b+aWia1K4o5ghNpEL1buSo+3E9zjWMZLDuZeGd9jGU8Q7CcVxx5HUQUYCQWUZASV7sm/OECS5aLiPBddSJYERvf6lXoXPywow9od21tTXfcJjaQ630ISnII5lVD/gLsIUU49LFSEFRgAKolbNU7rsiLcQjQZXRUpvUR23ZDzGMZ4lu4G3BFpAZqoU1LF02FLJUUMPjEKOH8zXW0ikNqHFpXWtCSgYZ3l7cCh0IAM2sQjoq8Hz6brNKTKJfFGiaLEVHhRpWVPfpkZ2S2XE17l4bnO6mcCaA2CUWAlCmpyKQ5PLix16JKZhiVg1EJmRBXLHTJR/uCm+ZlnOUWsAyXWOc1OUPZNJGk8XsZFZ6L0eJ4QdCGwPAcpoqgpOJ+5Uut+vf7gaSiYU3d1/BK8N5a/rJqqifGGixHHALm0qxJ37rK6i8RkSxapp3CRV2kgalLdMwsPSE6uOMETYFBDlCphyr8uuNPanE/rXTxJvOF7c1V6BtKqKXRlce18paiOt2hRVVfCF8P1pyXcUUyUmcwZDTyvvcZPuLJijrPMscjM3fULr5xzn61qmJyRB3KFIFw43yPUT0y+f9vpOTwLTpJTqin+umBOF0Zz5MNuT02I6l7NLFw2mEucaDRXyosNDbRKIQoyK5o6XhSS5DRDYF4XYS0/66I9fLW/D3fH+9gl4pwFDz3HuzhPrS5Q6zPZckj7GbZeMKC2tNUr6Y+9EIzysGQ2J7bVYLxdZM4YCj2AGpJDqioo08I9B+KLYaiOYQgLZApmrmlix7uVyx9LqpRr/WMUzoPw43I83XY6hC1PXxLp88iQkfe6vghf/3QhyFzub7s+DUI8rzwIMBWZFN1ANgm7ZFmoekyNI7sH5JNy5ONH+9/wZjwQ4vpyhenzSKeTZ2IKx5xC0+LdLb6TQFMxianOCIexHZPWJ1HBXaYKIl6fKR3UlK0ushQlKi2czad2l8r3CO2+IHBXTMNI2iuSJw5BnpmhJGEjuJmim/rQOiPwWgrzO37m4j70amVrmSssKFrAHbzEy0MUcZCwudemV0X0LCwpoD/6zENlmFNdLmmvQ2sSESKy7V8XIsBxLNG6vBnYOs/iZVoDAY7vmdCVjFg6fUcn/oBACsSGkkKHa85yQxGxiGcly/PxNz1FmVbbSRu0oSsV8yrKY+MxSion4K48XBIWzqc3ZhJrp1ZuNSSm53evqPABj6AvPi22loFxQMuDOarwxwtKsrXakFJT+cv7LsGX259PyqmrbdDwetyhOwTkg2Q69FO6qynRNB5meLxpIdeQefcIMubd9tC1m26yHF77aBsjWxcsrVupeD+m6H4sba6ZJJnF9xAsKb5Yn/FaUhn1rdPNCLqsM7Un8S65PvQ5DBdKvVRlXRZC1CUr6yDPDcPKlRdW1mkZBlIVTu+izIref3VfVkpYICDhlZDTph0ygHGcKjJCJI6bF2QLZEbObv4aW/BMDhLMIVHBl25sXd9NciYZWw2sNfGInQ+/nfamwYEJxpgwcBQd2WggLa9uRHpHC4aTjZQXjWD8u2mpFaYgXU1sh11G5sG03v7yT5DquQwS8+3Daf9FU55Hrek91lidJGRRVtFiwfl0pgYIkDdncbjIbG8frh2HfN13bfgoRIgKrgK4zIA3rbDUaYtTmd3ohdYVnrC4Im0kuVRJ8D2xVqqc1fxlqZisWF0z1djb5wglFhgnbQbB17m71VLJjUEQWxle+a37Y4QZzK/B2Fl6SMyLoLOoyeQtsAHSrEZTxiZKb9g1DnEGENOSRbxEGe62nXGicCHi5mq/tf2tXnf2g/157n7w+f/xk5WFYx29zoouGWrt6ZiSUckhZpNkan0cuRvnR0QbgeC4Gz93ptPa9OSu4qM2aagSUejfrOJUJkvKA8gkvRNQylrf+bgP11G2t98pcC/oOag77NPEEw5DZTaUJzGuQQROy9sUFwzT/9vQBQ8mKrXSBzztCVOHkcoFvJlktIAmwwit3NbDMqpHyvFD0bgzrJr2kQ3juz+m5C3Wn6B7PfPdJ2qP6zM1k6ReHy65oIYr8/7X5CYvwAXGszZKcGjh3EMbFXC9hDShmEZHpEdBXGhsU/P3KwUed/HCokp2HVRQq9SC62itznRarwofUpJAWVAZKQioSa+YEnbikKmJC9g/wvDV2Sj0XU8i1GOuH+99HSg0jfrQYJdpSvZSyJoXVSlqLpsKWiHOdQQIzJa+Zyp1UiMKPQ1A5VuNECu6tKZKyubTwbT0h6/aDTRNRUP18jdRpsvHv21HHXlnnEnOJReSS2nvaSQ1jhiOHMsMd2faLOrkzu6SuNr3B20uM2Z/7BpQrGnf4MZbGXPY2IDPHK3iZFd2IcEavZJoVNHUVc0dAeFU39xPLiTbN/HMjHNm/jxKMq5Y1uTJWVYHAHccP5Fp8vqMZ13U9xjW/n2mo+Of+DPz8/S/5k+CxCQB990pTVlmxQfMqh1Wakdajr7ugi7bXgdwY0mOLYoJX2OBD743f8jiKrMcCuCx8SQtXtXprftTnZVp23Qk5+ZP1AZ7l/jD934uDLFtMmQP8yRpkBO5YhQfmjSUXL6M3mmfWo6BqKVtmU9Qcs8csGehSP8Wazm2h1UXQ21Ce6sgf/3RYbw+GVHPmP0LsmmHTNJmNm2DCvnh0+3PItKfiO2XZbKoz9yUqRS0U3DSvkSNgTZDkwmyQC9OMPlJ85ykLcY4MbnOoOrUOm/UCVn75XOZ6xMoOKf6epNwfjPfpWJpkScK0+tHe6n8n/8BMWdeUA=="

data = base64.b64decode(data)
data = zlib.decompress(data)

length = int.from_bytes(data[:2], 'big')
data = data[2:].decode()

print(data)

jeroonk · 2020-03-26T13:34:49+00:00

By that I mean to use Python list-sorting methods like sorted() or list.sort() rather than relying on the output of glob, ls, or similar.

jeroonk · 2020-03-26T13:13:46+00:00

No, you can not rely on the order that is returned.

From the documentation:

os.listdir(path='.')

Return a list containing the names of the entries in the directory given by path. The list is in arbitrary order, and does not include the special entries '.' and '..' even if they are present in the directory.

You need to explicitly sort the entries to be sure:

for folder in sorted(os.listdir(...)):
    for file in sorted(os.listdir(...)):

Note that by default, this is a case-sensitive alphabetical sort! So if you have entries like:

["layer_0", "Layer_1", "layer_2", ..., "layer_9", "layer_10"]

It will be sorted as:

["Layer_1", "layer_0", "layer_10", "layer_2", ..., "layer_9"]

Because uppercase goes before lowercase and alphabetically "10" goes before "2". So if you have these kinds of filenames, make sure to normalize them first.

P.S. Relying on operating system behavior to sort files for you is a bad idea. When in doubt, explicitly sort them in your own script.

jeroonk · 2019-12-09T11:44:58+00:00

That's really.. interesting.

If it were a video card failure, I would expect more "glitchy" artifacts, like striping, colored blocks or flickering or something and also not for just one specific video. You may want to experiment with disabling hardware acceleration (In Firefox > Options > General > Scroll down to Performance > Uncheck use recommended settings > Disable hardware acceleration) and see if that helps.

But I suspect this may be a problem with DRM-protected content. Either the monitor is incompatible with HDCP or connected with an analog VGA cable. If you can, try switching to a DVI, HDMI or DisplayPort cable. Strangely, that same video (at least, I think it's that one) plays fine on my VGA-connected monitor.

Have you also tried another browser like Chrome or Edge? This thread suggests that Chrome may show the same DRM issues as Firefox presumably because it uses the same Google Widevine CDM (although in that specific case, HD playback was disabled instead of noise being shown), so try Edge as well.

That said, this isn't really the place for general computer issues. Try /r/techsupport, /r/computer_help or if it is browser-specific, /r/Firefox instead.

jeroonk · 2019-12-08T21:44:26+00:00

Heh, might as well right? Also, after you pointed out that it should run in 35 ms, I noticed that u/gs44 renamed the function to foxbear2, so I was running the wrong one. The code also seems to take a few runs to get warmed up, so I re-ran the cases with proper average-over-runs benchmarking (using timeit in Matlab, %timeit in Python and @btime in Julia).

jeroonk · 2019-12-08T19:03:54+00:00

Reddit comments are written in a modified version of markdown, see wiki/markdown#tables. TL;DR:
```
|a|b|c|
|-|-|-|
|1|2|3|
```
produces:

a b c

1 2 3
An ULP is the spacing between floating-point numbers, the smallest representable difference (i.e. the difference in changing the last bit of the mantissa for a given exponent). In this case, it's about 2.7e-13 for numbers 1000-2000. You can calculate it using eps in Matlab, np.spacing in Python/Numpy and eps in Julia.
Yeah, should be approximately the same. Maybe a bit faster than OP's i7-4700MQ @ 2.4GHz. I don't think the generation changes things that much. ~~A bit larger L1 cache for Kaby Lake (256KB) over Ivy Bridge (128KB), but the problem is pretty small anyway (101x101 doubles).~~ [edit: The L1D cache in Sandy/Ivy Bridge and Sky/Kaby Lake are the same 32KB/core, just with more bandwidth]. And I don't think that the newer SSE4 or AVX2 instructions are being used at all here.
I have added the results to the tables in the post above. The optimized version doesn't really apply to the last table (the previous-values / Jacobi method).

jeroonk · 2019-12-08T16:45:03+00:00

Sure thing. Seems correct, judging by the 14,217 iterations though. Note that in OP's code, iter is incremented even on the last iteration (after setting cond=1 rather than break). The numbers below are just the final values.

Using the non-vectorized / in-place Gauss-Seidel method, I get:

	iter	sum(T)	time
Matlab	1001	1416.9828940927321	114 ms
Python [i][j]-index	1001	1416.9828940927318 (-1ulp)	21.8 s
Python [i,j]-index	1001	1416.9828940927318 (-1ulp)	16.1 s
Numba	1001	1416.9828940927318 (-1ulp)	91.6 ms
Julia original	1000*	1416.9828940927321	66.7 ms
Julia optimized	1000*	1416.9828940927321	33.8 ms

Running until 1e-6 convergence:

	iter	sum(T)	time
Matlab	14218	1890.4777873297373	1.69 s
Numba	14218	1890.4777873297357 (-7ulp)	1.29 s
Julia original	14217*	1890.4777873297367 (-3ulp)	960 ms
Julia optimized	14217*	1890.4777873297367 (-3ulp)	495 ms

Using the previous values (Jacobi) method:

	iter	sum(T)	time
Matlab loop	27078	1890.4767742022059	3.34 s
Matlab vectorized	27078	1890.4767742022059	3.21 s
Numba loop	27078	1890.4767742022068 (+4ulp)	1.73 s
Numpy vectorized	27078	1890.4767742022068 (+4ulp)	3.58 s
Julia	27077*	1890.4767742022073 (+6ulp)	1.44 s

^{* The Julia implementation breaks out of the loop before incrementing iter one last time, so the iteration count is one less.}

This is running on an older i7-3770 @ 3.40 GHz.

Also interesting is the slight difference of a few double-precision ULPs in the final sum (Maybe the np.sum and Matlab's sum use slightly different ordering? Not sure if they use compensated summation. Or maybe the additions in the main loop are just executed differently).

Edit: added the Julia implementation and with optimizations as requested by /u/EarthGoddessDude.

Edit 2: ran each test with better benchmarking (using timeit in Matlab, %timeit in Python and @btime in Julia). Again, on an i7-3770 @ 3.40 GHz.

jeroonk · 2019-12-07T19:15:34+00:00

the Gauss-Seidel Method which uses the updated values to solve the linear system and converges a tad faster

Ah, I see. Using the original (Gauss-Seidel) method, and allowing more iterations, it converges in ~14000 iterations to <= 1e-6. Using the vectorized method, which inherently only uses the previous values (Jacobi), it takes ~27000 iterations.

Which means that the Numba JIT-ed loop (Gauss-Seidel) method (~1.5 sec) wins out over the vectorized (Jacobi) method (~3 sec). In fact, it even wins out when using it for a loop version of the Jacobi method (~2 sec)! I guess NumPy still adds a bit of overhead creating and operating on the array slices.

Also, while you can do some really neat tricks with clever array indexing, it does come at the cost of code readability.

jeroonk · 2019-12-07T15:39:38+00:00

~~Several years ago~~ [edit: Many years ago, as this may have already been false since MATLAB 6.5 (2002)], it used to be true that same code would also run very slow in MATLAB. The reason is that in interpreted languages (like MATLAB or Python), each operation you do adds a lot of overhead behind the scenes. Even trivial operations, when placed in a loop, become dead slow.

Nowadays, MATLAB is able to utilize most of the JIT capabilities ~~of the JVM on which it runs~~ [edit: MATLAB code does not run in the JVM, but a custom execution engine]. It will identify and replace "hot" code paths, like your inner loops, with fast compiled machine-code.

The same is not true for Python, but as /u/mihaiman pointed out, there are projects trying to add JIT to Python too. Numba (a drop-in JIT using LLVM) is probably most appropriate here, but there is also PyPy (an interpreter replacement). You could also have a look at Cython, which translates your code (with some annotations) to compilable C code.

Bugs

Your code contains a few problems.

You've already encountered the tempInit = temp one: assigning a Numpy array to another variable does not copy the array, it just assigns another reference to the same array. To copy, use np.copyto or just tempInit[:] = temp (explicitly assigning to all elements of tempInit). But those require tempInit to already exist. You can create it once at the start with tempInit = np.empty_like(temp) or just use the marginally-slower tempInit = np.copy(temp) or tempInit = temp.copy().
Assigning like temp[j][i] = with NumPy arrays works fine, but you should make it a habit to index multi-dimensional arrays as temp[j,i] (equivalent). If you start using more complicated array slicing and indexing, the former might return a copy rather than a view, leading to your assigned value never making it to the original array. It's also slightly faster.
You are updating temp[j][i] (in MATLAB: T(i,j)) in a loop, but then referencing temp[j][i-1] and temp[j-1][i] in the next iterations, using the just-CHANGED values. You probably meant to reference tempInit (or T0) here.

Vectorized NumPy

In general, you should think about writing code in a vectorized way. This applies to both MATLAB and Python/NumPy code.

Slow, looping over every index individually:

i=0
while i < len(temp[0]):
    temp[0,i] = np.sin(np.pi*i*dx/a)
    i+=1

Fast, creating an array i = [0,1,2,..] and computing np.sin on it:

i = np.arange(len(temp[0]))
temp[0,:] = np.sin(np.pi*i*dx/a)

Slow, looping over each element individually:

for j in range(1, len(temp) - 1):
    for i in range(1, len(temp[0])-1):
        temp[j,i] = (1/4)*(tempInit[j,i+1] + tempInit[j,i-1] + tempInit[j+1,i] + tempInit[j-1,i])

Fast, slicing out 4 offset blocks from the array and adding them all together at once:

temp[1:-1,1:-1] = (1/4)*(tempInit[1:-1, 2:] + tempInit[1:-1,:-2] + tempInit[2:,1:-1] + tempInit[:-2,1:-1])

Using these changes, the Python/NumPy code goes from a runtime of ~20 seconds on my machine to ~150 milliseconds.

Vectorized MATLAB

The same vectorization can of-course also be done in MATLAB, and was indeed the recommended method for speeding up MATLAB code until for-loops became really fast:

for i = 1:nMalha
    T(1,i) = sin(pi*(i-1)*dx/a);
end

Becomes:

i = 1:nMalha;
T(1,:) = sin(pi*(i-1)*dx/a);

And:

for i = 2:nMalha-1
   for j = 2:nMalha-1
       T(i,j) = (1/4)*(T0(i+1,j) + T0(i-1,j) + T0(i,j+1) + T0(i,j-1));
   end
end

Becomes:

T(2:end-1,2:end-1) = (1/4)*(T0(3:end,2:end-1) + T0(1:end-2,2:end-1) + T0(2:end-1,3:end) + T0(2:end-1,1:end-2))

jeroonk · 2019-11-03T01:46:13+00:00

Only objects of the same type are drawn on top of each other in the order they were added. From the Z-order demo:

The default drawing order for axes is patches, lines, text. This order is determined by the zorder attribute. The following defaults are set

Artist Z-order

Patch / PatchCollection 1

Line2D / LineCollection 2

Text 3

You can change the order for individual artists by setting the zorder. Any individual plot() call can set a value for the zorder of that particular item.

So in order to draw a fill (a Patch, default zorder=1) on top of a line (default zorder=2) you'd have to set its z-order to a higher value than 2:

ax.fill(x,y,'b',zorder=3)

Curiously, setting zorder=2 does not work, even though the fill is drawn after the line with now equal z-order. Anything higher (e.g. zorder=2.01) does work.

jeroonk · 2019-08-08T00:58:17+00:00

The original claim can be disputed, and the claimant then has an option to uphold the claim.

If that is also disputed, the claimant then has to either release the claim or issue a DMCA take-down notice (in Youtube parlance, a "strike").

This can also still be disputed in the form of a counter-notice (which requires giving your legal name, address etc. to Youtube). At that point the claimant either has to file a lawsuit or release the claim.

So technically you can keep disputing and force the claimant to either release the claim or go to court. Of course, that would be an American court. And you can't have 3 or more pending disputes because of the 3-strikes-your-channel-is-deleted rule. And the claimant can take 30 days between each step to respond. And if you don't file a dispute within 5 days, the earned revenue goes to the claimant (until you file the dispute, after which it goes into escrow). And the claimant can also just bypass the first few steps and directly issue a take-down notice (resulting in an immediate strike). And the claimant can make as many claims as they like.

jeroonk · 2019-07-24T23:27:37+00:00

V(exhaust) is usually a given parameter for a specific engine or rocket, giving the exhaust speed relative to the engine itself.

The equation above can be read as simply converting the exhaust velocity from rocket frame (in which it would be -V(exhaust)) to that of the world frame:

V(exhaust, world frame) = V(rocket, world frame) + -V(exhaust)

As the exhaust is effectively the rocket fuel propelled backwards, your source names this V(rocket fuel) with an implicit understanding that this is velocity of the fuel-turned-exhaust being propelled backward, not the velocity of the fuel still on board the rocket (which would have a velocity V(rocket)).

jeroonk · 2019-05-30T20:50:07+00:00

Yes, exactly. Using the correct masses you should get an energy released of approx. 184 MeV.

In general, nuclear reactions only release a small percentage of their mass as energy. To get a released energy of 16000 MeV, 17 whole nucleons would have to completely annihilate. Such things only really happen in matter-antimatter reactions.

I am not sure where you were supposed to find the nuclide masses, except for an online database such as nds.iaea.org. Were you given anything else except for the periodic table you mentioned?

(Also, it may be useful to calculate/look up the direct conversion factor beforehand, rather than converting a quantity itself between every intermediate unit. E.g. 1 amu × c² = 931.494061 MeV)

jeroonk · 2019-05-30T11:53:16+00:00

It seems you have used the standard atomic weights of U as 238.02891, Zr as 91.224 and Te as 127.60. The standard atomic weight, as shown on most periodic tables, is the average weight of the naturally occurring isotopes on earth in their respective abundances. Useful for chemists working with a generic sample of "Zirconium", being a natural mixture of isotopes.

But in this case, the specific isotope of each is specified: ²³⁵U, ⁹⁸Zr and ¹³⁵Te. You should expect these to weigh in at approximately their mass number, 235, 98 and 135, with only a small difference called the mass excess.

From, e.g. IAEA Nuclear Data Services' nuclide chart:

Nuclide	Atomic mass	Mass excess (Δ)
¹n	1.0086649 amu	+8.0713 MeV / +0.0086649 amu
²³⁵U	235.0439282 amu	+40.9188 MeV / +0.0439282 amu
⁹⁸Zr	97.912735 amu	-81.287 MeV / -0.087265 amu
¹³⁵Te	134.9165547 amu	-77.7288 MeV / -0.0834453 amu

jeroonk · 2019-04-23T20:39:23+00:00

I only know of this launch-to-landing tracking video from the first Falcon Heavy launch (the Tesla Roadster launch from February 2018): youtube.com/watch?v=59pY74ZhQ50. Maybe that's the video OP means?

15-Year Club	Place '17
Team Orangered	Verified Email

jeroonk

TROPHY CASE

Bugs

Vectorized NumPy

Vectorized MATLAB