Inline
> On 11 Apr 2017, at 16:24, David Gamey <david.ga...@rogers.com> wrote:
>
> Don,
>
> The problem is instruction set and translator. The translator is the bigger
> issue.
I guess we’re looking at from different perspectives. The translator may,
indeed, involve more work but the instruction set that it has to work with is
(as Clint pointed out to me) more fundamental. In either case, for the problem
to go away both sets of work will need to be done.
> I'd thought of converting to a list as an option. I'd not considered arrays.
> I'll have to consider that. Thanks.
>
> The pairs are a bit strange as I need to have even and odd aligned pairs. So
> for "123" I need both 12 and 23. It's the shear volume of digits that is the
> challenge. I only found this as I was benchmarking out to 10^11 digits.
I’m probably not understanding the subtleties of what you want to achieve. But
to provide a look-up array that maps all possible pairs of characters to a
number takes 256x256x(size of integer). So, even on a 64bit integer machine
it’s only 0.5MB. And, once the array has been allocated and the values
calculated it should place no further burden on the runtime storage allocation
no matter how many (pairs of) digits you want to process. If I’ve got
completely the wrong end of the stick, just ignore me :-)
Don
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
