NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
I did a bit more research, and found out some more interesting facts. First, I added a straight Java serialization test to my test program. This test produces files identical to VisADForm's serialization mode, so therefore VisADForm serialization isn't "forcing" anything. What is actually happening, I discovered, is that even though I'm calling setSamples(double[][], boolean) to set my samples for the "doubles" FlatField, they are getting packed back into floats in FlatField.packValues, because the range type is set to floats. It turns out that the range type is only set to doubles if the provided *domain* set is a DoubleSet. This behavior seems somewhat non-intuitive. Therefore, my two FlatFields are actually identical. Although I'm not sure how to construct a FlatField with a DoubleSet based on Integer2DSet--so that when I call setSamples(double[][], boolean) it preserves the doubles array without copying--VisBio does not need that functionality anyway. What does matter is that the binary option does seem to be promoting to double, as you say. My question is, is such a promotion necessary? Is it being done for convenience; i.e., would preserving the float range type be a huge mess? I would appreciate comments from those responsible for coding the VisAD binary form (dglo?) regarding the feasibility of adding this support. Would it be a quick little hack for me to make the binary form preserve the floats, or would it be a huge project? Thanks, Curtis At 11:51 AM 7/22/2004, Tom Rink wrote: >Curtis, > >It looks like the binary option promotes to double, and the serial >option forces float? > >Tom > >Curtis Rueden wrote: > >>Hi, >> >>I was using Java serialization to save some FlatFields to a disk >>cache file. I decided to switch this logic over to the VisADForm >>binary writer. I noticed that the size of the FlatFields on disk >>doubled with this scheme. >> >>These FlatFields were populated with setSamples(float[][], boolean). >>I did some experiments with VisADForm in serialization vs binary >>mode, and with float[][] vs double[][], and I'm confused. >> >>Below is my test program. And here is the output: >> >>C:\java\test>java BinaryFieldSizeTest >>Float files should be ~400000 bytes. >>Double files should be ~800000 bytes. >> >>C:\java\test>ls -l *.vad >>-rw-r--r-- 1 root None 800271 Jul 21 16:58 binary-double.vad >>-rw-r--r-- 1 root None 800271 Jul 21 16:58 binary-float.vad >>-rw-r--r-- 1 root None 403626 Jul 21 16:58 serial-double.vad >>-rw-r--r-- 1 root None 403626 Jul 21 16:58 serial-float.vad >> >>It doesn't seem to matter if the FlatField has double[][] samples >>or float[][] samples. And the binary version is twice as large as >>the serialized version. In particular, it is disconcerting that >>the "serial-double.vad" is twice as small as it should be. >> >>Is something wrong with my code? Or is this behavior a bug? Is >>there an easy way around the problem? Is there an easy fix that >>could be applied to the VisADForm writer? >> >>Thanks, >>Curtis
visad archives: