Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news1.tnib.de!feed.news.tnib.de!news.tnib.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Fixed-point arithmetic library
Date: Thu, 23 Feb 2012 23:21:18 +0100
Lines: 96
Message-ID: <9qnsf4Fv8fU1@mid.individual.net>
References: <alpine.DEB.2.00.1202222012550.5334@urchin.earth.li> <ji3ogh$i8r$1@news.albasani.net> <alpine.DEB.2.00.1202232046150.23797@urchin.earth.li>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net nK9wRqaFtG+GRmVnkHCsCAKw+UT3u4mH9Qd2rISP7BCjZELE0=
Cancel-Lock: sha1:X38sjrsfzCtNT0Dj9Dw/AonX2W0=
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
In-Reply-To: <alpine.DEB.2.00.1202232046150.23797@urchin.earth.li>
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12282

On 02/23/2012 10:15 PM, Tom Anderson wrote:
> On Wed, 22 Feb 2012, Jan Burse wrote:
>
>> If a decimal scale suits you, you could use:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html
>
> Decimal would be fine. BigDecimal might actually be okay too.
>
> I've actually misrepresented the context for this question slightly. My
> current place of work does a few calculations, and we currently use a

"few" like in "a few millions per second"?

> fixed-point implementation of our own. However, it doesn't quite meet
> all our needs. My choice is really between extending it, and replacing
> it with something else. Being lazy, i would rather take advantage of
> someone else's hard work than do any myself.
>
> Now, we wrote this fixed-point implementation having previously used
> BigDecimal, because we had some serious performance problems with that.
> This was before my time, so i'm very hazy on the details. I had already
> dismissed BigDecimal out of hand on the basis of that, but it might
> actually be worth looking at again.

How long is that benchmark ago?  JVMs and standard library have changed 
quite a bit during past years so the performance issues might actually 
have gone by now.

If I would be the one responsible I'd do the measurements myself.  It's 
usually better to base such decisions on hard (and current) facts.  Your 
application obviously exists so you have a clear idea of the nature of 
operations you have to perform as well as the frequency of operations as 
well as the range of input data.  That should make it quite easy to 
build a benchmark which realistically reflects your business case.  You 
could separate the load driving from the used math implementation via 
interface (see minimalistic example below) so you can reuse the same 
tests for all the implementations you want to analyze (at least 
BigDecimal and what you built).

Kind regards

	robert


package clj.math;

/**
  * Abstraction of math impl.
  *
  * @param <T>
  *            type of math numbers
  * @author robert
  */
public interface Math<T> {

	/**
	 * Create a new number from int.
	 *
	 * @param i
	 *            an integer to be converted.
	 * @return a number object representing the int.
	 */
	T create(int i);

	/**
	 * Create a new number from String.
	 *
	 * @param s
	 *            input string, must be a decimal representation of a number.
	 * @return a number object representing the string.
	 */
	T create(String s);

	/**
	 * Addition of two numbers.
	 *
	 * @param a
	 *            a number
	 * @param b
	 *            a number
	 * @return a + b
	 */
	T plus(T a, T b);

	/**
	 * Multiplication of two numbers.
	 *
	 * @param a
	 *            a number
	 * @param b
	 *            a number
	 * @return a * b
	 */
	T mult(T a, T b);
}