Comment On Constant Extensibility

Thomas P was working on some code a while back where the original developer had devised a "clever" way of encoding errors. [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Constant Extensibility

2007-10-05 09:19 • by ZOMGWTF (unregistered)
Or would that be a bitwise-OR to encode?

2^32

2007-10-05 09:21 • by Marcan (unregistered)
So if the app has more than 32 errors there is a FOURBILLIONTWOHUNDREDNINETYFOURMILLIONNINEHUNDREDSIXTYSEVENTHOUSANDTWOHUNDREDNINETYSIX?

*shudders*

Job security anyone?

Re: Constant Extensibility

2007-10-05 09:21 • by nEUrOO (unregistered)
156051 in reply to 156049
In old times :D we used to do that in order to save space...

Re: Constant Extensibility

2007-10-05 09:25 • by sobani (unregistered)
156053 in reply to 156051
Could you please explain to me how you save space by writing a number down, instead of using the number itself?

At least if I understand correct, you use THOUSANDTWENTYFOUR instead of 1024 to save space, right?

Re: Constant Extensibility

2007-10-05 09:32 • by Rank Amateur
<obligatory>
But this is essential in case they ever change the value of one thousand twenty four or two thousand forty eight.
</obligatory>
--Rank

Re: Constant Extensibility

2007-10-05 09:34 • by Josh (unregistered)
From way back in high school computer science, they would teach us never to use "magic" numbers. That is, every value should be represented by a constant or a variable.

Of course, the *idea* was that you were supposed to document the *purpose* of each value.

But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.

Re: Constant Extensibility

2007-10-05 09:35 • by Jason (unregistered)
156056 in reply to 156053
sobani:
Could you please explain to me how you save space by writing a number down, instead of using the number itself?

At least if I understand correct, you use THOUSANDTWENTYFOUR instead of 1024 to save space, right?
I believe he was referring to returning a single interger consisting of a bitwise OR to determine which errors occurred.

Re: Constant Extensibility

2007-10-05 10:03 • by T_PAAMAYIM_NEKUDOTAYIM
ZOMGNINTENDOSIXTYFOOOOOOOOOOOOUUUURRRRRRR

Re: Constant Extensibility

2007-10-05 10:14 • by Anonymouse (unregistered)
All of that trouble and the original developer still spelled FORTY wrong. Why didn't Thomas P just do a find/replace in order to introduce the more sane constant names?

waffles suck

Re: Constant Extensibility

2007-10-05 10:16 • by O Thieu Choi (unregistered)
Insufficiently evil, if you ask me. A properly insane coder would have used Roman numerals:

private constant static int MMXLVIII = 2048;

Re: Constant Extensibility

2007-10-05 10:18 • by sibtrag
156063 in reply to 156055
Josh:
From way back in high school computer science, they would teach us never to use "magic" numbers. That is, every value should be represented by a constant or a variable.

Of course, the *idea* was that you were supposed to document the *purpose* of each value.

But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.


I would maintain that using a constant named SQRT_3_OVER_2 is indeed good practice rather than using 0.866024503 many places in the code. Using SQRT_3_OVER_2 does document the purpose of the number (albeit a low-level meaning) and has the side benefit of avoiding typographical errors such as inadvertently reversing digits.

Re: Constant Extensibility

2007-10-05 10:19 • by Médinoc (unregistered)
Reminds me of this:
http://mindprod.com/jgloss/unmainotherpeople.html (see bottom of page)

Re: Constant Extensibility

2007-10-05 10:20 • by el jaybird (unregistered)
156065 in reply to 156055
Josh:
But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.


Well, that might not be so terrible if the code was calculating a function that involved (root 3 over 2) a lot. I've forgotten all my university math (sigh) but I know that was a number that showed up a lot, along with pi and e.

Re: Constant Extensibility

2007-10-05 10:21 • by phil (unregistered)
156067 in reply to 156061
Err.. no they didn't. They just used the English spelling, as opposed to the American English spelling.

(I live in England. We speak English. There is no such thing as "British English" - that would be like "European French". It is the *other* variants which should be named differently.)

Re: Constant Extensibility

2007-10-05 10:23 • by sibtrag
156069 in reply to 156062
O Thieu Choi:
Insufficiently evil, if you ask me. A properly insane coder would have used Roman numerals:

private constant static int MMXLVIII = 2048;


But we aren't doing Roman numeral operations in this example, we're doing binary operations. I'd suggest:

private constant static int B1000000000 = 512;
private constant static int B10000000000 = 1024;
private constant static int B100000000000 = 2048;

Re: Constant Extensibility

2007-10-05 10:24 • by bambuti (unregistered)
156070 in reply to 156067
phil:
Err.. no they didn't. They just used the English spelling, as opposed to the American English spelling.


Maybe they used your spelling, but it's certainly not the "English" spelling, nor indeed that of any English-speaking country in Britain or elsewhere. It's just plain wrong. Forty is forty.

Re: Constant Extensibility

2007-10-05 10:28 • by Rune (unregistered)
156071 in reply to 156067
Not sure if you're referring to the fourty part. But even in English, it's still forty.

Forty-Four.

The 'u' gets dropped.

Re: Constant Extensibility

2007-10-05 10:29 • by Licky Lindsay
Once again I call shenanigans. If this isn't a joke, I demand the submitter to reveal more of the code in order to prove it's from a real program.

Re: Constant Extensibility

2007-10-05 10:37 • by FredSaw
156073 in reply to 156051
nEUrOO:
In old times :D we used to do that in order to save space...
6809 Assembler (Tandy Color Computer). Ah, those were fun times.

Re: Constant Extensibility

2007-10-05 10:38 • by Trevel (unregistered)
156074 in reply to 156072
I don't know -- this is exactly what I'd expect to see from someone who had been told to replace numbers with constants but was never told *why*.

And besides, if you use a descriptive ERROR_FILE_NOT_FOUND sort of constant, then you can't reuse it anywhere else -- it would be misleading! ONETHOUSANDTWENTYFOUR is very clear what it's for and where it should be used -- anywhere you want to type in 1024 but can't because some idiot says you can't put 'magic numbers' in the file.

Re: Constant Extensibility

2007-10-05 10:45 • by operagost
156075 in reply to 156067
phil:
Err.. no they didn't. They just used the English spelling, as opposed to the American English spelling.

(I live in England. We speak English. There is no such thing as "British English" - that would be like "European French". It is the *other* variants which should be named differently.)
And you're a stupid troll, who obviosuly does not in live the UK but seems to think they spell everything with an extra "U".

Re: Constant Extensibility

2007-10-05 10:52 • by dlikhten
At least error onethousandtwentyfour would never go unnoticed.

Re: Constant Extensibility

2007-10-05 10:52 • by gur (unregistered)
Ooof, Phil, you need to keep a low profile for a while after that howler...

Captcha: ewww - indeed!!!

Re: Constant Extensibility

2007-10-05 11:13 • by The MAZZTer
156080 in reply to 156055
Josh:
But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.


THEORETICALLY this is actually not a WTF, except that you can't tell if they mean sqrt(3 / 2) or sqrt(3) / 2 (I'll assume the latter).

