Unsupported operand type(s) for +: 'DatetimeArray' and 'str' in M2_UGL_1

[pugach]

M2 Agentic AI - Chart Generation throws the following error when running the complete workflow:

Further investigation has shown that the issue is somehow connected with the name of the image. If the name of the image is “chart_v1.png” the code works, but for any other name I tried it fails with the same error.

# Generate initial code
code_v1 = generate_chart_code(
    instruction="Create a plot comparing Q1 coffee sales in 2024 and 2025 using the data in coffee_sales.csv.", 
    model="gpt-4o-mini", 
    out_path_v1="my_chart_v1.png"  # works with chart_v1.png
)

utils.print_html(code_v1, title="LLM output with first draft code") 

# Get the code within the <execute_python> tags
match = re.search(r"<execute_python>([\s\S]*?)</execute_python>", code_v1)
if match:
    initial_code = match.group(1).strip()
    utils.print_html(initial_code, title="Extracted Code to Execute")
    exec_globals = {"df": df}
    exec(initial_code, exec_globals)

[Deepti_Prasad]

improvise your prompt to instructions like kindly avoid using any operand related concern or something similar, so the agent generated codes don’t conflict with metadata data type

[pugach]

Ok, but why does it have to do with the name of the image? As I said before, it ALWAYS works for chart_v1.png, but NEVER works with other image names.

[Deepti_Prasad]

it is not about the next chart, but reflect creates a execution code, when this conflict happens, so make sure in the reflection part, mention in prompt what to avoid especially with the error you are encountering.

This was reported by learners and this is what was suggested by staff.

[pugach]

The error does not seem to be related to the reflection code. While experimenting I tried commenting out reflection calls. The error is thrown in the generation code. It is also thrown in the sample code for generating code in the beginning of the lab if you change the name from chart_v1.png to something else. Try it and you will see what I mean.

[Deepti_Prasad]

yes for the generation code, even I had got.

change original prompt,

add this

Avoid any operand types related error.

Code Error caused by defined image_name in M2_UGL_1

Hi haohao, Thanks for reporting this. I got the same error using the original prompt. After I added “Check operand types carefully to avoid errors” everything worked well. Comes to show that intelligence can be rather interactive…

[pugach]

@Deepti_Prasad

Avoid any operand types related error.

Adding this to the prompt sort of helps. At least, the sample code works with an arbitrary chart name. But the complete workflow still throws an error unless I change the base image name from ‘drink_sales’ to something else (e.g. ‘my_drink_sales’ worked). It remains unclear to me how and why the choice of the image name relates to the operand type error.

[Deepti_Prasad]

let me check the metadata and get back to you, on why changing base image name, made the difference.

@pugach

can you share screenshot of the error you got after adding the statement and yet you encountered the error. I need to look for comparison

[Deepti_Prasad]

hey @pugach

it is given in the assignment instructions why file name need to be changed everytime you run the workflow again

Regards

Deepti

[pugach]

As far as I understand that point, the reason to give it a different name each time is simply to avoid previous data from being overwritten, but it should not affect correctness of the code. In fact, code correctness obviously depends on the name.

BTW, now the lab seems to work differently. It throws no errors if I run it as is. It also works fine for some other image_basename’s, e.g. ‘drink_sales_1’, but when I change it to ‘my_drink_sales’ or ‘drink_sales_12’ it throws the same error (see the screenshot attached).

[Deepti_Prasad]

can you paste the complete error here,

I am trying to find a solution for this error from my end as a learning curve.

the conflict is because of datetime64/timedelta64 operand conflicting with arthimatic operations.

notice the error has one thing common whenever the operand has timedelta64 dtype, this error is being thrown. So this needs to be addressed as far as I feel.

[pugach]

The complete trace for the error when running the complete workflow with image_basename set to “my_drink_sales” goes below.

