Posts by Mike 137 3531 publicly visible posts • joined 10 Sep 2009
'"They are working on really poor quality qubits. These early qubits just aren't good enough, they have to get at least 10 times better in terms of their noise and stability..."'
This is a very real problem, by virtue of scale. Almost anything electromagnetic can interfere at this level. It's the ultimate hard nut to crack if quantum computing is ever going to go mainstream.
In that case you actually know it's a lot worse, as a coin toss has only two states, but a useful data word must have many.
The fundamental (and insoluble) problem is that quantum bit states are statistical in nature, not finite like the states of conventional logic. Several decades back I was using a "maybe gate" - a squared up diode noise generator, and it had similar uncertainty (which was why it was useful as a random sequence generator) ;-)
But if nothing else, this research has clearly demonstrated the problem.
"In theory, as you add qubits, the power of your quantum computer grows exponentially, increasing by 2n, where n is the number of qubits."
[1] what is the definition of "power" here?
[2] 2n growth (e.g. of numeric range) with bit count is not exclusive to the quantum domain. It's somewhat relevant to any binary base system.
So what point is being made?
[1] The sample size is less impressive than it seems at first sight. 31,743 accepted responses, 183 "countries or regions", so an average of 173 developers from each. Seven alternative working disciplines, so an average of 25 developers per country/region and discipline. We're now dealing with very small sets here from which to develop statistical arguments.
[2] Respondents were self selected and attracted via Twitter ads, Facebook ads, Instagram, Quora, VK, and JetBrains’ and "links to some user groups and tech community channels". Consequently it primarily represents a particular culture within the developer community (one that spends time on social media and possibly even one where javascript is preferred).
[3] The raw results were then "weighted", first using some quite arbitrary assumptions and then applying a mathematical "third stage" of "30+ [undisclosed] linear equations and inequalities" using "the dual method of Goldfarb and Idnani (1982, 1983)" which it's up to the reader to go and investigate.
This is not how reliable research is reported (even supposing the results are valid).
For some inexplicable reason, the "artificial intelligence" could identify a moving car in front as an obstacle, but not the stationary big yellow and black rectangular plate.
And actually it's not an autopilot in the strict sense. But even if it were, the big difference between aviation and road traffic is the separation between vehicles and obstacles and the time available for decision making. There's a fallacious assumption that road vehicle avoidance automation should make decisions about the nature of obstacles, which makes the process much more complicated (and complexity is hazardous).. Aviation collision avoidance systems very sensibly aren't expected to discriminate between different categories of obstacle - just to warn that there's one (of any old kind) ahead.
"...journeys are limited by the plane’s electric battery storage"
In reality, they're limited by the accuracy of the charge meter. A gas tank fuel level meter is extremely accurate, so it can be relied on as a basis for decision making while in flight. Not so a battery charge meter, as its reference point is the capacity determined at charging time but battery capacity varies dynamically with multiple factors including age, charge regime, temperature and discharge load.
The problem is the variability of air speed v. ground speed. Because flying into a stiff wind will empty the fuel tank or battery faster than flying in still air, the accuracy of the gauge is fundamental to safety, as when the fuel is out you crash. So safety margins will have to be much wider for electric planes than has been allowable to date (and there's unlikely to be much of an option for a "reserve" due to the very low energy density of the power source compared to gas).
"The lack of 3G shouldn't be too much of a pain because by that point, most people will have a 4G or 5G-capable handheld"
I know several people with arthritis who can't use a "gesture controlled" smart phone, so we'd better hope some vendors will provide 4G "feature phones". Otherwise, pseudo-Darwinian unnatural selection will "phase out" the elderly. Not forgetting of course that the currently young and agile will themselves one day become "elderly". Unless of course we adopt the principle of Logan's Run City.
I found out end of last week that they've done something behind the scenes that broke one of my CMS based web sites. It displays, but I can't post anything new.
I've always found their helpdesk very helpful and obliging, but have had to contact it rather too often for comfort latterly.
There's also a need for intuition - which is not guesswork, but in the words of the late Robt. Ornstein "arrival at a correct answer without recourse to inference". It's based on accumulated experience but experience alone is only a part of it.
For example, in the days of dumb terminals, I was thrown a dead one to fix. A huge board covered with TTL chips, no manual and no circuit diagram. It suddenly occurred to me that TTL is tough stuff, so I raided the digital chip drawers in the electronics shop and, one at a time, I sat a replacement chip on each of the onboard devices and turned on. Half a dozen chip tests down the line the terminal sprang to life. So I turned off, replaced the said chip and everything was fine. I haven't a clue why that approach occurred to me - it's distinctly oddball, but it succeeded. That's intuition, and without it the terminal would have been scrap.
"Our company has -no- formal software development processes"
No company I've ever consulted with in the last couple of decades has had any formal software development processes - or any adherence to formal standards - just locally developed habits. That's why it's not "software engineering" - just coding, because engineering is fundamentally a rigorous approach, not merely a body of knowledge.
One of my more thankless tasks has been to try to introduce some formal processes and standards into established development teams. Typically they don't want to know. It isn't just management pressure - I suspect it's to a large part self confidence. But the results often indicate the self confidence is misplaced.
One day someone might work out to how to write code that isn't riddled with hazardous vulnerabilities, or am I dreaming?. No mainstream OS or major application has to date been rendered free of critical bugs prior to being retired. Hence the obsession with "legacy" being dangerous. But the replacements rapidly demonstrate that they're just as bad. In any other branch of engineering this record would not be tolerated - but does software development yet qualify as engineering? I think not. Until it does, we're going to continue spiralling downwards towards digital oblivion, and considering the increasing penetration of software into pretty much everything we use, it's no longer that far off.
"Analysis of the shape and structure of the long-dead creature's wing compared to modern insects suggests that these panels may have allowed T. azari to communicate by reflecting light or producing crackling noises."
It's well known by bee keepers that the sound of a hive is indicative of the condition of the colony - not just health, but also response to invaders and other threats. Given the limited gamut of bee needs for communication, this seems rather similar.
"they had to agree for their "anonymised" data to be owned by the company supplying the tests."
I've met that in government service (without the guarantee of "anonymisation") within the last few years. A "team building day" required everyone to document their "strengths and weaknesses", and they hadn't bothered to find out that the information was shipped to the US by the "team builder" organisation with blanket re-use assumed.
"you got the results of what could be achieved by the chemistry after passing through the previous 2 layers of chemistry."
Actually you didn't (don't). The top (blue) layer is separated from the green and red layer by a carefully controlled filter and the green and red layers are separated only by their differential spectral sensitivity (ortho v. panchromatic) but all thee at the point of exposure are silver halide in gelatine, so there's no differential "chemistry" to pass through at that stage. The substitution of specific dyes for each layer during processing is the only point where the chemistry really affects the colour (and indeed where correction can be made for the non-linearity of the halide light response in the presence of extreme contrast), and for professional films that has been (is) so good that precise repro of critical colour products such as cosmetics is possible.
The Bayer filter causes each pixel colour to be some (often cunning) average of a cluster of adjacent pixels so there is a good chance that the final colour of an image pixel will not exactly represent the colour of the light that originally fell on the sensor pixel (particularly at high contrast edges).
So there are numerous factors that influence colour reproduction accuracy, but several of them outweigh nominal gamut.
Depends what you mean by "equivalent".
Disregarding the lens for now (although it's often the limiting factor for both film and digital photography), a monochrome film may have anything from 1M to 3bn grains per cm2 (fast v. ultra fine grain film), the lower figure nominally approximating to your 8.6MP, but that's the very bottom end of the scale for film. Colour films tend to the lower end of this range and the dye substitution process blurs the grain a bit, but that can actually increase subjective image quality as it tends to eliminate jaggy edges.
However, on a film the grains are randomly distributed and vary in size in a range of some 200:1, whereas the pixels of a digital array are on a rigid rectangular grid. This alone makes the film better able to record lines and edges that are not strictly perpendicular to the frame, as jaggy digital diagonals are unavoidable unless smooted artificially by post processing.
Then you have the effect of the Bayer filter, which averages a sliding array of (minimum) 4x4 pixels in order to render colour at all. So despite a lot of fancy math, you can roughly divide the linear pixel count by four to arrive at the actual resolution of a digital camera image. Furthermore the actual pixels out do not directly represent the image that landed on the sensor as they are the result of averaging, smoothing and various "enhancement" algorithms.
Consequently, given the same lens, a film image is a nearer approximation to what was being photographed than a digital image can ever be, and even with clever post processing you should probably multiply the "equivalent" pixel count by at least a factor of three. Funnily enough, for a 35mm frame that's around a 24-30 MP camera.
Taking this in conjunction with 'This shortfall prompted the BCS to state: "The lack of people over 50 working in tech is a strong indication that this group needs to reskill"', it might also suggest that the IT sector is less bothered about accumulated experience and personal expertise in problem solving (which are both fundamental to good engineering). This certainly seems to be the case in software development, witness the several web sites dedicated to "<insert programming language> interview questions and answers".
When I was teaching IT engineering and software development, my students actually expressed surprise that, when asked a question, I didn't immediately resort to thumbing through a textbook like (apparently) my predecessor had done. And I'm now constantly bumping into developers who state that something "can't be done" in <insert programming language> because there isn't a library method for it. I usually find it can be done with a little ingenuity, and often very simply.
'...the UK survey's 2,102 adult respondents, polled between 6 and 18 May, said their top concern was that "personal information [is] being used for scams or fraud."'
That may be primarily because they're unaware of how else their personal data are being abused.
Our research of the situation to end of 2020 showed that practically no business was properly informing data subjects about its processing of personal data, and this wholly unacceptable situation is hardly likely to have changed in the last six months. Indeed it has been tacitly approved by the EU in the text of the UK Adequacy decision via Article 49, which states "Data subjects should be informed of the main features of the processing of their personal data" [emphasis added]. This directly contravenes Article 5.1(b) of the GDPR, which states that personal data must be "collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes" [emphasis added].
The problem is further exacerbated by the strict letter if the GDPR, whereby only existing data subjects are legally entitled to request full details of processing. Those not yet signed up may request the details but there is no legal obligation on the data controller to comply beyond the publication of a "privacy statement" (which our research showed is almost universally woefully inadequate but nevertheless apparently generally acceptable to the ICO). Consequently you have to put your head in the noose before you can find out how much a business is likely to tighten it.
This definitely needs to be changed, and can be now we have the right to make our own laws again. Anyone should have a statutory right to find out in advance exactly what a business is going to do with their personal data.
Not nice, but in both Orwell's 1948 and Lucas' THX-1138 there were cameras everywhere, and the consequences in both cases were rather more severe than just being kicked of a video game. So there was plenty of prior warning. And in many places today the consequences of ubiquitous cameras are still much worse.
A rather minimalist criterion. I'd be more impressed if the code not only worked properly but were a reasonably optimised solution.
The example queries quoted are rather interesting on this basis. The first "//compute the moving average of an array for a given window size" is trivial, and the second "//find the two entries that sum to 2020 and then multiply the two numbers together" (still very, although not quite so, trivial) hand holds the AI at quite low level.
I've recently been developing a sub-microsecond resolution real time system in Java, and I can confirm that tiny variations in the code can make huge differences in performance. If I had to rely on AI, I'd rather ask it to "code me a timer that runs for an exact amount of time in increments of 500 nanoseconds". Otherwise I'm really doing all the hard stuff myself anyway.
If course, if this AI can be got to work reliably it's one step nearer total deskilling, so every business manager will be able to "write their own program". It'll probably run like a three legged dog with arthritis, but they won't need to pay programmers any more.
'In a series of tweets, she said: "Nothing could be more serious than government ministers facing investigation for potentially breaking the law.'
We have a prime minister who, according to Private Eye (1550, 8/07/21) is apparently on record (c. 1990) agreeing to facilitate an assault on a journalist who had (supposedly) annoyed a businessman friend.
"Automated guided vehicles, such as driverless forklifts, are common in modern warehouses but need dedicated infrastructure to operate properly. One wrong QR code, or a shelf that's a few millimetres outside a set tolerance, and they struggle."
A guy I once worked with had managed an automated warehouse using high lift robot forklifts working racks some 25 feet high (admittedly somel decades back). One day the bar code database died and everything stopped dead. They had to bring in mountaineers to abseil over the racks recording all the bar codes afresh.
This report is a (not terribly funny) joke.
The proposed principles are (as usual) vaguely expressed, and the section "Embedding our approach across government" just consists of proposals to 'examine', 'explore' and 'review' things.
"Embedding our approach with regulators" includes a proposal for "a voluntary forum comprising the CMA, FCA, ICO and Ofcom" (note voluntary) and a bit more 'exploring' and 'assessing'.
So, if anything other than a PR document, this is essentially a set of volatile aspirations with no concrete objectives or deliverables attached.
Government as usual.
Scott Adams summed this up very well over two decades back. In one strip the Pointy Haired Boss explains that he loves hiring temps as they get no benefits and you can chuck them in the dumpster when they're no longer needed. To Dilbert's remonstrance that it seems "a bit inappropriate", he responds "they're way too big to flush".
Indeed the staggered layout of the typewriter was itself due to ease of manufacturing, as each key was connected to a long lever running away from the operator to the mechanism that flipped the type bar. The stagger allowed the levers to be straight and lie neatly side by side. If the "ortholinear" layout had been used (as it was on the early Chinese keyboard) all the levers would've had to have multiple bends in them, making them harder to manufacture and less rigid.
""I think, based on what we've found, cyber insurance is not that silver bullet that maybe people were hoping or thought it was.""
It never really was.
Many moons ago I evaluated a handful of policies for an international business. At the two ends of the scale were capped payout plans with minimal obligations attached and adequate payout plans with considerable obligations on the insured.
The policy with optimal cover included an obligation to advise the insurer of any changes to the infrastructure within a very short time. As my client was a dynamic business frequently introducing new online services and opening new local offices all the time world wide, the combined cost of the premiums, the notifications and the excess terms rendered the policy uneconomic unless a claim were made successfully more often than once every couple of years.
I finally recommended self insurance, whereby an emergency reserve could be retained, earning interest while not called upon, rather than the business making a regular annual payout accompanied by a trickle of ongoing management costs.
The article is behind a paywall, but the abstract doesn't indicate what is precisely meant by "switch". What they've done (and it is clever) is a state-stable mechanically sliding mechanism controlled by an electric field. Three questions beg to be answered:
[1] would this be suitable to be used as a current carrying switch (even at microsignal levels)?
[2] if so, what would its switching capacity be?
[3] given its scale, how sensitive would it be to interference?
"it will receive an APK optimised for the device rather than a universal APK prepared by the developer."
Not only loss of control over signing - now we've lost control over the code as well.
Why doesn't Goooooooooooooooooooooooogle just create all the apps itself? Lack of talent? Shhhhhhhhhhhhhhhhhhhhh!!
"Does the NFT contain that code or has someone cocked up?"
As far as I'm aware the NFT is just an entry in a blockchain that is taken to imply ownership of the asset and probably contains a link pointing to where it resides on the web. The actual files aren't anywhere in the blockchain, so it's probably the auctioneer who's messed up when posting them on the web.
Insanity like this in principle has been around and come around numerous times over several centuries. Among a rather turgid miscellany of irrelevant stuff, Charles Mackay's Extraordinary Popular Delusions (1852) lists half a dozen instances of silly ideas that took an entire population by storm (far more extensively than NFTs), not least the South Sea Bubble of 1727, when hundreds of speculators ruined themselves buying the worthless stock of (in many cases patently) bogus companies. One such advertised itself as a company with a purpose so secret it could not be divulged. It was - they raised a huge sum by selling bogus stock and absconded to America.
On occasion, however, mass manias can have an even more harmful character. In 1731 the villagers of St. Medard started worshiping the tomb of the 17th century Jansenius, Bishop of Ypres. A cult developed involving eating earth from around Jansenius' tomb, voluntarily induced violent convulsions and "an urgent instinctive desire for certain extreme remedies, sometimes of a frightful character,--as stretching the limbs with a violence similar to that of the rack,--administering on the breast, stomach, or other parts of the body, hundreds of terrible blows with heavy weapons of wood, iron, or stone,--pressing with main force against various parts of the body with sharp-pointed swords,--pressure under enormous weights - exposure to excessive heat, etc." [The Convulsionists of St. Medard. Hon. Robert Dale Owen, The Atlantic Monthly. VOL. XIII. Feb., 1864 in two parts].
Ultimately some 800 people fell into this cult, which did nobody any good and not a few serious physical harm. despite it having no charismatic leader. It just spread spontaneously through the population.
On the face of it a few extremely rich folk wasting their money buying a hash seems quite mundane by comparison.
Moore's Law can't be kept alive, as it never really existed. Moore made a passing comment about the rate at which fabrication was advancing, quite secondarily to another topic that was (to him) more interesting. Typically, the minor comment was latched onto and the major point has been entirely forgotten.
There's absolutely no scientific, engineering or logical basis for there to be a constant rate of chip density increase, so "Moore's Law" is really nothing other than fabricators' PR hype.
Yours is indeed one (but not the only) possible interpretation. But the summary notwithstanding, if you read the entire report you find a consistent and repreated concentration on all the other factors, so the balance of the mindset is clear.
BTW I don't smoke (not unless I get very hot indeed).
Ideally you'd want a much longer hold up time for the router that you'd need for your computers as typically the UPS just lasts long enough for orderly shut down (I'm talking SOHO here). But your phone (via the router of course) needs to stay available for much longer than that if you want to be safe, so a separate UPS is a more resilient approach as you don't want your computers dragging the router power down soon after the mains go out.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
