When to use IMP operator in ColdFusion? - coldfusion

Implication: The statement A IMP B is the equivalent of the logical
statement “If A Then B.” A IMP B is False only if A is True and B is
False. It is True in all other cases.
http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec09d55-7ffc.html
I can vaguely remember what is an "implication" from college. When to use IMP operator in the real world?

After I applied my google-fu
Found this: http://www.cfug-md.org/meetings/RichardBierregaardLogicwCFConditionals.ppt
and it inspires me to find out that IMP might be useful for writing unit test:
assertTrue(Income >= 200000 IMP TaxRate == 0.35);
assertTrue(Income < 200000 AND Income >= 70000 IMP TaxRate == 0.28);
assertTrue(Income < 70000 AND Income >= 35000 IMP TaxRate == 0.20);
assertTrue(Income < 35000 AND Income >= 15000 IMP TaxRate == 0.10);
assertTrue(Income < 15000 IMP TaxRate == 0);
instead of
if (Income >= 200000) assertTrue(TaxRate == 0.35);
if (Income < 200000 AND Income >= 70000) assertTrue(TaxRate == 0.28);
if (Income < 70000 AND Income >= 35000) assertTrue(TaxRate == 0.20);
if (Income < 35000 AND Income >= 15000) assertTrue(TaxRate == 0.10);
if (Income < 15000) assertTrue(TaxRate == 0);
Do you think IMP version is better?

In the real world, it would be handy to be able to do something like this, to perform validation on optional params:
<cfif structKeyExists(URL, "a") IMP validateId(URL.a)>
Wherein we only care about validation of URL.a if it exists. That'd be about the most useful application of IMP, IMO (well, like, it would be).
However due to a bug in the implementation of IMP, this doesn't work :-(
I think Dale's assertion that the much longer (and incorrect) logic is easier to read than the shortened version is self-evidentally wrong, and based on a specious premise to boot. His position is based on an idea that "someone not knowing something" is a continuous state, ie: when someone doesn't know something (like what "IMP" means), then they will forever not know it. This is not true. A person might not know something initially, but once they find out about it, then they will know about it. So the problem of not knowing how the IMP oerator works is a very short-lived one.
I don't think situations arise wherein IMP is needed arise very often, but it's handy to have it there. And it'd be handier still if it worked properly ;-)

I think you should stay clear of it, I've never seen it used and never had a need to use it. Other developers mostly wont understand what it is or means.
I would rather write
<cfif a eq true and b eq false>
than
<cfif a imp b>
The first is much clearer.

Related

What am I misunderstanding when determining if a value is between two numbers?

