On Sun, Jun 14, 2020 at 2:44 PM Sebastian M. Ernst wrote:

I have overloaded the modulo operator in some test code and it actually helps a lot to make some logic more readable.

It would help a lot if you could show some examples.

https://en.wikipedia.org/wiki/List_of_mathematical_symbols#Symbols_based_on_... https://en.wikipedia.org/wiki/Tilde#As_a_relational_operator - https://patsy.readthedocs.io/en/latest/formulas.html https://patsy.readthedocs.io/en/latest/formulas.html https://docs.python.org/3/reference/expressions.html#index-61

The unary ~ (invert) operator yields the bitwise inversion of its integer argument. The bitwise inversion of x is defined as -(x+1). It only applies to integral numbers.

https://numpy.org/doc/stable/reference/generated/numpy.allclose.html

If the following equation is element-wise True, then allclose returns True.

absolute(a - b) <= (atol + rtol * absolute(b))

The above equation is not symmetric in a and b, so that allclose(a, b) might be different from allclose(b, a) in some rare cases.

The comparison of a and b uses standard broadcasting, which means that a and b need not have the same shape in order for allclose(a, b) to evaluate to True. The same is true for equal but not array_equal.

Presumably, tensor comparisons have different broadcasting rules but allclosr is similarly defined.

“Euclid’s first common notion is this,” says Lincoln in the film, “Things which are equal to the same thing are equal to each other. That’s a rule of mathematical reasoning. It’s true because it works. Has done and always will do. In his book, Euclid says this is ‘self-evident.’ You see, there it is, even in that 2,000-year-old book of mechanical law. It is a self-evident truth that things which are equal to the same thing are equal to each other.”

On Sun, Jun 14, 2020, 8:43 AM Sebastian M. Ernst wrote:

Hi all,

after just having typed tons of `math.isclose` (see PEP 485 [1]) and `numpy.isclose` calls (while basically using their default tolerances most of the time), I was wondering whether it makes sense to add a matching operator.

"Strict" equality check as usual: `a == b` "Approximate" equality check: -> `a ?= b` (similar to `!=`) -> `a ~= b` (my preference) -> `a === b` (just to confuse the JS crowd)

A corresponding method could for instance be named `__ic__` (Is Close), `__ae__` (Approximate Equal) or `__ce__` (Close Equal).

It's such a common problem when dealing with floating point numbers or similar data types (arrays of floats, float-based geometries etc). An operator of this kind would make many people's lives much easier, I bet. I have overloaded the modulo operator in some test code and it actually helps a lot to make some logic more readable.

Best regards, Sebastian

1: https://www.python.org/dev/peps/pep-0485/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KD45D5... Code of Conduct: http://python.org/psf/codeofconduct/

On 15/06/20 12:39 am, Sebastian M. Ernst wrote:

It's such a common problem when dealing with floating point numbers

Is it really? I've done quite a lot of work with floating point numbers, and I've very rarely needed to compare two of them for almost-equality. When I do, I always want to be in control of the tolerance rather than have a default tolerance provided for me. I'm inclined to suspect that if you think you need something like this, you're using an unreliable algorithm. -- Greg

On Sun, Jun 14, 2020, 10:22 AM Greg Ewing wrote:

On 15/06/20 12:39 am, Sebastian M. Ernst wrote:

...

It's such a common problem when dealing with floating point numbers

Is it really? I've done quite a lot of work with floating point numbers, and I've very rarely needed to compare two of them for almost-equality. When I do, I always want to be in control of the tolerance rather than have a default tolerance provided for me.

I've had occasion to use math.isclose(), np.isclose(), and np.allclose() quite often. And most of the time, the default tolerances are good enough for my purpose. Note that NumPy and math use different algorithms to define closeness, moreover. But it's more often than rare that I want to choose a different tolerance (or switch between absolute and relative tolerance). Adding an operator adds an impediment to refactoring to change tolerance. I'm more concerned about that problem than I am with the few extra characters needed to call a function.

On Sun, Jun 14, 2020 at 6:34 AM Wes Turner wrote:

https://docs.python.org/3/reference/expressions.html#index-61

