| 02:03.46 | *** join/#utah AimerPaddle (~AimerPadd@c-98-202-183-214.hsd1.ut.comcast.net) |
| 02:51.42 | *** join/#utah davido_work (~doswald@c-50-168-241-168.hsd1.ut.comcast.net) |
| 03:01.27 | *** join/#utah olli_ (~olli@c-73-20-95-1.hsd1.ut.comcast.net) |
| 03:09.32 | *** join/#utah davido_ (~davido@c-50-168-241-168.hsd1.ut.comcast.net) |
| 03:40.37 | *** join/#utah OldCoder (~OldCoder@unaffiliated/oldcoder) |
| 03:49.44 | *** join/#utah olli_ (~olli@c-73-20-95-1.hsd1.ut.comcast.net) |
| 03:53.36 | *** join/#utah olli_ (~olli@c-73-20-95-1.hsd1.ut.comcast.net) |
| 15:56.02 | *** join/#utah infobot (ibot@69-58-76-73.ut.vivintwireless.net) |
| 15:56.02 | *** topic/#utah is Utah related discussion including user groups | logs @ http://ibot.rikers.org/%23utah/ | See also ##lds |
| 15:56.02 | *** mode/#utah [+o infobot] by ChanServ |
| 15:56.43 | goozbach | xen bug |
| 15:56.47 | goozbach | nother nasty one |
| 15:56.52 | goozbach | hence the reboot |
| 15:56.56 | goozbach | mine did too |
| 16:17.35 | *** join/#utah wargasm (~wargasm@69.169.178.194) |
| 16:54.46 | unum | ignores jalbretsen invoice like he does his linode invoices |
| 16:56.02 | *** join/#utah AimerPaddle (~AimerPadd@c-98-202-183-214.hsd1.ut.comcast.net) |
| 17:04.25 | *** join/#utah davido_work (~doswald@216.50.142.194) |
| 17:08.25 | shalkie | We can just send out invoices? |
| 17:08.33 | shalkie | spams the room with invoices |
| 17:08.58 | Tod-Work | /ignore shalkie |
| 17:09.04 | Tod-Work | woops! |
| 17:11.58 | *** join/#utah AimerPaddle (~AimerPadd@c-98-202-183-214.hsd1.ut.comcast.net) |
| 17:14.52 | jlp_znc | you can send invoices to anyone you like. now, if they will get paid or not is a totally different thing. |
| 17:15.07 | jlp_znc | and my linode rebooted, too, but I was expecting it because I actually read the e-mail. :-) |
| 17:19.25 | shalkie | This week I was told that the canadian gov sent out letters asking for payments on the premise that those that were hiding something would pay it and those that weren't would contest it If they contested it they were told it was a mistake ;) |
| 17:27.10 | jfindlay | that's funny |
| 17:31.56 | rainbows | that shouldnt be legl |
| 17:32.57 | *** join/#utah AimerPaddle (~AimerPadd@c-98-202-183-214.hsd1.ut.comcast.net) |
| 17:36.46 | RyanE | I've heard of scams being run the same way. Sending IT-type invoices to large companies that outsource IT, and some percentage of them will pay without asking. |
| 17:37.50 | jfindlay | there are people who send out similar extortion payments for patents and copyrights |
| 17:40.03 | shalkie | I've gotten letters from debt collectors claiming I have a debt. Oddly once I send out a letter asking them to validate the debt I never hear from them again. |
| 17:41.14 | jlp_znc | I had that happen once for a debt that I had paid. fortunately, I still had the receipt. |
| 17:43.23 | RyanE | I was sent a parking ticket from NYC when I had rented the car (and stayed in) Connecticut. |
| 17:43.35 | RyanE | Took months to fight it, the bill kept growing and growing. |
| 17:43.47 | RyanE | Got a copy of the original ticket, and the date was the week *after* I had rented the car. |
| 17:45.49 | rainbows | lol |
| 17:45.54 | rainbows | that sucks |
| 17:46.28 | RyanE | It was back when I coudln't afford to pay the $35 dollar ticket. Now it'd just be a matter of principle. :) |
| 18:17.22 | programmerq | when I came back from India, I checked a bag at the desk. they asked me all these extra security questions and I was really confused as to why. then, when I handed them my green amex card, they were all wide eyed "do you have another card?" "no" "follow me" ".... okay...." |
| 18:17.33 | programmerq | they pulled out one of the mechanical card embosser things and dusted it off |
| 18:17.52 | programmerq | I paid that way and then went on to get a bunch more questions asked |
| 18:18.10 | programmerq | then, when the charge hit my card, I got a nasty email notification that Iwas out of compliance |
| 18:18.24 | programmerq | it had been more than 45 days since the charge appeard, and I hadn't filed it |
| 18:18.41 | programmerq | the person running the mechanical machine had written down the month incorrectly |
| 18:18.53 | programmerq | that' my best story for a mistake |
| 18:18.59 | programmerq | not a debt collection thing, but meh. |
| 18:32.39 | *** join/#utah AimerPaddle (~AimerPadd@63.226.94.30) |
| 18:40.54 | T4rku5 | I'm pretty excited to let everyone know -- BSidesSLC 2016 will be held at the Salt Palace (thanks to CompuNet) |
| 18:55.08 | programmerq | okay, someone asked me a question the other day that has me wishing I knew more about computer science. |
| 18:55.40 | *** join/#utah T4rku5 (~T4rku5@66.135.28.122) |
| 18:55.40 | *** join/#utah T4rku5 (~T4rku5@unaffiliated/shunkydave) |
| 18:57.23 | *** join/#utah wargasm (~wargasm@69.169.178.194) |
| 18:57.27 | programmerq | say I want to store the day of week, hour, minute, and second. I figured I could just treat the whole thing like a seconds counter. 0-604799. Tuesday at 6:23am would be 195780. |
| 18:58.00 | programmerq | to store values between 0-604799, I need 20 bits of data: 2**20=1048576 |
| 18:59.25 | programmerq | I started wondering if I could get the bitcount down by storing things differently: 3 bits for day of week, 5 for hour, 6 for minute, 6 for second. nope, that's 21 bits. |
| 18:59.35 | programmerq | err, still 20 bits |
| 18:59.49 | programmerq | every way I slice it up, I get 20 bits |
| 18:59.53 | programmerq | I mean, it makes sense |
| 19:00.15 | programmerq | but it got me wondering if there wasn't a clever CS way to get it down below 20 bits |
| 19:01.57 | programmerq | the most obvious tradeoff would be to reduce my precision |
| 19:10.32 | RyanE | Yeah, if you want seconds precision, you get seconds precision. There's no way to compress something that's taking up the smallest amount of space as a count of each unique item. |
| 19:10.45 | RyanE | The other obvious tradeoff is to make your 'epoch' date sometime closer to now. |
| 19:11.10 | RyanE | If you only have dates going forward from 1/1/2015, your epoch can be smaller, so you can use less bits (assuming you also bound your future) |
| 19:11.32 | RyanE | but those are risky, since you never know how long your system is going to be running. |
| 19:11.48 | programmerq | this question wasn't about a specific tuesday, just any old tuesday and time. |
| 19:11.51 | programmerq | so not a full date |
| 19:12.00 | programmerq | I didn't ask why |
| 19:12.45 | programmerq | it just seems like there should be a clever way to explait the fact that this isn't an arbitrary counter from 0-604799, and that there is other structure to the data that I could use to my advantage. |
| 19:13.49 | programmerq | but, at the end of the day it's seconds I'm counting. |
| 19:16.24 | unum | I think integer is the most effecient data type to store |
| 19:19.02 | RyanE | Yeah, I misread the original question, I don't think you can get below 20 bits. |
| 19:19.30 | RyanE | Similar to this question: |
| 19:19.37 | RyanE | https://stackoverflow.com/questions/595884/what-is-the-smallest-size-of-bytes-that-you-can-store-a-timestamp |
| 19:20.26 | RyanE | of course, at 21 bits for the 'bit-sliced' version, that's probably worth the extra bit to make it easier to encode/decode. |
| 19:20.47 | programmerq | it actually ended up being 20 still |
| 19:21.04 | programmerq | there's plenty of space leftover since it only just barely needs the 20th bit in the seconds-integer approach. |
| 19:24.28 | *** join/#utah Enemby (~Enemby@unaffiliated/enemby) |
| 19:38.59 | *** join/#utah milkmaid_ (sid60592@gateway/web/irccloud.com/x-etsxlmifxaegjdhl) |
| 19:52.47 | *** join/#utah tristanbob_l (~tristanbo@62.sub-70-208-7.myvzw.com) |
| 19:58.57 | *** join/#utah davido_work (~doswald@216.50.142.194) |
| 20:05.39 | jfindlay | https://stopcyberspying.com/: featuring more of your privacy systematically voted away |
| 20:16.35 | *** join/#utah wargasm (~wargasm@69.169.178.194) |
| 20:54.43 | unum | I thought you might be able to pull off so compression if you really wanted to |
| 20:54.59 | unum | but I just don't know what kind of compression you can do on 20 bits |
| 21:03.30 | jfindlay | sudo make me a hoverboard and a lightsaber |
| 21:11.43 | *** join/#utah AimerPaddle (~AimerPadd@63.226.94.30) |
| 21:13.51 | *** join/#utah T4rku5 (~T4rku5@unaffiliated/shunkydave) |
| 21:16.56 | *** join/#utah Nemus (~Nemus@unaffiliated/nemus) |
| 21:37.35 | RyanE | My argument against there being any possible compression is that there's no redundancy of data. Every number in the 'pool' of integers being used represents a discrete data value. Since there's no redundancy, there's no compression available. |
| 21:37.53 | RyanE | sudo make me a wizard |
| 21:38.03 | jfindlay | sudo sudo |
| 21:38.35 | jfindlay | it's not endomorphic, right? |
| 21:39.59 | RyanE | sudo sumo |
| 22:00.38 | jlp_znc | ultimately, your're not going to be able to get it better than the number of bits you need to store the seconds, since that is the granularity of your data. |
| 22:01.06 | jlp_znc | imagine if you will, that you list all of the possible values. the number of values you will have is the same as the number of seconds in a week (604800) |
| 22:02.10 | jlp_znc | you need to be able to represent 604800 discrete values. you must have 20 bits to do that, and you "waste" the additional ~400000 values that you could also represent with those 21 bits. |
| 22:02.33 | jlp_znc | but you are not wasting any bits. you need every one of the ones you have. |
| 22:03.47 | jlp_znc | takes off computer scientist hat |
| 22:06.07 | RyanE | I think that's what I said. :) |
| 22:06.25 | RyanE | but yours was clearer, FTW. |
| 22:06.34 | jlp_znc | sorry, didn't read your response, RyanE. I had some of that in buffer and just started typing. :-) |
| 22:49.32 | jlp_znc | also, on most architectures, unless you take care to prevent it, the compiler will happily allocate you a full 32 bits for your "int". even if you tell it you only want, e.g. 20 bits in your packed data structure, it's just as likely to pad it out to 32 because it's easier. |
| 22:51.01 | RyanE | or 64 bits |
| 22:51.12 | RyanE | depending on architecture and compiler switches. |
| 22:55.25 | asoc | there are efficiency gains to that padding as well correct? |
| 22:59.41 | RyanE | yeah, for processing/moving large amounts of data, there are operations that operate on the larger size. |
| 23:32.10 | *** join/#utah smcquay (~smcquay@173-164-185-125-SFBA.hfc.comcastbusiness.net) |
| 23:52.12 | levi | Some processors will fault when asked to fetch an n-byte value at an address that is not an even multiple of n. Those that do not fault will take longer for such a fetch than they will for a properly aligned one. |
| 23:52.59 | levi | This is the main reason why C is allowed to insert padding between and after elements of a struct. |
| 23:54.00 | levi | But it can't insert padding before the first element. The first sub-object of a compound object in C always shares the address of the compound object itself. |
| 23:55.37 | levi | This is occasionally a useful fact to be aware of when reading/writing C code. |