I've found a problem with setAutoRange() in HPlot where it crashes if plot values are too similar. The example code below shows up the problem. I found that I could avoid the problem by manually setting the range but wanted to flag it up anyway so someone can look into it in the distributed code. It's a bit strange this one, and doesn't seem to happen at all values, even with the same gap. I am using jHepWork version 3.3.

Thanks,

Andrew

Example code:

    public static void main(String[] args) {

        // Set values. Strange numbers in test are simply because they're the ones I found the problem with.
        double[] xValues={1,2,3,4,5};
        double[] test = {1.04999999999961,1.04999999999961,1.0499999999996101,1.04999999999961,1.04999999999961};

        // Fill P1d
        P1D testP1D = new P1D("test");
        testP1D.fill(xValues, test);
       
        // Plot it using autorange (which crashes) or manual axes (which doesn't). Comment out the relevant lines.
        HPlot actualPlot = new HPlot("test", 1280, 1024);
        actualPlot.setAutoRange();
//        actualPlot.setRangeAll(0, 6, 1.049999999999, 1.05);
        actualPlot.draw(testP1D);
        actualPlot.visible();
    }

jHepWork 3.3 is released. This release features high-performance containers (P0I,P0D,P1D,P2D) which are about factor 5-10 faster than the Java collections  or Python lists. It also includes a new 3D canvas, HPlot3XYZ, as well as an interactive fit engine.

admin

See the link http://jwork.org/jhepwork/wikidoc/doku. … lot_styles

Sergei

It happened earlier due to a bug which led to failures to start IDE on some platforms (Linux/Unix, Window XP).
Now it is fixed.

http://jwork.org/jhepwork/download/jhepwork-3.2.txt

Main features include:
 

• Symbolic (analytic) calculations can be done in Java or Jython

• Analytical calculation (Octave/matlab files) can be executed using the same "run" button as for jython/BeanShell/Java code.
      Also F8 can run matlab/octave code.

• [Help]->[jHepWork help] starts default browser with online manual. We do not include static manual with the application.

• Putting together the major financial Java packages.

• All API links redirected to Oracle API

• Symbolic calculations (simplify, integrate, expansion, differential). See jhplot.math.Symbolic

• HPlotter canvas - will use Jas/Aida style of plotting

Documentation:
  Contains description for analytic calculations
  Description for financial calculations

p>0.5 looks fine, I don't seem to be able to attach more that one file so I have attached the P<0.5 version.
With P=0.501 the mean was 10.059E00 but with P=0.499 it is 11.498E00 as you can see from the attached pdf a big dip where the bigest value would be expected.

I may have done something silly but can't see where to look for it.

Plotting the values from d1 in excel shows the same as the plot produced here.

this is my script:

from jhplot.math.num.random import *
from jhplot  import HPlot,H1D,HTable,HLabel,P0D
from jhplot.io.csv import *
p=0.5-0.001
s=20
n=1000
x1= BinomialRandomVariable(s,p)
d1=P0D("%s/%s"%(s,p))

c1 = HPlot("Canvas",600,400,1, 1)
c1.visible(1)
#c1.setAutoRange()
h1 = H1D("%s/%s"%(s,p),2*s+1, 0, s)

z=[]
for i in range(2*s+1+2):
   z.append(0)

for i in range(n):
   y1=x1.nextRandomVariable()
   d1.add(y1)
   h1.fill(y1)
h1.setErrors(z)
c1.draw(h1)
c1.setAutoRange()
c1.drawStatBox(h1)
lab=HLabel("%s samples"%n, 0.15, 0.7, "NDC")
c1.add(lab)
c1.update()

Please note that Java7 has some bug (or feature) and one  cannot run jhepwork on  Linux (fedora, ubuntu)
with Java7. Running using Window  should be fine, which is an idication that  there is  something wrong with Java7.
This bug report was posted on Java7 forum, but the issue was closed since it was difficult to reproduce this bug

A typical error running examples (as "Tools->JHPlot") is

Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
        at org.freehep.graphics2d.VectorGraphics.create(VectorGraphics.java:538)
        at jhplot.GHMargin.paintComponent(GHMargin.java:671)
        at javax.swing.JComponent.paint(JComponent.java:1054)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paint(JComponent.java:1063)
        at javax.swing.JLayeredPane.paint(JLayeredPane.java:585)
        at javax.swing.JComponent.paintChildren(JComponent.java:887)
        at javax.swing.JComponent.paintToOffscreen(JComponent.java:5228)
        at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManag

http://jwork.org/jhepwork/download/

It works with Java 6.  Running using Java 7 may  have some problems  (will be send to a separate post)

http://jwork.org/jhepwork/download/jhepwork-3.0b.txt

The release date for jhepwork 3.0 will be in August. It is planned to release 2 compiled
versions:  for java6 and java7 (will be official in July 28). In latter case,
all dependent packages will be recompiled using  JDK7.

Performance improvements for jhepwork  for JDK7  are expected up to  30-40% (compared to JDK6)
for array/matrix  manipulation (see, for example, this benchmark result
http://geeknizer.com/java-7-whats-new-p … -1-6-1-7/)

Sergei

We are using the JHPlot API in our scientific data acquisition software. Basically, the application runs a script that acquire and process data intermittently, then display the last processed data in a display window (built atop HPlot), every 1m30s approximately. For some unknown reason until yesterday, the application was always starting to act up on us after around 23h30 of execution.

We've been having this trouble for quite some time and I just figured out where it was coming from.

I'm running JVisualVM profiler against the running application. It looks like the java heap somehow gets filled up to its limit. But the JVM is smart enough to garbage collect just enough to prevent an outofmemoryexception. Looking at the GC activity, we notice it take a LOT of CPU activity.

When dumping the heap to a file and examine it more thoroughly, we notice it is completely filled with instances of 2 objects:
java.lang.ref.Finalizer
java.awt.Font

You heard right: Font objects filling up memory! This does seem like a memory leak, doesn't it?

The variable name that seems to be in cause is iniFonts, vector of java.awt.Font that is found in Jplot's Graph.java.

I'm running out of ideas on how to solve this. My best guess as to what's happening is well described here http://www.fasterj.com/articles/finalizer2.shtml. If you could help me out on this one, it would be greatly appreciated!

http://jwork.org/jhepwork/download/jhepwork-2.9.txt