This page aggregates together stuff having to do with Joey from elsewhere on the net.
Checking git commit signatures can detect a collision attack. Of course, that checking is also not enabled by default, and there's not yet a config to change that.
I am kind of surprised also today to see pigdog.org on the top of HN.
Yeah, that's a red alert if the two are casually connected. In this case it's too little sleep due to reading an excellent book and stuff and locking/concurrency problem noticed due to if anything, being in an unusually open frame of mind. So not a bad casual connection.
Cooked gumbo for the first time, and while the 1st roux failed miserably, I got there in the end. Soo rich dark and good!
author: Kim Stanley Robinson
average rating: 3.78
book published: 2015
date added: 2015/10/04
Evening wander to the riverfront; stumbled into VindaLou. Ate all the amazing street food things I could get to in the crush of bodies, and watched the fancy dances and happy folks.
Millennium Falcon drone tried to hard-crash my laptop, but my physical IDS got in the way #derbycon
IIRC something to do with a library it's linked to. I'd check but.. the ootool to list linked libraries requires same license agreement.
Agreeing to the Xcode/iOS license requires admin privileges, please re-run as root via sudo.
I think maybe I can go from my haskell DSL to a linux exe that only contains MOV #derbycon
Lunch with @textfiles, and now a talk about a C compiler that uses only MOV instructions #DerbyCon
Just 4 hours drive from home, in a direction rarely taken..
Seeking firefox plugin to replace default new tab page with a tag-cloud style display of page titles scaled by usage amount
Now I'm pondering using http://hackage.haskell.org/package/accelerate to implement hardware-accellerated rational arrays..
oops, I somehow pasted that as 1%1 + 1000000 where my actual benchmark was 1%1 + 1000000
3d games use floating point for speed, but could rational numbers be fast enough? After some benchmarking I think maybe so. Might be worth it in a game that involves many scales and/or vast distances.
I benchmarked ratios of Integers vs floats in haskell. Haskell's Ratio type is pretty optimised, and it supports unbounded Integers via gmp. Ratio Int is faster, but let's go all the way and have the positions of objects in the game support completely arbitrarily large/small numbers with no loss of precision.
Benchmark says: Adding and dividing are 25x slower. Comparing equality is only 3x slower, while comparing less-than is 5x slower. Take these numbers with some salt; very large/complicated values in ratios will use progressively more cpu time (and memory, for really big Integers!) Doesn't seem too horribly bad anyway.
Presumably at some point the Ratio Integer needs to be converted to a Float to be fed to graphics hardware to display the object. That takes 553 ns. But, you probably want to offset it first (ie, relative to camera position), so let's say 760 ns. Assuming you're doing that 60 times per second, with 1000 3d points in view, this conversion would use 12% of the total CPU.
So, if the points you want to represent with perfect precision are relatively small in number, say the centers of not too many objects, I think this could be perhaps a viable approach. Although this is not my area.. I mostly just want to see a game that scales from very large to very small to very distant without strange bugs from floating point errors.
import Data.Ratio import Criterion import Criterion.Main main = defaultMain [ bgroup "add1" [ bench "rational" $ whnf (r1 +) r1 , bench "rational converted to frac" $ whnf (\v -> realToFrac (r1 + v)) r1 , bench "float" $ whnf (1.0 +) 1.0 ] , bgroup "div3" [ bench "rational" $ whnf (r1 /) r3 , bench "float" $ whnf (1.0 /) 3 ] , bgroup "cmp" [ bench "rational" $ whnf (\(a,b) -> r1 == a || r1 == b) (r3, r1) , bench "float" $ whnf (\(a,b) -> 1.0 == a || 1.0 == b) (3, 1) ] , bgroup "lt" [ bench "rational" $ whnf (\(a,b) -> r1 > a || r1 > b) (r3, r1) , bench "float" $ whnf (\(a,b) -> 1.0 > a || 1.0 > b) (3, 1) ] ] r1 :: Ratio Integer r1 = 1%1 + 1000000 -- not simply 1%1 because the more complicated value makes the benchmark slower and thus more realistic r3 :: Ratio Integer r3 = 3%1
The Introduction covers most all points raised:
- It rejects the relational algebra approach, instead wanting any expression in the DSL to be easily translatable to SQL by the user.
- Wants to support as many SQL features as possible. Presumably uses strong typing to help features tie together in only correct ways, so avoiding the "noise words" in the lisp DSL, although I don't know how well using types scales, given the size of SQL.
- Rejects portability; it's up to the user to deal with that.
That seems sane, and especially on the portability question, I wonder if that's not better dealt with by first getting a eDSL that can express non-portable SQL, and then dealing with the portability issues at the host language level. Kind of the same way we deal with OS portability.
There are some other tricky things in doing a SQL DSL efficiently, like getting it to fuse queries when composing expressions. IIRC I saw a talk about solving that at ICFP.
Only regret, no chance to slaughter a pig or pilot a spaceship.
Only problem with Norwegian minions is they are not very minion-like really and may end up taking a side hike to visit Virginia or something.
author: Neal Stephenson
average rating: 4.10
book published: 2015
date added: 2015/05/22
author: Jo Walton
average rating: 3.73
book published: 2015
date added: 2015/04/16
author: Joan Slonczewski
average rating: 3.42
book published: 2011
date added: 2015/02/01
author: Ed Finn
average rating: 3.74
book published: 2014
date added: 2014/12/18
List of feeds: