0.0001 to power 2

[blackjetrock]

This calculation takes a long time.

[blackjetrock]

I changed the square root code to use the more standard Newton's formula and it now works better.

[edwig]

Please enlighten me with your source code modifications :-)

[blackjetrock]

The code is at the end of this comment. It seems to be better at small values of N.
There's some of my debug code in there too, and it's untidy, I'm working on getting this all running on my calculator PCB. I have code that runs on a RP Pico, if you have one of those then I could send you the firmware file so you can run it. It is a simulation of the Casio PRO-101. It's pretty much finished, I just have some bugs to sort out and tidying up.

// Icd::sqrt
// Description: Square root of the number
// What it does: Does an estimation through a double and then
// Uses the Newton estimation to calculate the root
icd
icd::SquareRoot() const
{
icd number(0L,0L);
icd half(("0.5"));
icd two(2L);
icd three(3L);
int sqrti = 0;

// Optimization: sqrt(0) = 0
if(IsNull())
{
return number;
}
#if DEBUG_SQRT
printf("\nSQRT:Number:%s", number.AsString().c_str());
#endif

// Getting the breaking criterion
icd epsilon = Epsilon(10);

number = *this; // Number to get the square-root from
if(number.GetSign() == -1)
{
throw new std::string(("Cannot calculate a square-root from a negative number"));
}

#if DEBUG_SQRT
printf("\nNumber now:%s", number.AsString().c_str());
#endif

// First estimate
double estimate1 = number.AsDouble() / 2;
double estimate2 = 1 / sqrt(estimate1);
icd result(estimate1);
icd between;

// Newton's iteration
icd last_result("0.0");

while(true)
{
result = (result + number/ result ) / two;
between = last_result - result;
if( between.AbsoluteValue() < epsilon)
{
break;
}

  last_result = result;

#if DEBUG_SQRT
printf("\nNumber now:%s", number.AsString().c_str());
printf("\nBetween: %s", between.AsString().c_str());
printf("\nResult: %s", result.AsString().c_str());
#endif

}

return result;
}

[edwig]

Tried out your alternate logarithm on the bcd class (see last checkin).
Sadly it performs much slower than the standard algorithm (some 14 times slower)
See Unitest in "UnitTestBCD.cpp testmethod "T100_Root10thousands" for a measurement and proof.

By the provided testcode i smell that you meant not to use the "bcd" class (which is the purpose of this project!) but the "icd" class.
Will provide an "icd200" test class as well. Stay tuned.

[blackjetrock]

Ah, yes, I am using the ICD library not the BCD one. I have also ported it to a RP Pico. If you have access to a Pico then you can run that code, all you need is a Pico and a USB cable. I can give you access to that repository. It definitely ran slowly on the Pico port, and the alternative algorithm runs faster, at least for small numbers.

Have you tried testing with the value 0.00001?
that was the problem value for my port.

Andrew

[edwig]

Alas,

I have added the same unit tests for the ICD class and alsoo created a new ICD208 class with 104 decimals to meet your case.
For both classes all unit tests are added and your test case is added as an alternative square-root calculation.
The square root test are repeated a 1000 times in a tight loop with an HighPerformanceCounter around it.
The HPFCounter can measure in the nanosecond range.

These are the results for ICD: (See the unit tests)

For large numbers in ICD
Original code : Speed of the SQUARE ROOT calculation = 0.161931
FAST SQUAREROOT: Speed of the SQUARE ROOT calculation = 0.641662

For small numbers < 1 in ICD (tested with 0.0001)
Original code : Speed of the SQUARE ROOT calculation = 0.011214
FAST SQUAREROOT: Speed of the SQUARE ROOT calculation = 0.262210

For large numbers in ICD208
Original code : Speed of the SQUARE ROOT calculation = 0.464387
FAST SQUAREROOT: Speed of the SQUARE ROOT calculation = 3.015204

For small numbers < 1 in ICD208 (tested also with 0.0001)
Original code : Speed of the SQUARE ROOT calculation = 0.041188
FAST SQUAREROOT: Speed of the SQUARE ROOT calculation = 1.370566

CONCLUSIION:
No. Your alternative is a factor 4 to 25 times SLOWER than the original. That also counts in the range between 1 and 0.
The evidence is in the unit tests for this.
Sorry.

[blackjetrock]

That's really odd. I can video the two routines and how long it takes (I only have the code running on real hardware). I wonder if the Pico handles some aspect of the calculation differently to the PC (x86?)? It's not a problem as I can continue to run the code that is faster on the Pico. This wasn't a criticism of your code, just that it seems to run differently on the Pico. The crashing at 200 digits is equally odd. I suspect some aspect of the Pico again, as I have examined the code and can't quite see why it would fail. For now, again, it's not a problem as 38 digits is fine for the calculator simulator I am creating. For other calculator simulations I want to do I would like 200 digits so I can do the standard 1E+/-99 number range. Regards Andrew Menadue

