[JSCIENCE-72] LargeInteger#valueOf(BigInteger) returns incorrect result for -1 possibly others? Created: 10/Dec/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Blocker
Reporter: hutchiko Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Issuezilla Id: 72

 Description   

Using version 4.3.1 LargeInteger#valueOf(BigInteger) converts the BigInteger
value "-1" into the LargeInteger value "-0":

assertEquals(-1, LargeInteger.valueOf(new BigInteger("-1")).intValue());

I have not investigated deeply but on face value this appears to be a missed
corner case.

My workaround is to use the String version of the factory:

LargeInteger.valueOf(someBigInteger.toString())






[JSCIENCE-69] AlternateUnit constructor results in a NPE if the 'parent' argument is a non-standard unit Created: 28/Nov/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Blocker
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 69

 Description   

This issue was noticed in JScience v4.3.1.

If the parent argument to the AlternateUnit constructor is not a standard unit,
this results in a NullPointerException. I believe this occurs because the
string expression argument to 'new UnsupportedException(...)' references 'this',
when maybe it should use 'parent'.

The relevent code snippet from AlternateUnit(String symbol, Unit<?> parent) is
shown below.

if (!parent.isStandardUnit())
throw new UnsupportedOperationException(this
+ " is not a standard unit");






[JSCIENCE-65] Amount.root(n) for odd roots (n) does not work for negative values Created: 08/Oct/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Blocker
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File AmountOddRootOfNegativeValueTest.java    
Issuezilla Id: 65

 Description   

The Amount.root(int n) method for odd roots does not work for negative values.

For example Amount.valueOf( -8, SI.METRE.pow(3) ).root( 3 ) should result in an
Amount of "-2 m". However, it actually returns an amount with a value of NaN.

I will attach a small JUnit test for a few odd root cases.



 Comments   
Comment by shanmann [ 08/Oct/07 ]

Created an attachment (id=8)
JUnit test for some odd roots of negative values.





[JSCIENCE-98] Real.valueOf(doubleValue) doesn't work if doubleValue is negative Created: 23/Jul/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Blocker
Reporter: littlea11 Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 98

 Description   

I get an AritmeticException when doing the following:

Real number = Real.valueOf(-3.3254);

The exception is:

Exception in thread "main" java.lang.ArithmeticException: Negative number or
zero
at javolution.lang.MathLib.floorLog2(Unknown Source)
at javolution.lang.MathLib.floorLog10(Unknown Source)
at org.jscience.mathematics.number.Real.valueOf(Real.java:203)
at com.ml.pa.scenarios.Master.main(Master.java:103)

But it is ok if I do

Real number = Real.valueOf(-3);

I can get around it by doing:

Real number = Real.valueOf(3.3254);
number.times(-1);

Here is the code of Real.valueOf:

-------------------------------------------------------------
/**

  • Returns the real number (inexact except for <code>0.0</code>)
  • corresponding to the specified <code>double</code> value.
  • The error is derived from the inexact representation of
  • <code>double</code> values intrinsic to the 64 bits IEEE 754 format.
  • @param doubleValue the <code>double</code> value to convert.
  • @return the corresponding real number.
    */
    public static Real valueOf(double doubleValue) { if (doubleValue == 0.0) return Real.ZERO; if (Double.isNaN(doubleValue) || Double.isInfinite(doubleValue)) return Real.NaN; // Find the exponent e such as: value == x.xxx * 10^e int e = MathLib.floorLog10(doubleValue) - 18 + 1; // 18 digits significand. long significand = MathLib.toLongPow10(doubleValue, -e); int error = (int) MathLib.toLongPow10(Math.ulp(doubleValue), -e) + 1; return Real.valueOf(LargeInteger.valueOf(significand), error, e); }

------------------------------------------------------------------------
If MathLib.floorLog10 does what the name says, it won't work unless the
argument is greater than zero.






[JSCIENCE-82] MultiplyConverter's "Identity converter not allowed" constraint can cause Unit.equals() and UnitConverter.equals() to fail Created: 30/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Blocker
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 82

 Description   

This problem was noticed in JScience 4.3.1.

MultiplyConverter's "Identity converter not allowed" constraint can cause
Unit.equals() and UnitConverter.equals() to fail, when they should succeed.

The following example demonstrates a case where this constraint in
MultiplyConverter is "tripped" during a Units.equals(Object) call. Note that
the example below requires that issue #80 in
UnitFormat.DefaultFormat.readLong(CharSequence) be fixed before this example
code will result in the example output below.

It may also be that this constraint in RationalConverter could also be "tripped"
during an equals() call, but an example that would do so was not looked for.

---- Begin example code ----
package jscience;

import javax.measure.unit.NonSI;
import javax.measure.unit.SI;
import javax.measure.unit.Unit;

import org.jscience.JScience;

public class UnitEqualsExample {
public static final void main( final String[] args )

{ System.out.println( "JScience.VERSION=" + JScience.VERSION ); final Unit<?> unit1 = NonSI.FOOT.times(SI.KILO(NonSI.POUND_FORCE)); // NOTE: This Unit.valueOf() call requires that // UnitFormat.DefaultFormat.readLong(CharSequence) is fixed to // handle integer values larger than what an int can hold. See // https://jscience.dev.java.net/issues/buglist.cgi issue #80. // final Unit<?> unit2 = Unit.valueOf( unit1.toString() ); // The following equals() should work and return true, but an // "Identity converter not allowed" IllegalArgumentException is thrown // by MultiplyConverter constructor. // final boolean equalsResult = unit1.equals( unit2 ); System.out.println( "equalsResult = " + equalsResult ); }

}
---- End example code ----

---- Begin output ----
JScience.VERSION=4.3.1 October 4 2007
Exception in thread "main" java.lang.IllegalArgumentException: Identity
converter not allowed
at javax.measure.converter.MultiplyConverter.<init>(MultiplyConverter.java:36)
at javax.measure.converter.RationalConverter.concatenate(RationalConverter.java:95)
at javax.measure.converter.UnitConverter.equals(UnitConverter.java:84)
at javax.measure.unit.TransformedUnit.equals(TransformedUnit.java:100)
at javax.measure.unit.ProductUnit.equals(ProductUnit.java:301)
at jscience.UnitEqualsExample.main(UnitEqualsExample.java:28)
---- End output ----



 Comments   
Comment by shanmann [ 06/Feb/08 ]

After looking into this a little deeper, I believe a possible fix for this issue
is that RationalConverter.concatenate(UnitConverter)'s handling of "Long
overflows" should return UnitConverter.IDENTITY when ((dividendDouble /
divisorDouble) == 1.0), instead of (new MultiplyConverter(dividendDouble /
divisorDouble)).

Comment by shanmann [ 06/Feb/08 ]

After looking into this a little deeper, I believe a possible fix for this issue
is that RationalConverter.concatenate(UnitConverter)'s handling of "Long
overflows" should return UnitConverter.IDENTITY when ((dividendDouble /
divisorDouble) == 1.0), instead of (new MultiplyConverter(dividendDouble /
divisorDouble)).





[JSCIENCE-83] Unit.valueOf(CharSequence) parsing error due to readDouble() advancing parser one character too far Created: 31/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Blocker
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 83

 Description   

This problem was noticed in JScience 4.3.1.

When Unit.valueOf(CharSequence) contains a float value, a parsing error results
due to UnitFormat.DefaultFormat.readDouble(CharSequence,ParsePosition) advancing
the parser one character too far. This occurs at the line 'pos.setIndex(end+1)'
just after the end of the while loop. The 'end+1' should just be 'end'.

---- Begin example code snippet ----
System.out.println( "JScience.VERSION=" + JScience.VERSION );

final Unit<?> unitWithFloatBad = Unit.valueOf( "m*123.56/s" );
---- End example code snippet ----

---- Begin output ----
JScience.VERSION=4.3.1 October 4 2007
Exception in thread "main" java.lang.IllegalArgumentException:
java.text.ParseException: unexpected token 1
at javax.measure.unit.Unit.valueOf(Unit.java:482)
at jscience.UnitValueOfFloatIndex1TooFar.main(UnitValueOfFloatIndex1TooFar.java:11)
Caused by: java.text.ParseException: unexpected token 1
at
javax.measure.unit.UnitFormat$DefaultFormat.parseProductUnit(UnitFormat.java:468)
at javax.measure.unit.Unit.valueOf(Unit.java:479)
... 1 more
---- End output ----






[JSCIENCE-81] Unit.valueOf(CharSequence) parses float values incorrectly Created: 29/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Blocker
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 81

 Description   

This problem was noticed in JScience 4.3.1.

Unit.valueOf(CharSequence) parses float values incorrectly because
UnitFormat.DefaultFormat.readDouble(CharSequence,ParsePosition) does not include
any characters at or beyond the decimal point ('.') in the String passed to
Double.parseDouble(String). This also causes the decimal point ('.') being
parsed as the start of the next token, which results in the
'java.text.ParseException: unexpected token 1' shown in the example output below.

---- Begin example code ----
package jscience;

import javax.measure.quantity.Length;
import javax.measure.unit.SI;
import javax.measure.unit.Unit;

import org.jscience.JScience;

public class UnitValueOfFloat {
public static void main( final String[] args )

{ System.out.println( "JScience.VERSION=" + JScience.VERSION ); final Unit<?> unitWithFloatBad = Unit.valueOf( "m*1234.56" ); System.out.println( "unitWithFloatBad=" + unitWithFloatBad ); }

}
---- End example code ----

---- Begin output ----
JScience.VERSION=4.3.1 October 4 2007
Exception in thread "main" java.lang.IllegalArgumentException:
java.text.ParseException: unexpected token 1
at javax.measure.unit.Unit.valueOf(Unit.java:482)
at jscience.UnitValueOfFloat.main(UnitValueOfFloat.java:13)
Caused by: java.text.ParseException: unexpected token 1
at
javax.measure.unit.UnitFormat$DefaultFormat.parseProductUnit(UnitFormat.java:468)
at javax.measure.unit.Unit.valueOf(Unit.java:480)
... 1 more
---- End output ----



 Comments   
Comment by shanmann [ 29/Jan/08 ]

I missed the source of the problem when I originally looked at the
readDouble(CharSequence,ParsePosition) method. The string in the following is
missing a '4', "012356789+-.E".indexOf(csq.charAt(end)).





[JSCIENCE-80] Unit.valueOf(CharSequence) parses large integer values incorrectly Created: 28/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Blocker
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 80

 Description   

This problem was noticed in JScience 4.3.1.

Unit.valueOf(CharSequence) parses large integer values incorrectly because
UnitFormat.DefaultFormat.readLong(CharSequence,ParsePosition)
uses an int to hold the intermediate results (int result) instead of a long.

---- Begin example code snippet ----
final Unit<?> unitBigInteger = SI.KILO( NonSI.POUND_FORCE );
final Unit<?> unitBigIntegerBad = Unit.valueOf( unitBigInteger.toString() );

System.out.println( "unitBigInteger = " + unitBigInteger );
System.out.println( "unitBigIntegerBad = " + unitBigIntegerBad );
---- End example code snippet ----

---- Begin output ----
unitBigInteger = N*8896443230521/2000000000
unitBigIntegerBad = N*313192101/400000000
---- End output ----






[JSCIENCE-160] SI.GRAM definition is wrong Created: 01/Sep/11  Updated: 01/Sep/11

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Philippe Laflamme Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File issue-160.patch    

 Description   

The SI.GRAM is currently defined as:

new TransformedUnit(KILOGRAM, SIPrefix.KILO.getConverter())

Which (if I read this correctly) says that the GRAM is "a KILO KILOGRAM". The prefix should be MILLI. The following code demonstrates the issue:

SI.GRAM.getConverterTo(SI.KILOGRAM).convert(1000)

This should return 1.0, but returns 1000000.0.



 Comments   
Comment by Philippe Laflamme [ 01/Sep/11 ]

Patch against r53 to fix this issue.





[JSCIENCE-174] [PHYSICS] Amount.INCREMENT is exactly 1.0 Created: 23/Nov/14  Updated: 23/Nov/14

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: sukarsono Assignee: dautelle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

REPRO:
1) Create an Amount instance from a positive double with any constructor that does not explicitly set the error bounds
2) Check the value of getMaximumValue()

Expected: getMaximumValue() returns a double that is larger than the double used to instantiate the Amount
Actual: getMaximumValue() returns the double used to instantiate the Amount

Why? The static DOUBLE_RELATIVE_ERROR of 2^-53 is smaller than the java machine 1.0+ epsilon so INCREMENT is exactly equal to 1.0



 Comments   
Comment by sukarsono [ 23/Nov/14 ]

PS: to confirm the claim in the "Why?" portion just try this in any java environment:

1.0 + Math.pow(2, -53) == 1.0;
1.0 + MathLib.pow(2, -53) == 1.0;
Comment by sukarsono [ 23/Nov/14 ]

PPS: Quick fix should be to just make DOUBLE_RELATIVE_ERROR = 2^-52 though of course this would produce (unavoidable) backcompat breakages.

PPPS: Amount in the summary refers to org.jscience.physics.amount.Amount





[JSCIENCE-165] 5.0-SNAPSHOT POM Requires Update for JAVOLUTION Created: 06/Dec/12  Updated: 06/Dec/12

Status: Open
Project: jscience
Component/s: Economics, Mathematics, Physics, www
Affects Version/s: Version 5.0
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: goulash1971 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse Juno (Mac OsX 10.8)


Tags: maven

 Description   

Hi guys

The JAVOLUTION SNAPSHOT has been renamed as javolution-6.0.0-SNAPSHOT.

Therefore the POM for the 5.0-SNAPSHOT needs to be updated, otherwise it will fail on dependencies.

Regards
Stuart



 Comments   
Comment by goulash1971 [ 06/Dec/12 ]

II can see that you have already addressed this in SVN as 5.0.0.

Will keep the issue open until you've pushed this through build through to Maven.

  • Stuart




[JSCIENCE-133] Fix for LargeInteger.sqrt and LargeInteger.divide Created: 15/Feb/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 133

 Description   

This fixes JSCIENCE-76 and JSCIENCE-102.

First, there is a bug in LargeInteger.divide:
if ((that._size <= 1) && ((that._words[0] >> 32) == 0))
return divide(that.intValue());
should read
if ((that._size <= 1) && ((that._words[0] >> 31) == 0))
return divide(that.intValue());
since intValue returns a negative value for _words[0] > 2<<31.

Second, sqrt was broken since it does not work for 0 and 1, often returns wrong
values and does not even terminate for some values, since the iteration forever
oscillates between, say, 2 and 3. My suggestion is:

