speedgains with a less verbose conversion about cracknum HOT 5 CLOSED

In that case I'd suggest do a separate program for bulk converts and use crackNum for when you want finer level of detail. It'll be as simple as putting the function I posted above in a file and compiling. (You can add a version that does the double-precision as well.) It's best to keep the two separate I think, and you can pick whichever you want.

from cracknum.

CrackNum isn't really designed for speed; or for such bulk conversions. This is because it supports all sorts of floating-point formats (i.e., with varying exponent and significand bits) and thus the conversion is done via a complicated process to support all these formats. Turning of verbosity wouldn't really save anything, as the bulk of the time is spent elsewhere.

But if all you're trying to do is to convert a float to its hex-layout, then you should simply use a much simpler program to do so, instead of going through CrackNum. It could be as simple as this:

import Data.Char
import Data.ReinterpretCast
import Numeric

floatToHex :: Float -> String
floatToHex f = chunk $ map toUpper $ showHex (floatToWord f) ""
 where chunk "" = ""
       chunk xs = let (f, s) = splitAt 4 xs in f ++ ' ' : chunk s

An example use:

*Main> putStrLn $ floatToHex 123456789
4CEB 79A3

I'd expect this to run significantly faster than crackNum, allowing you to do bulk processing.

from cracknum.

Thank you for the feedback, will look into it ! :)

from cracknum.

I can potentially add a bulk-convert option to CrackNum for single and double-precision only, which bypasses the heavy part. Though I still think a separate program is best for this purpose. Let me know if that's not possible for you for whatever reason.

from cracknum.

I can potentially add a bulk-convert option to CrackNum for single and double-precision only, which bypasses the heavy part. Though I still think a separate program is best for this purpose. Let me know if that's not possible for you for whatever reason.

A separate program or high-level language, for me, would not be my first choice as the special sauce that is crackNum sets it apart from those two other options. In that line of thought a bulk integration would IMHO be a fine addition for crackNum, less verbose but integrated even at the costs of being less speedily then a separate stand alone program but with less overhead then a high level language solution such as Python.

from cracknum.