ImageJ

IJ.d2s "quirk"

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Joachim Wesner

IJ.d2s "quirk"

Hi again,

I already note for some time, that IJ.ds2 has a "quirk" for very small
values, for example

double small_value = 9.915e-6;
IJ.write(IJ.d2s (small_value, 2));

will not output

"0.00"

but

"9.915E-6"

instead!

Is this intended behaviour?

Sometimes it might be useful to tell if a result is not exactly zero, but
*LARGER* numbers will nevertheless be rounded down to zero as for ex. 1e-3!

Sincerely

Joachim Wesner

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Wayne Rasband

Re: IJ.d2s "quirk"

> Hi again,

> I already note for some time, that IJ.ds2 has a "quirk"
> for very small values, for example

> double small_value = 9.915e-6;
> IJ.write(IJ.d2s (small_value, 2));

> will not output

> "0.00"

> but

> "9.915E-6"

> instead!

> Is this intended behaviour?

IJ.d2s() automatically switches to scientific notation for very small
values to prevent them from being misleadingly displayed in the Results
table as zero. You can avoid the use of scientific notation by
increasing the number of decimal places. Here is what you get

0 9.915E-6
1 9.915E-6
2 9.915E-6
3 9.915E-6
4 9.915E-6
5 9.915E-6
6 0.000010
7 0.0000099
8 0.00000992
9 0.000009915

when you run this macro

n = 9.915e-6;
for (d=0; d<=9; d++)
print(d2s(n,d));

-wayne

> Sometimes it might be useful to tell if a result is not exactly zero,
but
> *LARGER* numbers will nevertheless be rounded down to zero as for ex.
1e-3!

Adrian Daerr-2

rounding to a fixed number of decimals [was: IJ.d2s "quirk"]

May I humbly suggest that this rounding mechanism be totally avoided at
least in the "List", "Save" and "Copy" options in profile plot windows,
or that there be at least an option that switches it off (quick and ugly
hack: if the requested number of decimal places is negative, never
truncate) ? I'd prefer to either always use scientific notation, or let
some java printf function decide which notation to use. If rounding
there has to be, it would be better to *always* truncate, and never
switch to scientific notation, because the resulting clipping can be
surprising and hard to detect, as in the following example.

Since version 1.39g, the plot profile window rounds to 9 decimal places
if the setting is less or equal 3, but this has only made the problem a
little less likely to occur. It can still be treacherous to export data,
if you run e.g.:

newImage("Untitled", "32-bit Ramp", 400, 400, 1);
run("Divide...", "value=100000000");
makeLine(0, 100, 105, 100);
run("Plot Profile");

you get this plot:
http://www.msc.univ-paris-diderot.fr/~daerr/tmp/Plot_of_ramp.tif

so far so good. Now save the data with the "save" button, and plot it
using your favorite plotting program, and you will get:
http://www.msc.univ-paris-diderot.fr/~daerr/tmp/Plot_of_ramp_data.png

Did you expect this ? Imagine now data that almost always evolves in the
lower, correctly saved, linear part, but now and then has bigger values.
Then the clipping might go unnoticed for quite a while, and finding the
cause when you finally notice can be tough.
Don't trust "save" to really save your data without double-checking !

Adrian

On 10/09/09 17:36, Wayne Rasband wrote:

>> Hi again,
>>
>> I already note for some time, that IJ.ds2 has a "quirk"
>> for very small values, for example
>>
>> double small_value = 9.915e-6;
>> IJ.write(IJ.d2s (small_value, 2));
>>
>> will not output
>>
>> "0.00"
>>
>> but
>>
>> "9.915E-6"
>>
>> instead!
>>
>> Is this intended behaviour?
>
> IJ.d2s() automatically switches to scientific notation for very small
> values to prevent them from being misleadingly displayed in the Results
> table as zero. You can avoid the use of scientific notation by
> increasing the number of decimal places. Here is what you get
>
> 0 9.915E-6
> 1 9.915E-6
> 2 9.915E-6
> 3 9.915E-6
> 4 9.915E-6
> 5 9.915E-6
> 6 0.000010
> 7 0.0000099
> 8 0.00000992
> 9 0.000009915
>
> when you run this macro
>
> n = 9.915e-6;
> for (d=0; d<=9; d++)
> print(d2s(n,d));
>
> -wayne
>
> > Sometimes it might be useful to tell if a result is not exactly zero,
> but
> > *LARGER* numbers will nevertheless be rounded down to zero as for ex.
> 1e-3!

