Skip to main content

Timeline for Programming with Bits and Bytes

Current License: CC BY-SA 3.0

15 events
when toggle format what by license comment
Mar 31 at 0:10 comment added ceilingcat 95 bytes
Jun 17, 2020 at 9:04 history edited CommunityBot
Commonmark migration
Sep 9, 2015 at 15:24 comment added r3mainer @TobySpeight Nice one, thanks!
Sep 9, 2015 at 15:24 history edited r3mainer CC BY-SA 3.0
Edit suggested by Toby Speight (thanks!)
S Sep 9, 2015 at 13:03 history suggested Toby Speight CC BY-SA 3.0
Clarify input encoding is ASCII/ISO-8859/UTF-8 - EBCDIC requires different constants
Sep 9, 2015 at 12:37 comment added Toby Speight A tiny improvement: a*257/16 is one byte shorter than a/16|a*16.
Sep 9, 2015 at 12:31 review Suggested edits
S Sep 9, 2015 at 13:03
Sep 8, 2015 at 14:46 history edited r3mainer CC BY-SA 3.0
deleted 11 characters in body
Sep 8, 2015 at 13:27 comment added MarcDefiant I just saw it now, but you can also use a/16|a*16 instead of a/16|(a&15)*16. The few bits on top get removed by the &255.
Sep 8, 2015 at 13:24 history edited r3mainer CC BY-SA 3.0
d'oh!
Sep 8, 2015 at 13:19 comment added MarcDefiant In this case you can even use the format string %u instead of %hhu
Sep 8, 2015 at 13:10 comment added r3mainer Ah, good point. Turns out it was more efficient to mask out the lower 8 bits at each iteration.
Sep 8, 2015 at 13:09 history edited r3mainer CC BY-SA 3.0
added 37 characters in body
Sep 8, 2015 at 12:53 comment added MarcDefiant I tried the challenge myself and I wrote almost exactly the same code. Btw. your program doesn't drop the bit when shifting upwards (input: !<> should result in 127 and not 255). Either define your a as char, or use the line a&=255 (and use %u) to get the correct effect. Also you can shorten your negation a^255 to ~a. a>>4&15 is also shorter than your (a&240)/16.
Sep 7, 2015 at 19:21 history answered r3mainer CC BY-SA 3.0