Tuesday, September 28, 2021

CONTINUITY: The Great Jerusalem Artichoke Scam

The “weed that whips OPEC”. … “… Jerusalem artichokes were the antidote to global banking, OPEC, the Trilateral Commission, the Rothschilds, the evils of Big Ag, and Ayatollah Khomeini.”

Posted at 13:03 Permalink

THE HAPPENING WORLD: Tesla Announces “Full Self-Driving” Beta 10.2—Prioritised by Customers' “Safety Rating”

Here is more about the Tesla “Safety Score” from 2021-09-25. One hopes a swarm of contingency fee lawyers are poring over Tesla's customer agreements and licenses to see if this panopticon surveillance and coercion to enable it violates the “shrink wrap license” shield Tesla has erected against liability and failure to perform under claims of “self-driving”.

Posted at 11:50 Permalink

TRACKING WITH CLOSEUPS: Gigantiops destructor—The Celebrated Jumping Ant of Amazonia

Here is more on Gigantiops destructor. How do they do it?

Posted at 11:18 Permalink

Monday, September 27, 2021

Add category: Cat Earth

Perhaps this explains what is happening to Australia.

Posted at 14:51 Permalink


Posted at 13:42 Permalink

CONTEXT: Did an Asteroid Impact Destroy the Biblical City of Sodom?

Yes, I am well aware of Betteridge's Law.

A recent paper published in Nature, “A Tunguska sized airburst destroyed Tall el-Hammam a Middle Bronze Age city in the Jordan Valley near the Dead Sea” (full text [PDF]), argues (from the abstract) “… in ~ 1650 BCE (~ 3600 years ago), a cosmic airburst destroyed Tall el-Hammam, a Middle-Bronze-Age city in the southern Jordan Valley northeast of the Dead Sea. The proposed airburst was larger than the 1908 explosion over Tunguska, Russia, where a ~ 50-m-wide bolide detonated with ~ 1000× more energy than the Hiroshima atomic bomb. … Tall el-Hammam may be the second oldest city/town destroyed by a cosmic airburst/impact, after Abu Hureyra, Syria, and possibly the earliest site with an oral tradition that was written down (Genesis).”

How plausible is this? Well, we know that the Tunguska event occurred, and its interpretation as having been caused by a cosmic impactor that disintegrated in the atmosphere is consistent with analysis of smaller, more recent, and better documented impacts such as the 2013 Chelyabinsk meteor. The analysis in the Nature paper covers a wide spectrum of scientific disciplines including geology, archaeology, bioarchaeology and analysis of human skeletal remains, mineralogy and shock formation, agronomy, and small body planetary science. But in this age of widespread and deep corruption in academic and institutional science (as the replication crisis spreads from the squishy into the harder sciences), publication in a prestigious venue does not ensure the reliability of the work, and specialists in the relevant fields have been quick to respond, “Not so fast.”

For example, Mark Boslough, four of whose papers on the Tunguska event were cited as references, responded on Twitter as follows:

beginning a long thread which you can read by clicking the message above.

Scott Manley surveys the claims in the paper and other objections raised to it in this video and suggests that readers “Take these claims with a pillar of salt.”

Posted at 12:21 Permalink

CONTINUITY: Galileo Observed and Drew an Occultation of Θ Libræ in 1610

Posted at 11:53 Permalink

TRACKING WITH CLOSEUPS: The Subtle Physics of Bowling

Did you know that bowling lanes are not only oiled, that the oil is responsible for the behaviour of the ball, but that there are dozens of different ways to do it?

Posted at 11:23 Permalink

Sunday, September 26, 2021

THE HAPPENING WORLD: Tesla “Safety Score” to Spy on Customers' Driving Behaviour, Phone Home

Some Tesla owners think this is just great.

Why, it's “Almost like a credit score!” (bang in original). Indeed…just like a social credit score, to be precise. Perhaps if your score indicates “antisocial driving” your Tesla will only allow you to drive back and forth between your residential pod and socialist labour cubicle.

“They'll go into debt to buy their own shackles” — Kelvin R. Throop

Posted at 12:37 Permalink

THE HAPPENING WORLD: Atlas V Landsat 9 Launch

The Webcast of the launch is scheduled to start at 17:30 UTC on Monday, 2021-09-27.

Posted at 12:28 Permalink

CONTEXT: Cryptocurrency-Trading Hamster Outperforms the Standard&Poor's 500

Those with a grasp of history and a nose for irony will note that the hamster's name is “Mr Goxx”., who has his own Twitch page and livestream. Take that, potty-mouthed “stonks” day trader!

Posted at 11:58 Permalink

