True until disproven or false until proven? - language-agnostic

I've noticed something about my coding that is slightly undefined. Say we have a two dimension array, a matrix or a table and we are looking through it to check if a property is true for every row or nested dimension.
Say I have a boolean flag that is to be used to check if a property is true or false. My options are to:
Initialize it to true and check each cell until proven false. This
gives it a wrong name until the code
is completely executed.
Start on false and check each row until proven true. Only if all rows are true will the data be correct. What is the cleanest way to do this, without a counter?
I've always done 1 without thinking but today it got me wondering. What about 2?

Depends on which one dumps you out of the loop first, IMHO.
For example, with an OR situation, I'd default to false, and as soon as you get a TRUE, return the result, otherwise return the default as the loop falls through.
For an AND situation, I'd do the opposite.

They actually both amount to the same thing and since you say "check if a property is true for every row or nested dimension", I believe the first method is easier to read and perhaps slightly faster.
You shouldn't try to read the value of the flag until the code is completely executed anyway, because the check isn't finished. If you're running asynchronous code, you should guard against accessing the value while it is unstable.
Both methods "give a wrong name" until the code is executed. 1 gives false positives and 2 gives false negatives. I'm not sure what you're trying to avoid by saying this - if you can get the "correct" value before fully running your code, you didn't have run your code in the first place.
How to implement each without a counter (if you don't have a foreach syntax in your language, use the appropriate enumerator->next loop syntax):
1:
bool flag = true;
foreach(item in array)
{
if(!check(item))
{
flag = false;
break;
}
}
2:
bool flag = false;
foreach(item in array)
{
if(!check(item))
{
break;
}
else if(item.IsLast())
{
flag = true;
}
}

Go with the first option. An algorithm always has preconditions, postconditions and invariants. If your invariant is "bool x is true iff all rows from 0-currentN have a positve property", then everything is fine.
Don't make your algorithm more complex just to make the full program-state valid per row-iteration. Refactor the method, extract it, and make it "atomic" with your languages mechanics (Java: synchronized).

Personally I just throw the whole loop into a somewhat reusable method/function called isPropertyAlwaysTrue(property, array[][]) and have it return a false directly if it finds that it finds a case where it's not true.
The inversion of logic, by the way, does not get you out of there any quicker. For instance, if you want the first non-true case, saying areAnyFalse or areAllTrue will have an inverted output, but will have to test the exact same cases.
This is also the case with areAnyTrue and areAllFalse--different words for the exact same algorithm (return as soon as you find a true).
You cannot compare areAnyFalse with areAnyTrue because they are testing for a completely different situation.

Make the property name something like isThisTrue. Then it's answered "yes" or "no" but it's always meaningful.
In Ruby and Scheme you can use a question mark in the name: isThisTrue?. In a lot of other languages, there is a convention of puttng "p" for "predicate" on the name -- null-p for a test returning true or false, in LISP.

I agree with Will Hartung.
If you are worried about (1) then just choose a better name for your boolean. IsNotSomething instead of IsSomething.

Related

How does one incorporate Boolean logic in defined functions?

I have got this to work but I am trying to intuitively understand how the if (see below...has_botton_and_top)statement works in this instance.. i.e how the boolean logic works :
def cylinder_surface_area(radius, height,has_top_and_bottom ):
side_area = height * 6.28 * radius
if has_top_and_bottom:
top_area = 2*3.14 * radius ** 2
return (side_area + top_area)
else:return side_area
print(cylinder_surface_area(10,5,False))
I don't use Python a whole lot, but when I do I really like using the Python IDLE editor. It gives you a pretty bare-bones editor for your code, that you can execute very easily. In terms of editor, it is entirely a matter of preference. As long as the editor that you are using suits all of your needs and you can use it, it is the best editor for you.
Now, in reference to your question: I can definitely understand where your confusion comes from. The way that Python treats variables(and consequently does not require strict typing of variables) was confusing for me at first as well. From the Python documentation,
Any object can be tested for truth value, for use in an if or while
condition or as operand of the Boolean operations below. The following
values are considered false:
None False zero of any numeric type, for example, 0, 0L, 0.0, 0j. any
empty sequence, for example, '', (), []. any empty mapping, for
example, {}. instances of user-defined classes, if the class defines a
__nonzero__() or __len__() method, when that method returns the integer zero or bool value False. All other values are considered true
-- so objects of many types are always true. Operations and built-in functions that have a Boolean result always return 0 or False for
false and 1 or True for true, unless otherwise stated. (Important
exception: the Boolean operations "or" and "and" always return one of
their operands.)
Thus, your function is expecting for you to enter a Boolean input, however even if you enter a String, an Integer, a Double, or anything else it will still be able to evaluate all of these with well-defined behavior. I am assuming that your confusion comes from the fact that you can evaluate any variable as True or False, and not how Boolean logic works at its core. If you need me to explain Boolean logic as well, feel free to comment and I'll add that too.

using the OR function in Excel

I am just trying to use the OR function in Excel for analyzing some string variables. Instead of using a character count to verify whether someone anwered correctly, I would like to use the or function to accept more than one answer as correct.
For instance, return 1 if cell = "she was always there" or "she was there always".
How would I do this?
=IF(OR(A1="this",A1="that"),1,0)
IF takes three values:
The logical test
The value if true
The value if false
Each value can take other functions as it's argument. In this case, we use an OR function as the logical test. The OR can take any number of arguments (I'm sure there is a limit but I've never seen it). Each OR argument takes the form of a logical test and if any of the logical tests are TRUE, then the result of the OR is TRUE.
As a side note, you can nest many functions to create complex tests. But the nesting limit seems to be set at 7. Though there are tricks you can use to get around this, it makes reading the function later very difficult.
If you can live with "TRUE" or "FALSE" returns, then you don't need the IF function. Just:
=OR(A1="she was always there",A1="she was there always")
I found that by Googling "EXCEL OR FUNCTION"
http://office.microsoft.com/en-us/excel-help/or-function-HP010062403.aspx

How should I format this piece of code?

Here are two ways of calling callscript (in pseudocode):
using duplicate calls
if flag == true
flag = false
callscript
flag = true
else
callscript
endif
using an extra variable
flag2 = flag
flag = false
callscript
flag = flag2
conditions
I have to make sure is that flag is false when the script is called.
Also, the flag value has to be restored to the original value.
Is there a better way to do this than these two? If not, which one of these is a better choice?
The best would be to send the flag along in the call, so that the relation between the flag and the method is clear:
callscript(false)
If that's not an option, and you have to choose between the two, then either one would do. There is no clear winner, readability is about the same for both, so it's just a matter of taste.
The second option would be the better one if the actual call is complicated so that you don't want to repeat it in the code, or if the data type is something more complicated than a boolean.
I would go with variant two with a change to the name of variables to make it a bit more easy to understand.
saved_flag = flag
flag = false
callscript
flag = saved_flag
I like the second one much better, because if you name flag2 in a sensible way (like
backupValueOfFlag = flag
flag = false
callscript
flag = backupValueOfFlag
) it is much clearer what you are doing and why you are doing it.
I think this is why local variables and subroutine parameters have been invented.
Do you really have to work with globals?
I will choose the second one. The first one is too artifical for me - the if there is not for program flow but to preserve the flag value.
As for me, better choice is first one. Because it is more readable and more clear what is going on there.

What is the term for "catching" a return value

I was training a new developer the other day and realized I don't know the actual term for "catching" a return value in a variable. For example, consider this pseudocoded method:
String updateString(newPart) {
string += newPart;
return string;
}
Assume this is being called to simply update the string - the return value is not needed:
updateString("add this");
Now, assume we want to do something with the returned value. We want to change the call so that we can use the newly updated string. I found myself saying "catch the return value", meaning I wanted to see:
String returnedString = updateString("add this");
So, if you were trying to ask someone to make this change, what terminology would you use? Is it different in different languages (since technically, you may be calling either a function or a method, depending on the language)?
assign the return value to a variable?
Returned values can be assigned or discarded/ignored/not used/[insert synonym here].
There isn't really a technical term for it.
I would say "returnedString is to be initialised with the return value of updateString".
"Catch" makes me think of exceptions, which is a bit misleading. How about something like "use" or "store" or "assign"?
Common ones that I know:
You assign a value to a variable.
You store a value into a variable.
check the function's return value, do not ignore return values
In the example, you're simply assigning the return value of the function to a new variable.
When describing the behavior of that single line of code, it doesn't really matter that the return value is not essential to the use of the function. However, in a broader context, it is very important to know what purpose this "Interesting Return Value" serves.
As others have said there isn't really a word for what you describe. However, here's a bit of terminology for you to chew on: the example you give looks like it could be a Fluent Interface.
I suggest "cache", meaning store it for later.
Maybe there's a subliminal reason you're saying "catch".
It's better too state the purpose rather than the implementation details (because actual implementation can be different in different programming langugages).
Generally speaking:
- Save the return value of the call.
If you know the return value is a result of something:
- Save the result of the call.
If you know the return value is to signify a status (such as error):
- Save the status of the call.
By using the word "save", you can use that same statement across the board, regardless of the mechanism used in that particular language to save the return value.

Best Practice: function return value or byref output parameters?

I have a function called FindSpecificRowValue that takes in a datatable and returns the row number that contains a particular value. If that value isn't found, I want to indicate so to the calling function.
Is the best approach to:
Write a function that returns false if not found, true if found, and the found row number as a byref/output parameter, or
Write a function that returns an int and pass back -999 if the row value isn't found, the row number if it is?
Personally I would not do either with that method name.
I would instead make two methods:
TryFindSpecificRow
FindSpecificRow
This would follow the pattern of Int32.Parse/TryParse, and in C# they could look like this:
public static Boolean TryFindSpecificRow(DataTable table, out Int32 rowNumber)
{
if (row-can-be-found)
{
rowNumber = index-of-row-that-was-found;
return true;
}
else
{
rowNumber = 0; // this value will not be used anyway
return false;
}
}
public static Int32 FindSpecificRow(DataTable table)
{
Int32 rowNumber;
if (TryFindSpecificRow(table, out rowNumber))
return rowNumber;
else
throw new RowNotFoundException(String.Format("Row {0} was not found", rowNumber));
}
Edit: Changed to be more appropriate to the question.
functions that fail should throw exceptions.
If failure is part of the expected flow then returning an out of band value is OK, except where you cannot pre-determine what an out-of-band value would be, in which case you have to throw an exception.
If I had to choose between your options I would choose option 2, but use a constant rather than -999...
You could also define return value as Nullable and return Nothing if nothing found.
I would choose option 2. Although I think I would just use -1 not -999.
Richard Harrison is right that a named constant is better than a bare -1 or -999.
I would go with 2, or some other variation where the return value indicates whether the value was found.
It seems that the value of the row the function returns (or provides a reference to) already indicates whether the value was found. If a value was not found, then it seems to make no sense to provide a row number that doesn't contain the value, so the return value should be -1, or Null, or whatever other value is suitable for the particular language. Otherwise, the fact that a row number was returned indicates the value was found.
Thus, there doesn't seem to be a need for a separate return value to indicate whether the value was found. However, type 1 might be appropriate if it fits with the idioms of the particular language, and the way function calls are performed in it.
Go with 2) but return -1 (or a null reference if returning a reference to the row), that idiom is uses extensively (including by by .nets indexOf (item) functions), it's what I'd probably do.
BTW -1 is more acceptable and widly used "magic number" than -999, thats the only reason why it's "correct" (quotes used there for a reason).
However much of this has to do with what you expect. Should the item always be in there, but you just don't know where? In that case return the index normally, and throw an error/exception if it's not there.
In this case, the item might not be there, and that's an okay condition. It's an error trap for unselected values in a GridView that binds to a datatable.
Another few possibilities not yet mentioned:
// Method 1: Supports covariance; can return default<T> on failure.
T TryGetThing(ref bool success);
// Method 2: Does not support covariance, but may allow cleaner code in some cases
// where calling code would use some particular value in in case of failure.
T TryGetThing(T DefaultValue);
// Method 3: Does not support covariance, but may allow cleaner code in some cases
// where calling code would use some particular value in case of failure, but should
// not take the time to compute that value except when necessary.
T TryGetThing(Func<T> AlternateGetMethod);
// Method 4: Does support covariance; ErrorMethod can throw if that's what should
// happen, or it can set some flag which is visible to the caller in some other way.
T TryGetThing(Action ErrorMethod);
The first approach is the reverse of the method Microsoft developed in the days before support existed for covariant interfaces. The last is in some ways the most versatile, but is likely to require the creation of a couple of new GC object instances (e.g. a closure and a delegate) each time it's used.