Dalton Filho

Thank you very much!

Hello Ranchers,

I'm currently developing an open-source project that aims to translate JFC windows into C++ wxWidgets using the properties of the window. The home page of the project is at https://wxmatisse.dev.java.net/

My question: can I obtain the ButtonGroup from which a JRadionButton is member? Is there any method I can use or even a workaround? I'm a little disappointed with it because so far the JFC API has allowed the wxMatisse project to translate everything.

I will appreciate any help.

Henry, thank you very much for the insight. I didn't finish college too long ago and yet it seems like my computer architecture teacher didn't provide me with the most up to date information. I was assuming that failed conditional branch was a catastrophe even in modern processors.

... and to update you with an actual result, I've multiplied the number of iterations on the "optimised" test by 2n. The traditional counter is almost 80% faster.

Dalton

Hello everyone again,

Using Henry's solution, I've made up a test to compare the performance of the solution without conditional branches against the traditional approach, which uses one iteration to count up and another to count down. The complete code for the test is below:

// Return: zero for zero. one for anything else. public static int isNotZero(int n) { int nSign = (n >>> 31); int negnSign = (-n >>> 31); return nSign + negnSign; } // Return: one for zero. zero for anything else. public static int isZero(int n) { return isNotZero(n) ^ 1; } // Return: one for equal. zero for not equal. public static int isEqual(int n, int n2) { return isZero(n - n2); } // Return: zero for equal. one for not equal. public static int isNotEqual(int n, int n2) { return isNotZero(n - n2); } // Return: e for equal. ne for not equal. public static int isEqualThenElse(int n, int n2, int e, int ne) { return (isEqual(n, n2) * e) + (isNotEqual(n, n2) * ne); } public static long counter(int n) { int counter = 0; int diff = 1; int iterations = 0; long time = System.currentTimeMillis(); while (iterations++ < 1000000) { diff = isEqualThenElse(counter, 0, 1, diff); diff = isEqualThenElse(counter, n - 1, -1, diff); counter += diff; } return System.currentTimeMillis() - time; } public static long traditionalCounter(int n) { int counter = 0; int iterations = 0; long time = System.currentTimeMillis(); while(iterations++ < 1000000) { for (; counter < n; counter++); for (counter -= 2; counter > 0; counter--); } return System.currentTimeMillis() - time; } public static void main(String[] args) { long total = 0; for (int i = 0; i < 2500; i++) { total += traditionalCounter(11); } double traditionalCounterAvg = total / 2500.0; total = 0; for (int i = 0; i < 2500; i++) { total += counter(11); } double counterAvg = total / 2500.0; double percent = (1.0 - (counterAvg / traditionalCounterAvg)) * 100.0; System.out.printf("Traditional counter average: %s%n", traditionalCounterAvg); System.out.printf("Optimised counter average: %s%n", counterAvg); System.out.println("The optimised counter is " + percent + "% faster"); }

Yes, the tests use conditional branches, but because the same branches were put in both tests, the overhead should be systematically distributed. In my machine, the optimised counter is 77% faster, which is quite a reasonable number to me. To dismiss the possibility that my machine might be "poisoning" the results, other people could test the code to see if the results are consistent in other machines.

To make things even more interesting, Henry's solution was faster than the other forum's solution, which is also based on bitshift operations to avoid the conditional branches.

I admit that my assumption could be wrong: this solution could be slower, but what is so wrong about trying to find a better solution, one that doesn't seem obvious at first? This is a good programming challenge in the worst case, and for this problem in particular it really paid off.

Math.abs() uses conditional branches.

Can someone create a circular counter that would go back and forth from 0 to N-1 ad infinitum, without any conditional branches?

For N = 4, this counter would output: 0 1 2 3 2 1 0 1 2 3 2 1 0 1 2 3 2 1 0 1 2 ...

I sent this challenge to another forum and it took 35 days for someone to find the answer. Can Javaranchers beat them?

What is this challenge all about? Efficiency, of course! When I'm doing a fade-in/fade-out animation, I'm reading a color array back and forth, and because I want this animation to have the best performance possible, removing the conditional branches is a great help. Of course, the alternative computation should be cheaper than a failed conditional branch.

With the solution found on the other forum, the perfomance is 40.5% higher without conditional branches, which is a very significant number!

PS: I know we have JavaFX today, but at the time I needed it first, it didn't exist; nevertheless, this is a good programming challenge that remains until this day.

After 5 weeks of wait, I've finally received my results:

General Con: 100 100
Documentation: 70 70
OOD: 30 30
GUI: 40 24
Locking: 80 80
Data Store: 40 40
Network Server: 40 7

Total: 400 351


I'm happy I've finally passed, despite my tragic RMI grade... I would love to know what exactly went wrong with the network server, but I'm on my own to speculate why. My GUI was quite simple and intuitive, but perhaps the assessor thought my minimal table design was a bit too intuitive.

I'm sure the most useful kind of thread on this forum must be the SCJD results. This is where everyone can contribute to everyone's success by describing what counted and what deducted on their final results, it's not a mere podium. Here's my contribution:


Network server

