Re: math, bigly

On 08/09/2017 11:05 AM, Mark Waddingham via use-livecode wrote: Fortunately, there is a potential carrot to go with the stick - we can expand the range of the bit operations (and baseConvert) to 52-bits without too much difficulty I think; and add error checking at the same time. Which would

Re: math, bigly

On 08/09/2017 10:15 AM, Mark Waddingham via use-livecode wrote: ...although that scale is relatively common in 'high-end' cryptography settings (factoring large numbers for the purposes of generating keys and such). Heh. And that, of course, is exactly what I was working on, and what got me

Re: math, bigly

Is it a good idea to implement a bignum library in LC Builder? ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

Re: math, bigly

On 2017-08-09 18:50, Richard Gaskin via use-livecode wrote: Imagine the frustration of passing an invalid object reference to something like the delete command, and rather than reporting that it couldn't do what it asked you it just arbitrarily deleted some other object instead without

Re: math, bigly

Mark Wieder wrote: > But what annoys me isn't the fact that baseconvert, etc (bitXor is the > one that bit me) only work on integers less than 2^32. It's more the > fact that the input data was crunched down to something the functions > could handle, and then give me the wrong result with no

Re: math, bigly

On 2017-08-09 19:15, Bob Sneidar via use-livecode wrote: OIC. I was under the impression that the C math libraries deal with numbers of high precision better than Livecode does, perhaps themselves generating errors on overflow. Maybe that is not the case. C itself does no error checking/bounds

Re: math, bigly

On 2017-08-09 19:11, Mark Wieder via use-livecode wrote: The problem I've run into is more at a higher level, dealing with number parsing and runtime overflow detection before truncating input parameters down to unsigned integers and calling the math library. Well there's two things here...

Re: math, bigly

On 08/09/2017 09:32 AM, Mark Waddingham via use-livecode wrote: Please do file a bug about it - it is, at the very least, an anomaly. Done. http://quality.livecode.com/show_bug.cgi?id=20254 -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode

Re: math, bigly

OIC. I was under the impression that the C math libraries deal with numbers of high precision better than Livecode does, perhaps themselves generating errors on overflow. Maybe that is not the case. Bob S > On Aug 9, 2017, at 10:11 , Mark Wieder via use-livecode >

Re: math, bigly

On 2017-08-09 18:56, Bob Sneidar via use-livecode wrote: Btw, I should mention that the way numbers work in LiveCode has become one of my biggest 'pet peeves' over the last year or so. The current way things work is too simplistic really - it hides the very important distinction between

Re: math, bigly

On 08/09/2017 09:56 AM, Bob Sneidar via use-livecode wrote: I wonder how much leveraging SQLite can help. SQLite has only basic math functions, and you cannot use stored functions, but you CAN map functions to a C API. And if you can do THAT, then someone has written a math API, and maybe

Re: math, bigly

I wonder how much leveraging SQLite can help. SQLite has only basic math functions, and you cannot use stored functions, but you CAN map functions to a C API. And if you can do THAT, then someone has written a math API, and maybe that is a good place to start looking. Bob S

Re: math, bigly

On 2017-08-09 18:29, Mark Wieder via use-livecode wrote: Looking into the engine code, by the time you get to the actual bitXor code, the input arguments are already unsigned integers. Since I was passing 20-hex-digit values to bitXor, I would have expected some kind of runtime warning or error

Re: math, bigly

Hi Mark. I remember an old trick to determine if a math function was overflowing. Run the equasion backwards and see if that result equals the initial value. This will reveal rounding errors too. Bob S > On Aug 8, 2017, at 18:38 , Mark Wieder via use-livecode >

Re: math, bigly

On 2017-08-09 18:29, Mark Wieder via use-livecode wrote: Looking into the engine code, by the time you get to the actual bitXor code, the input arguments are already unsigned integers. Since I was passing 20-hex-digit values to bitXor, I would have expected some kind of runtime warning or error

Re: math, bigly

On 2017-08-09 18:14, Mark Wieder via use-livecode wrote: Oops. OK - point sheepishly taken. Is that the definition of integer in the dictionary? The "integer" entry just says "if the value contains digits (and an optional minus sign) and no other characters, it is an integer", which is as

Re: math, bigly

On 08/09/2017 02:58 AM, Mark Waddingham via use-livecode wrote: The engine hasn't ever done range checks on integers - mainly because numbers are doubles so (in most ases) you just lose accuracy / precision as the numbers get larger. In this case it *could* because it is actually using

Re: math, bigly

I agree. At least the result should contain something about an overflow. Bob S > On Aug 9, 2017, at 09:14 , Mark Wieder via use-livecode > wrote: > > But what annoys me isn't the fact that baseconvert, etc (bitXor is the one > that bit me) only work on

Re: math, bigly

On 08/09/2017 02:36 AM, hh via use-livecode wrote: Mark wrote: but I'm annoyed that the IDE doesn't give me an overflow warning if I try to perform an operation on a number that's bigger than 0x. Instead, it just happily trims it down to an unsigned integer and proceeds to give me a

Re: math, bigly

On 2017-08-09 11:36, hh via use-livecode wrote: Mark wrote: but I'm annoyed that the IDE doesn't give me an overflow warning if I try to perform an operation on a number that's bigger than 0x. Instead, it just happily trims it down to an unsigned integer and proceeds to give me a

Re: math, bigly

> Mark wrote: > but I'm annoyed that the IDE doesn't give me an overflow warning if I try > to perform an operation on a number that's bigger than 0x. > Instead, it just happily trims it down to an unsigned integer and proceeds > to give me a wrong result. Hey Mark. Don't complain because

math, bigly

Phooey... put baseconvert("10001",16,10) ...and yes, I understand what's going on under the hood, but I'm annoyed that the IDE doesn't give me an overflow warning if I try to perform an operation on a number that's bigger than 0x. Instead, it just happily trims it down to an