BDouble Operations

[twodayslate]

BDouble is missing some important functionality. Below are some of things I think should be added:

• Powering
• Modulo
• Floor
• Ceiling
• Rounding
• Square root
• Scientific Notation
• Random Big Number #22

BDouble also needs full support for the String initialization method (completed in #20)

Also proposing a repository name change to some variant of BigNumber

[mkrd]

Yes, BDouble definitely needs more methods, I will add some stubs and start implementing the missing stuff.
What name change would you propose?

[twodayslate]

BigNumber sounds good to me. Swift-BigNumber may be good as well. I only say BigNumber cause that is what is in the Podfile

[mkrd]

The name also fits better since this project also contains BDouble. But I'm a little bit worried that that the project will get less downloads because most people look for the search term "swift big integer" or "swift bigint"

[twodayslate]

That's true, but that is also what the description and tags are for?

[mkrd]

Yeah you're right, I'll change it tomorrow :D

[twodayslate]

Great - you should publish the the CocoaPods trunk when you do :)

[twodayslate]

Here is some janky scientific notation - suggestions/comments/improvements appreciated.
https://ghostbin.com/paste/her6d

Didn't really want to read this http://kurtstephens.com/files/p372-steele.pdf

[fossfool]

Hi all:

I've been playing around with a square root method for a large primes project I'm working on and I'm willing to tackle this request. I've got some feed back requests before I wrap it up:

1. I'm using Heron's / Hero's method with optimizations. Seems to be a bit faster in code than Newton's . Is anyone opposed to this approach?

2. Currently I'm using a precondition to ensure n is positive at the top of the function:

precondition( n.isPositive() )

Is this the best approach to take, or should I be doing something different? Alternatives - return nil - makes using the function a bit more painful - and you could be introducing further errors down stream - but you avoid the hard break. - invert the number? I really don't like the idea because it's hiding the problem....

3. How many digits of precision should the function support? Currently, the rounds required at < 6,332 places is 11 and I feel the performance is acceptable, 12 rounds gets slow but 12,593 decimal places - 13 and go to lunch....

4. Precision "Passing": The other question I had is about precision. I could take two approaches, either allow the user to explicitly request the precision to be used or use the precision of n passed in? Or both, I guess. Any thoughts?

5. Speaking of precision, would anyone be opposed to adding precision to the BDouble init routines? I'm I'm doing a lot of 2 liner instantiations just to set precision on variables that could just as well be created with "let." I'm thinking of adding it an optional parameter at the end of the inits? I'm concerned as an old fart coder that's new to Swift - I know messing with your code's function signatures is a bad idea (.Net anything). That said, from what I've read, it's not a big deal Swift. Would adding new inits be a better approach, or just go ahed and modify the existing ones?

Thanks in advance for your advice and direction.

-fossfool

[twodayslate]

I suppose the BDouble.precision should be renamed to BDouble.defaultPrecision to match GMP. I'm fine with a precision constructor as long as if it is not set BDouble.defaultPrecision is used.

[fossfool]

I need to eat crow.

After digging into in the core code, I've realized precision is not like the "normal" precision we're used to associating with floating point variables. It has nothing to do with the actual precision of the underlying value stored in the variable. As I understand it now, precision only comes into play when converting a BDouble to a decimal string representation. Would you agree?

Changing the "Global Default" is easy enough, and while you may be looking to be compatible with other libraries, I'd opt for a name which more clearly conveys what it does.

For anyone coming across this later, there are two functions used to create a decimal string representation of BDouble: decimalDescription() and decimalExpansion(precisionAfterDecimalPoint: Int), decimalDescription() just passes self.precision to decimalExpansion. The rub is if you do:

var x = BDouble(0.0)
x.precision = 20
x = 2/3
print(x.decimalDescription)

You get: 0.6667

Precision isn't "sticky." It get's clobbered in the assignment back to x. The precision of the
value is still 2/3 . If you use:

print(x.decimalExpansion(precisionAfterDecimalPoint: 50))

0.66666666666666666666666666666666666666666666666667

Better yet, use:

print(x.fractionDescription)

// 2/3

Since precision isn't "sticky," I don't think there's much value adding precision to the inits, and would impact initialization times (granted very very negligibly). Further, I think it would be a distraction in equations, and may lead people to actually believing they need to worry about it if they come across you code down the road.

[twodayslate]

Currently, yes, precision is only used for decimalExpansion but that doesn't mean it can't also represent precision for a decimal approximation for something like 3^(1/3) or repeating values as well. Curious on your thoughts as you might have a better math background than I do. Perhaps we need a printingPrecision?

When a new BDouble is created, the it uses the Global BDouble.precision. When you did x = 2/3 it is creating a new BDouble. The precision shouldn't be "clobbered" if you did x = x + 2/3. I don't know of a way to not "clobber" on a reassignment of a variable let me know. The same concept can be seen with something like this:

var x = UILabel()
x.text = "Hello World"
print(x.text)
> "Optional("Hello World")\n"
x = UILabel()
print(x.text)
> "nil\n" # this isn't Hello World anymore!

I think normally people only set the precision once and then never need it again unless printing.

However, this brings up a good point that for operations, if a new BDouble is created in an operation it should get the precision from the parent. I don't think it is always doing that now.

I don't think an optional precision argument in the initializer would slow down creation too much and could have a default to alleviate some confusion. Some of the current initializers should be convenience initializers as well.

I can work on fixing/improving the initializers if we can come to some agreement on a way forward.

[fossfool]

I'm getting, Ambiguous use of operator '+=', when I try x += 2/3. My math is so so calculus back in college 30 years ago, and a lifetime of aviation and computer science kept the basic skills up. Mostly logic and set theory though. I was a CISSP - so I'm interested in the crypto when you go there.

Okay back to precision - not used now - would like to "Reserve it" for later use... Got ya. Here's how I've made my code more readable before I realized it wasn't an issue:

var x = BDouble(0.0)
x = 2 / 3 ; x.precision = 20

Off the top of my head, and thinking in general terms, in other languages I've used a setter property - to get around things like this. Expose a .value property instead of doing an assignment on the entire structure, that could be a way around it.

x.value = 2/3 

I did some digging and I ran across this:

http://iosbrain.com/blog/2018/02/20/swift-4-property-observers-responding-to-changes-in-property-values-and-managing-state/

I haven't worked with them in Swift yet. Let me go read up and review the swift docs. I think it may be what we're looking for. Hey, drop me an email. I've exposed an address on my profile if you want to take this offline while we hash this out.

[twodayslate]

You might be interested in rawData then. You could use your link to create a getter and setter.

[twodayslate]

Pretty much only have modulo left. I finished root in 6a379be