Is there a NaN for non-double numbers?

  • Thread starter =?ISO-8859-1?Q?Jan_Thom=E4?=
  • Start date
?

=?ISO-8859-1?Q?Jan_Thom=E4?=

Hi,

i am trying to write some kind of registry that internally stores values
as strings. I wanted to provide some convenience methods which allow to
retrieve property values as int or float.

<code>
/**
* @see #getPropertyAsString(String)
*/
public double getPropertyAsDouble(String xPathToProperty);

/**
* @see #getPropertyAsString(String)
*/
public float getPropertyAsFloat(String xPathToProperty);

/**
* @see #getPropertyAsString(String)
*/
public int getPropertyAsInt(String xPathToProperty);

/**
* @see #getPropertyAsString(String)
*/
public long getPropertyAsLong(String xPathToProperty);

/**
* Convenience method to read a property as a string.
*
* @param xPathToProperty the xpath to the property.
*
* @return the property value as a string, null if no such property
can be found.
*/
public String getPropertyAsString(String xPathToProperty);

</code>

Now if the value doesnt exist or is not convertible to a
float/double/integer i cannot return null, since i want to return value
types. For the double value type there is a value called Double.NaN
which would be my candidate to return if the value doesnt exist or is
not convertible. However i found no such value in Float, Long, Integer.
Now my question is:

1. could I do something like:

<code>
public int getPropertyAsInt( String xPathToProperty ) {
....
if ( cannotConvertOrDoesntExist ) {
return (int) Double.NaN;
}
}
</code>

2. If i cannot do this, what other approach could be taken?

Thanks in advance for all your help.

Best regards,
Jan Thomä
 
S

Stefan Ram

Jan Thomä said:
Now if the value doesnt exist or is not convertible to a
float/double/integer i cannot return null, since i want to
return value types.

You might throw an exception in this case.

Or, return two values: A state indicator and the value:

return new int[]{ 1, 123 };

Or, return the wrapper objects instead, which the
client then can unbox after he has tested for null.
 
P

Patricia Shanahan

Stefan said:
You might throw an exception in this case.

Specifically, NumberFormatException exists to do exactly this job.

Even for double, returning a NaN would be bad practice given Java's
failure to distinguish different NaN values. The double may in fact
already be a NaN. "NaN" can be converted to double e.g. by Double's
valueOf method, and is possible output from Double.toString. It is a
legitimate value for double, and one an application may need to store
and retrieve.

Patricia
 
?

=?ISO-8859-1?Q?Jan_Thom=E4?=

Patricia said:
Stefan Ram wrote:
Even for double, returning a NaN would be bad practice given Java's
failure to distinguish different NaN values. The double may in fact
already be a NaN. "NaN" can be converted to double e.g. by Double's
valueOf method, and is possible output from Double.toString. It is a
legitimate value for double, and one an application may need to store
and retrieve.

Ah, thanks for pointing that out. I will stick to exceptions then.

Best regards,
Jan
 
M

Mark Thornton

Patricia said:
Even for double, returning a NaN would be bad practice given Java's
failure to distinguish different NaN values.
This has changed --- they can now be distinguished using the
Double.doubleToRawLongBits and Float.floatToRawIntBits methods.

Typically the docs don't say when this was added, but it has been there
for a while.

Mark Thornton
 
P

Patricia Shanahan

Mark said:
This has changed --- they can now be distinguished using the
Double.doubleToRawLongBits and Float.floatToRawIntBits methods.

Typically the docs don't say when this was added, but it has been there
for a while.

Mark Thornton

I should have said something like "distinguish completely" or
"distinguish consistently".

In a few cases, including Double.NaN, the NaN bit pattern is documented.
However, that is of limited use because much of the time it is
undocumented.

Patricia
 
D

Dimitri Maziuk

Jan Thomä sez:
Ah, thanks for pointing that out. I will stick to exceptions then.

Note that exceptions 1) come with run-time performance overhead,
and 2) should only really be thrown in exceptional circumstances.
So if you're going to see a lot of not-a-number values and that
is "situation normal", exceptions may not be the best way to go.

Typical solutions are domain-specific NaN (e.g. string searches
returning -1 as there is no negative position in a string) or
an extra check (e.g. JDBC's wasNull() returns true if previously
fetched value was a NULL).

To answer your question, it's a feature of two's complement
binary representation of integers: all possible bit patterns
represent valid numbers. So no, integer NaN is simply not
possible on modern computers.

Speaking of number representation, for floats there are several
bit patterns that do not represent a valid number, hence different
NaN values. Whether that makes any difference to your application
is domain-specific: if all you care for is a valid number, any NaN
is as good as another one.

Dima
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top