Raf Van de Plas

Kind of what I said in my most recent post.

Thx guys for the insight! Sometimes discussing the problem can already get the sting out of it .

Grtz,

Raf.

Since d == f is true, it seems that the internal representations of both variables are still behaving as expected. However, you might argue that the f is implicitly converted to a double and you're actually checking equality between two doubles.

My guess is that the difference shows up in the code that displays the value of a variable as a numeric value. When showing a float, this code probably figures out that 3.02 was meant (as its the closest possible value in all possible floats). When showing a double this code finds the even closer value of 3.0199999809265137 (not present in the 'world of float') and shows it.

If this hunch is correct then this entire situation might be as close to correct as possible on the machine level, but might introduce an intuitive 'gotcha'.

If this is a correct assumption then there's no real problem with using widening conversion in Java between float and double, but it does imply to remember that what you see is not necessarily what you've got (just very close to it).

Am I correct?

Raf.

Hi,

there's this annoying little conversion problem that is getting in my way.

I was under the impression that a widening conversion from a float to a double primitive (which happens implicitly without a cast) would conserve the original value completely. This however doesn't seem to be the case. Here's an example:
float f = 3.02f; System.out.println("float = " + f); double d1 = f; System.out.println("double via implicit conversion = " + d1); double d2 = Double.parseDouble(Float.toString(f)); System.out.println("double via String = " + d2);

The result is:
float = 3.02 double via direct conversion = 3.0199999809265137 double via String = 3.02

The problem is that when I explicitly want to store the value 3.02 in a float and it gets converted to a double, this double variable does not contain exactly what was in the float.

One thought is that double is not able to hold the 3.02 value exactly, but this is disproven by the 5th and 6th line of code where the conversion is done via a String object (how resource-wasting can you get ). Via this method the double does contain the value originally intended.

Another idea is that the original float variable didn't really contain the 3.02 but rather an approximation, and that this approximation shows up as a real intended value when the conversion to double happens.

Net result is that I have an intended value in the form of a float and I can only get this value exactly in a double by doing the conversion via a String object which is incredibly resource wasting... Apparently the widening conversion between float and double isn't as preserving as I thought.

Am I missing something here? Suggestions welcome.

Raf.

Hi guys,
I'm looking for a good java performance-related book with some references to scalability as well. So far, I'm thinking about "java performance and scalability" by Dov Bulka, but it's already pretty old (2000).
Any good alternatives out there? I hope you guys can give some good pointers.
Regards,
Raf

Hi,
a small remark here that's probably not the solution to you original problem, but what the hell...
In SAX a DefaultHandler doesn't garantee to read the characters between a start and end tag in one go. For example, if you've got '<moviename>The Terminator</moviename>', depending on the parser implementation, you can have one characters()-event giving you "The Terminator" but you can just as well have 6 character()-events that give you "Th", "e T", "erm", "in", "a", "tor".
Bottom line: don't perform your string adding in the characters()event but just append it to a StringBuffer there and the process the content of the buffer in the endElement()-event.
Just something I wanted to say,
Raf
The Angry Belgian

Hi Richard,
I haven't worked with this "Castor" before, so I can't really tell how it could/should be used.
But as external DTDs are specified in the XML 1.0 specification from the W3C it (Castor) should be able to understand them if it claims to work with XML.
My guess is that you're not referencing the DTD correctly when it's external. I suggest you check the correct syntax in some tutorial or the specifications.
Let us know how it turns out

Raf
The Angry Belgian

