Some nice small graphics demo programs

[Antti J Ylikoski]

I wrote a number of (small) Java demo programs for prospective
employers, and I feel that some ones among them are interesting and
nice enough so that someone over there may want them, maybe for nice
looking graphics demo purposes. (This entry is not here in order to
look for a job -- I only want to show those nice graphics demo
programs.)

Some interesting graphical demos are:

The Hilbert Curves demo:
(Modified and created, after the Deitel-Deitel textbook, and by
myself. Originally was by Niklaus Wirth in the 1980's.)
http://koti.mbnet.fi/bluejay/DrawPanel.java
http://koti.mbnet.fi/bluejay/DrawPanelTest.java

The Mandelbrot Set demo:
(Modified, after the Horstmann-Cornell textbook)
http://koti.mbnet.fi/bluejay/RasterImageTest.java

The Julia Set (Dragon Curve) demo:
(Completely by me)
http://koti.mbnet.fi/bluejay/Complex.java
http://koti.mbnet.fi/bluejay/JuliaSet.java


As the English idiom goes: Enjoy!


kind regards, Antti J Ylikoski
Helsinki, Finland

[Joerg Meier]

On Fri, 15 Aug 2014 03:17:05 +0300, Antti J Ylikoski wrote:

> I wrote a number of (small) Java demo programs for prospective
> employers, and I feel that some ones among them are interesting and
> nice enough so that someone over there may want them, maybe for nice
> looking graphics demo purposes. (This entry is not here in order to
> look for a job -- I only want to show those nice graphics demo
> programs.)

Very nice. However, if you are not looking for a math job but for a
programming job, I recommend looking at the Oracle or the Google Java Code
Conventions, as your code is ill formatted, and I would not be terribly
excited over it as a potential employer.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[Antti J Ylikoski]

On 15.8.2014 17:47, Joerg Meier wrote:
> On Fri, 15 Aug 2014 03:17:05 +0300, Antti J Ylikoski wrote:
>
>> I wrote a number of (small) Java demo programs for prospective
>> employers, and I feel that some ones among them are interesting and
>> nice enough so that someone over there may want them, maybe for nice
>> looking graphics demo purposes. (This entry is not here in order to
>> look for a job -- I only want to show those nice graphics demo
>> programs.)
>
> Very nice. However, if you are not looking for a math job but for a
> programming job, I recommend looking at the Oracle or the Google Java Code
> Conventions, as your code is ill formatted, and I would not be terribly
> excited over it as a potential employer.
>
> Liebe Gruesse,
> Joerg
>

Are you familiar with the GNU Emacs, the EMACS was considered the
world's best academic world text editor in its time? It still is
running strong.

That code has been formatted with the conventions of the GNU Emacs, and
was taken from the NetBeans IDE which I'm using. Do you know the NetBeans?

Therefore, I would not be immensely excited over that entry as an
employer.........

Heipparallaa, Andy Y

[Joerg Meier]

On Tue, 19 Aug 2014 04:44:33 +0300, Antti J Ylikoski wrote:

> On 15.8.2014 17:47, Joerg Meier wrote:
>> On Fri, 15 Aug 2014 03:17:05 +0300, Antti J Ylikoski wrote:
>>> I wrote a number of (small) Java demo programs for prospective
>>> employers, and I feel that some ones among them are interesting and
>>> nice enough so that someone over there may want them, maybe for nice
>>> looking graphics demo purposes. (This entry is not here in order to
>>> look for a job -- I only want to show those nice graphics demo
>>> programs.)
>> Very nice. However, if you are not looking for a math job but for a
>> programming job, I recommend looking at the Oracle or the Google Java Code
>> Conventions, as your code is ill formatted, and I would not be terribly
>> excited over it as a potential employer.

> Are you familiar with the GNU Emacs, the EMACS was considered the
> world's best academic world text editor in its time? It still is
> running strong.

Yes, I am. It is, as far as Java goes, an antiquated dinosaur which, it
appareas, does not even support proper code formatting.

> That code has been formatted with the conventions of the GNU Emacs, and
> was taken from the NetBeans IDE which I'm using. Do you know the NetBeans?

Yes, Netbeans is Suns/Oracles IDE which is also generally considered the
worst IDE out of the big three. That code is still ill formatted.

> Therefore, I would not be immensely excited over that entry as an
> employer.........

Don't ask for input and then get hostile when you don't like the response.

For me, this post ist EOD, because I frankly don't care to argue with
someone who is evidently not interested in improving themselves and instead
of being grateful for advice lashes out in an attempt to defend against a
practice that the vast, overwhelming majority of the Java development world
has adopted over a decade ago now.

[Antti J Ylikoski]

I asked for justified, matter-of-fact response. Why do you feel that
those demo programs were somehow bad? Hostility without grounds usually
leads to a sardonic response, as the response by me.

>
> For me, this post ist EOD, because I frankly don't care to argue with
> someone who is evidently not interested in improving themselves and instead
> of being grateful for advice lashes out in an attempt to defend against a
> practice that the vast, overwhelming majority of the Java development world
> has adopted over a decade ago now.
>
> Liebe Gruesse,
> Joerg
>

Ah, if you say that this Java code from GNU EMACS and the NetBeans is
ill-formatted, then maybe you could change to being constructive and
tell the newsgroup in which ways it is ill-formatted.

"....who is evidently not interested in improving themselves...."
That is an unsubstantiated allegation, as my circles would call it.

w/ kind regards, Dr Antti Ylikoski

[Arne Vajhøj]

????

He actually explained that your formatting did not follow
Oracle coding convention (also known as Java coding convention).

>> For me, this post ist EOD, because I frankly don't care to argue with
>> someone who is evidently not interested in improving themselves and
>> instead
>> of being grateful for advice lashes out in an attempt to defend against a
>> practice that the vast, overwhelming majority of the Java development
>> world
>> has adopted over a decade ago now.
>

> Ah, if you say that this Java code from GNU EMACS and the NetBeans is
> ill-formatted, then maybe you could change to being constructive and
> tell the newsgroup in which ways it is ill-formatted.
>
> "....who is evidently not interested in improving themselves...."
> That is an unsubstantiated allegation, as my circles would call it.

????

He pointed out the problem (formatting not following coding
convention) and you did not express any interest in investigating
the coding convention or changing your formatting.

Arne

[Arne Vajhøj]

That said then I don't think the code is that bad formatted.

If you use spaces instead of tab for indentation so that your
code looks right in editors with tab every 4 instead of
your tab every 8, then it is within normal deviation from the
coding convention in my opinion.

(your starting curly braces are not placed like the coding
convention prescribe, but you are not the only dissident in
this area)

But as is with editor tab every 4 it does not look good.

Arne

[Arne Vajhøj]

On 8/19/2014 6:39 AM, Joerg Meier wrote:
> On Tue, 19 Aug 2014 04:44:33 +0300, Antti J Ylikoski wrote:
>
>> On 15.8.2014 17:47, Joerg Meier wrote:
>>> On Fri, 15 Aug 2014 03:17:05 +0300, Antti J Ylikoski wrote:
>>>> I wrote a number of (small) Java demo programs for prospective
>>>> employers, and I feel that some ones among them are interesting and
>>>> nice enough so that someone over there may want them, maybe for nice
>>>> looking graphics demo purposes. (This entry is not here in order to
>>>> look for a job -- I only want to show those nice graphics demo
>>>> programs.)
>>> Very nice. However, if you are not looking for a math job but for a
>>> programming job, I recommend looking at the Oracle or the Google Java Code
>>> Conventions, as your code is ill formatted, and I would not be terribly
>>> excited over it as a potential employer.
>> Are you familiar with the GNU Emacs, the EMACS was considered the
>> world's best academic world text editor in its time? It still is
>> running strong.
>
> Yes, I am. It is, as far as Java goes, an antiquated dinosaur which, it
> appareas, does not even support proper code formatting.
>
>> That code has been formatted with the conventions of the GNU Emacs, and
>> was taken from the NetBeans IDE which I'm using. Do you know the NetBeans?
>
> Yes, Netbeans is Suns/Oracles IDE which is also generally considered the
> worst IDE out of the big three. That code is still ill formatted.

I don't think there is consensus that NetBeans is worse than Eclipse
and IntelliJ.

I believe we have more than a few NetBeans users here.

(I have never liked NetBeans, but that does not change that
other do)

Arne

[Eric Sosman]

On 8/14/2014 8:17 PM, Antti J Ylikoski wrote:
> I wrote a number of (small) Java demo programs for prospective
> employers, and I feel that some ones among them are interesting and
> nice enough so that someone over there may want them, maybe for nice
> looking graphics demo purposes. (This entry is not here in order to
> look for a job -- I only want to show those nice graphics demo
> programs.)
>
> Some interesting graphical demos are:
>
> The Hilbert Curves demo:
> (Modified and created, after the Deitel-Deitel textbook, and by
> myself. Originally was by Niklaus Wirth in the 1980's.)
> http://koti.mbnet.fi/bluejay/DrawPanel.java
> http://koti.mbnet.fi/bluejay/DrawPanelTest.java

> [...]

Everyone else is going on and on about formatting, so I thought
I'd offer a few remarks about the stuff other than white space. I've
only looked at the Hilbert curves code, so my observations may or may
not be relevant to the other things.

First: Put your code in named packages, and don't leave it in the
default "unnamed" package. It might sort of almost be all right to use
the unnamed package for programs whose code is completely contained in
one single source file, but as soon as you've got two or more files you
really, really, really ought to package them. Seriously. It will save
you a lot of headaches.

Second: Swing is not thread-safe, so nearly every manipulation of a
Swing object must occur on the Event Dispatch Thread. You'll find some
old tutorials and examples that construct and initialize entire GUI's
directly from main(), but that's because Sun themselves didn't realize
at first how pernicious the race conditions could be. A sample of how
to set up a GUI might look something like

public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable(
// This method will be called on the EDT:
@Override
public void run() {
// All the Swing setup happens here:
JFrame frame = new JFrame("Gooey");
...
frame.pack();
frame.setVisible(true);
}
));
...

(I've shown the "traditional Java" form; Java 8's "lambda expressions"
offer a sleeker way to write this.)

Third: Swing is not thread-safe, et cetera et cetera, so if you're
writing classes that extend or combine Swing components there will be
parts of your own code that must run on the EDT and you should take
steps to ensure that your class is used correctly by other classes.
For example, if your class extends JPanel (quite a common thing to do
in Swing applications), its constructor, like JPanel's, should only be
invoked on the EDT. Here's an idiom I find helpful:

public class DrawPanel extends JPanel {
public DrawPanel(...) {
super(...);
assert SwingUtilities.isEventDispatchThread();
...
}
...
}

There's no clean way to do the assert prior to invoking the superclass
constructor, but putting it just as early as possible will catch a lot
of careless errors during development instead of after deployment.

My remaining comments are about opportunities to streamline, clean
up, or otherwise improve the DrawPanel class.

Formally, the paintComponent() method receives a Graphics reference.
However, what Swing actually passes is a reference to a Graphics2D, a
Graphics subclass with additional capabilities. Among these are the
ability to establish a mapping between user-space and display-space
coordinates: You can translate, scale, rotate, or apply any arbitrary
affine transform. In brief, all that work you're doing to derive pixel
coordinates could be done for you by the Graphics2D methods.

... and done more accurately, in all probability. You've taken a
rather cavalier approach when converting floating-point to int values,
just chopping off any fractional part that might be present. This will
get you a value, sure, but not always the best value. You may "know"
that the result of some calculation should be 42, exactly, but because
floating-point calculations involve approximation the value you actually
compute might be 41.99999999932165357 instead. When you convert such a
number to int, you should consider whether to chop or round (probably
with one of the Math.round() methods). Graphics2D's mapping of user
coordinates to pixel coordinates is careful about such things.

Floating-point jitter also shows up in your intPower() method,
which I reproduce here for those who might not have seen it:

private static int intPower(int n, int e) // raise int to int power
{
return (int) Math.pow((double)n, (double)e);
} // end method intPower

(The (double) casts are unnecessary, by the way: Java knows the argument
types for Math.pow(), and will do the conversions without being told.)
The problem, again, is the approximate nature of floating-point: You may
call intPower(7,3) and "know" that the result should be 343, but the
computed value might be 343.0000000000003455 or 342.99999999992353256.
In the latter case, the naive conversion to int could surprise you by
raising an odd prime to an integer power and getting an even number!
Again, Math.round() would be a countermeasure.

A closer look, though: When your code calls intPower(), n is always
equal to 2 -- you never try to exponentiate any other value! There's
an easier and more straightforward way to raise 2 to an integer power:

private static int twoToThePower(int e) {
return 1 << e;
}

But a still closer look suggests the method is entirely unnecessary!
It's only called once, in this loop:

for(nn = 1; nn <= n; nn++) {
scale = intPower(2, nn+1);
...

That is, scale takes on the values 4,8,16,... in successive iterations.
You could just calculate those values as they come up, instead of going
through an entire "from scratch" exponentiation each time:

for (scale = 4, nn = 1; nn <= n; scale *= 2, nn++) ...

(Compiler implementors call this "strength reduction.")

We now return you to our featured program, an impassioned debate on
the proper arrangement of white space.

--
eso...@comcast-dot-net.invalid

[lipska the kat]

<snip>

An object lesson on how to give advice on Usenet. Excellent.

Even though you didn't actually *ask* for advice on your coding style
you have to expect a critique of your code when you do post it.

As an aside, some of the 'styles' you will see in this newsgroup are
far worse than yours (IMHO of course) so don't lose any sleep over it.



--
Lipska the Kat�: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[ĵess stone]

In article 1vjiwlgmscftb$.1o6estz8...@40tude.net, Joerg Meier
said...

> On Tue, 19 Aug 2014 04:44:33 +0300, Antti J Ylikoski wrote:
>
>> Are you familiar with the GNU Emacs, the EMACS was considered the
>> world's best academic world text editor in its time?
>

> Yes, I am. It is, as far as Java goes, an antiquated dinosaur which, it
> appareas, does not even support proper code formatting.

Jeezus, not so fricking loud! I agree with you, but don't let Bent C.
Dalager catch you saying things like that, or the froup'll wind up
embroiled in another two-year-long, 5000-post flamewar. :)