|
Nippashish posted:lua seems like a really bizarre choice but it actually strikes a really good balance between flexibility, speed and ease of use in a way that no other language has managed. also the core torch7 libraries are really good. it would be nice if lua had a decent standard library and support for parallelism, though or a debugger or profiler
|
#
?
Apr 10, 2015 00:29
|
|
|
|
| # ? May 22, 2024 20:43 |
|
|
starting a bunch of luajit interpreters in the same process and sharing tensors between them with some ffi magic is not too bad a debugger would be p ace tho
|
|
#
?
Apr 10, 2015 00:34
|
|
|
JawnV6 posted:i had to divide by 1000 yeah! yeah! (you could also mix in a shift-by-16 and a shift-by-17 to get even closer!)
|
|
#
?
Apr 10, 2015 00:43
|
|
|
i found a paper on doing a svd in CORDIC and depending on what kind of processing we wanna do on the device i might have to dehumanize myself
|
|
#
?
Apr 10, 2015 00:45
|
|
|
Subjunctive posted:it would be nice if lua had a decent standard library and support for parallelism, though https://github.com/pkulchenko/ZeroBraneStudio it's not very good but better than nothing luajit has a reasonable good built-in profiler. there's a few profilers for puc lua but none that are really worth using
|
|
#
?
Apr 10, 2015 00:59
|
|
|
today this thread led me to naively ask the Torch BDFL why we use Torch instead of something else. thanks, thread.
|
|
#
?
Apr 10, 2015 03:32
|
|
|
oh god sorry. i knew you guys were involved with torch but,
|
|
#
?
Apr 10, 2015 05:05
|
|
|
it's cool, I was going to be introduced to him soon anyway I'm sure
|
|
#
?
Apr 10, 2015 05:27
|
|
|
Nippashish posted:memory networks have a way to do this which seems to work pretty well, but isn't perfect (which is why they need to label supporting facts when they train on their qa tasks). Jason and co just published a paper about an improvement that removes the need for the supporting facts to be labeled in the training data, BTW: Weakly Supervised Memory Networks.
|
|
#
?
Apr 10, 2015 18:56
|
|
|
and this helps with lua debugging a fair bit: https://github.com/facebook/fblualib/tree/master/fblualib/debugger
|
|
#
?
Apr 10, 2015 19:36
|
|
|
why do we have source code management that treats source code as bytes instead of, you know, source code? i would like to see errors if my branch calling foo(bar) merges a branch changing the signature of foo to foo(bar, baz). yeah, the compiler does this, but don't we want to know about errors as soon as possible, and not 20+ minutes into a build?
|
|
#
?
Apr 10, 2015 23:22
|
|
|
Pie Colony posted:why do we have source code management that treats source code as bytes instead of, you know, source code? i would like to see errors if my branch calling foo(bar) merges a branch changing the signature of foo to foo(bar, baz). yeah, the compiler does this, but don't we want to know about errors as soon as possible, and not 20+ minutes into a build? like which language's source code should it be treated? when you change compilers, do your historical diffs reflect the new semantics or the old? does it mean you can't check in syntax errors?
|
|
#
?
Apr 10, 2015 23:28
|
|
|
you could run your static code analyzer (compiler) after you merge and before pushing your changes
|
|
#
?
Apr 10, 2015 23:28
|
|
|
also most source control systems will treat text files as text and not just raw bytes when merging
|
|
#
?
Apr 10, 2015 23:29
|
|
|
how would it detect the error faster than you would by compiling? if it can, why doesn't the compiler do that?
|
|
#
?
Apr 10, 2015 23:29
|
|
|
also what youre thinking about seems like it exists: https://www.semanticmerge.com/ I have no idea how good it is in practice over text-based source code merging I've gotten by fine so far w/ static type analysis and tests
|
|
#
?
Apr 10, 2015 23:32
|
|
|
Subjunctive posted:like which language's source code should it be treated? when you change compilers, do your historical diffs reflect the new semantics or the old? does it mean you can't check in syntax errors? obviously the tools would be language-specific. and like you point out, they may even need to be compiler specific. comedyblissoption posted:also most source control systems will treat text files as text and not just raw bytes when merging yeah you're right, files are kinda the fundamental abstraction. but why not functions, classes, or modules? Subjunctive posted:how would it detect the error faster than you would by compiling? if it can, why doesn't the compiler do that? well, the compiler is probably the one going to be doing that. imagine the SCM tool calling into the lexer/parser when you make a commit or merge a branch. you wouldn't even be able to commit code that would obviously break the build to your repo. and the compiler isn't the first thing running in my build.
|
|
#
?
Apr 10, 2015 23:49
|
|
|
Pie Colony posted:why do we have source code management that treats source code as bytes instead of, you know, source code? i would like to see errors if my branch calling foo(bar) merges a branch changing the signature of foo to foo(bar, baz). yeah, the compiler does this, but don't we want to know about errors as soon as possible, and not 20+ minutes into a build? i think u want a really good static analyser? there arent any perfect ones, but there are some that may be good depending etc
|
|
#
?
Apr 10, 2015 23:54
|
|
|
Snapchat A Titty posted:i think u want a really good static analyser? there arent any perfect ones, but there are some that may be good depending etc nah, think of it as just being a more useful abstraction. i can't count the amount of times i've been viewing diffs on github and some extra spaces or tabs or something else makes the formatting incredibly hard to read. that stuff's not useful to me, show me the actual code that changed. i'll admit i''ve been  all day though
|
|
#
?
Apr 11, 2015 00:01
|
|
|
comedyblissoption posted:also what youre thinking about seems like it exists: oh nice, this is actually exactly what i mean. this seems pretty sweet
|
|
#
?
Apr 11, 2015 00:06
|
|
|
"static analysis" is a euphemism for "hacky tools i have to use because my programming language doesn't have an expressive enough type system"
|
|
#
?
Apr 11, 2015 00:11
|
|
|
Pie Colony posted:nah, think of it as just being a more useful abstraction. i can't count the amount of times i've been viewing diffs on github and some extra spaces or tabs or something else makes the formatting incredibly hard to read. that stuff's not useful to me, show me the actual code that changed. oh yeah i "thought up" that once too, assuming i read your thing right, like, diff the actual tokens instead of whatever whitespace around them?? i think the easiest way is just to have like a commit-hook linter to enforce style
|
|
#
?
Apr 11, 2015 00:24
|
|
|
Subjunctive posted:Jason and co just published a paper about an improvement that removes the need for the supporting facts to be labeled in the training data, BTW: Weakly Supervised Memory Networks. this (softmax instead of max margin) is how google's ntm works. ive been wondering if they tried this for the original memory networks paper or not and im about even money on it didn't work with the freebase qa task vs jason loves max margin and didn't try anything else.
|
|
#
?
Apr 11, 2015 00:32
|
|
|
Subjunctive posted:and this helps with lua debugging a fair bit: https://github.com/facebook/fblualib/tree/master/fblualib/debugger the fblualib stuff has been unusable because of the second clause in the PATENTS file but apparently that is literally changing as we speak which is pretty awesome and i am legit looking forward to trying this out.
|
|
#
?
Apr 11, 2015 00:34
|
|
|
Pie Colony posted:well, the compiler is probably the one going to be doing that. imagine the SCM tool calling into the lexer/parser when you make a commit or merge a branch. you wouldn't even be able to commit code that would obviously break the build to your repo. and the compiler isn't the first thing running in my build. to model C++ and catch things like signature changes you need to see all the includes and preprocessor configuration, so it will need build configuration information. it can't operate on a file at a time in isolation. this is why people do code indexing as part of real compiler pipelines and build processes. you need template expansion and checking for symbol collisions (so it has to understand scope) and overload resolution and all that jazz. you can already make a commit hook that builds the tree and runs tests if you want (or push to a staging branch that is only and automatically promoted when it's green, which works nicely)
|
|
#
?
Apr 11, 2015 00:37
|
|
|
Mr. Glass posted:"static analysis" is a euphemism for "hacky tools i have to use because my programming language doesn't have an expressive enough type system" "expressive enough type system" is like "sufficiently smart compiler". if you think you've found one, you're missing something
|
|
#
?
Apr 11, 2015 00:39
|
|
|
how is a powerful type system not exactly static program analysis?
|
|
#
?
Apr 11, 2015 00:43
|
|
|
Soricidus posted:"expressive enough type system" is like "sufficiently smart compiler". if you think you've found one, you're missing something yup Mr. Glass posted:"static analysis" is a euphemism for "hacky tools i have to use because my programming language doesn't have an expressive enough type system" lil' Hilbert, some things are true but aren't provable
|
|
#
?
Apr 11, 2015 01:02
|
|
|
Subjunctive posted:how is a powerful type system not exactly static program analysis?
|
|
#
?
Apr 11, 2015 01:08
|
|
|
comedyblissoption posted:if you want to get into a wrong obnoxious semantic debate if my compiler infers types to detect error it is an elegant tapestry of computer science, but if I use a different tool to do it it becomes an ugly hack, sullying all things it touches.
|
|
#
?
Apr 11, 2015 01:12
|
|
|
Mr. Glass posted:"static analysis" is a euphemism for "hacky tools i have to use because my programming language doesn't have an expressive enough type system" this is why i prefer c++. its turing-complete type system makes it trivial to statically analyze.
|
|
#
?
Apr 11, 2015 01:23
|
|
|
in practice things called "static analyzers" are basically typecheckers that sacrifice some soundness for completeness. a more expressive type system makes this tradeoff useful less often, but no one has managed to make a sound and complete type system that you can realistically write useful programs in, so there's theoretically always going to be room for a "static analyzer"
|
|
#
?
Apr 11, 2015 01:30
|
|
|
Subjunctive posted:if my compiler infers types to detect error it is an elegant tapestry of computer science, but if I use a different tool to do it it becomes an ugly hack, sullying all things it touches.
|
|
#
?
Apr 11, 2015 01:40
|
|
|
lets all try to define what a type is
|
|
#
?
Apr 11, 2015 01:40
|
|
|
i dont fully see what kind of type system would catch some of these errors: http://clang-analyzer.llvm.org/available_checks.html
|
|
#
?
Apr 11, 2015 01:49
|
|
|
fritz posted:i dont fully see what kind of type system would catch some of these errors: http://clang-analyzer.llvm.org/available_checks.html which ones? dead store is the only one that doesn't seem completely trivially using only features in existing real type systems
|
|
#
?
Apr 11, 2015 03:03
|
|
|
yeah, I think Rust alone catches half of them.
|
|
#
?
Apr 11, 2015 03:08
|
|
|
Pie Colony posted:why do we have source code management that treats source code as bytes instead of, you know, source code? i would like to see errors if my branch calling foo(bar) merges a branch changing the signature of foo to foo(bar, baz). yeah, the compiler does this, but don't we want to know about errors as soon as possible, and not 20+ minutes into a build? Jews.
|
|
#
?
Apr 11, 2015 03:08
|
|
|
the "ignore whitespace" problem was solved in 1875 or something, fwiw. it doesn't require language processing
|
|
#
?
Apr 11, 2015 03:17
|
|
|
|
| # ? May 22, 2024 20:43 |
|
|
ideally you'd want to only ignore non-semantic whitespace changes, which does require language processing
|
|
#
?
Apr 11, 2015 03:22
|
|