Joachim Wesner

Antwort: Re: IJ.d2s "quirk"

In reply to this post by Wayne Rasband

Hi Wayne,

yes I see that point, but IMHO there should be a way to suppress switching
to exponential if requested, to avoid that LARGER values come out in
SMALLER (zero) results.

Also,

1) The number of digits right to the decimal point in exponential form
should be the same as in the non-exp form!? (It´s always 3)
2) When the switch occurs should somehow depend in a sensible way on the #
of digits given.

I checked the sourcecode, there is this undocumented(?) feature that giving
a *negative* number of digits, solves 1) above, but 2) would need a change.

Most sincerely

Joachim Wesner

Wayne Rasband
<[hidden email]>
Gesendet von: An
ImageJ Interest [hidden email]
Group Kopie
<[hidden email].
GOV> Thema
Re: IJ.d2s "quirk"

10.09.2009 17:36

Bitte antworten
an
ImageJ Interest
Group
<[hidden email].
GOV>

> Hi again,

> I already note for some time, that IJ.ds2 has a "quirk"
> for very small values, for example

> double small_value = 9.915e-6;
> IJ.write(IJ.d2s (small_value, 2));

> will not output

> "0.00"

> but

> "9.915E-6"

> instead!

> Is this intended behaviour?

IJ.d2s() automatically switches to scientific notation for very small
values to prevent them from being misleadingly displayed in the Results
table as zero. You can avoid the use of scientific notation by
increasing the number of decimal places. Here is what you get

0 9.915E-6
1 9.915E-6
2 9.915E-6
3 9.915E-6
4 9.915E-6
5 9.915E-6
6 0.000010
7 0.0000099
8 0.00000992
9 0.000009915

when you run this macro

n = 9.915e-6;
for (d=0; d<=9; d++)
print(d2s(n,d));

-wayne

> Sometimes it might be useful to tell if a result is not exactly zero,
but
> *LARGER* numbers will nevertheless be rounded down to zero as for ex.
1e-3!

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

Wayne Rasband

Re: IJ.d2s "quirk"

In reply to this post by Joachim Wesner

> Hi Wayne,
>
> yes I see that point, but IMHO there should be a way to
> suppress switching to exponential if requested, to avoid
> that LARGER values come out in SMALLER (zero) results.
>
> Also,
>
> 1) The number of digits right to the decimal point in
> exponential form should be the same as in the non-exp
> form!? (It´s always 3) 2) When the switch occurs should
> somehow depend in a sensible way on the # of digits given.
>
> I checked the sourcecode, there is this undocumented(?)
> feature that giving a *negative* number of digits, solves
> 1) above, but 2) would need a change.

The "quirk" has been removed in the 1.43g daily build. IJ.d2s() now
only uses exponential notation when the second argument (# of digits)
is negative. The "List", "Save" and "Copy" options in profile plot
windows now use exponential notation when "Scientific Notation" is
enabled in Analyze>Set Measurements.

-wayne

Adrian Daerr-2

Re: IJ.d2s "quirk"

> The "quirk" has been removed in the 1.43g daily build. IJ.d2s() now only
> uses exponential notation when the second argument (# of digits) is
> negative. The "List", "Save" and "Copy" options in profile plot windows
> now use exponential notation when "Scientific Notation" is enabled in
> Analyze>Set Measurements.

Great, thank you!
Adrian