mIRC Home    About    Download    Register    News    Help

Print Thread
#271207 19/01/23 06:29 PM
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Historically the identifiers that interpreted scifi text into integer were treating 'd' the same as 'e'. However in .bf mode they are not:

//echo -a $int(1.23e2) $int(1.23d2) vs %null.bf $int(1.23e2) $int(1.23d2)

result: 123 123 vs 123 1

I have no opinion on whether $int $abs etc should be fully compatible with .smallfloat mode, or should not see this notation in .bf mode at all. This is the only place I've ever seen where 'd' was synonymous with 'e' when interpreting notation.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. This conversion is handled by the basic atof() CRT call which converts text to a float and is used throughout mIRC. On the atof() page, Microsoft says that support for 'd' and 'D' is non-standard and it looks like it was removed in later versions of the CRT. mIRC is currently compiled with Visual C++ 2008. I could probably add support for 'd' and 'D' to MAPM to make it work in the same way as non-bigfloat.

Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
Just to be clear, I was referring to 'd' support for the existing identifiers when they handle the notation. For reasons I describe in my other post, I don't think it's a good idea for the new integer-only identifiers to try to support the approximation of this notation, since the approximations of 1.23e2 style of fractions can contain whatever rounding error comes from the source, which wouldn't be from mIRC because I'm not aware of mIRC itself creating this notation


Link Copied to Clipboard