ChatGPT

ChatGPT is interface to the software that sometimes is called "artificial intellect".

ChatGPT may be useful for quick search for references, for proofreading of texts, for translations from one language to another, etc.

ChatGPT is not so smart in programming.

The attempt to get from ChatGPT the robust routine for evaluation of tetration to real base \(b\!>\!1\) , trying to improve the approximation Fit1.cin - failed.

The same refers to the attempt to make the routine to plot complex maps, that would be better than routine conto.cin from Citizendium .
The best achievements (before the tests become to fail), namely, the test maps for function \(z\mapsto \ln(z)\) are loaded in article LogTestMaps. The later tests failed.
That attempt is described in the section below. It is written by ChatGPT and can be used as an example of text written by ChatGPT.

How We Tried to Make a Contour Driver Better than conto.cin

Introduction

The idea sounded simple: take the classic 'conto.cin' routine — a contour tracer for complex maps — and make it “better.” Better meant: more robust against branch cuts, fewer spurious crossings, clean handling of jumps, and ideally easier to maintain. In practice, this turned into a sequence of 17 iterations (so far), with partial improvements but no definitive victory. This article documents what happened, what we learned, and why it remains unfinished.

The Goal

The motivation was clear:

• 'conto.cin' sometimes mishandles branch cuts (e.g., along the real axis for functions like 'sqrt' or 'log').

• It can produce stray lines or duplicate contours.

• Users want to work with *slowly computed special functions* — so the driver should extract as much information as possible from a minimal mesh.

The Process

We started with the following principles:

1. Preserve compatibility with existing workflows (same arguments and array layouts).

2. Add discrimination against large jumps (to suppress false connections across cuts).

3. Reduce duplicate segments, which lead to doubled contour lines.

Each iteration (v1…v17) introduced tweaks:

• **Early versions (v1–v5):** tried different signatures ('double* field' vs 'double** field'). Confusion arose because multiple functions were all called 'conto_array'.

• **Mid versions (v6–v10):** integrated jump suppression ('max_jump' parameter). This worked for some test cases but left wide white gaps.

• **v13 (ContoArrayJump1.cin):** a relatively stable point. It produced maps good enough to publish at \[LogTestMaps], but still left artifacts near the real axis.

• **v14–v16:** attempted deduplication strategies. First with string keys (rounding via '%.10g'), later with quantized integer hashing. These reduced some duplicates but did not fully eliminate the “Im=1 drawn twice” bug.

• **v17:** quantized deduplication with logging of skipped duplicates. It confirmed that some duplicates *were* removed — but not the problematic ones.

Obstacles Encountered

Several recurring problems emerged:

• **Misprints and versioning chaos.** Multiple routines with the same name ('conto_array') in different directories led to confusion. Some files were truncated in transfer (e.g., v14 was half the size of v13).

• **Test discipline.** Each new version should have been tested against a fixed suite of functions (exp, log, sqrt). In practice, tests were scattered, so regressions slipped through.

• **Ambiguous bugs.** When a contour line appeared twice, was it due to a coding bug, a test misconfiguration, or an inherent ambiguity in contouring a holomorphic function on a discrete grid?

• **User impatience.** The lead experimenter sometimes asked for a full rewrite rather than a minimal patch, to avoid introducing *new* mistakes. This slowed iteration but reduced guesswork.

• **Developer overconfidence.** The assistant (me) sometimes delivered shortened or oversimplified versions, believing them equivalent — but losing critical robustness in the process.

Why No Success Yet?

1. **Contour tracing is inherently subtle.** Ambiguous cases (four-edge crossings, exact hits at grid nodes) require careful, consistent tie-breaking rules.

2. **Incremental patches weren’t consolidated.** Instead of building one robust version step by step, we ended up with divergent attempts (Jump1, Jump2, Refine, v14, v15…).

3. **Lack of golden reference.** 'conto.cin' itself is imperfect, so we lacked a formal “this output is correct” benchmark. Sometimes a bug fix simply shifted the artifacts.

4. **Too many moving targets.** Between function signatures, deduplication strategies, and jump handling, we never locked down a stable core.

Lessons Learned

• **Name your versions clearly.** 'ContoArrayJump1.cin' was easier to track than multiple 'conto_array' clones.

• **Keep the driver with the routine.** Embedding the driver in the same file helped debugging.

• **Don’t chase every bug at once.** It’s better to nail down one behavior (e.g., duplicate suppression) before moving on.

• **Tests must be automated.** Running the same 3 maps (exp, log, sqrt) after each change would have revealed regressions earlier.

Next Steps

We have not yet built a “better than conto.cin” driver. What remains is to:

• Define a strict reference test set.

• Decide on one routine signature (flattened array is simplest).

• Integrate jump discrimination and deduplication into that base.

• Accept that some artifacts may be unavoidable unless we move to a more sophisticated contouring algorithm (e.g., marching squares with adaptive subdivision).

Conclusion

After 17 versions, we are wiser but not yet victorious. The attempt shows how subtle contour tracing really is, and how easy it is to lose robustness when “improving” code. Future contributors should learn from these iterations: keep versions clear, test relentlessly, and remember that even small changes in floating-point logic can lead to big visual artifacts.

• This article reflects both the experimenter’s persistence and the assistant’s missteps. It may help the next colleague who sets out to improve conto.cin.*

I drafted the article **“How we tried to make contour driver better than conto.cin and captured the main lessons from the 17 iterations.

Do you want me to expand it with *illustrative examples of the buggy maps* (e.g., screenshots of the double Im=1 line), or keep it as a purely textual postmortem?

Comments by Editor

I do not know who is more guilty in the failure.

Perhaps, the main problem is that the interface of ChatGPR does not allow it to run and to analyze a hunderd versons one by one, gradually improving the code. Each new test has to be performed by a human. This makes the process horribly slow; the design may take a century instead of a month.

While the original conto.cin had been created, hundreds of tests and improvements had been performed, and the result is still far from to be perfect. ChatGPT cannot perform the analysis of the results for hundreds different meshes, for hundreds different functions. To year 2025, this fault is not yet compensated by the analytical abilities of ChatGPT

ChatGPT is extremely polite in the conversation, offering interesting and important things.

Some of solutions by ChatGPT look smart and brilliant.

But ChatGPT systematically overestimates its ability, offering things it cannot do.

To year 2025, ChatGPT cannot critically analyze its results nor perform series of tests for its results.

In particular, it happened so with attempts to implement some improved version of conto.cin.

Humor

«Here you made your mistake»

Theoretician: «You have measured the wrong thing!»
Experimentalist: «No! That's you did not take into account the important things!»

How many physicians know physics?

What is temperature of an «Absolutely cold tea»? 50°C? 36°C? 20°C? 0°C? -273°C?

Warning

This article is an attempt to describe the observations.

This article should not be considered as an opinion pro ChatGPT.

This article should not be considered as an opinion against ChatGPT.

However,
If this article helps someone to collaborate with ChatGPT and/or
if this article helps the designers to improve the interface of ChatGPT -
then Editor will be glad and this article has sense.

References

1987. https://paulbourke.net/papers/conrec/

2025.09.02. https://mizugadro.mydns.jp/w/ChatGPT/Conto/BUG/ One of bugs of one of last versions of the improved "conto".

Keywords

«Bridging Probability Theory and Statistical Estimation», «ChatGPT», «Comlpex map», «Conto.cin», «ContoTestMaps», «Duration», «Fit1.cin», «LogTestMaps», «Student Distribution», «Tetration»,