INT not here...

[RogerTango]

Doesnt look like PICAXEBASIC supports INT- I have a formula I want to work out, but some fractions will end up being the result, and the SOUND command wants whole numbers.

Anyone been in this type of situation? The duration is what I will be working with.


Thanks,
Andrew

 

[goom]

The PICAXE only supports integer maths, so you are in luck. Any fractional part of a division will be truncated.

 

[RogerTango]

The PICAXE only supports integer maths, so you are in luck. Any fractional part of a division will be truncated.

Can you give an example of what you mean by truncated?

Would 16.4 then become 16? If so, that would suit perfectly fine, I do not need the fraction to be rounded with this particular application!

Thanks,
Andrew

 

[Jeremy Leach]

Picaxe variables are whole numbers (e.g b0 as a byte, or w0 as a word).
Maths expressions always put the result into a variable, so are always whole numbers.

You can work out the fractional parts of calculations, and even attempt floating point maths, but picaxe basic is essentially all based on whole numbers.

 

[RogerTango]

So, if I assign b1 = 14.5, then go back later and read b1, it should hold 14??

Andrew

 

[Jeremy Leach]

well, yes, if you had a maths expression like b1 = 29/2 then b1 would be loaded with the integer result, 14. ie the whole number.

 

[westaust55]

So, if I assign b1 = 14.5, then go back later and read b1, it should hold 14??

Andrew

No you cannot assign b1 = 14.5

The Programming Editor will see the decimal point and declare a syntax error

BUt as others have said all numbers in the PICAXE BASIC are truncated to integers.

So:
1. you can only assign a number directly as an integer
2. The results of all maths will be an integer (just as if you used =INT(x) in Excel)

 

[RogerTango]

Heres what I intended to communicate:

b0 = 12
b1 = 8
b3 = b0 / b1

That is, 12 / 8 = 1.5

Where as we are assigning whole numbers to b0 and b1 (in accordance to the expectations of the PICAXE BASIC).

Is there an error generated, or does b3 simply become 1? 55, if I understand you correctly that is correct. Please validate for me sir.

Thanks-
Andrew

 

[hippy]

b3 will become 1, no error generated.

 

[RogerTango]

New question, lets say I need to increase the duration of a tone, for example, by 10%

rem b0 = tone duration
b0 = 20
b0 = b0 + (b0 * .1)
rem b0 becomes 22, 20* 10% (.1) is 2, plus 20 = 22

Will the above work, multiplying by fraction? Sorry to be asking what I should be trying, I am not at my bench/hackshop right now.

Thanks,
Andrew

 

[goom]

No, ONLY integers are permitted. You can get round this with something like:
b0 = b0/10+b0
Expressions are evaluated strictly from left to right, and no brackets allowed.

 

[westaust55]

1. you cannot use brackets and there is no precedence in maths operations.
2. you cannot multiply by a fraction (that is 0.1)

So in your example:
B0 = 20
B0 = b0 /1 0 + b0 ; that calcs as 20/10 + 20 = 2 + 20 = 22

 

[RogerTango]

Ahhhhhh....

Perfect sense, yes. The math is much more elementary. Thanks for the help, thats right on point!

Andrew

 

[moxhamj]

b0=b0*11 then b0=b0/10
will increase it by 10%.

I prefer to do these things in seperate lines - if you do it all in one line, you need to think through all the steps and check each one doesn't go out of range.

Just watch that b0 doesn't go over 255 in the process.

If it does, use w0 instead of b0 as w0 can go up to 65535.

There is usually an integer way around the maths. Eg if you are doing things to 0.1 precision, multiply everything by 10. If to 0.01 precision, multiply by 100.

 

[hippy]

Note that all maths is done using 16-bits so only if an intermmediate result exceeds 65535 or the final result is over 255 will you have a problem with byte variables. This will work as expected, b1 will become 200 ...

b0 = 100
b1 = 400 * b0 / 200

 

[RogerTango]

Very helpful, this info is going into my notebook.

Thanks,
Andrew

 

[westaust55]

Note that all maths is done using 16-bits so only if an intermmediate result exceeds 65535 or the final result is over 255 will you have a problem with byte variables. This will work as expected, b1 will become 200 ...

b0 = 100
b1 = 400 * b0 / 200

"only if an intermmediate result exceeds 65535 ...will you have a problem with byte variables"

now that is a fact where there has been confusion in the past for many thinking even intermediate results in the same line cannot exceed 255.

 

[BCJKiwi]

word variables actually work in a similar manner but are a bit harder to sort out.

i.e. the intermediate result of two word calculations (16 bit) is 32 bit. However as there is no direct access to this 32 bit intermediate result, the upper and lower parts are stored into separate places but can be retrieved.
The calculation has to proceed in two separate 16 bit portions which can be combined again at the end.

So PICAXE does do 32 bit math!

See Manual 2 (varaibles - mathematics), and, discussions in these threads;
http://www.picaxeforum.co.uk/showthread.php?t=8624

http://www.picaxeforum.co.uk/showthread.php?t=10165

 

[westaust55]

Thanks BJCKiwi.

Good to know it applies to word variables as well.
There are a lot of these little "gems" that could be added into the next revision of the Manual 2.

As I often say:

The first day you (I) do not learn something new is your (my) first day in a wooden box

 

[Jeremy Leach]

Think we need to be careful here. My understanding is this: the internal picaxe maths is 16bit and as an expression is evaluated left to write, if any of the intermediate result is > 16bit then there will be overflow. Yes, the ** operator gives the high word of a multiplication, but still gives a 16bit result. If you are assigning the result of an expression to a byte variable, then the least significant byte of the (word) result gets assigned. There are ways to calculate using 32bits, but the picaxe maths itself is 16bit.

 

