Overunity.com Archives is Temporarily on Read Mode Only!



Free Energy will change the World - Free Energy will stop Climate Change - Free Energy will give us hope
and we will not surrender until free energy will be enabled all over the world, to power planes, cars, ships and trains.
Free energy will help the poor to become independent of needing expensive fuels.
So all in all Free energy will bring far more peace to the world than any other invention has already brought to the world.
Those beautiful words were written by Stefan Hartmann/Owner/Admin at overunity.com
Unfortunately now, Stefan Hartmann is very ill and He needs our help
Stefan wanted that I have all these massive data to get it back online
even being as ill as Stefan is, he transferred all databases and folders
that without his help, this Forum Archives would have never been published here
so, please, as the Webmaster and Creator of this Forum, I am asking that you help him
by making a donation on the Paypal Button above
Thanks to ALL for your help!!


Time Travel Research

Started by telemachus, October 10, 2011, 03:51:51 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

WilbyInebriated

Quote from: CuriousChris on October 24, 2011, 04:45:31 AM
Not wanting to pick sides here, but as I am an accomplished programmer I feel I can contribute.
In many programming languages "" == 0 ( "==" means "is equal to?", "=" normally means assignment, as in let A be equal to B )
technically == is an 'equal' operator but, it is for integers... for strings, as used in thecuttingedge's example, the correct operand would be eq and not ==.  again. strings are not integers...

Quote from: CuriousChris on October 24, 2011, 04:45:31 AM
Some languages regard "" as undefined and will throw an error if you try to assign it to an integer or float. This is the common "NaN" error.
the difference may be subtle, but there is a difference...

0 represents an integer in the set of all integers (called the set Z in mathematics) NULL (which is what "" is) is not an integer, and it could represent the absence of things that aren't even numbers (as it does in this case... ie: "" is a nullstring and not an integer).

Quote from: CuriousChris on October 24, 2011, 04:45:31 AM
But languages such as c and its derivatives will normally assign the value 0 (zero)
is entirely acceptable psuedocode and often used.

CC
no. if i were to write the code:
if (ohm="")  {ohm=0;}
what would be happening is... that if variable ohm was a null string it would then be set to an integer. 0 in this case. since you are referencing C and derivatives try this code equivalent:
"".Contains(0);
and see if it returns false or true...

it's not even pseudocode...  ::)
There is no news. There's the truth of the signal. What I see. And, there's the puppet theater...
the Parliament jesters foist on the somnambulant public.  - Mr. Universe

CuriousChris

Drinking again are we?
Quote from: WilbyInebriated on October 24, 2011, 05:14:18 AM
technically == is an 'equal' operator but, it is for integers... for strings, as used in thecuttingedge's example, the correct operand would be eq and not ==.  again. strings are not integers...
the difference may be subtle, but there is a difference...

In what language ? in perl 'eq' is correct for strings, in bash 'eq' is correct for integers. In C/C++ == is correct for integers and pointers to characters, a string is nothing more than an array of characters. When dereferencing C/C++ pointers, it points to the first character (of the string). For a null string "" the first character is (multi)byte 0.

For a scripting language such as perl 'eq' is the string comparison operator. it does not exist in languages such as c/c++ etc.

So for C/C++ if ( *Ohm == "" ) is perfectly valid whereas in perl you would use if ( $ohm eq "" ) and in bash  if [ $ohm == "" ]


Quote from: WilbyInebriated on October 24, 2011, 05:14:18 AM
0 represents an integer in the set of all integers (called the set Z in mathematics) NULL (which is what "" is) is not an integer, and it could represent the absence of things that aren't even numbers (as it does in this case... ie: "" is a nullstring and not an integer).
no. if i were to write the code:
if (ohm="")  {ohm=0;}
what would be happening is... that if variable ohm was a null string it would then be set to an integer. 0 in this case. since you are referencing C and derivatives try this code equivalent:
"".Contains(0);
and see if it returns false or true...

There is no such thing as "".Contains() in C. C is not object oriented. If you attempted that you would get a compiler error. even c++ which is object oriented "".Whatever() is invalid.

But if it were valid "".Contains(0) (like in c#) it would return false, because it is a null string and does not contain anything at all.

Hence why I said "in many languages". That was the point. As I don't know what language cutting was talking about I was not limiting the discussion.

Quote from: WilbyInebriated on October 24, 2011, 05:14:18 AM
it's not even psuedocode...  ::)

Actually it is psuedocode, psuedocode does not need to be syntactically correct and in fact does not have a syntax other than it must portray the intention of the code. that's why its called psuedocode.

WilbyInebriated

Quote from: CuriousChris on October 24, 2011, 05:52:57 AM
Drinking again are we?
In what language ? in perl 'eq' is correct for strings, in bash 'eq' is correct for integers. In C/C++ == is correct for integers and pointers to characters, a string is nothing more than an array of characters. When dereferencing C/C++ pointers, it points to the first character (of the string). For a null string "" the first character is (multi)byte 0.
i don't drink... it's wilby... as in will be. as in arguing the difference tween null and 0 with neophytes will be driving me to drinking... ::) the symbol zero is converted into NULL by the compiler in (void *)0. The internal representation of NULL doesn't have to be zero and it's not correct to say that the NULL pointer is zero... ::)

Quote from: CuriousChris on October 24, 2011, 05:52:57 AM
So for C/C++ if ( *Ohm == "" ) is perfectly valid whereas in perl you would use if ( $ohm eq "" ) and in bash  if [ $ohm == "" ]
and if i were to use your perl code and print qq{$ohm}; it would print nothing... it wouldn't print 0  now would it. ;) because they are NOT equal, nor synonymous.


Quote from: CuriousChris on October 24, 2011, 05:52:57 AM
There is no such thing as "".Contains() in C. C is not object oriented. If you attempted that you would get a compiler error. even c++ which is object oriented "".Whatever() is invalid.

But if it were valid "".Contains(0) (like in c#) it would return false, because it is a null string and does not contain anything at all.
my bad. i should have said C# and it would return false because... wait for it...  the Contains (and Compare) function is for comparing strings to strings and not strings to integers... ;)

Quote from: CuriousChris on October 24, 2011, 05:52:57 AM
Hence why I said "in many languages". That was the point. As I don't know what language cutting was talking about I was not limiting the discussion.

Actually it is psuedocode, psuedocode does not need to be syntactically correct and in fact does not have a syntax other than it must portray the intention of the code. that's why its called psuedocode.
but you are missing the point... again...
null is not 0. nor are they synonyms...
and in C the symbol zero is converted into NULL by the compiler in (void *)0. the internal representation of NULL doesn't have to be zero and it's not correct to say that the NULL pointer is zero... ::)

actually it's not pseudocode. from teh wiki...
"pseudocode is a compact and informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a programming language, but is intended for human reading rather than machine reading. Pseudocode typically omits details that are not essential for human understanding of the algorithm, such as variable declarations, system-specific code and some subroutines."

although i agree that it does have some qualities of actual pseudocode, such as not declaring vars or subs, that doesn't make it pseudocode.

edit: if you want to argue this further, i suggest you take it to stackoverflow...
There is no news. There's the truth of the signal. What I see. And, there's the puppet theater...
the Parliament jesters foist on the somnambulant public.  - Mr. Universe

CuriousChris

Quote from: WilbyInebriated on October 24, 2011, 06:08:22 AM
i don't drink... it's wilby... as in will be.

but you are missing the point... again...
null is not 0. nor are they synonyms...
and in C the symbol zero is converted into NULL by the compiler in (void *)0. the internal representation of NULL doesn't have to be zero and it's not correct to say that the NULL pointer is zero... ::)

actually it's not pseudocode. from teh wiki...
"pseudocode is a compact and informal high-level description of the operating principle of a computer program or other algorithm. It uses the structural conventions of a programming language, but is intended for human reading rather than machine reading. Pseudocode typically omits details that are not essential for human understanding of the algorithm, such as variable declarations, system-specific code and some subroutines."

