Java

[Rupert_J_Young]

[From Rupert Young (970730.1130)]

(Rick Marken (970724.1250)

I finally got a chance to check out Rupert Young's Java demos of
control system operation at:

http://www.ee.surrey.ac.uk/cgi-bin/R.Young/java/javas.html

Nice work, Rupert! It's really great to see some Java demos written
by someone who actually knows how to write Java code;-) The demos
look great. I do have one suggestion, though. I think you should
label the graphs more clearly. I presume, for example, that time is
on the x axis but I can't tell what variables (in what units) are
being plotted over time.

Thanks. Yes I want to add things for the axes to make it clearer such as labels, tick marks, grids etc though these are non-trivial and time consuming but something I hope to get around to, eventually. For now the explanations are in the text (I think).

Well tomorrow I'm off to the big apple on route to Durango, see you all next week.

···

--
Regards,
Rupert

[Bill_Powers1]

[From Bill Powers (990925.0649 MDT)]

Rick Marken (990924.1400)--

I think that most of (all?) the people interested in the
CROWD program are on PCs so I think you all should just
stick with Pascal for the time being.

I'm quickly reaching that conclusion. Yesterday I downloaded all the Python
stuff and read through the tutorial and other docs. It started out very
simple and promising and I got my hopes up. But before I knew it, we were
into list-processing (Lisp) and object-oriented programming, and I was back
to where I was with Java.

I really don't understand what is supposed to be the charm of Lisp and OOP.
Specifically, what problems do you solve in those languages that you can't
solve in "regular" programming? I get a sense that the authors of these
languages don't just want to supply some tools for the programmer; they
want to tell the programmer how to think about the problem, too, and at
just one level. LISP is about ordered sequences; OOP seems to be about
categories. But of course both of them have to contain functions because
you can't actually represent real systems without functions, and both of
them have to contain logic for a similar reason. It seems to me that these
languages try to force a point of view on us, instead of letting us develop
our own.

Once one knows what one wants to do: what experiment they
want to conduct, what model they want to write, what demo
they want to create -- then I bet it will be relatively
easy to figure out what might be the best programming
language to use. And if more than one person wants to
collaborate on the project, then the collaborators will
end up using the same programming language.

I agree. I propose, as you suggest, that we do our behavioral modeling in
Turbo Pascal 7.0. If anyone wants to do it with OOP, fine, but OOP contains
too many arcane concepts, distractions for novices trying to learn about
models rather than programming languages.

Best,

Bill P.

[Bill_Powers1]

[From Bill Powers (990925/0705 MDT)]

Richard Kennaway (990925.0031 BST)--

The first thing I did was fire up CodeWarrior and create a new Java
applet project. This creates a source code file for a trivial "hello
world" applet, which I then compiled and ran as a check my system was
working ok. Then I added in your code, and compiled and ran it. It
appeared to work as it should, although my screen isn't big enough to
show the clipping at 600. So I reduced the clip bounds to 400*300 and
it worked. Remember that the third and fourth arguments to setClip()
are the width and height, not the positions of the right and bottom
edges.
My immediate guess was that setBackground is a member function of
Applet, not of Graphics. ... As such, it should be called in the init()

method of the applet

I did that and it still works. thanks.

Notice also that your code in the paint() method does not actually erase
the window before drawing the circles. Assuming that's what you want to
do, the routine to call is g.clearRect( left, top, width, height ).
clearRect() fills a rectangle with the background colour.

I added the clearing statement at the end, to help see when the run was
finished.

The biggest problem was in the .HTML file, where part of the statement sets
the size of the window. I had forgotten that. I'm running 1280 x 768
resolution, so my 300 x 200 window was pretty small. Now everything works
as it should.

If you decide to
try to explain it to me ...

How am I doing?

Excellent. ly.

You can also write Math.random(), provided you import java.lang.*. This
is why random() doesn't work, no matter what you import:

Did that; it works. One of my problems was that I forgot I was doing an
applet and tried to run the program via "java" instead of an html screen,
which just returns a lot of errors. I see that you can't import
"java.lang.Math.*" and just use "random()". Oh, well.

In Java, *every* function is a member function of some object or class.

...

To call the random() function of the Math
class, you must write Math.random().

It's beginning to make sense.

I can't find out how to draw a single point on the screen. There doesn't
seem to be a method for doing this in the Graphics class. Lines,
rectangles, and ovals, yes. Points, no.

That is true. To draw a point at (x,y), call g.drawLine( x, y, x, y )
or g.drawRect( x, y, 1, 1 ).

Interesting. It can draw 25000 1-pixel lines per second, but only 12,500
1-pixel rectangles per second. It also draws 12,500 ovals per second with a
radius of 5 pixels.

But weren't you complaining that the designers threw in everything that
everyone might want? Well, here's one they missed. You want there
should be a g.drawPoint() as well?

Yeah.

... I haven't used Swing yet, but I have a book devoted to it. It is
two hundred pages longer than "Java 1.1: The complete reference", and it
only deals with Swing.

I can see that if I use Java, it's going to be in a limited way. Thanks
much for your help. You're a good explainer.

Best,

Bill P.