Live data from Hacker News

The Lost Art of Logarithms

lostartoflogarithms.com

71–80 of 204 posts

Re: The Lost Art of Logarithms

#71
post #24

Here's an logarithmic fact that I've made use of frequently: If X is a random variable having a uniform distribution between zero and one, then –ln( X )/ λ has an exponential distribution with rate λ . This relationship comes in handy when, for example, you want to draw weighted random samples. Or generating event times for simulations.

How long do I have to study math to understand this?

Not long. We were taught logs, and use of log tables, at Middle School. So probably around about age 11.

I also vaguely recall a couple of lessons where we went over Napier's Bones, and they had us produce equivalents on pieces of paper to cut out and move around.

I believe I still have my school day log tables around somewhere. I'd just have to practice for 1/2 hr to remind myself how to use them. That said, they did have usage instructions in the last few pages.

Re: The Lost Art of Logarithms

#72
post #2

I started using LMAX Disruptor for some projects. One quirk with Disruptor is that the queue size always has to be an exponent of two. I wanted to make sure that I always have at least enough room for any size and I didn't want to manually compute, so I wrote this: var actualSize = Double.valueOf(Math.pow(2, Math.ceil(Math.log(approxSize) / Math.log(2)))).intValue(); A bit much for a single line, but just using some…