Now if SQRT_3_OVER_2 is defined as 0.5773503 it's almost as valid as defining a PI. Almost. Because there IS a sqrt() function in any competent language and the computation only takes a few cycles, so why hard code it? The only reason you'd need to is if it was a bit more computationally hard, and ran several hundred times (or around there) a second in some time-critical code (ie a game rendering loop or something).

Re: Constant Extensibility

2007-10-05 11:16 • by Anonymously Yours (unregistered)
156082 in reply to 156072
Licky Lindsay:
Once again I call shenanigans. If this isn't a joke, I demand the submitter to reveal more of the code in order to prove it's from a real program.
I have to agree. Doing it the way this programmer did is clearly anti-lazy (not to be confused with "making an effort"), which goes against the very nature of programming. Who would choose to type that much extra?

Re: Constant Extensibility

2007-10-05 11:18 • by MikeCD (unregistered)
156083 in reply to 156065
el jaybird:
I've forgotten all my university math (sigh) but I know that was a number that showed up a lot, along with pi and e.

Yep, it's probably best known as sin(60˚)

Re: Constant Extensibility

2007-10-05 11:24 • by tsmith (unregistered)
Errors were encoded into a single integer rather than using a Boolean for each error that occurred. A nice way to overcomplicate things, but fine.


It's actually a common coding idiom in systems programming.