I was negligent on the RMI server: I didn't care for broken clients, although I've justified that case on my choices document. I thought it was too complex to take care of that on the project, perhaps I was wrong. I've also added the stub file, which is unnecessary in JDK 6. I did not discuss my server design at all on my choices.txt, maybe that was another factor.

Data store & Locking

I'm happy I didn't fall victim of the 40/80 curse! I had a separate locking manager. My database class could accept different locking managers that could be used to apply different locking strategies (locking / no locking / time managed locking / etc). I had one class for low level record operations (the record manager), another for locking (the lock manager), and another for search operations (the search manager) which resulted in a 272 lines Data class that was easy to understand.

Search mechanism

My search mechanism was extremely flexible: I used the strategy pattern to encapsulate search criterias in such a way that I could easily create criterias of arbitrary complexity. The strategy pattern normaly yields many classes, but I wasn't deducted any points for my choice.

General considerations & Documentation

For the purpose of this project, I didn't trust code formatters, and apparently it paid off! I've followed the Sun code convention rigorously (I have yet to see one code formatter that does so). I've documented every single member of every single class. Very dreadful, but it paid off...

I think the most important contribution I can make has to do with the infamous 48h rule: I did not implement it and I gave strong reasons for doing so on my choices.txt. I suppose my general considerations score shows it was a valid choice. I also did not implement insertion and removal of records and justified my choice.

OOD

I am very satisfied with my OOD score! I used the common 3 tier approach, and I went as far as naming the packages according to their role on the MVC pattern! My other relevant OOD decisions were already described on my other considerations.


Some stats

Number of classes: 36
Size of choices.txt: 14.3KB


I wish everyone success and I hope I have contributed somehow!
[ September 15, 2007: Message edited by: Dalton Filho ]

You are in the right direction by encapsulating the search criteria into a class of its own, but I'm not too confortable with your design for this class.

If you have different interchangeable algorithms, don't abuse conditional statements, use the Strategy Pattern. It solves your problem beautifully and is very extensible.

I think it's more consistent to implement both 48h rule and date check prior to booking or neither. If no program can write to the database (assumption) and no recent records are available, would it make sense to do any kind of date checking?

I think the question may not be what you can(not) do, but what you should (not) do. You should not go beyond the scope of your assignment, for your own sake. On my assignment this rule is not one of the "musts".

I was wondering if should implement the 48h rule, but I have seen people here (with 100% score) who did not implement it (which is ok as long as you justify it on your choices.txt). I'm on the final revision of my assignment and I don't plan to implement it.

Do you comment methods of inner classes? Given the atomic nature of my inner classes, I feel redundant having to comment the inner class and its (only) method. Many lines would be added uselessly.

Consider the following situation, where A is a proxy of B:

package x; class B { void m1() { // Some implementation } void m2(int p) { // Some implementation } void m3(String p) { // Some implementation } }
package x; public class A { private B b = new B(); public void method1() { b.m1(); } public void method2(int p) { b.m2(p); } }

And consider the following restrictions:

- I cannot/do not want to change B
- I cannot/do not want to extend B
- I cannot/do not want to make B available
- I cannot/do not want to make method m3 available

And this necessity:

- I do not want to have to write all proxy methods!


Imagine there were a special syntax for proxy methods:

package x; public class A { private B b = new B(); public proxy b.m1() as method1(); public proxy b.m2(int) as method2(int); }

Which would result in the same interface of the first class A example.

Has anyone here had the same needs? Would there be another alternative to write less when writing a proxy class?

Is there anything impeding you from adding another (more flexible) search method on your data class?
[ September 11, 2006: Message edited by: Dalton R. Filho ]

Originally posted by John Deal:
Yes I am an old hacker. COBOL Begin-Paragraph End-Paragraph (or something like that), Pascal Begin End, SPL (Algol 60 based language), C, C++ { }. I like to try to keep the same basic code layout across all languges. Personally the SUN standard for brace placement drives me crazy. I will most likely do it "My Way" then convert it at the end. I may just try the format converter.

I was a software programmer/engineer for 23 years before starting to teach at a community college for the last 3 years. Lots of languages, lots of targets, lots of operating systems. It has been quite a ride!

Thanks!

Thank you John, that explains it all. I remember one teacher saying in a data structures class (that was taught using Java) that we were not just programming in a new language (most people had an Object Pascal background), we had to "speak Javanese" - that included not writing method names starting with capital letters (we used to do that in OP), writing braces as if they were begin/end paragraphs, among other subtleties.

Not placing the braces the standard way, considering your experience, may lead people to think you despise other Java subtleties in favor of old (bad?) practices you consider correct.

This a big controversy, but for the SCJD you should follow the Java Code Convention, which does not allow braces to be placed that way.

As far as the interface declared in the document, you should not take that into account, it does not even ident correctly.

Just curious: did you inherit that brace placement style from another language? It looks very object pascal (BEGIN...END)

http://java.sun.com/docs/codeconv/html/CodeConventions.doc5.html

# Open brace "{" appears at the end of the same line as the declaration statement
# Closing brace "}" starts a line by itself indented to match its corresponding opening statement, except when it is a null statement the "}" should appear immediately after the "{"

[ September 08, 2006: Message edited by: Dalton R. Filho ]