What is the correct scientific notation of zero? Based on http://mathworld.wolfram.com/ScientificNotation.html it could be just 0. In PanoramaX the output pattern #.#E will reformat 0 into 1.0E-100 and that does not look OK. Do I need to change the output pattern?

# Scientific notation of zero

**BruceDeB**#2

It may not look right, but it is correct to within 100 decimal places, which is much better than you will usually get with scientific notation!

This may not be a Panorama thing, but an Apple limitation.

**hrg**#3

Unfortunately that is not possible because there are values in the column that are much smaller than 1.0E-100. I would prefer to get either 0 or something like 0E+00 as in Numbers or Excel.

**hrg**#4

As a new user of PanoramaX I would like to continue my question concerning scientific notation and support of small numbers in this software.

The PanoramaX help for Numbers states that all numbers are 64 bit. The linked webpage states that this means ca. 5.0E-324 as the smallest number. Does PanoramaX support such small numbers, can they be compared and can a range of data sets be selected based on such small numbers? (once the problem with zero has been solved)

Please let me know how to enter numbers in scientific notation in the Formula Workshop.

Should the Formula Workshop support the full precision of 64 bit numbers or is it limited because it is intended to serve only demonstration purposes?

For example:

1 + 0.0000000000000001 does not compute (display correctly?) in the Formula Workshop but

1 + 0.000000000000001 does.

**dave**#5

Yes. Numbers that small are supported, as are NANs and infinity. The problem with zero is a problem with the output pattern. It’s not being displayed correctly, but it really is zero, and if the value is carried forward into a subsequent calculation, it will perform correctly.

You have exceeded the precision of a 64 bit floating point number. Counting the hidden bit, there are 53 bits in the mantissa. The sign bit and the exponent account for the rest. log10(2^53) = 15.954589770191, so 53 significant binary figures is equivalent to between 15 and 16 significant decimal figures. It’s much closer to 16 than 15, but it’s less than 16. Your number has 17 significant figures.

Panorama will display up to 16 digits in most form objects, and the str( function will round to 16 digits, with trailing zeroes removed, when it converts a float to text. Panorama will never display 17 significant digits for a floating point number.

**hrg**#6

Thank you for your explanation. In that case it might be possible for the developer to quickly address the incorrect display of zero in scientific notation. I have large tables sometimes starting with >100000 rows before a cleanup and there is always a chance that 1E-100 really exists as a value in a table and that will be very confusing.

**billashw**#7

Realize it might not work for your situation, but you can get additional fine-tuning if you are able to have two fields, one containing the ‘raw’ floating point number, and one containing a text representation. In this example, the displayed number is “0” if the raw number is 0, otherwise the scientific notation format is used. I use the concept of separating the stored number from the displayed number in a time line database that includes geologic and cosmologic time spans.

**hrg**#8

That is a possibility but I would rather have the developer fixing this ASAP. It is also somewhat odd that if a number in scientific notation is selected for editing that it changes back to standard notation and seems on the way to auto-reset to 0. If I then use undo to get the number back and then change the column type to text for easier editing every single value in the column is set to zero. There is something very funky going on and I will wait for a fix before using the software. In Numbers and Excel such numbers stay in scientific notation during editing which is a lot easier in my opinion.

This is the test file with three columns/rows:

a,0e+00,0

b,1e-100,1

c,1.1e-203,2