protomikron

31 ms·

271.
by protomikron 10y ago
Graphics (speaking of modern 3D graphics) on Linux sucks, because NVidia and Co do not really care about it. It has gotten better (e.g. the deep learning crowd is mostly on Linux using cuda), but is still a far-cry from the stability of oth
272.
by protomikron 10y ago
This is an interesting area and the most important recent change is the opening of the data. More and more municipalities provide web services where you can download high-quality imagery, e.g. have a look at https://www.wien.gv.a
273.
by protomikron 10y ago
We could call this the "Kantian Space-Time Assumption" as a precondition for strong AI. :) As others have mentioned, it is a philosophical question and probably one of the fundamental questions of our and next generations.
274.
by protomikron 10y ago
> This isn't an engineering problem, it's a philosophical problem [...] Indeed. However we can not rule out the possibility that we engineer a system without a "body" (I think you are referring to the Embodied mind th
275.
by protomikron 10y ago
You are right my mistake. However it seems to me that the Haskell community lays more emphasis on purity and the OCaml community takes a more pragmatic approach - but this distinction may be superficial for practical concerns.
276.
by protomikron 10y ago
And this is actually a terrible thing. Fortunately my school did this stuff with the Python stack, however the situation is similar to MS Office - it is taught in schools (general education I mean) and so people struggle with e.g. LibreOffi
277.
by protomikron 10y ago
Coq is a theorem prover and library that is written in ML (OCaml), so it is definitely not Haskell. It is interesting that most (interactive) proof systems (e.g. Isabelle and Coq) are written in ML, I think it is probably historical. AFAIK
278.
by protomikron 10y ago
> This showed that fundamentally, a terminal-based text editor is trivial to build. I do not agree. There is a big difference between a proof-of-concept terminal-based text editor and a state-of-the-art development editor like vim or ema
279.
by protomikron 10y ago
> Screw all the caching, interconnect, branch prediction, etc. - what has is done for us lately? What have the Romans ever done for us? - caching: better performance; performance critical code is mostly memory constrained (your CPU is wa
280.
by protomikron 10y ago
This is disgusting propaganda. It is so disgusting, that I have to comment here, although the thread is rather old, so sorry. Or is your comment satire? Hard to say these times ...
281.
by protomikron 10y ago
I would, but it seems I am not able to change the title anymore. I have an "edit" option in my comments, but maybe this functionality does not work for submissions? In particular I am not the author of the linked page.
282.
by protomikron 10y ago
I found this page via http://physics.stackexchange.com/questions/54052/is-it-possi... and I think it is really interesting. Furthermore it is interesting to know that one might consider the technology on the page
283.
Reproducing Young's experiment at home(teralab.co.uk)
2 points by protomikron 10y ago|3 comments
284.
by protomikron 10y ago
I researched it some years ago and the precision was just too low. Furthermore I believe that it has to work REALLY well. In particular it is interesting to know if there would be some kind of health risk? E.g. if the tracking is off (i.e.
285.
by protomikron 10y ago
Can you elaborate? I know that it might misbehave (i.e. report false positives), but I only encountered that with more complicated code that deals either with big-fat third party libraries or heavily optimized code where the developer e.g.
286.
by protomikron 10y ago
Show them Valgrind. I think if one teaches C to newcomers it is an invaluable tool. If you compile via -g you get nice reports over undefined behaviour, memory leaks, etc. Really I wish I had access to it when I learned C.
287.
by protomikron 10y ago
I completely agree and hope that more and more other engineers just say NO to aggressive advertising bullshit. It is not like one has no choice.
288.
by protomikron 10y ago
Yeah, ok, I get that, it is nice. But I do not see some kind of revolution (I am sure I heard that term connected to home automation) that is often proclaimed. For me the time saving is just too low compared with the alternative of wrestlin
289.
by protomikron 10y ago
That is funny. So the motive of your friend is security for himself and surveillance of his wife. The motive of cloud home automation stuff (e.g. Homeseer) is surveillance of its customers, e.g. your friend. It is like turtles all the way d
290.
by protomikron 10y ago
Yeah, bullshit was a hard term, I am sorry, but I just can not see how these things require a specific "home" device; - grocery list: So some kind of Todo list. But you can do that with your mobile computation device, or just take
291.
by protomikron 10y ago
Ok, controversial opinion: "[...] and manage everyday tasks" What exactly do we want to automate at home? I think this whole home automation and smart home stuff is complete bullshit. Obviously there are some nice things, like &qu
292.
by protomikron 10y ago
Interesting. Can anybody explain in a few sentences (if this is possible), why we have undefined behaviour in the first place? I know there are optimization reasons, but do we have data that confirms that turning on stricter flags (I think
293.
by protomikron 10y ago
I do not want to be snarky, but are these languages actually used and what do they bring to the table? I have to admit, if I hear the term "workflow" I get very suspicious as there does not seem to be a consensus on what exactly a
294.
by protomikron 10y ago
Thank you, that was fantastic! :) Classic South Park. Direct but with lots of truth in there.
295.
by protomikron 10y ago
You may test it. It is straight-forward do build, e.g. I tested the sdl2 demo (demo/sdl/) and CPU usage was <10%. I did not dig further, but I like the general idea, as GUI toolkits are biiiiig.
296.
by protomikron 11y ago
Short life times for vim are more a thing on remote sessions, e.g. for server configuration. I agree with you, that such a work flow is suboptimal for the general development case, so I will just describe what works for me: Do not close vim