public LargeInteger sqrt() {
if (this.isNegative()) throw new ArithmeticException("Square root of
negative integer");
if (equals(ZERO)) return ZERO;
if (equals(ONE)) return ONE;
int bitLength = this.bitLength();
StackContext.enter();
try {
// First approximation.
LargeInteger k = this.times2pow(-((bitLength >> 1) + (bitLength & 1)));
while (true) {
LargeInteger newK = k.plus(this.divide(k)).times2pow(-1);
if (!newK.minus(k).isLargerThan(ONE)) {
if (this.divide(newK).isLessThan(newK))

{ newK = newK.minus(ONE); }

return StackContext.outerCopy(newK);
}
k = newK;
}
} finally

{ StackContext.exit(); }

}

Tests for this are in my testsuite.






[JSCIENCE-126] Bug in LargeInteger.compareTo(long) Created: 19/Jan/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 126

 Description   

Currently we have that
LargeInteger.valueOf(Long.MIN_VALUE).compareTo(Long.MIN_VALUE)
yields -1.

The problem is in compareTo:

public int compareTo(long value)

{ if (_size > 1) return (value == Long.MAX_VALUE) && (this.equals(Long.MIN_VALUE)) ? 0 : (_isNegative ? -1 : 1); // size <= 1 long thisValue = _isNegative ? -_words[0] : _words[0]; return thisValue < value ? -1 : ((thisValue == value) ? 0 : 1); }

The first return statement should contain Long.MIN_VALUE twice, not
Long.MAX_VALUE and LONG.MIN_VALUE.






[JSCIENCE-123] Fix for "-0" == FloatingPoint.valueOf(Biginteger(-1)) Created: 16/Jan/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 123

 Description   

This solves Bug#72: LargeInteger.valueOf(java.math.BigInteger.valueOf(-1)) is "-0".
The problem is that in LargeInteger.valueOf(bytes,offset,length) the _size is
incorrectly set to 0 in this case. My fix for that is to include the line
if (isNegative && wordIndex < 0) wordIndex = 0; // special case for -1
just before
li._size = wordIndex + 1;

Caution: I don't understand the code completely and this is probably not the
most elegant fix. It seems to work though - my unittests verify this works with
a number of values.






[JSCIENCE-121] Important metedata methods missing Created: 05/Jan/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Critical
Reporter: scastria Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 121

 Description   

If I was trying to create a GUI for performing unit conversions between any two
units of the same quantity, I would need to create a list of all quantities.
However, I don’t see any mechanism in your API to get a list of available
quantities. I do see that I can list out all of the units from the
SystemOfUnits class so I thought I would list out each unit and then get the
Quantity for each one to build my own list. However, I don’t see how I can get
the Quantity string name for a given Unit instance.

My second problem is that I would like to present the user with a long name of
each unit in addition to the abbreviation or symbol. However, I don’t see any
mechanism in your API to get a long name of a Unit instance. Like I want to
display “meters� instead of just “m�.

Am I missing something?

Need a getQuantites() method somewhere to list out all Quantities supported by
the API
Need a Unit.getQuantity() method so the Quantity supported by a given Unit
instance can be discovered
Need a SystemOfUnits.getUnitsForQuantity(Quantity q) method so all the Units
that support the specified Quantity can be discovered
Need a Unit.getSymbol(), Unit.getName(), Unit.getDescription(), etc to get more
metadata about each Unit. Not sure if this should be in the UnitFormat or not,
be it should be somewhere.






[JSCIENCE-120] Contribution: regression testsuite for number package Created: 23/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive jsciencetestsandfixes-090219.zip     Zip Archive numbertestsuite.zip    
Issuezilla Id: 120

 Description   

Hi!

After talking to Jean-Marie I started writing a regression testsuite for the
number package, since there are a quite a couple of bugs. Here is my first shot.
It is not yet complete (about 50% code coverage of
org.jscience.mathematics.number) but I need some feedback, since major changes
become more and more a pain the more tests there are. Thanks!

Hans-Peter



 Comments   
Comment by hstoerr [ 23/Dec/08 ]

Created an attachment (id=17)
Preliminary testsuite for the number package.

Comment by hstoerr [ 19/Feb/09 ]

Created an attachment (id=20)
Testsuite and fixed sources for the number package, zip.

Comment by hstoerr [ 19/Feb/09 ]

The file jsciencetestsandfixes-090219.zip contains my testsuite for the number
package and the sourcefiles with fixed bugs. And there is a modified ant
buildfile that compiles and executes the tests and builds the jars only if the
tests execute without exceptions.

The file numbertestsuite.zip can be deleted.

Unfortunately I haven't reached my goal of zero known bugs for the number
package. The Real class contains still known bugs and I think there are
functionality changes necessary. There are only tests that do not cover the
error functionality. But I don't have the time for this at the moment, so don't
wait for it with the release.

I've covered most of the methods - the code coverage is at 90%. One could
probably expand the ComplexTestSuite a little and RealTestSuite, of course.

Best regards,

Hans-Peter





[JSCIENCE-124] LargeInteger.LONG_MIN_VALUE missing sign Created: 18/Jan/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 124

 Description   

LargeInteger.LONG_MIN_VALUE is currently positive. This breaks times(long) for
Long.MIN_VALUE. In the static initializer there should be the additional line
LONG_MIN_VALUE._isNegative = true;






[JSCIENCE-118] FloatingPoint.round and LargeInteger.FIVE are broken Created: 23/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 118

 Description   

FloatingPoint.round(FloatingPoint.valueOf(0.9)) yields 0 instead of 1.
This is due to two bugs:
LargeInteger.FIVE has copy and paste errors: it should be
static final LargeInteger FIVE = new LargeInteger(1);
static

{ FIVE._words[0] = 5; FIVE._size = 1; }

(By the way: shouldn't LargeInteger.LONG_MIN_VALUE be negative?)

Second, the third line of FloatingPoint.round should read
LargeInteger half = LargeInteger.FIVE.times10pow(-_exponent-1);
instead of
LargeInteger half = LargeInteger.FIVE.times10pow(_exponent - 1);

The same problem applies to Real.



 Comments   
Comment by hstoerr [ 23/Dec/08 ]

This should be a patch instead of an issue, since I included a fix.
Tests to verify the fix are included in issue 120.





[JSCIENCE-115] FloatingPoint.valueOf and Real.valueOf throw on negative values Created: 12/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 115

 Description   

If you call FloatingPoint.valueOf(double) with negative values, you get an
java.lang.ArithmeticException: Negative number or zero .

Solution: in FloatingPoint.valueOf(double) the line
int e = MathLib.floorLog10(doubleValue) - 18 + 1; // 18 digits significand.

should be replaced with

int e = MathLib.floorLog10(MathLib.abs(doubleValue)) - 18 + 1; // 18 digits
significand.

(This has a different cause from Issue 113 and I have already a solution, so I'm
submitting this separately.)

I would also suggest adding the lines
if (doubleValue == 1.0)
return FloatingPoint.ONE;
to this function.

Best regards,

Hans-Peter



 Comments   
Comment by hstoerr [ 15/Dec/08 ]

The same problem with the same solution exists in Real.valueOf(double) .

Comment by hstoerr [ 23/Dec/08 ]

This should be a patch instead of an issue, since I included a fix.
Tests to verify the fix are included in issue 120.





[JSCIENCE-116] Real.valueOf(CharSequence) does not work for -0.XXX Created: 15/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 116

 Description   

If you give values to Real.valueOf(CharSequence) that start with -0. the answer
is positive. This is since the value before the decimal point is interpreted as
an integer and is checked later for being negative - which does not work if it
is zero. A consequence is that the same error appears at
FloatingPoint.valueOf(CharSequence) as well.

To fix this one can insert the following 3 lines at the start of the function:
if ('-' == chars.charAt(0))

{ return valueOf(chars.subSequence(1, chars.length())).opposite(); }

 Comments   
Comment by hstoerr [ 23/Dec/08 ]

This should be a patch instead of an issue, since I included a fix.
Tests to verify the fix are included in issue 120.





[JSCIENCE-113] LargeInteger.digitLength is broken Created: 09/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Critical
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 113

 Description   

The following is actually true:
assertEquals("0.899999999999999967",FloatingPoint.valueOf(0.09).toString());
(Should be 0.08999... or something.)
I believe the bug is actually in LargeInteger.digitLength but I did not
completely understand it.



 Comments   
Comment by hstoerr [ 13/Dec/08 ]

The Bug in FloatingPoint.valueOf I originally submitted is actually caused by a
broken LargeInteger.digitLength : it yields 2 for the number 9.

Suggested fix:

public int digitLength()

{ int bitLength = this.bitLength(); int min = (int) ((bitLength-1) * BITS_TO_DIGITS) + 1; int max = (int) (bitLength * BITS_TO_DIGITS) + 1; if (min == max) return min; return (LargeInteger.ONE.times10pow(min).isLargerThan(this)) ? min : min + 1; }

The testcase that works now is:

assertEquals(1, LargeInteger.ZERO.digitLength());
assertEquals(1, LargeInteger.ONE.digitLength());
long val = 10;
int len = 2;
while (val < Long.MAX_VALUE / 10)

{ LargeInteger l = LargeInteger.valueOf(val); assertEquals(l.toString(), len, l.digitLength()); assertEquals(l.toString(), len, l.plus(LargeInteger.ONE).digitLength()); assertEquals(l.toString(), len - 1, l.plus(LargeInteger.ONE.opposite()).digitLength()); val *= 10; len++; }

One more thing: the bitLength of 0 is set to 0 but the digitLength is both with
and without my fix 1. This is inconsistent, but I don't know whether it should
be 0 or 1 in both methods.

Best regards,

Hans-Peter

Comment by hstoerr [ 23/Dec/08 ]

This should be a patch instead of an issue, since I included a fix.
Tests to verify the fix are included in issue 120.





[JSCIENCE-105] MeasureFormat.parse returns wrong value for negative numbers expressed using a CompoundUnit Created: 06/Oct/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Critical
Reporter: zeled Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File MeasureFormatTest.java    
Issuezilla Id: 105

 Description   

Value aggregated during parse of a measure which is expressed using CompoundUnit
symbols (like °:':") is wrong if the leading value is a negative number.

For example, parsing 13°15' gives -765' (-13*60+15) instead of -795' ((13*60+15))!



 Comments   
Comment by zeled [ 06/Oct/08 ]

Created an attachment (id=13)
Test to demonstrate MeasureFormat.parse bug for negative numbers + compound unit





[JSCIENCE-102] Bug in LargeInteger - note same result as BigInteger Created: 11/Sep/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Critical
Reporter: martclau Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 102

 Description   

There is a bug in LargeInteger as shown in the following test code. The results
are compared to BigInteger; I'm pretty sure that BigInteger is correct.

The test shows that the x value is not computed correctly. In fact the error
occurs when computing the temp value lT1:

BigInteger result:
t1: 74bf5b47d9ca17e310848dfe633e77bad947ca1f624744f4d89b5941757a73c0
t2: 38bbe5c160d586ff3dfe87bbec8fb3048219f361e950880eee6cb0c6d1f585c0
x: 97a82a834b9e6b50660ae30d43dac9b200276e8bcd2ed6a6593048de09276d1a
y: 30a9590a01066d8ef54a910afcc8648dbc7400c01750af423ce95547f2154d56
LargeInteger result:
t1: 978ef38482948f6497d51819d8fad09568d4ec011ec76344715293a820869b64
t2: 38bbe5c160d586ff3dfe87bbec8fb3048219f361e950880eee6cb0c6d1f585c0
x: e82eb8bc78851411e1105c29d5c64222e951663dabcf32f20267d7d385733e69
y: 30a9590a01066d8ef54a910afcc8648dbc7400c01750af423ce95547f2154d56

See the following code:

import java.math.BigInteger;

import org.jscience.mathematics.number.LargeInteger;

// Besides the following bug:
// - testBit / setBit functions
// - faster squaring
// - init from String

public class Bug {
public static void main(String[] args)

{ String P = "FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF"; String X = "45a9d2f1bc91fe103bf997089f8d640f28e56a13fd0d24dc8912f85b20d1f2f3"; String Y = "fa524f482cc22eb69a395b9cce557b8b026ef82186181299f081f0938292ba94"; String Z = "f5c4ecdbbbde6621dc07a9c6bba7ee6222a571bb66dfbc420a6b7a1c5a4cc800"; System.out.println("BigInteger result:"); BigInteger bP = new BigInteger(P, 16); BigInteger bX = new BigInteger(X, 16); BigInteger bY = new BigInteger(Y, 16); BigInteger bZ = new BigInteger(Z, 16); BigInteger bT1 = bZ.pow(2).modInverse(bP); BigInteger bT2 = bZ.pow(3).modInverse(bP); System.out.println("t1: " + bT1.toString(16)); System.out.println("t2: " + bT2.toString(16)); System.out.println("x: " + bX.multiply(bT1).mod(bP).toString(16)); System.out.println("y: " + bY.multiply(bT2).mod(bP).toString(16)); System.out.println("LargeInteger result:"); LargeInteger lP = LargeInteger.valueOf(bP); LargeInteger lX = LargeInteger.valueOf(bX); LargeInteger lY = LargeInteger.valueOf(bY); LargeInteger lZ = LargeInteger.valueOf(bZ); LargeInteger lT1 = lZ.pow(2).modInverse(lP); LargeInteger lT2 = lZ.pow(3).modInverse(lP); System.out.println("t1: " + lT1.toText(16)); System.out.println("t2: " + lT2.toText(16)); System.out.println("x: " + lX.times(lT1).mod(lP).toText(16)); System.out.println("y: " + lY.times(lT2).mod(lP).toText(16)); }

}






[JSCIENCE-84] Unit.valueOf(CharSequence) does not support a number immediately after opening paren Created: 31/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Critical
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 84

 Description   

This problem was noticed in JScience 4.3.1.

Unit.valueOf(CharSequence) does not support a number immediately after opening
paren.

---- Begin example code snippet ----
System.out.println( "JScience.VERSION=" + JScience.VERSION );

final Unit<?> unit = Unit.valueOf( "(123*s)" );
---- End example code snippet ----

---- Begin output ----
JScience.VERSION=4.3.1 October 4 2007
Exception in thread "main" java.lang.IllegalArgumentException:
java.text.ParseException: unexpected token 8
at javax.measure.unit.Unit.valueOf(Unit.java:482)
at
jscience.UnitValueOfNumberAfterOpenParen.main(UnitValueOfNumberAfterOpenParen.java:11)
Caused by: java.text.ParseException: unexpected token 8
at
javax.measure.unit.UnitFormat$DefaultFormat.parseProductUnit(UnitFormat.java:468)
at
javax.measure.unit.UnitFormat$DefaultFormat.parseProductUnit(UnitFormat.java:395)
at javax.measure.unit.Unit.valueOf(Unit.java:479)
... 1 more
---- End output ----






[JSCIENCE-151] valueOf(LargeInteger > significand, int exponent) class Decimal does not copy significand Created: 02/Mar/11  Updated: 02/Mar/11

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: Version 5.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: widerstand Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

in line 239 of the class Decimal in the method valueOf(LargeInteger
significand, int exponent) there is a critical bug, which results in
incorrect results, e.g. when using the times method of the matrix class.

instead fp._significand = significand;

it must be

fp._significand = significand.copy();

otherwise a reference is only used and in class DenseMatrixImpl line 171
in method times(Matrix<F> that) overwrites results from the previous
iteration. So all results are wrong.






[JSCIENCE-70] Matrix-vector multiplication Created: 02/Dec/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: alidapalmi Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: PC


Issuezilla Id: 70

 Description   

Hi,

I've just started to use JScience and I'm having some troubles using
operations between matrixes and vector.

My problem is that, according to me, the following code gives me the
wrong answer (and I cannot understand if the problem is in my wrong
understanding of the operations/data structures, or somewhere else):

import org.jscience.mathematics.function.Polynomial;
import org.jscience.mathematics.function.RationalFunction;
import org.jscience.mathematics.function.Term;
import org.jscience.mathematics.number.Real;
import org.jscience.mathematics.vector.DenseMatrix;
import org.jscience.mathematics.vector.DenseVector;

public class JScienceTest {

public static void main(String args[]) {

Polynomial<Real> one_poly =
Polynomial.valueOf(Real.valueOf(1),Term.ONE);
Real element1 = Real.valueOf(0.8);
Real element2 = Real.valueOf(0.6);
Real element3 = Real.valueOf(0.4);
Real element4 = Real.valueOf(0.2);
Real element5 = Real.valueOf(1.2);
Polynomial<Real> element1_poly =
Polynomial.valueOf(element1,Term.ONE);
Polynomial<Real> element2_poly =
Polynomial.valueOf(element2,Term.ONE);
Polynomial<Real> element3_poly =
Polynomial.valueOf(element3,Term.ONE);
Polynomial<Real> element4_poly =
Polynomial.valueOf(element4,Term.ONE);
Polynomial<Real> element5_poly =
Polynomial.valueOf(element5,Term.ONE);
RationalFunction<Real> element1_fun =
RationalFunction.valueOf(element1_poly, one_poly);
RationalFunction<Real> element2_fun =
RationalFunction.valueOf(element2_poly, one_poly);
RationalFunction<Real> element3_fun =
RationalFunction.valueOf(element3_poly, one_poly);
RationalFunction<Real> element4_fun =
RationalFunction.valueOf(element4_poly, one_poly);
RationalFunction<Real> element5_fun =
RationalFunction.valueOf(element5_poly, one_poly);

DenseVector row1 = DenseVector.valueOf(new
RationalFunction[]

{ element1_fun, element2_fun, element3_fun, element4_fun }

);
DenseVector row2 = DenseVector.valueOf(new
RationalFunction[]

{ element2_fun, element5_fun , element1_fun, element3_fun }

);
DenseVector row3 = DenseVector.valueOf(new
RationalFunction[]

{ element3_fun , element1_fun, element5_fun, element2_fun }

);
DenseVector row4 = DenseVector.valueOf(new
RationalFunction[]

{ element4_fun, element3_fun, element2_fun, element1_fun }

);

java.util.List<DenseVector<RationalFunction<Real>>> content
= new java.util.Vector();
content.add(row1);
content.add(row2);
content.add(row3);
content.add(row4);

DenseMatrix A = DenseMatrix.valueOf(content);

Real val = Real.valueOf(1.028532932);
val = val.times(-1);
Polynomial<Real> val_poly = Polynomial.valueOf(val,Term.ONE);
RationalFunction<Real> val_fun =
RationalFunction.valueOf(val_poly, one_poly);

DenseVector<Real> B = DenseVector.valueOf(new
RationalFunction[]

{ val_fun, val_fun, val_fun, val_fun}

);

System.out.println("A: ");
System.out.println(A);
System.out.println("B: ");
System.out.println(B);

DenseVector res = A.times(B);

System.out.println("RES: ");
System.out.println(res);
}

}

Note that:
1. I'm using RationalFunction in the matrix and in the vector because
this is just a simplification of the problem I need to solve

2. the right result should be:
A = [0.8 0.6 0.4 0.2
0.6 1.2 0.8 0.4
0.4 0.8 1.2 0.6
0.2 0.4 0.6 0.8]

B = [-1.028532932 -1.028532932 -1.028532932 -1.028532932]

res (A*B) = [-2.057065865 -3.085598797 -3.085598797 -2.057065865]

Instead I get: res = [-4.8612931 -1 -2.0570659 -2.0570659]

3. I have also another question: why I cannot instantiate a negative
Real? (using Real.valueOf(num), if num is < zero I get an exception)

Thank you very much for your patience.
Sorry if the questions seems to be too basic, but I'm just a beginner.
Best regards
Alida






[JSCIENCE-71] Precision issue with Real Created: 06/Dec/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: sirandreus Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: All


Issuezilla Id: 71

 Description   

Hi,

Im currently evaluating JScience, but I have some issues with the precision of
Reals.

Real.setExactPrecision(100);
Real r1 = Real.valueOf("0.0000000000000000001");
Real r2 = Real.valueOf("2.0");

System.out.println(r1.plus(r2));

The output here should be 2.0000000000000000001 but the result I get is:
2.0000000000000000000
(in fact the console output is: 200000000000000000000E-19)

what am I doing wrong ?

Also I have a usecase, where I need a different precisions of Real. I think it
would be nice, if one could setup the precision for each Real object instead of
global configuration using the static methods.

A possible solution would be to introduce a RealFactory, which could be set up
with a specific precision.

kind regards,
Andreas






[JSCIENCE-73] Image processing Created: 13/Dec/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: biozit Assignee: jscience-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File Imagem.java    
Issuezilla Id: 73

 Description   

This a part of the source i develeop for my graduencian work....
this class provide acess and anothers operator to a a image...
i have another operator an theciniquis implemented..i wnat to post this frist
one to set a model to format the rest of the code...



 Comments   
Comment by biozit [ 13/Dec/07 ]

Created an attachment (id=9)
the class control image





[JSCIENCE-74] Unit expression syntax for input and output are not the same Created: 14/Dec/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 74

 Description   

Seen in JScience.VERSION 4.3.1 October 4 2007

The syntax for unit expressions accepted/used for input and output, are not the
same.

For example "1/ft" is not accepted for input (e.g. Unit.valueOf("1/ft")).
However, it is output by Unit.valueOf("ft^-1").toString().

It seems like the syntax should be the same between input and output. This
would allow an output unit expression to be directly used for input.

---- Begin example program source ----
package jscience;

import javax.measure.unit.Unit;

import org.jscience.JScience;

public class UnitSyntaxExample {
public static void main( final String[] args )

{ System.out.println( "JScience.VERSION=" + JScience.VERSION ); final Unit<?> unit_1 = Unit.valueOf( "ft^-1" ); System.out.println( "unit_1=" + unit_1 ); // The following unit expression is not supported for input purposes, // even though the toString() output for unit_1 is exactly this format. // final Unit<?> unit_2 = Unit.valueOf( "1/ft" ); System.out.println( "unit_2=" + unit_2 ); }

}
----- End example program source -----

– Begin example program output -----
JScience.VERSION=4.3.1 October 4 2007
unit_1=1/ft
Exception in thread "main" java.lang.IllegalArgumentException:
java.text.ParseException: unexpected token 8
at javax.measure.unit.Unit.valueOf(Unit.java:482)
at jscience.UnitSyntaxExample.main(UnitSyntaxExample.java:17)
Caused by: java.text.ParseException: unexpected token 8
at
javax.measure.unit.UnitFormat$DefaultFormat.parseProductUnit(UnitFormat.java:468)
at javax.measure.unit.Unit.valueOf(Unit.java:480)
... 1 more
– End example program output -----






[JSCIENCE-75] FloatingPoint.minus produces incorrect results Created: 29/Dec/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: erikengbrecht Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS X
Platform: Macintosh


Issue Links:
Dependency
blocks JSCIENCE-109 Bug in FloatingPoint.minus Open
Issuezilla Id: 75

 Description   

The following code:

import org.jscience.mathematics.number.*;

public class FPTest {
public static void main(String[] args)

{ LargeInteger sig1 = LargeInteger.valueOf("-18024982662959761380"); int exp1 = -17; FloatingPoint fp1 = FloatingPoint.valueOf(sig1, exp1); LargeInteger sig2 = LargeInteger.valueOf("-1976423537605237043"); int exp2 = -16; FloatingPoint fp2 = FloatingPoint.valueOf(sig2, exp2); FloatingPoint result = fp2.minus(fp1); System.out.println(result.toString() + " this is wrong..."); FloatingPoint fp3 = FloatingPoint.valueOf("-180.2798266"); FloatingPoint fp4 = FloatingPoint.valueOf("-197.6423576"); FloatingPoint r2 = fp4.minus(fp3); System.out.println(r2.toString() + " this is roughly what it should be"); }

}

Produces the following result:
-0.37789218039012131810E3 this is wrong...
-0.173625310E2 this is roughly what it should be

It appears there's an incorrect sign in there somewhere...



 Comments   
Comment by erikengbrecht [ 29/Dec/07 ]

I checked out the source and changed the minus method to the following:

public FloatingPoint minus(FloatingPoint that)

{ return this.plus(that.opposite()); }

The problem was that plus was being invoked if this had a larger exponent than that. That obviously won't
work because then the signs are wrong. This seemed like the simplest solution.





[JSCIENCE-77] Unit.alternate(String) does not support all Unit cases Created: 07/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 77

 Description   

This applies to at least JScience 4.3.1.

The Unit.alternate(String) method will fail if the Unit instance (parent) it is
applied to isn't a "standard unit". However, it seems like it would be very
useful to be able to "install" new units with a provided label, for any unit
instance.

The following is one example of this:

Unit<Length> MIL = NonSI.INCH.divide( 1000 ).alternate( "mil" );

The following does not work either:

Unit<Length> M3 = SI.METRE.divide( 3 ).alternate( "m3" );

If this behavior is not a proper use of Unit.alternate(String), it would be
desirable to have this functionality provided in some manner.

UnitFormat.alias()/label() provides the parsing side of the desired
functionality. However, it does not "install" the unit as one which will be
used and retained through out. Also, you have to apply alias()/label() to all
the UnitFormat instances (I believe). The following demonstrates this.

final Unit<Length> MIL = NonSI.INCH.divide( 1000 );
UnitFormat.getInstance().alias( MIL, "mil" );

final Unit<? extends Quantity> unit = Unit.valueOf( "mil" );
System.out.println( "unit = " + unit );

---- Output ----
unit = m*127/5000000

---- Desired output ----
unit = mil



 Comments   
Comment by dautelle [ 11/Feb/08 ]

----------------------- Additional comment.
It was already pointed in issue 77 that it'll be desireble to able to
alternate derived units, not only standart one, and personally I agree with
it. But my issue is about what's happens when I violate current contract. In
statement before, if parent is not a standart unit, we throw an exception
with message, this + " is not a standard unit" – but creating such message
will evaluate this.toString(), and leads to NullPointerException from
UnitFormat class, since at this point in constructor 'this' is absolutely
empty! So, user will not see any clearifing message! It can be rather
confusing, and, without sources, it is hard to understand what's wrong. Here
is an test-case for reproduce:

final Unit<Duration> unit = SI.SECOND.times( 60 );
final AlternateUnit<Duration> minute = unit.alternate( "min" ); //here
I've got NPE
-----------------------





[JSCIENCE-78] Allow digits in unit symbols/names. Created: 10/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 78

 Description   

Currently the label given to a unit cannot contains digits (this to avoid
mistaking the unit for a product unit for which the digits are exponents).
This constraint could be removed by tokenizing product units not based upon
separators (ie. digits, space); but by matching to longest existing names/symbols.






[JSCIENCE-76] Square root fails on some numbers Created: 02/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: octahedron80 Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All
URL: http://tucomday.net


Issuezilla Id: 76

 Description   

According to "org.jscience.mathematics.number.LargeInteger", it has a method
called "sqrt()" for finding square root and flooring it. I use this method
commonly on my project. It works good at first. But later, I found that some
numbers result an error and make application terminate when I use the function.
I found:

LargeInteger.valueOf("8").sqrt()

is the cause of error. It returns "Java Result: 1" on err console instead of 2.
I wonder why it is so I try other else number. I found:

LargeInteger.valueOf("3").sqrt() ---> should be 1 but errs
LargeInteger.valueOf("15").sqrt() ---> should be 3 but errs
LargeInteger.valueOf("24").sqrt() ---> should be 4 but errs
LargeInteger.valueOf("35").sqrt() ---> should be 5 but errs
LargeInteger.valueOf("48").sqrt() ---> should be 6 but errs
etc.

also cause the same error. So I conclude that when I find the square root of
LargeInteger in form (n^2 - 1), it always ends up in the error. (3 = 2^2 - 1, 8
= 3^2 - 1, 15 = 4^2 - 1, etc.)

One more thing, I also found another case which causes different behavior.

LargeInteger.valueOf("0").sqrt() ---> should be 0 but errs
LargeInteger.valueOf("1").sqrt() ---> should be 1 but errs

They unnaturally return "java.lang.ArithmeticException: Division by zero".

Those are things I want to inform to the library developer. I use java 1.5, 1.6
on Windows XP. It causes both in IDE and command line. I need to use this
function correctly on my project. Thank you in advanced.

Octra Bond.



 Comments   
Comment by octahedron80 [ 02/Jan/08 ]

Oh, I almost forgot to tell. I use the latest library version 4.3.1. (earlier
4.3 too)





[JSCIENCE-68] Units text parser order of operations Created: 19/Oct/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: jeffdickson Assignee: dautelle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 68

 Description   

Order of operations in text parser is different from version 3.

(Amount<AngularAcceleration>)Amount.valueOf("1000 rad/s^2");
(Amount<AngularAcceleration>)Amount.valueOf("1000 (rad/s)/s"));

Both contain rad/s^2, but the following

(Amount<AngularAcceleration>)Amount.valueOf("1000 rad/s/s"));

effectively parses as rad/(s/s) and returns a unit of rad

Confirmed with other units, for example "1000 s/m/m" gives 1000 s






[JSCIENCE-64] XMLObjectWriter.write then XMLObjectReader.read of a non-exact Amount loses error Created: 05/Oct/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File AmountXMLExample.java    
Issuezilla Id: 64

 Description   

If you do an XMLObjectWriter.write then XMLObjectReader.read of a non-exact
Amount the error attribute is lost. The "read" Amount value has a zero error
value, meaning the minimum and maximum properties are exactly equal.

I tested this against JScience versions 4.3.1, 4.2.0, 4.1.2, 4.1, and 3.3-beta
(2007/02/15), and they all exhibited the same result.

I will attach a program demonstrating this issue. I've included the output of
the original and xml_read Amount's for the non-exact case below.

Properties of original:
toString=(12.3399999999999999 ± 8.9E-16) m
isExact=false
exactValue=NOT-EXACT
estimatedValue=12.34
unit=m
minimumValue=12.339999999999998
maximumValue=12.34
absoluteError=8.881784197001252E-16
relativeError=7.197556075365683E-17

Properties of xml_read:
toString=(1.0E1 ± 0.0) m
isExact=false
exactValue=NOT-EXACT
estimatedValue=12.34
unit=m
minimumValue=12.34
maximumValue=12.34
absoluteError=0.0
relativeError=0.0



 Comments   
Comment by shanmann [ 05/Oct/07 ]

Created an attachment (id=7)
Example of XML write/read losing error attribute.





[JSCIENCE-62] Exception message from Amount.valueOf(CharSequence) with an invalid unit no longer has details Created: 04/Oct/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File AmountValueOfParsingChangeExamples.java    
Issuezilla Id: 62

 Description   

In 4.2.0 and earlier versions, the exception message from
Amount.valueOf(CharSequence) with an invalid unit string, contained information
related to what failed in the parsing.

For example Amount.valueOf( "10.0 notaunit" ) would have resulted in an
exception with the following message.

"notaunit not recognized (in 10.0 notaunit at index 5)"

In 4.3.1, and I presume 4.3.0, however it is:
"Incomplete Parsing"

Looking at the source of AmountFormat.java, the ParseException is being
"captured" in AmountFormat.PlusMinusError.parse(CharSequence,Cursor). In
pre-4.3.x it was allowed to "escape" the parse method.

I will attach a simple program with the call shown above.



 Comments   
Comment by shanmann [ 04/Oct/07 ]

Created an attachment (id=6)
Example of Amount.valueOf(CharSequence) with an invalid unit string





[JSCIENCE-63] Use TextFormat.setInstance to set default format. Created: 05/Oct/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 63

 Description   

Classes such as LargeInteger, Real, etc. should not have their default format
registered using TextFormat.setInstance
By registering, all others utilities (XML, Configurable, ...) will be able to
use that format.






[JSCIENCE-67] POSITIVE_INFINITY, NEGATIVE INFINITY, etc Created: 18/Oct/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: frgomes Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 67

 Description   

Float64 lacks constants

static int MAX_EXPONENT
Maximum exponent a finite double variable may have.

static double MAX_VALUE
A constant holding the largest positive finite value of type
double, (2-2-52)·21023.

static int MIN_EXPONENT
Minimum exponent a normalized double variable may have.

static double MIN_NORMAL
A constant holding the smallest positive normal value of type
double, 2-1022.

static double MIN_VALUE
A constant holding the smallest positive nonzero value of type
double, 2-1074.

static double NaN
A constant holding a Not-a-Number (NaN) value of type double.

static double NEGATIVE_INFINITY
A constant holding the negative infinity of type double.

static double POSITIVE_INFINITY
A constant holding the positive infinity of type double.






[JSCIENCE-66] Mutable numbers Created: 11/Oct/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: frgomes Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 66

 Description   

It should be great if classes from package org.jscience.mathematics.number
could have mutable counterparts, like MutableFloat64, etc.

This feature would enable user programs easily use Float64 numbers for
instance, but under an application defined class name.

A good example of this functionality is provide by
org.apache.commons.lang.mutable.MutableDouble class






[JSCIENCE-60] SI.METRE transformed units seem to be broken Created: 04/Sep/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: jlowenz Assignee: jscience-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 60

 Description   

I first discovered these problems when I noticed that SI.KILOMETRE.toString()
threw a NPE. Then I discovered more problems diving in deeper... As far as I can
tell, there's some kind of race condition in the static initializers within
UnitFormat. Whatever it is, km1 is broken when running the following code on my
machine, while km2 seems to work fine (even though they are defined the same).

<code>
import javax.measure.unit.SI;
import javax.measure.unit.Unit;
public class Test {
public static void main(String[] args)

{ Unit km1 = SI.KILOMETRE; Unit km2 = SI.KILO(SI.METRE); //System.out.println("km1 == km2? " + km1.equals(km2)); // throws NPE or returns false if you reverse km1/km2 //System.out.println(SI.KILOMETRE); // throws NPE }

}
</code>






[JSCIENCE-57] Need units simplification in calculations Created: 08/Aug/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: johnranderson Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 57

 Description   

Currently dimensionless units such as [ms/s] are not simplified in calculations.
This can lead to thrown exceptions during complicated calculations, for example:

> Amount<Velocity> vel = Amount.valueOf(20.0, SI.METER_PER_SECOND);
> Amount<Duration> t1 = Amount.valueOf(1.0, SI.MILLI(SI.SECOND));
> Amount<Length> l = Amount.valueOf(2.0, SI.METER);
> Amount<Length> len = (Amount<Length>) vel.times(t1).times(l).root(2);
> System.out.println( "len = " + len );

The result of this is:

> len = (6.324555320336756 ± 2.2E-15) m·ms^1:2/s^1:2

and any attempt to use the resulting "len" variable throws a
ConversionException: s holds a base unit with fractional exponent.
The [ms/s] unit should be simplified prior to the square root.

I'm not sure what the solution to this problem is, but I am hoping that this
request will stimulate some suggestions.

Thanks,
-John






[JSCIENCE-59] Amount class/package in physics Package Created: 27/Aug/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: cat Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 59

 Description   

The Amount subclass of Quantity in JScience is defined in the 'physics' package.
However, it is used for other fields such as Economics, so a more neutral name
and package should be found for that.






[JSCIENCE-51] calculation of e fails unexpectedly Created: 28/May/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: djelovsek Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 51

 Description   

Hi!
I'm running some tests on my Intel P4 530 (3.0 MHz, 2GB) IBM machine.
I tried to run this piece of code in my Eclipse 3.2 enviroment with
jdk 1.4_09 and jdk 1.6_01

final static double EPSILON = 1E-20;
final static int REPEATS = 1000;

static Real eReal(int iPrecision) {
Real curfact = Real.valueOf("1");
Real factmul = Real.valueOf("1");
Real curval = Real.valueOf("0");

for (int iIteration = 0; true; iIteration++) {
// System.out.print("Iteration " + iIteration + "\r");
// divide 1 by the current factorial
Real bdTerm = Real.valueOf("1").divide(curfact);
// add the result to the accumulated value
curval = curval.plus(bdTerm);
System.out.println(iIteration + " " + bdTerm + " " + curval);
// check convergence of the current value
if(bdTerm.isLessThan(Real.valueOf(EPSILON)))

{ break; }

// move to the next factorial value
curfact = curfact.times(factmul);
factmul = factmul.plus(Real.valueOf("1"));
}
//System.out.print(curval);
return curval;
}

public static void main(String[] args) {

t = System.currentTimeMillis();
Real er = null;
for (int i = 0; i < REPEATS; i++)

{ er = eReal(iPrecision); }

t1 = System.currentTimeMillis() - t;
System.out.println("jScience - Real: " + t1 + " ; " + er);
}

Probably I'm doing something wrong , because at iIteration == 9
the value of curval "jumps" to 0E-17
instead of being somewhere between 2.71827876984126984(in the previous
iteration ) and the number e.
Where have i (or you) failed?
Thanks,
Damjan






[JSCIENCE-53] Provide Matrix Positive Definite, Square Root and Cholesky Decomposition. Created: 10/Jul/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: New Feature Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 53

 Description   

Add support to calculate Matrix Positive Definite, Square Root and possibly
Cholesky Decomposition.

Ref. http://mathworld.wolfram.com/PositiveDefiniteMatrix.html






[JSCIENCE-56] Matrix.pseudoInverse() gives wrong results Created: 08/Aug/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: lorenzj Assignee: dautelle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 56

 Description   

Hi,

the method pseudoInverse() in the abstact class Matrix (and therefore also in
the class DenseMatrix) is incorrect. Cosider the following example:

DenseMatrix<Rational> mat,result;
mat=DenseMatrix.valueOf(
new Rational[][] {{Rational.ONE,Rational.ZERO},
{Rational.ZERO,Rational.ZERO}}
);
result=DenseMatrix.valueOf(mat.pseudoInverse());

The correct result in this example should the matrix itself.
But the method throw a ArithmeticException: Dividend is zero

The reason is, that in pseudoInverse() you call
thisTranspose.times(this)).inverse()
but the matrix isn't invertible.

Suggestion:
see http://en.wikipedia.org/wiki/Pseudoinverse
"Finding the pseudoinverse of a matrix"
Maybe you could generalize the class LUDecomposition, so that it works for
rectangular matrices, to get the matrices B and C described in the wikipedia page.

Best regards
J.Lorenz






[JSCIENCE-54] Amount.valueOf(CharSequence) fails for values without unit Created: 30/Jul/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 54

 Description   

Some cases where Amount.valueOf() fails are Amount.valueOf("1"),
Amount.valueOf("1.0"), and Amount.valueOf("1.0 "). However, Amount.valueOf("1
") succeeds.

I would expect all the cases to create a Dimensionless Amount result (Unit.ONE
units).

I didn't try using the other AmountFormat instances to see if they had a similar
result.

The following source and output demonstrates the cases shown above. I was using
JScience 4.1.2 for this example.

------------- Start of Java source ---------------
import org.jscience.physics.amount.Amount;

public class AmountValueOf {
public static void main(String[] args)

{ test( "1" ); // fails test( "1 " ); // works test( "1.0" ); // fails test( "1.0 " ); // fails }

private static void test(String valueStr) {
System.out.println();
System.out.println( "**** Begin value string \"" + valueStr + "\"" );
try

{ Amount<?> amount = Amount.valueOf(valueStr); System.out.println( "amount = \"" + amount + "\"" ); }

catch (RuntimeException ex)

{ ex.printStackTrace(System.out); }

finally

{ System.out.println( "**** End value string \"" + valueStr + "\"" ); }

}

}
---------- End of Java source ------------

---------- Start of output -----------

        • Begin value string "1"
          java.lang.StringIndexOutOfBoundsException: String index out of range: 1
          at java.lang.String.charAt(String.java:687)
          at
          org.jscience.physics.amount.AmountFormat$PlusMinusError.parse(AmountFormat.java:173)
          at
          org.jscience.physics.amount.AmountFormat$PlusMinusError.parse(AmountFormat.java:117)
          at javolution.text.TextFormat.parse(Unknown Source)
          at org.jscience.physics.amount.Amount.valueOf(Amount.java:243)
          at AmountValueOf.test(AmountValueOf.java:16)
          at AmountValueOf.main(AmountValueOf.java:6)
        • End value string "1"
        • Begin value string "1 "
          amount = "1 "
        • End value string "1 "
        • Begin value string "1.0"
          java.lang.StringIndexOutOfBoundsException: String index out of range: 3
          at java.lang.String.charAt(String.java:687)
          at
          org.jscience.physics.amount.AmountFormat$PlusMinusError.parse(AmountFormat.java:183)
          at
          org.jscience.physics.amount.AmountFormat$PlusMinusError.parse(AmountFormat.java:117)
          at javolution.text.TextFormat.parse(Unknown Source)
          at org.jscience.physics.amount.Amount.valueOf(Amount.java:243)
          at AmountValueOf.test(AmountValueOf.java:16)
          at AmountValueOf.main(AmountValueOf.java:8)
        • End value string "1.0"
        • Begin value string "1.0 "
          java.lang.StringIndexOutOfBoundsException: String index out of range: 4
          at java.lang.String.charAt(String.java:687)
          at
          org.jscience.physics.amount.AmountFormat$PlusMinusError.parse(AmountFormat.java:183)
          at
          org.jscience.physics.amount.AmountFormat$PlusMinusError.parse(AmountFormat.java:117)
          at javolution.text.TextFormat.parse(Unknown Source)
          at org.jscience.physics.amount.Amount.valueOf(Amount.java:243)
          at AmountValueOf.test(AmountValueOf.java:16)
          at AmountValueOf.main(AmountValueOf.java:9)
        • End value string "1.0 "
                          • End of output --------------





[JSCIENCE-48] Real Class Broken (3.3 Beta) Created: 15/Mar/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 48

 Description   

The following code is not executing properly and I'm not sure why:
...
DenseVector<Real> row1 = DenseVector.valueOf(Real.valueOf(1.0),
Real.valueOf(1.0),Real.valueOf(1.0));
DenseVector<Real>[] rows = new DenseVector[3];
rows[0] = row1;
rows[1] = row1.times(Real.valueOf(2));
rows[2] = row1.times(Real.valueOf(3));
Matrix<Real> M = DenseMatrix.valueOf((DenseVector<Real>[]) rows);

Vector<Real> r2 = M.times(row1);
System.out.println(r2);
...

Everything compiles fine and no exceptions are thrown ... the program just
hangs. When I pause the process in the debugger, it appears that the main
thread is stuck in LargeInteger.times10pow(int), called from Real.toText
(), ...

I think the real problem is that somehow the DenseMatrix.times() call
resulted in Reals that are erroneously humongous. I haven't been able to
recompile the JScience library from source to allow my debugger to trace
through its methods, but inspecting some of the Reals in r2 indicates
something fishy.

Here are the values from the first real in r2 (whose expected value should
be 3.000 +- ...):
...
_error:LargeInteger = 276000000000000000000
_exponent:int = -34
_mantissa:LargeInteger = 300000000000000000000000000000001587
...






[JSCIENCE-49] Measure's estimated value generates different results compared to the equivalent double Created: 30/Mar/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 49

 Description   

The Measure implementation results in the getEstimatedValue() value being
different than would occur if double values were used. This assumes the Measure
values on contain floating point representation errors. I would expect that a
sequence of operations on Measure would result in a getEstimatedValue() value
that exactly matched the same operations applied to doubles, just with the
Measure result knowing what the accumulated error is. I believe this is due to
the _minimum/_maximum implementation, and getEstimatedValue() being ((_minimum +
_maximum) * 0.5).

It seems that it would be desirable, for non-exact Measure operations, for
getEstimatedValue() to match the equivalent operations applied to doubles.

Here's is a simple code example demonstrating this.

------------------------ Begin Source Code -------------------------
package jscience;

import javax.measure.quantities.Length;
import javax.measure.units.NonSI;
import javax.measure.units.Unit;

import junit.framework.TestCase;

import org.jscience.physics.measures.Measure;

public class MeasureEstimatedValueTest extends TestCase {

public MeasureEstimatedValueTest(String arg0)

{ super(arg0); }

public void test()

{ double dbl = 1.0 + 2.0 + 3.0 + 4.0; Unit<Length> unit = NonSI.FOOT; Measure<Length> measure = Measure.valueOf(1.0,unit) .plus( Measure.valueOf(2.0,unit) ) .plus( Measure.valueOf(3.0,unit) ) .plus( Measure.valueOf(4.0,unit) ) ; double diff = dbl - measure.getEstimatedValue(); System.out.println( "dbl = " + dbl ); System.out.println( "measure = " + measure ); System.out.println( "diff = " + diff ); assertEquals( 0.0, diff, 0.0 ); }

}
------------------------ End Source Code -------------------------

------------------------ Begin Output -------------------------
dbl = 10.0
measure = (9.999999999999996 ± 2.7E-15) ft
diff = 3.552713678800501E-15
------------------------ End Output -------------------------






[JSCIENCE-46] Scalar equals() ignores units and is not consistent with compareTo() Created: 15/Feb/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 46

 Description   

This is relative to JScience v3.3-Beta (Feb. 15, 2007 build).

Consistent as used here is the meaning described in the Comparable interface's
javadocs.

The javax.measure.quantities.Scalar<Q>.equals() implementation would return true
to the question "Is 2cm equal to 2km" because it ignores the unit settings, only
using the amounts (2 and 2). Also equals(Object that) is not consistent with
compareTo(Quantity<Q> that), because compareTo() compares this and that
converted to the same units.

As in Issue #45 ("Measure equals() is not consistent with compareTo()"), I would
lean towards the layman's viewpoint for equals(). For example that "1000m" is
equal to "1km". Also that it is desirable for equals() and compareTo() to be
consistent.

It seems desirable for Scalar and Measure to have equivalent implementations for
equals() and compareTo().



 Comments   
Comment by dautelle [ 16/Feb/07 ]

Under investigation will be fixed shortly.

Comment by shanmann [ 01/Mar/07 ]

It didn't come to mind when I submitted the original issue, that modifying the
equals() implementation would likely trigger the need for an update to
hashCode(). This would be done to maintain the equals/hashCode contract, where
equal objects have equal hash codes (Javadocs for Object equals/hashCode).





[JSCIENCE-47] Please add missing methods from older JScience versions Created: 19/Feb/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: axelclk Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 47

 Description   

Please add missing methods from older JScience versions into the latest version
(JScience version 3.3 Beta - February 15, 2007)
Vector<IExpr>#asRowMatrix()

LargeInteger#toInt()
LargeInteger#toLong()
LargeInteger#signum()

Fraction#signum()



 Comments   
Comment by dautelle [ 21/Feb/07 ]

Will be added in next release.





[JSCIENCE-42] Consider using static UnitFormat.alias/label methods. Created: 14/Sep/06  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 42

 Description   

Labeling/aliasing should be static, e.g. UnitFormat.label(PSI, "psi") and
inherited by all UnitFormat instances. Static labels/aliases can only be changed
by UnitFormat sub-classes overriding UnitFormat.getUnit(Symbol) and
UnitFormat.getName(Unit)



 Comments   
Comment by dautelle [ 02/Oct/07 ]

It possible UnitFormat and SystemOfUnits should work together.





[JSCIENCE-45] Measure equals() is not consistent with compareTo() Created: 14/Feb/07  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File MeasureEqualsAndCompareTo.java    
Issuezilla Id: 45

 Description   

This is relative to JScience v3.3-Beta (Feb. 12, 2007 build).

Is it intentional that Measure equals() is not consistent with compareTo()?
(Consistent as described in the Comparable interface's javadocs.)

Whether "1000 m" should be equals to "1 km", does seem to have some non-obvious
wrinkles. From a layman's viewpoint it would seem true would be the answer.
However, from an OO techie's viewpoint, who knew that the two Measure objects
have different unit values ("m" vs. "km"), false might be the answer.

I mostly lean to the layman's viewpoint for a couple reasons. First, if I asked
someone if 1000m was equal to 1km they would say yes. Second, having equals()
and compareTo() be consistent is a desirable thing, and it seems that
compareTo() should return 0 (equality). The second point does contain a degree
of "self defining truism" in its reasoning.

To support strict equality checks, there could be a different method for that
(e.g. strictEquals() or something like that).

I will attach a simple Java class as an example.



 Comments   
Comment by shanmann [ 14/Feb/07 ]

Created an attachment (id=4)
Example of Measure equals() and compareTo() being inconsistent

Comment by shanmann [ 15/Feb/07 ]

I hadn't thought to look at javax.measure.quantities.Scalar<Q> when considering
the Measure equals() and compareTo().

I created a separate issue (#46) for Scalar's equals() and compareTo(),
describing that its equals() ignores units, and that its equals() and
compareTo() are not consistent.

It seems desirable for Scalar and Measure to have conceptually equivalent
implementations for equals() and compareTo().

Hopefully this doesn't cause a major problem, especially with the javax.measure
packages being prepared for JSR-275.

Comment by dautelle [ 16/Feb/07 ]

Under investigation will be fixed shortly.

Comment by shanmann [ 01/Mar/07 ]

It didn't come to mind when I submitted the original issue, that modifying the
equals() implementation would likely trigger the need for an update to
hashCode(). This would be done to maintain the equals/hashCode contract, where
equal objects have equal hash codes (Javadocs for Object equals/hashCode).





[JSCIENCE-37] Integration of Geotools classes. Created: 13/Jul/06  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: New Feature Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive nature.zip    
Issuezilla Id: 37

 Description   

The Geotools group is migrating few classes to JScience (see attached zip file).

Here are the proposed names for these classes:

org.jscience.chemistry.earth.SeaWater
org.jscience.astronomy.calendars.TropicalYear
org.jscience.astronomy.calendars.SynodicMonth
org.jscience.astronomy.solar-system.SunRelativePosition



 Comments   
Comment by dautelle [ 13/Jul/06 ]

Created an attachment (id=3)
Geotool classes.





[JSCIENCE-36] CoordinateReferenceSystem.getConverterTo(...) should be invoked by CoordinateOperationFactory Created: 12/Jul/06  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: desruisseaux Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 36

 Description   

Users should not be required to invoke
CoordinateReferenceSystem.getConverterTo(...) in order to convert coordinate
between two CRS, because the above-cited method is JScience specific. It would
be preferrable to provide an implementation of CoordinateOperationFactory
interface, which may delegate his work (under the hood) to
CoordinateReferenceSystem.getConverterTo(...).

http://geoapi.sourceforge.net/2.0/javadoc/org/opengis/referencing/operation/CoordinateOperationFactory.html

Once a CoordinateOperationFactory implementation is available, it should be
declared in the following file (to be bundled in JScience JAR):

META-INF/services/org.opengis.referencing.operation.CoordinateOperationFactory






[JSCIENCE-35] Refactor CoordinateConverter as a sub-interface of MathTransform Created: 12/Jul/06  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: desruisseaux Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 35

 Description   

The JScience CoordinateConverter interface:

http://www.jscience.org/api/org/jscience/geography/coordinates/crs/CoordinatesConverter.html

should be a sub-interface of at least the GeoAPI's MathTransform interface, and
maybe a sub-interface of CoordinateOperation as well:

http://geoapi.sourceforge.net/2.0/javadoc/org/opengis/referencing/operation/MathTransform.html
http://geoapi.sourceforge.net/2.0/javadoc/org/opengis/referencing/operation/CoordinateOperation.html

It may be woth to rename the "CoordinateConverter" interface as
"CoordinateTransform" for consistency with the GeoAPI interface names. In
addition, the "convert" method should probably be renamed as "transform" for
consistency as well (note that ISO 19111 make a subtle nuance between
"conversion" and "transformation").






[JSCIENCE-30] LargeInteger.toText(int radix) slow in comparison to BigInteger.toString() Created: 17/Apr/06  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: New Feature Priority: Major
Reporter: axelclk Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 30

 Description   

The LargeInteger#toText(int radix) method is relativly slow in comparison to
BigInteger#toString().
Especially for large factorial numbers written in fast algorithms with JScience,
the output of the large result is relatively slow.
(for fast factorial algorithms try these
oneshttp://www.luschny.de/math/factorial/FastFactorialFunctions.htm )






[JSCIENCE-27] Equality of Unscaled Units Created: 08/Mar/06  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: simtec Assignee: dautelle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://jscience.dev.java.net/servlets/ReadMsg?list=units&msgNo=156


Issuezilla Id: 27

 Description   

The current version 3.0.2 of javax.unit.Unit seems to have no functionality to
find out that a unit like SI.RADIANS or NonSI.DEGREE_ANGLE belongs to Angle
and not to Dimensionless.

The problem seems related to the problem described in
https://jscience.dev.java.net/issues/show_bug.cgi?id=3. Hence the current
version 3.0.2 does not have the function Unit.getParentUnit().

Valentin

Comment copied from e-mail of Jean-Marie Dautelle:

You raise an interesting question. If the unit is a product of non-scaled
units, it is simple (e.g. unit.equals(SI.RADIANS)).
In the most general case (e.g. scaled units), we can provide a
Unit.getUnscaledUnits() method which would return the unscaled units
(typically a ProductUnit) that you can test for equality:
unit.getUnscaledUnits().equals(RADIANS.divide(SECOND)); // Angular velocity.






[JSCIENCE-26] UnitFormat cannot be usually subclassed due to visibility of global Unit symbol table Created: 03/Mar/06  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: raycromwell Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 26

 Description   

For various reasons, I need to implement my own UnitFormat class, with custom
parser and formatter. But methods like unitFor() seem impossible to implement
because

a) BaseUnit stores symbol mappings in a global package protected map
b) UnitFormat baseclass has no publically exposed unitFor() and nameFor()
method, and one cannot extend StandardFormat or access it,
otherwise in my own CustomFormat unitFor() I'd just call
UnitFormat.getStandardInstance().unitFor(...)

Is it possible to either a) add abstract unitFor() and nameFor() to UnitFormat
so that I can delegate to StandardFormat or

b) make StandardFormat public so it can be subclassed

or

c) add a static method to Unit so that one can call something like
Unit.unitFor("symbol")

Workaround:
it's ahack and it's ugly, but one can implement a "unitFor()" like method by
calling UnitFormat.getStandardInstance().parse("symbol")






[JSCIENCE-18] Matrix SVD Support Created: 25/Oct/05  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: New Feature Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 18

 Description   

SVD calculation support.
http://mathworld.wolfram.com/SingularValueDecomposition.html






[JSCIENCE-147] org.jscience.geography.coordinates.Coordinates.clone() calls itself recursively Created: 12/Nov/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: radkiewicz Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 147

 Description   

The method clone() in org.jscience.geography.coordinates.Coordinates calls
itself instead of copy() - which should be the right behaviour.

None of its subclasses overwrittes this behavior (the method is final), so
calling this method will result in a StackOverflowError.






[JSCIENCE-146] Currency constructor does not validate String param Created: 11/Nov/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: oliver_meyn Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 146

 Description   

The javadoc says that "new Currency(String code)" will validate the code against
its static currency codes, but this is not the case. The following will run
without exceptions:

double value = 1.23;
String code = "ABC";
Currency currency = new Currency(code);
Amount amount = Amount.valueOf(value, currency);

and amount.toString() produces "1.23 ABC".

Not sure if it's related, but Currency.valueOf(code) always fails (even on valid
currency codes eg "USD")






[JSCIENCE-144] missing 4 in readDouble for UnitFormat$DefaultFormat Created: 08/Sep/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: andrewbachmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 144

 Description   

I found what seems to be a bug in UnitFormat$DefaultFormat. On line 615, in the
method readDouble, there is a string literal: "012356789+-.E". I believe this
should also include the digit "4".

I verified that this bug exists in JScience version 4.3.1. The line number might
be different from what I provided in the trunk/head.



 Comments   
Comment by andrewbachmann [ 08/Sep/09 ]

this issue duplicates issue 107
https://jscience.dev.java.net/issues/show_bug.cgi?id=107





[JSCIENCE-145] MeasureFormat.NumberUnit.format() does not use NumberFormat with CompoundUnits Created: 19/Oct/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: joust Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 145

 Description   

To reproduce:
1. Call MeasureFormat.getInstance() and pass in your own NumberFormat.
MeasureFormat formatter = new DecimalFormat(" #,### "), UnitFormat.getInstance();

2. Format a Measure that uses a Compound Unit
Measure<Double, Length> measure =
Measure.valueOf(23928.0,NonSI.MILE.compound(NonSI.FOOT));
String str = formatter.format(measure);

3. Note numbers don't end up being formatted according to the NumberFormat being
passed in. In this case, it should read " 4 mi 2,808 ft" but instead reads
"4mi2808ft"

Probable bug cause:
File: javax.measure.MeasureFormat.java
Method: MeasureFormat.NumberUnit.formatCompound()
Line 95: toAppendTo.append((long) value);

Recommended fix:
change line 95 to: _numberFormat.format((long) value, toAppendTo, pos);



 Comments   
Comment by joust [ 19/Oct/09 ]

Sorry, step 1 should read:
MeasureFormat formatter = MeasureFormat.getInstance(new DecimalFormat(" #,###
"), UnitFormat.getInstance());





[JSCIENCE-143] Bug in method "getLatitudeZone(final LatLong latLong)" in class "UTM" Created: 21/Aug/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: ottoheltne Assignee: dautelle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 143

 Description   

The method "getLatitudeZone(final LatLong latLong)" in the
class "org.jscience.geography.coordinates.UTM" can sometimes return an
incorrect latitude zone. When your latitude argument is negative, this will
cause rounding errors, effectively pushing all the latitude zones on the
southern hemisphere down one degree.

Below is a suggestion to how the problem can be solved:

public static char getLatitudeZone(final LatLong latLong) {
if (isNorthPolar(latLong)) {
if (latLong.longitudeValue(RADIAN) < 0)

{ return 'Y'; }

else

{ return 'Z'; }

}
if (isSouthPolar(latLong)) {
if (latLong.longitudeValue(RADIAN) < 0)

{ return 'A'; }

else

{ return 'B'; }

}

final double degreesLatitude = latLong.latitudeValue(DEGREE_ANGLE);
char zone = 'C';
int latitudeZoneDegrees = -72;

while(degreesLatitude >= latitudeZoneDegrees){
latitudeZoneDegrees += 8;
zone++;

if(zone == 'I' || zone == 'O')

{ zone++; }

if (zone > 'X')

{ zone = 'X'; }

}

return zone;
}






[JSCIENCE-142] Some classes should override equals and hashcode methods Created: 20/Aug/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: jolkdarr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 142

 Description   

For instance: LatLong.






[JSCIENCE-140] JSR-275 - Missing unit argument in Measure.approximate Created: 06/Aug/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 140

 Description   

This is actually a JSR-275 issue (temporary stored here).
To be consistent the Measure.approximate should specify the epsilon unit.
Also, seems better to use standard equals method with additional parameters
rather than a new name.

/**

  • Compares this measure and the specified measurable to the given accuracy.
  • Measurements are considered approximately equals if their absolute
  • differences when stated in the same specified unit is less than the
  • specified epsilon.
    *
    *
  • @param that the measurable to compare with.
  • @param epsilon the absolute error allowed stated in epsilon unit.
  • @param epsilonUnit the epsilon unit.
  • @return <code>abs(this.doubleValue(epsilonUnit)-
    that.doubleValue(epsilonUnit)) <= epsilon</code>
    */
    public boolean equals(Measurable<Q> that, double epsilon, Unit epsilonUnit) { return Math.abs(this.doubleValue(epsilonUnit) - that.doubleValue(epsilonUnit)) <= epsilon; }





[JSCIENCE-141] Know the parts of a composite dimension Created: 09/Aug/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: jsaiz Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 141

 Description   

[From a mail sent to users@jscience.dev.java.net]

In order to build a string with a dimensional equation from a unit, I would like
to do something like this:

Unit<?> mps = SI.METERS_PER_SECOND;
Dimension dimension = mps.getDimension();
String dimEquation = dimension.toString(); // [L]/[T]

Now, the format of dimEquation is not guaranteed (in the Javadoc of
Dimension.toString()).
Moreover, I would like it to be "L T-1" instead of "[L]/[T]".

I'm not requesting to change the Dimension.toString() method, but just to know
how to access the components of a dimension, so I can build that string myself.

With similarity with ProductUnit, I think methods like the following could be
added to Dimension class:

int getDimensionCount()
Dimension getDimension(int index)
int getDimensionPow(int index)
int getDimensionRoot(int index)

Examples:

  • For NonSI.ANGSTROM:

getDimensionCount(): 1
getDimension(0): Dimension.LENGTH
getDimensionPow(0): 1
getDimensionRoot(0): 1

  • For SI.METERS_PER_SQUARE_SECOND:

getDimensionCount(): 2
getDimension(0): Dimension.LENGTH
getDimension(1): Dimension.TIME
getDimensionPow(0): 1
getDimensionRoot(0): 1
getDimensionPow(1): -2
getDimensionRoot(1): 1

A workaround to my problem would be to check whether the unit is an instance of
ProductUnit, go through all the units in the product, and ask their dimension,
but having these methods in Dimension class would be much cleaner and generic.






[JSCIENCE-139] LargeInteger sqrt function fails for integers that are 1 less than perfrct squares Created: 05/Aug/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: 0x4765654b Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: All


Issuezilla Id: 139

 Description   

I have been working with the LargeInteger class and have discovered a problem:

If you use the "sqrt" function on some integers it loops until it runs out of
memory:

So far I have discovered that it fails on integers that are 1 less that a
perfect square (15, 35, 63...)

— code ----
LargeInteger current = LargeInteger.valueOf("15");
LargeInteger root = current.sqrt() ;

— code ----

— output —
Java heap spaceException in thread "main" java.lang.OutOfMemoryError: Java heap
spacejava.lang.OutOfMemoryError: Java heap space
Java Result: 1
— output —

I am using the sun JDK 1.6.0_14

compiled using ant.

The javolution and geoapi jars are the ones that are packaged with the source
version of the JScience library.

Upon further investigation, the approximation method alternates between 2
values.

For example, in the case of 15 is vibrates between 3 and 4

— code —
/**

  • Returns the integer square root of this integer.
  • @return <code>k<code> such as <code>k^2 <= this < (k + 1)^2</code>
  • @throws ArithmeticException if this integer is negative.
    */
    public LargeInteger sqrt() {
    if (this.isNegative())
    throw new ArithmeticException("Square root of negative integer");
    int bitLength = this.bitLength();
    StackContext.enter();
    try
    Unknown macro: { // First approximation. LargeInteger k = this.times2pow(-((bitLength >> 1) + (bitLength & 1))); while (true) { LargeInteger newK = (k.plus(this.divide(k))).times2pow(-1); System.out.println("Next approximation: " + newK) ; if (newK.equals(k)) return StackContext.outerCopy(k); k = newK; } }

    finally

    { StackContext.exit(); }
    }
    – code –
    Next approximation: 4
    Next approximation: 3
    Next approximation: 4
    Next approximation: 3
    .
    .
    .
    Next approximation: 4
    Next approximation: 3
    Next approximation: 4
    Next approximation: 3
    Next approximation: 4
    — output (for an integer value of 15) –


    The solution for the oscillation of values could be constructed as (assuming it
    only oscillates between 2 values):

    — code —
    /**
    * Returns the integer square root of this integer.
    *
    * Also prevents the approximation method from being caught in an
    * infinite loop when the approximations start oscillating between
    * 2 values
    *
    * @return <code>k<code> such as <code>k^2 <= this < (k + 1)^2</code>
    * @throws ArithmeticException if this integer is negative.
    */
    public LargeInteger sqrt() {
    if (this.isNegative())
    throw new ArithmeticException("Square root of negative integer");
    int bitLength = this.bitLength();
    StackContext.enter();
    try {
    // First approximation.
    LargeInteger k = this.times2pow(-((bitLength >> 1) + (bitLength &
    1)));
    LargeInteger previousK = LargeInteger.valueOf("-1") ;

    while (true) {
    LargeInteger newK = (k.plus(this.divide(k))).times2pow(-1);
    if (newK.equals(k))
    return StackContext.outerCopy(k);

    // Detect the occurrence of oscillation of a value such as the
    // sqrt of 15 oscillates between 3 and 4
    if ( newK.equals(previousK) ) {
    if ( previousK.compareTo(k) > 0 ) { return StackContext.outerCopy(previousK) ; } else { return StackContext.outerCopy(k) ; }
    }

    previousK = k ;
    k = newK;
    }
    } finally { StackContext.exit(); }

    }

      • code —





[JSCIENCE-137] Money/Currency should not have dependency to the physics module (Amount class) Created: 04/Jun/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 137

 Description   

Money/Currency should be based solely on JSR-275 (units/measure) and if possible
be a maven artifact on its own. The capability of mixing physical quantities
with money should be preserved (e.g. price per gallons, hourly cost, etc.)






[JSCIENCE-136] Wrong conversion LatLon to UTM in UTM Grid's exception zones Created: 20/May/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: gdelory Assignee: andersonpd
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 136

 Description   

Hi,

In zone 31X, 33X, 35X and 37X (and supposedly 31V and 32V), strange conversion
happens from LatLon to UTM coordinate. I am not sure it is wrong, but it differs
from Google Earth for example.

It happens because author decided central meridian for thus zones are not usual
ones. (For example for longitude zone 37, usual central meridian is 39°
longitude, however author choosed 40.5°, which is not even zone's center)

In NGA UTM specification, I can not find a clue about different central meridian
for thus exceptions zones, and I assume it has to stay same as for the rest of
longitude zone, but I may be wrong.

That's why I am suggesting to remove thus special cases in method
UTM.getCentralMeridian(int, int) as following :

public static double getCentralMeridian(int longitudeZone, char latitudeZone) {
// polar zones
if (latitudeZone < 'C' || latitudeZone > 'X')

{ return 0.0; }

return Math.toRadians((longitudeZone - 1) * 6 - 180 + 3);
}

It should fixed LatLon to UTM conversion in thus zones.

By the way there is a bug in this method which should be fixed if I am wrong
with NGA specifications :

// V latitude zone exceptions
if (longitudeZone == 'V') {
if (latitudeZone == 31)

{ return Math.toRadians(1.5); }

else if (latitudeZone == 32)

{ return Math.toRadians(7.5); }

}

longitudeZone should be latitudeZone and vice-versa

Hope it helps



 Comments   
Comment by gdelory [ 20/May/09 ]

Summary spelling fixed

Comment by gdelory [ 21/May/09 ]

Assignment to Paul D. Anderson





[JSCIENCE-138] AmountFormat failure with Exact Digits only Created: 15/Jun/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: jgrahn Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 138

 Description   

This bug seems to only apply to the ExactDigits formatter.

The following code results in an ArrayIndexOutOfBoundsException (which is at the
very least the wrong exception):

AmountFormat formatter = AmountFormat.getExactDigitsInstance();
Amount<Length> feet = Amount.<Length>valueOf(8.7d, .13, NonSI.FOOT);
String value = formatter.format(feet).toString();

-The exception-

java.lang.ArrayIndexOutOfBoundsException: -1
at javolution.text.TextBuilder.append(Unknown Source)
at javolution.text.TypeFormat.format(Unknown Source)
at
org.jscience.physics.amount.AmountFormat$ExactDigitsOnly.format(AmountFormat.java:301)
at
org.jscience.physics.amount.AmountFormat$ExactDigitsOnly.format(AmountFormat.java:272)
at javolution.text.TextFormat.format(Unknown Source)
at javolution.text.TextFormat.format(Unknown Source)






[JSCIENCE-135] Mathematical error in calculating compound values Created: 15/Apr/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: rcasha Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 135

 Description   

The technique for converting decimal degrees into degrees-minutes-seconds does
not work correctly (gives wrong figures).

eg: 35.857497 should convert to 35°51'27, but instead produces 35°50'26"

This might be some rounding error.

Sample Code:
------------------------------------------------------
package test;

import java.math.BigDecimal;
import javax.measure.DecimalMeasure;
import javax.measure.quantity.Angle;
import javax.measure.unit.NonSI;
import javax.measure.unit.Unit;
import static javax.measure.unit.NonSI.*;

public class TestDMS {

public static final Unit<Angle> DMS =
DEGREE_ANGLE.compound(MINUTE_ANGLE).compound(SECOND_ANGLE);

public static void main(String[] args)

{ DecimalMeasure<Angle> v1 = new DecimalMeasure<Angle>(new BigDecimal("35.857497"), NonSI.DEGREE_ANGLE); System.out.println(v1); DecimalMeasure<Angle> v2 = v1.to(DMS); System.out.println("actual = "+v2); System.out.println("expected = 35°51'26.99\""); }

}
------------------------------------------------------
I'm re-posting this here since it's the first bug in project JSR-275 and I don't
know if there's anyone watching that one.

https://jsr-275.dev.java.net/issues/show_bug.cgi?id=1






[JSCIENCE-134] Bug in LargeInteger.modInverse Created: 15/Feb/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 134

 Description   

I've found another bug in modInverse:
LargeInteger.valueOf(-1).modInverse(LargeInteger.valueOf("9876543212345678985432123456789876543210"))
returns 1. Unfortunately I do not really understand the implementation. If you write
LargeInteger a = this.mod(m);
instead of
LargeInteger a = this;
this is fixed, but this is probably not the best way.






[JSCIENCE-131] Strange part of Rational.valueOf(CharSequence) Created: 02/Feb/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 131

 Description   

It is unclear to me what the part
} else

{ // No divisor. return valueOf(LargeInteger.valueOf(txt.subtext(0, sep)), LargeInteger.ONE); }

of Rational.valueOf(CharSequence chars) is meant to be, but it seems certainly
broken.



 Comments   
Comment by hstoerr [ 02/Feb/09 ]

Sorry, I accidentially pressed the submit button to early.
Anyway: if the idea is here to allow Rational.valueOf("134") to be interpreted
as 134/1, then it should be
} else

{ // No divisor. return valueOf(LargeInteger.valueOf(txt), LargeInteger.ONE); }

Currently Rational.valueOf("134") just throws a IndexOutOfBoundsException since
sep is -1.





[JSCIENCE-127] Complex conjugate of matrix Created: 20/Jan/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: bjornnordstrom Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 127

 Description   

It seems there is no operation to calculate the complex conjugate of a matrix in
JScience.

Ideally, for my case, the commonly used hermitian transpose (complex conjugate
and transpose) should also be implemented in JScience. In Matlab, this operation
is denoted by ctranspose(A) or A'.






[JSCIENCE-128] Provide Amount class with more complete set of arithmetical operators Created: 28/Jan/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: muddybeemer Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 128

 Description   

I would like to use the Amount class as a basis for engineering calculations in
a MathCad-like program.

In order to do this, it is necessary for Amount class to implement a more
complete set of mathematical operators. I would propose as a minimum that all
of the relevant operators in the java.Math class be implemented in the Amount
class, with the appropriate dimensional limitations.

I think it would also be necessary to provide pow(Amount exp) and root(Amount n)
for dimensionless Amounts, and perhaps for non-dimensional amounts where exp and
n are "equal" to integers.



 Comments   
Comment by muddybeemer [ 28/Jan/09 ]

oops - I meant java.lang.Math





[JSCIENCE-129] Bug in LargeInteger.toText Created: 01/Feb/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 129

 Description   

LargeInteger.valueOf("100000000000000000000").toString() yields
1000000000000000000000 instead of
100000000000000000000 .
The bug is activated on some values with many zeroes.
Fix for the problem: the last line of
LargeInteger.write(LargeInteger li, int radix, int divisor, Appendable out)
is

return TypeFormat.format(rem, radix, out); // Writes low.

but should be replaced with

if (0 != rem)

{ return TypeFormat.format(rem, radix, out); // Writes low. }

else

{ return out; }

The problem is that the last zero is written twice if 0 == rem.






[JSCIENCE-132] Real.approximates(NaN) == false Created: 02/Feb/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 132

 Description   

The Javadoc of Real.approximates(Real) says that Real.approximates(NaN) should
be true, but the code says
if (diff == NaN) return false;
One or the other is wrong.






[JSCIENCE-130] a better Rational.hashCode Created: 02/Feb/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 130

 Description   

I suggest using a hashCode implementation for Rational that distributes the
values better: for instance
3191 * _dividend.hashCode() + 9811 * _divisor.hashCode()
(that are two random primes). Otherwise there are too many collisions for small
divisors - for instance 0/1 and 1/2 have fothe same hashcode.






[JSCIENCE-119] FloatingPoint.sqrt(0) should be 0 Created: 23/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 119

 Description   

FloatingPoint.sqrt(FloatingPoint.ZERO) throws an Exception instead of returning 0.
I suggest adding
if (isZero()) return ZERO;
to FloatingPoint.sqrt, and
if (this == ZERO) return ZERO;
to Real.



 Comments   
Comment by hstoerr [ 23/Dec/08 ]

This should be a patch instead of an issue, since I included a fix.
Tests to verify the fix are included in issue 120.





[JSCIENCE-122] FloatingPoint.hashCode() slightly broken Created: 14/Jan/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 122

 Description   

The current implementation of FloatingPoint.hashCode() does not conform to the
requirement that objects that are equal() have the same hashcode. For instance
FloatingPoint.valueOf("0.723") has a different hashCode than
FloatingPoint.valueOf("0.723000").

To fix this, I suggest:

1. change the LargeInteger.hashCode Implementation such that it returns this.mod(p)
2. change the FloatingPoint.hashCode Implementation such that it returns
_significand.mod(p).times(10.pow(-exp) mod p)

where p = 1327144033. (This is just some random prime < Integer.MAX_VALUE.)

This would be:
LargeInteger:
public int hashCode() {
long code = 0;
// 1327144033 is just an appropriately large prime;
// 1050537101 is 263 mod 1327144033 . The result is this.mod(1327144033) .
for (int i = _size - 1; i >= 0; i--)

{ code = (code * 1050537101 + _words[i]) % 1327144033; }

return _isNegative ? -(int) code : (int) code;
}

FloatingPoint:
public int hashCode() {
if (isZero()) return 0;
if (isNaN()) return 483929293; // some random number
// This is a random prime - the same as in LargeInteger.hashCode()
// We return _significand.mod(p).times(10.pow(-exp) mod p)
final long p = 1327144033;
long code = _significand.hashCode();
int exp = _exponent;
long mult;
if (0 > exp)

{ mult = 398143210; // modInverse of 10 mod p exp = -exp; }

else

{ mult = 10; }

while (0 != exp) {
if (1 == exp % 2)

{ code = (code * mult) % p; }

mult = (mult * mult) % p;
exp = exp / 2;
}
return (int) code;
}

A test is in my upcoming test-suite.






[JSCIENCE-117] Distribution in maven repository / maven build Created: 23/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: New Feature Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 117

 Description   

I suggest distributing the JScience Library in the global maven repository.

Maven (http://maven.apache.org/) is a extremely useful build and artefact
distribution system. You can create new projects easily (including automatic
download of the artefacts) including automated download of the needed libraries;
you have tons of plugins for automated deployment and whatever.

OK, plain Ant has most of this as well, but maven is easier and more powerful in
my opinion. Adding this as a second way of distribution does not hurt, at least.

One might also think about restructuring the project to build with maven, but
this would require changes in the project structure.

If you care I could do both finding out how to get JScience into the global
repositories and, if wanted, restructure the project.






[JSCIENCE-114] Bug in FloatingPoint.compareTo Created: 09/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on JSCIENCE-109 Bug in FloatingPoint.minus Open
Issuezilla Id: 114

 Description   

FloatingPoint.ZERO.compareTo(FloatingPoint.valueOf(0.5)) yields 1 instead of -1.
This is probably just a result of the bug in FloatingPoint.minus I submitted.



 Comments   
Comment by hstoerr [ 23/Dec/08 ]

This is indeed a result of issue 109. Fix is included there.
Tests to verify the fix are included in issue 120.





[JSCIENCE-112] 100 EuroCents are not equal to one Euro Created: 08/Dec/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: mbrinkma1 Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 112

 Description   

When trying to use the lib for coping with currencies (especially EUR and
EUR-cents), I cannot get this JUnit-test-case to get "green":

public class TestCurrency {
private static final Amount<Money> ONE_EURO = Amount.valueOf(1, Currency.EUR);
private static Unit<Money> EURO_CENT = Currency.EUR.times(100);

@Test
public void test1()

{ Amount<Money> amount = Amount.valueOf(100, EURO_CENT); Currency.EUR.setExchangeRate(100); Amount<Money> amount2 = amount.to(Currency.EUR); Assert.assertEquals(ONE_EURO.getExactValue(), amount2.getExactValue()); }

}

I get the exception:

org.jscience.physics.amount.AmountException: Inexact measures don't have
exact values

I understand this results from using a "double" for the exchange-rate.

Is there any way to get a comparison "1 EUR = 100 EUR-Cents" to work?



 Comments   
Comment by mbrinkma1 [ 16/Dec/08 ]

Proposal: for coping with exchange-rates / VAT-calculations etc. it is a good
choice to use java.lang.BigDecimal instead of float- or double-calculations.





[JSCIENCE-110] DataAmount "bit" missing in default label list Created: 25/Nov/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: helgeboehme Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 110

 Description   

DataAmount is defined in SI but missing in UnitFormat.SI_UNITS list. Results to
transformations of DataAmount not being formatted correctly (e.g. to kbit) and
parsing of prefixed "bit" fails.

— example code —
import static javax.measure.unit.SI.BIT;
import static javax.measure.unit.SI.KILO;

import javax.measure.quantity.DataAmount;
import javax.measure.quantity.Frequency;
import javax.measure.unit.ProductUnit;
import javax.measure.unit.SI;
import javax.measure.unit.Unit;

public class DataRateTest {

public static void main(String[] args) {
// works
Unit<Frequency> frequencyUnit=KILO(Frequency.UNIT);
System.out.println("KILO(HERTZ): "+frequencyUnit);
frequencyUnit=Unit.valueOf("MHz").asType(Frequency.class);
System.out.println("\"MHz\": "+frequencyUnit);
// fails
Unit<DataAmount> dataAmountUnit=KILO(DataAmount.UNIT);
System.out.println("KILO(BIT): "+dataAmountUnit);
try

{ dataAmountUnit=Unit.valueOf("Mbit").asType(DataAmount.class); System.out.println("\"Mbit\": "+dataAmountUnit); }

catch (Exception e)

{ System.out.println(e.getClass().getSimpleName()+": "+e.getMessage()); }

}
}
— end example code —

— expected result —
KILO(HERTZ): kHz
"MHz": MHz
KILO(BIT): kbit
"Mbit": Mbit
— end expected result —

— proposed patch —
Index: src/javax/measure/unit/UnitFormat.java
===================================================================
RCS file: /cvs/jscience/src/javax/measure/unit/UnitFormat.java,v
retrieving revision 1.3
diff -u -r1.3 UnitFormat.java
— src/javax/measure/unit/UnitFormat.java 4 Oct 2007 18:26:33 -0000 1.3
+++ src/javax/measure/unit/UnitFormat.java 25 Nov 2008 09:45:44 -0000
@@ -780,12 +780,6 @@
////////////////////////////////////////////////////////////////////////////
// Initializes the standard unit database for SI units.

  • private static final Unit<?>[] SI_UNITS = { SI.AMPERE, SI.BECQUEREL, - SI.CANDELA, SI.COULOMB, SI.FARAD, SI.GRAY, SI.HENRY, SI.HERTZ, - SI.JOULE, SI.KATAL, SI.KELVIN, SI.LUMEN, SI.LUX, SI.METRE, SI.MOLE, - SI.NEWTON, SI.OHM, SI.PASCAL, SI.RADIAN, SI.SECOND, SI.SIEMENS, - SI.SIEVERT, SI.STERADIAN, SI.TESLA, SI.VOLT, SI.WATT, SI.WEBER }

    ;
    -
    private static final String[] PREFIXES =

    { "Y", "Z", "E", "P", "T", "G", "M", "k", "h", "da", "d", "c", "m", "µ", "n", "p", "f", "a", "z", "y" }

    ;
    @@ -799,12 +793,13 @@
    }

static {

  • for (int i = 0; i < SI_UNITS.length; i++) {
    + for (Unit<?> si:SI.getInstance().getUnits()) {
    + String symbol;
    + if(si instanceof BaseUnit) symbol=((BaseUnit<?>) si).getSymbol();
    + else if(si instanceof AlternateUnit) symbol=((AlternateUnit<?>)
    si).getSymbol();
    + else continue;
    for (int j = 0; j < PREFIXES.length; j++) {
  • Unit<?> si = SI_UNITS[i];
    Unit<?> u = si.transform(CONVERTERS[j]);
  • String symbol = (si instanceof BaseUnit) ? ((BaseUnit<?>) si)
  • .getSymbol() : ((AlternateUnit<?>) si).getSymbol();
    DEFAULT.label(u, PREFIXES[j] + symbol);
    if (PREFIXES[j] == "µ") {
    ASCII.label(u, "micro" + symbol);
      • end proposed patch —

The patch uses SI#getUnits() instead of using a local copy of the list.
BTW. holding a map of unit formats including all prefixes this way looks much
like a workaround. I'd expect the prefix is prepended dynamically by
TransformedUnit to the parent.






[JSCIENCE-111] Prefixing of ProductUnits Created: 25/Nov/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: helgeboehme Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 111

 Description   

Transformations of ProductUnits are not formatted using prefixes but
multiplicative factors. E.g. after applying the patch from issue #110 it should
be possible to format KILO(DataRate.UNIT) as "kbit/s"

— example code —
import static javax.measure.unit.SI.BIT;
import static javax.measure.unit.SI.KILO;

import javax.measure.quantity.DataRate;
import javax.measure.unit.ProductUnit;
import javax.measure.unit.SI;
import javax.measure.unit.Unit;

public class DataRateTest {

public static void main(String[] args)

{ // unexpected format Unit<DataRate> dataRateUnit=KILO(DataRate.UNIT); System.out.println("KILO(BIT/SECOND): "+dataRateUnit); // works dataRateUnit=new ProductUnit<DataRate>(KILO(BIT).divide(SI.SECOND)); System.out.println("(KILOBIT)/SECOND: "+dataRateUnit); // works, uses 2nd form dataRateUnit=Unit.valueOf("Mbit/s").asType(DataRate.class); System.out.println("\"Mbit/s\": "+dataRateUnit); }

}
— end example code —

— current result —
KILO(BIT/SECOND): (bit/s)*1000
(KILOBIT)/SECOND: kbit/s
"Mbit/s": Mbit/s
— end current result —

— expected result —
KILO(BIT/SECOND): kbit/s
(KILOBIT)/SECOND: kbit/s
"Mbit/s": Mbit/s
— end expected result —

TransformedUnits should be formatted using prefixes if the ProductUnit parent is
not too complex.

— simple but not recommended solution —
Index: src/javax/measure/unit/Unit.java
===================================================================
RCS file: /cvs/jscience/src/javax/measure/unit/Unit.java,v
retrieving revision 1.2
diff -u -r1.2 Unit.java
— src/javax/measure/unit/Unit.java 3 Oct 2007 07:14:42 -0000 1.2
+++ src/javax/measure/unit/Unit.java 25 Nov 2008 10:06:27 -0000
@@ -336,6 +336,10 @@
}
if (operation == UnitConverter.IDENTITY)
return this;
+ if(this instanceof ProductUnit)

{ + ProductUnit<Q> pu=(ProductUnit<Q>) this; + if(pu.transformFirstTerm(operation)) return pu; + }

return new TransformedUnit<Q>(this, operation);
}

Index: src/javax/measure/unit/ProductUnit.java
===================================================================
RCS file: /cvs/jscience/src/javax/measure/unit/ProductUnit.java,v
retrieving revision 1.2
diff -u -r1.2 ProductUnit.java
— src/javax/measure/unit/ProductUnit.java 3 Oct 2007 07:14:41 -0000 1.2
+++ src/javax/measure/unit/ProductUnit.java 25 Nov 2008 10:06:27 -0000
@@ -467,5 +467,20 @@
private static final long serialVersionUID = 1L;
}

+ /**
+ * If possible, transforms the first term of the product unit.
+ * @param operation the converter from the transformed unit to this unit
+ * @return <code>true</code> if the transformation was performed.
+ */
+ boolean transformFirstTerm(UnitConverter operation) {
+ if(_elements.length==0) return false;
+ Element e=_elements[0];
+ if(e.getPow()==1 && e.getRoot()==1)

{ // only perform for linear units to have clear formatting + _elements[0]=new Element(e.getUnit().transform(operation),1,1); + return true; + }

+ return false;
+ }
+
private static final long serialVersionUID = 1L;
}
\ No newline at end of file
— end simple but not recommended solution —






[JSCIENCE-109] Bug in FloatingPoint.minus Created: 16/Nov/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Major
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
depends on JSCIENCE-75 FloatingPoint.minus produces incorrec... Open
blocks JSCIENCE-114 Bug in FloatingPoint.compareTo Open
Issuezilla Id: 109

 Description   

FloatingPoint.ZERO.minus(FloatingPoint.valueOf(0.1)) yields 0.1 instead of -0.1.

The bug is in the following lines of FloatingPoint.java:
public FloatingPoint minus(FloatingPoint that) {
if (this._exponent > that._exponent)
return that.plus(this);

Obviously plus is wrong. May be that.opposite().plus(this) ?



 Comments   
Comment by hstoerr [ 23/Dec/08 ]

This should be a patch instead of an issue, since I included a fix.
Tests to verify the fix are included in issue 120.

Comment by hstoerr [ 16/Jan/09 ]

75 is a bug report of the same bug.





[JSCIENCE-106] jsr-275 0.8 UnitConverter formatting not idempotent Created: 23/Oct/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: tuomas_kiviaho Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 106

 Description   

Idempotence might not be the correct term but UnitFormat isn't capable to parse
back formatted unit when applied to TransformedUnit.

degree_angle [s*60/1]^-1 is such an example where UnitConverter brackets cause
parsing error. CompoundUnit seems to do soas well. Formatting on the other hand
can only handle add, multiply and rational converters.

My solution to fix the problem is to introduce toString and valueOf methods to
converters and to delegate the formatting to them allowing new unit converters
to be implemented without worrying about formatting/parsing.



 Comments   
Comment by tuomas_kiviaho [ 23/Oct/08 ]

I pulled out trunk from CVS and I noticed that square backets are not used
anymore so give example is invalid.

Nevertheless CompoundUnit and other converters were also neglected.
TransformedUnit can't be expanded so there really can't be other converters
although there is a fallback section still in the code. I assume assertion to be
more appropriate approach.

CompoundUnit seems not to be working correctly. From documentation I dug out and
example NonSI.HOUR.compound(NonSI.MINUTE) that evaluates to h:min (the other
example at javadoc pointed to absent NonSI.DEGREE_MINUTE). ':' separator is
determined to be part of identifier so the parser is unable to split the expression.





[JSCIENCE-107] UnitFormat.readDouble doesn't recognize the digit 4 Created: 10/Nov/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: jasonwastaken Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 107

 Description   

The match string doesn't contain the digit "4". I've included the fix - see
comments.

private double readDouble (CharSequence csq, ParsePosition pos) {
final int length = csq.length();
int start = pos.getIndex();
int end = start+1;
while (end < length) {
/**

  • 10.24.08, JED: Fix bug -> added missing 4.
    */
    if ("0123456789+-.E".indexOf(csq.charAt(end)) < 0) { break; }

    end += 1;
    }
    pos.setIndex(end+1);
    return Double.parseDouble(csq.subSequence(start,end).toString());
    }






[JSCIENCE-108] Add additional units to NonSI and remove MACH Created: 14/Nov/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: jhuwaldt Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Java Source File NonSI.java     Java Source File UnitFormat.java    
Issuezilla Id: 108

 Description   

First, MACH is not a unit and should be removed. Mach number is defined as the air speed divided by the
local speed of sound. The local speed of sound is a function of air temperature and air temperature is
typically a function of altitude. Therefore, Mach number can not be defined by a simple constant.

Second, a number of units that are commonly used in the United States, especially in various fields of
engineering, should be added to NonSI. These include: slug (a unit of mass), ft/s, ft^2, in^2, kip (kilo-
pounds-force), poundal (a unit of force), lbf/ft^2 (psf), lbf/in^2 (psi), ft^3, and BTU (British Thermal Unit).



 Comments   
Comment by jhuwaldt [ 14/Nov/08 ]

Created an attachment (id=15)
Removed MACH, added SLUG, FEET_PER_SECOND, SQUARE_FOOT, SQUARE_INCH, BTU, KIP, POUNDAL, psi, psf, CUBIC_FOOT

Comment by jhuwaldt [ 14/Nov/08 ]

Created an attachment (id=16)
Added default labels for slug, BTU, fps, kip, psf, psi, deleted Mach

Comment by jhuwaldt [ 14/Nov/08 ]

The attached patch also addresses issue #100.





[JSCIENCE-103] LargeInteger: support for bit operations Created: 11/Sep/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: martclau Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 103

 Description   

It would be really nice if LargeInteger supported the equivalent og BigIntegers
testBit, setBit, etc.






[JSCIENCE-104] LargeInteger: String constructor Created: 11/Sep/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: martclau Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 104

 Description   

It would be really nice if LargeInteger supported the equivalent of
BigInteger(String, int) constructor. Storing constants in strings is much more
space efficient.



 Comments   
Comment by martclau [ 11/Sep/08 ]

This issue was marked as a bug by mistake.





[JSCIENCE-99] Exception "Identity converter not allowed" when using factor 1.0 Created: 11/Aug/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: ecg08 Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 99

 Description   

e.g. this code works:
Unit<Power> watt = SI.WATT.times(0.5).times(2.0);

whereas this code fails with "java.lang.IllegalArgumentException: Identity
converter not allowed":
Unit<Power> watt = SI.WATT.times(1.0);

Obviously the provided code is just an example to demonstrate the problem. It
doesn't reflect the real code where the factor is variable. Nevertheless I don't
see why the factor can't be one.
Am I doing smth wrong or is this a bug?
I used version 4.3.1.






[JSCIENCE-96] Make compatible with GeoAPI 2.2-SNAPSHOT Created: 19/Jun/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Task Priority: Major
Reporter: desruisseaux Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File diff.txt    
Issuezilla Id: 96

 Description   

GeoAPI upgrated from legacy JSR-108 to JSR-275.

http://jira.codehaus.org/browse/GEO-131

Binaries can be downloaded here (select a binary not older than June 18, 2008):

http://maven.geotools.fr/repository/org/opengis/geoapi/2.2-SNAPSHOT/

I attached to this issue a patch making JScience compatible with
geoapi-2.2-20080618.142232-16.jar. Summary of changes:

  • Two methods were renamed to reflect name change in ISO specification
    or GeoAPI (e.g. getValidArea() --> getDomainOfValidity()). The old
    names are still present as deprecated methods for compatibility purpose.
  • A few new methods implemented as "return null" for now.
  • Replaced a few "throws new UnsupportedOperationException()" by
    "return null" when the ISO specification said that this method
    is optional. This apply mainly to getRemarks(). I have left the
    exception when the ISO specification said that the method is
    mandatory (mainly getName()). Tip: the optional / mandatory state
    of a method appears in GeoAPI javadoc with @Obligation annotation.

GeoAPI javadoc for linking JScience javadoc if wanted:

http://geoapi.sourceforge.net/2.2/javadoc/index.html



 Comments   
Comment by desruisseaux [ 19/Jun/08 ]

Created an attachment (id=12)
Proposed patch as a CVS diff





[JSCIENCE-100] Add NonSI.CUBIC_FOOT Created: 12/Aug/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 100

 Description   

CUBIC_INCH is already there. This is a very common unit of volume.






[JSCIENCE-101] org.opengis.referencing.cs.CoordinateSytem missing Created: 25/Aug/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: retsil Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 101

 Description   

org.opengis.referencing.cs.CoordinateSytem is referred to in
org.jscience.geogrpahy.coordinates.Altitude, but the class is missing.

The ant build fails with multiple missing classes.

The problem can be averted by removing the opengis and geography packages and
commenting out the relevant code in jScience.java

This appears to affect the CVS version as well as jScience-4.3.0






[JSCIENCE-97] Unable to unmarshal XML for Matrix subclasses Created: 26/Jun/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: jgustaf Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 97

 Description   

I ran the following test and got an access exception.

---- Begin example code snippet ----
Complex[][] array = new Complex[][]{

{Complex.valueOf(1, 0)}

};
ComplexMatrix matrix = ComplexMatrix.valueOf(array);
XMLObjectWriter writer = XMLObjectWriter.newInstance(new
FileOutputStream("foo.xml"));
writer.write(matrix);
writer.close();

XMLObjectReader reader = XMLObjectReader.newInstance(new
FileInputStream("foo.xml"));
ComplexMatrix matrix2 = (ComplexMatrix)reader.read();
reader.close();
---- End example code snippet ----

---- Begin output ----
Exception in thread "main" javolution.xml.stream.XMLStreamException caused by
java.lang.IllegalAccessException: Class javolution.xml.XMLFormat can not access
a member of class org.jscience.mathematics.vector.ComplexMatrix with modifiers
"private"
at javolution.xml.XMLFormat.newInstance(Unknown Source)
at javolution.xml.XMLFormat$InputElement.get(Unknown Source)
at javolution.xml.XMLFormat$InputElement.getNext(Unknown Source)
at javolution.xml.XMLObjectReader.read(Unknown Source)
---- End output ----

Seems to be due to the null constructors being declared private.






[JSCIENCE-95] Strange conversion from LatLong to UTM at 60N 12E Created: 16/Jun/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: curios Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 95

 Description   

Hi!

There is a rather strange conversion from LatLong to UTM at 60N 12E.

a) Longitude values equal and larger than 12E will give an easting value that
seems to be half of what it should be.
b) If one uses the utm object created in a) above and converts it back to
latlong it will produce the correct latlong value of 60N 12E (even if the utm
seems to be wrong).
c) If one creates an UTM object with the latitude and longitude values from a)
above, the conversion from the new utm to latlong will give a latlong with 60N 6E.

This implies two things:
1) The converstion from latlong to utm is a bit strange at some values.
2) The utm-to-latlong algorithm uses more information than what is given from
creating an UTM directly.

Does someone have an idea on how to fix this?

LatLong latLong = LatLong.valueOf(60, 12, NonSI.DEGREE_ANGLE);
--> latlong: [60.0 °, 12.0 °]
UTM utm = UTM.latLongToUtm(latLong, ReferenceEllipsoid.WGS84);
--> utm: [332705.17865555035 m, 6655205.483634522 m]
(Easting value above is half of what it should be)
LatLong latLong2 = UTM.utmToLatLong(utm, ReferenceEllipsoid.WGS84);
--> latlong: [59.999999999910685 °, 11.999999996072283 °]
(Strangely enough is the new latLong equal to the original latlong the utm was
created by)

utm = UTM.valueOf(32, 'V', 332705.17865555047, 6655205.483634522, SI.METER);
--> utm: [332705.17865555047 m, 6655205.483634522 m]
latLong = UTM.utmToLatLong(utm, ReferenceEllipsoid.WGS84);
--> latlong: [59.999999999910685 °, 5.999999996072284 °]
(here is the latlong "correct" according to the utm)

Yours sinecerly
Geir Meyer

Source code and output:

System.out.println("Wrong conversion of 60N 12E to UTM");
LatLong latLong = LatLong.valueOf(60, 12, NonSI.DEGREE_ANGLE);
UTM utm = UTM.latLongToUtm(latLong, ReferenceEllipsoid.WGS84);
LatLong latLong2 = UTM.utmToLatLong(utm, ReferenceEllipsoid.WGS84);
System.out.println("latlong: " + latLong + " to utm: " + utm + " and back
to latlong: " + latLong2);
utm = UTM.valueOf(32, 'V', 332705.17865555047, 6655205.483634522, SI.METER);
latLong = UTM.utmToLatLong(utm, ReferenceEllipsoid.WGS84);
System.out.println("utm: " + utm + " to latlong: " + latLong);

System.out.println("Correct conversion of 60N 11.999E to UTM");
latLong = LatLong.valueOf(60.0, 11.999999999, NonSI.DEGREE_ANGLE);
utm = LatLong.CRS.getConverterTo(UTM.CRS).convert(latLong);
latLong2 = UTM.utmToLatLong(utm, ReferenceEllipsoid.WGS84);
System.out.println("latlong: " + latLong + " to utm: " + utm + " and back
to latlong: " + latLong2);

utm = UTM.valueOf(32, 'V', 667294.8212887102, 6655205.4836319936, SI.METER);
latLong = UTM.utmToLatLong(utm, ReferenceEllipsoid.WGS84);
System.out.println("utm: " + utm + " to latlong: " + latLong);

Wrong conversion of 60N 12E to UTM
latlong: [60.0 °, 12.0 °] to utm: [332705.17865555035 m, 6655205.483634522 m]
and back to latlong: [59.999999999910685 °, 11.999999996072283 °]
utm: [332705.17865555047 m, 6655205.483634522 m] to latlong: [59.999999999910685
°, 5.999999996072284 °]
Correct conversion of 60N 11.999E to UTM
latlong: [60.0 °, 11.999999999 °] to utm: [667294.8212887102 m,
6655205.4836319936 m] and back to latlong: [59.999999999910699 °,
12.000000002927719 °]
utm: [667294.8212887102 m, 6655205.4836319936 m] to latlong: [59.999999999910699
°, 12.000000002927719 °]






[JSCIENCE-94] Polynomial.times(Polynomial) bug Created: 16/May/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: cheremin Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 94

 Description   

here is a cite from Polynomial.times(Polynomial) code:
[code]
Polynomial<R> result = Polynomial.newInstance();
R zero = null;
for (Map.Entry<Term, R> entry1 : this._termToCoef.entrySet()) {
Term t1 = entry1.getKey();
R c1 = entry1.getValue();
for (Map.Entry<Term, R> entry2 : that._termToCoef.entrySet()) {
Term t2 = entry2.getKey();
R c2 = entry2.getValue();
Term t = t1.times(t2);
R c = c1.times(c2);
R prev = result.getCoefficient(t);
R coef = (prev != null) ? prev.plus(c) : c;
if (isZero(coef))

{//here is an error!!! zero = coef; }

else

{ result._termToCoef.put(t, coef); }

}
}
if (result._termToCoef.size() == 0) return Constant.valueOf(zero);
return result;
[/code]
in the line noticed we can see special processing for the case when coefficients
are sum to the zero. But we do not call result._termToCoef.put(t, coef) (or
result._termToCoef.remove(t)), so old coefficient really not cleared. It leads
to an error during multiplication of polynomials like (x-A)*(x+A) – it gives us
x^2-Ax-A^2 instead of x^2-A^2.






[JSCIENCE-93] Unit conversion error of a unit containing a base unit with fractional exponent Created: 24/Apr/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 93

 Description   

This issue was seen in JScience 4.3.1.

The unit conversion process should support units that contain a base unit with a
fractional exponent. Not being able to do such conversions means general
operations can not be performed in these cases. Like Unit.toStandardUnit() (the
exception occurs in ProductUnit's implementation), Unit.getConverterTo(),
Amount.compareTo(), Amount.doubleValue(), Amount.minus(), Amount.plus(), etc.






[JSCIENCE-92] Matrix.determinant() returns NaN Created: 16/Apr/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: jusername Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 92

 Description   

Float64Matrix m = Float64Matrix.valueOf(new double[][] {

{ -1.75, -1.75, -8.75, -7.0, -5.0, -5.25, -3.5, -7.0, -8.75 }

,

{ -1.75, -1.75, -8.75, -7.0, -5.0, -5.25, -3.5, -7.0, -8.75 }

,

{ -8.75, -8.75, -43.75, -35.0, -25.0, -26.25, -17.5, -35.0, -43.75 }, { -7.0, -7.0, -35.0, -28.0, -20.0, -21.0, -14.0, -28.0, -35.0 },
{ -5.0, -5.0, -25.0, -20.0, -18.5, -15.0, -10.0, -20.0, -25.0 }, { -5.25, -5.25, -26.25, -21.0, -15.0, -15.75, -10.5, -21.0, -26.25 },
{ -3.5, -3.5, -17.5, -14.0, -10.0, -10.5, -7.0, -14.0, -17.5 }, { -7.0, -7.0, -35.0, -28.0, -20.0, -21.0, -14.0, -28.0, -35.0 },
{ -8.75, -8.75, -43.75, -35.0, -25.0, -26.25, -17.5, -35.0, -43.75 }

});

System.out.println(m.determinant().doubleValue());

The determinant of this matrix should be 0, not NaN.






[JSCIENCE-91] Matrix.pow(1) can fail because it does a this.times(this) Created: 15/Apr/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 91

 Description   

This issue was found in JScience 4.3.1.

The Matrix.pow(int exp) method for (exp > 0) always does 'pow2 =
pow2.times(pow2)', even for exp==1 when it isn't needed. This can result in an
exception if the matrix contains Amount elements, and those elements are not
compatible (unit-wise) for this.times(this) matrix multiplication.






[JSCIENCE-90] Change default Celsius symbol Created: 22/Mar/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File celcius_character_on_linux.png     Text File pached_lines_in_unitformat_java.txt    
Issuezilla Id: 90

 Description   

Celsius single character (U+2103) symbol is not supported by most font.
We should use the two characters °C as default symbol (consistent with Fahrenheit).



 Comments   
Comment by lsimma [ 26/Jan/09 ]

Created an attachment (id=18)
arial font on linux often used - see difference with single and two character celsius

Comment by lsimma [ 26/Jan/09 ]

Created an attachment (id=19)
two lines changed in UnitFormat.java solved the problem here on linux with arial font





[JSCIENCE-87] Resource bundle for symbols to units mapping. Created: 14/Feb/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 87

 Description   

The default symbol to unit mapping should be part of a resource bundle.
This bundle should be able to map symbols to base units, alternate units and
transformed unit. Additionally, users should be able to load their own unit
bundle. This is particularly important as database persistency is usually
achieved through textual representation of units (new symbols to units mapping
need to be persisted somehow).






[JSCIENCE-89] Measurable toInt/toLong should return truncated values. Created: 11/Mar/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 89

 Description   

toInt(Unit) and toLong(Unit) returns truncated values. It is not consistent with
Number and prevent compound formatting such as:

class TimeFormat extends MeasureFormat {

String format(Measurable<Duration> time)

{ // Returns "hh:mm:ss.ss" long hour = time.longValue(NonSI.HOUR); long min = time.longValue(NonSI.MINUTE) - hour * 60; double sec = time.doubleValue(SI.SECOND) - hour * 60 - min * 3600; return hour/10 + "" + hour%10 + ":" + ... }

}

Note: The class CompoundUnit should be removed as it does not fit with others units.






[JSCIENCE-88] Amount parsing error. Created: 11/Mar/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 88

 Description   

Amount.valueOf("(10.0 ± 8.9E-16) m") generates an error (parenthesis not
recognized). Parsing should be modified to ignore '(',')' and ' '
Also, amount should use integer error (e.g. and possible mantissa) to ensure
that Amount.valueOf(x.toString()).equals.






[JSCIENCE-86] NPE in Unit.alternate Created: 04/Feb/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: cheremin Assignee: jscience-issues
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 86

 Description   

When I try to create alternate unit for non-standart one, I've got NPE instead
of supposed IllegalArgumentException, of something like it.

Test case:

final Unit<Duration> minute = SI.SECOND.times( 60 );
minute.alternate("minute"); //here i've got NPE

Browsing sources I found the reason:

AlternateUnit(String symbol, Unit<?> parent) {
if (!parent.isStandardUnit())
throw new UnsupportedOperationException(this
+ " is not a standard unit");

it's quote from AlternateUnit constructor. When parent is non-standart unit, it
throws UnsupportedOperationException, but during evaluation of this
+ " is not a standard unit" we've got NPE from this.toString() (since this
currently is not valid – all fields are null). Here is the stack trace

java.lang.NullPointerException
at javax.measure.unit.AlternateUnit.hashCode(AlternateUnit.java:122)
at java.util.HashMap.get(HashMap.java:343)
at javax.measure.unit.UnitFormat$DefaultFormat.nameFor(UnitFormat.java:305)
at javax.measure.unit.UnitFormat$DefaultFormat.format(UnitFormat.java:639)
at javax.measure.unit.UnitFormat.format(UnitFormat.java:187)
at java.text.Format.format(Format.java:133)
at javax.measure.unit.Unit.toString(Unit.java:499)
at java.lang.String.valueOf(String.java:2615)
at java.lang.StringBuilder.append(StringBuilder.java:116)
at javax.measure.unit.AlternateUnit.<init>(AlternateUnit.java:50)
at javax.measure.unit.Unit.alternate(Unit.java:299)






[JSCIENCE-85] Unit expressions do not follow normal math operator evaluation in some cases Created: 31/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Major
Reporter: shanmann Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 85

 Description   

This was noticed in JScience 4.3.1.

I wasn't sure whether this should be entered as a defect or as an enhancement,
so I selected defect.

For example the unit expression "m*12/s*34" is interpreted as "(m*12)/(s*34)",
not as "(m*12/s)*24" as normal math expression evaluation would do.

This also appears indirectly in the toString() of a unit. For example
Unit.valueOf( "(m*12)/(s*34)" ).toString() results in "m*12/s*34". Which is
correct for the current Unit expression evaluation implementation, but is likely
to be misinterpreted by a reader as "(m*12/s)*34", which is not what
Unit.value("m*12/s*34") would result in.






[JSCIENCE-79] UCUM Support (Unit parsing/formatting) Created: 23/Jan/08  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Major
Reporter: dautelle Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Zip Archive jscience-additions-2.zip     Zip Archive jscience-additions-ucum.zip     Zip Archive jsr-275.zip     Zip Archive ucum.zip     Zip Archive ucum2.zip    
Issuezilla Id: 79

 Description   

JSR-275 requires the support of UCUM unit format.
Eric Russel sent us an implementation (see attachment) which should be incorporated.



 Comments   
Comment by dautelle [ 23/Jan/08 ]

Created an attachment (id=10)
UCUM Parser/Formatter written by Eric Russell

Comment by russell734 [ 31/Jan/08 ]

Created an attachment (id=11)
Updated UCUM parser/formatter, plus new UnitFormat implementation

Comment by pepijnve [ 28/Oct/08 ]

Created an attachment (id=14)
Integrated Eric Russell's code into JSR code; added UCUM annotation support

Comment by pepijnve [ 03/Apr/09 ]

Created an attachment (id=21)
Updated ucum integration

Comment by dautelle [ 11/May/09 ]

Created an attachment (id=22)
UCUM integrated to first official version (1.0)





[JSCIENCE-161] NPE caused by typo Created: 01/Sep/11  Updated: 01/Sep/11

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Philippe Laflamme Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File issue-161.patch    

 Description   

The following code seems to contain a typo:

public Map<? extends PhysicsDimension, Integer> getProductDimensions() {
        Map<? extends PhysicsUnit, Integer> pseudoUnits = pseudoUnit.getProductUnits();
        if (pseudoUnit == null) return null;
        FastMap<PhysicsDimension, Integer> fundamentalDimensions = FastMap.newInstance();
        for (Map.Entry<? extends PhysicsUnit, Integer> entry : pseudoUnits.entrySet()) {
            fundamentalDimensions.put(new PhysicsDimension(entry.getKey()), entry.getValue());
        }
        return fundamentalDimensions;
    }

Notice that the null check is done on pseudoUnit instead of pseudoUnits (missing s). The test is useless since an NPE would have been thrown on the previous line. This is most probably a typo.



 Comments   
Comment by Philippe Laflamme [ 01/Sep/11 ]

Patch against r53





[JSCIENCE-164] asType(Mass.class) does not work with string OUNCE.toString() Created: 06/Jul/12  Updated: 06/Jul/12

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: aarti100 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following throws an exception when the variable unit has value OUNCE.toString()
Unit<Mass> unit1 = Unit.valueOf(unit.subSequence(0, unit.length())).asType(Mass.class);






[JSCIENCE-158] Monomial-wise mapping of a function Created: 13/May/11  Updated: 13/May/11

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: celestin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File GeneralFunction.java     Text File jscience-158.patch    
Tags: optimization, polynomials

 Description   

Description of the issue
------------------------
Many operations on polynomials are defined as "monomial-wise" operations, meaning that the same operation is carried out on each monomial, and summation of the resulting monomials (or polynomials) gives the resulting polynomial.

In other words, using the terminology of jscience, let us consider a org.jscience.mathematics.function.Polynomial<R> p which shall be written symbolically

p = c0*t0 + c1*t1 + ...
where c0, c1, ... are coefficients (of type R), and t0, t1, ... are of type org.jscience.mathematics.function.Term.

Let us now consider a function f taking as an input a monomial c*t (c : R, t : org.jscience.mathematics.function.Term), and returns a new monomial f(c*t). I would like to be able to compute in an efficient way the following polynomial

q = f(c0*t0) + f(c1*t1) + ...

Using a loop for (Term t: p.getTerms()) is of course possible, but incredibly slow, while a direct traversal of p._termToCoef is much, much faster.

Proposal
--------

First define a GeneralFunction<X, Y>, with only one method
Y evaluate(X x)

Then, in org.jscience.mathematics.function.Polynomial<R>, define a method
Polynomial<R> map(GeneralFunction<Map.Entry<Term, R>, Map.Entry<Term, R>> f)

which carries out the operation above.

Discussion
----------
I propose to define a GeneralFunction (or any other name), because the function f we want to map on the polynomial is not really a org.jscience.mathematics.function.Function.

Improvements on this side might be

  • find a better name,
  • make org.jscience.mathematics.function.Function inherit from GeneralFunction.

I didn't define a type Monomial<R>, but used Map.Entry<Term, R> instead. This makes implementation of the requested feature easier, but might lead to confusing code.

Examples of use
---------------
I'm using org.jscience.mathematics.function.Polynomial to carry out series expansions in many (9) variable, so the polynomials are quite big. Each time I carry out a multiplication, I need to do truncation. If I loop over the terms of the polynomial to be truncated, it's incredibly slow. Using the solution described above results in a significantly faster execution. Silly measurements on a specific case showed that the new implementation was 200x faster !

Proposed implementation
-----------------------
Attached is the source for GeneralFunction, as well as a patch for Polynomial.
This patch actually also includes modifications from issue JSCIENCE-155.






[JSCIENCE-150] KILOGRAM.equals(KILO(GRAM)) should return true. Created: 01/Mar/11  Updated: 01/Mar/11

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: current
Fix Version/s: Version 5.0

Type: Bug Priority: Major
Reporter: dautelle Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Aready an issue in JSR-275, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=338334






[JSCIENCE-153] Create a method to return the neutral element Created: 14/Apr/11  Updated: 14/Apr/11

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: celestin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While writing code working with Polynomials<Rational>, one might be faced with the creation of monomials such as

Variable<Rational> x = new Variable.Local<Rational>("x");
Polynomial<Rational> p = Polynomial.valueOf(Rational.ONE, x);

This is fine, but suppose we now want to go generic, that is write something like

Variable<R> x = new Variable.Local<R>("x");
Polynomial<R> p = Polynomial.valueOf(R.ONE, x);

Then we are stuck, because R.ONE does not actually exist!

I propose to add three methods
1. To GroupAdditive<G>
G getZero()

2. To GroupMultiplicative<G>
G getOne()

2. To Ring<R>
R getOne()

This would solve the problem.

Also,






[JSCIENCE-152] Error in multiplication of two Polynomials Created: 02/Apr/11  Updated: 13/Apr/11

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: sbrisard Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File DemoBug.java     File jscience-152.patch.diff    

 Description   

Multiplication of two polynomials sometimes gives the wrong answer (see example attached). This is due to an error in the code for Polynomial.times. The output of the example is given below
p = [1]a² + [2]ab + [1]
q = [1]a5 + [-5]a4b + [10]a³b²
p.times(q) = [1]a7 + [-3]a6b + [11]a5b² + [15]a4b³ + [10]a³b4
q.times(p) = [1]a7 + [-3]a6b + [1]a5b² + [15]a4b³ + [10]a³b4

p.times(q) is wrong, while q.times(p) is correct. During calculation of p.times(q), the coefficient of a5b2 goes to 0 = 10+(-10). It should then either be set to zero in the _termToCoef entry set, or be removed from this entry set, until it is again non-zero in further iterations. I chose the second option (removal), and the correct code looks like this

public Polynomial<R> times(Polynomial<R> that) {
Polynomial<R> result = Polynomial.newInstance();
R zero = null;
for (Map.Entry<Term, R> entry1 : this._termToCoef.entrySet()) {
Term t1 = entry1.getKey();
R c1 = entry1.getValue();
for (Map.Entry<Term, R> entry2 : that._termToCoef.entrySet()) {
Term t2 = entry2.getKey();
R c2 = entry2.getValue();
Term t = t1.times(t2);
R c = c1.times(c2);
R prev = result.getCoefficient(t);
R coef = (prev != null) ? prev.plus(c) : c;
if (isZero(coef))

{ zero = coef; result._termToCoef.remove(t); // NOTE : Added this line }

else

{ result._termToCoef.put(t, coef); }

}
}
if (result._termToCoef.size() == 0)
return Constant.valueOf(zero);
return result;
}



 Comments   
Comment by celestin [ 13/Apr/11 ]

Here is a patch for this issue.





[JSCIENCE-149] Matrix Eigendecomposition (also called spectral decomposition) Created: 31/Jan/11  Updated: 31/Jan/11

Status: In Progress
Project: jscience
Component/s: Mathematics
Affects Version/s: current
Fix Version/s: Version 6.0

Type: New Feature Priority: Major
Reporter: dautelle Assignee: dautelle
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 5 days
Time Spent: Not Specified
Original Estimate: 5 days


 Description   

Provide Matrix decompositions based on eigenvalues.
Ref. http://en.wikipedia.org/wiki/Eigendecomposition_(matrix)






[JSCIENCE-159] org.jscience.mathematics.random Created: 22/Jun/11  Updated: 22/Jun/11

Status: Open
Project: jscience
Component/s: None
Affects Version/s: Version 5.0
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: metawalker Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File org.jscience.mathematics.random.rar    

 Description   

Add a PRNG part of Randomness Framework which is really works and tested.






[JSCIENCE-173] UTM getCentralMeridian Improvement Created: 13/Apr/14  Updated: 13/Apr/14

Status: Open
Project: jscience
Component/s: Geography
Affects Version/s: Version 5.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dautelle Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The method 'getCentralMeridian(int, char)' in 'org.jscience.geography.coordinates.UTM.java' makes exceptions for several zones.
But the central meridian depends only on the identifier of the longitudeZone.
The zone 32V is extended on the left side by 3°, even the zone 37X.
The zone 31V is cutted on right side by 3°, 31X is extended on right side. 33X and 35X are extended on both sides.
The central meridian for UTM stands in all cases on its original position.
The only exceptions are the polar zones, which has no central meridian.

So this is sufficient:

public static double getCentralMeridian(int longitudeZone, char latitudeZone) {
// polar zones
if (latitudeZone < 'C' || latitudeZone > 'X')

{ return 0.0; }

return (longitudeZone - 1) * 6 - 180 + 3;
}

Peer-Cedric Hänsel






[JSCIENCE-172] NonSI.OUNCE and NonSI.OUNCE_LIQUID_US/UK use the same label "oz" Created: 03/Apr/14  Updated: 03/Apr/14

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ilikerobots Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

UnitFormat defines the same label for both Mass OUNCE and Volumes OUNCE_LIQUID_US or OUNCE_LIQUID_UK. This makes it impossible to fetch the mass ounce by label.

Example:

try {
    Amount myMass = Amount.valueOf(1.0, SI.KILOGRAM);
    Unit targetUnit = Unit.valueOf("oz") ;
    myMass.to(targetUnit);
} catch (ConversionException e) {
    fail(e.getMessage());
}
//reports: java.lang.AssertionError: kg is not compatible with oz

I am working around this be redefining the labels:

UnitFormat.getInstance().label(NonSI.OUNCE_LIQUID_US,  "oz_liquid");
UnitFormat.getInstance().label(NonSI.OUNCE_LIQUID_UK,  "oz_liquid_uk");
UnitFormat.getInstance().label(NonSI.OUNCE,  "oz");





[JSCIENCE-171] cannot convert product unit equivalent to temperature to another temperature Created: 20/Feb/14  Updated: 20/Feb/14

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ilikerobots Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A product unit which is equivalent to a Temperature cannot be converted to another temperature. This probably affects any product units involving "non-linear" conversion.

Example:

Amount original = Amount.valueOf("1 L- °F/gal");
Unit targetUnit = SI.KELVIN;
assertTrue(original.getUnit().isCompatible(targetUnit));

try {
    Amount converted = original.to(targetUnit);
    assertEquals("0.14676225 K",
            converted.getEstimatedValue() + " " + converted.getUnit().toString());
} catch (ConversionException e) {
    fail(e.getMessage());
}
// reports: java.lang.AssertionError: °F is non-linear, cannot convert





[JSCIENCE-170] Problem with LargeInteger class Created: 02/Feb/14  Updated: 15/Feb/14

Status: Open
Project: jscience
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dautelle Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File TestClass.java     Java Source File TestMultiply.java    

 Description   

Lately I have been experimenting with generating large primes and have tried using your LargeInteger class. I found the LargeInteger class to be quite fast for multiplication, however, I encountered the following problem.

The LargeInteger class will allocate too much memory in the heap for sufficiently large integers. Specifically, I tried it with a 1000 digit integer. I also tried a simple/naive modpow fundtion which does not run out of memory, but seems to be noticably slower than the BigInteger modpow function. This indicates that the problem is probably fixable, although speed may have to be sacrificed.

I have attached a java file for you to try to play with, especially since a 1000 digit number would probably line wrap in an e-mail. The number I test is probably prime.



 Comments   
Comment by dautelle [ 15/Feb/14 ]

LargeInteger multiplication does not scale well.
_____________________________________________
Multiplying 1000 longs together takes 0.0 to run.
Multiplying 1000 BigIntegers together takes 0.019 to run.
Multiplying 1000 LargeIntegers together takes 0.03 to run.
Multiplying 1000 Apints together takes 0.606 to run.

Multiplying 10 BigIntegers that are 10000 digits long takes 0.199 seconds to run.
Multiplying 10 LargeIntegers that are 10000 digits long takes 0.688 seconds to run.
Multiplying 10 Apints that are 10000 digits long takes 1.156 seconds to run.

Multiplying 10 BigIntegers that are 100000 digits long takes 11.327 seconds to run.
Multiplying 10 LargeIntegers that are 100000 digits long takes 28.621 seconds to run.
Multiplying 10 Apints that are 100000 digits long takes 2.22 seconds to run.





[JSCIENCE-167] Product of Complex Polynomials doesn't work. Created: 07/Mar/13  Updated: 07/Mar/13

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Gerard91 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Eclipse on Windows.



 Description   

The product of two complex polynomials in two variables with the funtion .times() it doesn't work.






[JSCIENCE-169] Amount toString prints wrong value when slightly less than 1.0 Created: 01/Aug/13  Updated: 01/Aug/13

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: Version 5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: DanielJackson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Java 1.7, JScience 4.3.1, Javolution 5.2.3



 Description   

Values slightly less than one with a moderately large error print 0.1 instead of 1.0 when rounding up. The minimum and maximum values are correct, as are the returns from getEstimatedValue() and getAbsoluteError().

The error may lie in Javolution in the classes TextBuilder.java or MathLib.java though it is difficult to pinpoint it due to the complexity of the relevant methods. Suspected methods: TextBuilder.append(double, int, boolean, boolean) or MathLib.toLongPow10(double, int).

Example:
for (double value = 0.94; value <= 1.005; value += 0.001)
{
Amount<Power> pwr1 = Amount.valueOf(value, 0.1, SI.WATT);
System.out.println(String.format("toString: %s\tactual: %s ± %s", pwr1,
pwr1.getEstimatedValue(), pwr1.getAbsoluteError()));
}

Output:

toString: (0.9 ± 0.10) W actual: 0.94 ± 0.10000000000000009
toString: (0.9 ± 0.10) W actual: 0.9409999999999998 ± 0.10000000000000003
toString: (0.9 ± 0.10) W actual: 0.942 ± 0.10000000000000009
toString: (0.9 ± 0.10) W actual: 0.9429999999999998 ± 0.10000000000000003
toString: (0.9 ± 0.10) W actual: 0.944 ± 0.10000000000000009
toString: (0.9 ± 0.10) W actual: 0.9449999999999998 ± 0.10000000000000003
toString: (0.9 ± 0.10) W actual: 0.946 ± 0.10000000000000009
toString: (0.9 ± 0.10) W actual: 0.9469999999999998 ± 0.10000000000000003
toString: (0.9 ± 0.10) W actual: 0.948 ± 0.10000000000000009
toString: (0.9 ± 0.10) W actual: 0.9489999999999998 ± 0.10000000000000003
toString: (0.9 ± 0.10) W actual: 0.95 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9509999999999998 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.952 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9529999999999998 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.954 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9549999999999998 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.956 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9569999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.958 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9589999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.96 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9609999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.962 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9629999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.964 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9649999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.966 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9669999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.968 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9689999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.97 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9709999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.972 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9729999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.974 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9749999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.976 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9769999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.978 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9789999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.98 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9809999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.982 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9829999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.984 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9849999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.986 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9869999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.988 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9889999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.99 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9909999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.992 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9929999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.994 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9949999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.996 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9969999999999999 ± 0.10000000000000003
toString: (0.1 ± 0.10) W actual: 0.998 ± 0.10000000000000009
toString: (0.1 ± 0.10) W actual: 0.9989999999999999 ± 0.10000000000000003
toString: (1.0 ± 0.10) W actual: 1.0 ± 0.10000000000000009
toString: (1.0 ± 0.10) W actual: 1.001 ± 0.10000000000000009
toString: (1.0 ± 0.10) W actual: 1.0019999999999998 ± 0.10000000000000009
toString: (1.0 ± 0.10) W actual: 1.0029999999999997 ± 0.10000000000000009
toString: (1.0 ± 0.10) W actual: 1.0039999999999996 ± 0.10000000000000009
toString: (1.0 ± 0.10) W actual: 1.0049999999999994 ± 0.10000000000000009






[JSCIENCE-168] AmountFormat does not return correct value when using getExactDigitsInstance Created: 05/Jun/13  Updated: 05/Jun/13

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jazeee Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following works:
System.out.println(Amount.valueOf(0.001, (NonSI.LITER)).to(SI.MILLI(NonSI.LITER)));

Returns (0.9999999999999998 ± 1.7E-16) mL (Or effectively, 1mL)

The following doesn't work correctly:

AmountFormat.setInstance(AmountFormat.getExactDigitsInstance());
System.out.println(Amount.valueOf(0.001, (NonSI.LITER)).to(SI.MILLI(NonSI.LITER)));
Returns 0.100000000000000 mL

This may be related to JSCIENCE-138






[JSCIENCE-148] Conversion Bug in Amount with Duration Units Created: 17/Nov/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Bug Priority: Minor
Reporter: jeffcorbets Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 148

 Description   

Hi -

I have run into a bug where if I start with an amount of 1 hour, convert it to
seconds, and then convert it back to hours, my end amount is 0.1 hours. I have
not been able to reproduce this with any initial amount other than 1.0 hour.

  • Jeff





[JSCIENCE-125] Mismatch: FloatingPoint radix 10, LargeInteger radix 2 Created: 19/Jan/09  Updated: 31/Jan/11

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: Version 6.0

Type: Improvement Priority: Minor
Reporter: hstoerr Assignee: jscience-issues
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 125

 Description   

I was wondering why the http://www.apfloat.org/ Library
performs much better than JScience on arbitrary precision
floating point multiplications when the number of digits is large.
(On 10000 digits it was 4 times as fast as JScience, but on
40000 digits it is 16 times as fast as JScience.) The effect
becomes painful above 1000 digits or so.

The profiler gave me the hint that most of the time is spent
in Calculus.divide. So the reason is the mismatch between
FloatingPoint, which works radix 10 for the exponents,
and LargeInteger, which works with radix 2. So the multiplication
itself is speeded up by the Karatsuba Algorithm, but
afterwards a normalization, that is a division by 10^digitnumber,
is performed, which is an expensive operation in radix 2.
So the nifty multiplication algorithm does not help here.

It is impracticable to change the radix for the FloatingPoint
exponent, since this would change the interface. However
it would be possible to change LargeInteger to work internally
with base 10. The _words would then not be between 0 and
9223372036854775808, but between 0 and 1000000000000000000.
A division by a power of 10 would then be a linear operation in
the size of the number, not a quadratic operation as it is now.
You can do that without changing the interface of LargeInteger/FloatingPoint.

A summary of what would happen to the arbitrary precision operations for a large
number of digits:

  • Some operations would have a dramatic speed up:
    FloatingPoint multiplication, LargeInteger.toString and valueOf(String) in base
    10, the XML serialization
  • Many operations would be slightly slower since the number has about 5% more _words
  • Some operations would be dramatically slower: the shift Operations,
    getLowestBit, longValue if you insist on the "last bits" semantics.

If LargeInteger is changed to base 10, JScience has a distinguishing feature to
ApFloat, since it is base 2 only.

If you want to change this I volunteer for this job, since I find this an
interesting problem.

Best regards,

Hans-Peter Störr






[JSCIENCE-162] Exception in AlternateUnit constructor causes null pointer exception Created: 01/Nov/11  Updated: 01/Jun/12

Status: Open
Project: jscience
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mcclosdl Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SUSE 10



 Description   

AlternateUnit(String symbol, Unit<?> parent) {
if (!parent.isStandardUnit())
throw new UnsupportedOperationException(this
+ " is not a standard unit");

The constructor of UnsupportedOperationException refers to this which eventually results in this.toString() which causes a NullPointerException because _symbol is null.

java.lang.NullPointerException
at javax.measure.unit.AlternateUnit.hashCode(AlternateUnit.java:122)
at java.util.HashMap.get(HashMap.java:300)
at javax.measure.unit.UnitFormat$DefaultFormat.nameFor(UnitFormat.java:305)
at javax.measure.unit.UnitFormat$DefaultFormat.format(UnitFormat.java:639)
at javax.measure.unit.UnitFormat.format(UnitFormat.java:187)
at java.text.Format.format(Format.java:140)
at javax.measure.unit.Unit.toString(Unit.java:499)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at javax.measure.unit.AlternateUnit.<init>(AlternateUnit.java:50)
at javax.measure.unit.Unit.alternate(Unit.java:299)
at com.wec.cnfd.fpa.UnitTest.test1(UnitTest.java:23)



 Comments   
Comment by jbangerter [ 01/Jun/12 ]

This appears to be a duplicate of JSCIENCE-86





[JSCIENCE-163] The equals method in the VectorMeasure class always returns false Created: 05/Feb/12  Updated: 05/Feb/12

Status: Open
Project: jscience
Component/s: www
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: stuart_nimmo Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Attachments: Java Source File JScienceTest.java    

 Description   

The equals method in Object is overridden by javax.Measure to return equals if the unit and amount are equal.
VectorMeasure returns a clone of the value for comparison, and since the amount is a vector, this will always return false, even for identical objects (where the == operator returns true).

I suggest that the VectorMeasure equals method should be overridden to correct this.

I have included source code that demonstrates the problem.






[JSCIENCE-155] [Polynomials] Terms (others than ONE) having zero (additive identity) for coefficient are *not always* automatically removed. Created: 14/Apr/11  Updated: 14/Apr/11

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: celestin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File DemoIssue155.java    

 Description   

Adding [0]x and [0]x² returns [0]x+[0]x², instead of [0].
See attached demo.






[JSCIENCE-154] Identifying null with the neutral element for addition? Created: 14/Apr/11  Updated: 14/Apr/11

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: celestin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When manipulating Polynomials, I worked with expressions like
p.times(q.getCoefficient(Term.ONE))
which raises NullPointerException if q has no constant term. Two possible solutions would be
1. to make getCoefficient return polynomial zero when the specified term is not present,
2. to change the contract of mul, so as to have
p.times(null) == zero

What do you think?
Sébastien






[JSCIENCE-157] Polynomial<Float64> cannot detect zero terms Created: 02/May/11  Updated: 24/Jun/11

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: celestin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For the addition of two polynomials, a test is carried out on the coefficient of each term, in order to check that the coefficient is not zero. This test boils down to coef.equals(coef.opposite), which is very fine for e.g. Rational, but NOT for Float64, since in Float64, -0.0 < 0.0 !!!
This is a bit annoying, since loads of terms -which are otherwise rigorously zero- remain in the results of computations carried out on Polynomial<Float64>.
What is best, in your opinion?
1. Do nothing: I can always implement MyFloat64, with modified compareTo method,
2. Change Polynomial.isZero().

Thanks for your help/ideas,
Sébastien



 Comments   
Comment by celestin [ 24/Jun/11 ]

I don't know why "rigorously" has been barred. My point is that the test coef.equals(coef.opposite) fails for (exact) zero as a Float64.





[JSCIENCE-156] More readable console writing of terms/polynomials Created: 28/Apr/11  Updated: 28/Apr/11

Status: Open
Project: jscience
Component/s: Mathematics
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: celestin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File jscience-156.patch    
Tags: term, toText

 Description   

On some consoles, the 2 and 3 exponents (² and ³) are not easily distinguished. I propose that for low-values of the exponent in a term, printing follows the same conventions as for higher values. Therefore, x**3*y**2 would print as "x3y2" instead of "x³y²".
I attach a patch for this slight modification.






[JSCIENCE-166] Amount string parsing Created: 12/Feb/13  Updated: 01/Jul/14

Status: Open
Project: jscience
Component/s: Physics
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: DanielJackson Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Eclipse Juno, Java 7



 Description   

When using the Amount.valueOf(csq) method I receive an error; for example, the following code produces this:

Amount<Power> a = Amount.valueOf(10.0, SI.WATT); // so far so good
Amount<Power> b = (Amount<Power>) Amount.valueOf(a.toString); // this produces an error

java.lang.IllegalArgumentException: Incomplete Parsing
at javolution.text.TextFormat.parse(Unknown Source)
at org.jscience.physics.amount.Amount.valueOf(Amount.java:244)
at ... // project specific path
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)



 Comments   
Comment by cameronsstone [ 03/Feb/14 ]

Any updates on this?

How about a hint on:
1) how to implement parsing for arbitrary Amount types?
2) which version of JScience to implement them in?

Comment by dautelle [ 06/Feb/14 ]

Hello,
The amount class with a new implementation will be in the draft release 5.0 (this month hopefully).
Cheers

Comment by cdupont2 [ 01/Jul/14 ]

Hello!
Is there a workaround to make the parsing of a new unit work on 4.3?
Cheers





Generated at Tue Sep 01 15:11:34 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.