I have a PDF form that adds up several different answers and displays the sum of these answer at the bottom of the page. I want to take that number, and have a sentence underneath it display three different options depending on the sum.
Greater than 60: Proceed
between 45 & 60: Consult Sales Lead
Less than 45: Decline
I am attempting to run a custom calculation script that takes the sum (which is named "total") and writes the above options, but I'm running into a myriad of errors.
My code I've written is below
var A = this.getField("total").value;
if (A >= 60){
event.value = "Proceed";
} else {
if (A <= 45){
event.value = "Decline";}
} else {
if (A < 60 && A > 45){
event.value = "Proceed, decision made with sales leader";}
}
If I were to only write the below block, I do not get any errors.
var A = this.getField("total").value;
if (A >= 60){
event.value = "Proceed";
}
I'm a newbie when it comes to most JavaScript, so any help is greatly appreciated! Thanks in advance!
I have based most of my code off of different search results from google. My main source
example 1
Below are a few other links I've referenced
example 2
example 3
You can leave away the
if (A < 60 && A > 45) {
line, because that condition is always true after the two previous conditions.
And then, it should work properly.
Just if you want to stay with that last condition, you would have to close it with a curly brace.
I think I managed to figure it out! For some reason, the addition of the "else" factor was causing syntax errors, so I tried it without and it seems to work as intended!
My code, for anyone that happens to find this, is the following:
var A = this.getField("total").value;
if (A >= 60) {event.value = "Proceed";}
if (A <= 59 && A >= 46) {event.value = "Proceed, decision made with sales leader";}
if (A <= 45) {event.value = "Decline";}
if (A == 0) {event.value = " ";}
Thanks to everyone that took a look at this, even if you didn't get to comment before I figured it out!

If else condition precedence in Verilog

I have noticed that there is a precedence of assignment while using if-else conditionals in Verilog. For example as in the code below:
if(counter < 6)
z <= 1;
else if(counter < 12)
z <= 2;
else
z <= 3;
I noticed that until the counter is less than 6, the value of z is assigned the value of 1 (z <= 1) and as soon as the value of the counter exceeds 6 and is less than 12, z is assigned the value 2 (z <= 2).
What if there are different variables used inside the conditionals as in the code below?
if(wire1_is_enabled)
z <= 1;
else if(wire2_is_enabled)
z <= 0;
What happens when both conditions are true? What is the behaviour of the assignment operator here?
I believe this is poor programming habit.
Yes, nested if-else branching statements naturally assume a priority in the order of execution. Think about using a case statement instead of deeply nesting if statements which are much more readable.
There is nothing wrong with this coding style unless you have code like:
if(counter < 6)
z <= 1;
else if(counter < 2)
z <= 2; // unreachable
else
z <= 3;
Then the statement z <= 2; becomes unreachable because when the first condition is false, the second condition can never be true. Fortunately there are a number of tools that can flag this problem for you.
Both if and case statements assume priority logic. However, you have an option to explicitly add a priority or unique keyword before the if or case keywords to declare and check your intent. See sections 12.4 and 12.5 in the IEEE 1800-2017 SystemVerilog LRM.
The 2 if/else statements behave the same way; the first condition to be true has the highest priority. Once a condition evaluates to true, all the following else clauses are ignored. Therefore, z <= 1 if both wire1_is_enabled and wire2_is_enabled are true. This is easy to prove to yourself with a simple simulation.
This is not a poor coding habit. This situation is common in Verilog. When you say programming, perhaps you are thinking of software languages. Keep in mind that these are hardware signals instead of software variables.

Can I use return to return to the start of an if statement?

I'm currently programming some homework, and we have to make a program that turns a hindu-arabic numeral into a roman numeral. I've already made the first part, where my teacher said we had to make sure the number is in between 1 and 3999. My algorithm so far is like this:
if (num-1000) > 0 {
add M to output
num -= 1000
return if
}
else {
(repeat for other digits, aka 500, 100, 50, and so on)
}
The problem is, I don't know if it's even possible. All the Stack Overflow pages I've seen say that I should use while statements for this, but since we haven't tackled while statements yet (even though I've self-learned it) we can't use while loops. So, can I use return to return to the start of an if statement?
What you are describing is a while. You can also achieve that with a go to but using that at this stage of learning would inspire some very very bad habits so I wholeheartedly discourage it. Another way you could do this is with recursion but that is an even more advance topic.
Given your restrictions (no loops, a number between 1 and 3999) I think you are supposed to use a bunch of ifs. Something like this pseudocode:
if (n >= 3000)
add 'M'
else if (n >= 2000)
add 'MM'
else if (n >= 1000)
add 'MMM'
n = n % 1000;
if (n >= 900)
add 'CM'
// and so on

Is condition evaluation optimized ? Is this code bad?

1.Imagine condition if (obj.is_x() || obj.is_y() || obj.is_z())
Will obj.is_y() and obj.is_z() be called and evaluated if obj.is_x() returned true ?
2.Is this a bad idea(in general)? Does this code look bad ?
bool isbn13_prefix_valid (const string& prefix)
{
unsigned num = stoi(prefix);
if (num == 978 || num == 979) return 1; //super common ones
else if ( num >= 0 && num <= 5 || num == 7 || num >= 600 && num <= 649
|| num >= 80 && num <= 94 || num >= 950 && num <= 989
|| num >= 9900 && num <= 9989 || num >= 99900 && num <= 99999)
return 1;
return 0;
}
No, it will not, due to short-circuiting.
Yes, that code looks bad. Not because it's incorrect, but because you're stuffing an extremely long conditional into a single if statement. Try refactoring your code to make it cleaner.
Your code is absolutely fine. I'd like to see a comment where these strange numbers come from, that's all.
Turning it into a dozen trivial functions as has been suggested is in no way helpful. It actually makes it a lot harder to read the code, because it gets spread out over many many lines of code. Yes, it is complex. But that's due to the problem being complex, and trying to spread the complexity out doesn't help one bit.
Your actual question: In a || b, a is evaluated first. If it is true, then b is not evaluated and the result is true. If a is false, then b is also evaluated and the result is true or false, depending on the result of b.
An optimising compiler may start evaluating b before it has finished evaluating a, if it can prove that the evaluation of b has no side effects, and if it believes that (mostly due to parallelism in the hardware) it is on average faster to evaluate as much in parallel as possible, even if some things are evaluated when it wasn't necessary. But this is not noticable in the results of your code, and will only make the code faster.

Is it possible to define a variable in expression in C++?

I have this insane homework where I have to create an expression to validate date with respect to Julian and Gregorian calendar and many other things ...
The problem is that it must be all in one expression, so I can't use any ;
Are there any options of defining variable in expression? Something like
d < 31 && (bool leapyear = y % 4 == 0) || (leapyear ? d % 2 : 3) ....
where I could define and initialize one or more variables and use them in that one expression without using any ;?
Edit: It is explicitly said, that it must be a one-line expression. No functions ..
The way I'm doing it right now is writing macros and expanding them, so I end up with stuff like this
#define isJulian(d, m, y) (y < 1751 || (y == 1752 && (m < 9) || (m == 9 && d <= 2)))
#define isJulianLoopYear(y) (y % 4 == 0)
#define isGregorian(d, m, y) (y > 1573 || (y == 1752 && (m > 9) || (m == 9 && d > 13)))
#define isGregorianLoopYear(y) ((y % 4 == 0) || (y % 400 = 0))
// etc etc ....
looks like this is the only suitable way to solve the problem
edit: Here is original question
Suppose we have variables d m and y containing day, month and year. Task is to write one single expression which decides, if date is valid or not. Value should be true (non-zero value) if date is valid and false (zero) if date is not valid.
This is an example of expression (correct expression would look something like this):
d + 4 == y ^ 85 ? ~m : d * (y-2)
These are examples of wrong answers (not expressions):
if ( log ( d ) == 1752 ) m = 1;
or:
for ( i = 0; i < 32; i ++ ) m = m / 2;
Submit only file containing only one single expression without ; at the end. Don't submit commands or whole program.
Until 2.9.1752 was Julian calendar, after that date is Gregorian calendar
In Julian calendar is every year dividable by 4 a leap year.
In Gregorian calendar is leap year ever year, that is dividible by 4, but is not dividible by 100. Years that are dividable by 400 are another exception and are leap years.
1800, 1801, 1802, 1803, 1805, 1806, ....,1899, 1900, 1901, ... ,2100, ..., 2200 are not loop years.
1896, 1904, 1908, ..., 1996, 2000, 2004, ..., 2396,..., 2396, 2400 are loop years
In september 1752 is another exception, when 2.9.1752 was followed by 14.9.1752, so dates 3.9.1752, 4.9.1752, ..., 13.9.1752 are not valid.
((m >0)&&(m<13)&&(d>0)&&(d<32)&&(y!=0)&&(((d==31)&&
((m==1)||(m==3)||(m==5)||(m==7)||(m==8)||(m==10)||(m==12)))
||((d<31)&&((m!=2)||(d<29)))||((d==29)&&(m==2)&&((y<=1752)?((y%4)==0):
((((y%4)==0)&&((y%100)!=0))
||((y%400)==0)))))&&(((y==1752)&&(m==9))?((d<3)||(d>13)):true))
<evil>
Why would you define a new one, if you can reuse an existing one? errno is a perfect temporary variable.
</evil>
I think the intent of the homework is to ask you to do this without using variables, and what you are trying to do might defeat its purpose.
In standard C++, this is not possible. G++ has an extension known as statement expressions that can do that.
I don't believe you can, but even if you could, it would only have scope inside of the parentheses they are defined in (in your example) and cannot be used outside of them.
Your solution, which I will not provide fully for you, will probably go along these lines:
isJulian ? isJulianLeapyear : isGregorianLeapyear
To make it more specific, it could be like this:
isJulian ? (year % 4) == 0 : ((year % 4) == 0 || (year % 400) == 0)
You'll have to just make sure your algorithm is correct. I'm not a calender expert, so I wouldn't know about that.
First: Don't. It may be cute, but even if there's an extension that allows it, code golf is a dangerous game that will almost always end up causing mmore grief than it solves.
Okay, back to the 'real' question as defined by the homework. Can you make additional functions? If so, instead of capturing whether or not it's a leap year in a variable, make a function isLeapYear(int year) that returns the correct value.
Yes, that means you'll calculate it more than once. If that ends up being a performance issue, I'd be incredibly surprised... and it's a premature optimization to worry about that in the first place.
I'd be very surprised if you weren't allowed to write functions as part of doing this. It seems like that'd be half the point of an exercise like this.
......
Okay, so here's a quick overview of what you'll need to do.
First, basic verification - that month, day, year are possible values at all - month 0-11 (assuming 0-based), day 0-30, year non-negative (assuming that's a constraint).
Once you're past that, I'd probably check for the 1752 special cases.
If that's not relevant, the 'regular' months can be handled pretty simply.
This leaves us with the leap year cases, which can be broken down into two expressions - whether something is a leap year (which will be broken down additionally based on gregorian/julian), and whether the date is valid at that point.
So, at the highest level, your expression looks something like this:
areWithinRange(d,m,y) && passes1752SpecialCases(d,m,y) && passes30DayMonths(d,m,y) && passes31DayMonths(d,m,y) && passesFebruaryChecks(d,m,y)
If we assume that we only return false from our sub-expressions if we actively detect a rule break (31 days in June for the 30DayMonth rule returns false, but 30 days in February is irrelevant and so passes true), then we can pretty much say that the logic at that level is correct.
At this point, I'd write separate functions for the individual pieces (as pure expressions, a single return ... statement). Once you've gotten those in place, you can replace the method call in your top-level expression with the expanded version. Just make sure you parenthesize (is that a word?) everything sufficiently.
I'd also make a test harness program that uses the expression and has a number of valid and invalid inputs, and verifies that you're doing the right thing. You can write that in a function for ease of cut and paste for the final turn-in by doing something like:
bool isValidDate(int d, int m, int y)
{
return
// your expression here
}
Since the expression will be on a line by itself, it'll be easy to cut and paste.
You may find other ways to simplify your logic - excepting the 1752 special cases, days between 1 and 28 are always valid, for instance.
Considering it is homework, I think the best advice would be an approach to deriving your own solution.
If I were tackling this assignment, I would start by breaking the rules.
I would write a c++ function that given the variables d, m, and y, returns a boolean result on the validity of the date. I would use as many non-recursive helper functions as needed, and feel free to use if, else if, and else, but no looping aloud.
I would then Inline all helper functions
I would reduce all if, else if, and else statement to ? : notation
If I was successful at limiting my use of variables, I might be able to reduce all this to a single function with no variables - the body of which will contain the single expression I seek.
Good Luck.
You clearly have to have the date passed in somehow. Beyond that, all you're really going to be doing is chaining && and || (assuming we get the date as a tm struct):
#include <ctime>
bool validate(tm date)
{
return (
// sanity check that all values are positive
date.tm_mday >= 1 && date.tm_mon >= 0 && date.tm_year >= 0
// check for valid days
&& ((date.tm_mon == 0 && date.tm_mday <= 31)
|| (date.tm_mon == 1 && date.tm_mday <= (date.tm_year % 4 ? 28 : 29))
|| (date.tm_mon == 2 && date.tm_mday <= 31)
// yadda yadda for the other months
|| (date.tm_mon == 11 && date.tm_mday <= 31))
);
}
The parenthesis around date.tm_year % 4 ? 28 : 29 actually aren't needed, but I'm including them for readability.
UPDATE
Looking at a comment, you'll also need similar rules to validate dates that don't exist in the Gregorian calendar.
UPDATE II
Since you're dealing with dates in the past you will need to implement a more correct leap year test. However, I generally deal with dates in the future, and this incorrect leap year test will give correct results in 2012, 2016, 2020, 2024, 2028, 2032, 2036, 2040, 2044, 2048, 2052, 2056, 2060, 2064, 2068, 2072, 2076, 2080, 2084, 2088, 2092, and 2096. I will make a prediction that before this test fails in 2100 silicon-based computers will be forgotten relics. I seriously doubt we will use C++ on the quantum computers in use then. Besides, I won't be the programmer assigned to fix the bug.