Re: Is anything easier to do in java than in lisp?
RobertMaas_at_YahooGroups.Com
Date: 06/30/04
- Next message: Silvio Bierman: "Re: Make BufferedReader.readLine() not consider \r EOL"
- Previous message: yamini: "Attribute "field1" invalid for tag testtag according to TLD"
- Maybe in reply to: RobertMaas_at_YahooGroups.Com: "Re: Is anything easier to do in java than in lisp?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 29 Jun 2004 22:52:49 -0700
> From: Antonio Menezes Leitao <Antonio.Leitao@evaluator.pt>
> You google for it. Type "interval arithmetic java" on google
I already did that several weeks ago.
> and you will get several promising links (they look promising to me,
> at least)
They looked promising to me too, until I actually clicked on the links
and started reading the details.
> - the Brandeis Interval Arithmetic Constraint Solver (with Java
> source code)
>>You need a java-enabled web brower to run the applet.
I don't have any such browser here on VT100 dialup into Unix shell. By
the way, Java Applets don't usually work. I wrote one for a class
assignment and put it up here: http://www.rawbw.com/~rem/Lab7.htm and
it works fine from InterNet Explorer in the computer lab at De Anza
College, but it doesn't work in InterNet Explorer in the instructor's
office, and it doesn't work in the classroom adjoining the computer
lab. (In the latter two places, the main dialog comes up, but none of
the buttons do anything.)
>>the current version is NOT sound since it relies on Java's underlying
>>math library which is not proven to be accurate to the last bit.
I.e. they don't really implement interval arithmetic, instead they use
ordinary sloppy floating-point arithmetic for the guts of it, then
pretend it's accurate when running interval constraints on top of that,
so it's not at all what I'm looking for which is interval arithmetic
where it counts to guarantee bounds on results of arithmetic
operations.
> - interval.sourceforge.net/interval (a 100% Java, verifiable
> implementation of interval arithmetic operations and constraint
> contractors for the arithmetic operations and elementary functions
> (exp,log,sin,cos,tan,asin,acos,atan,sin2pi,...)
>>Platforms supported
>> * RedHat Linux 6.1 on the PC and Macintosh OS X
>> Note: Porting to other architectures should not be hard. The only
>> non-portable code is that which deals with setting the rounding
>> modes!
The only java system I have access to from home is FreeBSD Unix, which
is neither of the above two systems. I have no idea what would have to
be done inside the jvm to set rounding modes on FreeBSD Unix.
> Is adding annonymous inner classes a minor change?
No, that's a major sort of thing. If I try to port somebody else's
software that depends on that in a key place, I'd probably have to
rewrite the whole module to get it to work under an old version of
java.
> Is adding automatic boxing and unboxing a minor change?
Yeah, it'd be a pain to explicitly box/unbox everywhere the compiler
gives an error message, if there are lots of places, but it's a simple
fix linear in number of such places, so I'd consider it a minor change.
> Is adding generic types a minor change?
I don't know what that phrase means in java jargon. I know what
abstract classes and interfaces are, and how you can declare a variable
of the generic class and make it dispatch at runtime. Also I know about
the Object class and how LISP-like no-declared-type programming can be
done by passing everything as Object variables to static methods and
then having the static method do a typecase of the argument to dispatch
to all the specific methods. But I don't know whether the phrase you
used is anything like either of those.
> I'm curious: what is your definition for "platform independent"?
If the desired task makes sense on a set of platforms, then the program
or whatever does that task on them all. For example, text-mode Web
browsing makes sense on both GUI systems and VT100 dialups, and indeed
some browsers work on GUI systems and some work on VT100 dialups so a
truly platform independent web browser would make sense, but in any
case using the appropriate web browser for each platform the text-mode
Web pages do indeed work on all such platforms. So text-mode Web pages
are in that sense platform independent. (They even work with
Web-by-email services!) There's no reason applets shouldn't work
everywhere HTML FORMs work, except the people in charge of java haven't
bothered to do that.
> The Linj compiler that translates from Linj to Java is written in
> Common Lisp and it needs a Common Lisp environment to run. It is the
> Linj compiler that is not platform independent because binary Common
> Lisp code is not platform independent.
Oops, sorry, in all this discussion of java classes that people say I
can download and run anywhere, I forgot Linj isn't java code. But if
you generate fasl files and then load them into a CL environment,
although the contents of the fasl files themselves are dependent on the
CPU, the process of making them is system independent (compile-file
..) so if you avoid calling anything from the SYSTEM package, if you
stick to making ANSI CL calls, it should be easy to make Linj run on
any ANSI-compliant CL system. I guess I'm overlooking something.
- Next message: Silvio Bierman: "Re: Make BufferedReader.readLine() not consider \r EOL"
- Previous message: yamini: "Attribute "field1" invalid for tag testtag according to TLD"
- Maybe in reply to: RobertMaas_at_YahooGroups.Com: "Re: Is anything easier to do in java than in lisp?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]