big float constant

[janni]

Somehow big constants of type float are not accepted. Cannot declare in a module constant larger than ca. 9.2E18 (anything bigger causes rest of module to vanish from Code Explorer and compilation) and attempt to declare such constant in main module may even cause SF IDE to crash .

[Jerry Messina]

I seem to recall seeing something like this too, but it's not that specific in that large values evaluate ok for me, much larger than what you called out.

I think what happens is the Code Explorer is constantly evaluating expressions for display, and if you happen to be in the middle of editing a value it can sometimes result in an exception occurring, which stops the Code Explorer window from further updates.

Another thing that can cause issues with the Code Explorer is the number of files and the order of includes. I typically have projects with a few hundred files and that can cause 'out of memory' issues that result in having to use task manager to kill it. In cases like this when working with large projects I find it more stable to turn off the Code Explorer 'Explore Includes' (Code Explorer window | down arrow | uncheck 'Explore Includes').

[Jerry Messina]

I think I just ran across exactly what you're seeing.

I had this:

Code: Select all

const f1 = 9.2E19 
const f2 = 1.345678E37
const f3 = 1/f2

I then edited it to:

Code: Select all

const f1 as float = 9.2E19 
const f2 as float = 1.345678E37
const f3 = 1/f2

As soon as I changed f1 the others vanished from the explorer, and when I changed f2 it crashed.

[janni]

Yes, it's IDE problem (I should have posted it in IDE forum) but there's also a problem within the compiler. Under MPLABX one also cannot use too big numbers as they're reported out of range.

According to Help file, max range for float type is -1e37 to +1e38 though internally it's close to +/-3.4E38 ($FF800000 or $FF000000). Compiler starts to protest somewhere above 9.2E18 so I couldn't define a maxFloat constant reflecting the real maximum. Interestingly, one may go up to about 6.0E37 when assigning value to a variable.

[Jerry Messina]

If you're defining a const then just drop the 'as float' and you'll get a much wider range

Code: Select all

const C1 = 3.40282366921E+37         // don't use 'as float'

The compiler expands all floating-point constant values to a fixed-point representation, so anything past approx E+/-37 can cause issues.
I'm not sure that a 'maxFloat' const would do you much good anyway.

[janni]

The compiler expands all floating-point constant values to a fixed-point representation, so anything past approx E+/-37 can cause issues.

Apparently not all floating-point constants, just those explicitly declared as float . And that's about the limit of approximately 9.2E18 (64 bit integer limit). The higher limit is inexplicable.

I'm not sure that a 'maxFloat' const would do you much good anyway.

It's useful when one doesn't want to use assembly in math functions library but check/mark an overflow. And to think I was accused of liking assembly too much .

The overflow value set in SF floating-point routines is 3.40282366920938E38 ($FF000000), not 3.40282366921E+37, so Im still unable to declare proper value in Basic. Compiler balks at anything greater than $FC4CCCCB (6.80564642571034E37).

[janni]

The more I look at it, the more it seems like simple mistake. Maximum positive value in Microchip notation is 6.8056469E38 ($FF7FFFFF) and that's exactly the value that compiler blocs but with decimal power of 37 instead of 38.

Naturally, as the internal floating-point library assigns +/-3.4028236E38 (exactly $FF000000 or $FF800000) as an overflow, this should probably be the best limit for numbers accepted by the compiler.

[Jerry Messina]

Apparently not all floating-point constants, just those explicitly declared as float

All floating point values are converted from an exponential format to a straight decimal format before assembly.
The buffer is approx 43 chars (42+sign) in length, so this can put a limit on what's actually used.
Here are some examples

Code: Select all

// small numbers
fr = 1.23456789123456789123456789E-30
'fr_M8_F32 = 0.0000000000000000000000000000012345678912
fr = 1.23456789123456789123456789E-37
'fr_M8_F32 = 0.0000000000000000000000000000000000001235
fr = 1.23456789123456789123456789E-38
'fr_M8_F32 = 0.0000000000000000000000000000000000000123

// large numbers
fr = 1.23456789123456789123456789E+30
'fr_M8_F32 = 1234567891234570000000000000000.0
fr = 1.23456789123456789123456789E+37
'fr_M8_F32 = 12345678912345700000000000000000000000.0