[hippy]

Jeremy is right; the PICAXE is "16-bit", with the exception of ** which does have a transient 32-bit calculation to it.

32-bit, 64-bit, N-bit, BCD, negatives, fixed and floating point math can all be done with a PICAXE but only by coding appropriate algorithms. The same is true of any micro or controller.

 

[Technical]

All mathematics is carried out in separate (firmware only) 16-bit variables in the PICAXE bootstrap, it is not done in the variables themselves At the end of the 'line of maths' the result is simply loaded into the variable of choice - either the full 16-bits into a word variable or the lower 8 bits into a byte variable (or 1 bit into a bit variable!). So the only overflow is at this end point, or if an intermediate result ever goes above 65535 or below 0.

** does return the high 16-bits of the 32 bit result of 16x16 multiplication
* returns the lower 16 bits
*/ returns the middle 16 bits
But in each case this is still just a 16 bit number if used as part of a longer mathematical line.

 

[westaust55]

byte variable mathematics

So in line with what hippy stated earlier ,

for byte variable maths it can in fact better to endeavour to complete a computation on a single line, subject to the issues of the simple left to right sequence of computation.

and using a modified version of hippy’s example:

b0 = 116
b0 = 530 * b0 / 2

will work even though the intermediate result of 530 * b0 = 61480
without the need to use word variables which use up another precious byte variable
But

b0 = 116
b0 = 530 * b0
b0 = b0 / 2

will cause an overflow (error in the result) of the byte variable at the first line since b0 exceeds 255

 

[BCJKiwi]

32 bit math;
The key is that there is access to both 16bit portions of the 32bit intermediate result.

So if one 16bit x 16bit operation is carried out (not multiple operations in the one line), then two separate calculations can proceed from there, one on the each of the 16 bit portions of the intermediate result.

This gives the possibility of retaining the 32 bit resolution in the final result - see threads referenced earlier.

 

[Jeremy Leach]

WestAust, I think a clearer example might be:

Example1:
b0 = 200 * 2
b0 = b0 / 2

Overflow occurs on first line when result is put into b0. B0 actually gets loaded with 144 (400 has a most sig byte of 1 and a least sig byte of 144).
Second line gives result of 72.

Example2:
b0 = 200 * 2 / 2

No overflow in final result. Result = 200.

 

[07cmelluish]

does the number always round downwards

 

[Rickharris]

does the number always round downwards

Tested in the simulator (and you could all have done this to answer your questions including generating the appropriate sounds) the division is always rounded down so 9/2=4

11/3=3

 

[MartinM57]

does the number always round downwards

Probably - but it's an excellent question

Have to ask "rounds downwards" compared to what and under what circumstances - a perfect infinite digit accuracy calculator that evaluates any arbitrary expression in a PICAXE-like way (main features being left to right with no brackets)?

I don't think I'd trust the simulator too much - I doubt there is an identical code base between the simulator and the PICAXE runtime firmware (a number of differences have been found in the past) - and I'd certainly check with a calc that produces greater than 0.5 at the end e.g. 23/12 EDIT- sorry Rick - I now see you did that with 11/3

I'm sure (exercise for others ) that some expressions can be proposed where:
- overall, the answer is rounded down to the nearest correct integer compared with an infinite digit accuracy calculator e.g. 9/4, 23/12 etc
- overall the answer is lower and completely wrong (at the integer level) compared with an infinite digit accuracy calculator e.g. 23/12*12
- (maybe) overall the answer is higher and completely wrong (at the integer level) compared with an infinite digit accuracy calculator e.g. errr...can't think of one off-hand

I don't think there is a simple answer - other than to carefully look at every calc you do. In the past, I've used a spreadsheet with a column for the 'perfect maths' outputs for a calc and a column for the 'PICAXE maths' calculations and eyeballed/auto-colour coded the differences (usually resulting in reworking the 'PICAXE maths' to get more appropriate answers)

 

[BeanieBots]

PICAXE firmware will always round down.

Currently, (V5.2.7) there is a known bug in the simulator where some calculations do not always round down. This has been promised to be fixed for the next PE release.

 

[hippy]

On a physical PICAXE, division always rounds down towards zero, simply as a result of bits falling off the lower end of the number which are discarded. 11/2 is %1011 shift right by one bit which is %101 with the 1 which was the lsb shifted off and discarded. 10/4 would be 2.5, %10.1 if decimals existed but this again is truncated to %10 (2) as an integer result.

The Rev-Ed code used in the simulator is different to that used in the actual firmware with all the awkwardness that native number handling on a PC is rarely the same as on the PICAXE so the actual firmware behaviour has to be emulated. The intention is to make calculations in the simulator behave exactly as they would on the PICAXE - sometimes we don't get that quite right, but we do aim to fix those cases.

The usual problematic cases come down to the PICAXE using 16-bit unsigned maths whereas a PC programming language will offer 16-bit signed maths. In such cases $FFFF divided by two should be $7FFF, but on a PC $FFFF is -1, 'divided by two' can become zero or may remain as -1 depending on how that's done. Annoying nuisances which we have to deal with. No need to suggest solutions though as the issue is under control - the example is simply by way of explaining how these issues may come about

 

[MartinM57]

So I just tried

b0 = 23/12*12

in the simulator, and got...wait for it...24.

Was expecting 12, would have been happy with 23, but am surprised with 24.

What sort of rounding is that? - or is that just another instance of the well-known (but not explicitly detailed anywhere, as far as I know) simulator bug?

Don't have a real PICAXE to hand to check..

 

[hippy]

Yes, this likely is the known problem with simulator division, which we are working towards fixing with an upcoming release of software. Probably 23/12 is wrongly becoming 2, times 12 is 24.

Operation on a physical PICAXE will be correct.