THE HAPPENING WORLD: Weekly Space Report: Starbase Claw and Tank Farm, FAA Environmental Assessment, Inspiration4 Returns, and Landsat 9 Launch

Posted at 11:24 Permalink

Saturday, September 25, 2021


Posted at 14:34 Permalink

THE HAPPENING WORLD: Scientific American: “Jedi” are “prone to (white) saviorism and toxically masculine approaches to conflict resolution”

Scientific American, founded in 1845, was once a paragon of science communication to the intelligent layman. After it was sold to the Germans in 1986, it began an intellectual decline which was initially gradual and then increasingly precipitous. By the early 1990s I had taken to calling it “Scientific Enquirer”, as its pages were increasingly filled with midwit sensationalism and advocacy for collectivist policies. I let my subscription lapse in the mid-90s and have since rarely seen a citation of anything in it I'd be inclined to read. Now, they have apparently gone fully “woke”. Just read this piece, under the rubric “Inequality: Opinion”, titled “Why the Term ‘JEDI’ Is Problematic for Describing Programs That Promote Justice, Equity, Diversity and Inclusion“, which has sufficient zingers per paragraph to help you meet your guffaw quota for the day. For example, “The space opera franchise has been critiqued for trafficking in injustices such as sexism, racism and ableism. … Star Wars arguably conflates ‘alienness’ with ‘nonwhiteness,’ often seeming to rely on racist stereotypes when depicting nonhuman species. The series regularly defaults onto ableist tropes, memorably in its portrayal of Darth Vader, which links the villain’s physical disability with machinic inhumanity and moral deviance, presenting his technology-assisted breathing as a sinister auditory marker of danger and doom. What’s more, the bodies and voices centered in Star Wars have, with few exceptions, historically been those of white men.” (Hello—Princess Leia, Chewbacca, C3PO, and R2-D2 are “white men”?)

Sic transit gloria Jedi. It seems to me that it's Scientific American that is “problematic” and “arguably” a disgrace to its distinguished history.

Posted at 12:47 Permalink

CONTEXT: Concorde Crash in July 2000—What Happened to Air France Flight 4590?

Posted at 12:05 Permalink

CONTINUITY: Repairing a Pressurised, Oil-Filled Underground Power Transmission Line

Posted at 10:53 Permalink

Friday, September 24, 2021

CONTEXT: Observing the Formation of Massive Stars with Radio Telescopes

Posted at 13:28 Permalink

TRACKING WITH CLOSEUPS: Maze Solving by Particle Diffusion

Dumbest way? Well, massively parallel search is how biology solves all kinds of problems and it seems to work very well. And, looking backward at it, it looks like teleology or design.

Posted at 12:56 Permalink

CONTEXT: Meteor Crater in Arizona—A Lunar-like Impact Crater on Earth

The impactor is estimated to have been an iron-rich asteroid around 50 metres in diameter, which released around 10 megatons TNT equivalent energy when it struck the Earth at 12.8 km/second. The energy is comparable to that of the Tunguska impact, but the latter formed no crater because it was probably a stony rubble pile which disintegrated in an airburst instead of an nickel-iron bullet that reached the surface.

When I was a kid, all of the books called this feature “Barringer Meteor Crater” after Daniel M. Barringer, who was one of the first to suggest it was an impact crater and not volcanic. Barringer later purchased the crater in hopes of mining iron from it, and the Barringer family still owns the crater today, There is a Barringer Crater, but it's on the far side of the Moon and 58 times bigger than the one on Earth.

Posted at 11:58 Permalink

THE HAPPENING WORLD: Floating Point Benchmark: Raku (Perl 6) Language Added

Raku Mascot, Camelia I have posted an update to my trigonometry-intense floating point benchmark which adds Raku to the list of languages in which the benchmark is implemented. A new release of the benchmark collection including Raku is now available for downloading.

Raku has had a gestation period which may be longer than any other programming language to ever actually be released. Following the release of version 5 of Perl, Larry Wall began the process of designing its successor, dubbed, not surprisingly, “Perl 6”. This was around the year 2000, and design documents began to appear. Perl 6 was intended to be a major overhaul of the language, in which upward compatibility with existing code would be sacrificed where necessary to clean up some of the infelicitous syntax and semantics that Perl had accreted over the years and gave it a reputation of being, while powerful, expressive, and concise, ugly to read and confusing and error-prone to write.

Over the years, it became apparent that Perl 6 was a moving target, as many of the design documents superseded aspects of those which preceded them. Further, the landscape of programming languages was changing over time, with techniques such as functional programming, asynchronous concurrent processing, optimisation for vector and parallel architectures, and strong type checking to guard against common programming errors, coming into use and expected to be present in any new language to enter the arena.

