Divide by zero differences between Windows and Linux implementations under 9.1

Hi Richard, I run your code in Linux 8.6.3 and I added into the spreadsheet. But then, I realized that the permutations you are trying (while very valuable and helpful to compare) are not still covering the ORIGINAL case you reported: 3.0/0.0 

Neither the subset followed by Andres like those: 

-1.0 / 0.0

-1.0 / -0.0

1.0 / -0.0

Right? 

What do you think its the best way to update your script to also include those? Because I am not sure that adding a 1.0 and -1.0 in the "special" dict is the best path. 

Thoughts?

Thanks,  

On Thu, Jun 27, 2019 at 1:28 PM Mariano Martinez Peck <[hidden email]> wrote:

Thanks Richard for your fantastic detective work! From what I can see the only missing part of the whole picture is 8.6.3 on Linux.

I will run that, fill it into the spreadsheet and share this with the VM team for analysis.

Once again, thanks both, Andres and Richard for the great report. 

On Wed, Jun 26, 2019 at 6:04 PM Richard Sargent <[hidden email]> wrote:

And for those who want to conduct the test for themselves, here is the script.

You will need to modify it if you are going to run it on a big endian machine.

On Wednesday, June 26, 2019 at 2:00:15 PM UTC-7, Richard Sargent wrote:

On Tuesday, June 25, 2019 at 4:31:38 PM UTC-7, Andres Valloud wrote:

I like +INF.  Just out of curiosity, what happens with these?

-1.0 / 0.0

-1.0 / -0.0

1.0 / -0.0

0.0 / 0.0

0.0 / -0.0

-0.0 / 0.0

-0.0 / -0.0

Similarly, what happens with +, ×, and -, when operating with 0.0 and -0.0?  For instance:

0.0 - 0.0

0.0 - -0.0

-0.0 - 0.0

-0.0 - -0.0

Good question. I decided to answer it for all the special floats, including both zeros, and all four arithmetic operations.

I've attached the PDF result and an Open Office spread sheet with the results.

The cases that failed all yielded essentially the same error, differing only in which operation encountered the error.

Primitive failed in: Float>>#/ due to Unknown floating point exception

Andres.

On Tue, Jun 25, 2019, 19:30 Richard Sargent <[hidden email]> wrote:

3.0/0.0 when evaluated under Windows in VA Smalltalk 9.1 throws a ZeroDivide exception.

3.0/0.0 when evaluated under Linux in VA Smalltalk 9.1 (32-bit) answers +Inf.

I'm wondering about the explanation of this different behaviour and whether it is controllable.

That is, whether one can choose to get an error or choose to get +Inf, and how to control it if so.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/1c19feb7-d3f3-437e-b30a-2e7d5797df93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/5c54a56a-82c6-4f54-860a-d5c191b9c07c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/6QyaBdN7qpk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibH%2BgOb7nEsMnsktcU6Hy412R5dsu%2BtejXhYuyH-YPZ-uQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Thanks Richard. So I changed your script to add 1.0 and -1.0 and also there was a problem with:

 answer := [firstOperand perform: operation with: secondOperand]
on: Error
do: [:ex | ex return: ex messageText].

Because in the case of ZeroDivide that was answering nil instead of the real exception message. So I replaced #messageText with #description. 

I then completed the rest of the OS/Versions. 

Attached is the final doc with the differences. 

Our conclusion is that the new VM (VA >= 9.0) keep the exact same results as the old VM (VA <= 8.6.3), in both, Windows and Linux. Which does not surprise us as minimizing behavioral changes in new VM was one of our goals. 

Now, we also agree that there are some scenarios where Linux and Windows answer differently. But again, since it has been like this for years (even in the old VM), it looks like a bit risky to change now and the potential  code we could break. We will still discuss this in our next development meeting and I will let you know the results. 

After reading in the in the IEEE 754-2008 standard, and in documentation of glibc in support of that standard,

https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_20.html

I believe I understand the more or less "correct" way to handle FP exceptional conditions.

754 defines five exceptional conditions:
1) Invalid operation (11 different ones, square root of a negative number is one example)
2) Division by zero
3) Overflow
4) Underflow
5) Inexact

