- now that I re-examined the code, the note in commit 51fd6327a6
can be mostly ignored
PackedList isMaster(nPoints, 1u);
is not really inefficient at all, since the '1u' is packed into
32/64-bits before the subsequent assignment and doesn't involve
shifts/masking for each index
The same misinformation applies to the PackedList(size, 0u) form.
It isn't much slower at all.
Nonetheless, add bool specialization so that it is a simple assign.
- bugfix: noParallel() didn't remove 'parallel' from validParOptions
allowing it to sneak through to the Pstream layer.
noParallel() now clears the entire validParOptions as well
- new convenience methods
* addOption()
* removeOption()
* addBoolOption() - as per addOption(), but for bool options (no param)
- printUsage() output format
* options sorted alphabetically
* options listed on separate lines for better readability
- new optionUsage static member for short usage information about
an option
* corresponding addUsage() method or provide usage information
in addOption() / addBoolOption()
Note:
PackedList constructor initializes to zero, faster not to do it
ourselves.
ie,
PackedList foo(nPoints);
vs.
PackedList foo(nPoints, 0);
saves an extra nPoints operations with shifts/masks etc.
If speed is important, change this type of code
PackedList isMaster(nPoints, 1u);
for (loop)
{
if (condition)
{
isMaster.set(i, 0u); // unset bit
}
}
return isMaster;
into this:
PackedList notMaster(nPoints);
for (loop)
{
if (!condition)
{
notMaster.set(i, 1u);
}
}
notMaster.flip();
return notMaster;
or this:
PackedList isMaster(nPoints);
isMaster.flip();
for (loop)
{
if (condition)
{
isMaster.set(i, 0u);
}
}
return isMaster;
- exception calcType.H since it'll most likely be used for building
applications anyhow
- use quailified names in more of the lagrangian code
- killed some tab indents in various places.
- forgot to use readList in removeEntry, which caused the test failure.
- remaining problem:
it doesn't work as might be expected
This is the problem:
dict
{
foo xxx;
bar yyy;
}
dict
{
baz zzz;
#remove foo
}
This only removes 'foo' from the current scope (the second dict), since
it occurs before the dictionary merge does.
To remove from the final, merged dictionary, we'd need a new
deleteEntry type that would do the right thing on the merge before
self-destructing (ie, removing itself too).
- forgot to use readList in removeEntry, which caused the test failure.
- remaining problem:
it doesn't work as might be expected
This is the problem:
dict
{
foo xxx;
bar yyy;
}
dict
{
baz zzz;
#remove foo
}
This only removes 'foo' from the current scope (the second dict), since
it occurs before the dictionary merge does.
To remove from the final, merged dictionary, we'd need a new
deleteEntry type that would do the right thing on the merge before
self-destructing (ie, removing itself too).