Perl version 5, while once dominating the system administration tool application space, began to look increasingly long in the tooth, with newer entrants such as Ruby and especially Python being the tools of choice for new projects and programmers entering the job market. By 2019, it was judged that the language, while clearly descended from Perl, had evolved into something sufficiently different that a new name was called for, and Perl 6 was henceforth called “Raku”. Unlike Perl, whose operation was essentially defined by what the implementation did, Raku has a formal specification, allowing multiple implementers to build their own compilers and libraries for the language. At the moment, the most widely used and actively developed compiler is Rakudo, which is available for a variety of machines and operating systems.

I developed the Raku implementation of the floating point benchmark with Rakudo v2021.09, which implements Raku language specification v6.d, running on Xubuntu Linux version 20.04 LTS on a 64-bit Intel x86 architecture machine. I developed and benchmarked two separate versions of the program. The first was a minimal port of the existing Perl implementation of fbench. I simply fixed the code to accommodate changes in the language, but used none of the new features or program structuring tools introduced in Raku—I call this the "port" version. The second was a clean sheet Raku implementation based upon the object oriented architecture used by the C++ version and other modern language implementations such as Haskell, Scala, Erlang, Rust, and Go. This I call the "native" version, which uses Raku's object oriented features, strong typing, enumeration and constant types, and improved control structures to structure the code.

For timing comparisons, I used the C version, compiled with GCC version 9.3.0, which executed the C benchmark with a timing of 0.795 microseconds per iteration, and Perl version v5.30.0, which ran the Perl implementation at 32.1619 microseconds/iteration, or 40.46 times slower than C.

So, how does Raku stack up against these two mainstays of the systems programming world? Well, the good news is that it got identical answers to the eleven decimal places we validate. The bad news is that it is hideously, nay, appallingly slow. How slow? Well, the native version, where I used Raku the way I understand it is supposed to be used, and with the benefit of more than a day's experimenting, tweaking the code, and trying to understand what was going on, produced a timing of 163.42 microseconds per iteration, which is five times slower than Perl and two hundred and six times slower than C. And the minimal port, representative of what you get if you take an existing Perl program performing numerical calculations and migrate it to Raku by simply fixing the changes in language? It runs at a rate of 584.6 microseconds per iteration, which is eighteen times slower than Perl and seven hundred and thirty-five times slower than C.

What is going on here? First of all, I suspect that with development of a compiler and support libraries to support such an ambitious and, until recently, rapidly evolving language, priority has rightly been given to a complete and correct implementation of the language specification rather than optimisation. This is to be expected, and performance should improve over time, especially since language features in Raku such as strong typing and immutable and private variables should permit compiler optimisation better than that of Perl, whose heritage was a typeless, interpreted language.

But, for numerical programming (which, to be fair, was never Perl's strong point or a major application area), Raku's type system is distinctly odd and full of pitfalls for the incautious programmer unaware of what is going on under the hood. Raku has base numeric types of Int (arbitrary precision integers), Rat (arbitrary precision rational numbers [fractions]), Num (IEEE 754 double precision floating point), and Complex (complex numbers made up of two Nums). These, in turn, form “roles” such as Real, which encompasses the Int, Rat, and Num types. Now, this seems eminently reasonable. But now consider the following innocent statement:

  my Num $f = 0;

which declares a floating point variable and sets it to zero. What happens? Why, you get a fatal error message because you've tried to initialise a variable of type Num to an Int value, the constant zero. All right, you say, this seems a bit reminiscent of 1950s programming languages where every floating point number had to have a decimal point or an exponent, so you replace “0” with “0.0” and try again. (At least you don't have to repunch the card and hand your deck in across the counter then wait six hours to see what happens.) And the result is…blooie!—now you've tried to assign a Rat (rational number) to a Num, because everybody knows that “0.0” is just shorthand for “0/10” a rational number if anybody's ever seen one. The only way to get this statement past the compiler is to write the right hand side as “0e0” or “0.0e0”, which it deems to be a Num, or else explicitly convert the type with 0.Num or Num(0).

This may seem to be runaway pedantry which will probably get fixed in a future release, but it's actually more pernicious than you might think. Suppose you declare all of your floating point variables as Real, which encompasses all the (non-complex) numeric types. Now you can assign integers, decimal numbers, and floating point numbers with exponents to them without error. But if you assign a value like, say, 5895.944 (the wavelength, in angstroms, of the “D” spectral line used in evaluating optical designs) to your variable, it takes on a type of Rat, and calculations with it will be performed in library-implemented rational arithmetic, which is much slower than hardware floating point. And when you have a mixed-type expression involving a Num, it has to promote the value from rational to floating point, another slow operation. Note that this will happen if you so much as use a decimal constant in an expression involving floating point values. If you fail to tack an exponent onto it, everything slows down like molasses in mid-winter. Before I figured this out and explicitly typed all of the constants in my program, the “native” version ran more than three times slower than the results I report here.

