World: r3wp

what's the best way to convert a hex string to a decimal value in 
R3?

One way is to start with an issue! rather than hex
    >> to-integer #100
    == 256

perfect... just what I needed  thanks  :-)

I got some strange results with decima!

But check it works for large values first.....

>>  to integer! #{2710}         
 
== 10000


>>  to decimal! #{2710}
 
== 4.94065645841247e-320

decimal is broken with issue.

>>  to decimal! to binary! 10000
 
== 4.94065645841247e-320

>>  to integer! to binary! 10000 

== 10000

Probably explained by this Curecode report
   http://www.curecode.org/rebol3/ticket.rsp?id=547

There is something that doesn't seem correct about the following: 
:

>> to decimal! to integer! to binary! 10000

== 10000.0

>>  to decimal! to binary! 10000         
 
== 4.94065645841247e-320

not a bug, as explained in the curecode ticket

decimals and integers are not hard coded the same way in a binary

00

Peter: 

>> to binary! 10000.0
== #{40C3880000000000}

>> to binary! 10000
== #{0000000000002710}

Why do you think they should be the same?

I don't. It's the behaviour of to-decimal that I don't understand;

>> to decimal! #{0000000000002710}
== 4.94065645841247e-320

In R2 this would raise a script error:

>> to decimal! to binary! 10000   
** Script Error: Invalid argument: #{3130303030}
** Near: to decimal! to binary! 10000

In R2:
>> to binary! 10000
== #{3130303030}

So we get the ascii value of each digit in the number. In R3:

>> to binary! 10000
== #{0000000000002710}


The number is seen as a 64-bit integer, and we get the binary representation 
of that.

then why do you think, that this is a bug?:

>> to decimal! to binary! 10000.0
== 10000.0

If you want to know more, read http://www.rebol.net/wiki/Decimals-64

Maxim: "what's the best way to convert a hex string to a decimal 
value in R3?" - Try this:
>> pi
== 3.14159265358979
>> enbase/base to-binary pi 16
== "400921FB54442D18"
>> to-decimal debase/base "400921FB54442D18" 16
== 3.14159265358979
>> to-decimal debase/base enbase/base to-binary pi 16 16
== 3.14159265358979


You asked for the best way: No method that uses the issue! type for 
binary conversions could be considered the best way.

Not sure what specific data transformation Maxim needs.

I'd be interested in the REBOL code to do would would seem to be 
a simple transformation:
  How do I get from:

    #{0100}   ;; two bytes of binary, perhaps read from an external file
   to:

    256          ;; the equivalent integer (given the implicit endian 
    assumptions)

if it's for storing usage, then restoring, perhaps the base 64 format 
is enough.

>> enbase to-binary pi
== "QAkh+1RELRg="

>> to-decimal debase enbase to-binary pi
== 3.14159265358979

and it take less size (besides, it has always the same length)

Ah, it's those implicit endian assumptions that can trip you up, 
Sunanda. But here's a good method that for big-endian 64-bit on R3:
>> to-integer #{0100}
== 256

that for -> that works for

Thanks, Brian......I'd tried that, and it did not work for me. Must 
have been having one of those blond moments, because it works now 
:)

newb instant ;-)

It should work for 32-bit integers too, but there isn't yet a build 
that supports them (though the source does).

U mean something like this ?
>> to-integer #{01000000}
== 16777216

I mean 32-bit integer! type, not 32-bit binary encoding converting 
to the current 64-bit integer! type.

It's supposed to be an R3 build option for embedded of legacy systems 
that don't support 64-bit integer math.

of -> or

and my connversion is not exact, because we don't have the sign bit 
expansion

Nice puzzle.

Giving a signed 16bit binary integer, give the corresponding R3 integer.

A one-liner solution (without any test) would be  appreciated

I don't like it very much, be i think i got something...


>> signed16: funco [n][(complement -1 + shift n -15) and -65536 or 
n]
>> signed16 to-integer #{FFFF}
== -1

Well, that math solution is better than the binary manipulations 
I was doing.

Idea comming from a forth kernel i've done

I like the discussion occuring because of my simple question... all 
of your answers are pre-emptively solving other issues I was going 
to have in the future.  :-)

Argh.... I felt vaguely, that there was an easier way

>> signed16: funco [n][32767 - n xor 32767]
>> signed16 to-integer #{FFFF}
== -1

32767 is found like this for signed 16bit integers:
2 ** 15 - 1

Ladislav: The behaviour of to-decimal appears to be different from 
the documentation for the decimal! datatype. That's why I think that 
to decimal! to binary! 10000.0 is a bug.

What documentation? Link it so we can fix it.

A lot of the R3 manual is still R2.3 placeholder docs, not updated 
yet. We changed the behavior of TO throughout R3, so those docs are 
more likely to be wrong. We definitely need volunteers to help with 
the docs. For now, the most accurate documentation for a lot of topics 
is still CureCode.

Wow .. I see Amiga R3 build is pending !

Can we ask Carl for an ARM build?

not after the leg though ...

I want WinMobile build :-)

I think that we should put empahsis on main OSes, and then on mobile 
ones - OS-X - dunno how to use anything like R3, unless the phone 
is jailbroken, WinMobile, Android, WebOS (Palm), Symbian(?), BlackBerry(?)

I think that mobile platforms are trend now. And it will be even 
more in upcoming years. New Google phone comes from HTC, it will 
be Snapdragon CPU (1GHz) based - lot's of power.