This is perfectly usable, of course, but I’d write var actualSize = Integer.highestOneBit(approxSize - 1) purely to avoid involving the horrors that live beneath the humble pow() and log(). (Integer.highestOneBit, also known as “isolate leftmost bit”, “most significant one”, or the like, essentially has to be a primitive to be efficient, unlike its counterpart for the lowest bit, x&-x. The actual CPU instruction is u…

The above gives an incorrect result for approxSize = 1 (namely 0). The following works (for values up to 2^30, of course):

    var actualSize = Integer.MIN_VALUE >>> Integer.numberOfLeadingZeros(approxSize - 1) - 1;
Or, if you want 0 to map to 0 instead of to 1:

    var actualSize = Integer.signum(approxSize) * Integer.MIN_VALUE >>> Integer.numberOfLeadingZeros(approxSize - 1) - 1;
Of course, you could also use a variation of:

    var actualSize = Math.min(1, Math.Integer.highestOneBit(approxSize - 1) 

Re: The Lost Art of Logarithms

#73
post #65

Earlier quoted context omitted.

I guess you have to define what you mean by "conceive". I'm not sure you can even conceive a number like 1,000, if you're talking about holding an intuitive visual understanding in your mind at once. Like, I can easily see 100 in my mind's eye as a 10x10 grid of circles. Even if I don't see each one clearly, I have a good sense of the 10 on each edge and the way it fills in. But ask me to imagine 10 of those side-by-…

My first cut at conceiving is to answer "how long would it take a really fast computer to count to that number". The answer for 10^4000 is still something like 10^3978 years. So, a still inconceivable time. (100 tera-ops computer) [edited to correct calculation)

But the length of time it takes a modern computer to count to 10 or 1,000 is perhaps inconceivably small by your metric, no? Your idea arbitrarily selects numbers around 2 billion as being conceivable, at least for a single core on my MacBook.

But my question isn't what makes 10^4000 inconceivable -- my question is what makes 10^4000 any less conceivable than 1000. To me, they're both firmly in the realm of abstractions we can reason about using the same types of mathematical methods. They're both qualitatively different from numbers like 5 or 10 which are undoubtedly "conceivable".

Re: The Lost Art of Logarithms

#74

I found that looking at the original motivation of logarithms has been more elucidating than the way the topic is presented in grade-school. Thinking through the functional form that can solve the multiplication problem that Napier was facing (how to simplify multiplying large astronomical observations), f(ab) = f(a) + f(b), and why that leads to a unique family of functions, resonates a lot better with me for why lo…

We used logarithms routinely for large multiplications, divisions, etc. in 11th and 12th grade. No calculators were allowed. This was in India.

Re: The Lost Art of Logarithms

#75

I found that looking at the original motivation of logarithms has been more elucidating than the way the topic is presented in grade-school. Thinking through the functional form that can solve the multiplication problem that Napier was facing (how to simplify multiplying large astronomical observations), f(ab) = f(a) + f(b), and why that leads to a unique family of functions, resonates a lot better with me for why lo…

I actually prefer the straightforward log is an inverse of exponents. It's more intuitive that way because I automatically can understand 10^2 * 10^3 = 10^5. Hence if you are using log tables, addition makes sense. I didn't need an essay to explain that.

Take logs, add 2 + 3 = 5 and then raise it back to get 10^5.

Re: The Lost Art of Logarithms

#76
post #71
post #24

Earlier quoted context omitted.

How long do I have to study math to understand this?

Not long. We were taught logs, and use of log tables, at Middle School. So probably around about age 11. I also vaguely recall a couple of lessons where we went over Napier's Bones, and they had us produce equivalents on pieces of paper to cut out and move around. I believe I still have my school day log tables around somewhere. I'd just have to practice for 1/2 hr to remind myself how to use them. That said, they di…

Look im 30, most people I know have forgotten all of school math long ago, me included. Entry barrier too big now.

Re: The Lost Art of Logarithms

#77

Earlier quoted context omitted.

Unless I'm missing something, this can just be directly verified, no “understanding” necessary. All you need to know is that probability distributions can be characterized by their probability density function (PDF). If Y=-ln(X)/lambda, then P(Y exp(-lambda a)) = 1-exp(-lambda a). And if Z is exponential with rate parameter lambda, then P(Z They have the same PDF, so they're the same distribution.

I mean if starting from scratch that seems like many years in most western education systems to get to probability, logarithms, exponentiation. I would say If you knew 2+2=4, and not much else you're years away from 'understanding', if you know ln(exp(y)) = y, and P(x>0.5) = 0.5 for a uniform distribution on [0, 1) then you don't need any additional understanding. I would bet the GP comment is somewhere inbetween the…

Yea got many answers and I dont understand a single one. Good thing you barely need math in programming.

Re: The Lost Art of Logarithms

#78
post #65

Earlier quoted context omitted.

My first cut at conceiving is to answer "how long would it take a really fast computer to count to that number". The answer for 10^4000 is still something like 10^3978 years. So, a still inconceivable time. (100 tera-ops computer) [edited to correct calculation)

But the length of time it takes a modern computer to count to 10 or 1,000 is perhaps inconceivably small by your metric, no? Your idea arbitrarily selects numbers around 2 billion as being conceivable, at least for a single core on my MacBook. But my question isn't what makes 10^4000 inconceivable -- my question is what makes 10^4000 any less conceivable than 1000. To me, they're both firmly in the realm of abstracti…

the length of time it takes a modern computer to count to 10 or 1,000 is perhaps inconceivably small by your metric

But I'd just call it "instantaneous" and something I experience frequently. Whereas 10^3978 years is beyond experience and even imagination.

Re: The Lost Art of Logarithms

#79
post #24

Here's an logarithmic fact that I've made use of frequently: If X is a random variable having a uniform distribution between zero and one, then –ln( X )/ λ has an exponential distribution with rate λ . This relationship comes in handy when, for example, you want to draw weighted random samples. Or generating event times for simulations.

How long do I have to study math to understand this?

All you need is plot -log(x) for x between 0 and 1 and you will see that log(x) transforms a uniform line into an exponential decay (towards 1). Its being said in a fancy way. This is also the origin of the log likelihood loss function in ML

Re: The Lost Art of Logarithms

#80
post #66

Interesting insight why applying a log transform often makes data normally distributed: Pretty much all laws of nature are multiplications (F=m a, P V=n R T, etc). If you start with i.i.d random variables and multiply them, you get log-normal data by virtue of the central limit theorem (because multiplications are additions on a log scale; and the CLT is also somewhat robust to non iid-ness). Thinking of data as the…

All data is linear when plotted on a loglog scale with a thick marker.

But in my explanation, there is no x axis.
Post reply on HN