A suitably smart compiler should be able to analyse the code and do much of this conversion at compile time, but the existence of polymorphic types such as Real may render this impossible in some cases. In any case, a programming language which requires such extreme fussiness to avoid painful and non-obvious speed penalties will have a steep hill to climb in competition with others that impose no such burden on their users.

The relative performance of the various language implementations (with C taken as 1) is as follows. All language implementations of the benchmark listed below produced identical results to the last (11th) decimal place. In the table below, I show Perl as 23.6 times slower than C, not the 40.46 times I measured as a part of these tests. I suspect this is due to the value in the table being measured on a 32 bit machine where the advantage of C-generated machine code is less than the 64 bit machine on which I ran this test.

Language Relative
C 1 GCC 3.2.3 -O3, Linux
JavaScript 0.372
Mozilla Firefox 55.0.2, Linux
Safari 11.0, MacOS X
Brave 0.18.36, Linux
Google Chrome 61.0.3163.91, Linux
Chromium 60.0.3112.113, Linux
Node.js v6.11.3, Linux
Chapel 0.528
Chapel 1.16.0, -fast, Linux
Parallel, 64 threads
Visual Basic .NET 0.866 All optimisations, Windows XP
C++ 0.939
G++ 5.4.0, -O3, Linux, double
long double (80 bit)
__float128 (128 bit)
MPFR (128 bit)
MPFR (512 bit)
Modula-2 0.941 GNU Modula-2 gm2-1.6.4 -O3, Linux
FORTRAN 1.008 GNU Fortran (g77) 3.2.3 -O3, Linux
Pascal 1.027
Free Pascal 2.2.0 -O3, Linux
GNU Pascal 2.1 (GCC 2.95.2) -O3, Linux
Swift 1.054 Swift 3.0.1, -O, Linux
Rust 1.077 Rust 0.13.0, --release, Linux
Java 1.121 Sun JDK 1.5.0_04-b05, Linux
Visual Basic 6 1.132 All optimisations, Windows XP
Haskell 1.223 GHC 7.4.1-O2 -funbox-strict-fields, Linux
Scala 1.263 Scala 2.12.3, OpenJDK 9, Linux
FreeBASIC 1.306 FreeBASIC 1.05.0, Linux
Ada 1.401 GNAT/GCC 3.4.4 -O3, Linux
Go 1.481 Go version go1.1.1 linux/amd64, Linux
Julia 1.501 Julia version 0.6.1 64-bit -O2 --check-bounds=no, Linux
Simula 2.099 GNU Cim 5.1, GCC 4.8.1 -O2, Linux
Lua 2.515
LuaJIT 2.0.3, Linux
Lua 5.2.3, Linux
Python 2.633
PyPy 2.2.1 (Python 2.7.3), Linux
Python 2.7.6, Linux
Erlang 3.663
Erlang/OTP 17, emulator 6.0, HiPE [native, {hipe, [o3]}]
Byte code (BEAM), Linux
ALGOL 60 3.951 MARST 2.7, GCC 4.8.1 -O3, Linux
PHP 5.033 PHP (cli) 7.0.22, Linux
PL/I 5.667 Iron Spring PL/I 0.9.9b beta, Linux
Lisp 7.41
GNU Common Lisp 2.6.7, Compiled, Linux
GNU Common Lisp 2.6.7, Interpreted
Smalltalk 7.59 GNU Smalltalk 2.3.5, Linux
Ruby 7.832 Ruby 2.4.2p198, Linux
Forth 9.92 Gforth 0.7.0, Linux
Prolog 11.72
SWI-Prolog 7.6.0-rc2, Linux
GNU Prolog 1.4.4, Linux, (limited iterations)
COBOL 12.5
Micro Focus Visual COBOL 2010, Windows 7
Fixed decimal instead of computational-2
Algol 68 15.2 Algol 68 Genie 2.4.1 -O3, Linux
Perl 23.6 Perl v5.8.0, Linux
BASICA/GW-BASIC 53.42 Bas 2.4, Linux
QBasic 148.3 MS-DOS QBasic 1.1, Windows XP Console
Raku 205.6
Rakudo v2021.09/v6.d, Linux, object-oriented rewrite
Minimal port of Perl version
Mathematica 391.6 Mathematica, Raspberry Pi 3, Raspbian

Download floating point benchmark collection

Posted at 11:36 Permalink