Java3D and Floating Point

Classes and methods that are like

javax.vecmath.Vector3f.cross(Vector3f v1, Vector3f v2)
javax.vecmath.Vector3d.cross(Vector3d v1, Vector3d v2)

can produce (ranged) innacurate, overflow or underflow
results in float and double return values, if the data for
the input vectors are in just the vulnerable but unavoidable
places.

-Is it possible that the logic for methods like this will be redone,
either just where things presently stand in Java, or ever as a
result of numeric value types that emerge with Project Valhalla?

-It is possible that JEP 306 would go ahead, eliminating any
such problem in the calculations of methods like these two examples?

https://bugs.openjdk.java.net/browse/JDK-8175916

Hey

The JEP 306 will be a bit helpful but how would the project Valhalla help? I don't think we'll modify the math classes.

By the way, Java3D 1.7 no longer uses the "javax" namespace.

I'm after a solution to floating point arithmetic overflow and underflow woes,
in terms of the float and double types already there, and while using =,-,*,/,% (and further)
operators and not method invocation. Mainly for float and double, Float and Double,
but also in terms of true Arbitrary Precision Arithmetic; for numbers
that have an infinitely pro extensible precision and/or scale.
These are conditions that BigInteger and BigDecimal in fact do not always meet.
Naturally there would needs be a StrictMath equivalent for such.

I had been lead to believe that value types could/would be a basis for numeric
Integer/Decimal  positive/negative value types, definable by the programmer via
the language (with some implemented ones probably included too),
that could be ranged arithmetic types, with ranges simlar to Float.MIN_VALUE
and Float.MAX_VALUE,  Double.MIN_VALUE and Double.MAX_VALUE, and even further.
They would probably have StrictMath transcendental libraries included.

The use for these being more number types that support operator syntax,
that do not ever suffer from numeric flow and overflow, might be (push and pull)
convertable to previous type values at least, might allow for an infinite
number of decimal places in values (contingent to recurring decimal curtailing
submitted instruction, and the available memory of the jvm).

I would view the the JEP 306 change as absolutely necessary somehow, probably
with both options for floating point and range accuracy modes.  Such a change may need
to apply to precompiled code that doesn't allow for insertion of any new commands to change
localised, floating point denormal or abnormal vulnerable code.

The Vector3d.cross and Vector3f.cross methods in java3d 1.6 are cases in point;
of floating point overflow and underflow vulnerable code that has been put in place
inside the language/major libraries (of which java3d and vecmath are held),
which could return slightly range innacurate results which programmers cannot rely on.

So I had been hoping Valhalla will produce better syntactic arithmetic type support, certainly.

I had been trying to learn any more about these areas, certainly what and when
and how likely JEP 306 is, and how certain/how far reliant industry might expect
some change.

Since you have mentioned it, is Java3D and its javadoc finished, and if so whereabouts are they?

Is there anyone involved in Java3D who might know any better that could reply
to these three areas here?

ZacharyABCD wrote

Since you have mentioned it, is Java3D and its javadoc finished, and if so whereabouts are they?

http://jogamp.org/wiki/index.php/Java3D_API_Documentation

Ah no, it isn't finished, but it is on the same server and directory as java3d 1.6, in pre-release, uncompleted fashion.

May you or anyone else involved with JoGamp and its forums reply to my questions, in terms of java float and double
floating point denormals, mathematics ranged types, operator syntax, true Arbitrary precision mathematics,
and/or [StrictMath] transcendental self type library support?

ZacharyABCD wrote

Ah no, it isn't finished, but it is on the same server and directory as java3d 1.6, in pre-release, uncompleted fashion.

How dare you write such things?! It's a JogAmp API, just face it, it's no longer maintained by Sun Microsystems / Oracle. Java3D 1.6.0-Final isn't a pre-release, it's a release. Nothing is perfect, feel free to tell us what is wrong, buggy or missing but it's not "uncompleted" (except Java3D 1.7 which is still a work in progress with one pre-release). You're the kind of person who makes confusion between classes within JavaFX 3D API and Java3D API whereas they are in different namespaces, I have no lesson to receive from you. Your remark is misleading and you clearly disparage our work. Some people find me touchy but enough is enough right now, you qualify the final version of Java3D 1.6 "uncompleted fashion".

We are volunteers, keep it in mind.

Phil and Harvey, feel free to answer other questions of course. Personally, I'm fed up.

Zachary,
I agree whole-heartedly with Julien's sentiments.

The documentation that he directed you to appears to me to have no issues.

The 1.7 JavaDoc is labelled "pre" because 1.7 is in pre-release, so that's entirely accurate and appropriate. It is also complete and well written (by Sun and SGI engineers mainly, many years ago).

The 1.6 JavaDocs are marked final as that is the status of 1.6.

The use of the same server is obviously the best place for these documents (who would change servers, that's crazy).

The use of the same folder is utterly irrelevant, it's clearly named "Java3D API Documentation". It's a pity we don't have the rest of the previous releases up there as well, along with the tutorials and examples.

I'm the current main maintainer of Java3D, but I don't have a in depth background in number representation in computer science so I'm not really in a position to make a definitive decision about the value to Java3D of investigating the proposals you outline.

Two other aspects of this cause me to not priorities looking into it as a matter of urgency.

1/ Accuracy and speed are always a trade off in computer processing, the goals of Java3D include performance, but not numerical accuracy (which is incorporated only in the Locale object), and also specifically state performance will always be chosen over other factors. If however evidence arises that JEP 306 or Valhalla are faster than java.math.* then that would increase their desirability.

2/ You appear to be somewhat  belligerent in your communications more recently, which in and of itself is not a major issue, however on top of that you also appear (to me) to not have the Java3D community and ecosystem's best interests at heart. So this makes me less inclined to investigate the issues you raise.

Phil.

No-one has cause to panic over my use of the word "uncompleted".  I'm not suggesting anything.
I was just hoping to ask after a little more information from the JoGamp end of things, were it pertinent.
:)

Is there anyone who can particularly respond with any news information about any upcoming changes to java floating
point arithmetic, particularly as impacts

javax.vecmath.Vector3f.dot
javax.vecmath.Vector3f.cross
javax.vecmath.Vector3d.dot
javax.vecmath.Vector3d.cross

methods, and the range accurary of their results?