By using constants, you'd expect to see something like this:

private int error; // The current error code.
// Error masks
...
private static final int ERROR_INVALID_FILENAME = 1024;
private static final int ERROR_INVALID_USERNAME = 2048;
private static final int ERROR_INVALID_PASSWORD = 4096;
...



Actually, I'd expect to see something like this:

private int error; // The current error code.
// Error masks
...
private static final int ERROR_INVALID_FILENAME = (1 << 10);
private static final int ERROR_INVALID_USERNAME = (1 << 11);
private static final int ERROR_INVALID_PASSWORD = (1 << 12);
...

Re: Constant Extensibility

2007-10-05 11:27 • by Chris (unregistered)
At least they used constants for it, so any half decent Editor can rename it to a more useful name. If they used 1024 and you tried a Find & Replace, you'd run into problems when you get lines like:

if( iMenuState == 231024 ){

So bravo to the original programer! Well done on adapting your Hello World app into a real program! ;)

Re: Constant Extensibility

2007-10-05 11:47 • by SomeCoder (unregistered)
156091 in reply to 156080
The MAZZTer:
Josh:
But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.


THEORETICALLY this is actually not a WTF, except that you can't tell if they mean sqrt(3 / 2) or sqrt(3) / 2 (I'll assume the latter).

Now if SQRT_3_OVER_2 is defined as 0.5773503 it's almost as valid as defining a PI. Almost. Because there IS a sqrt() function in any competent language and the computation only takes a few cycles, so why hard code it? The only reason you'd need to is if it was a bit more computationally hard, and ran several hundred times (or around there) a second in some time-critical code (ie a game rendering loop or something).



Actually, power functions (and of course we all know that square root is a power function) are incredibly taxing for most systems to perform. Granted, we don't know what the original code was really supposed to do, but if speed was a factor, then you would want to avoid all built in power functions as much as possible (as you alluded to).

This code looks like Java though, so I'm going to assume that speed isn't that important (I'm not saying that Java is slow, just that the kind of optimization you would get from not using power functions would most likely be less important in Java than say C++).

Re: Constant Extensibility

2007-10-05 11:51 • by Tp (unregistered)
At least he didn't use acronyms!
OTTF + OTTF = TTFE

captcha: scooter! How much is the FISH!

Re: Constant Extensibility

2007-10-05 11:54 • by real_aardvark
156095 in reply to 156069
sibtrag:
O Thieu Choi:
Insufficiently evil, if you ask me. A properly insane coder would have used Roman numerals:

private constant static int MMXLVIII = 2048;


But we aren't doing Roman numeral operations in this example, we're doing binary operations. I'd suggest:

private constant static int B1000000000 = 512;
private constant static int B10000000000 = 1024;
private constant static int B100000000000 = 2048;

Whooooosh ....

I'd suggest:

B001000000000 = 512;
B010000000000 = 1024;
B100000000000 = 2048;

But that's just me being tidy. (Although it does sort of provide some measure of code-review friendliness.)

I think you miss the point about Roman numerals. (In fact, I know you miss the point.) We're not dealing with floating-point arithmetic here. (O lord, that would be insane ... particularly since the Roman numeric system has no concept of zero. Perhaps we could map:

I => 0
II => 1
...
XI => 10

etc. Well, it worked for C arrays the other way around, didn't it?)

In fact, replacing the supposed "magic numbers" with Roman numerals would be much, much more readable. Would you rather type FOURTHOUSANDANDNINETYSIX, or MMMMIVC? Easy to get your boss, the documenters, the testers, and the maintenance programmers on your side. And, even better, it enhances job security. Who the fuck knows what MMMMIVC represents?

The tiny problem with this is that there is no common accepted Roman numeral system that deals with integers > 5000.

Still, this is alright if you're working on a twelve-bit architecture.

With a two-bit programmer.

Off topic: Alex might want to examine http://www.wtfmagazine.co.uk/ for potential copyright violation.

Re: Constant Extensibility

2007-10-05 11:55 • by Bored Bystander (unregistered)
156096 in reply to 156091
SomeCoder:
The MAZZTer:
Josh:
But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.


THEORETICALLY this is actually not a WTF, except that you can't tell if they mean sqrt(3 / 2) or sqrt(3) / 2 (I'll assume the latter).

