Don,
I'm not at all concerned about a little time/memory trade-off space. I seem to
be caught in a bit of a catch-22 on this. To use a list or array, I'll need to
convert the string to integer and then perform the look up. The only other l
mechanisms I can think of are using ord, tables (with the trapped variable
issue), or something like find. Right now even with the collections these are
from slowest to fastest: find(), ord(), integer(), table[].
So using a table lookup of a string is probably the best option for now. It's
still acceptable up to about 10 billion operations. I'll probably benchmark
integer() and list/array lookup just for comparison and in case the collections
become a problem.
Thanks
David
From: Don Ward <d...@careful.co.uk>
To: David Gamey <david.ga...@rogers.com>
Cc: Clint Jeffery <jeffe...@uidaho.edu>; Unicon Group
<unicon-group@lists.sourceforge.net>
Sent: Tuesday, April 11, 2017 3:34 PM
Subject: Re: [Unicon-group] Unexpected garbage collections
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
------------------------------------------------------------------------------
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
