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 I've thought about several different journal entries I could write lately, but I somehow just don't feel I have the requisite will-to-type to write any of them. So here are some scattered thoughts I'm not journaling about:

dtm: (Default)
And now for something totally geeky. Of interest only to those programmers whose programming interests encompass both java generics and functional languages that tend to represent lists as singly linked lists most of the time. This is just kind of wandering about, with no coherent theme or conclusion to the post.
(Haskell-style lists in java, with generic type safeness) )

Update: figured out a better way to do append in the ? extends E model.
dtm: (Default)
So one thing I discovered as I went back over my old posts is that I used to do some serious computer geeking in my posts. I mean, seriously.

And I haven't done any computer geeking on livejournal in a while, so:
The insanity that is the jvm's shutdown sequence )
dtm: (Default)
So let's suppose you have a Java double (or float) and you want to come up with a string that represents the double/float in decimal but, and here's the kicker, you want the shortest string that'll adequately represent the number. For example, if you have the float corresponding to 0.85, when printing it out you might get:
0.8500000238418579
Not what you want (to get that in java you have to cast the float to a double, but you can get slightly less ugly artifacts simply by producing the float out of a long calculation - accumulated roundoff and whatnot).

What if you want to say "give me the shortest decimal assuming that this double's mantissa is only accurate to 20 bits"? (a java double has 23 bits in the mantissa)

Now suppose you want to do this in a tight loop where speed is critical. (otherwise, it wouldn't be much fun, would it?)

I've got vague references to stopping conditions using only integer arithmetic in this paper from 1992, but it's hard to clear though what the other stuff they say to get to what I want. Also, most of the paper assumes that the reader is fully aware of the contents of a presentation made at some ACM SIG* conference in 1990. Not too helpful, so I may just end up working it out on my own.

May 2017

S M T W T F S
 123456
78910111213
14151617181920
212223242526 27
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 24th, 2017 12:50 pm
Powered by Dreamwidth Studios