Now if SQRT_3_OVER_2 is defined as 0.5773503 it's almost as valid as defining a PI. Almost. Because there IS a sqrt() function in any competent language and the computation only takes a few cycles, so why hard code it? The only reason you'd need to is if it was a bit more computationally hard, and ran several hundred times (or around there) a second in some time-critical code (ie a game rendering loop or something).



Actually, power functions (and of course we all know that square root is a power function) are incredibly taxing for most systems to perform. Granted, we don't know what the original code was really supposed to do, but if speed was a factor, then you would want to avoid all built in power functions as much as possible (as you alluded to).

This code looks like Java though, so I'm going to assume that speed isn't that important (I'm not saying that Java is slow, just that the kind of optimization you would get from not using power functions would most likely be less important in Java than say C++).


I'd like to know why they didn't call it COS_30 or SIN_60 since that's probably where it came from.

Re: Constant Extensibility

2007-10-05 12:00 • by misha
156097 in reply to 156067
phil:
Err.. no they didn't. They just used the English spelling, as opposed to the American English spelling.

(I live in England. We speak English. There is no such thing as "British English" - that would be like "European French". It is the *other* variants which should be named differently.)


Ahh, now I see why the gov't introduced compulsory key skills classes...

Re: Constant Extensibility

2007-10-05 12:08 • by Cloak (unregistered)
156099 in reply to 156062
O Thieu Choi:
Insufficiently evil, if you ask me. A properly insane coder would have used Roman numerals:

private constant static int MMXLVIII = 2048;


Or even better use the Klingonian base 13 numbering system

Re: Constant Extensibility

2007-10-05 12:08 • by Cloak (unregistered)
156100 in reply to 156062
O Thieu Choi:
Insufficiently evil, if you ask me. A properly insane coder would have used Roman numerals:

private constant static int MMXLVIII = 2048;


Or even better use the Klingonian base 13 numbering system

Re: Constant Extensibility

2007-10-05 12:08 • by DaveK
156101 in reply to 156091
SomeCoder:
The MAZZTer:
Josh:
But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.


THEORETICALLY this is actually not a WTF, except that you can't tell if they mean sqrt(3 / 2) or sqrt(3) / 2 (I'll assume the latter).

Now if SQRT_3_OVER_2 is defined as 0.5773503 it's almost as valid as defining a PI. Almost. Because there IS a sqrt() function in any competent language and the computation only takes a few cycles, so why hard code it? The only reason you'd need to is if it was a bit more computationally hard, and ran several hundred times (or around there) a second in some time-critical code (ie a game rendering loop or something).



Actually, power functions (and of course we all know that square root is a power function) are incredibly taxing for most systems to perform. Granted, we don't know what the original code was really supposed to do, but if speed was a factor, then you would want to avoid all built in power functions as much as possible (as you alluded to).

