[Chicago] Advice about a Java program?

Michael Maloney tac at tac-tics.net
Fri Oct 10 22:47:47 CEST 2014


One last thing I wanted to say!

You mentioned that it's nice that Python allows ints and floats to be kept
in the same list. I just wanted to issue a warning on that.

In 99.9% of situations, *keep your lists homogeneous*. That is, *don't* keep
more than one type of data in them. (This goes for any sort of collection).

The basic operations on lists are essentially:

1) taking a list and mapping a function over it
2) taking the list and filtering out items that don't interest you, and
3) reducing or folding the list into a summary value

All three of these require that the items in the list share some common
operations. For mapping, you need to supply a function that behaves for
every element in the list. For filtering, you need to supply a test that
makes sense for all elements. And for reduction, you need some binary
operation that works with each element.

So while it may seem neat that you can store elements of different types,
if you end up with, say, a list containing bools and ints together, the
number of "shared operations" that work on these is much smaller than
either a homogeneous list of bools or a homogeneous list of ints separately.

It *is* possible in Python to do a run-time test of what type an object is,
(and then presumably doing something intelligent based on the result).
However, it is arguably bad coding practice. It's easier to reason about
code that acts "uniformly" on their inputs, rather than dispatching based
on type. Runtime type inspection is also slightly nuanced when dealing with
subtyping, and in Python, it is limited in what it can tell you. (You can
tell an integer is an integer, but given a function, you can't tell what
inputs are valid nor what outputs to expect back from it).

In practice, mathematical and algorithmic code tends to be specialized to
one data type. (And perhaps re-implemented separately for different types,
say for single-precision floats then for double-precision floats). This is
because performance is often paramount in these domains. But just realize
that this kind of thing is done because it's necessary, not because it's a
good thing to do.

If execution speed wasn't an issue, you would want to parametrize your
matrix code by the data type. Java can do this (to some degree) with
subtyping and generic types. (It's a non-issue for Python because of its
lack of static typing).

At the risk of alienating some people, in mathematics, matrices are
commonly done over some arbitrary ring. (A ring is a set of numbers which
support addition, subtraction, and multiplication, but may or may not
support division). In Java, you might consider defining an abstract base
class called Ring with four methods: add, negate, and multiply. Then, for
your matrix code, instead of working with int[][]'s or double[][]'s, you
would have Ring[][]. Then, during matrix multiplication, any place you
would use matrix1[i][j] * matrix2[j][k], you would instead write it as
matrix1[i][j].multiply(matrix2[j][k]) (and analogously for addition).

Then, you could create an IntRing class where multiplication is just
integer multiplication, etc, and a FloatRing with the operations for
floats. I could also later decide to create a ComplexRing, and now, without
any changes to my code (which I made into a library and published to
Github), now works for complex numbers. I could also create a ModularIntRing,
where operations are taken mod some number for my (slow-ass, unverified)
crypto implementations! I could even have really fancy classes like
PolynomialRing or PowerSeriesRing, and now I can do a bit of symbolic
mathematics. Or I might make my Matrix class itself a Ring, and now I can
work with block matrices (with square blocks).

Of course, again, none of this matters in Python. Python trades away any
sort of static guarantees about your program for an incredible amount of
flexibility. The Java version, on the other hand, makes you jump through
more hoops up front, but it will also catch more errors at compile time.

I think I got carried away. If any of this doesn't make sense, just ignore
it!


On Fri, Oct 10, 2014 at 3:11 PM, Michael Maloney <tac at tac-tics.net> wrote:

