Has anyone tested the approach described in this post of creating a vector of letter counts rather than sorting?

I tried that approach with 8th to generate map keys instead of sorting word alphabets. It ran about the same speed as my original version. I got a little help from the 8th forums and version below is currently the fastest version for 8th:

That's nicely faster than the Perl code and in many ways more readable.

I wonder whether C++ with sort templates would generate less greenhouse gases than the C programs. Although compiling might destroy a rainforest or two, the loss would quickly be compensated by a billion people using the resulting binary to improve their bananagrams.

Along different lines, do you think it might be possible to find anagrams in the insane British dictionary using interpreted Basic? Since no compiling would be needed, no rainforests would be harmed.

...do you think it might be possible to find anagrams in the insane British dictionary using interpreted Basic? Since no compiling would be needed, no rainforests would be harmed.

Yes, the rain forests would be safe from compilation. And I'm sure interpreted BASICs could get the job done eventually. But I think of it like this:

Imagine a world where all the factories, boats, trains and cars were still powered by steam engines burning lot's of lovely black coal. Houses, shops, factories, streets and roads were still lit by gas. Homes and all were heated by coal burning fires.

All of that was perhaps acceptable when we knew no better, the industrialized population was very small and the total population of the planet was much less and living in poverty.

That is what it would be like if everyone used BASIC today.

People miss BASIC like we miss the majesty of steam engines and I miss sitting by the heat and glow of a coal hearth. But it's just not acceptable at scale.

Yes, I will... I have watched online videos of lectures of under graduate courses in introductory CS from MIT and Berkeley. The oldest, and best, by Prof. Brian Harvey from Berkeley over 10 years ago.

These course covered introductory CS material including learning a programming language and moving on to data structures (lists, trees, etc) and various algorithms and algorithmic analysis etc. Over the years the language used has changed, even if the conceptual stuff remained the same. Brian Harvey originally used Scheme the last one I saw used a version of Scratch would you believe!

I was amazed to find that in the year they used Java the poor students were having a really hard time even programming simple things. Half way through the course they were still lecturing on how to program in Java. The actual CS material was way behind. Lost in the noise of all that language complexity.

Contrast to the Scheme version of the course where the language was pretty much done with after the first week and they moved on to to the interesting CS stuff immediately.

So yes, I blame Java.

I've been thinking about this anecdote since last year and have a different theory: Due to the demise of the golden age of personal computing as well as the steam engine, the students changed in a significant way over the observed time period.

Scheme was used for the earlier course because the instructor didn't want to bore students who were already expert Basic, Pascal and C programmers with something they already knew. Later such an assumption didn't hold, so the course changed to include a significant amount of introductory programming material. Not surprisingly, the poorly prepared students struggled anyway.

This highlights why reintroducing programming alongside reading, writing and arithmetic is important in primary and secondary school and the original problem the Raspberry Pi was designed to address.

as for python, below python is c & c++, and that can further hook that up to superpower cuda or opencl driven super computers
and that super computer can be the top tier national grid supercomputers
python normally for the 'front' layer so that you don't need to do all that hard work of the icing in c/c++
i.e. write code compile, problem debug with a debugger, edit compile again and run again.
with python it is just edit and run
this is especially so if you are meddling in 200 dimension tensors if 2D is x and y, 3D is x, y and z then 200 dimensions you would run out of alphabets and tensors
but numpy and https://numpy.org/
the entire anaconda suite is made just to do that scientific computing (actually more than that)https://www.anaconda.com/distribution/
then you add googles tensorflowhttps://www.tensorflow.org/
and with sufficient enlightenment you may reach the nirvana of deep reinforcement convolution neural network machine learning
the machines trained with sufficient data comes alive and works like a *living thing* ! - the danger of the dark sidehttps://www.youtube.com/watch?v=-TTziY7EmUA

oh by the way would anyone explore the *dark side* and make an all powerful Raspberry pi 4 robot with machine vision i.e. cameras programmed with tensorflow and python and it figure how to walk all around your city? lol
it would scare the hell out of the city folks as if they has seen a ghost
this is no longer fiction as the learning can be simulated on a fast computer with a high powered gpu crunching away with petaflops of desktop computing power, then the trained simulated model loaded on a Rpi 4 robot and the whole thing comes alive

perl is a little different and it is invented initially as a 'sysadmin' language
it is ideal if you need to dice with text

c is pretty ok, until one day you visit a code that has a set of pointers to pointers to pointers to pointers to pointers and that they are void * pointers so that they can point to any structure or functions. c++ java & all that 'object oriented-ness' is supposed to try to suppress this demon of a cryptic web of pointers, i'm not too sure how far all that object oriented-ness has achieved that, but probably it helps one write tidier codes if one wants to

Last edited by ag123 on Fri Jul 19, 2019 4:45 pm, edited 4 times in total.

People miss BASIC like we miss the majesty of steam engines and I miss sitting by the heat and glow of a coal hearth. But it's just not acceptable at scale.