This code looks like Java though, so I'm going to assume that speed isn't that important (I'm not saying that Java is slow, just that the kind of optimization you would get from not using power functions would most likely be less important in Java than say C++).


Ummm, unless you think the value of sqrt(3.0)/2.0 might change, you don't really need to recalculate it every time round the loop. Once at start-of-day would be enough.

And in fact pretty much every compiler for pretty much every language will calculate it once at compile-time and then replace it by a constant throughout your code for you. So it makes a whole bunch of sense for both accuracy *and* efficiency *and* good design and code clarity and maintainability to have a const variable somewhere in your code statically initialised with the actual formula rather than a hard-coded constant.

Re: Constant Extensibility

2007-10-05 12:10 • by db (unregistered)
156103 in reply to 156080
[quote="The MaZZTer"]Now if SQRT_3_OVER_2 is defined as 0.5773503 it's almost as valid as defining a PI. Almost. Because there IS a sqrt() function in any competent language and the computation only takes a few cycles, so why hard code it? The only reason you'd need to is if it was a bit more computationally hard, and ran several hundred times (or around there) a second in some time-critical code (ie a game rendering loop or something).[/quote]

Any competent optimizing compiler would evaluate sqrt(3)/2 or sqrt(3/2) into constants.

Re: Constant Extensibility

2007-10-05 12:10 • by DaveK
156104 in reply to 156100
Cloak:
O Thieu Choi:
Insufficiently evil, if you ask me. A properly insane coder would have used Roman numerals:

private constant static int MMXLVIII = 2048;


Or even better use the Klingonian base 13 numbering system


Such a great joke, it was worth telling twice!

Re: Constant Extensibility

2007-10-05 12:10 • by AssimilatedByBorg
156105 in reply to 156072
Licky Lindsay:
Once again I call shenanigans. If this isn't a joke, I demand the submitter to reveal more of the code in order to prove it's from a real program.

Oh, I find it entirely believable. I got a program where 0, 1, 2, and 3 were rolled into constants called ZERO, ONE, TWO, and THREE (plus or minus some system Hungarian for good^H^H^H^Hbad measure). And then, you should see the number of lines in this code such as:

counter = counter + ONE

Seriously. I really wish I was making this up.

Re: Constant Extensibility

2007-10-05 12:16 • by Cloak (unregistered)
156108 in reply to 156080
The MAZZTer:
Josh:
But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.


THEORETICALLY this is actually not a WTF, except that you can't tell if they mean sqrt(3 / 2) or sqrt(3) / 2 (I'll assume the latter).

Now if SQRT_3_OVER_2 is defined as 0.5773503 it's almost as valid as defining a PI. Almost. Because there IS a sqrt() function in any competent language and the computation only takes a few cycles, so why hard code it? The only reason you'd need to is if it was a bit more computationally hard, and ran several hundred times (or around there) a second in some time-critical code (ie a game rendering loop or something).


SQRT_3_OVER_2: sqrt(3)/2 = 0,86602540378443864676372317075294

SQRT_3_OVER_2: sqrt(3/2) = 0,61237243569579452454932101867647

Re: Constant Extensibility

2007-10-05 12:22 • by bighusker
156112 in reply to 156080
The MAZZTer:

Now if SQRT_3_OVER_2 is defined as 0.5773503 it's almost as valid as defining a PI. Almost. Because there IS a sqrt() function in any competent language and the computation only takes a few cycles, so why hard code it? The only reason you'd need to is if it was a bit more computationally hard, and ran several hundred times (or around there) a second in some time-critical code (ie a game rendering loop or something).


If it's used enough that it could be stored as a constant, why on earth would anyone calculate the same value on every iteration of a loop? Calculate it once and assign the value to a variable that can be re-used. The meaningless few clock cycles you lose by calculating it once are worth making your code readable.

Re: Constant Extensibility

2007-10-05 12:22 • by Reversed Engineer (unregistered)

I would expect this kind of thing from an application that had been de-compiled and had gone through one or more steps of refactoring to a more usable form.

For example, the code might decompile like this:

if(i2 == 1024)
{
s5 = s4;
s4++;
}

Then in the first step, you might do something like this:

public static final int ONETHOUSANDTWENTYFOUR = 1024;

if(i2 == ONETHOUSANDTWENTYFOUR)
{
s5 = s4;
s4++;
}

It's a very small baby step toward refactoring it. You know what was there before (1024) and it's fairly easy to rename the constant later, like so:

if(errorCode == FILE_NOT_FOUND)
{
s5 = s4;
s4++;
}

I wouldn't call it a WTF.

CAPTCHA: ninjas (<hand signs> reverse engineer jutsu!)

Re: Constant Extensibility

2007-10-05 12:22 • by real_aardvark
156114 in reply to 156108
Cloak:
The MAZZTer:
Josh:
But I can't help but vividly recall a homework assignment that involved some kind of calculations, and just about everyone's program had a constant named some variant of SQRT_3_OVER_2.


THEORETICALLY this is actually not a WTF, except that you can't tell if they mean sqrt(3 / 2) or sqrt(3) / 2 (I'll assume the latter).

