Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TheBiggerFish]

...Can you upload compiled code?

Or is the point of this exercise using make with Java?

Bleugh, this sounds terrible.

[breadman]

There's was a stackoverflow question to optimized this code from a computation puzzle:

I'm too lazy to look it up - what is that function supposed to even do? Or is it just purely a "puzzle" problem?

I looked it up - the problem statement in http://stackoverflow.com/questions/43029024/reducing-the-time-complexity-of-the-code-below is actually kind of ambiguous if it's just the first statement; if you follow the example, then it matches...

I took a look.  It turns out that for that particular problem, caching the results is a huge win.  For 10⁹, for example, that reduces the number of calls from 1,023,093,838 to 691.

Sometimes, micro-optimizations distract you from the real problem with an algorithm.

Anyone have any experience with MATLAB? I'm taking a course with it and about to buy the software, but I'm not sure if there's any of the extra modules that are helpful enough to justify another 10 bucks each.

I used it in college, but can't say that I would ever have used it since then.  Granted, I'm more willing than most to use open-source alternatives, programming myself to make up for any slack.

Anyone here had the displeasure of using make with Java?

I think I have, but I used to use make for quite a few things, and haven't really used Java for a decade or so.

Code: [Select]

sources = $(wildcard ./src/*.java)


Do note that this won't recurse into subdirectories.  If all your .java files are in a single directory, it's fine, but I seem to recall the culture encouraging excessively deep directory structures.

Code: [Select]

classes = $(sources:.java=.class ./src/=./bin/)


This is a problem.  It looks like you're trying to turn "./src/ClassName.java" to "./bin/ClassName.class" (completely reasonable), but you're actually turning it into "./src/ClassName.class ./src/=./bin/" due to a misunderstanding of the makefile variable substitution syntax.  You could do it in two steps, or you could use the more powerful substitution form:

Code: [Select]

classes = $(sources:./src/%.java=./bin/%.class)


Code: [Select]

%.class : %.java


Make doesn't consider the definition of $classes when evaluating this rule, so it doesn't know how to find the right .java file.  Even after correcting the definition as above, when it needs ./bin/ClassName.class, it will look for ./bin/ClassName.java, instead of ./src/ClassName.java, because the % symbols are straight-up substituted.  Instead, you need:

Code: [Select]

./bin/%.class: ./src/%.java


Code: [Select]

$(JAVAC) $<


This line doesn't tell javac where to put the .class file, which would probably end up using its default location in the same directory as the .java file.  You may want to override the sourcepath, too, in case it needs to look up information from another file.

Code: [Select]

$(JAVAC) -d bin -sourcepath src $<


[Arx]

Thank you! I figured out a hacky, hacky solution in the end, but it's nice to see the actual way of doing it. Make seems like a useful thing to know, but there's such a bewildering quantity of information out there that I get a bit lost. Slowly making my way through the GNU Make Manual, though, which is clarifying a lot of things (and muddying some others...).

[Pseudo]

There's was a stackoverflow question to optimized this code from a computation puzzle:

I'm too lazy to look it up - what is that function supposed to even do? Or is it just purely a "puzzle" problem?

I looked it up - the problem statement in http://stackoverflow.com/questions/43029024/reducing-the-time-complexity-of-the-code-below is actually kind of ambiguous if it's just the first statement; if you follow the example, then it matches...

I took a look.  It turns out that for that particular problem, caching the results is a huge win.  For 10⁹, for example, that reduces the number of calls from 1,023,093,838 to 691.

Sometimes, micro-optimizations distract you from the real problem with an algorithm.

Yep. My naive implementation in Python works just fine:

Code: [Select]

import sys
@functools.lru_cache(maxsize=None)
def maxSum(n):
return n and max(n, maxSum(n//2) + maxSum(n//3) + maxSum(n//4))
Also, in case you are wondering:

Code: [Select]

>>> maxSum(10**1000)
107428639370816894282905754471321831518581303185425911940693187681195007321945988349882143120902910400886527923620957274764951380456741382084706587048538786154771612940823867761038833086956122124681283950342202102907719931543369912800740053443551539289722666291720359846410140779179924104094766456788576904771417042802444892483345375529093935583084253865006408160389805593176530643710579419012595042578031772447113635678144051094440330549055091411989660718033246620933839392551824546424923488957675932121571155907787854455748165845176223146906449047431508730495745633313271764866571423579399796775704176595215852644453976623823367419021424402783381524810655198501269693938129700094066493794659564823372029540527720068315371071207607522278012105675340595722082148948234123939638207721957567717407731813328775369184448827317789554077827350035143824296462233041623198614297228892656550316185255221724146893318035161668707135088732309129845480263028807967273443643378810339582419287587907021278692142889371486606957198689248383852081657427214676080014962347334671570118688132967723155789


[MoonyTheHuman]

I was wondering what you guys thought about Rust?

(Resources to check it out at if you dont know:
https://www.rust-lang.org/
https://play.rust-lang.org/
https://doc.rust-lang.org/)

[smjjames]

I was wondering what you guys thought about Rust?

(Resources to check it out at if you dont know:
https://www.rust-lang.org/
https://play.rust-lang.org/
https://doc.rust-lang.org/)

You mean iron oxide? /insert chemistry joke.

I'm sorry, lol

[Reelya]

While you apparently can make a Rust program almost as fast as C++, apparently that's very frought with trial and error. Small changes to a Rust program cause wildly varying performance in ways that C++ is fairly hardened against. So Rust might rival C++ for performance but only if you're an optimization whiz who profiles everything, and if you're that guy then you're not the person who's going to benefit the most from switching to Rust.

http://cantrip.org/rust-vs-c++.html

Rust might then benefit from improved compilers, but if you're going that route, improved compilers for C++ could also detect more of the same types of errors Rust says it solves.

[milo christiansen]

In short: Rust has a very ironically appropriate name.

[Reelya]

I'd also be wary of a language that says it never segfaults.

C++ segfaults for a good reason: the code is designed to fail rather than perform illegal operations. If you have out of bounds array reads in Rust does it just keep chugging along and pretend everything is ok? C++ could do that, but the designers decided not to.

C++ fails when you make a range of glaring errors. That enforces discipline in checkng that you are indeed coding logically correct structures. Merely promising not to fail no matter what you do doesn't make your code magically correct.

[Strife26]

Hypothetical greatest programming language ever:

Instead of throwing an error when things go wrong, the program will open a new window and prompt the user to play a randomly selected DOS game instead.

[MoonyTheHuman]

I'd also be wary of a language that says it never segfaults.

C++ segfaults for a good reason: the code is designed to fail rather than perform illegal operations. If you have out of bounds array reads in Rust does it just keep chugging along and pretend everything is ok? C++ could do that, but the designers decided not to.

C++ fails when you make a range of glaring errors. That enforces discipline in checkng that you are indeed coding logically correct structures. Merely promising not to fail no matter what you do doesn't make your code magically correct.

Segfaults are errors caused by outofbojds memory use being stopped by the kernel. rust avoids this by not lettin the kernel hndle it, instead opting fr a 'panic' system where it unwinds the stack and gives a stacktrace istead of outright diwing without anh debug info forthose not using a debugger

[da_nang]

To be fair, C++ out-of-bounds memory access is undefined behavior. It's entirely up to the OS how that is handled.

For instance, from what I recall, freeing a memory block doesn't necessarily mean you'll get a segfault should you access that block again as long as the block hasn't been allocated elsewhere.

[Rose]

This reminds me of a crash bug I was having that only happened in linux, because of the differences in the way windows and linux handled array out of range errors. Windows just gave garbage data, which I didn't even use, so I never noticed it, but linux would segfault.

[lethosor]

To be fair, C++ out-of-bounds memory access is undefined behavior. It's entirely up to the OS how that is handled.

For instance, from what I recall, freeing a memory block doesn't necessarily mean you'll get a segfault should you access that block again as long as the block hasn't been allocated elsewhere.

I'm not quite sure what you mean by the block being "allocated elsewhere" - by another program or the same program? If it's the former, virtual memory prevents programs from accessing each others' memory in the same way as their own. There's no way a program could accidentally access another program's memory (without going through OS-specific APIs, etc.).

If it's the latter (e.g. a program allocates a block with addresses 100-200, frees it, and allocates another block which happens to have the same address), that's worse - as far as the OS is concerned, that program can access those addresses freely, regardless of whether the program intends to access data stored in that block previously or in the "new" block in the same location.

(That may be unclear; I had to write this quickly, but let me know if I need to clarify anything.)

[Antsan]

I was wondering what you guys thought about Rust?

(Resources to check it out at if you dont know:
https://www.rust-lang.org/
https://play.rust-lang.org/
https://doc.rust-lang.org/)

Rust is really cool. To me it looks like a imperative/class-oriented programming language with Haskell's type system.

I'd also be wary of a language that says it never segfaults.

C++ segfaults for a good reason: the code is designed to fail rather than perform illegal operations. If you have out of bounds array reads in Rust does it just keep chugging along and pretend everything is ok? C++ could do that, but the designers decided not to.

C++ fails when you make a range of glaring errors. That enforces discipline in checkng that you are indeed coding logically correct structures. Merely promising not to fail no matter what you do doesn't make your code magically correct.

Rust never segfaults because the type system makes sure that all possible segfaults are caught at compile time. That means that a lot of stuff that would compile with C(++) doesn't compile with Rust without providing additional information. So, no, no uncaught segfaults or chugging along, instead you can't even get the damn thing to compile. Which is a nice thing, in my eyes.
You can get it to compile programs that may contain segfaulting behavior, but you need to explicitly wrap the corresponding code in stuff that either catches that segfault or mark the code as unsafe.
Rust errs on the side of not compiling your program.
C(++) errs on the side of compiling your program to be as fast as possible, which is much more dangerous and common than you give it credit for.