search

occam-ra / occam

OCCAM Reconstructability Analysis Tools
Other
20 stars 14 forks source link

Fix white-space intolerance in variable names #15

Open gdcutting opened 5 years ago

gdcutting commented 5 years ago

Per Marty: "Occam is white-space intolerant in the long names of the variables in the variable block. So if "New York" was a long variable name, the space between the "w" and the "Y" would cause Occam to fail."

"We could handle this in one of two ways: either Occam could, on reading in the input file, just ignore (delete) the space (or it could be more than one space) and store that variable as "NewYork" (and output that in the Occam output), or this could be treated as a fatal error, and the user should be told to remove all such white spaces. I'd prefer the first of these ways, but if for any reason, the second is much easier to implement, that would be OK."

gdcutting commented 5 years ago

I think I have fixed this. Just changed the scan pattern (Input.cpp(245)) to allow whitespace (rather than throw an error and quit). Everything else is the same, I believe (but try it with your own files to make sure). Test the change at my dev version: http://occam.systemscienceguy.com/occam/weboccam.cgi

gdcutting commented 5 years ago

Accidentally merged this upstream already, my oversight. Was making some minor corrections to install doc formatting and realized I needed to clarify language on permissions, and this (whitespace fix) got included too in that merge. I'm going to leave it since the change is very small but will leave the issue open and still confirm with Marty when he's back next week.

gdcutting commented 5 years ago

Also see some "temporary code" for allowing numbers in variable names. Is this still what we want? If not I could remove the "temporary code" and clean things up a tiny bit.

gdcutting commented 5 years ago

Joe pointed out that Marty actually wants to allow the processing of the variable with space but then to delete the space. Seeing the best way to do that.

gdcutting commented 5 years ago

Is it okay to leave the space? As far as I can tell this only shows up in one place, at the top of the report under 'Option Settings'. My argument for this is that since you already have a variable alias that you specify in the input file (this is the variable name/label that is used in the reporting and search/fit output), it seems useful to have a field that allows spaces that could have a more descriptive label. This is one issue, to me, with the current output is that it create a situation where it's easy to understand what your variables actually are. So allowing spaces in and treating this is as a description field might actually help with that. Also seems that it could be slightly confusing if we remove whitespace from the label that's entered in the file and then don't notify about that.

gdcutting commented 5 years ago

Further clarification from Marty: "Occam detects that the number of values in a record exceeds the number of variables, I don't think it should try to fix this and go on, since this might be true for other other states and/or other variables as well. It should just give a fatal error, telling the user that 'Record XXX has a greater number of values than the number of variables. This could be caused by a state of a variable having an internal space, which is not allowed. All internal spaces in states of variables should be removed.'"