Predictable Schadenfreude
|
| Author | Content |
|---|---|
| hkwint Aug 13, 2010 1:08 PM EDT |
While reading this, I thought: "When does he say it", but at the end, there it was: "I can not help to think that Google could migrate Android from Java to the ECMA/ISO CIL and C#. " How predictable. Of course, after Sunset comes the Oracle-era, and in the Oracle-era Miguel is right. |
| Sander_Marechal Aug 14, 2010 8:01 AM EDT |
C#? They'd be better off porting it to Python... |
| gus3 Aug 14, 2010 8:48 AM EDT |
You know that, I know that, but this is Miguel we're talking about. Still, PJ@Groklaw pointed something out. Remember Jonathan Schwartz after his Sun exit, talking about when Microsoft tried to threaten Sun over some VM patents? http://jonathanischwartz.wordpress.com/2010/03/09/good-artis... Sun's lawyers pulled out their patent portfolio and said, you're violating these patents of ours. If you sue us, we will sue you right back. If Gates&Co had a dog in the fight, it suddenly needed dentures. So why isn't Oracle going after Microsoft? It isn't like there's any love lost between Ellison and Gates/Ballmer. Oracle keeps the Windows version of their database, only begrudgingly, and they make sure everyone knows that high availability and Windows simply do not mix. (Ellison and Jobs are buddies on the golf course, so Oracle probably won't go after Apple.) Does this make sense, or is my freshly-awake, half-asleep mind overestimating its coherence? |
| hkwint Aug 14, 2010 9:12 AM EDT |
I thought Microsoft already paid for SUN-patents pertaining to VM's / Java? |
| gus3 Aug 14, 2010 9:25 AM EDT |
Re-reading Schwartz's post (and waking up some) gets to me what I think is the real reason: M$ tried to go after Sun with Office patents violated by OOo, and Sun retorted with Java patents violated by .NET. If Oracle tries to assert the Java patents against M$, it'll get slapped around with the Office patents. |
| hkwint Aug 14, 2010 10:13 AM EDT |
Hence Oracle needs to lose OOo? |
| gus3 Aug 14, 2010 10:23 AM EDT |
If they want to go after Microsoft, yes. |
| DarrenR114 Aug 16, 2010 3:05 PM EDT |
Too many fundamental disparities between Python and Java to make a move from Java to Python feasible:
Ternary Operator:
A lot of programmers use this all over the place, and Python's non-standard implementation would make such a migration a real pain. LV = ( iDOM == 15)? 'Yay - Payday' : 'Aw - no money today for you';and $result = ($a > $b) ? $x : $y;is a lot easier for most to understand than x if a>b else yor (lambda:y, lambda:x)[a > b]() all of the braces for code blocks '{,}'; all of the semi-colons at the end of statements; variable definition statements; Then there's all the forced re-factoring that would have to take place. All those years put into the development of Android would have to be scrapped for a complete re-write. Not very practical from a business stand point. Whereas, the language disparities between C# and Java are far fewer (because of the directive to make them very similar) and less destructive to the original codebase. But then what do I know? I'm incompetent and don't have a clue about software development or data processing (according to some regular contributors on this site.) |
| jdixon Aug 16, 2010 3:13 PM EDT |
> is a lot easier for most to understand than Assuming I understand them at all, I don't see where one is harder than the other myself. But that's me, YMMV. > Whereas, the language disparities between C# and Java are far fewer (because of the directive to make them very similar) and less destructive to the original codebase. But those similarities mean that C# is itself more likely to violate one or more Java patents then Python. It's a no win situation. |
| DarrenR114 Aug 16, 2010 5:45 PM EDT |
with "Chinese walls" - re-deploying an piece of software into another language is usually a safe bet to avoid a the minefield that is "patent portfolios". |
| hkwint Aug 16, 2010 6:48 PM EDT |
Honestly, I don't agree about the ternary operator being harder, because: Someone without any programming experience can understand what the 1st Python statement does, even if you don't know the notation it's trivial what this says. the same can certainly not be said for the C-style ternary operator. When reading about C, I had to read it four times before understanding what it did. I can assure you anyone with proficient math-knowledge will understand the Python-way of saying this. So, when saying: "It's easier for most", you could better have said "easier for people with prior programming knowledge". Which is why Windows is more intuitive to Windows users than Linux users. Moreover, using the ternary operator doesn't make sense anyway: http://embeddedgurus.com/stack-overflow/2009/02/efficient-c-... I'd say code with it is harder to read than a simple "if then else" loop, because you have to look for the bloody colon and question mark before you can understand what the code does. Maybe you think 'fork bomb-like stuff' is easy to read and understand, but to 'noobs' like me, "if ... then ... else ..." is preferable. Unless you're trying to minimize the size of the source code, but then you should be using Python anyway! Apart from that, most of your objections are all 'notation issues'. Yes, Python does have different notation than other languages (which lots of people detest), and yes, it would be pretty pointless to convert any Java program to Python, it will be hard, it would be a waste of money, but if you want it, I think it can be done. But I agree rewriting in Python is a pretty pointless solution. Coding around the patents would probably be much easier. Or trying to "port" the code to the GPL'd-Java instead, if such were possible. But I don't know anything about Java. If not, probably just pay what Oracle is asking, or try to find any other patents to counter-sue them. Or maybe Google should give PostgreSQL or MariaDB some 'corporate enterprise' backing (yes, I know, I just cursed as it's MySQL with a different name). |
| jezuch Aug 17, 2010 2:44 AM EDT |
Quoting:Moreover, using the ternary operator doesn't make sense anyway: [HYPERLINK@embeddedgurus.com] That's funny, because if the compiler is dumb enough to generate different assembly than from the equivalend if-else, then it's a grave bug in the compiler. When you have polyhedral analysis of nested loops and automatic vectorization, things like that are really a no-brainer. And regarding syntax - it's just syntax. You have to learn it the same in any language. Even if Python's version reads "natural" I still have to learn the precise semantics to immediately understand what it does when I see it. So all these "this syntax is harder to understand" arguments are a waste of oxygen (and bytes). |
| Sander_Marechal Aug 17, 2010 3:55 AM EDT |
It's not about syntax anyway. It's about picking a platform that isn't a patent trap. Python is better in that regards than C#. I'm not saying that it would be smart to move everything Android from Java to Python. But *if* they're going to move from Java to something else, they'd better go with Python. What Google should do is fight hard, and ensure FOSS Java. |
| DarrenR114 Aug 17, 2010 1:54 PM EDT |
@hans, harder for *most* - because *most* programmers will not start out learning Python (thankfully.) ... python has several different ways to do the ternary operator and NONE of them conform to the syntax found in the other popular languages that have the ternary operator (I am not familiar with ALL of the many 1,000s of programming languages out so I'll leave it as the popular ones). Why the PPTB (Python Powers That Be) chose to diverge from conventional wisdom, I don't know, but being different for the sake of being different is just plain idiocy. The ternary operator in the 'C' derivitives is actually very intuitive - ask a question and get one of two answers. Ask a question (the condition) ended with a '?' (something that most of us learn in grammar/elementary school) and then provide the affirmative path folllowed by the negative path (delimited by the colon ':'). Now try explaining the structure and thinking behind the ternary operator in python in just 2 sentences. It can't be done. |
| DarrenR114 Aug 17, 2010 2:16 PM EDT |
*If* Google were to port Android from Java to another (unencumbered) development platform, the better choice would be C++, instead of Python. My reasoning behind this statement? Standards. Python, like PERL, Java, and C#, is controlled by a single body that makes some pretty arbitrary decisions. C++ is ANSI standard and controlled by internationally recognized standards bodies. Python has PEP, but the final authority is one man. The same is true for Perl. PHP is controlled by one company (Zend). ANSI C++ has only one standard, whereas Python has at least 2. And which Python to use? The 2.x or the 3.x tree? The two separate trees are very different and neither tree is going away (witness the continuing development on the 2.x tree simultaneous to the continuing development of the 3.x tree). And the biggest reason for going with C++ over Python: Reliability. Python can't even get simple math done right: ===================================== Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15) [GCC 4.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 2.3 - 3.4 -1.1000000000000001 >>> 2.0 - 3.9 -1.8999999999999999 >>>===================================== I'm sorry, but if a compiler can't do simple math like that correctly - it does NOT belong on any production platform ANYWHERE. |
| jdixon Aug 17, 2010 3:04 PM EDT |
> Python can't even get simple math done right: Any language which defaults to floating point math rather than integer math will have that problem. |
| gus3 Aug 17, 2010 3:19 PM EDT |
Even if Python defaulted to integer math, including a sub-integral portion in the number representation (even ".0") should invoke floating point interpretation. Come on, even C gets it right: #include Running it shows "-1.900000" for its output. |
| DarrenR114 Aug 17, 2010 3:20 PM EDT |
@jdixon,
From the same Linux machine:
Perl:
$ perl -e 'print eval(2.0 - 3.1)."\n";' -1.1 PHP: $ php -a Interactive shell php > echo 2.0 - 3.1; -1.1 php > SQLPlus: Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, Data Mining and Real Application Testing options Conclusion, based on these findings: There is NO acceptable excuse for Python's result. |
| bigg Aug 17, 2010 4:00 PM EDT |
Quoting:In versions prior to Python 2.7 and Python 3.1, Python rounded this value to 17 significant digits, giving ‘0.10000000000000001’. In current versions, Python displays a value based on the shortest decimal fraction that rounds correctly back to the true binary value, resulting simply in ‘0.1’. http://docs.python.org/tutorial/floatingpoint.html Changing the way numbers are represented on the screen is not a solution. I prefer to see the way they are stored - that is more honest. |
| jdixon Aug 17, 2010 4:04 PM EDT |
> There is NO acceptable excuse for Python's result. Do you really want me to break out my Tandy Color Computer with Microsoft Basic and demonstrate that Python isn't the only language which does this? You can argue that no modern language should do this if you want, but it's a well known problem over the years. And no language which uses floating point math is going to give you an exact result, even if the display shows it as being so. |
| bigg Aug 17, 2010 4:11 PM EDT |
> no language which uses floating point math is going to give you an exact result, even if the display shows it as being so. Correct, because it's a hardware issue, not a software issue. |
| DarrenR114 Aug 17, 2010 4:17 PM EDT |
Personally, I'd like to see Google take C as a foundation and extend it to "compile once - run everywhere". And then release those extensions to ANSI control, relieving the resulting platform of any encumbrances. J2SE replaced with an extended C (C2SE for argument's sake) and then replace J2EE, using C2SE as the foundation. But then again, I'm partial to gtk over qt because C++ has a lot of overhead that I'm not sure is necessary and which also makes it difficult to justify for low-level applications. ===================================================== Edited to add: it just occurred to me - what Google should do is migrate Android from Java to Ada. Ada is ANSI standard (adopted as a standard pretty much right out of the box) and is designed for embedded systems (like mobile phones.) The syntax is very similar to Pascal, and it *is* the DoD standard, so finding the talent would pose little issue. http://en.wikipedia.org/wiki/Ada_(programming_language) |
| jezuch Aug 17, 2010 5:35 PM EDT |
Quoting:Python can't even get simple math done right: OK, I feel like I'm beating a dead horse here, but I gather you have no idea about floating point arithmetic, ulps, numerical stability and stuff like that. I actually made a similar mistake in front of a professor once. I feel silly to this day for insisting that this was a compiler problem, not my choice of a numerically unstabe algorithm. (Well, Numerical Methods was not an obligatory class in my course... I think now I regret not taking it.) |
| Sander_Marechal Aug 17, 2010 7:02 PM EDT |
Darren, do you really have to take a piss at Python at every opportunity? It's getting quite old... |
| DarrenR114 Aug 18, 2010 11:11 AM EDT |
@Sander, Yes, I do. Especially when people sing its praises to the point that they believe it's a suitable replacement or C, C++, or Java. It's not. Do you have to keep defending the indefensible faults of Python? It's getting quite old. @jezuch, You miss the point. It doesn't matter that it's a hardware issue - I KNOW that. Do you know when that hardware issue first surfaced? I do. It's how the phrase "1.0 + 1.0 = 1.999999999 for very large values of 1" got so popular in the IT world. Hint: 80387 co-processor. [url=http://books.google.com/books?id=pj0EAAAAMBAJ&pg=PA5&lpg=PA5&dq=80387 coprocessor bug&source=bl&ots=1969QiEaxp&sig=-P_N6cZpUSwJXKu2X0o67Qxb7VA&hl=en&ei=p_drTPGDB8H78AaQhfTLDA&sa=X&oi=book_result&ct=result&resnum=5&ved=0CCUQ6AEwBA#v=onepage&q=80387 coprocessor bug&f=false]http://books.google.com/books?id=pj0EAAAAMBAJ&pg=PA5&lpg=PA5...[/url] What point have you missed? It doesn't MATTER that it's a hardware issue - the point is that the Python compiler doesn't correct for the KNOWN issue when other compilers and interpreters do - without any special handling. |
| bigg Aug 18, 2010 11:20 AM EDT |
> the Python compiler doesn't correct for the KNOWN issue when other compilers and interpreters do - without any special handling. Actually, according to the link and quote I provided above, Python now does the same correction when displaying on the screen. |
| DarrenR114 Aug 18, 2010 11:27 AM EDT |
@bigg - Patching the display is not a fix, because in data processing most data gets stored - not just displayed. If the underlying value is stored incorrectly, which is what this indicates, the data is bad. >>> y = 2.0 - 3.1 >>> print y -1.1 >>> y -1.1000000000000001 >>> NOT acceptable. This "fix" is as dishonest as the doctored videotape that MS introduced in court during the anti-trust trial. But you already knew that when you posted the link and quote. |
| jdixon Aug 18, 2010 12:25 PM EDT |
> I do. It's how the phrase "1.0 + 1.0 = 1.999999999 for very large values of 1" got so popular in the IT world. Hint: 80387 co-processor. Then you don't know. The problem is inherent in floating point arithmetic, which depends on storing values in logarithmic format. As such, it predates the 80387 by quite a bit. Any language which uses floating point arithmetic will have the problem, whether you can see it or not. |
| gus3 Aug 18, 2010 12:33 PM EDT |
Hello, BigNum, BigInt, and BigRat. |
| DarrenR114 Aug 18, 2010 12:43 PM EDT |
@jdixon - then you don't know. There was no such bug with the 80287 math co-processor - meaning the problem is NOT inherent in Floating Point Arithmetic. When Intel first released the Pentium, it didn't think the issue was a real problem, but "fixed" it anyways (probably due to all the bad publicity and falling share price.) First in 1994 and then in 1996. If it was truly a problem with Floating Point Arithmetic, as you assert, then the problem would have appeared with the 287 co-processor and never have been fixed in later processors. |
| bigg Aug 18, 2010 12:44 PM EDT |
> Any language which uses floating point arithmetic will have the problem, whether you can see it or not. Obviously not, so it looks like we are in fact beating a dead horse. |
| jdixon Aug 18, 2010 1:16 PM EDT |
> Obviously not, so it looks like we are in fact beating a dead horse. Bigg, the conversion from integer format to logarithmic format and back is always inexact. This has been known since the days the computations were done by people using logarithmic tables, long before computers as we know them existed. |
| bigg Aug 18, 2010 1:58 PM EDT |
> Bigg, the conversion from integer format to logarithmic format and back is always inexact. This has been known since the days the computations were done by people using logarithmic tables, long before computers as we know them existed. I agree, I was actually saying that Darren will never want to see that because he doesn't like Python. I stay away from Perl because of the syntax, but this is an interesting example: #!/usr/local/bin/perl $b = 0.725/2; printf "0.725/2 is %.30gn", $_ for $b; Upon running this program, what do you know, I got the following output: 0.725/2 is 0.36249999999999999 OMFG!!! Perl can't do arithmetic correctly!!! It's not a real language!!! In Python, with a more, shall we say, reasonable syntax, I get >>> 0.725/2 0.36249999999999999 |
| bigg Aug 18, 2010 2:07 PM EDT |
Oh, and in case anyone should want to read about floating point numbers in Perl, here is a pretty well written one: http://answers.oreilly.com/topic/415-how-to-round-floating-p... Note especially: Quoting:Whether visible or not, rounding of some sort is virtually unavoidable when working with floating-point numbers. Carefully defined standards (namely, IEEE 754, the standard for binary floating-point arithmetic) coupled with reasonable defaults within Perl often manage to eliminate or at least hide these round-off errors. Which, of course, is exactly what Python does. So now let's see what Darren had to say about Python's fix: Quoting:@bigg - |
| jdixon Aug 18, 2010 2:25 PM EDT |
> I agree, I was actually saying... OK. I misunderstood. I apologize. |
| jezuch Aug 18, 2010 2:38 PM EDT |
Quoting:You miss the point. It doesn't matter that it's a hardware issue - I KNOW that. Do you know when that hardware issue first surfaced? I do. It's how the phrase "1.0 + 1.0 = 1.999999999 for very large values of 1" got so popular in the IT world. Hint: 80387 co-processor. That's only a proof that you still don't get it. We're not talking about a hardware bug. We're talking about a precisely, deliberately crafted standard. Crafted by people much, much smarter than you or me. I've got a surprise for you: 3.1 does NOT have an exact floating point representation. Python 2.6.6rc1+ (r266rc1:83691, Aug 5 2010, 17:07:04) [GCC 4.4.5 20100728 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 3.1 3.1000000000000001 Python is just honest with you. |
| bigg Aug 18, 2010 3:01 PM EDT |
> Python is just honest with you. Precisely. Darren has just provided a case study in why hiding things is the wrong strategy. He has apparently been using Perl for years, and didn't know anything about the inexact nature of floating point arithmetic, because Perl always gave the "right" answer. |
| hkwint Aug 18, 2010 9:08 PM EDT |
Quoting:Come on, even C gets it right: Probably, everyone is already aware, but this noob just found out: #include < stdio.h > int main(){ float a = 2.0, b = 3.9; printf("%10.30fn", a - b ); } gives: -1.900000095367431640625000000000 which clearly shows C-float is more off than Python, and worse, like bigg just stated, is hiding it (if one doesn't set precision). Come on, even a cheap TI83 is more precise than this! Which is why, if I want to do math, I use a calculator designed to do math (TI89, I think it has something like "arbitrary precision" because it provides the exact answer to 2^2000 without rounding, and such). Reminds me of 'right tool for the job'. |
| bigg Aug 18, 2010 9:40 PM EDT |
@hans: If you define a to be double rather than float, you'll get the same answer as Python. The greater the precision, the slower your program will run, so for serious number crunching double precision is usually sufficient. (And if you do GPU computing with CUDA, you want to use single precision if at all possible, as double precision on my older card is 5-10x slower than single precision.) |
| krisum Aug 19, 2010 2:07 AM EDT |
> Which is why, if I want to do math, I use a calculator designed to do math One would have to use something like GNU MP (I think has bindings for python/perl...) or Java's BigInteger/BigDecimal for arbitrary precision arithmetic. |
| Sander_Marechal Aug 19, 2010 3:50 AM EDT |
Yes, but those are slower. I have only used arbitrary precision libraries when dealing with money (don't want any chance of rounding errors) and when dealing with IPv6 (128-bit, which converts nicely to decimal but is often too big. Floats are only 32-bit and doubles usually 64-bit). |
| jezuch Aug 20, 2010 2:37 AM EDT |
Quoting:when dealing with money (don't want any chance of rounding errors I'm not familiar with the requirements of banking software, but isn't fixed-point arithmetic [usually?] good enough for that? Or do you really need to store those thousandths of a cent? |
| gus3 Aug 20, 2010 2:54 AM EDT |
Banker's rounding is the sine qua non in this case. http://en.wikipedia.org/wiki/Banker's_rounding#Round_half_to... |
| Sander_Marechal Aug 20, 2010 3:02 AM EDT |
@jezuch: Sometimes the amounts can get big enough that fixed-point arithmetic doesn't work. In 32-bit you only get a range of +/- 21 million with two decimal places. If you want four decimal places (i.e. when computing interest) you only get a range of +/- 210 thousand. Hardly enough for a mortgage. Using 64-bits is much better. You get +/- 9.2 trillion with four decimal places. But not all platforms have support for 64-bit integers yet. PHP is one such platform. Whenever I need to deal with monetary values in PHP, I use the BCMath extension. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!