Timeline for How can I understand numerical precision of values in Microsoft BASIC (on the Dragon 32)?
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 12, 2020 at 11:15 | comment | added | Graham Lee | Unsurprisingly the error was that I was doing the wrong thing :). "My Python implementation" was actually "my using a Python library" that had a much more nuanced implementation of the algorithm than I thought. If I implement my rough BASIC algorithm in Python I get equally bad answers, so now I need to implement the higher-order algorithm in BASIC. Thanks, everyone. | |
| Aug 12, 2020 at 8:54 | comment | added | Graham Lee | @alephzero good suggestion, thanks, but in this case not true. | |
| Aug 11, 2020 at 20:30 | comment | added | supercat |
On many platforms, a floating-point type which uses a 32-bit explicit-leading-one mantissa could be processed more efficiently than either an IEEE single- or double-precision value, while offering greater precision than the former. It's too bad the C Standard wouldn't allow a conforming implementation to have that as its double type, since there are many cases for which that precision would be adequate, and on some platforms the performance win versus IEEE double would be pretty huge.
|
|
| Aug 11, 2020 at 14:50 | comment | added | alephzero | @GrahamLee just a suggestion for a different cause of the problem: in Python you have two different local variables with the same name in different functions, but in Basic you have one global variable. | |
| Aug 11, 2020 at 11:41 | comment | added | Raffzahn | @ninjalj Sure, but the first bit is still used as sign, isn't it? Above isn't meant fill all details, but show the ranges used to reason about precision. | |
| Aug 11, 2020 at 10:48 | comment | added | ninjalj | Is the exponent really split into sign plus exponent? MBF as used in other machines uses a biased exponent (-128 to get the real value of the exponent) with a special value of 0 exponent meaning 0 for the floating number. | |
| Aug 10, 2020 at 22:35 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 258 characters in body
|
| Aug 10, 2020 at 22:14 | comment | added | Graham Lee |
When I force the types in my Python version to be np.single, they still agree with the double-precision version to 8 s.f. after 210 iterations.
|
|
| Aug 10, 2020 at 22:04 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 2207 characters in body
|
| Aug 10, 2020 at 22:04 | comment | added | Graham Lee | Thanks! That's what I was looking for. I'm seeing errors become meaningful fast in numbers that are ~10^-4, and I'm just using basic maths operations. I'm a little surprised how "bad" my results are, when I've seen pretty good Mandelbrot plots in MS BASIC. It's possible - nay probable - I'm holding it wrong. | |
| Aug 10, 2020 at 21:58 | comment | added | Leo B. | The rounding mode and whether hidden guard bits are used for rounding tie-breaks might matter for the numerical stability as well. | |
| Aug 10, 2020 at 21:45 | vote | accept | Graham Lee | ||
| Aug 10, 2020 at 21:13 | comment | added | Jean-François Fabre | yes, python uses the machine IEEE representation, double for native python, and can use single if numpy is used. | |
| Aug 10, 2020 at 21:12 | history | edited | Jean-François Fabre | CC BY-SA 4.0 |
added 5 characters in body
|
| Aug 10, 2020 at 21:10 | history | edited | Raffzahn | CC BY-SA 4.0 |
added 512 characters in body
|
| Aug 10, 2020 at 21:02 | history | answered | Raffzahn | CC BY-SA 4.0 |