Forgot your password?

Comment: Re:its why devs cringe. (Score 2) 180

by ShadowRangerRIT (#47578213) Attached to: PHP Finally Getting a Formal Specification

Most high level scripting languages (can't speak for PHP, but it's true for Perl, Ruby and Python) implement simple user defined objects as dictionaries. That said, the lookup cost, while obviously much higher than pre-compiled v-tables, are not as expensive as you might imagine; attribute access uses interned strings, and strings cache their hash code on first hash. If you don't actually have to recompute the hash, and equality checks are (for attribute lookup) a simple reference identity test, the CPU costs are basically nil, you just have the issue of page faulting due to "random" access into the hash table (and Python at least optimizes for that case; the collision chaining algorithm in recent versions of Python tries to chain into the same cache line if it can, alternating with chains by "long steps" to avoid issues with consecutive hash codes).

Stuff that kills Python performance includes: Minimal optimization of code by the byte code compiler, and none by the byte code interpreter (while each hash table lookup is cheap, a loop will perform it over and over again, even if you're accessing the same attribute on the same object, because the compiler and interpreter aren't sophisticated enough to recognize what's happening); inability to parallelize CPU bound tasks using threads thanks to the GIL; lack of "primitive" types, so even basic math involves substantial memory allocator overhead and memory fragmentation, etc.

TL;DR: Python's performance problems aren't primarily a result of hash tables.

Comment: Re:Catching the big choices (Score 2) 710

Gets worse if you own an electric vehicle. My power company has a neighbor comparison tool, where it compares my electric usage to similar neighbors (the nearest 100 houses of roughly the same size, same heat/AC systems, same number of occupants). I reliably came in between #2 and #5 lowest electric usage. Until I bought a Leaf. I'm still in the top 20% "most efficient", but only barely, thanks to the $20-30 of electricity it takes to fuel each month. Because I got rid of a 20 MPG rusting to pieces junker for a 115 MPGe vehicle, my performance on the one metric of "home electric use" went down.

Comment: Re:Java or Python (Score 2) 415

by ShadowRangerRIT (#47411961) Attached to: Python Bumps Off Java As Top Learning Language

The ability to seamlessly use + with mixed text and numeric types in a language without explicitly declared types is usually considered a design flaw, not a positive feature. Perl uses separate operators for strings vs. numbers to avoid ambiguity, while Python and Ruby require explicit type conversions. Java defaults to string concatenation, but Java requires explicit types, so you get a compile time warning if you make a mistake like adding a String and an int and expecting an int. Even PHP, the go to standard for poor language design, which explicitly rejects separating operators for strings and numbers, made a concession for addition vs. concatenation and borrowed Perl's approach of using + for addition and . for concatenation so the operator itself selects the operation.

The sole exception to this rule that I can think of is JavaScript, where + is type dependent, and it lacks explicitly typed variables. The fact that you're allowed to use addition with silent coercion to String if either operand is a string is explicitly called out as one of the Awful Parts in JavaScript: The Good Parts, which should tell you something. Basically, implicitly typed scripting languages should prohibit implicit type conversions when they use + for both addition and concatenation. The alternative is to behave incorrectly silently.

As for the ternary operator, really? That's your big gripe? The fact that it reads like an English sentence? Guido hates excessively concise/cryptic punctuation as language elements, so they chose something that reads a bit more like English; if you read it aloud, e.g. "a if a is not None else b", it makes sense. You could also view it as a stealthy attack on the ternary operator, which many people despise as encouraging cryptic code. Either way, we're not talking about something truly ridiculous here; it's a reasonable design decision. This isn't PHP's left associative ternary operator or anything.

Comment: Re:Which raises the critical question: (Score 5, Informative) 415

by ShadowRangerRIT (#47410087) Attached to: Python Bumps Off Java As Top Learning Language

I really hope 3.x, if only for the fact that your code tends to work with non-English text by default, because str supports the whole Unicode range, so it works with non-English input by default. Compare to 2.x where you have to make a conscious effort to work with Unicode. Particularly important for third party libraries, where they aren't producing a final application, and often don't think about Unicode at all even for text based APIs. Heck, the Python built-in csv module in 2.7 doesn't work properly with Unicode; you have to load or convert as UTF-8 bytes, parse, then decode to the 2.7 unicode type. It's a mess.

For teaching purposes 3.x is even better, since you have a proper distinction between binary data and text, rather than the mushy 2.x situation where str is sometimes binary data and sometimes handicapped text, while unicode is always text, and sometimes interoperates with str, while at other times it explodes. Teaching languages should be consistent, and 3.x is simply more consistent than 2.x (largely because of cleanup decisions like this).

Comment: Re:Adults are the carriers (Score 1) 387

by ShadowRangerRIT (#47249897) Attached to: California Whooping Cough Cases "an Epidemic"
I wouldn't have normally bothered, but the distinction is relevant given TFA. The switch to an acellular version of the pertussis inoculation is what reduced the duration and efficacy of protection. It's not that the old pertussis vaccine was ineffective, it's that we've been using a different vaccine for the last 20 years, give or take, and the new vaccine ended up losing a lot more efficacy than they expected.

Comment: Re:nissan or mazda? (Score 2) 137

I agree that a good shared standard might allow for efficient production of batteries by removing the market fragmentation that dissuades people from starting up "gigafactories".

That said, Tesla hasn't demonstrated a superior battery technology. The 2013 Leaf's range was rated lower than it really should have been. It offered a "Long life" charging setting, where it would stop charging at 80% instead of 100% to extend battery life. The EPA decided to base the estimated range on a 90% charge to split the difference between the two options, because the 80% charge was "recommended". Tesla allows you to stop charging at any 10% increment between 50% and 100%, but because lower charges aren't "recommended" the EPA assigned a range based on a 100% charge.

Factoring that in, at 100% charge, the 2013 Leaf should have a range of ~84-85 miles. Assuming 84, on a 24 kWh battery pack, that's 3.5 mi/kWh. The Tesla gets ~3.1 mi/kWh. The Tesla is heavier thanks to all those extra batteries, which is a big part of the difference; I suspect that if you made a Tesla with a 24 kWh pack, it would have similar efficiency to the Leaf. Battery tech is hard to improve; Tesla and Nissan are using the same basic tech.

TL;DR: Stacking more batteries is hardly a demonstration of superior technology.

Comment: Re:nissan or mazda? (Score 2) 137

Not according to Nissan's website. The base S model has a 3.6 kW charger. You can add a charge package for $1250 that upgrades it to a 6.6 kW charger and adds a Quick Charge port, but the base model doesn't support 6.6 kW charging or a Quick Charge port by default (similarly, the mid-level SV model comes with a 6.6 kW charger, but requires an add-on package to get Quick Charge). Might be hard to find a completely base S model without the charge package, but Nissan claims it's an option.

Comment: Re:nissan or mazda? (Score 4, Informative) 137

Nissan doesn't have problems with charge times (at least, no more than Tesla). The base model takes 8 hours to charge from empty, but they offer a 4 hour charge option (that runs off the same Level 2 charging stations) and a Quick Charge option that gets an 80% charge in 30 minutes. Pretty similar to Tesla.

Comment: Re:Diesel? (Score 1) 462

by ShadowRangerRIT (#47081297) Attached to: Fiat Chrysler CEO: Please Don't Buy Our Electric Car
It's not about gas vs. diesel (or electric). It's about variant designs sold in the U.S. vs. Europe. They don't sell exactly the same car. Even with the same fuel type (though they might beef up the U.S. engine to handle the extra weight), U.S. cars tend to do a little more poorly on mileage due to the weight of the extra safety features.

Comment: Re:It's still NP. (Score 1) 114

A short key right now is 512 bits (0.5 KB). A longish key right now is 4096 bits (4 KB); many sites use shorter keys because high traffic sites can't afford the bandwidth and CPU required to transmit and process even a 4096 bit key for thousands of connections per second. Squaring even the short end of that range would produce a 262144 bit key (256KB). That's a ridiculous amount of data overhead just to initiate a connection, and performing math in a space that large would tax the CPU of individual computers; if a web server is performing that much math for every connection, you'd dramatically increase the overhead to serve web pages.

TL;DR: Squaring key length make math hard, hurt computer.

Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson