>= Nano Trivia <= , or is it?

[Mark Pearson]

Re: &gt;= Nano Trivia &lt;= , or is it?

>= is essential when evaluating a date. If a user is required to enter a 'date from' and then 'date to', you must use >= to if the 'date to' includes the 'date from' in its equation as a valid date. This is releavant to most calander type activities based on days or time. A days sick leave can be entered as 'from today' - 'to today' giving a value of 1 day off sick.

You will always need to reflect on input of at least two dates, the only way that make this > only is to change the way a user operates and actually thinks about dates and time. Using the arguments in this thread, the user would need to enter >yesterday in the 'date from' and <tomorrow in the 'date to', to achieve a value of today. Illogical thought process to most

[Tom Cone Jr]

Re: &gt;= Nano Trivia &lt;= , or is it?

What compels someone to say >=M instead of >L?

Simple. When the possibility exists that a value being tested will be less than M but greater than L ... and you don't want anything less than M.

[rleunis]

Re: &gt;= Nano Trivia &lt;= , or is it?

"What compels someone to say >=M instead of >L?
Can you answer that? Do you have to use .not.<M?
"
Real live example:
Suppose you are looking for a partner.
And one of the criteria is:
He or she is at least as big as me?
You are referencing your own height, so you would be looking for a partner which is equal or greater than you.
Or you would be looking for someone not smaller than yourself.
I suppose you would not be looking for someone greater than yourself minus 1 (or what ever other increment)...
would you?
It's all about what are you referencing to.

[G Gabriel]

Re: &gt;= Nano Trivia &lt;= , or is it?

You stated: "The point of my question is the implementation of the combined operands ">=" and "<="."

So I thought you did not like combined operands...

That's why I gave you an alternative solution...

Not that I don't like "Combined" operands, it's the redundency of it. At what point somebody's brain says I will look for anything "more than" L vs I will look for anything "More than or equal to" M?

The restriction of an integer of 1 was not part of the original post, I think...

The thread is not all about ">=" when it comes to numerics only nor there are restrictions to integers only. That part was only in response to the example in your post. I already spent plenty enough time stating, use the value immediately before the one you are testing for. Doesn't have to be integer, but some brave soul ventured into infinity which took this discussion on a big detour that didn't have to happen as infinity has no place here.
I am not sure if I am speaking Greek? Which part of this people are having trouble understanding?
At what point your brain decides that you've got to use ">=" while you could simply and have many times used ">"? Just for simplicity 's sake, answer this question for me if you can:
What compels someone to say >=M instead of >L?
Can you answer that? Do you have to use .not.<M?

Anyway it does not change my post and validity of it, I think.

No.. I am sorry because now you are back in the same arena as ">=" where alpha has to do the double check:
<10
and
.not.
You might as well stick with ">=".

[rleunis]

Re: &gt;= Nano Trivia &lt;= , or is it?

You stated: "The point of my question is the implementation of the combined operands ">=" and "<="."

So I thought you did not like combined operands...

That's why I gave you an alternative solution...

The restriction of an integer of 1 was not part of the original post, I think...

Anyway it does not change my post and validity of it, I think.

It's also valid for any numeric value..

"What would you rather use?"

I do not have a bias towards any solution. Just the one which works and is in line with what I feel is right...As long as the result is the same.

I think this indeed rounds it up nicely:
"but for psychological impairments that seem to challenge self-affirmation, they refuse to understand it"

[G Gabriel]

Re: &gt;= Nano Trivia &lt;= , or is it?

if you do not like filter="field >= 10"
what you think about using the .not. operator:

.not.(field<10)

I would if I were a contortionist
.not.(field<10) is the same as field>9
What would you rather use? Assuming of course that the increment is an integer of 1.

[G Gabriel]

Re: &gt;= Nano Trivia &lt;= , or is it?

I covered, earlier in the thread, the only "variety of reasons" that matter,

If that's the best anyone could come up with in opposition,it's pretty lame if you ask me.
As to the first reason, my research on that came empty, so I will take your word for it but, and that goes into the second reason, clarity of code, that comes from clarity of mind which seems lacking with some.

It's a simple logic:
If something is "More than or equal to" something else, then logically it is simply more than the thing immediately before that other thing. If I explain this to my Neighbor's cat, she will get it the first time. It is not that people don't understand that, but for psychological impairments that seem to challenge self-affirmation, they refuse to understand it. Can't help anyone there and getting tired of trying.

[csda1]

Re: &gt;= Nano Trivia &lt;= , or is it?

I have yet to see those "variety of reasons"

I covered, earlier in the thread, the only "variety of reasons" that matter,

• #1 and foremost, it is not slower, it is exactly the same time to execute in Alpha Five (or just about any other computer or language still in existence). While a useful inquiry, especially if there was any time difference, the answer is 0.0000000 seconds difference in time to execute
• #2. It is logically clearer to developers and other readers of code. Clarity of code is always important, unless you wish to protect your source code through confusion - which almost always backfires when you need to revisit the code 6 months later)

