 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 : MMbasic 5.3 Requests.
  Page 8 of 11   |
|||||
| Author | Message | ||||
redrok Senior Member  Joined: 15/09/2014 Location: United StatesPosts: 209 |
Hi Jim;Your undoubtedly correct. That was my conclusion also. So, words to that effect in the instruction should be changed to say a maximum of 32 bits can be handled. On the other hand: My test was outputting a ridiculous number of bits. I can't see why any normal user would want to use this many bits. redrok |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6268 |
Who said anyone here was 'normal'? VK7JH MMedit |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
Viva la difference - and long live abnormality! Greg |
||||
sagt3k Guru Joined: 01/02/2015 Location: ItalyPosts: 313 |
Geoff For the next version, a few of functions to manage popular wifi esp8266 ? Type ..wifi.set...wifi.ping...wifi.httpget...wifi.connect etc  Thanks Sagt3k |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 724 |
MQTT? MMBASIC has no IP Stack, but would it make sense with devices like those from Lantronix "serial to TCP" Bridge? |
||||
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
This one is really easy. I think in the float type variables, actually double type should be used otherwise rounding problems might become a significant issue especially when doing precise calculations. This is very easy to demonstrate in the following example: a=0 r=0.05 For t=0 To 100000 a=a+r Next Print a Question: without executing the code, can you suggest its output? BTW. this reminds me - the numeric block arrow keys are not supported. This always drives me crazy. In addition to that if you press by mistake the numeric '-' or some other key there you unconditionally get thrown out of the editor. http://rittle.org -------------- |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6268 |
I don't have any problems with the num pad. The arrow keys work as expected and the other keys don't cause any issues either. What terminal program are you using? There might be some configuration that needs changing. Jim VK7JH MMedit |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
This has been covered before. It is inherent to floating point (whether double or whatever) on ALL computers. The fix is to understand and then code around it. (It is of course covered by computer science etc books and articles discussing fl pt.) So, you would still have problems with double and you would also cause a slow down and greater use of precious memory. To address the question: 0.05 is NOT stored as 0.05 but as something fairly close to 0.05 and almost every fl pt operation loses some more accuracy so repeated addition is a nightmare waiting to happen. If you need a precise result, you must code around this. It happens on everything using fl pt: IBM/360, Cray/1, IBM PCs, SPARCs, VAXen, PIC32, yes, everything. Most of the time it's easy to code around. Just think it through, in those cases where you actually need accuracy. John |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
The errors you observe when you repeatedly add 0.05 are binary rounding errors. Every numeric base system has inherent errors. We are used to the fact that, in base 10, you can't divide by 3 or 7 or any multiple of 3 or 7. You wind up with a repeating decimal with no exact solution, like 0.33333333. This drives accountants, lawyers and courts nuts because they can't pass a law to make it go away. Base 2, the way computers think, is particularly bad. You can't divide by 3, 5, or 7, or any multiple of 3, 5, or 7. That's why certain languages, like COBOL and dBase, which were written to handle business transactions, use BCD math. Binary Coded Decimal uses binary bits to express values in decades, not bicades. In hex notation it counts to &hA and then stops. &hA is a decimal 09. BCD math requires the language to go through the same programmatic steps we use with pencil and paper to do multiplication and division. It is slow as mollasses but it beats an abacus. Paul in NY |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
Although in a related way they had a go Indiana Pi Bill John |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
For precision i always use an integer. In MMBasic it is 64 bits. Just scale the number to how many digits precision you need. [code] a%=0 r%=5 'Scaled x 100 For t=0 To 100000 a=a+r Next Print a%/100 [/code] For bookkeeping stuff i normally scale by 10000, to keep rounding errors very very small. This will give a max value of 922337203685477.5807 If you are not Paypal then this is sufficient. Microblocks. Build with logic. |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
IBM/360, Cray/1, IBM PCs, SPARCs, VAXen, PIC32 all have compilers offering double precision. Workarounds are really not cost effective. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
They do NOT fix the problem, do they? (Hint: the answer is no.) See the many computer science articles - here's a start wiki Simply coding for the issue (in those cases where it matters) is not hard and is very cost effective. John |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Changing from float to double in the compiler will not make the rounding issues go away but will definitely improve the accuracy. It is an easy fix as well. We have 64-bit integers, it sort of does make sense if the floats are 64-bit as well http://rittle.org -------------- |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
But will use up more RAM and make programs a lot slower. It may break some existing programs. Overall, Geoff will decide, but I understand you have the source code so you could rebuild it with 64-bit floats for your own use. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
i'd be interested in hearing what the flash overhead of going to 64-bit floats was, especially if it could be shoe-horned into an mx170. but, as others have said, the extra digits would have limited usefulness to the vast majority of micromite users. the micromite is, after all, foremost a microcontroller. of course, since we have 64-bit integers, someone could always write a comprehensive set of c-functions that used integers containing 64-bit floats: i = fsin(j) i = fcos(j) i = ftan(j) i = fasin(j) i = facos(j) i = fatan(j) i = fnegate(j) i = fpower(j, k) i = fadd(j, k) i = fsub(j, k) i = fmul(j, k) i = fdiv(j, k) s$ = float2string(i) i = string2float(s$) r = float2real(i) i = real2float(r) etc... these c-functions would be simple wrappers for C library functions, i'd imagine creating them would be relatively straight forward. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10197 |
Actually close to impossible, you can't call library functions from Cfunctions as the library code, which doesn't exist in the Micromite firmware, would have to be included in the Cfunction and there doesn't seem to be a way to get the relative addressing to work. You could put hooks into the Micromite firmware which reference the double functions and then give CFunctions access to them. This would force the compiler/linker to include the double functions in the Micromite firmware (increasing its size) and make them callable from CFunctions - this is something I've asked Geoff to look at but is probably only possible in the MX470 |
||||
| isochronic Guru Joined: 21/01/2012 Location: AustraliaPosts: 689 |
BTW, wrt the given example, ie, a=0 r=0.05 For t=0 To 100000 a=a+r Next Print a and using a different language, for output in six sigfig and two dp, I get: single precision (eg micromite) gives the answer 4999.28 double precision gives the correct answer 5000.00 which resolves the calculation as required. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4033 |
So what? It'll fail for some other values. It's inherent. Just get used to it!! John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
that is a shame. how about using a different maths library, or would the footprint become prohibitive? i could see it becoming an enormous project with limited user appeal. an interesting idea might be a second MX170 (or 150) programmed up as a dedicated maths coprocessor cheers, rob :-) |
||||
| Page 8 of 11 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
