Better demo:
But this points out that the input to hex-to-number should be type text, not type number, because you can't type an "x" into a number-type input slot.
Nice work on the elegant recursive algorithm, and thank you for getting the block names right!
If it were me, though, I wouldn't require the "0x" at the beginning of the input to hex-to-number. I'd check for it and remove it in the top-level procedure before calling the subprocedure, whose input would then be just the digits.
I really don't like the block name. A number is a number is a number regardless of whether it is expressed in hexadecimal, binary, or decimal (or whatever). So a better name would be hexadecimal ... to decimal.
to hexadecimal is a fine name.
And as pointed out recently Snap! is not consistent about this:
This is a consequence of the fact that Snap! uses +n to convert n to a number in JavaScript (if possible).
imo all the text/number behavior is difficult to work with precisely
here i will write (join ) as "x" and (x)+(0) as +x
"2748.0" is displayed as 2748.0, and adding 0 changes it to +2748, displayed as 2748
"2748.0" is not identical to "2748"
<is ["2748.0"] a [text]?> says false
<is ["2748.0"] a [number]?> says true
"2748.0" is identical to +2748
the identical block especially bothers me here because from my perspective, the whole point is that you can expect them to be EXACTLY the same. but in this case they have different behaviors with the same operations, (join [2748.0] [whatever]) isn't the same as (join ((2748) + (0)) [whatever]), and it gets much worse when doing things like splitting numbers by digits
i can imagine someone making a project that asks for a number, does sensible checks on it, and then has issues displaying it later because it was formatted differently from how snap displays other numbers. it could even break entirely if it did things like replacing digits with text operations, expecting an integer but running into issues with a .0
this type stuff should probably be moved to another thread if it continues
Testing numeric equality is what the = block is for. The IS IDENTICAL TO block is our way of letting users see under the hood a little to see whether the internal representation of some value is the same as the internal representation of some other value, even if the two values are displayed the same.
No no no no no no no!
Yes, there is an underlying number for any representation. But the representation is a different thing from the number. When people get confused about this, it makes me regret the automatic conversion between numbers and numerals done in Snap! (as in Logo). Fortran programmers and C programmers never get confused about this, because if they have a string of digits and they want to do arithmetic on the corresponding number, they have to do an explicit conversion from numeral to number.
If you look at the OP's code, you will see that it operates on (hexadecimal) numerals by doing text operations, JOIN and LAST LETTER OF and so on, whereas it operates on numbers by doing arithmetic operations, + and FLOOR and MOD and so on. There are places where it multiplies or divides a number by 16, because that's what you have to do to make room for another (hex) digit in the numeral, but there aren't places where it multiplies or divides by 10, because there are no decimal numerals involved in the algorithm.
that's exactly what i'm expecting it to do, and what it's not doing.
(join [2.0]) is NOT the same as ((2.0)+(0)), but the is identical block says they are.
they clearly are different because the first is 3 characters long, and the second is one. (2.0, and 2)
Yes. I should have said a better name is
hexadecimal string ... to number
I think my problem is that when I hear "hexadecimal" I think "hexadecimal number" so converting it to a number isn't what is going on. But, yes, calling the output "decimal" is confusing since it is a "number that displays as a decimal".
Right, but there's no such thing as a "hexadecimal number." As you said, the number is the number, however it's represented. You'll be a happier person if you teach yourself to think "hexadecimal numeral." :~)
P.S. And "number that displays as a decimal" is misleading, because that's not a property of a number. Snap! displays numbers as decimal numerals, period.
Sorry to necropost (or whatever you call it here), but is it just me or do these blocks not seem to work anymore? I even tested them in the project linked in the original post, but Decimal to Hexadecimal seems to only report 0X0 for every number, when I do believe it should only report that for the decimal of 0, and Hexadecimal to Decimal seems to report weirdly. For example, "0x0" reports "-16" and "0x11" reports "-239". I don't really know how to convert between hexadecimal and decimal, so I can't really try to fix it myself. I do remember it working in the past, though. Did, maybe, a recent Snap! update break it?
It is not so much that an update to Snap! broke it, but that the OP made a mistake and it worked anyway in previous versions. Here is the link to the project in V9: Snap! Build Your Own Blocks. As you can see, it still works. But V10 doesn't. Let's take a look at why:
In version 9, if one has an input variable to a ring but doesn't add any inputs when calling it, the input isn't defined and so an existing variable takes precedence:
In fact, if we don't define an "n" variable first, it errors:
However, in version 10, the inputs variables are created even if their values aren't provided, and then default to 0.
This behaviour can be changed very easily:
This is happening inside the definition of the hexadecimal block as well:
And can be fixed the same way:
excellent explanation, @mark4sisb, thank you!
Thank you for explaining how to fix the block. I tried it, and it now works. Also, if you mean, like, Snap! versions by "V10" and 'V9" (that's what I assume because of the way you're saying variables get created if they don't have values and because of the fact it works in the project you linked but didn't work in my project), then I didn't know that Snap! projects developed in earlier Snap! versions "stay" in that Snap! version. Correct me if I'm wrong, though.
Snap projects are saved to the cloud, which can be accessed by any snap version, regardless of which version the project was made in (it will warn you when you try to load a project from a newer version in an older version, but it won't stop you).
Ah, I see. Thank you. That'll be all.
In some cases, when an older project is loaded in a newer version, Snap! will notice a compatibility problem and change the code in the project to reflect the changes in Snap!. We try to maintain backward compatibility (old project in new Snap!) but make no effort to support forward compatibility (new project in old Snap!).
i mean,, that makes sense, as you can't really predict the future.
Systems that try for forward compatibility design every part of their interface to just ignore parts of an input that they don't understand, instead of reporting an error. So the program you're running might not do what you intend, but it'll load and run, and do something.