Import #N/A data from .xlsx file

Share icon

Tue, 02/21/2017 - 06:43 am

I got 6.941780573162677e-310 cell in IGOR PRO 7 after importing .xlsx file including the exact cell #N/A. Please tell me what's the solution to that.
I got 2.470328229206233e-323 in Igor 7.02 and
7.09471e-274 in Igor 1.38B01
for "#NV". This value should correspond to #N/A in the English version; created with the NV() resp. NA() function; Excel 2016.

Having a look in the xml-file shows #N/A as value.
Maybe it's a glitch in the loader?
As a workaround you might load the data as text and convert it later on in Igor, e.g. using str2num.

HJ

February 21, 2017 at 07:20 am - Permalink

This affects loading .xlsx files but not .xls files.

I have fixed the problem in Igor7. #N/A will be treated as NaN. This fix should be available tomorrow (Wednesday Pacific Time) in the nightly build. Choose Help->Igor Pro Nightly builds.

I am not going to fix it in Igor6. Here is a workaround that you can execute after loading the wave:
wave0 = wave0<1E-300 ? NaN : wave0      // Workaround for XLLoadWave not recognizing #N/A

February 21, 2017 at 03:58 pm - Permalink

hrodstein wrote:
This affects loading .xlsx files but not .xls files.

I have fixed the problem in Igor7. #N/A will be treated as NaN. This fix should be available tomorrow (Wednesday Pacific Time) in the nightly build. Choose Help->Igor Pro Nightly builds.

I am not going to fix it in Igor6. Here is a workaround that you can execute after loading the wave:
wave0 = wave0<1E-300 ? NaN : wave0      // Workaround for XLLoadWave not recognizing #N/A


Hi hrodstein,

Thank you for your effort. Could you also do this for IGOR Pro 6.37? I have the same problem in 6.37.

Peter

March 23, 2017 at 02:49 am - Permalink

Quote:
Thank you for your effort. Could you also do this for IGOR Pro 6.37? I have the same problem in 6.37.


I'm afraid not.

In Igor6, XLLoadWave is an XOP which is trickier to mess with than something in Igor itself. Changing, recompiling, and testing it for Macintosh and Windows, 32-bit and 64-bit, is quite time consuming.

More important, any change runs the risk of introducing new bugs and we don't want to be introducing new bugs in Igor6. That would make Igor6 less stable and divert us from work on Igor7 and Igor8.

March 23, 2017 at 11:13 am - Permalink