> @Philip, I believe Douglas is taking a class, so unfortunately, Clojure is
> probably not an option. (Although I encourage anyone to look at Clojure).
>
> A few comments on the code:
>
> Watch your alignment. On line 11, for example, the block inside the main
> method lines up with the declaration. You want to tab it. Even though Java
> doesn't enforce indentation, you should pretend it is. On line 18 and other
> places, you've tabbed the curly brace. This is a relatively stylistic
> choice. (I think C programmers use it still, though?) Java's official style
> guide says opening curly braces should come at the end of the same line,
> closing curly braces should line up with the if/for/while statement or
> method declaration that opened it:
>
> while (...) {
>     // ...
>     // ...
>     // ...
> }
>
> At 101 lines of code, your main method is excruciatingly long. Most
> methods you write should to be between 1 and ~8 lines long. Highly
> algorithmic code (say, an implementation of a mergesort) might be around 30
> lines long. The main method of a script might be that long too in some
> cases. But 101 is enough to exhaust anyone's attention. As I mention in the
> other email I sent, you shouldn't need to double-space all of your code.
> And you should consider splitting the main method up into separate smaller
> "helper" methods.
>
> A good way to do this might be to break out these pieces: the code to read
> the user's dimension input (~18 lines), the user's choice of data type (~10
> lines), the user's entry input (~20 lines), and the output code (~30 lines).
>
> Even in cases where splitting a method up into separate pieces doesn't
> decrease the total line count of your program, it often helps your codes
> readability considerably. Especially if you choose your method names
> carefully, it's easier to glance at the function call and *guess* what it
> should be doing, without having to be presented with the gory details.
>
> I know none of this addresses your question directly, but often, having
> your code more organized will help you isolate the errors you run into.
> Rearranging your code to make it more understandable is what we call this
> refactoring. I don't know about the rest of the community, but I've always
> found it very relaxing. Like trimming a bonzai tree or raking the sand in a
> zen garden :)
>
>
> On Fri, Oct 10, 2014 at 1:21 PM, Philip Doctor <diomedestydeus at gmail.com>
> wrote:
>
>>
>> For console output I'd recommend checking the docs on how to pad numbers
>> into columns (
>> http://docs.oracle.com/javase/tutorial/java/data/numberformat.html).  If
>> this is not a homework assignment and you're allowed to use 3rd party
>> libraries I've never used it but I heard good things about
>> https://code.google.com/p/j-text-utils/ .
>>
>> Of course if you're not doing it for a class I'm not totally sure why you
>> would reinvent the wheel on matrix multiplication as there's tons good math
>> libraries out there for java that will do this:
>>
>> http://commons.apache.org/proper/commons-math/
>> http://math.nist.gov/javanumerics/jama/
>> https://code.google.com/p/efficient-java-matrix-library/
>>
>> (a dozen more if you google it)
>>
>> Best of luck (p.s. if jvm is a requirement but java isn't, I'm going to
>> fan-boy plug clojure as a language you might enjoy more given your
>> statements about python).
>>
>> /off-topic
>>
>>
>> On Fri, Oct 10, 2014 at 12:43 PM, Lewit, Douglas <d-lewit at neiu.edu>
>> wrote:
>>
>>> This is probably the wrong forum for this, but I thought I would give it
>>> a try because the people at my university cannot always be counted on for
>>> good feedback.
>>>
>>> I wrote this Java program that multiples two matrices.  I think it's
>>> basically pretty good.  (And doing this in Python is WAY EASIER because
>>> Python doesn't distinguish between lists of ints and lists of doubles, and
>>> actually allows both data types to get combined in the same list. )
>>>
>>> However, I'm having some issues with the formatted output of my "float"
>>> matrices.  They are technically doubles, but in the program I refer to them
>>> as floating point values for the sake of clarity because some users of the
>>> program may not know what a double is.  Is that like a double martini?  : )
>>>
>>>
>>> I'm trying to get all of my numbers lined up properly in their
>>> respective columns, but it's just not working out that way, even with the *printf
>>> *command.....???
>>>
>>> If anyone can offer some good suggestions about good formatting, that
>>> would be great.  I would really appreciate it.
>>>
>>> By the way, I did the same thing in Python and it took less than half as
>>> much code!  The Python code was short and to the point.  I guess Java has
>>> its uses, but for some things it is really tedious and overly complicated.
>>> Ah well.... but then again Java developers make really good money, so I
>>> guess I'll have to study both Java AND Python!
>>>
>>> Take care and thanks for the feedback.
>>>
>>> Best,
>>>
>>> Douglas Lewit
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20141010/b71b2e43/attachment-0001.html>


More information about the Chicago mailing list