Miva Merchant Empresa Bugs?

[leslienord]

Re: MIVA Empresa Bugs?

Sorry for the delay, Bill sometimes I step away.

[BillBuilt]

Re: MIVA Empresa Bugs?

Ok i think i got it. Waiting 48 hrs to get my post posted must have forced me to stop trying for a bit and walk away from it, i realized that the server requires the addresses to be surrounded by < >. Simple solution that was being overlooked out of frustration i suppose.


Bill M.

[BillBuilt]

Re: MIVA Empresa Bugs?

Not sure if this is an Empressa bug or not, but i cannot use MvSMTP at all with my current host. Returns:

Runtime error in test.mvc @ [00000000:0000004c]: D:! My DocumentsMy Web Sitestest.mv: Line 3: MvSMTP: Syntax error - your mail software violates RFC 821.

Raw mail log:

Aug 24 09:16:36 server courieresmtpd: started,ip=[::ffff:69.36.5.142]
Aug 24 09:16:36 server courieresmtpd: HELO server.billbuilt.com
Aug 24 09:16:36 server courieresmtpd: MAIL FROM:[email protected]
Aug 24 09:16:36 server courieresmtpd: error,relay=::ffff:69.36.5.142,msg="554 Syntax error - your mail software violates RFC 821.",cmd: MAIL FROM:[email protected]

Of course my host tells me its Empressa. Its running linux and using the Courier mail server. I have to resort to calling a php script to do emails, which can be argued is better, and i agree if your wanting to do complex emailing, esp BCC and such, but for very simple text only emailing, this is quite a hassle.

PHP via mail() or using the PEAR mail class works just fine so i am leaning towards some incompatibility in Empressa.

Any help would be appreciated, as i have no idea where to even start with tracking this down.

Thanks,
Bill M.

[Greg B]

Re: MIVA Empresa Bugs?

In the past I think there has been an issue with the tax getting rounded inconsistently so that one of the payment modules was messing up on rare occasions.

It is still a problem with sales tax and the LinkPoint payment module.

[d_host]

Re: MIVA Empresa Bugs?

I even looked at Microsoft Excel. It has three functions: ROUND, ROUNDUP and ROUNDDOWN. The last two do exactly what you'd expect, but ROUND behaves identically to ROUNDUP.

There is good reason to use the "round to even" method. In calculations on a lot of numbers it avoids the tendency to bias the results in the direction of the rouding. That is going up half the time tends to balance out with the going down half the time.

While that does make things more fair in the long run, it has been a common practice in all fields involving monetary exchanges that you round up - every time. I've seen the "round to even number" before, but that's mostly used in programming areas where you do not necessarily involve money exchanging hands. If you check with your local bank or supermarket or gas station, they always round up to the closest penny. Right or wrong, that's how "everyone in the world" does it in retail and financial businesses.

[wcw]

Re: MIVA Empresa Bugs?

In the past I think there has been an issue with the tax getting rounded inconsistently so that one of the payment modules was messing up on rare occasions. I don't know if it was paylink or which one; maybe someone else knows. But that is a consideration on how to do it. Will it mess up a payment module? Apparently this is bankers rounding and since the major reason for mivascript is a shopping cart that deals with money, the round to even might be the way to go.

On the other hand, I vote for the Excel method, ie three different functions, ie rnd(), rndeven(), rndup(). rnd() would stay as it is now, for legacy reasons even though it is not consistant. Those who want to use rndup() function could do it that way. rndeven() would round even on all platforms (windows and unix). The downside is that there is tons of code that are using rnd() and thus inconsistant. So over time, those systems would get changed to the intended rounding system.

Thank you very much for getting back to us.

[Mark Johnson]

Re: MIVA Empresa Bugs?

I have done some research on this issue. Here's what I came up with. The Miva Engine uses the C sprintf function to implement its rnd function and ROUND operator. This is considered a standard way to do rounding. On UNIX systems the sprintf function does the "round to even" method. Unfortuneately on Windows the same function does the "round up" method.

So I decided to look around and see how it's done elsewhere. Brandon MUS posted that PHP uses "round up". Perl uses "round to even". Python uses "round to even". Ruby uses "round up".

I even looked at Microsoft Excel. It has three functions: ROUND, ROUNDUP and ROUNDDOWN. The last two do exactly what you'd expect, but ROUND behaves identically to ROUNDUP.

There is good reason to use the "round to even" method. In calculations on a lot of numbers it avoids the tendency to bias the results in the direction of the rouding. That is going up half the time tends to balance out with the going down half the time.

My inclination is to have Miva behave the same on all platforms and use the "round to even" method. I would also be favorable to the Excel idea and add a "round up" and "round down" function.

Being new here, we thought we would take an informal poll of the developers. So if you hava an opinion, let us know.

[Brandon MUS]

Re: MIVA Empresa Bugs?

http://en.wikipedia.org/wiki/Roundin...to-even_method I think I learn something from Wiki every day :D

PHP does not use the round-to-even method.

<?php printf( "%.0f %.0f %.0f\n", 0.5, 0.51, 1.5); //prints: 1 1 2 ?>

[SpaceMoose]

Re: Rounding bug in 5.06

When they find that there are versions of Empressa that give different
results, which version are they going to 'fix'? The useful one?

[SpaceMoose]

deleted. ..........
posted in wrong place

[wcw]

Re: Rounding bug in 5.06

Please keep us posted. If that is the accepted method, I can live with that. Course it should work the same way on Windows (and Mia) the same way.

[Mark Johnson]

Re: Rounding bug in 5.06

That is not logical. .5 should be expected to round up in every case. Why is Markus finding on Windows Empresa that it works differently, ie .5 rounds up to 1?

I'm sorry that you don't find it logical, but it is the accepted standard for rounding. That is, since 2.5 is exactly half way between 2 and 3, the choice of which way to round is arbitrary. Someone long ago established the "round towards the even number" rule. The accepted standard in computing is the C language printf function which is why I used it in my example. It is also the reason that it is implemented that way in the MivaScript engine.

I agree with you that if it behaves differently on Windows, that is a problem. I am investigating that now.

[wcw]

Re: Rounding bug in 5.06

That is not logical. .5 should be expected to round up in every case. Why is Markus finding on Windows Empresa that it works differently, ie .5 rounds up to 1?

[Mark Johnson]

Re: Rounding bug in 5.06

Bill,

Your test is showing the expected output from the rnd function, i.e. a number ending in .5 rounds towards the even number. Here is a simple C test program:

#include "stdio.h"

double d1 = 0.5;
double d2 = 0.51;
double d3 = 1.5;

int main () {
printf( "%.0f %.0f %.0f\n", d1, d2, d3 );
}

It produces the output: "0 1 2"

What you want to use is either int( number + 0.5 ) or floor( number + 0.5 ) depending on what you want to happen with negative numbers.

int( -3.2 ) is -3 but floor( -3.2 ) is -4.

This bug is apparently much worse. Expanding the test you get

0.5 rounds to 0
1.5 rounds to 2
2.5 rounds to 2
3.5 rounds to 4
4.5 rounds to 4
5.5 rounds to 6
6.5 rounds to 6
7.5 rounds to 8
8.5 rounds to 8

Even numbers round down and odd numbers round up. This has nothing to do with banker rounding. Anybody have any thoughts on it?

Rick - can we get this fixed soon? I realize updating empresa is a major undertaking, but you have to be able to trust a program's math.

[Rick Wilson]

Re: MIVA Empresa Bugs?

Mark, our new VP of Development, will be posting about this shortly.