dtm: (Default)

It's somehow been in the air in a few different math places I visit online what the sum of:

1 1 3 + 1 5 1 7 + 1 9 +

and

1214+1618+110+

are. Among other things, these series come up when working out the probability that with randomly chosen values for x and y in the range (0, 1) whether floor(x/y) is even or odd, or whether round(x/y) is even or odd.

Now, these are very well known series and the quite well-known answer to these are:

113+1517+19+=π41214+1618+110+=12ln(2)

The usual way that I've seen to solve the first of these (11/3+1/5+) involves showing somehow that it's the Taylor series for arctan(x) evaluated at x=1; this can be justified in detail or presented “out of thin air”. The usual way to solve the second of those involves rewriting it as:

12n=1(1)nn

and then working that out. For some reason these two series are approached completely separately as though the solution for one has absolutely nothing to do with the other, even though the series are obviously closely related. (I'll grant that the answers, at least for now, look completely unrelated)

Anyway, I stumbled on a way of looking at these series that makes it obvious how the two series above are related, and that as far as I can tell easily extends to the much more general case of:

n = 0 ( 1 ) n h n + k , h + , k { 1 , 2 , . . . , h } More math than you probably wanted to read today )
dtm: (Default)
So I guess I'm going to try things here again, now that cohost is shutting down.

I'm not sure I will use it for much, but I do think I'll probably soon be archiving and/or hiding most entries older than about 10 years, mostly because my kid doesn't need to be able to find those entries, and if he somehow wants them he can ask me about them.

Anyway though, for a first entry, here's something I'm pulling over from cohost:


A puzzle I made


So, I made a puzzle as a bit of a tribute to my dad. I have verified that solving the puzzle is possible in the sense that "if you know what went into constructing this but not the answer, it is possible to derive the answer" but of course that's no guarantee that people who are not me will naturally look at it and say "ah, these are the tools I need to wield to attack this".

Solving the puzzle requires Math, but getting to where you can figure out which Math to use first requires reading x86 assembly language. So first of, if either of those things strikes you as Intensely Not Fun, this isn't for you.

Hard-mode puzzle, and link to slightly less-hard-mode )
Why this puzzle )
dtm: (Default)

Okay, I've gone and deleted my livejournal. I don't know if I'm going to resume blogging, but if I do it'll be here and not there.

In the meantime, here's a cute little result about the sum of Fibonacci numbers that I worked out while answering a question from a friend's child:

j = 0 n F j = F n + 2

(In case the MathML doesn't work for you, that's \sum_{j=0}^n F_j = F_{n+2})

(Using the convention that F0=0 and F1=F2=1)

dtm: (Default)
So here's a bit of a geeky post, but not so terribly geeky that I'm hiding the bulk behind a cut link.

"true" and "false" are simple concepts, right? Different programming languages seem to have hugely different ideas of what they are:

In C, 0 is false, any other integer is true, and the coercion rules make a null pointer false, and any other pointer true. Anything else is a compile error.

C++ follows (inherits?) the C rule, and adds true and false as things that are true and false.

In shell, 0 is a true exit value; any other exit value is false. Inside [ ], empty strings are false and other strings (such as "0" or "1") are true.

In Python, 0, 0.0, -0.0, False, None, the empty string, empty tuples, lists, and dicts are all false. Anything else (such as the string '0') is true. (A note on 0.0 vs -0.0: they're both == according to python, and both false, but print differently. One can be turned into the other by multiplying by -1)

In Perl, 0, the empty string, and undef are false, and since evaluation as a boolean imposes scalar context, an empty array or hash variable is also false. Anything else (including arrayref or hashref values to empty structures) is true. Note that because perl helpfully autoconverts like a $SOME_NOUN_HERE, the string "0" and 0.0 are to perl identical to 0, and therefore false. (hence the Perl idiom "0 but true") A full discussion of the quirks of perl around various representations of zero could probably fill a small book, but I'll note that other consequences are that the expression -0 is true, but -0.0 is false.

In Ruby, false and nil are false, anything else (including 0, the empty string, and an empty Array or Hash) is true.

In Javascript, 0, null, undefined, the empty string, false and NaN are false. Anything else (such as an empty Array, or empty Object) is true.

In Java, (since the autoboxing introduced in Java 1.5) true and Boolean.TRUE are true, false and Boolean.FALSE are false, ((Boolean) null) is a runtime exception, and anything else is a compile error.

In Haskell, True is true, False is false, and anything else is a compile error.

Google Go behaves like Java 1.4 or Haskell - true is true, false is false and anything else is a compile error.

Scala appears to behave the same way - true is true and false is false. Anything else (including an instance of RichBoolean, or of java.lang.Boolean) is a compile error.

In Common Lisp, nil, aka the empty list, is false. Anything else - including 0, the empty string or empty vectors of other types - is true.
dtm: (Default)

So listening to NPR is really depressing this morning - not shocking, like it was a year ago, just sad.

I was looking at something I put up about a year ago (on the 12th), and I realized that it probably doesn't mean anything to anyone but me, but I'll repeat it here anyway.

First, though, a bit of explanation: one of our machines at work gets data from Reuters; this data is coming in all the time throughout the day, and at one point an automatic process at Reuters' data center would log in to our system and send data pretty much once every five minutes or more. Anyway, here's what I found in the logs when I looked on the 12th:

# pwd
/var/log/ncftpd
# ls -t xfer* | head -1 | xargs tail -1 | cut -c 1-20
2001-09-11 09:06:17

Translation: in the ftp logs, from the most recent log, from the last entry, the last timestamp was 2001-09-11 09:06:17. After that, nothing.

I then checked the possibilities of pulling the data from reuters instead of having them push it to us:

# ftp datascope.reuters.com
ftp: connect: No route to host
ftp>

That's a bit of an understatement; Reuters had during August moved their data center to their offices in the world trade center.

September 2025

S M T W T F S
  123456
78910111213
14151617181920
21222324252627
282930    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 28th, 2026 01:45 pm
Powered by Dreamwidth Studios