 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Problem with MM+ matematics
Page 1 of 2   |
|||||
| Author | Message | ||||
kiiid Guru  Joined: 11/05/2013 Location: United KingdomPosts: 671 |
I noticed recently that MM+ (and my extension probably MM in general) has some bug in the floating point handling. Operations with very small or very large numbers often lead to completely wrong results or error messages. For example try this: z=1E44 or z=1E-44 Now print the value of z. In both chases it will be wrong. I have some program which makes intensive FP operations and sometimes it exits unpredictably with an error "number too large" (or something like that). And that considering that fact that all the numbers there are smaller than 100 but with many digits after the decimal point. Geoff, fs there any way to deal with this? Maybe compile the MM+ source to work with doubles instead of floats? http://rittle.org -------------- |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
See the manual for floating point range i.e. 3.40282347E+38 to 1.17549435E-38 Changing to double is a huge job. Workround approach is to keep powers of 10 in a second integer variable |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
It's single precision IEEE754 I think. (Which does not include 1E44, 1E-44, etc.) As PeterM says, not easy to change. John |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Actually in my program the numbers are not even close to this range. Normally they are up to 6-7 digits after the decimal point, yet occasionally the program fails and wipes the value of the variable replacing it with something completely invalid like 1.237276E+22 or the sort. This happens when a very small number gets added to or subtracted from another number, not necessarily small. Again, the numbers that I operate with (actually angles for a servo) are within the range -60...+60 and the precision no greater than what a float can take, but this still happens, especially when the numbers are very close to 0. Unfortunately it is totally unpredictable, so I can't post a reproducible example. http://rittle.org -------------- |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
could you perhaps modify your program so that when it sees a completely invalid result it automatically saves all the relevant variables in flash and sets a flag to indicate that an error has occurred? when the error happens, you would then have permanently saved the set of values that caused it, that you could retrieve and post. cheers, rob :-) |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
This is very strange. MMBasic uses the Microchip single precision floating point library which is in wide use and is carefully optimised. So it hard to see that there could be such a severe bug in that. Also, I would have thought that such a bug in MMBasic's expression evaluation routines would have surfaced by now. I have just run a series of tests with a sequence of floating point operations and they executed perfectly so the mystery continues. It sounds as if something is changing memory that it should not be changing. It could be a bug, or a CFunction, or peak/poke. It would be very handy if you could make the problem consistently appear (hard, I know). Geoff Geoff Graham - http://geoffg.net |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
@Geoff - possible bug v5.0 on 28pinner?? Wasn't sure where to post the following but it is linked to this thread's title talking about 'big' numbers. If at the command prompt you type: PRINT 7^7^7 the answer comes back as: 6812400838176574343 BUT if you type: A=7: PRINT A^A^A then the answer shows as: -9223372034707292160.(((((e+2147483647 Any number bigger than 7 'loaded' into A; and then printed as: A^A^A will give exactly the same -922..... result WW |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
What about if you type A%=7: print A%^A%^A% ? |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
matherp is right. 
Ignore my typos that the command prompt reminded me of...... Smoke makes things work. When the smoke gets out, it stops! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Initially: "Error: Variable or constant exists with a different type" 
Anyway: B%=7: PRINT B%^B%^B% gives the 6812400.... (correct) answer. By the way, I am not 'needing' the correct mathmatical answer; just pointing out that the 'format' of the A^A^A result is 'incorrect'; and is also exactly the same for numbers > 6 for this example. IMHO it would be better if 'number too big' could be displayed; assuming it is possible to 'trap'. WW EDIT: Grogs beat me to it; but note I am NOT after the answer . . . .
|
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
I was just explaining the discrepancy in your results a=7 sets a as a float unless you have "option default integer" set, whereas 7^7^7 interprets 7 as an integer as there is no decimal point print 7.0^7.0^7.0 gives your error which is one for Geoff to see if he can trap the overflow |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
I am now curious as to where '-9223372034707292160.(((((e+2147483647' comes from  |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
It comes from a special bug. It is called the floating bug. It grows exponentially once it gets close to a point and amazingly also when it is far away from a point. Remedies against this bug include using bits as they are normally used, instead of grouping bits to specific functions. The groups will then not agree as they are on the left and on the right. They will never agree to a single point. Raw bits are the best remedy. The more the better. 64 bits should be sufficient to kill any floating bug instantly. Microblocks. Build with logic. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
It's a bug! Those parens are just some buffer corruption or the like. It's called what now? How about a URL? John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
oh no, not a buffer overrun bug! i thought microsoft had cornered the market on them. cheers, rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
MMBasic does not attempt to check for arithmetic overflow. It would slow the interpreter too much and given the huge range of floating point numbers, would only occur in extreme circumstances - like those listed above. Geoff Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Just as an idea for tracking problems coming from unknown or intermittent sources like this - how hard would be to implement some short length TRON-style list, which would return the line numbers of say the last 10 executed lines? This functionality already exists and can be enabled by the TRON command, but it would have been extremely helpful if I was able to list and see the last few lines of executed code before an error has been raised, or even if I hit Ctrl-C. That would be an incredibly good tool for tracking down problems in longer programs. Extending this even further by being able to see the stack of called SUBs - that's already going pro.  http://rittle.org -------------- |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Geoff Unless I'm missing something 7.0^7.0^7.0 = 6,812,400,838,176,574,343 = 6.812400E18 Which shouldn't overflow. "a=6.812400E18" works fine and "print a" reports the correct number A bug in in the Microchip powf function? |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Done as (7^7)^7 the result is 256,923,577,521,058,878,088,611,477,224,235,621,321,607 About 2E41 I think - so beyond single precision's range. Linux bc gives me a far larger value for 7^(7^7) (goes off the screen). John |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
That's interesting so the 64-bit integer version is also wrong but doesn't look as silly. I've just checked oon Excel and it agrees with your figure exactly |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
