now, if you want to measure things in special or general relativity you introduce time as a coordinate with a different metric signature. then the total spacetime "volume form" has dimensions of volume times time.
On the topic of volume, though, its important to note that its very possible to change shape without changing volume. This is what every incompressible fluid does when it moves around, and is also the type of deformation described by a "pure shear" of some solid body. It's important not to confused the derivative of the volume (dV/dt, a single number) with the total set of derivatives of the individual material elements (the set {dX_i/dt} of the derivative of each displacement vector X in each direction i, d*N numbers where d is the spatial dimension and N is the number of material elements in the solid).
sorry, i am immediately thinking of the teaching nightmare having the name of the concept and the name of one of the the units for the concept being the same!
edit: i am mad about the volts thing - having volts as a unit, and having "voltage" used as a catch all to refer to p.d./e.m.f. is tough to deal with
Edited by tears ()
| Nova Nomo |
| Energio |
| Potenco |
| Forto |
| Metro |
| Litro |
| Gram |
| Dua |
| Temp |
| Lumen |
| Stango |
| Premo |
| Turnu |
| eFluo |
| ePremo |
| Om |
| eMole |
| Mole |
| Persekundo |
| ? |
| ? |
| Zum |
if you were simplifying units surely the first thing you would do is to strip out stuff like pascals and bar all together and just express it as N/m2 or MN/m2. it would help with understanding - same for watts as J/s
i dont understand why you would rename kilogram to gram when there is already a quantity of mass called a gram - i could understand if you wanted to switch the SI unit of mass to the quantity denoted by a gram - that would be cool, since the use of the kg is just some historical quirk. then kilogram would just be the unit + the prefix like everything else
i dont like the term electron pressure to refer to p.d. because it brings in all sorts of misconceptions - electricity is one of the hardest things to teach and i have used plenty of water flow metaphors, but they tend to come back and bite you - since volts are just joules per coulomb i think that is a far better way to unit it - since it is very descriptive as energy per packet of charge -> i also find it helps with visulisation in terms of energy transfer. The problem does build with this since converting derived units back to SI units is pretty hard when you get to things like ohms - V/A, which would then be (J/C)/A or J/(A2 x s) or whatever which quickly gets complicated - expressing units in terms of other units and back to SI units tends to get left to A-level physics here
i also dont like the term eFlow for rate of flow of charge, just because it uses an e, which tends to get associated with electrons, and charge flow is charge flow not necessarily electron flow - i know that e is used for elementary charge but theres a big difference between teaching elementary charge at A-level and teaching flow of charge to 12 year olds who cant write good.
i can see problems with relating quantity of charge to moles in the eMole for coulombs and moles for amount, unless you were to redefine one or the other so that the mole part refereed to the same number of particles and elementary charge multiples - which you could do - it would be quite nice to standardise
im not against renaming units, i just think that ease of learning is paramount
please advise on how to build a no-kill mouse trap. the mice have outsmarted all my attempts so far. they are cute but are becoming overly confident and comfortable. preferably construction plans only use household items, no cnc here.
thanks in advance.
Gssh posted:dear math thread posters,
please advise on how to build a no-kill mouse trap. the mice have outsmarted all my attempts so far. they are cute but are becoming overly confident and comfortable. preferably construction plans only use household items, no cnc here.
thanks in advance.
mice are notoriously bad at maths, so if you write some simple algebra on a piece of paper in a box the mouse will feel compelled to go into the box and try to solve it, which will take him hours.
there are some minor optimizations you could make to your code. my intuition says not to allocate vectors as frequently and avoid clever math tricks that feel good but probably don't translate well to code (like the dot product thing for summing the vector's elements!). you could also translate this code into a language that uses your CPU's native floating point arithmetic instead of using the arbitrary precision decimal numbers that i assume scad uses by default... but 64-bit floating point numbers are only large enough to calculate like 100 rows of this calculation before running out of precision.
anyway all this is small potatoes because you'll only be reducing the coefficient of your time function (e.g. 4n^2 vs. n^2). those sorts of gains are overshadowed infinitesimally by n^2 as n gets real big. so if you want major speed improvement you'll need to exploit some sort of other identity.. probably something related to summing reciprocals. if you were calculating just the sum of the sums of each row in the triangle, you could just use the triangle's identity sum(n)=2^n to reduce the algorithmic complexity down from O(n^2) to just O(n)! but obviously you need to sum reciprocals of elements not just the elements... idk!
e: (i think amazon ec2 also has micro instances that might be better for your use-case that are just.. free -- but i'm unsure about that works)
Edited by aerdil ()
nice proof!! i'm not familiar with sum(1/(n,k)) = 1 + 1/n.
i made my way through most of the exercises in book of proof last summer and that stuff is really rewarding. also rewarding are the exercises on project euler, if you're not familiar with that site and are looking for more coding practice
import numpy as np
def sumtworows(hardstop):
thesum = (1/6+1/5)
uprow = [5, 10]
while hardstop != 0:
k = len(uprow) - 2
midodd = 2 * uprow[k+1]
oddrow = [uprow[0]+1]
for n in range(k + 1):
oddrow.append(uprow[n] + uprow[n + 1])
oddrow.append(midodd)
evnrow = [oddrow[0]+1]
for n in range(k + 2):
evnrow.append(oddrow[n] + oddrow [n + 1])
which = [i for i in range(1, k+3)]
oddsum = 2 * sum([1 / oddrow[i] for i in which]) * np.prod([1 for i in which])
evnsum = 2 * sum([1 / evnrow[i] for i in which]) * np.prod([1 for i in which])
uprow = evnrow
thesum = oddsum - 1/midodd + evnsum + thesum
hardstop = hardstop - 1
return thesum
hardstop = int(input("Enter a hardstop value to calculate to: "))
print (sumtworows(hardstop))
Edited by aerdil ()
A. Bill, do you think you've found yourself?
B. What?
A. I mean -here we are on the edge of the Indian Ocean, miles away from civilization. It's been months since we ran off to avoid getting swept up in the system, and "to find ourselves." I'm just wondering if you think we've done it.
B. Actually, Alice, I've been thinking about the same thing. These past months together have been really great-we're completely free, we know each other, and we feel like real people again instead of like machines. But lately I'm afraid I've been missing some of the things we've "escaped" from. You know, I've got this fantastic craving for a book to read - any book, even a textbook, even a math textbook. It sounds crazy, but I've been lying here wishing I had a crossword puzzle to work on.
A. Oh, c'mon, not a crossword puzzle; that's what your parents like to do
this line cut too close. i never got good at crossword. RIP Conway, a lovely man. fuck this corona shit
http://people.math.harvard.edu/~knill/teaching/mathe320_2015_fall/blog15/surreal1.pdf
toyot posted:sum(1/(n,k)) = 1 + 1/n, for 0 < k < n
i dont think this is true? try n = 3: then you have 1/(3,0)+1/(3,1)+1/(3,2)+1/(3,3) = 1+1/3+1/3+1 = 8/3 != 1+1/3