grid command causes fpe

[gary]

both attempted uses of the grid command for the bernard loop paper ended in fpes. the common thread is R3244:3245

---

the following throws an fpe

test element nitrogen abundance -4.2 vary grid -4.5 -3.5 0.5

adding log to the command does not help. The grid command does what it is supposed to do - it emits -4.5, -4. and -3.5. The problem is the forced linear interpretation of these negative numbers at parse_elements.cpp:484 - added in 3245

---

the following throws an fpe test constant temperature 4 vary grid from 4e3K to 2e4K in 2e3K steps

the problem is r3244 - forced log interpretation at parse_constant.cpp:65, which is forced by the log on the vary option at line 100. that forced log is r4344

every grid command i tried for this paper threw an fpe.

[gary]

Ryan pointed out that the log/linear keyword on the grid command would fix the constant temperature case - that is correct. But the problems are wider and deeper than only that.

Simplicity is always better than complexity. A possible solution: it introduces another level of complexity - lots of commands accept the vary/grid option. would all commands require the linear / log option? for commands that don't have the linear/log distinction, do we still require the keyword on the grid command? or is it only required for temperature commands?

i have not studied this part of the code - does the linear / log option change what the grid command emits? svn blame shows that the current source for the constant temperature log interpretation had a delta on r3941/3942 on 2010 may 27 - comments say there was no net change with this pair. the forced log interpretation was added to the vary command in r3244. the command had followed the code's rules before that rev.

if we agree that we want to move towards "no logs in the input parser" we don't want to add more log use, and also want to make it possible to not use them at all. I don't remember why we force the log rule in this constant temperature command, or what inspired r3244.

We need to do cases where the grid command emits the following for quantities that range over a vary wide range

hden 3 vary grid 1 5 1

then do hden 1 hden 2 hden 3 hden 4 hden 5

for this case we do want log steps.

but for other cases (like what i was trying to do) we want linear steps, as the following:

constant temperature 3 grid 4e3 6e3 1e3

we want to do: constant temperature 4e4 constant temperature 5e4 constant temperature 6e4

I think both would work if we just had the simplest possible grid command which emitted what a for loop would do in C. It should do nothing clever at all. Then let the constant temperature command follow the code's other rules. Is there something wrong with this simplest possible rule? There must have been a good reason for r3244

We will have to think about how to do the first case when we don't have logs, but the current implementation has that problem too.

My question, before adding more rules to the grid command, is there a problem with a really simple grid command, which simply emitted what a C "for" loop would do, with the constant temperature following the code's rules?

[gary]

there is a hack to get the constant temperature command to not throw an fpe in r4098

[gary]

one final note -

user input must never be blindly accepted. If a number has been scanned in THE CODE WILL CHECK THAT IT IS >0 BEFORE TAKING A LOG. Anything else is irresponsible.

user input should be taken as a dangerous assault on the code. Verify it before accepting it. Do not throw an fpe. Explain what is wrong. It should be impossible for a number entered on a command line to cause an fpe.

[gary]

r4112 hacks the element name abundance command so that it works with the grid command