Hi Ron,

if you do not like filter="field >= 10" what you think about using the .not. operator: .not.(field<10)

While a clever solution, it takes longer to execute in Alpha 5, albeit an almost unmeasurable amount, as Alpha's expression evaluation is extremely fast. Most compilers (not the AEX Alpha file code compile which is not really a compile in the computer language sense) in computer languages that do clever compiler optimizations, and one of them would convert .not.(field<10) to field>=10

What really drives coders crazy, is when a compiler sees something called Loop-invariant code motion (often not seen by a coder, or for timing delays) that is really a repetitive operation in the loop, as in

for i =1 to 50
x=10
next

eliminates it to

x=10

I'm absolutely sure Alpha Five's Xbasic does no compiler optimizations at all, as it is primarily an interpreted language. There are times, however, that the expression evaluator seems to do some minor expression optimization in it's execution, most likely Common subexpression elimination, but I have not explicitly checked for this.

But for those looking for speed, it really pays off if you understand the methods of loop optimization (especially loop unrolling), as these can be applied manually for big increases in speed.

[rleunis]

Re: &gt;= Nano Trivia &lt;= , or is it?

if you do not like filter="field >= 10"
what you think about using the .not. operator:

.not.(field<10)

[G Gabriel]

Re: &gt;= Nano Trivia &lt;= , or is it?

I have yet to see those "variety of reasons". As long as this thread has gone, haven't seen them yet and don't suppose will ever see them.

This "debate" has reached the point of diminishing returns.. all points to be made have already been made and each can make up their mind or dig their heels.. either way, is no skin off my nose.

[Al Buchholz]

Re: &gt;= Nano Trivia &lt;= , or is it?

anyone would agree if you have a numeric field incrementing on integer, then logically:
x>9
is better than
x>=10

But some like to loose the big picture and argue the exceptions.

The point is that anyone or everyone doesn't agree with that hypothesis and conclusion for a variety of reasons.

Now others have multiple points of view and can determine for themselves what is appropriate.

[G Gabriel]

Re: &gt;= Nano Trivia &lt;= , or is it?

But why bother worrying about how many decimals when you can just use '>='.

Gee.. I don't know. I didn't know that every number in every numeric field must have decimals? Didn't know that you guys use decimals in everything, and if people are having trouble with decimals, how do they manage using them routinely in these fields?! Huh! Sounds like a self-defeating argument.

These are theoretical answers to theoretical questions (really nit-picking questions) because anyone would agree if you have a numeric field incrementing on integer, then logically:
x>9
is better than
x>=10

But some like to loose the big picture and argue the exceptions.

[aRob]

Re: &gt;= Nano Trivia &lt;= , or is it?

gmeredith,

Their proofs are based on the idea that when dealing with infinity, 9.9999... and 99.9999... have the same number of decimal places so when subtracting the two numbers, the decimal part disappears. If you start with a finite number of decimal places,no matter how many, 9.9999..(finite repeat) will always be less than 10.

[gmeredith17]

Re: &gt;= Nano Trivia &lt;= , or is it?

But why bother worrying about how many decimals when you can just use '>='.

Interesting thought though G but like your thread title states its just trivia and personally I'd advocate business as usual for most scenarios and continue using the '>=' method.

Oh and as far as some of the math go it's a little worrying. I am far from a mathematician but....

(I can't bring myself to use X as it can get confusing with the multiplication symbol)

10Y=99.999

(as G said lets leave infinity alone and give it a fixed number of decimals for calculation purposes)

For 10Y to equal 99.999, Y must equal 9.9999.

Therefore

10x9.9999=99.999

Does everyone agree?

Now,

10Y-Y=99.999-9.9999

and you get

10Y-Y=89.9991 not 90.

Please also note 10Y doesn't equal 89.9991 or even 90. You all seem to be losing that -Y in your equations or -X in you examples. Where did it go?

Like I said maths isn't really my thing and I welcome any corrections to my attempt at making sense of some of these proofs.

Oh and finally I haven't read all the posts in this thread so if I have missed something then my apologises.

[G Gabriel]

Re: &gt;= Nano Trivia &lt;= , or is it?

This thread that started out with a simple concept turns out to be a debate about infinity.

So as the issue does not get lost in the ever widening debate, I still maintain that:

x>"L"
is a lot better than:
x>="M"

and:
x>{01/01/2009}
is a lot better than:
x>={01/02/2009}

and as to numeric, and hopefully by now everyone came to realize that you cannot store "Infinity" in a field (or a variable) and that you are limited to a certain number of decimals, then all you have to do, assuming that the values you are dealing with are in decimals, is to step back one decimal. For all practical purposes, the majority of all numeric fields use 2 decimals, if any. In few cases you use more. If you use 16 decimals, and if you really rely on the accuracy of the 16th decimals, you have more trouble beyond the scope of this thread.