Replies: 4 comments 1 reply
-
Hummmm.... seems like a no brainer to me? or am I just being dense as usual? |
Beta Was this translation helpful? Give feedback.
-
Ok ... I see the problem .. it is a bit more complicated than that - so I guess I was being dense. Sorry. Still seems bad form to spit out something we cannot read though. |
Beta Was this translation helpful? Give feedback.
-
This is why programs have "save" and "export" functionslity. "Save" is to write in fully supported formats, "export" is to write in formats that might not be supported. |
Beta Was this translation helpful? Give feedback.
-
Also, you know this is not a useful yes or no question. Yes implies that it should always do it, and no implies that it should never do it. Although both are very silly, no is much sillier, adding a lot of bias to the question. |
Beta Was this translation helpful? Give feedback.
-
This discussion-poll originates from comments in:
#2454
#2463
The Corfunc perspective takes a suitable SAS dataset, extrapolates it to low and high Q, and transforms that extrapolated data into 1D and 3D Correlation Functions and an Interface Distribution Function. Some analysis of the 1D CF is then performed.
Not unsurprisingly, Users do sometimes want to have the values of the transformed data so they can replot it, so there is a button for outputting these to file. At present these values are written to a 4-column CSV file as: real space axis value Z, 1D CF, 3D CF, IDF.
The SasView ASCII loader will read this file but because it is expecting I(Q) data it treats the 3D CF as dI and the IDF as dQ, which is obviously misleading to an uninitiated User.
There are obviously alternative ways of writing out these data. Those are not the subject of this discussion-poll. The question here is whether, as a rule/policy, if SasView writes data it should be written in a way that SasView can sensibly read that data?
Please vote!
2 votes ·
Beta Was this translation helpful? Give feedback.
All reactions