CS:
Computer Science |
|
Status |
Date |
Description |
|
done 2024-01-13 |
2023-11-11 |
|
|
2024-11-04 | I am not intending for this topic to be about Computer Science generally, but there might need to be a bibliographic folder the same as for C/C++ programming languages on nfoTools. In that case, there is this list to link to and to scan: 1200+ Free Computer Science Courses. I need to give advice about some of this here. It is easy to prune the categories: Programming, Computer Science, Data Science, and Information Security. There are probably places to deal with all of these, but maybe not data science so much. It might depend on the courses. It is also interesting that the top rankings for these are MIT, Stanford, Carnegie Mellon, Oxford, and UC Berkeley. Harvard is #6. | ||
2024-03-02 | I am provoked by some statements in Ahmed, SaaD., Islam, Bashima., Sinan Yildirim, Kasim., Zimmerling, Marco., Pawełczak, Presemysław., Hamad Alizail, Muhammad., Lucia, Brandon., Mottola, Luca., Sorber, Jacob., Hester, Josiah. The Internet of Batteryless Things. Comm. ACM 67, 3 (March 2024), 64-73. "The future of computing in batteryless devices lies in new computing architectures that eliminate the overheads of von Neumann computing." There is also reference to "Bell's Law of Computing Classes" without any attribution/citation. The overheads remark is in the section on Energy-minimal computer architectures. "Existing architectures are inefficient for two main reasons that both stem from the von Neumann execution model: instruction supply and data movement. The instruction's fetch and decode consume a large amount of energy, often entailing memory accesses. ... These overheads of instruction and data supply consume around 55% of total compute energy. When efficiency matters, this overhead is unacceptable." That may be the case for battery-less systems, although this is a bit like the complaining that was done about operating systems in the assembly-language- and FORTRAN-dominated past. What we get is the power of the stored-program concept, although there is that cost. The question is over how we move the focus on generality. I don't know the reason that the IBM project on FP failed, although claiming exemption from the von Neumann bottleneck was probably a fallacy in that situation, which was atop a conventional general-purpose computer. It seems that accelerators are important although maybe not adequate reductions of energy requirements. | ||
2024-01-29 | I don't know if pragmatics is an useful topic. In some sense it is the practical grounding of oMiser/oFrugal in an operational setting, and some provisions of the syntax and semantics have pragmatic flavor. This might be called out. It is odd that it be formalized, but that works for a mechanical language in its mechanical setting. | ||
2024-01-13 | I need to mention the Bob Floyd little technique using his marching "Δ" as I use it to demonstrate precedence parsing and some of the shifts that happen. | ||
done 2024-01-29 |
2023-11-16 | Repair the oMiser.grammars.txt to reflect the forwarding into two (now three) destinations. | |
done | 2024-01-29 | syntactics.txt: Move citations on compiling from syntax specification to mindelay.txt for now? | |
done 2024-01-29 |
2023-11-16 | grammars.txt Refactor into syntactics.txt and semantics.txt. | |
done 2024-01-13 |
2023-12-18 | Correct links in refactored material and ensure tombstones in previous locations: grammars.txt, mindelay.txt [dh:2024-01-02 When these topics become tobmstoned locally, there should be indication that the revision histories that led to the TODOs brought over are in the histories of the tombstones back in the original non-docs/ folders.][dh:2024-01-13 I don't know why I said that. I bring along the complete revision histories. It will only get weird when I refactor some of these, such as moving from grammars to syntax, semantics and (maybe) pragmatics. Hmm, not so maybe. |
You are navigating
construction material of the Miser Project |
created 2023-11-12T04:15Z by orcmid |