although i agree that it does have some qualities of actual pseudocode, such as not declaring vars or subs, that doesn't make it pseudocode.

...

edit: if you want to argue this further, i suggest you take it to stackoverflow...

Yeah I got the name. on here you must spend a lot of time looking wistfully at the bottle.

I never said anything about null pointers. "" IS NOT a null pointer! it is an empty string in C/C++ that is represented by the character "\0"

now try this on a C compiler.

Quote#include <stdio.h>
#include <stdlib.h>

int main() {
    int i = atoi("");
    printf("%d",i);
    return 0;
}




Then read the return values section here...
http://www.cplusplus.com/reference/clibrary/cstdlib/atoi/

Reread your paragraph about psuedocode. your interpretation is simply different from mine thats it. psuedocode can be totally different depending on the language you are used to. psuedocode for Python would be different from psuedocode for PERL. The Parentheses and Braces you added where superfluous and are not usually shown is psuedocode, unless it was necessary or simply easier/quicker/clearer.

SO. Yeah I have spent a bit of time on there.


WilbyInebriated

Quote from: CuriousChris on October 24, 2011, 08:28:33 AM
Yeah I got the name. on here you must spend a lot of time looking wistfully at the bottle.

I never said anything about null pointers. "" IS NOT a null pointer! it is an empty string in C/C++ that is represented by the character "\0"
yeah i got a bottle with your name on it now... ;)
we have been talking about null and 0 and you mentioned C pointers... hello context!!... ::)

look... regarding false, null, nothing, 0, undefined, etc., etc.
each of these has specific meanings that correlate with actual concepts. sometimes multiple meanings are overloaded into a single keyword or value.
in C and C++, NULL, false and 0 are overloaded to the same value (in my opinion, C is 'broken' in that respect). in C# they're 3 distinct concepts.

null or NULL usually indicates a lack of value, but usually doesn't specify why. 0 indicates the natural number zero and has type-equivalence to 1, 2, 3, etc. and in languages that support separate concepts of NULL should be treated only a number.

false indicates non-truth. and it used in binary values. it doesn't mean unset, nor does it mean 0... it simply indicates one of two binary values...

nothing can indicate that the value is specifically set to be nothing which indicates the same thing as null, but with intent...

undefined in some languages indicates that the value has yet to be set because no code has specified an actual value...

Quote from: CuriousChris on October 24, 2011, 08:28:33 AM
now try this on a C compiler.
your example is barely even tangential to the discussion... you are converting string to integer which is not what thecuttingedge's "pseudocode" as you call it was doing... is it? ::) but thank you for proving my point that strings are not integers and must be converted to like type before compare. ;)

Quote from: CuriousChris on October 24, 2011, 08:28:33 AM
Reread your paragraph about psuedocode. your interpretation is simply different from mine thats it. psuedocode can be totally different depending on the language you are used to. psuedocode for Python would be different from psuedocode for PERL. The Parentheses and Braces you added where superfluous and are not usually shown is psuedocode, unless it was necessary or simply easier/quicker/clearer.

SO. Yeah I have spent a bit of time on there.
i am aware what pseudocode is. ::) if you insist on being pedantic, please spell it correctly...  and no, it doesn't have to look any different in python, perl, pascal, c or any other language you can think of... that's the point of pseudocode... ::)
eg:
extract the next word from the line (good)
set word to get next token (poor)

append the file extension to the name (good)
name = name + extension (poor)

FOR all the characters in the name (good)
FOR character = first to last (ok)

another eg:
set total to zero
set grade counter to one
while grade counter is less than or equal to ten
      input the next grade
      add the grade into the total
set the class average to the total divided by ten
print the class average.

furthermore, i wasn't showing pseudocode... i was showing actual code that would compile... what are you going on about?
There is no news. There's the truth of the signal. What I see. And, there's the puppet theater...
the Parliament jesters foist on the somnambulant public.  - Mr. Universe