Timeline for Simple complexity
Current License: CC BY-SA 3.0
24 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 17, 2020 at 9:04 | history | edited | CommunityBot |
Commonmark migration
|
|
| Sep 20, 2017 at 15:14 | history | edited | Ian H. | CC BY-SA 3.0 |
-47 bytes
|
| Sep 20, 2017 at 15:04 | comment | added | Ian H. | @JonathanFrech Hey, that's awesome! i'll improve my post as soon as I can. | |
| Sep 20, 2017 at 12:59 | comment | added | Jonathan Frech | Take a look at my improved C# constant golfer, which also implements someone's idea to use hexadecimal literals. | |
| Sep 20, 2017 at 12:45 | comment | added | Jonathan Frech |
Investigating the problem further, I think that any integer literal on the <<'s left side that is larger than 2**31-1 is -- without a trailing L -- interpreted as a 64-bit number. If, however, that literal is smaller or equal to 2**31-1, it is interpreted as a 32-bit number. Bitshifting a 32-bit number results in a 32-bit number, not in a required 64-bit number, and thus the output is buggy.
|
|
| Sep 20, 2017 at 12:20 | comment | added | Jonathan Frech | This code snippet strongly suggests that that might be the problem. | |
| Sep 20, 2017 at 12:17 | comment | added | Jonathan Frech |
I am no expert in C#, but replacing all << with L<< seems to fix the issue. Is it possible that a literal number is an integer by default, and so wraps around as only 32 bits are used?
|
|
| Sep 20, 2017 at 12:12 | comment | added | Ian H. | @JonathanFrech It seems some numbers are bugged with your solution, any idea why? | |
| Sep 20, 2017 at 12:12 | comment | added | Ian H. | @Neil Oh you're right, that does help. | |
| Sep 20, 2017 at 11:35 | comment | added | Shaggy | Looks like the bottom of this is bugged. | |
| Sep 20, 2017 at 11:11 | comment | added | Jonathan Frech |
Well, if the trailing l is not needed, you can probably save even more bytes.
|
|
| Sep 20, 2017 at 11:07 | comment | added | Neil | You would save 4 bytes by not having to specify the padding character. | |
| Sep 20, 2017 at 11:06 | comment | added | Ian H. |
@Neil That wouldn't save any bytes, as I would have to replace the other 0s in the binary string anyways.
|
|
| Sep 20, 2017 at 11:05 | comment | added | Neil | Can you not pad the string with spaces in the first place? | |
| Sep 20, 2017 at 10:48 | comment | added | Ian H. |
@JonathanFrech Thanks, that's awesome? Actually we can even shorten it by 22 bytes, since C# doesn't require the l suffix!
|
|
| Sep 20, 2017 at 10:47 | history | edited | Ian H. | CC BY-SA 3.0 |
-22 bytes
|
| Sep 20, 2017 at 10:33 | comment | added | Jonathan Frech | I think you can save 11 bytes by shortening some constants using bitshifting. See my Python script for a list of possible replacements. | |
| Sep 20, 2017 at 10:12 | comment | added | Ian H. | @KevinCruijssen Thanks, getting close to the <1000! :P | |
| Sep 20, 2017 at 10:12 | history | edited | Ian H. | CC BY-SA 3.0 |
added 4 characters in body
|
| Sep 20, 2017 at 9:44 | comment | added | Kevin Cruijssen |
You can save 14 bytes by printing directly and using the new[]{...} directly in the loop: o=>{foreach(var l in new[]{...})System.Console.WriteLine(System.Convert.ToString(l,2).PadLeft(64,'0').Replace('0',' ').Replace('1','#'));} Try it here. 1002 bytes
|
|
| Sep 20, 2017 at 9:19 | history | edited | Ian H. | CC BY-SA 3.0 |
removed unneccessary space character
|
| Sep 20, 2017 at 9:18 | comment | added | Ian H. | @JonathanFrech Ah you are right, apparently it snuck in there somehow. | |
| Sep 20, 2017 at 9:17 | comment | added | Jonathan Frech |
Is there not an unnecessary space in long[] n=new[]?
|
|
| Sep 20, 2017 at 9:15 | history | answered | Ian H. | CC BY-SA 3.0 |