wip authored by Frédéric Bapst's avatar Frédéric Bapst
...@@ -237,33 +237,39 @@ We have been working on the automatic replacement of the primitive types ...@@ -237,33 +237,39 @@ We have been working on the automatic replacement of the primitive types
float/double (as well as their "standard wrapper" counterpart Float/Double) by float/double (as well as their "standard wrapper" counterpart Float/Double) by
objects that realize richer number models. objects that realize richer number models.
COJAC illustrates this with an option `-BDP nDigits` that turns float/double into `BigDecimal` with a specific number of significant digits. There are still limitations, but... yes we did it! Now our poor numbers can be enriched in various ways, that we only start to
study. There are still limitations, but... yes we did it!
Here is an example to show the idea: ## 3.1 Our wrapping mechanism
``` Our wrapping mechanism... is automatic! Just tell us which number model you want to
prompt> java HelloMrCojac activate, and there you go.
3.232315809405594
3.1425916543395442
3.1415936535887745
prompt> java -javaagent:cojac.jar="-BDP 2" HelloMrCojac COJAC features a mechanism of *Magic Methods* that can be used to interact with
3.3 3.3 the richer model. A magic method is a method with an identifier starting with
3.3 3.3 the prefix `COJAC_MAGIC_` and a specific signature, to be declared in user
3.3 3.3 code; at runtime,
COJAC will redirect the call to such methods to the implementation inside the wrapper,
thus giving the user code access to the "richer number" power.
prompt> java -javaagent:cojac.jar="-BDP 100" HelloMrCojac The magic methods are model-specific (see below), but every number wrapper will at least
3.2323158094055926 3.232315809405592687326433456464416216738198162346769157914668750582063275561727574111475040267609927 provide those two methods:
3.142591654339543 3.142591654339543050901127737252204566153538256316955873675303860503427171619557703217696070138604748
3.141593653588793 3.141593653588793239212643133279315384134670383750090190572600838450905273472072581879999874230239464
``` ```
public static String COJAC_MAGIC_wrapperName();
public static String COJAC_MAGIC_toString(double n); // internal representation
And the corresponding code: ```
## 3.2 Number model "BigDecimal"
COJAC illustrates this with an option `-BDP nDigits` that turns float/double into `BigDecimal` with a specific number of significant digits. There are still limitations, but... yes we did it!
Here is a small demo program:
``` ```
public class HelloMrCojac { public class HelloMrCojac {
public static String COJAC_MAGIC_DOUBLE_toStr(double n) { return ""; } public static String COJAC_MAGIC_toString(double n) { return ""; }
public static void main(String[] args) { public static void main(String[] args) {
double p1=approxPi(10); double p1=approxPi(10);
...@@ -286,6 +292,64 @@ public class HelloMrCojac { ...@@ -286,6 +292,64 @@ public class HelloMrCojac {
} }
} }
``` ```
A normal run will produce that output:
```
prompt> java HelloMrCojac
3.232315809405594
3.1425916543395442
3.1415936535887745
```
And now, let's compute with twice as much significant numbers:
```
prompt> java -javaagent:cojac.jar="-Rb 30" HelloMrCojac
3.2323158094055926 3.23231580940559268732643345646441621673819
3.142591654339543 3.142591654339543050901127737252204566153538
3.141593653588793 3.141593653588793239212643133279315384134670
```
Just for fun, let's show that we can decrease the internal precision:
```
prompt> java -javaagent:cojac.jar="-Rb 2" HelloMrCojac
3.3 3.3
3.3 3.3
3.3 3.3
```
## 3.3 Number model "Interval computation"
## 3.4 Number model "Discrete stochastic arithmetic"
Interval computation is known to offer strong guarantees, but also to be overly
pessimistic in the estimation of the relative error (the interval is often far
wider than needed). "Discrete stochastic arithmetic" is an interesting
alternative: roughly, the idea is to keep 3 versions of every arithmetic
result, each corresponding to the application of a rounding mode choosen randomly.
An unstable computation has a high probability of producing 3 manifestly divergent
results, and the relative error can be estimated.
For the moment, we don't follow the full-strength theory behind stochastic
arithmetic, and simply round up/down randomly. We claim again that the
real breakthrough lies in the ease of our tool, which helps experimenting
with the model.
That wrapper offers the same magic methods as our interval computation model.
## 3.5 Number model "Automatic differentiation"
*Automatic differentiation* is an awesome idea (never heard of it? You should have
a look!). One reason the technique is not in widespread use lies in the fact that
there is a lack of *simple* tools that can show its power. We pretend that the
situation dramatically changes thanks to COJAC.
-------------------------------------------------- --------------------------------------------------
# 4. Detailed usage # 4. Detailed usage
...@@ -389,6 +453,6 @@ If you dream of a similar tool not limited to the Java world, have a look at [ht ...@@ -389,6 +453,6 @@ If you dream of a similar tool not limited to the Java world, have a look at [ht
...well, happy problem sniffing, and happy number wrapping! ...well, happy problem sniffing, and happy number wrapping!
<span>&nbsp;&nbsp;&nbsp;&nbsp;</span> ...and give us feedback ;-) <span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span> ...please give us feedback ;-)
<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span> The COJAC Team. <span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span> The COJAC Team.
\ No newline at end of file \ No newline at end of file