Is there an open source Android keyboard that would support it? Everything I find is based on Whisper, which is from 2022. Ages ago given how fast AI is evolving.
I wish I had a Google Keyboard that could easily run on Whisper Medium. This is already great. But unfortunately would be too much inference cost, incredibly slow. The problem with Whisper is not the inference quality: medium and large are incredible. Is that the base model is not enough, and the only one with fast inference in mobile devices.
They are just shipping the same whisper-small that everyone else is using, and did not much to improve their models since release. Other models have been "coming soon" forever. https://keyboard.futo.org/voice-input-models
This is actually really good. I'm writing with it right now. It's just not the best setup as a keyboard. Because for example you cannot easily switch back to uh the normal keyboard with keys.
If you try profiling almost any program that does linear algebra (something that uses Numpy, for instance), you will see a lot of calls and CPU time in functions with names like DGETRF or SGESVX. These obscure names stand for stuff like Single-precision GEneral matrix Solve Vector eXtended; i.e., solve a linear system of equations with a full, dense matrix. Why are they so difficult to parse? Couldn't they come up with a friendlier name?
They come from Lapack, the standard linear algebra foundation library, which is written in Fortran 77. That library was first written in 1992, when the Fortran 90 standard was still new and not supported everywhere, so they stuck with the earlier version. Lapack has become the standard library for dense non-parallel linear algebra; it is still maintained and updated, but the basic math algorithms haven't changed much, so there was no need to replace it entirely. Today there are also processor-specific libraries like MKL or Apple Accelerate, but they still all follow the same Lapack API.
When Fortran-77 was standardized, they decided to keep function names at most 6 letter long, to "ensure portability". I.e., they wanted to support certain compilers and architectures that were already considered old in 1977.
TL;DR: if you can't read easily those flame graphs today, it's because of backward compatibility with certain mainframes that probably date back to the late 1960s.
In particular, 6-letter long function names may have been convenient on mainframes that used 6-bit alphanumerics in 36-bit words, the 36-bits having been backward compatible with 10-decimal-digit electromechanical calculators.
EDIT: I had thought 10 digits of precision were required for certain calculations, but the WP article points out that they may have just corresponded to the operators having had 10 digits on 2 hands, in which case we're being backwards compatible with Hox genes, specifically Hoxd, and tetrapod pentadactyly is backwards compatible to hundreds of millions of years:
Had more to do with punch cards and flexowriter tapes and octal, which predates large word sizes or even mainframes. Note the following from the MIDAS macro assembler [0]
Fortran predates this and was a different lineage than IBM, but not how six char symbols were a request
> The MACRO language had been used on the TX-0 for some three years previous to the writing of MIDAS. Hence, MIDAS incorporates
most, of the features which have been requested by users of MACRO, such as more flexible macro Instructions, six character symbols and relocation.
Note that when porting b to the pdp-11, which was ascii vs the earlier FIODEC/flexowriter 6 bit paper tapes is why c case statements fall through, they used it to allow lower case commands in ed as an example.
Flexowriters are 1940s iirc, and TX-0 through the early pdps were octal so it makes sense to grow in multiples of the 3.3 bit lines of paper tape
Also note you can count to 12 on one hand and 60 with the other. That is why the ancient Sumerians used it. Base 10 was added to Roman abacus but they still kept the uncia (12) for some functions.
IIRC that wasn’t droop until the renaissance when they read Archimedes attempt to calculate the number of grains of sand needed to fill the universe with grains of sand, he used decimal and they asserted it was superior.
At my first job circa 1990, our codebase was constrained to 6-character function names in the core libraries, which had to run on many platforms including mainframes. If I recall correctly, you could have longer names, but only the first 6 characters were significant to the linker.
Never thought about why that might be other than "yeah, memory is expensive".
That is correct, I did not mention Linpack. It had different function names than Lapack though (while the naming scheme was similar, and still constrained to 6 letters); for instance DGETRF was named DGEFA in Linpack. [1]
Yes. Lapack was the successor to linpack and I seem to recall some of the linpack routines going back much further than the eighties. MATLAB (which existed before the commercial release in 1984) was built on linpack.
Cue obligatory reference to the programmer archaeologists in Vernor Vinge's novel A Deepness in the Sky. Their job, on starships, is to safely bodge the multiple strata of software that have accreted since Mankind left Earth, centuries before.
It's because Signal has some unhealthy obsession with "security" and does not want to recipient of the communication to ever be able to export messages in plain text.
reply