754 lets programs, or individual program "blocks," handle FP exceptions using either of two strategies:
1) Set a status flag and continue execution with a default result value. Check the status flag later if you want to know whether a particular kind of exception has occurred since the last time the flag was cleared.
2) Trap on exceptional condition, with several options for what that means.

For support of strategy 1, based on the support functions provided in C99 and glibc, we *should* provide:

* Primitives to test and clear the FPU status word, corresponding to fetestexcept() and feclearexcept(). Possibly also feraiseexcept()

In addition, we *could* provide:

* Rounding mode control primitives, corresponding to fegetround() and fesetround().

For support of strategy 2, it's a bit more complicated. IEEE754 would want us to signal resumable exceptions so that a handler could specify what result it wanted for the operation that triggered the exception. C doesn't have a way to support this. It's unclear to me what would be required to get around this limitation.
What glibc does provide is a way to enable traps that then send SIGFPE. These are feenableexcept() and fedisableexcept().
So what we might be able to do is to provide, as Richard suggested, a way to specify an exception class for each of the five exceptional conditions. If each is nil (the default) that condition will not be trapped. This is the current 3.3.x behavior. If an exception class is specified, an exception of that class is signaled upon trap of that exceptional condition. The signaled exception should contain as much information as possible about the operation that was being attempted at the time (ideally, operation attempted (add, multiply, sqrt, ...) and the arguments.
It's unclear how much of this information is available within C. In Linux, we might only be able to distinguish all three of the five traps. In AIX and Solaris, we might have even less information.

Thanks for the script for carrying on the tests!

Best regards,

On Fri, Jun 28, 2019 at 12:37 PM Richard Sargent <[hidden email]> wrote:

On Fri, Jun 28, 2019 at 7:52 AM 'Mariano Martinez Peck' via VA Smalltalk <[hidden email]> wrote:

Hi Richard, I run your code in Linux 8.6.3 and I added into the spreadsheet. But then, I realized that the permutations you are trying (while very valuable and helpful to compare) are not still covering the ORIGINAL case you reported: 3.0/0.0 

Neither the subset followed by Andres like those: 

-1.0 / 0.0

-1.0 / -0.0

1.0 / -0.0

Right? 

What do you think its the best way to update your script to also include those? Because I am not sure that adding a 1.0 and -1.0 in the "special" dict is the best path. 

Well, from a mathematical standpoint, 1.0 and -1.0 are special. I do think the easiest way to get the answers is to add them to the mix. And perhaps "specials" is not the best name, so if you have a better name, feel free to use it.

Thoughts?

Thanks,  

On Thu, Jun 27, 2019 at 1:28 PM Mariano Martinez Peck <[hidden email]> wrote:

Thanks Richard for your fantastic detective work! From what I can see the only missing part of the whole picture is 8.6.3 on Linux.

I will run that, fill it into the spreadsheet and share this with the VM team for analysis.

Once again, thanks both, Andres and Richard for the great report. 

On Wed, Jun 26, 2019 at 6:04 PM Richard Sargent <[hidden email]> wrote:

And for those who want to conduct the test for themselves, here is the script.

You will need to modify it if you are going to run it on a big endian machine.

On Wednesday, June 26, 2019 at 2:00:15 PM UTC-7, Richard Sargent wrote:

On Tuesday, June 25, 2019 at 4:31:38 PM UTC-7, Andres Valloud wrote:

I like +INF.  Just out of curiosity, what happens with these?

-1.0 / 0.0

-1.0 / -0.0

1.0 / -0.0

0.0 / 0.0

0.0 / -0.0

-0.0 / 0.0

-0.0 / -0.0

Similarly, what happens with +, ×, and -, when operating with 0.0 and -0.0?  For instance:

0.0 - 0.0

0.0 - -0.0

-0.0 - 0.0

-0.0 - -0.0

Good question. I decided to answer it for all the special floats, including both zeros, and all four arithmetic operations.

I've attached the PDF result and an Open Office spread sheet with the results.

The cases that failed all yielded essentially the same error, differing only in which operation encountered the error.

Primitive failed in: Float>>#/ due to Unknown floating point exception

Andres.

On Tue, Jun 25, 2019, 19:30 Richard Sargent <[hidden email]> wrote:

3.0/0.0 when evaluated under Windows in VA Smalltalk 9.1 throws a ZeroDivide exception.

3.0/0.0 when evaluated under Linux in VA Smalltalk 9.1 (32-bit) answers +Inf.

I'm wondering about the explanation of this different behaviour and whether it is controllable.

That is, whether one can choose to get an error or choose to get +Inf, and how to control it if so.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/1c19feb7-d3f3-437e-b30a-2e7d5797df93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/5c54a56a-82c6-4f54-860a-d5c191b9c07c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/6QyaBdN7qpk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibH%2BgOb7nEsMnsktcU6Hy412R5dsu%2BtejXhYuyH-YPZ-uQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAGNapEOSYR2mFmXSV7XjWOPBUQsLD8Syp1jmuKjEKey57Vu__g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/6QyaBdN7qpk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibH5N4_pOHmCmENOKE3ipJ7-DBGz9RJc9M5ahhvMeuuqtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

On Tue, Jul 2, 2019 at 7:31 AM 'Mariano Martinez Peck' via VA Smalltalk <[hidden email]> wrote:

Thanks Richard. So I changed your script to add 1.0 and -1.0 and also there was a problem with:

 answer := [firstOperand perform: operation with: secondOperand]
on: Error
do: [:ex | ex return: ex messageText].

It would be nice if there were a single selector which would answer the message text if not nil and the exception description otherwise. (Like others, I really don't want to see the "(ExError) An error occurred" prefix if there is anything else which could be displayed.)

Now, we also agree that there are some scenarios where Linux and Windows answer differently. But again, since it has been like this for years (even in the old VM), it looks like a bit risky to change now and the potential  code we could break. We will still discuss this in our next development meeting and I will let you know the results. 

At this point, I agree changing things is not a good idea.

I really would like to have a clear understanding of what causes the different behaviour between Linux and Windows implementations and whether it could be controlled. I think it can, at least under Linux. Who knows about Windows?!!

The following note is from one of our bug entries, raised by a customer. It does look like it is controllable, although most of what Martin documents is far more detailed than I care to become expert on!

After reading in the in the IEEE 754-2008 standard, and in documentation of glibc in support of that standard,

https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_20.html

I believe I understand the more or less "correct" way to handle FP exceptional conditions.

754 defines five exceptional conditions:
1) Invalid operation (11 different ones, square root of a negative number is one example)
2) Division by zero
3) Overflow
4) Underflow
5) Inexact