Hi,
First things first: my first name is simply 'Raf' (short for Raphael), all the rest is part of my surname.
Well it looks like you've got the main idea already. XML was conceived for separating the content from the presentation. I think this should give you ample possibilities for exporting the content of the courses you're offering to various media and formats (I'm thinking simple HTML on the site, the possibility to get a PDF, created server-side, with the same content but in a more printable form (just look for a simple PDF-generating script or app).
If everything already comes from a DB, you can still use XML to reduce access to the DB for the less important data. In fact I'm sure you've put certain data in the DB just because you needed some form of persistence and wanted to keep things as simple as possible (if not, you're the first I've heard of to be so disciplined ).
An example: If you're offering some form of help to your users, you could put the help topics and their explanation into an XML document instead of in a table in your DB.
In fact you can keep any information that is not subject to a lot of editing clear of the DB and unload it somewhat.
Another fine benefit of keeping not-frequently updated info out of the DB occurs when you've got extensive security features. When you're access to the DB is checked for security and validation, it would be a waste of resources to have to go through all that checking just to get to the read-only explanation of a certain help topic.
Hope this gives you some ideas, because it all depends on your situation and what you've got implemented at the moment.
What the link between OO and XML is concerned, you may be able to get some ideas from the JAXB at Sun (http://java.sun.com/xml/jaxb/index.html)
Anyway, any questions plz ask...
Raf
The Angry Belgian

Hey Ken,
tell us something more about what your objective is with that class you've got to give and why you want XML in it so badly.

I don't know wether you used an internal DTD (inside the XML document) or an external one.
To debug the DTD I suggest you take the DTD code you got and put it inside your actual XML code within the following construct:
<?xml version="1.0"?>
<!DOCTYPE socks [
<!ELEMENT socks ( sock* ) >
<!ELEMENT sock (name, image, color, price, smell) >
<!ATTLIST sock number CDATA #REQUIRED >
<!ELEMENT name (#PCDATA) >
<!ELEMENT image (#PCDATA) >
<!ELEMENT color EMPTY >
<!ELEMENT price (#PCDATA) >
<!ELEMENT smell (#PCDATA) >
<!ATTLIST color value (white|black) #REQUIRED >
]>
<socks>
...
</socks>

Check wether this still throws the same error. If so, you've got a genuine DTD syntax problem (I think).
If that's the case, plz reply with as much info as possible
Raf Van de Plas
The Angry Belgian

I'll take thirty while you're at it
Raf Van de Plas
The Angry Belgian

Hi,
I'm afraid I haven't had any experience with "mqseries" so I can't really say if XML serves a similar purpose, but you're partially right about the middleware-use of XML. I say partially because XML is much more than that single application. It can be used as universal data format between systems, never actually seen in that form by a user (=middleware). It can just as well be served directly to a customer (by applying a stylesheet or something). It serves as a common denomitor. Every single system that understands XML (and it's dictionary in the form of a DTD or schema) is able to talk with eachother.
About the Java server pages you're right: XML is not really necessary if you just want to show DB data on a webpage. But if you needed multiple clients to access the same set of data (some clients being webpages, but others being actual apps for example) it would be better to keep the access to the DB unified and simple through the use of XML.
Another benefit of XML, not very well known, is that it's much simpler to use for persistence of data if the dataset has rows that differ greatly in field fillup. In a relational DB this would mean that some rows would have a whole lot of empty or null values in fields that they really don't need, because somewhere there's a small number of rows that do need them. In XML you work more according to the OO paradigm and can individually add and remove to elements when necessary without causing a lot of empty fields in other elements.
Hope this clarifies things,
if not let me know
Raf Van de Plas
The Angry Belgian

I would like to point out my view on XML.
What happens today if you want to make a data format or document that needs to be read by multiple systems (= differences in hardware or software, it doesn't matter as long as they're different from eachother). You would decide on a certain way of storing your data and then have to adapt these systems to correctly interprete the document. This is often very difficult or even impossible and would often require source code and recompilation (I'm not even getting started about the hardware problems such as the big endian & little endian issue). The industry had to come up with a solution that was interpretable by almost any system and this meant using plain text. That way this solution (XML) is editable and viewable in any plain text editor, and this would be impossible with a binary format.
Then came the issue of how we're going to recognize certain data between other characters. For this part of XML, they used a subset of a standard that's around for almost 30 years, called SGML. They threw away the bits of SGML that weren't really worth their salt and created the XML 1.0 specification available at www.w3c.org. SGML and XML are not a language to encode data in a text-document, but they are meta-languages. This means: with XML you define a language for the specific purpose you want to achieve (and create whatever elements you need). Examples of such a language, defined by XML, are MathML and XHTML (The XML specification of HTML 4.0).
Well, I've given quite an extensive explanation about what exactly XML is, but maybe you're wondering why we need it.
XML is a way of making you're stored data available to programs other than the parent app that created the file in the first place. This can be done by adapting a system to understand XML or (if the legacy system cannot be changed) by using a separate XML parser that outputs a data format that the legacy system can understand.
In conjunction with databases, XML serves a rather subjective role. When you're data is resting on a system (i mean not moving through different architectures or needed by any program that doesn't understand a DB resultset) you should use whatever DB you use and handle you're data through SQL. But whenever you want to exchange data with some other source (like a file or other database) you're better off first converting to XML and then importing it in you're DB. (I know, the big databases often provide some function to import different data formats, but in the real world the one you need is often just not in the list and you're glad you can import XML).
Well I could go on like this forever but it's probably better if anyone with an XML question just posts it here and I'll try to give you my 2 cents about the solution.
Anyway raja, hope I could help you out. If not let me know too
-------------------------
Raf Van de Plas
The Angry Belgian

I don't have experience with mySQL-databases but I presume your working with the JDBC-classes. If that's the case you should get a ResultSet returned for any Statement (SELECT * FROM...) you throw at the database.
Construct a method that build a treemodel according to a resultset you pass it and call this method either when you know something has changed (when the database notifies you) or at predefined times (polling).
Simply run throught each record in the resultset and construct nodes as necessary. Then pass this model to the JTree via its setModel() method.
Hope this helps...
------------------