Re: Including AI into Emacs

[Jean Louis <bugs@gnu.support>]

* Christopher Howard <christopher@librehacker.com> [2024-12-10 21:15]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Integration, if that is the right work, is enhancing the human
> > workflow to minimize efforts and provide optimum results. That is
> > what I mean.
> 
> That is not integration, that is optimization or
> efficiency. Integration may lead to better optimization or
> efficiency but it might have the opposite effect.

Sure optimization. Though I didn't express me well enough. I mean
connecting human methods of interactions with computer methods.

Integrating means making part of the whole. It is of course
optimization as well.

Examples of integration:

- program monitoring and making statistics of events in the house,
  acting upon events logically; if human turned on lights at specific
  time, lights will be turned on in future automatically; learning
  patterns; acting upon triggers; sensors detecting events such as
  movements, cleaning toilet, mopping the floor when nobody is at
  home, feeding pets, cutting grass, recognizing strangers at the
  gate;

- learning patterns of communication, rejecting nicely patterns not
  relevant, accepting relevant (higher level spam detection);
  answering common questions;

- understanding the agenda, the plan, reviewing automatically what was
  done, what not, making new agenda and plan based on previous one;
  printing it morning early in few copies, making it ready for human;

> > Programmers are not necessarily scientists, and so they think in terms
> > of typing. But it is possible to control light with brainwaves, with
> > special hat, or typing on computer with the eyeball movements.
> 
> None of those interface have any appeal to me at all. Well, okay,
> controlling light with brainwaves sounds interesting, at least. But
> even so I don't see how the input interface has anything to do with
> whether or not LLMs (or other AI approaches) should be integrated it
> our workflow. Unless an input interface is so compute intensive that
> it requires some kind of cluster-based neural network just to work
> at all.

We are already integrating, just it moves slow. The new LLM revolution
is making it possible for common man to create it easier, in much more
easier way than programming, it is higher level programming, the goal
we wanted to achieve back in time.

Look here what people are doing: https://websim.ai/

Computer development now moves inevitably into direction of complex
integrations.

> > Makers of LLMs now provided "trained" models  that
> > can type text, translate text more accurately then common translators. 
> 
> This sounds like an argument for using LLMs to do language
> translation, which I suppose must be acknowledged. Regarding prose:
> I've read the mind-numbing, generic prose output on the Internet
> that is now being spit out by LLMs, and I hope that goes away. The
> artwork generated is also terrible, which has been showing up on
> some of the cheap furnishing products we buy from China.

Yes, it works very well for translations.

- **Spanish:** Sí, funciona muy bien para traducciones.
- **French:** Oui, cela fonctionne très bien pour les traductions.
- **German:** Ja, es funktioniert sehr gut für Übersetzungen.
- **Chinese (Simplified):** 是的，它在翻译方面效果非常好。
- **Arabic:** نعم، إنه يعمل بشكل جيد جدًا للترجمات.
- **Russian:** Да, это очень хорошо работает для переводов.
- **Japanese:** はい、翻訳にとてもよく機能します。
- **Portuguese:** Sim, funciona muito bem para traduções.
- **Hindi:** हां, यह अनुवाद के लिए बहुत अच्छा काम करता है।
- **Italian:** Sì, funziona molto bene per le traduzioni.

Imagine. And I just said: translate in bullet list in 10 different
languages.

You can also say: make Emacs Lisp structure out of it:

Sure! Here is the translation of "Yes, it works very well for translations." in 10 different languages, formatted as an Emacs Lisp structure:

```emacs-lisp
'(("Spanish" . "Sí, funciona muy bien para traducciones.")
  ("French" . "Oui, cela fonctionne très bien pour les traductions.")
  ("German" . "Ja, es funktioniert sehr gut für Übersetzungen.")
  ("Chinese (Simplified)" . "是的，它在翻译方面效果非常好。")
  ("Arabic" . "نعم، إنه يعمل بشكل جيد جدًا للترجمات.")
  ("Russian" . "Да, это очень хорошо работает для переводов.")
  ("Japanese" . "はい、翻訳にとてもよく機能します。")
  ("Portuguese" . "Sim, funciona muito bem para traduções.")
  ("Hindi" . "हां, यह अनुवाद के लिए बहुत अच्छा काम करता है।")
  ("Italian" . "Sì, funziona molto bene per le traduzioni."))
```

Isn't that great? 

I have been wasting hours and hours looking into various structures
and making new Lisp structures to import data from other programs, now
I just insert sample data and get the Emacs Lisp program ready, often
almost ready for production.

> >> For activity (3), even I can do it without the help of remote
> >> compute cluster, it is going to require a large model database, plus
> >> intense computing resources, like a separate computer, or an expensive
> >> GPU requiring proprietary drivers.
> >
> > Here is example that works without GPU:
> > https://github.com/Mozilla-Ocho/llamafile/
> >
> > and other examples on same page. 
> 
> I don't see how a llama driven chat interface or an image generator
> is going to be useful to me, or worth the computing costs. But I
> suppose if something like that could be specialized to have expert
> knowledge of the libraries on my computer or my work flow, it might
> be worth playing around with.

- Website Revision System, sales and marketing:
 
  - Open Graph image related to page can be automatically generated,
    very useful in Internet marketing;

  - Correct titles, make them more appealing, describe the article,
    generate slugs;

  - By using list of links as memory, automatically link words in the
    article with relevant links;

  - Answer customers' questions, point out to articles, products,
    provide support;

- Family:

  - Generate daily routines for children; 

  - Generate planning, fun, entertainment;

- Programming:

  - Create templates, improve CSS, programming code;

  - Quickly find answers, debug; becoming rapid;

There is infinite list of uses.

> > Just as usual, you have got the computing cost, electricity and
> > computer wearing cost.
> 
> My understanding was, for LLMs, the difference involves orders of
> magnitude. That is what I hear others saying, at least.

As I said, there are LLMs working on computer without GPU:

GitHub - Mozilla-Ocho/llamafile: Distribute and run LLMs with a single file.:
https://github.com/Mozilla-Ocho/llamafile

It works on mine i5 CPU, though slow. We will see soon when I insert
Nvidia GPU how it will work. I am very satisfied with results.

It can describe the picture on my computer, which is a fantastic
feature! 📸 I can already envision indexing all my images. It's not
just about my personal life; I also have numerous pictures related to
courses and teaching others.

> Regarding inference engines, I recall with Prolog there is a lot of
> backtracking going on, so the essence of figuring out a workably
> efficient program was (1) coming up with intelligent rules, and (2)
> figuring out when to cut off the backtracking. I have a old Prolog
> book on my book shelf, but I haven't played around with Prolog at
> all for years

SWI-Prolog:
https://www.swi-prolog.org/

-- 
Jean Louis

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)