Naked Science Forum
Non Life Sciences => Geek Speak => Topic started by: Boogie on 21/08/2012 23:47:04
-
It appears that Borland C++ compiler (version 6) has a bug with the log() function.
For example, a compiled application using log(15) returns 2.708. My calculator and OpenOffice agree that log(15) = 1.706
Anyone else encounter this? I fought this problem almost all day thinking I was doing something wrong!!!
-
Logs can have different bases ...
The logarithm to base b = 10 is called the common logarithm and has many applications in science and engineering. The natural logarithm has the constant e (≈ 2.718) as its base; its use is widespread in pure mathematics, especially calculus. The binary logarithm uses base b = 2 and is prominent in computer science.
https://en.wikipedia.org/wiki/Logarithm
For example, a compiled application using log(15) returns 2.708.
That looks like log to base e
[ Invalid Attachment ]
-
Also see the change of base formula in the Wikipedia article above.
https://en.wikipedia.org/wiki/Logarithm#Change_of_base
It looks complicated, but it turns out to be relatively simple calculation because "b" is a constant, so you just calculate the constant divisor. If Borland c++ doesn't already have the function, you could write a quick function to change the base to the desired base (10?)
-
Thanks Clifford, I agree. I think Borland got them backwards. The base 10 command : log10(x) produces 1.176.
This drove me nuts. The log function was only a small part of the algorithm I was working on and it took me forever to finally suspect it. I did not expect this sort of library bug with a version six release.
I just noticed that I really "fat fingered" the return value in my initial post. :-[
-
I don't think it is a Borland thing, but rather a C++ thing... and perhaps Standard C.
http://www.cplusplus.com/reference/clibrary/cmath/log/
Probably somebody 30 years ago decided to use Log(x) as the natural log, rather than using ln(x).
Then, to make each version of the program more or less backward compatible, the old syntax was pushed forward.
In Unix, ln means to "link" files.
-
Yeah, I think you're right. Unless I'm just getting confused, Dynamic C appears to be doing the same thing.
One solution :
#define LOG log10 //lib is wrong
#define LOG10 log //lib is wrong
Now when I use LOG(x) it replaces it with log10(x). LOG10(x) is replaced by log(x)
I was a little suprised that this worked. It's a little anal, but it might save me some head scratching if I need to go back and trouble shoot the algorithm sometime in the future.
-
Yeah, I think you're right. Unless I'm just getting confused, Dynamic C appears to be doing the same thing.
One solution :
#define LOG log10 //lib is wrong
#define LOG10 log //lib is wrong
Now when I use LOG(x) it replaces it with log10(x). LOG10(x) is replaced by log(x)
I was a little suprised that this worked. It's a little anal, but it might save me some head scratching if I need to go back and trouble shoot the algorithm sometime in the future.
I would be careful with such a definition.
If someone else is likely to work on your program in the future, it is a sure method to spell disaster.
It would be extremely confusing to define the natural log, Loge(x) to be written as Log10(x).
If ln(x) is not used elsewhere, you might choose to define it as your natural log function.
Then you would merely define log(x) and log10(x) as meaning the same thing. Or... you could define log10(x) to throw an error so you could remember what you had done.
-
If ln(x) is not used elsewhere, you might choose to define it as your natural log function.
Yes! That is a much better solution. Good point, thanks!
I knew confusion would get to me sooner or later.
-
Ahhh
Are you using caps in your #define functions?
It may be a good mnemonic, but could also lead to a mess with using both upper and lower case log functions.
I think I'd just do a find & replace, and be done with it. Perhaps remember to double check your work for a bit until you get used to the way natural logs are used in C++.
I must admit, however, that I was one of those people that would often define "dir" and "ls" to mean the same thing.