Slashdot Mirror
Mandrake 8.0 Beta Released
Boiling rumors can now be set aside: Linux-Mandrake's 8.0 beta is ready for grabbing. Before you complain about Version
Inflation (Slackware, Red Hat and others should come out with v10 just for fun), read the fine print indicating that by using this beta version, you're surrendering your machine to the winds of time, and French aliens may come kidnap you and your data for sheer sadistic sport. That is, especially if you have a VIA Apollo Pro or KT133 Chipsets and a WD drive greater than 8.4Gb in size. So the real 8.0 isn't ready yet (that will be the time to complain about version inflation proper), but like Red Hat's Fisher, this is a nice way to experience upgrades all around the mulberry bush, including a 2.4 kernel (2.4.2, actually) without building them all yourself.
Ok, this is a rant and it is a bit personal, but I'm getting sick of all the i586 and i686 packages(especially those) floating around. Now I can forgive Mandrake since that's part of its bag. But why other binary distributions (like mozilla)?
I own lots of Pentia class machines, but I also have some really cool 486 machines that I'd like to use. Yes, I could get the source and recompile everything, but this is my rant and I'm going to enjoy it for a minute.
Thank you.
So goto Redhat's web site and update the damn kernel and, while you're there - grab all the updatess. It's pretty simple to run:
rpm -Uvh *
and thats it! I'm running here Redhat 7 with those updates and it didn't have even a single problem since the update of the GCC
Hetz (Heunique)
Actually, I get 10=9 not 9=10. And, by my quick analysis that is in fact the correct answer. Here's why: when the the constant expression is evaluated by the compiler, it can do a couple of tricks to come up with the "correct" answer of 10 (eq. rounding and infinte precision math (like "bc") come to mind). But the variable expression must be evaluated with floating point math, and that's where your difficulty is. 0.3 and 0.7 cannot be accurately represented in the IEEE floating point format. so the equation actually results in 2.99999999... + 6.999999999.... = 9.99999999... . In order to get an answer of 10, the other platforms you tried either (a) use a non-IEEE-standard floating point format. or (b) rounded instead of truncated when casting to an int (which I believe is nat ANSI standard C compliant behaviour).
- A.P.
--
* CmdrTaco is an idiot.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I've got a WDC WD153BA (15 gig 7200 RPM ATA-100 drive) and now I'm more than a little scared that my HTTP/NFS/NIS/DNS/SMTP server is going to shit the bed without warning. Is there a list of "known bad" models?
- A.P.
--
* CmdrTaco is an idiot.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Install LM 8.0 on some old 486 machine, let it start KDE (or gnome, doesn't matter), open star office, maybe netscape too... Then go to cinema and by the time you come back some of the progs may already be ready and waiting for you...
OK, you could go for some lighter GUI, and avoid real slowware, but the sad fact is: old machines are too slow for modern GUI software. So what's the point on installing the newest disto on it?
This said, there are some places where such machines would do a perfect job:Civileme has been investigating this for quite some time, and he wrote about it on Mandrakeforum. It looks as if WD has severe QA problems, and this time it got a help from chipset and a bug (or at least lack of workaround) in kernel.
Here are the stories:- Numerical Analysis & the Walrus
- What Now? WINDisks, of course
- Is this Computer Science or Voodoo?
Civileme even claims that WD drives just fake CRC, but it's difficult to say if there is some truth in this or not. One is sure: these beasts cause a lot of trouble.Having a WD drive bit me pretty bad about a year ago. A week or so after a kernel recompile, I wound up with filesystem corruption, even though I was running a stable kernel. I take my computer very seriously, and though I was able to recover my important data, losing the filesystem hurt *bad*.
My faith in Linux took a big hit after that. The only explanations for that error were 1) hardware failure (seemed unlikely) or 2) serious kernel bug. I contemplated migrating to FreeBSD, but was informed that much of the IDE code between Linux and BSD is shared, so any fundamental bug would probably follow me to the new platform. So, I just rebuilt my system and carried on.
A few months later I was reading Kernel Traffic, and someone posted a filesystem corruption problem with the exact same symptoms, using the exact same WD hard drive. One of the hackers identified the source of the problem -- it was Western Digital.
Some models of WD drives are advertised as "UDMA compatible". That is, you can enable UDMA and they will run. However, WD is sidestepping the fact that the drives are *not* UDMA "compliant". Apparently a part of the UDMA spec is the transmission of periodic CRC checks to detect and correct errors. Some WD drives will operate in this mode, but blow off the CRC checks. This is suicidal. If the drive is used in UDMA mode (which it claims compatibility with) you *will* get data corruption...it's just a matter of when and how bad.
Thinking back before the failure, sure enough, I had enabled UDMA in the kernel, looking for a speedup from my UDMA "compatible" drive. WD had mislead me in the features of that drive, and it resulted in data loss. I view this as highly irresponsible on their part, and I will certainly not buy from them again.
--Lenny
Very funny! I switched from AmigaOS to Debian, and now use FreeBSD for my LAN servers and test machines (I'm building a "jail" host server even as we speak).
Good ol' Bob seems to have nailed this one on the head! :)
Dewey, what part of this looks like authorities should be involved?
Applicability: Linux-Mandrake 8.0 BETA 1 WARNING This BETA has the potential to mis- recognize the drive geometry on systems with VIAApollo Pro or KT133 Chipsets and WD drives greaterthan 8.4Gb in size. This leads to massive andunrecoverable data corruption. Do NOT install or attempt to test with these systems. It relates to recently discovered kernel bug which may be fixed in kernel 2.4.2. We expect to have the fix in place for BETA 2 (Traktopel). Thank you for your patience.
Professional Wild-Eyed Visionary
Well...I'd say it's just a case of users having an overwhelming sense of pride in their distribution =)
;P )
I admit, I'm a debian convert (used Redhat for 3 years, then tried debian once - can't ever go back) but I try to be an understanding one - No distribution is "right" for everyone...debian just happenes to be "right" for me (and for quite a few other, more opinionated folks as well, it seems
I'm also not a descendant of an amiga user (never owned one - never owned anything made by commodore, although I'm in the process of acquiring an old c64 to play with).
Don't make general statements like that - it just makes us all look bad.
Other than that, nice troll =)
This has nothing to do with ANSI C. This is how floating point numbers work. It depends on the FPU (i.e. the *hardware*) you are running on. Floating point numbers are not exact and you must never assume that 10.0 == 10.0 no matter what language you are using. For some simple cases it just may happen to work, but in general this assumption is a grave programming error.
___
___
If you think big enough, you'll never have to do it.
I saw the 8.0 Beta out of the corner of a blurred eye and coulda sworn I saw "B 0 B", instead of "8.0 Beta"
It's related to how the x86 FPU works and how GCC uses it. You'd get the same answer on any x86 operating system using GCC, including FreeBSD and Windows 2000.
I've been toying with the idea of installing a Linux Distro. I have about 20Gb of unused drive sitting here.
But it's my bread-and-butter drive: my whole business life is on it.
I have an Asus K7V, and a big IBM drive. Apparently in that combo, Linux will eat my files. If that carried over to the Windows partitions, I'd be toast...
Think I'll keep away from Linux for a while longer. I can't afford data loss like that.
--
--
Don't like it? Respond with words, not karma.
For the record, I get the same bug with the Cygwin-experimental version of GCC 2.95.2-6
ObJectBridge (GPL'd Java ODMG) needs volunteers.
Finding God in a Dog
So you're using RedHat 4.2, 5.2, or 6.2 then? Those are the supported versions that use a "standard" compiler.
-
RedHat may still say Fisher on their web pages, but Wolverine (Beta 7.0.91) is already out, and has been for a week.
-
*shrug* Floating point is tricky. I would class your post as a clever troll. I think gcc, by default, is not strictly IEEE compliant.
Need a Python, C++, Unix, Linux develop
This is a silly reason. It's a slight different in how floating point calculations are done on the two platforms. Floating point calculations not involving powers of two are going to have some error in them. For some reason, with gcc under Linux on the x86, the error results in the second calculation giving a result very slightly less than 10. The (int) typecast does not round.
This more proves the lesson that you shouldn't expect exact results out of floating point calculations that it proves whether or not any particular OS is better than another.
Need a Python, C++, Unix, Linux develop
I'm running Mandrake 7.2 on the firewall that I'm sending this message through. I've been a mandrake user since version 6.0.
Unless I'm tweaking or doing something weird all of my mandrake boxes are rock solid stable.
DrakConf is a big reason why I've stuck with mandrake. I don't ave to visit web pages to know which kernel module to use when I add a new piece of hardware, I find out from DrakConf and poof I put it in.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
If you've got a minute, and one of those 'bleeding edge' OSes, try compiling with no optimizations and running this for fun:
int main(void)
{
int a = 60, b = 6, c = 10;
printf("%d = %d\n", (int) (((60/6)*0.3) + (10*0.7)), (int) ((( a/b)*0.3) + ( c*0.7)));
exit(1);
}
(BTW the lameness filter defies logic, that was the best I could do with the C snippet)
A friend was tortured for a few hours doing an assignment until I took a look at the code and realized the problem boiled down to something that can be reduced to this snippet.
I compiled this with default compiler settings on every platform I could find. This means Digital Unix 4.0, OpenVMS 7.2, Solaris 8, IRIX 6.4, HP-UX 10.20, FreeBSD 4-STABLE, OpenBSD 2.8 and various Linux distros, from ancient to cutting edge - both with gcc and any commercial compilers that happened to be available at each box.
On all Linux distros, and only on Linux distros, ranging from an ancient Slackware setup to the latest Red Hat, I get 9=10. On everything else, I get 10=10. Go figure, and remember that the whole OS is compiled with that.
I think I'll just stick to FreeBSD as far as my intel boxes are concerned.
LNUX has dropped over 40% since the market closed last Tuesday, though, while NASDAQ's only lost about 5%. Same pretty much holds true (as far as LNUX bleeding way more than the market as a whole) whether you look at the last 5 days, 10 days, whatever. Stick a fork in this company, it's done. On the bright side, ESR's original $41,000,000 worth of LNUX stock is now down to about $550,000, and his gloating sounds more comical everyday.
Cheers,
These version numbering schemes are becoming ridiculous. Actually overheard in a store (Frys's Sunnyvale): "No, get that one over there, it's Linux 7.2. This one is 7.0" (referring to two distinct distros). I would hate to know what they thought of FreeBSD 4.2 or Caldera 2.3 :-)
A Government Is a Body of People, Usually Notably Ungoverned
> hehehe that's pretty funny, but my zip drive works fine with 2.4.2
And mine with 2.4.0
--
Sheesh, evil *and* a jerk. -- Jade
You are very, very confused as to how numbers are stored in a binary system. .9999 will not be stored with 4 digits (.9999). It will be stored as a binary mantissa and a binary exponent, not as 4 characters. The problem lies in that the mantissa can only carry so much precision. Think of it this way:
.5
.25
.75
.125
For number greater than 1:
0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
etc.
For numbers less than 1:
1000 =
0100 =
1100 =
0010 =
etc.
I'm working off of very vague memories here (10 years since I had this in class), but I believe the IA32 architecture has 80 bit floats, with some portion allocated for the mantissa and the rest for the exponent.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
There was some discussion of the review on mandrake's forum. What was noted there is that Helix explicitly says that their packages don't yet work with mandrake 7.2. The reviewer essentially tried to install an incompatible package, and then complained when it didn't work. That's far from what I'd call "intelligent reviewing."
-schussat
The hour of noon has passed. Let us go and get some Kentucky Fried Chicken.
Does anyone know if this bug affects WD SCSI drives, or just ATA ones?
I'm running 7.1 at home, and it seems a bit flakey - not sure why. Maybe because I'm using reiserfs?
It was OK for a while, but the slocate and logrotate cron jobs now just chunder on forever (I've now disabled them), and sometimes the system just goes into a CPU killing disk-swap downward spiral (I've got 64MB RAM, but two swap regions totalling a lot more - maybe 128MB or 256MB).
Any ideas? Anyone else have problems with 7.1 that went away with 7.2?
I think I'm gonna give 8.0 a try anyway - got a partition reserved waiting for it!
Thanks, Ted. That 100% CPU usage sounds pretty familiar!
/var/log directories when I get home?
I'll check my
BTW, off the top of your head, do you know how to configure logrotate - is there a simple way to avoid this problem (other than disabling logrotate, which is what I did)?
Same thing here - the reason I'm going to install 8.0 is because I want the 2.4.x kernel and KDE 2.1... SuSE seem pretty aggressive with keeping up too - I might give them a shot one of these days.
If I wanted a older stable version of Linux I'd go for Debian.
See, that's my problem - the install goes well (it seems), then I reboot... kernel decompresses and loads, then when init is starting, I see an error telling me that libreadline can't be found, and things grind to a screeching halt, ending with a very fun "no processes left in this runlevel message". I was planning on getting the new stuff off of Cooker as soon as I was up, but I never got so far as a login... and the installer only gives four choices for network cards, so I need to wait until my system is up to configure that (or I could go get a Tulip/3c595/PCINe2000/whatever the fourth choice is that I don't have). No big deal, but kind of a pain. Also, when the install asks for the 2nd (ext) CD, it doesn't unlock the drive... so you can't put any of those RPMS on at install time. Unless there is some (undocumented) reason why I can't load the kernel with Milo...
I haven't had much time to scour lots of places for help, but if the install is broken before I get up and running... my MD5 sum matched for the iso, too, so I haven't tried pulling that down again and reburning - it'll take a while.
--
"It's tough to be bilingual when you get hit in the head."
Ah yes, Wintel beat Apple... but for the people who had Beta and Apple in 1985... well, you can still buy Apples (and really, the PowerPC chip is a better processor architecture than the x86... the Altivec stuff is nice, but that does limit the peak speeds of the chip).
I knew what you were getting at, but unlike Beta (which was quite a bit better, but good old corporate politics and licensing killed it), Alpha and x86 don't completely overlap in the same app space. Something about 64bit data, 64b PCI, and a much better FPU than the x86 line (and stable as hell, too). DEC dropped the ball, and Compaq hasn't pushed things as much as we'd like, but really, an 833MHZ 21264 rates 590 base/650 peak in specfp2000, while a 1.5GHz P4 rates 543/552, a 1GHZ P-III a 292/304, and a 1.2GHz Athlon 304/342. Stable, tested, available hardware (the high speed alphas have been around a lot longer than the P4 and higher speed P3s have been almost working). There are some very good uses for what I term real hardware, and there are still plenty of installations out there. Free software is one of the great ideas. GCC isn't so hot for fp performance on Alphas (something I'd like to help along), but the DEC/Compaq compiler is cheap, and running Tru64 is slick. The idea is to help Linux do what it needs to. I've got a nearly four year old low-end Alpha here (my 21164PC test box) that can still rock with the best of them
Also, by my count there are far less S/390 mainframes, AS/400s, RS/6000s, O2s, and E10ks than Wintel boxes, so I guess everyone should just give up on those too... damn Superior Technology X, Y, and Z.
--
"It's tough to be bilingual when you get hit in the head."
I wish somebody had a current distro for Alpha. The latest I can find is RH7.0 (brokenish) or Mandrake 7.1 (won't reboot after install - can't find libreadline5). Kind of a pain for those of us running Alphas... I'd love to see a distro release with 2.4.x sometime in the near future.
--
"It's tough to be bilingual when you get hit in the head."
suse may end up the #1 distribution because... well, europe LOVES it... germans especially...
and, i think that suse may actually be /profitable/, even... something that is unheard of for US distribution companies...
yeh yeh... their american division got fscked... but there is more to the world than the good ole US of A...
tagline
... hi bingo
[..] On all Linux distros [..] I get 9=10.
Repeat after me: Floating point calculations are imprecise. It seems like you've got it the wrong way around, by the way: the calculation that is done at compile time is "exact".
You can simplify the above further to
... (int) (3 + c * 0.7)
int c = 10;
which gives you 9 -- because 0.7 happens to be rounded down in binary! (60/6) is an integer calculation, so that gives you exactly 10 -- but with floating point calculations you get rounding errors.
That the first expression, which is calculated by the compiler does result in 10, is because that is done by the optimised compiler, which calculates the whole expression in the FPU without storing intermediate results. And the i386 FPU uses 80-bit numbers internally, so that it does work out OK in this case. Or perhaps you're just plain lucky.
If you want the answer to be 10, just change int c = 10; to double c=10.0000000000001;.
When it comes to numerical mathematics, lesson one is: You cannot trust the rounding of floating point calculations.
Jeroen Nijhof
What, you think I run this box for fun? =) This is the database server for the Town Hall of a smallish (14k people) town in Massachusetts. GCC is on there because one of our vendor's programs has a component that's compiled on-site.
We've got a file server running linux now, desktops run Win9x. At home I dual boot W98 and SuSE 6.4.
--
--
"I personal[ly] think Unix is "superior" because on LSD it tastes like Blue." -- jbarnett
# uname -a
SCO_SV hol504 3.2 5.0.5 i386
#
Reading specs from
gcc version 2.95.2 19991024 (release)
#
#
10 = 9
--
--
"I personal[ly] think Unix is "superior" because on LSD it tastes like Blue." -- jbarnett
Ech. Backup devices are for sissies ;) These days, it's just so much cheaper (and faster, etc) to get a second harddrive and backup to that. Or (my favorite) build a cheap local FTP server and backup to that. It beats tape...
A deep unwavering belief is a sure sign you're missing something...
A) There is nothing inherently wrong with "Windows characteristics." There are bad characteristics and Windows characteristics. An item in one set is not necessarily in the other.
.0 releases, everything has beta builds. Its an essential part of a software release. The problem isn't releasing Betas, but releasing Betas and pretending they are final products.
B) What's wrong with beta builds? Linux has had beta builds ever since I can remember (except they call it a -test) RedHat beta builds have been called
C) Try Gentoo Linux It's nice and light, has a lot of the cool package management features of Debian, and is well-thought-out. It also has something like a ports tree. It might be a little cutting edge for many people's tastes (a comment once accompanied a package "package x.y.z merged. Did we beat freshmeat?" It's still a development product, but its manual installation isn't really any harder than installing some other Linux distros, and gives you a lot more control. When this thing reaches 1.0, RedHat watch out!
A deep unwavering belief is a sure sign you're missing something...
Why would you want to do that? ReiserFS is faster, more stable, and HERE NOW!
A deep unwavering belief is a sure sign you're missing something...
Actually, the PCI spec is a very expensive "open" bus. If you have ever tried to write an PCI code, you'll find that they charge several hundred dollars for the specs.
A deep unwavering belief is a sure sign you're missing something...
X.10 and X.11. Can you say trademark violations?
A deep unwavering belief is a sure sign you're missing something...
I doubt you can upgrade without reformating. Still, it would be no trouble at all to copy data over to a spare partition, format with ReiserFS (or if you have the balls, XFS!) and copy stuff back over. ext3 essentially exists to save the user the trouble of two copies. Kinda silly.
A deep unwavering belief is a sure sign you're missing something...
I believe he meant from ext2.
A deep unwavering belief is a sure sign you're missing something...
...and BTW, I tried on solarix x86 with gcc 2.95.2 and also got 10 = 9, so this is not even an OS issue. It's all about a bad programming practice that produces bad results with a certain compiler/CPU combination (using the same gcc version on solaris/SPARC gives 10=10). That's all there is to it.
If a certain program doesn't produce the same result with different compilers/platforms, the most like cause is not a bug in the compiler, but an undefined behaviour caused by a badly written program.
Opus: the Swiss army knife of audio codec
However, consider explaining that 10 equals 9 for small values of 10 only on Linux distros out of dozens of other platforms to someone that was being tortured while doing a C assignment.
In case you didn't read my other comment, this have nothing to do with Linux, since I could reproduce the same thing on Solaris x86 and I'm pretty sure I'd also get that with gcc/Win32. The way your code is, luck is the most important factor is determining whether it'll work or not! Regardless of the platform (I bet you could find another similar example that would produce 10=10 on your linux setup and 10=9 on other setups).
Opus: the Swiss army knife of audio codec
There's nothing strange in your example. It looks strange because in the decimal system, .7 is easy to represent. What if I asked you to compute (3 * .3333333333), you'd say .9999999999 and if I asked you (int)(.9999999999), the answer would be 0. However, when I said .3333333333, I meant 1/3, but there's no way you could have known. In (binary) float representation, .7 is a periodic number, just like 1/3 in the decimal representation. That's why you need to expect wierd (random) outputs when you compute stupid things like (int)(10 * .7).
Opus: the Swiss army knife of audio codec
I think you did not understand anything at all from my several posts! THIS IS NOT A BUG, it's a feature! You cannot make the assumption that such float calculation will be exact to the last digit, period. If you round to the nearest integer, you'll get the right result, all the time. But when you make such stupid assumptions, you're just asking for trouble.
.6*10 = 6.
If you want to convince me that's a bug, go look up in the C language definition and find the place where they guaranty you that these kinds of calculations has to give what you're expecting. There's simply no guaranty of that, that's all. AFAIK, the only float calculations that are required to be exact (IEEE spec or something like that) are those that involve integer numbers, like 2.0 + 3.0 = 5.0... and certainly not
I hope you get it now.
Opus: the Swiss army knife of audio codec
OK, I'm not talking about "standard" code with no library calls. If you get different results for a float calculation on two different platforms, it's most likely because:
- You've got an uninitialized variable that "happened" to have a value of 0 with some compiler/platform
- A comparison between two floats (a == b), which you should never do.
- An array bounds error, which can sometimes (if you're lucky) not overwrite any useful data (but does with another compiler/platform)
- Your trying to use things (int)10*.7 in some computation...
...you get the point.
Opus: the Swiss army knife of audio codec
I know all that... I said that to simplify things I was going to work in decimal, although (duh!) de CPU works in binary.
Opus: the Swiss army knife of audio codec
The value of: (int) (((60/6)*0.3) + (10*0.7)) can be either 9 or 10, depending on when the float values are moved in/out the floating point registers (which are 80 bits instead of 64 bits for a double). Your compiler cannot guaranty the result and you should no assume that the result is 10, unless you round to the nearest integer (instead of casting to an int, which is equivalent to a floor).
Therefor, it's not the compilers fault it this problem happens, it's your fault if you make those kind of assumptions (It's the same reason why you should almost never use == when comparing 2 floating point numbers).
Opus: the Swiss army knife of audio codec
OK, let's go... (with my previous 3 * .333333 example)
.333333 (6 digits in the register) in register and multiply by the 3 that's in memory. The result is .999999. When you store that in memory, it is rounded to 4 digits, giving 1.000, which when converted to int, gives 1.
.3333 (4 digits in memory), you get .999900 in the register. When you store that in memory, you get .9999, which once conterted to int gives you 0.
We'll work in decimal, so transpose this to binary for a real CPU. Let's say your "float" (as stored in memory) has 4 digits and your float registers can hold 6 digits (a double is 64 bits, a register is 80 bits).
If you load
Now, if you have 3 in the register and multiply by
The only thing that changed is what goes to register and what goes to memory. I'm not saying this is exactly what happens in your example, but it's probably something similar.
BTW, if you look at the gcc man page, there's an option called -ffloat-store which deals with registers that are larger than the memory representation of the float number.
Opus: the Swiss army knife of audio codec
In Red Hat Linux, all versions in a series (like 6.0, 6.1, 6.2) are binary compatible.
When we break backwards binary compatibility (like when we introduce new major versions of libc), we increase the major number.
We won't switch while in a major series, but after that we'll just ship compatibility libs and the new compiler.
its the principal behind it. there was no reason for RH to make a stupid move like that at all.
Of course there are reasons:
On the minus side: C++ isn't binary compatible with other versions of gcc. As we went with glibc 2.2, this wouldn't have been compatible with anything anyway (a combination of gcc and glibc is binary incompatible with any other combination). There has never been C++ binary compatiblity on Linux, and there won't be until gcc 3.0 is released and used.
As you can see above, there is no doubt that on technical merits, this was the choice to do. And we did it. Unfortunately, we could have handled the political situation better. As for the end-user experience, that's irrelevant.
When gcc 3.0 comes out, we intend to switch to that at one point - "when" is dependent on when gcc 3.0 is actually released and how it fits into our cycles, as it will be a binary incompatible change.
PS: Mandrake uses it too.
a)British
and
b)Too old
Rich
Funny this happens. I run Oracle Applications under several linux boxes. Wouldn't it suck for any business of any size to be running production erp applications to have some critical numbers off becuase of a flawed arithmatic algorythm in the standard libc libraries?
Firstly, as so many posts have pointed out, floating point is inexact and you can easily fall foul of rounding errors when casting to integer.
More importantly, this is why databases go to the trouble of providing DECIMAL type as part of the SQL standard. Floating point variables have 'interesting' rounding errors, and most businesses, especially those doing any sort of accounting, can't afford to lose any precision. All DECIMAL type calculation are therefore done to the limit of the precision of the type and have well-understood rounding limitations which should not manifest themselves like this.
Quite honestly, if you are using floating point numbers for any sort of simulation, doing the error analysis is a complete pain in the neck. In many respects you are better off using integer values, maybe with scaling offsets, because at least then you can control and understand all the cases where you drop precision.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Version inflation?
Emacs 20.7. Say no more.
Good thing that Emacs 21 is due out soon then ;-)
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
What I'm tryin to say is, you can bitch all you want about lack of support for Superior Technology X, but once it's on that downward slide, you're just going to frustrate yourself.
Ok my karma is maxed out. When do I become Enlightened?
Crap is still crap despite sales figures. x86 is a god-awful architecture, not even as good as the 68000 arch on my Amiga was in 1994, let alone the likes of Alpha, PPC or Sparc. Next you'll be saying Britney Spears has more talent than Mantovani since she sells more albums.
Huh? Check this Linux Counter Estimate first next time.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
Oh good god. Quit whining and shut up!
The only possible problem this causes is when proprietary bastards keep their source code locked in a vault and only ship binaries. Decent Free software will simply require recompiling using a different compiler. I don't know about you, but the fact that the packages on any given distribution are out of date before the ISO is built keeps me from caring, since I end up recompiling all my major packages from source anyway.
And if you really care about binary incompatibility try running a non-x86 processor with a Red Hat-based system (like Yellow Dog Linux), then see how many RPMs you run into that are completely useless. And then please feel free to forward my complaints along with your own to the people who completely ignore an entire chipset, making the excuse that "We support Linux because we released an RPM".
I do not have a signature
I'm not sure what better way to describe it, but I just didn't care for the way they setup certain items and the entire look and feel left me somewhat annoyed. I realize things like wallpapers and icons can be changed fairly easily, and I'm certainly not knocking having multiple distros, as I do enjoy having the latest and greatest kernel/software releases included with Mandrake, but I'm just not sure who I would recommend Mandrake to. Perhaps I'm just biased because I've been using a certain other version of Linux for so long.
Compiling kernels the old fashioned way. The Linux Pimp
--It's Pimptastic!--
They're using a whole new kernel version. I think that's enough reason to call it Mandrake 8.0.
I would like to go on record here as saying that debian users are turning into the BSD's of the Linux distro's. They are pompous and annoying and 31337 and probably all descendants of Amiga users.
I am therefore going public with an official statement:
I Bob Abooey, am hereby and do officially proclaim that I will never ever ever, ever, use debian Linux. If debian is the only Linux distro left on earth I will drive to Best Buy and give my last dollar to the wild eyed clerk for a copy of Microsoft Windows. If debian was the only OS left on the planet I will chop down a tree and build an abacas. In fact from this point in time I refuse to even acknowledge the rumor that debian even exists. And lastly, all of you apt-get-morons can kiss my big hairy white arse.
Yours,
All the best,
--Bob
Latest Mandrake was 7.2, so it's quite natural to have the new one called 8.0beta! Ok, in the past they have jumped from 6.1 to 7.0 (this was the *real* version inflation), but in a still older past, they did a 5.3 after 5.2 :-) Anyway, I've tried to download the two ISOs - I've followed and contributed to the development of this new Mandrake on the Cooker-list and while there are not many extra features from Mandrake itself this time, there is Kernel 2.4 an, KDE 2.1 and Gnome/Evolution and Nautilus. So I'm very impatient to test this release candidate!
I disagree for server use: I have several machines serving thousands HTTP request per day, with MySQL database calls and Mandrake is great for that: excellent performances (i586 optimizations + SGI optimization in Apache-Extranet-Advanced-Server). And also they have the high security levels: I put the highest and have not cracker breaking my servers. That's very confortable. And really, for stability: did you test it intesivly? It's *really* not unstable. And they are very reactive with security patches.
Why is it not the Mandrake icon?
I just bought 7.2. and tried 8.0beta download. I am new to linux so I appreciate the easy install. But the sound doesn't work in either of these distrobutions. Going to their bugzilla page and doing a search on "sound", there are open bugs that go back to last october with soundblaster cards and getting them to work. I'm no rocket scientist, but they need to have a "version freeze" until they take care of all the soundcard problems.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Has anyone gotten the KT133 chipset working with ANY HD's? I have a Abit KT7-Raid and after compiling 2.4 I get MASSIVE drive corruption. I've tried turning DMA off and it seems to help a little but last night the ystem locked again and now it won't complete a fsck. (same as what used to happen very quickly when DMA modes was on? FYI I'm, using a maxtor DMA-100 Drive that I'd like to use on the HPT370 Controller once I solve the corruption problems.
hi warlock (george here)
okay let's take a look at this
[#4] The accuracy of the floating-point operations (+, -, *,
/) and of the library functions in <math.h> and <complex.h>
that return floating-point results is implementation
defined. The implementation may state that the accuracy is
unknown.
many people have ALREADY said that floating point is INHERENTLY unaccurate. the REASON why you get 9 = 10 or 10 = 9 is because ONE of the expressions is calculated at COMPILE time and the OTHER is done at run time and the METHOD may differ. there is NO way to represent many floating point numbers exactly on many cpus, this is why approximations are used instead. this will OCCASIONALLY lead to a rounding error. YOUR example is particularly precipitous and draconian because you use an operation (TRUNCATION) that is the most likely to show the unaccuracy!!
all in all i have to say that your criticizm is pretty PICKY. and trust me i KNOW picky, my wife is the most picky person EVER, "george keep your elbows off the table, george put the toilet seat up, george don't use the word AIN'T" god!!!!!! sorry if this is harsh but god i have to come HOME to the world's biggest grouch and there is NO REASON why this pickiness should be tolerated!! god
your bud
-gbd
One wonders why the other distro's have so much difficulty equaling Mandrake in this arena? People like Debian and Red Hat are too purist in their respective fields to ever really become popular in the home, however as their users have accepted this it does not matter, I suppose. Still, such lack of ambition in the arena is startling.
The bleeding edge and easy to use nature of Mandrake is why it has 28% of the marketplace. More power to them, I say, and hopefully other distro's will take a leaf out of their book.
You know exactly what to do-
Your kiss, your fingers on my thigh-
You know exactly what to do-
Your kiss, your fingers on my thigh-
I think of little else but you.
Mandrake2001
Your world frightens and confuses me! When I order an espresso at StarBucks, I think that the foam on top is the saliva of a rabid mammoth! Sometimes when I drive my Ferrari at the racetrack on weekends, I wonder, "Are there little men inside running really, really, fast?"
My primitive mind can't grasp these concepts. But there is one thing I do know -- the 2.4 kernel still does not support my Zip Drive or USB joystick. This is really annoying to me, a primitive caveman, because I it makes it difficult to work on my flight-control systems source code from work under a familiar UNIX-style environment. Instead, I have to copy the code from my Windows machine with a working Zip drive, copy over the gigabit ethernet in my primitive, caveman home, and then copy the compiled executables back in order to test the tolerances. Even my feeble, confused mind can recognize that USB support in the 2.4 kernel is a necessity!
Thank you.
My daughter looks like that idiot Cyborg_Monkey!