Hello David,
If you do look into using arrays and the string to integer conversion turns out
to be the performance problem, then the only other thing I could suggest, which
would be very quick (but not for the faint-hearted) would be to write a C
function that just took two characters from a string parameter starting from a
specified position and returned the bits as the (integer) answer. But, before
I did that, I’d want to satisfy myself that the string to integer conversion
genuinely was the bottleneck. If you’re tempted to go down this route, there
are some examples in the plugins directory.
Don
> On 11 Apr 2017, at 21:28, David Gamey <[email protected]> wrote:
>
> 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 <[email protected]>
> To: David Gamey <[email protected]>
> Cc: Clint Jeffery <[email protected]>; Unicon Group
> <[email protected]>
> 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 <[email protected]
>> <mailto:[email protected]>> 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
> <http://sdm.link/slashdot>
> _______________________________________________
> Unicon-group mailing list
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/unicon-group
> <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
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
