Nevermind.
Pilot error.
In trying to create a small reproducible example, I found that one *CAN* in
fact assemble a Jar File URI as a string, with an appropriate path, and
then you CAN open a stream and it opens the right jar file.
It does require string hacking. The call
>
>
> Instead of feeding the new resource path (e.g. /d1/quux.dfdl.xsd) into
> getResource, can you strip off everything after the exclamation in the
> original jar path, append that new resource path, and use that as the
> new URI? This way there is no resource look up at all for relative paths.
The recent changes in Daffodil to include/import resolution was done
with the intention that relative paths were only expected only be found
in the same jar, and only absolute paths would look on the classpath.
This was done to make it for very simple logic to be used to transform
schemas to a
As of Java 20, the constructors for Java.net.URL have all been deprecated.
This has some implications for us. The matter is rather subtle, so bear
with me.
We use URL constructors so that a non-hierarchical URL, such as
jar:file:/foo.jar!/d1/d2/baz.dfdl.xsd can resolve a relative path such as
Let me summarize.
(1) Based on SL's observations, if you start from data containing binary
floating point numbers, round trip will be fine. We do not need an epsilon
approach, as converting the base 10 back to binary for comparison will
generate equal results. So all we need is xsi:type="double"
When doing floating point math, epsilon comparisons are pretty much
mandatory due to loss of precision.
But the TDML runner isn't doing math, we know *exactly* what value
should be written to the infoset so we should be able to do exact
comparisons.
Java 19 didn't changed the precision of
I think two different topics came into this thread. One is "doing the math",
and the other is "round-tripping".
When doing the math, 1.1 + 2.2 = 3.30003 or something similar in floating
point. There it is fine to round or epsilon difference to check that it is 3.3.
Trying to check more
As someone who did Fortran for over 30 using code libraries some written 60
years ago. The epsilon approach is baked in.
I think there are methods in some Java test frameworks where you can do an
Assert that will automatically handle epsilon internally.
Best,
Dave
Sent from my iPhone
> On
Floating point comparison is typically done with +- delta as Mike suggested.
Sincerely,
Harinder Sood
Senior Program Mnager
hs...@owlcyberdefense.com
240 805 4219
owlcyberdefense.com
The information contained in this transmission is for the personal and
confidential use of the
Based on what I've learned today from reading that bug, I think in Java
at least, float -> string -> float will give you back the exact same
float. Note that string -> float -> string could give a different
result, since multiple strings can map to the same float, but a float
maps to only a
The base 10 problem is very real. We face this in cybersecurity systems
where people want a full data rip and rebuild according to spec, yet want
100% the exact same bits out as went in. This isn't always possible with
base10 floating point representations. Some information is lost converting
from
One thing to note is that by putting a value in a TDML document such as
"12.34e56" it is actually a string. Comparing that to a floating-point value is
going to require a conversion from string and that could invoke a rounding step
if it cannot be accurately represented by a float. If you
+1 for type aware comparisons. It should be a very small change to this
function:
https://github.com/apache/daffodil/blob/main/daffodil-lib/src/main/scala/org/apache/daffodil/lib/xml/XMLUtils.scala#L1098
And just need to add xsi:type to a few expected infosets that are
sensitive to the issue.
A third alternative could be to round the result and compare against the
rounded value. Epsilon is probably the better idea. I think different infosets
per JVM would be too brittle and difficult to keep up-to-date.
// Mike
-Original Message-
From: Mike Beckerle
Sent: Sunday,
14 matches
Mail list logo