# Here, insert your updates
user_instructions="Create a plot comparing Q1 coffee sales in 2024 and 2025 using the data in coffee_sales.csv." # write your instruction here
generation_model="gpt-4o-mini"
reflection_model="o4-mini"
image_basename="my_drink_sales"

# Run the complete agentic workflow
_ = run_workflow(
    dataset_path="coffee_sales.csv",
    user_instructions=user_instructions,
    generation_model=generation_model,
    reflection_model=reflection_model,
    image_basename=image_basename
)

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[10], line 8
      5 image_basename="my_drink_sales"
      7 # Run the complete agentic workflow
----> 8 _ = run_workflow(
      9     dataset_path="coffee_sales.csv",
     10     user_instructions=user_instructions,
     11     generation_model=generation_model,
     12     reflection_model=reflection_model,
     13     image_basename=image_basename
     14 )

Cell In[9], line 41, in run_workflow(dataset_path, user_instructions, generation_model, reflection_model, image_basename)
     39     initial_code = match.group(1).strip()
     40     exec_globals = {"df": df}
---> 41     exec(initial_code, exec_globals)
     42 utils.print_html(out_v1, is_image=True, title="Generated Chart (V1)")
     44 # 3) Reflect on V1 (image + original code) to get feedback and refined code (V2)

File <string>:5

File /usr/local/lib/python3.11/site-packages/pandas/core/ops/common.py:76, in _unpack_zerodim_and_defer.<locals>.new_method(self, other)
     72             return NotImplemented
     74 other = item_from_zerodim(other)
---> 76 return method(self, other)

File /usr/local/lib/python3.11/site-packages/pandas/core/arraylike.py:186, in OpsMixin.__add__(self, other)
     98 @unpack_zerodim_and_defer("__add__")
     99 def __add__(self, other):
    100     """
    101     Get Addition of DataFrame and other, column-wise.
    102 
   (...)
    184     moose     3.0     NaN
    185     """
--> 186     return self._arith_method(other, operator.add)

File /usr/local/lib/python3.11/site-packages/pandas/core/series.py:6154, in Series._arith_method(self, other, op)
   6152 def _arith_method(self, other, op):
   6153     self, other = self._align_for_op(other)
-> 6154     return base.IndexOpsMixin._arith_method(self, other, op)

File /usr/local/lib/python3.11/site-packages/pandas/core/base.py:1391, in IndexOpsMixin._arith_method(self, other, op)
   1388     rvalues = np.arange(rvalues.start, rvalues.stop, rvalues.step)
   1390 with np.errstate(all="ignore"):
-> 1391     result = ops.arithmetic_op(lvalues, rvalues, op)
   1393 return self._construct_result(result, name=res_name)