...

The unary ~ (invert) operator yields the bitwise inversion of its integer argument. The bitwise inversion of x is defined as -(x+1). It only applies to integral numbers.

yes, the tilde would be good, but, well, is already a unary operator, not a binary one. And If we were to add a new operator, it should have the same precedence as == currently does, so we can't really re-use any others either. But ~= would read well for those of us accustomed it its use in math. Or, if ever Python goes to full on Unicode: ≈ https://numpy.org/doc/stable/reference/generated/numpy.allclose.html

...

The above equation is not symmetric in a and b, so that allclose(a, b) might be different from allclose(b, a) in some rare cases.

There are a number of issues with the numpy implementations, one of which is this. We really wouldn't want an asymmetric equality-like operator. But that's one reason why math.isclose doesn't use that same algorithm: it is symmetric. But that being said, I don't think this is a good idea, because of two issues: 1) as stated by Greg Ewing, if you are comparing floats, you really should be thinking about what tolerance makes sense in your use case. 2) Even more critical, isclose() has the absolute tolerance set to zero, so that nothing will compare as "close" to zero. So you can't really use it without thinking about what value makes sense in your use case. Both of which lead to a basic concept: there is no single definition of"close", and operators can only have a single definition. NOTE: A way to get around that would be to have a global setting for the tolerances, or a context manager: with close_tolerances(rel_tol=1e-12, abs_tol=1e-25): if something ~= something_else: do_something() but frankly, the overhead of writing the extra code overwhelms that hassle of writing is_close(). So: -1 from me. However, to Alex's point: if someone posts some motivating examples where the operator would really make the code more readable, *maybe* we could be persuaded. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Mon, 15 Jun 2020 at 00:21, Greg Ewing wrote:

On 15/06/20 3:52 am, David Mertz wrote:

...

I've had occasion to use math.isclose(), np.isclose(), and np.allclose() quite often.

Can you elaborate a bit on the kinds of things you use them for?

I can't elaborate on David's use but in my own experience these functions are mostly useful for interactive checking or for something like unit tests. They can be used extensively in the testing code for projects with a lot of floating point functions. It's unlikely that a fundamental numeric algorithm would want to make use of a generic function such as this though without explicitly setting the tolerance which wouldn't work with an operator. Fishing for examples in numpy testing code I quickly came across this test file where almost every test is based on a function assert_array_almost_equal: https://github.com/numpy/numpy/blob/master/numpy/fft/tests/test_helper.py The docstring for assert_array_almost_equal refers to more functions that are variants of the idea of closeness testing but somehow not quite the same. -- Oscar

pytest.approx https://docs.pytest.org/en/stable/reference.html#pytest-approx ``` The ``approx`` class performs floating-point comparisons using a syntax that's as intuitive as possible:: >>> from pytest import approx >>> 0.1 + 0.2 == approx(0.3) True The same syntax also works for sequences of numbers:: >>> (0.1 + 0.2, 0.2 + 0.4) == approx((0.3, 0.6)) True Dictionary *values*:: >>> {'a': 0.1 + 0.2, 'b': 0.2 + 0.4} == approx({'a': 0.3, 'b': 0.6}) True ``numpy`` arrays:: >>> import numpy as np # doctest: +SKIP >>> np.array([0.1, 0.2]) + np.array([0.2, 0.4]) == approx(np.array([0.3, 0.6])) # doctest: +SKIP True And for a ``numpy`` array against a scalar:: >>> import numpy as np # doctest: +SKIP >>> np.array([0.1, 0.2]) + np.array([0.2, 0.1]) == approx(0.3) # doctest: +SKIP True By default, ``approx`` considers numbers within a relative tolerance of ``1e-6`` (i.e. one part in a million) of its expected value to be equal. This treatment would lead to surprising results if the expected value was ``0.0``, because nothing but ``0.0`` itself is relatively close to ``0.0``. To handle this case less surprisingly, ``approx`` also considers numbers within an absolute tolerance of ``1e-12`` of its expected value to be equal. Infinity and NaN are special cases. Infinity is only considered equal to itself, regardless of the relative tolerance. NaN is not considered equal to anything by default, but you can make it be equal to itself by setting the ``nan_ok`` argument to True. (This is meant to facilitate comparing arrays that use NaN to mean "no data".) Both the relative and absolute tolerances can be changed by passing arguments to the ``approx`` constructor:: >>> 1.0001 == approx(1) False >>> 1.0001 == approx(1, rel=1e-3) True >>> 1.0001 == approx(1, abs=1e-3) True ``` On Sun, Jun 14, 2020, 9:39 PM David Mertz wrote:

On Sun, Jun 14, 2020 at 7:49 PM Oscar Benjamin wrote:

...

...

...

I've had occasion to use math.isclose(), np.isclose(), and np.allclose() quite often. Can you elaborate a bit on the kinds of things you use them for?

I can't elaborate on David's use but in my own experience these functions are mostly useful for interactive checking or for something like unit tests. They can be used extensively in the testing code for projects with a lot of floating point functions.

At times I have computations which *should be* the same mathematically, but are carried out through a different sequence of specific computations. One common example is in parallel frameworks where the order of computation is indeterminate because multiple workers/threads/processes are each calculating portions to aggregate.

Another related case is when I call some library to do an operation, but I did not write the library, nor do I understand its guts well. For example, the tensor libraries used in neural networks that will calculate a loss function. Occasionally I'd like to be able to replicate (within a tolerance) a computation the library performs using something more general like NumPy. Having a few ulps difference is typical, but counts as validating the "same" answer.

Another occasion I encounter it is with data measurements. Some sort of instrument collects measurements with a small jitter. Two measurements that cannot be distinguished based on the precision of the instrument might nonetheless be stored as different floating point numbers. In that case, I probably want to be able to tweak the tolerances for the specific case.

-- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VJSIJ3... Code of Conduct: http://python.org/psf/codeofconduct/

Paul Sokolovsky writes:

I'd encourage everyone who thinks "I need a very special operator just for me",

I don't think anybody who posts here thinks that, though. They think "wow, I could really use this, and I bet other people too." math.isclose probably tempts somebody somewhere in the world about once a minute. Of course they often find out differently -- and mostly when they do, they're OK with that. (There are also joke or half-joke proposals, but that's a different thing, and we're all in on those jokes.)

instead think in terms "Python needs ability to define custom operators".

