This support note has some suggestions: https://support.sas.com/kb/61/382.html   But agree with Paige, first step is probably to run PROC CONTENTS to make sure that variable does not have a format attached. ... View more

This is still confusing, as you've introduced a new concept of a 'break'.  Please provide an example of the sample data you HAVE (schedule2), and the output you WANT from that sample data.   As a DATA step with CARDS statement, as Tom showed, and Paige asked for at the beginning of this thread. ... View more

Try tagsets.excelxp destination.  As discussed in this paper, it handles memory differently than the EXCEL destination.   https://support.sas.com/resources/papers/proceedings16/SAS5642-2016.pdf     ... View more

Thanks @Kathryn_SAS , that tech support note looks like exactly this problem.  Very interesting.  I tend to think in terms of the (logical) PDV, without worrying about registers and memory locations.  Very interesting to see the explanation in that note. ... View more

You could try tagsets.excelxp.   It might not have the same memory limitations as the EXCEL destination.  It writes .xml, but Excel will open it and you can do most of the same formatting. ... View more

Just for fun, what happens in M6 if you do: r = m-n; s = m-n; t = m-n; u = m-n; and what about: * r = m-n; s = m-n; t = m-n; u = m-n; And adding that PUT statement fixes the problem in M6?  That's a crazy part of the puzzle. ... View more

Please send the code and those images of 9.4M6 and 9.4M7 in to tech support.  Maybe they can explain and document this bug (assuming they agree it's a bug...) ... View more

That makes sense as the usual numeric precision issue.   But I don't see how that could explain: a = 3; m = 1/a; n = 1/a; Assigning different values to M and N.  Can it? ... View more

You might try submitting to tech support.  I can't think of an explanation. It's interesting that you both have the same version (9.4M6) showing this odd behavior.  But I still have a hard time believing this is a weird bug.  ... View more

@FoxHope wrote: Hi,   Do you mind if I ask further clarification question? Because it seems that this goes beyond the precision issue. If 1/3 cannot be represented precisely in binary, shouldn't the value of c and d be BOTH off by the same amount and their difference should be zero regardless? Agree, what you are reporting doesn't make sense to me, and isn't the basic numeric precision issue.   Even if somehow these two statements could return different values (because of what, random noise in precision): m = 1/a; n = 1/a; I can't think of an explanation for how these two statements could return different values (accept again random noise in precision...) x = m-n; y = m-n; And yes, your addition of a PUT statement shouldn't change values.   Something odd is happening.  Did you quit SAS and restart a fresh session? ... View more

I can't replicate your results.  I ran on 9.4M7 (Windows) and 9.4M8 (Linux). ... View more

SAS Viya Copilot was recently released.  Perhaps it will satisfy this request? ... View more

I'm confused.  Are you saying you get different results from running the below two bits of code, one with double quotes and one with single quotes?  That would be very surprising.   *double quotes; proc sql noprint; select distinct brand into: brands separated by ', ' from sel_drugs where cont_cat="IUD (intrauterine device)/IUS (intrauterine system) without hormone (copper)" and Act_Ing="LEVONORGESTREL" ; %put &=brands; *single quotes; proc sql noprint; select distinct brand into: brands separated by ', ' from sel_drugs where cont_cat='IUD (intrauterine device)/IUS (intrauterine system) without hormone (copper)' and Act_Ing='LEVONORGESTREL' ; %put &=brands; Note when posting code, please click the "running man" insert SAS code button and paste your code into that window.  It formats the code as code rather than as part of the text. ... View more

Thanks Nancy! (and thanks Inka, I assume…) ... View more