fr = 6.80564693E+37         // largest value that does not generate 'const value out of range'
'fr_M8_F32 = 68056469300000000000000000000000000000.0
fr = 9.856789123456+37      // however some values past that are accepted but generate incorrect values
'fr_M8_F32 = 46.856789123456000001

The more I look at it, the more it seems like simple mistake. Maximum positive value in Microchip notation is 6.8056469E38 ($FF7FFFFF) and that's exactly the value that compiler blocs but with decimal power of 37 instead of 38.

That could be.

There are some flags used by the floating-point libs that don't appear to be documented.

Code: Select all

include "system.bas"
public dim
    fp_flags as SB_SV7,                         // floating point flags
    fp_overflow    as fp_flags.booleans(1),     // multiply, addition, float to int
    fp_underflow   as fp_flags.booleans(2),     // divide, multiply(?)
    fp_div0        as fp_flags.booleans(3),     // divide by zero
    fp_rounding    as fp_flags.booleans(6)      // rounding on by default

I can't attest to how well/if they work... I've never tested that part of the code.

[janni]

All floating point values are converted from an exponential format to a straight decimal format before assembly.
The buffer is approx 43 chars (42+sign) in length, so this can put a limit on what's actually used.

This should be enough to hold maximal Microchip format value. Probably the conversion routine is a problem then. Especially if some larger values are incorrectly converted to text.

There are some flags used by the floating-point libs that don't appear to be documented.

That's quite enough documentation to know what takes place in calculations. These flags are implemented and work (I already adjusted respective flags in my version of integer math to have the same meaning). Every program starts with setting the rounding bit (it's so-called 'unbiased rounding' that increases accuracy in more complex calculations). That's why System library warns against modifying D24 aka SB_SV7.

I haven't fully checked the floating-point library yet, but it seems to work nicely, except for comparatively slow multiplication. So far I've implemented a faster routine (almost 3 times faster) making sure that power series calculations that I use a lot are quick enough.

[Jerry Messina]

This should be enough to hold maximal Microchip format value

For values less than about 1E-33 you begin to lose digits...

Code: Select all

fr = 1.2345678E-33
'fr_M8_F32 = 0.0000000000000000000000000000000012345678
fr = 1.2345678E-34
'fr_M8_F32 = 0.0000000000000000000000000000000001234568
fr = 1.2345678E-35
'fr_M8_F32 = 0.0000000000000000000000000000000000123457
fr = 1.2345678E-36
'fr_M8_F32 = 0.0000000000000000000000000000000000012346
fr = 1.2345678E-37
'fr_M8_F32 = 0.0000000000000000000000000000000000001235

[janni]

Indeed, though it'll matter only if there's an automatic conversion of declared value to text and back. I still don't grasp the significance of the conversion to text other than, when incorrectly done, it either causes rejection of the value or crashes the IDE. If it serves to consecutive evaluation of integer value then anything smaller than one is of no importance.

[Jerry Messina]

Sorry for not being clear... there are a few different issues here.

One is the IDE display in the Code Explorer window and the behavior when using 'const as float' and 'const' to define floating point values. That is strictly an IDE issue and has no effect on the actual values other than possibly limiting what you can display or declare that way. If you put the values directly in code that goes away (not a fix, just an observation).

Second is the max float value limit of 6.8056469E37 vs E38. That's an issue with the front-end compiler and its limit. Seems like a mistake to me.

Third, ALL floating-point values, no matter how you specify them (const, const as float, or directly in code) are converted to that text format by the frontend compiler before the code is actually constructed by the backend and the assembly language result is generated. So, any truncation that happens to the values in that format will result in the mchip hex float representation for the values being different from what is specified.

[janni]

That last is disturbing . I don't know why fp values would need to be converted to text form without exponent (mistake in choice of converting function?), usual algorithms converting fp value to Microchip format do not require it, but apparently the person who developed this haven't foreseen all the consequences. Any chance you can change that?

[Jerry Messina]

Doubtful, but I'll check.

[Jerry Messina]

This has been addressed in the latest compiler version 2.2.3.8

The range of floating point values accepted is defined in system.bas as:

Code: Select all

// microchip 32-bit floating-point limits
public const
   FLOAT_MAX as float = 6.80564693E+38,
   FLOAT_MIN as float = 1.17549435E-38

The issues with the IDE Code Explorer display of floating point have been addressed, and the truncation of small values has also been fixed.