Reading that *literally* (I take it seriously, below): Python has that ability already. It's just that the set of operator *symbols* is fixed (in a given version of Python), and almost exhausted for numerical types (but see below ;-). This has an important implication for readability: the associativity and precedence order of the symbols is also fixed, and only needs to be learned once.[1] If you always want isclose behavior for float "equality", you can't monkey patch (and you don't want to, I think), but you can subclass: import math class Real(float): exact_eq = float.__eq__ def__eq__(self, other): return math.isclose(self, other) or class AltReal(float): def __matmul__(self, other): # is self at other? close enuff! return math.isclose(self,other) Getting serious, as promised: Of course there will be work to do ensuring that all floats (more likely, all numbers) are converted to Reals in each entry point of the module, and probably a lot of duplication where "_private" versions of functions don't do the conversion, and "public" versions of them do. That could be avoided with custom operator symbols in many cases. But imposing this work is a deliberate choice of the language designers, for readability reasons, and maybe others. Perhaps it should be reconsidered, but I'm quite conservative on this one.

Recent example: implementation of "from __future__ import braces": https://github.com/NeKitDS/braces.py .

I strongly recommend the idiom: import __future__ as __watch_out_for_jokes__ (Recent? Isn't that more than a decade old? Hmmm: >>> from __future__ import braces File "<stdin>", line 1 SyntaxError: not a chance Different implementation, I guess. :-D :-þ :-D :-þ :-D :-þ :-D) Steve Footnotes: [1] This is not always a benefit. Occasionally there's a conventional assignment of symbols to operations where the "natural" behavior of the operations doesn't fit well with the associativity and precedence of the operators of 3rd grade arithmetic. But as a rule it's helpful.

On 14.06.20 17:52, David Mertz wrote:

On Sun, Jun 14, 2020, 10:22 AM Greg Ewing mailto:greg.ewing@canterbury.ac.nz> wrote:

On 15/06/20 12:39 am, Sebastian M. Ernst wrote: > It's such a common problem when dealing with floating point numbers

Is it really? I've done quite a lot of work with floating point numbers, and I've very rarely needed to compare two of them for almost-equality. When I do, I always want to be in control of the tolerance rather than have a default tolerance provided for me.

I've had occasion to use math.isclose(), np.isclose(), and np.allclose() quite often. And most of the time, the default tolerances are good enough for my purpose. Note that NumPy and math use different algorithms to define closeness, moreover.

I never use `math.isclose` or `np.isclose` without specifying tolerances, even if they happen to be the defaults (which is rare). There is no such thing as "x and y are approximately equal"; the question is always within what bounds. And this question must be answered by the programmer and the answer should be stated explicitly. Obviously these tolerances are application dependent, be it measurement errors, limited precision of sensors, numerical errors, etc. What makes the default values so special anyway? If I were to design such a function, I wouldn't provide any defaults at all. Yes, I read PEP-485, but I'm not convinced. The paragraph [Relative Tolerance Default](https://www.python.org/dev/peps/pep-0485/#relative-tolerance-default) starts with:

The relative tolerance required for two values to be considered "close" is entirely use-case dependent.

That doesn't call for a default value. [`np.isclose`](https://numpy.org/doc/stable/reference/generated/numpy.isclose.html) is even more extreme: They also specify (non-zero) defaults and because of that they need to display a *warning* at their docs which reads:

The default atol is not appropriate for comparing numbers that are much smaller than one (see Notes).

Then in the notes there is:

atol should be carefully selected for the use case at hand.

Sounds like it would've been more appropriate to not specify a default in the first place. Sure, some people might complain, who want a quick way to determine if two numbers are approximately equal, but as mentioned above, this question cannot be answered without specifying the bounds. All that the default tolerances do is prevent people from thinking about the appropriate values for their specific application. Since an operator doesn't allow to specify any tolerances, it's not a suitable replacement for the `isclose` functions.

On Tue, Jun 16, 2020 at 11:14:24AM +0300, Paul Sokolovsky wrote:

There's a reason why even projects otherwise largely written in Python, use a different language (like JavaScript) when they need easy-for-users scripting capabilities. A random example is https://github.com/frida/frida . That's because such projects want to let their users write one-liners like:

for_each_kaboom(function (kaboom) {print("here's kaboom", saboom); for (sub in kaboom) print(sub); })

What's so special about the ability to write one-liners? I trust that you agree that *limiting* users to only one line would be a terrible idea. So your scripting language surely will allow multiple lines of code. But if you give users the ability to write multiple lines of code, then what advantage is there to encourage them to cram them into a single line? Forth is a free-form concatenative language where whitespace separates words, and it lacks even the concept of "lines of code". To the interpreter, every Forth program is, or might as well be, a single line of code. You can literally write Forth code without once touching the Enter key, if you so choose. But in practice, everyone uses multiple lines, not just to separate word definitions but even within a single word once they exceed a certain level of complexity. As soon as a word contains loops or branches, the two dimensional structure is essential for the sake of maintainability and readability. In brace languages, there are a whole mountain of errors that occur when the logical structure of the program, as defined by the braces, doesn't match the apparent structure of the program, as seen by the programmer who is guided by indentation. These errors are rare in Python. (I was going to say "impossible", but I suppose that a sufficiently clever person could manage one using nested comprehensions. But they're impossible using regular for-loops and other block structures.) All Python does is require what people -- at least sensible people -- are already doing.

And while majority of people just leave Python behind in such cases, some people spent so much time with Python, that they refuse to (for they know that outside there's only bigger mess).

So wait, if you acknowledge that outside is only a bigger mess, why do you want to introduce that mess into Python and drag it down to that level? I honestly don't understand the point of your comment? Are you in favour of, or against, adding braces to Python?

On Sun, Jun 14, 2020 at 02:39:49PM +0200, Sebastian M. Ernst wrote:

Hi all,

after just having typed tons of `math.isclose` (see PEP 485 [1]) and `numpy.isclose` calls (while basically using their default tolerances most of the time), I was wondering whether it makes sense to add a matching operator.

I wrote the statistics module in the stdlib, and the tests for that use a lot of approximate equality tests: https://github.com/python/cpython/blob/3.8/Lib/test/test_statistics.py which includes an approx_equal function that pre-dates the math.isclose and a unittest assertApproxEqual method. So I like to think I'm a heavy user of approximate comparisons. I wouldn't use an approximate operator. Not even if it were written with the unicode ≈ ALMOST EQUAL TO symbol :-) The problem is that the operator can only have a single pre-defined tolerance (or a pair of tolerances, absolute and relative), which would not be very useful in practice. So I would have to swap from the operator to a function call, and it is highly unlikely that the operator tolerances would be what I need the majority of the time. -- Steven

On Tue, Jun 23, 2020 at 8:44 AM Mathew Elman wrote:

Perhaps a more versatile operator would be to introduce a +- operator that would return an object with an __eq__ method that checks for equality in the tolerance i.e

a == b +- 0.5

This is already valid syntax, because unary minus is a thing. So this is currently parsed as "a == b + (-0.5)". Reversing it to use -+ won't work because unary plus is also a thing.

On Tue, Jun 23, 2020 at 9:08 AM Mathew Elman wrote:

Well there you go, good point. I didn't really like it being an operator myself. But I can see having a math.tolerance class being useful.

On Tue, 23 Jun 2020 at 13:53, Jonathan Goble wrote:

...

On Tue, Jun 23, 2020 at 8:44 AM Mathew Elman wrote:

...

Perhaps a more versatile operator would be to introduce a +- operator that would return an object with an __eq__ method that checks for equality in the tolerance i.e

a == b +- 0.5

This is already valid syntax, because unary minus is a thing. So this is currently parsed as "a == b + (-0.5)".

Reversing it to use -+ won't work because unary plus is also a thing.

A little bit out of the box, but what about: a == b +/- 0.5 ...or even: a == b +or- 0.5 --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

On Tue, Jun 23, 2020 at 11:09 AM Rhodri James wrote:

On 23/06/2020 15:12, Ricky Teachey wrote:

...

On Tue, Jun 23, 2020 at 9:08 AM Mathew Elman wrote:

...

Well there you go, good point. I didn't really like it being an operator myself. But I can see having a math.tolerance class being useful.

On Tue, 23 Jun 2020 at 13:53, Jonathan Goble wrote:

...

On Tue, Jun 23, 2020 at 8:44 AM Mathew Elman wrote:

...

Perhaps a more versatile operator would be to introduce a +- operator that would return an object with an __eq__ method that checks for equality in the tolerance i.e

a == b +- 0.5

This is already valid syntax, because unary minus is a thing. So this is currently parsed as "a == b + (-0.5)".

Reversing it to use -+ won't work because unary plus is also a thing.

A little bit out of the box, but what about:

a == b +/- 0.5

...or even:

a == b +or- 0.5

Is "math.isclose(a, b, abs_tol=0.5)" really so hard to use?

TLDR: Of course it's not that hard to use. But the friction from "python code" to "mathematical calculations" is too large to make reaching for python as my go-to tool the first inclination. I'd really like to see this improved. I'm not strongly opinionated that this is a large, glaring need that simply *must* be rectified. Only that it would be VERY nice for those of us that use python primarily for mathematical calculations. BORING LONGER VERSION, BIT OF A RANT, SORRY: As a civil engineer, when I reach for a tool with which I am intending to do MATH, I generally do not reach for python right now-- even inside a Jupyter notebook. I reach for Mathcad or even Excel (blech). One of the biggest reasons is python code doesn't READ like real math in so many instances; this is a problem for me partly for my own reading, but also for my colleagues and clients. I would like to not have to spend a lot of time changing bits of the code to an output form for other non-programming people to read. My clients are not dumb, but if I were to print a jupyter notebook out and hand it to someone to read who doesn't know what python is, this: import math math.isclose(a, b, abs_tol=0.5) ...is just a step too far for them to read. So I have to use something else, or spend a lot of time massaging things to look more presentable. It would be nice-- for ME-- if there were ways to write functional code that looked more like calculations in python code. And something like +/- fits that bill. But I understand that not everyone-- perhaps not even close to significant % of people-- has the same needs I do, spending their days focused on producing, writing/reading mostly mathematical calculations with explanations. And that not everyone has the difficulty of having to present the math they are performing with their code to other people who are expecting to be reading calculations, not computer code. SIDEBAR Another BIG pain point for the "gee it would be nice if python code could look more like mathematical calculations" problem is the function writing syntax-- I love python, but sometimes I want to write a simple mathematical-looking structural engineering function: ∆y(P, H,L, E, I) = H * L^4 * P / (384 * E * I) ...and not: def ∆y(P, H,L, E, I): return H * L**4 * P / (384 * E * I) Boy would it be cool if we could use the walrus to write one-liner math functions! ∆y(P, H,L, E, I) := H * L^4 * P / (384 * E * I) THAT right there would change my life. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

On Tue, Jun 23, 2020 at 2:59 PM Wes Turner wrote:

...

∆y(P, H,L, E, I) := H * L^4 * P / (384 * E * I)

```python Δy = lambda P, H, L, E, I: H * L**4 * P / (384 * E * I) Δy ```

Is there a good way to redefine the '^' operator for {int, float, Decimal, Fraction, numbers.Number}? Why would it be dangerous to monkey-patch global types this way? Could a context manager redefine `float.__xor__ = float.__pow_` for just that scope? Why or why not?

https://docs.python.org/3.4/library/operator.html#operator.__pow__

As far as syntactical preferences, LaTeX may be considered to be the canonical non-executable syntax for mathematical expressions and equations. SymPy can parse LaTeX into symbolic expressions. Jupyter can render LaTeX embedded in Markdown. SymPy displays expressions as LaTeX in Jupyter notebooks.

```python from sympy import symbols P, H, L, E, I = symbols('P, H, L, E, I') Δy = H * L**4 * P / (384 * E * I) Δy ``` $\frac{H L^{4} P}{384 E I}$

```python import sympy sympy.sympify("H*L^4*P/(384*E_*I_)") ``` $\frac{H L^{4} P}{384 E_{} I_{}}$

https://docs.sympy.org/latest/modules/core.html#sympy.core.sympify.sympify calls parse_expr with `convert_xor=True`, by default.

https://docs.sympy.org/latest/modules/parsing.html#sympy.parsing.sympy_parse... :

...

Treats XOR, ^, as exponentiation, **.

```python from sympy.parsing.sympy_parser import parse_expr, standard_transformations,\ convert_xor trx = (standard_transformations + (convert_xor,)) parse_expr("H*L^4*P/(384*E_*I_)", transformations=trx) ``` $\frac{H L^{4} P}{384 E_{} I_{}}$

https://docs.sympy.org/latest/modules/parsing.html#experimental-mathrm-latex... :

...

LaTeX Parsing Caveats The current implementation is experimental. The behavior, parser backend and API might change in the future. Unlike some of the other parsers, LATEX is designed as a type-setting language, not a computer algebra system and so can contain typographical conventions that might be interpreted multiple ways

```python from sympy.parsing.latex import parse_latex #parse_latex(r'\frac{H L^{4} P}{384 E_{} I_{}}') parse_latex(r'\frac{H L^{4} P}{384 E I}') ``` $\displaystyle \frac{H L^{4} P}{384 E I}$

SageMath defines ^ as operator.pow. CoCalc supports Sage notebooks as well as Jupyter notebooks which import a CAS like SymPy, SymEngine, Diofant, SageMath.

https://ask.sagemath.org/question/49127/what-is-sage-equivalent-to-pow-in-sy...

... https://www.lidavidm.me/blog/posts/2013-09-15-implicit-parsing-in-sympy.html

https://stackoverflow.com/questions/49284583/how-to-use-unicode-characters-a...

Thanks for all of those suggestions! Some of those I've explored, others I haven't. I feel like I ought to relent from hijacking this thread now. Apologies to all.