File /usr/local/lib/python3.11/site-packages/pandas/core/ops/array_ops.py:273, in arithmetic_op(left, right, op)
    260 # NB: We assume that extract_array and ensure_wrapped_if_datetimelike
    261 #  have already been called on `left` and `right`,
    262 #  and `maybe_prepare_scalar_for_op` has already been called on `right`
    263 # We need to special-case datetime64/timedelta64 dtypes (e.g. because numpy
    264 # casts integer dtypes to timedelta64 when operating with timedelta64 - GH#22390)
    266 if (
    267     should_extension_dispatch(left, right)
    268     or isinstance(right, (Timedelta, BaseOffset, Timestamp))
   (...)
    271     # Timedelta/Timestamp and other custom scalars are included in the check
    272     # because numexpr will fail on it, see GH#31457
--> 273     res_values = op(left, right)
    274 else:
    275     # TODO we should handle EAs consistently and move this check before the if/else
    276     # (https://github.com/pandas-dev/pandas/issues/41165)
    277     # error: Argument 2 to "_bool_arith_check" has incompatible type
    278     # "Union[ExtensionArray, ndarray[Any, Any]]"; expected "ndarray[Any, Any]"
    279     _bool_arith_check(op, left, right)  # type: ignore[arg-type]

TypeError: unsupported operand type(s) for +: 'DatetimeArray' and 'str'

In contrast, the following code, which differs only by image_basename set to “your_drink_sales”, runs without errors.

# Here, insert your updates
user_instructions="Create a plot comparing Q1 coffee sales in 2024 and 2025 using the data in coffee_sales.csv." # write your instruction here
generation_model="gpt-4o-mini"
reflection_model="o4-mini"
image_basename="your_drink_sales"

# Run the complete agentic workflow
_ = run_workflow(
    dataset_path="coffee_sales.csv",
    user_instructions=user_instructions,
    generation_model=generation_model,
    reflection_model=reflection_model,
    image_basename=image_basename
)

Do you observe the same behavior on your side?

[Deepti_Prasad]

yes, thank you for working and reflecting on this.

actually this was a known reported error, but none try to resolve or reflect why base image name make difference in the arthimatic operation error related! to date and time datatype.

let me cross check with my error, and see if I can find solution or atleast a reasoning relative to base image name and workflow.

just to make it clear, I am not staff and only volunteer mentor addressing learner’s query. So if you want me to report this query to staff, i will do that. as earlier reporting of the same error was responded back to change name and prompt instructions for successful run of the workflow codes.

So according to staff this error is more of LLM’s limitations which I understand as llms have randomisation w.r.t. token response and the output can be variable depending on many factor like temperature, top-P, top-k, system prompts and context. So when one changes a name of any base input/image, and wants to retry again, one neeed to make sure to clear out the kernel output, then re-run the codes when changing the base image name. So just. making sure when you encountered error with drink_sales_12, did you first clear the kernel output and re-run cells from beginning???

[Deepti_Prasad]

@pugach

I just re-run m2_ugl1 lab codes I didn’t encounter any error, infact! I didn’t! even add any operand related error avoid instructions.

my code ran successfully with the original drink_sales name without any modification to the already given prompt.

Please make sure you have not by mistake edited or added anything from your side in this lab codes..

[pugach]

@Deepti_Prasad

So just. making sure when you encountered error with drink_sales_12, did you first clear the kernel output and re-run cells from beginning???

Yes, I have tried restarting the kernel, clearing output, and refreshing the page many times, but the behavior stays the same. That’s why I am less inclined to explain it by somewhat random nature of LLM outputs.

@Deepti_Prasad

I just re-run m2_ugl1 lab codes I didn’t encounter any error, infact! I didn’t! even add any operand related error avoid instructions.

my code ran successfully with the original drink_sales name without any modification to the already given prompt.

Yes, that’s what I observed and wrote about a couple of days ago. The last version of the lab worked fine as is, but still if you choose another image_basename the same error is thrown.

@Deepti_Prasad

So if you want me to report this query to staff, i will do that.

Sure, it should be investigated by the staff, because many people have the same issue, and changing the prompt seems to be only hiding the issue rather than solving it. By saying that I mean that even if you ask the model to avoid operand-type-related errors, it may work for some image name, but once you change it to a different one, things break again.

[reinoudbosch]

Hi pugach,

The first time I ran the code from a new notebook, I got the same error. So even with the original name for the image, it can run into this error. In my case, most subsequent runs worked, even with adjusted names for the image. So the code worked most of the time, but not always.

My interpretation is that it has something to do with the distribution of attention in the LLM while it handles the call. This is why adding something like ‘check carefully for operand errors’ may help, because it activates parameters in the model that increase attention values that support checking for operand errors.

In my view, the internal workings of LLMs are not very well understood, even if some AI researchers I know are specialized in that field. I would say this has something to do with the amount of engineering added to the original idea of attention.

This already started with the vanilla transformer. When you think about it, the title of the paper ‘Attention is all you need’ is a misnomer, as the vanilla transformer also includes embedding layers, positional encoding, feed forward layers, normalization, and residual connections in addition to attention (somehow distributed and synthesized with multiple heads). This makes the interpretation of attention values very difficult, in turn making it hard to understand how to direct and control attention in such a way that the LLM reliably provides the desired output.

Your question and comments are a case in point, and it is good that you bring this up because it deserves more (human) attention. Especially given the amount of (billions of dollar worth of) engineering rather than thorough conceptualization that is going on. Yann Le Cun’s call for more attention to conceptualization may be related to this.

So thanks for persisting with this issue as it raises an important point. Hopefully these kind of issues will be taken up more seriously by the AI community, leading to more attention being paid to conceptualization and subsequent re-engineering.

[Deepti_Prasad]

hi @pugach

So I did some digging from my side on why a particular change of image base name is causing this str type error related to error.

The first suggestion given was changed the dataframe datatype to .astype(str), so the base name datatype doesn’t conflict with the operand type error.

Unfortunately I still encounter the same error which you encountered with base name being “my_drink_sales”

So my next checkpoint was to dig in util.py file where I found

So, the code attempts to concatenate the date column (already converted to datetime objects in a previous step or assuming improper format) with a string, or because df['date'] and df['time'] are not string type before processing.

To fix this, we need to make sure both columns are strings before combining them, or parse them separately if they already exist as components.

Something like this in the metadata file

import pandas as pd
import matplotlib.pyplot as plt

# Ensure columns are strings before concatenation
df['combined_dt'] = df['date'].astype(str) + ' ' + df['time'].astype(str)
df['datetime'] = pd.to_datetime(df['combined_dt'])
df['year'] = df['datetime'].dt.year

# Filter data for Q1 2024 and 2025
q1_sales = df[(df['quarter'] == 1) & (df['year'].isin([2024, 2025]))]

# Group by year and coffee_name, then sum prices
sales_summary = q1_sales.groupby(['year', 'coffee_name'])['price'].sum().unstack(fill_value=0)

Then use further to execute the codes.

I will share this post with staff, see if they can resolve this image base name conflict.

Thank you again for informing and reflecting on this @pugach

Regards

Dr. Deepti

[reinoudbosch]

Interestingly, the LLM usually manages to resolve this issue when it is called.

This brings up the question why attention to defensive coding is usually triggered but not always. One solution could be to add something like ‘please code defensively’ to the prompt.

[Carlos_A_Lang-Sanou]

SOLVED

I have found that the error is caused in the second of these lines in the code generated for code_v1:

# Filter the data for Q1 of the years 2024 and 2025
df[‘date’] = pd.to_datetime(df[‘date’] + ’ ’ + df[‘time’])

due to trying to apply + to a datetime and a string.

I tried to catch this error as part of the execution of run_workflow and apply variations on the instructions for code inspection, to be used when the code fails and does not generate any chart, but found it difficult to do without a mayor overhaul to the set of functions in the notebook, so I quit early.

Lesson I learned: we need to also plan for how to deal with generated code that fails, as part of the reflexion exercise. OR modify the instructions to the first model, so that it somehow tests the generated code and verifies it runs or infers it will run (if static checks are used) before producing its result.

I finally, most easily fixed the issue by adding these instructions at the end of internal instructions for `generate_chart_code`

Generated code must be verified using
- py_compile
- pylint
- mypy

This totally removed the wrong statement from first draft code (V1), while still producing (the generated code) a chart with aspects to improve.

[Deepti_Prasad]

hi @pugach

one of my colleague @nramon has come with the resolution of your problem. Sharing what he mentioned

To fix it I changed the prompt in generate_chart_code from:

The code should create a visualization from a DataFrame 'df' with these columns:
- date (M/D/YY)
- time (HH:MM)
- cash_type (card or cash)
- card (string)
- price (number)
- coffee_name (string)
- quarter (1-4)
- month (1-12)
- year (YYYY)

To:

The code should create a visualization from a DataFrame 'df' with these columns:
{df.dtypes.to_string()}

The same can be done in reflect_on_image_and_regenerate

Getting it to work with gpt-3.5-turbo requires a more detailed prompt.

Let us know if that helps resolve the change in name for base model concern too.

Regards

Dr. Deepti