…

On Sat, 16 Dec 2023 at 16:22, Edwig Huisman ***@***.***> wrote: Alas, I have added the same unit tests for the ICD class and alsoo created a new ICD208 class with 104 decimals to meet your case. For both classes all unit tests are added and your test case is added as an alternative square-root calculation. The square root test are repeated a 1000 times in a tight loop with an HighPerformanceCounter around it. The HPFCounter can measure in the nanosecond range. These are the results for ICD: (See the unit tests) For large numbers in ICD Original code : Speed of the SQUARE ROOT calculation = 0.161931 FAST SQUAREROOT: Speed of the SQUARE ROOT calculation = 0.641662 For small numbers < 1 in ICD (tested with 0.0001) Original code : Speed of the SQUARE ROOT calculation = 0.011214 FAST SQUAREROOT: Speed of the SQUARE ROOT calculation = 0.262210 For large numbers in ICD208 Original code : Speed of the SQUARE ROOT calculation = 0.464387 FAST SQUAREROOT: Speed of the SQUARE ROOT calculation = 3.015204 For small numbers < 1 in ICD208 (tested also with 0.0001) Original code : Speed of the SQUARE ROOT calculation = 0.041188 FAST SQUAREROOT: Speed of the SQUARE ROOT calculation = 1.370566 CONCLUSIION: No. Your alternative is a factor 4 to 25 times SLOWER than the original. That also counts in the range between 1 and 0. The evidence is in the unit tests for this. Sorry. — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHQ75GEEGJZYMRH4NM27KETYJXDCVAVCNFSM6AAAAABAKUNKVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJYHA2TSNBZGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[blackjetrock]

Hi,

I've had another look at this and the sqrt of 0.001 doesn't ever exit.
I've instrumented the code:

// Newton's iteration
// Un = U(3-VU^2)/2
while(true)
{
between = number * result * result; // VU^2
between = three - between; // 3-VU^2
between *= half; // (3-VU^2)/2

if(between.ValueBehindPoint() < epsilon)
{
  break;
}
result *= between;

#if DEBUG_SQRT
printf("\nNumber now:%s", number.AsString().c_str());
printf("\nBetween: %s", between.AsString().c_str());
printf("\nResult: %s", result.AsString().c_str());
#endif

And I get this repeated on the output:

Between: +0.9999999999999999999999999999999999999998
Result: +31.6227766016837933199889354443271853371996
Number now:+0.0010000000000000000000000000000000000000
Between: +1.0000000000000000000000000000000000000014
Result: +31.6227766016837933199889354443271853372438
Number now:+0.0010000000000000000000000000000000000000
Between: +0.9999999999999999999999999999999999999992
Result: +31.6227766016837933199889354443271853372185
Number now:+0.0010000000000000000000000000000000000000
Between: +0.9999999999999999999999999999999999999996
Result: +31.6227766016837933199889354443271853372058
Number now:+0.0010000000000000000000000000000000000000
Between: +0.9999999999999999999999999999999999999998
Result: +31.6227766016837933199889354443271853371994
Number now:+0.0010000000000000000000000000000000000000
Between: +1.0000000000000000000000000000000000000014
Result: +31.6227766016837933199889354443271853372436
Number now:+0.0010000000000000000000000000000000000000
Between: +0.9999999999999999999999999999999999999992
Result: +31.6227766016837933199889354443271853372183
Number now:+0.0010000000000000000000000000000000000000
Between: +0.9999999999999999999999999999999999999996
Result: +31.6227766016837933199889354443271853372056
Number now:+0.0010000000000000000000000000000000000000
Between: +0.9999999999999999999999999999999999999998

I think the algorithm should exit on the ....9998 as epsilon is 2? maybe?
Your code is indeed faster than mine, I have timed 1.0, 0.1, 0.01,
but on 0.001 my code exits and the original doesn't. Obviously , for a calculator having the calculation end is more useful.
I'll investigate further.

[blackjetrock]

I changed the code to this:

// Newton's iteration
// Un = U(3-VU^2)/2
while(true)
{
between = number * result * result; // VU^2
between = three - between; // 3-VU^2
between *= half; // (3-VU^2)/2

if( between < 1.0)
  {
between = 1.0-between;
  }

if(between.ValueBehindPoint() < epsilon)
{
  break;
}
result *= between;

#if DEBUG_SQRT
printf("\nNumber now:%s", number.AsString().c_str());
printf("\nBetween: %s", between.AsString().c_str());
printf("\nResult: %s", result.AsString().c_str());
#endif

I'm not sure if this is correct, but the loop now ends. the outputs I get are this:

Modified original code:
Square root

+1.0000000000000000000000000000000000000000

Started timing...
Elapsed time = 758us
sqrt=+1.0000000000000000000000000000000000000000
+0.1000000000000000000000000000000000000000
Started timing...
Elapsed time = 1711us
sqrt=+0.3162277660168379331998893544432718533719
+0.0100000000000000000000000000000000000000
Started timing...
Elapsed time = 980us
sqrt=+0.1000000000000000000000000000000000000000
+0.0010000000000000000000000000000000000000
Started timing...
Elapsed time = 34947us
sqrt=+0.0316227766016837933199889354443271853372
S

Newton method code (mine):
Square root

+1.0000000000000000000000000000000000000000

Started timing...
Elapsed time = 9477us
sqrt=+1.0000000000000000000000000000000000000000
+0.1000000000000000000000000000000000000000
Started timing...
Elapsed time = 10712us
sqrt=+0.3162277660168379331998893544432718533719
+0.0100000000000000000000000000000000000000
Started timing...
Elapsed time = 10249us
sqrt=+0.1000000000000000000000000000000000000000
+0.0010000000000000000000000000000000000000
Started timing...
Elapsed time = 14649us
sqrt=+0.0316227766016837933199889354443271853371

So the two methods give the same answers, your original code is faster except for 0.001, which was the problem case before. I'm not sure what is happening here, but the exit condition doesn't seem to work on the Pico the same way. I also think that an iteration is more expensive on the Pico than on the PC, probably because the PC CPU has a lot of extra hardware for arithmetic.
At the moment, I'd like to use your code as it is faster, mostly, but I don't trust my 'fix'.

[edwig]

This is certainly very odd as a Pico (mostly an Intel J4xxx processor) should handle integer arithmetics the same was as a regular 'large' Core-i processor (being it a i5, i7 or i9 processor). The ICD library was deliberatly designed to use only 'integer' arithmetic (hence it's name).
The main purpose was to handle financial calculations withou rounding errors as 'double' or 'real' datatypes would, and in the process NOT generate general ledger roundings where you should extra book a cent (0.01) to get your financial books in order.

So the purpose was NOT to make trigionometrics work. For that we offer AFP and BCD, which use a mantissa and are more suitable to handle logarithmics, trigionmics or other engineering calculations.
Most generally: The ICD class is used in production applications with never more than 2 decimals. And only for 'simple' financial calculations (add, subtract, multiply, divide)

So my advice to you would be that: willing and planning to build a calculator: you would be better off with the BCD class.
That said: neither of these - to my knowledge - have been previously tested on a pico....

[blackjetrock]

It is indeed very odd. The Pico does have a hardware divider and the ARM processor has a multiply but that's it I think for arithmetic acceleration. I did look at your BCD libraray (and the Intel library, but that was way too big) but the Pico has limited RAM. I can't remember why I chose the ICD library instead. I didn't want to use malloc, maybe that was why, or maybe it was too complicated to port. I've nearly finished my calculator simulator, which is of a Casio PRO-101, which is a financial calculator. So the ICD library works for that. I think I'll look at the BCD library for other calculators. Do you think my 'fix' is correct? It works for a few test values, but I am not 100% sure it's correct. I suppose using my slower square root works fine for me. Regards Andrew Menadue

…

On Sun, 17 Dec 2023 at 11:56, Edwig Huisman ***@***.***> wrote: This is certainly very odd as a Pico (mostly an Intel J4xxx processor) should handle integer arithmetics the same was as a regular 'large' Core-i processor (being it a i5, i7 or i9 processor). The ICD library was deliberatly designed to use only 'integer' arithmetic (hence it's name). The main purpose was to handle financial calculations withou rounding errors as 'double' or 'real' datatypes would, and in the process *NOT* generate general ledger roundings where you should extra book a cent (0.01) to get your financial books in order. So the purpose was NOT to make trigionometrics work. For that we offer AFP and BCD, which use a mantissa and are more suitable to handle logarithmics, trigionmics or other engineering calculations. Most generally: The ICD class is used in production applications with never more than 2 decimals. And only for 'simple' financial calculations (add, subtract, multiply, divide) So my advice to you would be that: willing and planning to build a calculator: you would be better off with the BCD class. That said: neither of these - to my knowledge - have been previously tested on a pico.... — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHQ75GBAWAHSVQBXJN46B5TYJ3MXPAVCNFSM6AAAAABAKUNKVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJZGE2DSOJSGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>