754 lets programs, or individual program "blocks," handle FP exceptions using either of two strategies:
1) Set a status flag and continue execution with a default result value. Check the status flag later if you want to know whether a particular kind of exception has occurred since the last time the flag was cleared.
2) Trap on exceptional condition, with several options for what that means.

For support of strategy 1, based on the support functions provided in C99 and glibc, we *should* provide:

* Primitives to test and clear the FPU status word, corresponding to fetestexcept() and feclearexcept(). Possibly also feraiseexcept()

In addition, we *could* provide:

* Rounding mode control primitives, corresponding to fegetround() and fesetround().

For support of strategy 2, it's a bit more complicated. IEEE754 would want us to signal resumable exceptions so that a handler could specify what result it wanted for the operation that triggered the exception. C doesn't have a way to support this. It's unclear to me what would be required to get around this limitation.
What glibc does provide is a way to enable traps that then send SIGFPE. These are feenableexcept() and fedisableexcept().
So what we might be able to do is to provide, as Richard suggested, a way to specify an exception class for each of the five exceptional conditions. If each is nil (the default) that condition will not be trapped. This is the current 3.3.x behavior. If an exception class is specified, an exception of that class is signaled upon trap of that exceptional condition. The signaled exception should contain as much information as possible about the operation that was being attempted at the time (ideally, operation attempted (add, multiply, sqrt, ...) and the arguments.
It's unclear how much of this information is available within C. In Linux, we might only be able to distinguish all three of the five traps. In AIX and Solaris, we might have even less information.

Thanks for the script for carrying on the tests!

Best regards,

On Fri, Jun 28, 2019 at 12:37 PM Richard Sargent <[hidden email]> wrote:

On Fri, Jun 28, 2019 at 7:52 AM 'Mariano Martinez Peck' via VA Smalltalk <[hidden email]> wrote:

Hi Richard, I run your code in Linux 8.6.3 and I added into the spreadsheet. But then, I realized that the permutations you are trying (while very valuable and helpful to compare) are not still covering the ORIGINAL case you reported: 3.0/0.0 

Neither the subset followed by Andres like those: 

-1.0 / 0.0

-1.0 / -0.0

1.0 / -0.0

Right? 

What do you think its the best way to update your script to also include those? Because I am not sure that adding a 1.0 and -1.0 in the "special" dict is the best path. 

Well, from a mathematical standpoint, 1.0 and -1.0 are special. I do think the easiest way to get the answers is to add them to the mix. And perhaps "specials" is not the best name, so if you have a better name, feel free to use it.

Thoughts?

Thanks,  

On Thu, Jun 27, 2019 at 1:28 PM Mariano Martinez Peck <[hidden email]> wrote:

Thanks Richard for your fantastic detective work! From what I can see the only missing part of the whole picture is 8.6.3 on Linux.

I will run that, fill it into the spreadsheet and share this with the VM team for analysis.

Once again, thanks both, Andres and Richard for the great report. 

On Wed, Jun 26, 2019 at 6:04 PM Richard Sargent <[hidden email]> wrote:

And for those who want to conduct the test for themselves, here is the script.

You will need to modify it if you are going to run it on a big endian machine.

On Wednesday, June 26, 2019 at 2:00:15 PM UTC-7, Richard Sargent wrote:

On Tuesday, June 25, 2019 at 4:31:38 PM UTC-7, Andres Valloud wrote:

I like +INF.  Just out of curiosity, what happens with these?

-1.0 / 0.0

-1.0 / -0.0

1.0 / -0.0

0.0 / 0.0

0.0 / -0.0

-0.0 / 0.0

-0.0 / -0.0

Similarly, what happens with +, ×, and -, when operating with 0.0 and -0.0?  For instance:

0.0 - 0.0

0.0 - -0.0

-0.0 - 0.0

-0.0 - -0.0

Good question. I decided to answer it for all the special floats, including both zeros, and all four arithmetic operations.

I've attached the PDF result and an Open Office spread sheet with the results.

The cases that failed all yielded essentially the same error, differing only in which operation encountered the error.

Primitive failed in: Float>>#/ due to Unknown floating point exception

Andres.

On Tue, Jun 25, 2019, 19:30 Richard Sargent <[hidden email]> wrote:

3.0/0.0 when evaluated under Windows in VA Smalltalk 9.1 throws a ZeroDivide exception.

3.0/0.0 when evaluated under Linux in VA Smalltalk 9.1 (32-bit) answers +Inf.

I'm wondering about the explanation of this different behaviour and whether it is controllable.

That is, whether one can choose to get an error or choose to get +Inf, and how to control it if so.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/1c19feb7-d3f3-437e-b30a-2e7d5797df93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/5c54a56a-82c6-4f54-860a-d5c191b9c07c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/6QyaBdN7qpk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibH%2BgOb7nEsMnsktcU6Hy412R5dsu%2BtejXhYuyH-YPZ-uQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAGNapEOSYR2mFmXSV7XjWOPBUQsLD8Syp1jmuKjEKey57Vu__g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Email: [hidden email]

Twitter: https://twitter.com/MartinezPeck

LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/6QyaBdN7qpk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibH5N4_pOHmCmENOKE3ipJ7-DBGz9RJc9M5ahhvMeuuqtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/CAGNapEMX3Rgm6DYmfESEy9oXyAeGtghu29Ys4tZ3E95wqvONKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

 Mariano,

there's not much I can add to the Divide by Zero problem, but I ask you to take a loot at this thread about Exception's descriptions:

https://groups.google.com/d/msg/va-smalltalk/YnB-XFd3meE/21jDb-pDCAAJ

Interestingly, there still seem to be differences betwwen #messageText and #descriptiion. Plus: there is no "officially" correct way documented anywhere, afaik.
Ceterum Censeo this "(ExError)..." prefix is unnecessary and must go away. But you know that already, I just wanted to make sure to nag once again ;-)