# \[Feature\] Boolean mapping transforms should support integer map values **URL:** \ **Category:** Ignition\ **Tags:** perspective, ignition81\ **Created:** [June 6, 2022, 1:36pm UTC](https://forum.inductiveautomation.com/t/feature-boolean-mapping-transforms-should-support-integer-map-values/60402 "2022-06-06T13:36:47Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Cory.grube](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cory.grube/32/20476_2.png) [@Cory.grube](https://forum.inductiveautomation.com/u/Cory.grube)\ **Post date:** [June 6, 2022, 1:36pm UTC](https://forum.inductiveautomation.com/t/feature-boolean-mapping-transforms-should-support-integer-map-values/60402/1 "2022-06-06T13:36:47Z")
While setting up a mapping transform, I realized a boolean expression does not map to values of 0 or 1, but actually requires a false/true map. Automatic equating 0=false and 1=true could be a nice quality of life improvement for folks who tend to think primarily in numeric terms. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/0/d0f29c1bab04dd1b354b419bbd13ff5da26c5bbd.png) ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [June 6, 2022, 2:27pm UTC](https://forum.inductiveautomation.com/t/feature-boolean-mapping-transforms-should-support-integer-map-values/60402/2 "2022-06-06T14:27:38Z")
Unfortunately, that request would introduce some dangerous conditions for existing users which would break some existing projects; if we were to make a change like that and a user had implemented a Map transform which contained inputs values of `0` and `false`, which would we map to? As the transform exists currently, the input/output values are literally a Map (hence the name): we store those values as and then reference them with a key which is the input value. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [June 6, 2022, 2:30pm UTC](https://forum.inductiveautomation.com/t/feature-boolean-mapping-transforms-should-support-integer-map-values/60402/3 "2022-06-06T14:30:27Z")
You could always `toInt()` in your source expression. ---
**Author:** ![Cory.grube](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cory.grube/32/20476_2.png) [@Cory.grube](https://forum.inductiveautomation.com/u/Cory.grube)\ **Post date:** [June 6, 2022, 2:37pm UTC](https://forum.inductiveautomation.com/t/feature-boolean-mapping-transforms-should-support-integer-map-values/60402/4 "2022-06-06T14:37:54Z")
That’s an interesting point, hadn’t thought of that. To play devil’s advocate a bit, I think it’d make sense to apply the first or last matching map in a 0=false scenario. As it stands, the maps already support duplicate entries and does just that: ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/7/87b889f5cbf7a0449f9b71c4797b078514d758b8.png) Edit, worth noting that on OKing and reopening the binding, both entries read `0` and it continues to eval to `456` ---
**Author:** ![cmallonee](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cmallonee/32/6416_2.png) [@cmallonee](https://forum.inductiveautomation.com/u/cmallonee)\ **Post date:** [June 6, 2022, 2:45pm UTC](https://forum.inductiveautomation.com/t/feature-boolean-mapping-transforms-should-support-integer-map-values/60402/5 "2022-06-06T14:45:31Z")
Part of my point was that there is no “safe” way to loop back over a map, and this undermines the efficiency of such a transform. The common “safe” approach is something like this: ```auto my_map.get(desired_key, fallback_value) ``` where there is one attempt to access, and in the event no such key is found we fall back to using a provided value. Very efficient, very safe, no-nonsense. To loop back over the map in the event we don’t find the `desired_key` the first time through means we’d have to have some limit to the number of times we’re willing to loop over the map. How many times are we willing to access the map before we give up and use the default value? Once? Twice? At what point do we give up and use the fallback value? ---
**Author:** ![Cory.grube](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cory.grube/32/20476_2.png) [@Cory.grube](https://forum.inductiveautomation.com/u/Cory.grube)\ **Post date:** [June 6, 2022, 2:49pm UTC](https://forum.inductiveautomation.com/t/feature-boolean-mapping-transforms-should-support-integer-map-values/60402/6 "2022-06-06T14:49:08Z")
Great explanation! Thanks for taking the time to explain why it’s more troublesome than it appears at first glance