PBP and PBPL

[keymuu]

(L/2)*(L/2)

The result of that alone is over 30 Billion.

That is why I was asking if somebody would know some gimmicks and tricks to cut up that formula using "trick tools" available... calculating that in small steps or something like that.

/H

DIV32 is actually a DIV31/15. The maximum divisor for DIV32 is 15-bits or 32767
37234 is too much.

Yes true, but tricking around ... that was my hope but I do not how, so there I would have needed some help if that is usually possible at all to calculate small parts at time...

/1000

There's at least 3 decimals of precision you won't need, so why are the numbers so big to begin with? (rhetorical question)

Rhetorical or not, I know I'm stubborn ...

Really, test with Excel and skip the least significant digit (just one) compare with calculating with the calculation with all numbers and you will see that I'm not joking, at least with this matter ....

Let me open a whole new "Can of Worms", and suggest that you use the Microchip Floating Point Math module.
http://www.melabs.com/resources/fp.htm

It'll handle your numbers.
It takes a little getting used to, but it works.
<br>

Thank you Darrel you really know things, not kidding.... :-)

Why couldn't this pop up earlier?(Rhetorical question) :-)
I downloaded those, took the example directly from that page and it compiled without errors. I will next play around with it and see if it is possible to solve "this" with it. If not then the "splitting" will be actual again....

[keymuu]

Let me open a whole new "Can of Worms", and suggest that you use the Microchip Floating Point Math module.
http://www.melabs.com/resources/fp.htm

It'll handle your numbers.
It takes a little getting used to, but it works.
<br>

The example alone takes almost 7k of code space, precisely 6898 byte used.
There is really no room for the real application for it. Copying that example to my code brings up familiar errors telling that we go over the limit with about 3k. Obviously the FP-library is too big.... and easy to estimate that I would need slightly more functions than the example has.

"What goes up comes also down, always..."

So, if it would be possible to split the formula to smaller calculate one part at time or utilizing R0,R2 or something....

Isn't possible?

[Darrel Taylor]

Yup ... Worms ...

If you got rid of the USB bootloader you'd have another 4K to play with.
Talk about a Code HOG!

Really, test with Excel and skip the least significant digit (just one) compare with calculating with the calculation with all numbers and you will see that I'm not joking ...

I have tested it ... with "Open Orifice" not Excel.

And frankly, none of your formulas work out to what you say it should.

For instance in post#26

The question arise from the following formula:
R = ( (H^2) + ((L/2)^2) ) / H and for example
where
L = 315,103 -> 315103 (=LONG)
H = 37,234 -> 37234 (=WORD)

That should give R=703,9 (=WORD)

When I plug that into the spreadsheet I get 860,313.14
EDIT: OK, I see that your sample numbers changed along the way.

By the way, why do some people use commas as decimal points?
And do you then call it a "decimal comma"?
Then what do you use for 1000's separator ... periods?

Then in post#28, you say that

... (L/2)^2 could be calculated earlier in the PC and programmed as a constant to PIC ...
... in this case the constant Lsqr2 = 24 822 475 152

But it's not, it's 30,646,528,782.<hr>

At any rate, let's assume that what you wanted was actually (L/2)*(L/2)/H/1000

IF L = 350123 and H = 37234 then the result is 823, and of course the numbers are too big for PBP.

But, as I was saying before, you have 3 decimals of precision that you don't need.
So if you reduce the 2 numbers 1 digit each so that L = 35012 ,H = 3723 and the divide is 100 instead of 1000, then the largest interim number is 306,460,036 and the final result is once again 823.
Well within PBP's limits with DIV32.

[keymuu]

Yup ... Worms ...

If you got rid of the USB bootloader you'd have another 4K to play with.
Talk about a Code HOG!

I have tested it ... with "Open Orifice" not Excel.

And frankly, none of your formulas work out to what you say it should.

I have heard that Open Office is compatible with Excel, but how far does this compatibility go? Surprising if it wouldn't use the same amount of precision or bits to calculate what Excel on the spreadsheet... Can't really comment...

For instance in post#26When I plug that into the spreadsheet I get 860,313.14
EDIT: OK, I see that your sample numbers changed along the way.

My mistake, that i did not keep the example numbers constant along the way. But the "locally" they should show the case....

By the way, why do some people use commas as decimal points?
And do you then call it a "decimal comma"?
Then what do you use for 1000's separator ... periods?

That is the way numbers are handled in Scandinavia. You are right, the 1000's separator is period and often space also. My mistake again, did not remember that the other parts of the world do no use that. When the world is as global as it is today, one do not (at least not I) even see that small difference (comma, period) in numbers, you just see the number the right amount and I can't remember right now if there ever had been a misunderstanding close to me concerning this matter... automatically handled by your brain. But frankly speaking you can here see more and more your way of using separators, so I guess that ultimately the comma as a decimal separator will disappear....

Then in post#28, you say that But it's not, it's 30,646,528,782.<hr>

At any rate, let's assume that what you wanted was actually (L/2)*(L/2)/H/1000

I wrote in that way so that there would be more elements to play with and hoped some mastermind could do something with that, for example something like this:
(L/20)*(L/20)/H but this does not of course help anything....

IF L = 350123 and H = 37234 then the result is 823, and of course the numbers are too big for PBP.

But, as I was saying before, you have 3 decimals of precision that you don't need.

So if you reduce the 2 numbers 1 digit each so that L = 35012 ,H = 3723 and the divide is 100 instead of 1000, then the largest interim number is 306,460,036 and the final result is once again 823.
Well within PBP's limits with DIV32.

As I told earlier, Darrel you are, I don't know how to say this so I just say GREAT! You have a fantastic intuition, wow...

Also Excel is a great tool (Open Office spreadsheet perhaps also), I could with the help of it realize a point that has been kind of hided all the way here.
You can of course not reduce H at all, but on the other hand you could divide the intermediate result (L/2)*(L/2)=30646528782 (L=315123 and real 315,123) as far as to a word !!!!!, I think. At least my preliminary experiments show so with "these" example numbers. Lets call (L/2)*(L/2)=30646528782 = Lsqr2
Having H=37234 (real 37,234)
Next we need to divide Lsqr2 with H, so
Lsqr2/H = 823079,1422 (correct answer, we need the four most significant digits, and those seems to be 8230). Now the question, with how many digits can you get this result (8230)?
Yes, that is right five digits = 30646 !

So, 30646/37234=0.8230... Never mind where the decimal separator is... the numbers are correct, yessssss !!!

If we would have one more digit in the dividend we would be on the sure side, with so few digits (5) there are still some unsureness around.
Lets call the short Lsqr2 (30646) to Ls

We have Ls=30646 and H=37234
So now PBP should accomplish the following formula:

R=(Ls/H)*10000

Should be perfectly within the limits but it gives R=0 :-(

Now, do you have any ideas how to proceed from here?

Thanks

[keymuu]

Yes I'm stupid, blind and.... who know what..

Of course you can not do the division like that, instead:
rr = 10000*L
R = div32 H

And this gives the correct answer

I will still do some testing and soon I will tell if this was the final solution.........

[keymuu]

"rr = 10000*L
R = div32 H
this gives the correct answer"
Yes indeed ... as long L=350123, really...

What a coincident

Have only tested different values for L,
when H=37234 and noticed that I was wrong, totally wrong(?).

When L=310123 or 360123 (both values slightly over the real and needed values) the result R is more or less wrong.

L=360123 gives 8704 when it should be 8707, not a big error but too big anyway.

L=310123 gives 6401 and it should be 6457 this error again is huge...

Maybe there is some work around this, but I don't know one, do you?

For ex. if we say we will stay within L=310000 to 360000 and H=20000 to 40000,

we could "graphically" see the lines through the L points and H points,
meaning the points from min to max, and from these calculate an offset to result.
Or something like this...

Perhaps there is some other solution(s), does anybody know this??
Please help