AutoHotkey Community

For when you need to make those quick conversions...
e.g. toBin(0x5e3c) = 00000101111000111100; toBin(-16) = 11110000; toInt(10111) = 23; toInt(00111111) = 63



Note: toInt() will return signed values if the second parameter is true/1; the second parameter of toBin() should be how many least-significant bits to return (false/0 = to the nearest 4 bits) e.g. toInt(111110000001, true) = -127, toBin(12, 5) = 01100

Download (<1 KiB)

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

I like it!

I think that your title is misleading. "Lite" is an understatement!

One of the weakest areas of my coding is that my code is very un-optimized and usualy a lot longer and more complex than it needs to be. From studying examples like this and stuff that people like Laszlo write helps me to learn about how to optimize things.

_________________

"Power can be given overnight, but responsibility must be taught. Long years go into its making."

There were a few binary conversion routines already posted, like in here. The ones above are very short and nice. I have been using a little longer versions, which handle negative numbers and you can specify the number of bits.

Lite in the sense that it's quite compact

I've updated toBin() with Abs(p) + (!p * StrLen(Abs(n)) << 2) to return a specified number of bits. I also replaced modulo 2 with & 1 (can't believe I forgot this). I copied your idea to make toInt() support negative numbers by using n - (1 << StrLen(b)) * s, I thought inverting bits was the only way but this is great.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

I wanted to see if I could map hex to decimal using the Asc table. Here's what I came up with (not optimized):
Just a quick result from one of my many trivial experiments

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

I just updated the function with an LSB-skip parameter ('c'). Previous versions are still available.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

The following line of your new function is not guaranteed to work in the next release of AHK. (See here)

You could never know, what the following line does:
"+" is of higher priority than ":=", so first i+u is computed, but it is not a left value, so it were a syntax error. However, AHK has a bunch of semi- or un-documented rules to handle such code. In this case, the precedence of ":=" is raised, and first "u:=i<0" is computed, resulting in the new value of u, added to i. Because the applied rule is not described in any details, this code might provide different results in the next release of AHK.

I am sorry, Titan! Creative coding is not supported.

Why? Here's the sequential evaluation order:

1. c is incremented
2. Character from SubStr is obtained
3. l subtracted by c
4. 1 bit shift left by previous value
5. SubStr value multiplied by previous value
6. i assigned to previous value

I don't see how that could change. If what you said was about the prefix increment I doubt it's priority will be reordered.

I'm no fan of terse and rigid syntax rules. If it happens (and I certainly hope not), parenthesis can be added for an explicit evaluation order.

I'm confused, aren't you conservative here...

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

You have the shift-left operator. Is its left-hand side or right hand side is evaluated first? Chris refused to commit to either one, but they lead to different results. You must not assume that ++c is evaluated earlier than 1-c. It is a pity, but if a variable appears more than once in an expression, its value must not be changed by a side effect (:=, ++ etc.).
To be sure, add them now.
I am. Some newbie copies this line to his script, where it will not work, and we have to debug his code in the ask-for-help section, a year from now. Can we say, please use parentheses? It worked for a code guru, why and how should he change it?
There is a significant difference. Those languages precisely specify the rules, AHK does not. Their users can rely on these rules for a long time, we cannot, since they are undocumented features.

I already directly countered this argument in this topic. Do you want to debate it or just advertise your view? Because you still haven't responded.

@jonny: Don't we agree? I tried to convince Titan not to write obfuscated code, because it will cause us extra work later. I didn't say (here) that AHK should not allow these funny constructs, but beg not to use them.

I gave up arguing in the other thread. I should be happy having whatever AHK can offer. Up to a year ago I used AHK in my day-to-day work, prototyping algorithms, put together some quick-and-dirty automating tasks, but not any more. I still have my thousand line main script, with keyboard remap, analog clock, calendar, clipboard management, etc. always running, but AHK's goal to allow simple scripts to be even simpler is not for me. I just have different needs.

If I'm not mistaken, rhs like in all other languages. Chris would not frivolously morph the language without regard for compatibility; if something does change it will be stated in the release notes.

It's l - c (not 1). According to the documentation pre-increment/decrement "is performed immediately".

Why not? If we know the order or experiment with trial & error it shouldn't be a problem.

There's no need. We'll know if and when expression handling changes.

How many posts in the Ask For Help section concern complex expressions?! There's no need to be paranoid over something like that, the noob can invent his/her own method if nobody's willing to help.

If we know AHK follows PHP/C++ we can apply their rules.

lol, no it won't... nobody's asking you to moderate the forums or take on customer support.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

…and you go back an update all of your posted scripts, if necessary? It looks better not relying on undocumented features. Furthermore, changing undocumented features do not always get documented.
Immediately when? When the corresponding term is evaluated, of course. In "*p + *(++p)" the first reference is normally the un-incremented p, only after using it, in the evaluation of the second term will p be changed. Otherwise both terms referenced the same memory.
Until the next release. Then your script might stop working, because some undocumented feature changed.
Again, when something undocumented changes, and remains undocumented, it will not show up in the list of changes.
The tricky side-effects, precedence raising, etc. just have been introduced. But I have seen many expression related questions, mostly about = or :=, the need of %, and such.
But we don't know anything, because these rules in AHK are undocumented. It was sufficient documentation to tell, that expressions would follow the rules of PHP, but it is not the case.
Are you saying that I should stop answering beginners' questions? Maybe you are right…

I guess I'll have to. In the mean time I prefer to use the current features that are available, like most (99%) other users.

As far as I know Chris always mentions possible script-breaking updates in Announcements.

I haven't tried it but in my script ++c comes first anyway.

I'm not obsessive over compatibility issues. If I find something not working I'll try fix it with extra parenthesis. Your advice is good nevertheless and I'll bear it in mind for future scripts, thanks.

I have only seen queries relating to :=/% and none to do with evaluation order specifically (which is what this discussion is about right).

Chris mentioned it on the forum, are you saying that isn't credible?

'work' here implies forced duties, which is deceptive. You don't have to help noobs who use my code (which has never happened thus far). You are free to do as you wish but I appreciate your input and expertise, as always.

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

I did not see Chris saying that those rules are followed exactly in AHK, only that expression evaluation in AHK is not solely determined by the precedence table, but also by some rules. This is similar in PHP/C++. In fact, the AHK rules are not exactly the same.