News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Valid number formats

Started by jj2007, April 18, 2010, 09:42:08 PM

Previous topic - Next topic

jj2007

I am working on the MovVal dest, "123" macro. Some polishing needs to be done, but it seems most strings are now converted correctly - see table below.

Question: Would you miss any specific number formats not yet listed below? Octal is not foreseen, decimal, hexadecimal and binary should be enough.

Thanks for any hints, jj

         Result (rounded)  expected     ... from string
1   OK   1.2346e+25      = 1.2346e+25   12345678901234567890123456
2   OK   123.00          = 123.00       123
3   OK   10101.0         = 10101.0      10101d
4   OK   -1010.1         = -1010.1      -10101e-1
5   OK   1.2345e-123     = 1.2345e-123    (  1.2345E-123  )
6   OK   -0.12340        = -0.12340       -1.23400E-1
7   OK   -0.12340        = -0.12340       -1.2340E-1
8   OK   1.2300e+11      = 1.2300e+11   123.E9
9   OK   0.0     = 0.0  .
10  OK   1.2000          = 1.2000       1.2
11  OK   1.0000          = 1.0000       1.
12  OK   0.20000         = 0.20000      .2
15  OK   -1.2300e-99     = -1.2300e-99  ( -1.23e-99 )
16  OK   -1.2346e+05     = -1.2346e+05  -1.23456789e5
17  OK   -1.2346e+12     = -1.2346e+12  -12345678.9e5
18  OK   1234.6          = 1234.6       1.234567890e3
19  OK   1.2346e+11      = 1.2346e+11   123456789.0e3
20  OK   1.2346e+12      = 1.2346e+12   1234567890e3
21  OK   1.2300e+05      = 1.2300e+05   123e3
22  OK   12.000          = 12.000       12
23  OK   21.000          = 21.000       10101b
24  OK   21.000          = 21.000       10101y
25  OK   65793.0         = 65793.0      10101h
26  OK   74565.0         = 74565.0      $12345
27  OK   74565.0         = 74565.0      0x12345
28  OK   1.1932e+06      = 1.1932e+06   1234e5h
29  OK   8.1986e+16      = 8.1986e+16   123456789012345h
30  OK   12.000          = 12.000       1,2d
31  OK   1.2346e+12      = 1.2346e+12    (123,456,789,0e3)

dedndave

hiyas Jochen
i am sure you have this covered, but i did not see it in the list and i know you want to test it

hexidecimal values that require a leading zero in the form:

0Ah
0BADC0DEh
0BEACH

i suppose that they should be interpreted as variable names or spark an error if the leading zero is not included

jj2007

Quote from: dedndave on April 18, 2010, 10:18:46 PM
i suppose that they should be interpreted as variable names or spark an error if the leading zero is not included

Hi Dave,

Thanks for your quick reply. These examples work, up to a 64-bit string as input. I hesitate to insist on a leading zero because the routine should be able to read from external (non-Masm) sources, e.g. textfiles, where the formats abcdefh, 0xabcdef and $abcdef might be valid.

32  OK   7.0356e+05      = 7.0356e+05   $abc45
33  OK   7.0356e+05      = 7.0356e+05   0xabc45
34  OK   -6.0669e+18     = -6.0669e+18  abcdefabcdef1234h

qWord

hi,
you may want to support the f (float) and d (double) suffix for floating point values
FPU in a trice: SmplMath
It's that simple!

oex

Real number formats only or do imaginary numbers count?
We are all of us insane, just to varying degrees and intelligently balanced through networking

http://www.hereford.tv

jj2007

Quote from: qWord on April 18, 2010, 10:59:58 PM
hi,
you may want to support the f (float) and d (double) suffix for floating point values

Hi qWord,

include \masm32\include\masm32rt.inc

.code
mydw dd 123d ; works fine, but it's an integer
;myr4 REAL4 123f ; chokes with error A2048:nondigit in number

start: exit
end start


So there should be no 123d suffix in the source string. Unless you meant its usage in printing:
MovVal xmm1, chr$("1234567890.12345678")
movups MyR8, xmm1
Print Str$("    xmm1=%If\n", MyR8)

Output:     xmm1=1234567890.12345672 (note the reduced Real 8 precision)

@oex: I'll keep it to real numbers. The NaN stuff is a can of worms, and few people really need it.

qWord

jj, I was talking of something like:
1.0f, 1.f or 1.E-1f (c/c++)
masm accept this too .... but it also accept something like:
REAL4 1.E-1xyz
-> 0.1
  :bg
FPU in a trice: SmplMath
It's that simple!

jj2007

Quote from: qWord on April 19, 2010, 02:02:50 PM
jj, I was talking of something like:
1.0f, 1.f or 1.E-1f (c/c++)
masm accept this too .... but it also accept something like:
REAL4 1.E-1xyz
-> 0.1
  :bg

OK, accepted (it didn't cause me extra work because MovVal ignores trailing chars anyway  :bg)

tenkey

Quote from: jj2007 on April 18, 2010, 09:42:08 PM
         Result (rounded)  expected     ... from string
11  OK   1.0000          = 1.0000       1.
12  OK   0.20000         = 0.20000      .2


If you are going to allow the above formats (missing a leading or trailing 0), will you allow the signed and exponential variations of the above formats, too?
A programming language is low level when its programs require attention to the irrelevant.
Alan Perlis, Epigram #8

jj2007

Quote from: tenkey on April 23, 2010, 08:27:04 AM
Quote from: jj2007 on April 18, 2010, 09:42:08 PM
         Result (rounded)  expected     ... from string
11  OK   1.0000          = 1.0000       1.
12  OK   0.20000         = 0.20000      .2


If you are going to allow the above formats (missing a leading or trailing 0), will you allow the signed and exponential variations of the above formats, too?
It seems so...
OK          -0.0010000      = -0.0010000   -1.e-3
OK          2.0000e-04      = 2.0000e-04   .2e-3
OK          -2.0000e-04     = -2.0000e-04  -.2e-3