Basic was never meant to be majestic but rather as simple as possible while at the same time being all purpose. Note that in addition to being easy to learn, it was important for Basic to be easy to implement. This is because the original Dartmouth computer-literacy project specified that the undergraduate students also write the Basic compilers.

For majesty one should look to C++ and Java. After the digital apocalypse when all programs are written using deep-learning convolutional neural networks, the C++ and Java programming languages will replace the museum exhibits of ornate silver and porcelain tea sets which are presently used to demonstrate the rich excess of generations past.

Fortunately, we still have C, which retains much of the simplicity and efficiency of the original. If only it were as easy to learn as Python.

ejolson wrote:For majesty one should look to C++ and Java. After the digital apocalypse when all programs are written using deep-learning convolutional neural networks, the C++ and Java programming languages will replace the museum exhibits of ornate silver and porcelain tea sets which are presently used to demonstrate the rich excess of generations past.

For majesty there is no likes of BCPL, B, and C. The two you list are more of a worms nest (spegetti ball) than the worse of the stripped down MS-8KB BASIC program (even back then BASIC was a lot better than MS gave us, having parameterized subroutines with local veriables in the late 1970's [see Dartmouth BASIC (I think version 5 if I remember correctly)]).

Or see a good structured BASIC implementation, either MS-AmigaBASIC (many compilers available), BBC BASIC, or (pushing it here) Sinclair SuperBASIC.

RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

For saving electricity we could do a better balancing act than current compilers. Selective optimization, based on what is going to make the most difference. And have a means for the programmer to specify where extra optimizations should be used.

For the rest of the code just do some simple optimizations (simple register tracking for variables, constant expression elimination, case statement profiling for jump table, and inlining of very small functions).

In other words, normally do the level of optimization that can be done in even the simplest compilers, and reduce the compile run time. Then allow for extra optimizations to be applied only to portions of the code that it makes good since to so do with, as specified by the programmer.

This would make any language compiler better, save power in compiling (how many things does everyone still need to compile to use), as well as still saving power in execution.

RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Then allow for extra optimizations to be applied only to portions of the code that it makes good since to so do with, as specified by the programmer.

GCC can do that now. The programmer may specify that a function is either "hot" or "cold".
The branch prediction stuff for cold is interesting.

cold

The cold attribute on functions is used to inform the compiler that the function is unlikely to be executed. The function is optimized for size rather than speed and on many targets it is placed into a special subsection of the text section so all cold functions appear close together, improving code locality of non-cold parts of program. The paths leading to calls of cold functions within code are marked as unlikely by the branch prediction mechanism. It is thus useful to mark functions used to handle unlikely conditions, such as perror, as cold to improve optimization of hot functions that do call marked functions in rare occasions.

When profile feedback is available, via -fprofile-use, cold functions are automatically detected and this attribute is ignored.

hot

The hot attribute on a function is used to inform the compiler that the function is a hot spot of the compiled program. The function is optimized more aggressively and on many targets it is placed into a special subsection of the text section so all hot functions appear close together, improving locality.

When profile feedback is available, via -fprofile-use, hot functions are automatically detected and this attribute is ignored.

Then allow for extra optimizations to be applied only to portions of the code that it makes good since to so do with, as specified by the programmer.

GCC can do that now. The programmer may specify that a function is either "hot" or "cold".
The branch prediction stuff for cold is interesting.

Not quite what I am speaking of. I mean that the compiler runs a simple much faster parser for most of the code, only performing extra optimizations as specified (and only the extra optimizations specified), using a different parser if needed.

I know that some optimizations can only be done after the parser is done with it, hence the 'if needed' clause.

cold

The cold attribute on functions is used to inform the compiler that the function is unlikely to be executed. The function is optimized for size rather than speed and on many targets it is placed into a special subsection of the text section so all cold functions appear close together, improving code locality of non-cold parts of program. The paths leading to calls of cold functions within code are marked as unlikely by the branch prediction mechanism. It is thus useful to mark functions used to handle unlikely conditions, such as perror, as cold to improve optimization of hot functions that do call marked functions in rare occasions.

When profile feedback is available, via -fprofile-use, cold functions are automatically detected and this attribute is ignored.

hot

The hot attribute on a function is used to inform the compiler that the function is a hot spot of the compiled program. The function is optimized more aggressively and on many targets it is placed into a special subsection of the text section so all hot functions appear close together, improving locality.

When profile feedback is available, via -fprofile-use, hot functions are automatically detected and this attribute is ignored.

RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Then allow for extra optimizations to be applied only to portions of the code that it makes good since to so do with, as specified by the programmer.

GCC can do that now. The programmer may specify that a function is either "hot" or "cold".
The branch prediction stuff for cold is interesting.

Not quite what I am speaking of. I mean that the compiler runs a simple much faster parser for most of the code, only performing extra optimisations as specified (and only the extra optimizations specified), using a different parser if needed.

I know that some optimizations can only be done after the parser is done with it, hence the 'if needed' clause.

I don't know how other compilers work but for gcc the C front-end parsing phase is already simple and quick, it doesn't do any optimisations, those are mainly the domain of the middle-end, are language & processor independent and happen after all parsing has been done. The back-end then does final low-level optimisations before generating the processor-specific code.

Switching between multiple parsers mid-compile sounds like a good way to inadvertently end up with parsers that interpret the same code differently.

Basic was never meant to be majestic but rather as simple as possible while at the same time being all purpose. Note that in addition to being easy to learn, it was important for Basic to be easy to implement. This is because the original Dartmouth computer-literacy project specified that the undergraduate students also write the Basic compilers.

For majesty one should look to C++ and Java. After the digital apocalypse when all programs are written using deep-learning convolutional neural networks, the C++ and Java programming languages will replace the museum exhibits of ornate silver and porcelain tea sets which are presently used to demonstrate the rich excess of generations past.

Fortunately, we still have C, which retains much of the simplicity and efficiency of the original. If only it were as easy to learn as Python.

i like your snap
i've seen *real* codes e.g. open sourced etc that has c pointers to pointers (to pointers) and void * pointers funneled all over the place. it would take one enormous effort to figure out how pieces fit together. one can think of highly 'flexible' *plug-in* style modules and environments where the system is designed for one to plug one thing to another in a daisy chain or more elaborate setups, and that it handles data structures from anything to anything (any elaborate structures) (file systems?). the simplest pointers to pointers to pointers and void * pointers is a cascading set of call backs to call backs to callbacks that pass any structures to pointers to structures. Imagine a parser that can parse any possible language in the world and translate any language to any language. or in other cases like the high level declaration that an svg file, pdf document, cad document, msword document is a collection of arbitrary objects, fonts, text, etc, that become 'as generic as possible' and yet the codes need to deal with every different object at run time

i think to an extent java and c++ did not succeed in taming that real world affairs. i.e. it is really *natural*
anything that you want to be generic linked to generic linked to generic ended up with one doing cast to java.lang.object
voiding all that 'object oriented-ness' that's supposed to tame the pointers to pointers to pointers and void * pointers
(java & c++ has some sort of run time type identification though, all that *reflection (java)* and *RTTI (c++)* technology)
the fact that such projects exist shows where things are headedhttps://www.rttr.org/

but unfortunately the digital apocalypse using deep-learning convolutional neural networks is going to make things worst
how are you *ever* going to be able to debug a deep-learning convolutional neural network?
the whole nest possibly millions to billions of machine learned parameters are just arbitrary synapses in the artificial neurons
if it develop a bias i doubt any humanly efforts are going to be able to fix it

Last edited by ag123 on Sat Jul 20, 2019 8:28 am, edited 1 time in total.

The opposite of that is: Java, that's C++ without the ammunition and the smoking weapon.

You don't get the same level of opportunity to create pointer errors with Java because there's a single, clean, clearly defined interface for passing data between methods. With C++ you can turn everything into a blue screen of death with pointer abuse.

Now, lets guess what the language of choice was for the Windows kernel.

Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

The opposite of that is: Java, that's C++ without the ammunition and the smoking weapon.

You don't get the same level of opportunity to create pointer errors with Java because there's a single, clean, clearly defined interface for passing data between methods. With C++ you can turn everything into a blue screen of death with pointer abuse.

Now, lets guess what the language of choice was for the Windows kernel.

oh did ms somehow removed blue screens?
i'd guess these days with virtual memory, mmu, memory protection etc it simply crashed without warning
it burst just like a soap bubble - poof
lol

i'd guess the good o' parts of the windows kernel is still C
but lookout for thishttps://docs.microsoft.com/en-us/window ... df--driver
it is increasingly c++, and there are obvious reasons as like when java & c++ started - an attempt to limit the complexity of the *real world*

The opposite of that is: Java, that's C++ without the ammunition and the smoking weapon.

Take away the power and there is less chance people will hurt themselves or others.

I'm not sure I agree with the notion that Java is a kind of C++. Or perhaps we can say it is, like a plastic toy gun from Toys'R'Us sort of looks like a real one.

You don't get the same level of opportunity to create pointer errors with Java because there's a single, clean, clearly defined interface for passing data between methods. With C++ you can turn everything into a blue screen of death with pointer abuse.

Ugh? There are no pointers in the Java language.

It does have references, symbols that refer to objects. An entirely different thing. You can still cause program failure by using them incorrectly.

Now, lets guess what the language of choice was for the Windows kernel.

Probably because it's not actually possible to write an operating system kernel in Java. For that you need a real gun not a toy.

Or perhaps because Java did not exit when the Windows kernel was created. Windows: 1993, Java: 1996.

By the way, have you actually seen the source code of the Windows kernel? I suspect it's actually C. Or was when it was created. C++ was not a thing until 1998.

Am I showing a disdain for Java here? Absolutely. Java is the only major language we have that: Offers nothing new conceptually, was not created to solve any particular problem anyone had, has no reason to exist at all... Don't get me started on C#