Bug 462 : strange outOfBoundsArray when small double cast into float is passed to Rect();
Last modified: 2008-10-17 07:48



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2006-11-30 05:51
This small piece of code is worring me:

for ( int y=0;y<anncore.getNet().outputWeights.length;y++ )

The values I pass to the rect function come from getNet() which reads from
a thread.
I use the same values for any other output (like line() or println() ) and
I get no problems. It breaks when the sent values are specially low. If I
limit the production of the values to higher ranges (from the thread) then
there is no problem. I really think it doesn't have to do with Threads.

I use the 121-expert under windows. Eclipse platform

These are the values that the code is passing (printed with System.out.println)


java.lang.ArrayIndexOutOfBoundsException: 60200
at processing.core.PLine.drawLine_plain_spatial(PLine.java:769)
at processing.core.PLine.draw(PLine.java:404)
at processing.core.PGraphics3D.render_lines(PGraphics3D.java:1460)
at processing.core.PGraphics3D.endShape(PGraphics3D.java:988)
at processing.core.PGraphics.endShape(PGraphics.java:1111)
at processing.core.PGraphics3D.quad(PGraphics3D.java:2223)
at processing.core.PGraphics.rectImpl(PGraphics.java:1267)
at processing.core.PGraphics.rect(PGraphics.java:1262)
at processing.core.PApplet.rect(PApplet.java:7004)
at ANNGenerator.draw(ANNGenerator.java:41)
at processing.core.PApplet.handleDisplay(PApplet.java:1314)
at processing.core.PGraphics.requestDisplay(PGraphics.java:564)
at processing.core.PApplet.run(PApplet.java:1409)
at java.lang.Thread.run(Unknown Source)
Additional Comment #1 From alvaro 2006-11-30 05:54
another comment:

There is no problem when you simply do this, of course:

rect( (float)1.E-10, (float)1.E-10, 10, 10 );
Additional Comment #2 From alvaro 2006-11-30 06:03
Another addition:

I've discovered that it happens only with P3D rendering option.
Additional Comment #3 From fry 2006-12-01 06:52
that's a very large double... 8.0366003E8 is 8.0366003 x 10^8. the 1.E-10
is very small. we should still be able to catch it, so it qualifies as a
bug, but in general you're just confusing the renderer pretty badly. in the
meantime, it should be fixable by not using such large numbers.
Additional Comment #4 From fry 2006-12-01 06:53
may be a duplicate of bug #246.
Additional Comment #5 From fry 2008-10-17 07:48
fixed for 0151.