Now if SQRT_3_OVER_2 is defined as 0.5773503 it's almost as valid as defining a PI. Almost. Because there IS a sqrt() function in any competent language and the computation only takes a few cycles, so why hard code it? The only reason you'd need to is if it was a bit more computationally hard, and ran several hundred times (or around there) a second in some time-critical code (ie a game rendering loop or something).


SQRT_3_OVER_2: sqrt(3)/2 = 0,86602540378443864676372317075294

SQRT_3_OVER_2: sqrt(3/2) = 0,61237243569579452454932101867647

Ooh, impressive. You're obviously not using one of the OMGWTF contest calculators, are you?

Re: Constant Extensibility

2007-10-05 12:27 • by mudkip (unregistered)
156117 in reply to 156067
phil:
Err.. no they didn't. They just used the English spelling, as opposed to the American English spelling.

(I live in England. We speak English. There is no such thing as "British English" - that would be like "European French". It is the *other* variants which should be named differently.)


Why bother treating your English differently? No English is better than any other.

Re: Constant Extensibility

2007-10-05 12:30 • by ebs2002
156120 in reply to 156091
SomeCoder:

Actually, power functions (and of course we all know that square root is a power function) are incredibly taxing for most systems to perform. Granted, we don't know what the original code was really supposed to do, but if speed was a factor, then you would want to avoid all built in power functions as much as possible (as you alluded to).

This code looks like Java though, so I'm going to assume that speed isn't that important (I'm not saying that Java is slow, just that the kind of optimization you would get from not using power functions would most likely be less important in Java than say C++).


I was always of the impression that any decent math library calculates the square-root of an integer uses a table lookup method, not any sort of taxing algorithm (okay, it is certainly more taxing than bitwise operations, but it's about the same as division in terms of complexity).

Re: Constant Extensibility

2007-10-05 12:31 • by TallGuy (unregistered)
156122 in reply to 156105
Heh, I'm working with a Fortran application that does the same. However, there is a good reason because Fortran preserves type across math operations, so 1/2 and 1.0/2.0 are different (though 1/2 = 1/2.0). Even knowing why, I hate seeing things like v = (val + ONE) * TWOTHIRDS, though.

Re: Constant Extensibility

2007-10-05 12:33 • by TallGuy (unregistered)
156123 in reply to 156122
TallGuy:
Heh, I'm working with a Fortran application that does the same. However, there is a good reason because Fortran preserves type across math operations, so 1/2 and 1.0/2.0 are different (though 1/2 = 1/2.0). Even knowing why, I hate seeing things like v = (val + ONE) * TWOTHIRDS, though.


re:
AssimilatedByBorg:

Oh, I find it entirely believable. I got a program where 0, 1, 2, and 3 were rolled into constants called ZERO, ONE, TWO, and THREE (plus or minus some system Hungarian for good^H^H^H^Hbad measure). And then, you should see the number of lines in this code such as:

counter = counter + ONE

Seriously. I really wish I was making this up.

Re: Constant Extensibility

2007-10-05 12:40 • by M Cassidy (unregistered)
The code was probably the result of reverse engineering, ie using Reflector or similar. And what else, would the reflection tool name the enumerations?

Re: Constant Extensibility

2007-10-05 12:49 • by Velko (unregistered)
156129 in reply to 156105
AssimilatedByBorg:

Oh, I find it entirely believable. I got a program where 0, 1, 2, and 3 were rolled into constants called ZERO, ONE, TWO, and THREE...

Well, I have seen similar thing in database. There's table:

create table ZERO_ONE(number INTEGER);
insert into ZERO_ONE(number) values (0);
insert into ZERO_ONE(number) values (1);

Table contents were loaded into dropdown box to provide choice for obvious yes/no question.

I replaced it with checkbox, of course.

Re: Constant Extensibility

2007-10-05 12:50 • by Martini (unregistered)
Oh dear.

I hate to burst all your bubbles, but in C, C++, C# (and probably Java too) sqrt(3/2) is 1. sqrt((double)3/2) or sqrt(3/(double)2) or the float or decimal equivalents.. now that's another story.
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment