Everyrun

Welcome to HackerNoon’s interview series. This section is curated by our Editorial team to spotlight bold and disruptive startups across the globe. If you’ve been nominated, and answer these questions Startups-Of-The-Year create a brand profile here. Hey Hackers, Everyrun has been nominated in HackerNoon's annual Startup of the Year awards in Tallinn, Estonia. Please vote for us here: . https://hackernoon.com/startups/europe/europe-tallinn-estonia Read more about us below to understand why we deserve your vote. Meet Everyrun My Role Everyrun is a groundbreaking startup that connects runners and race organizers through its innovative platform. Our mission is to make hosting, monetizing, and participating in running events effortless and enjoyable. With Everyrun, organizers can easily showcase their events, while runners can discover and join exciting races in unique and creative locations. Whether you're a passionate runner or a race organizer looking to create unforgettable experiences, Everyrun is your go-to platform. Join us in shaping the future of running and be part of a vibrant global community that celebrates the joy of running while exploring new horizons. Elevate your running journey with Everyrun today! How We're Disrupting/Improving the Running Industry Everyrun is poised to disrupt the running events industry by breaking down borders and embracing virtual event functionality. Our platform eliminates geographical limitations, allowing runners from around the world to participate in races without physical constraints. With our mobile app, runners can easily track their progress, connect with fellow participants, and explore new routes. By embracing technology, Everyrun provides a seamless and inclusive experience for both runners and organizers, revolutionizing the way running events are conducted. Say goodbye to boundaries and join us in shaping a future where anyone can run, compete, and connect, regardless of location. Standing Out from The Crowd What sets Everyrun apart from other startups in the same space is our commitment to removing barriers for event organizers and runners, coupled with a strong focus on cost-effectiveness. We understand the financial challenges faced by organizers, which is why we provide affordable solutions through our race management app. This includes a budget-friendly timing solution for physical events and a virtual option, ensuring that organizing amazing running events no longer requires a substantial budget. For runners, we offer a seamless experience by simplifying event participation. Once registered on our platform, runners can use the same race number to participate in all events hosted on Everyrun. This convenient approach not only streamlines the registration process but also enhances the overall runner experience by eliminating the need for multiple codes or registrations. At Everyrun, we are dedicated to creating a level playing field, making running events accessible and enjoyable for all, regardless of financial constraints or logistical challenges. Our comprehensive approach and user-centric features distinguish us as a platform that truly understands and addresses the needs of both event organizers and runners. Our Predictions/Thoughts on the Running Events Industry in 2023 The running events industry is undergoing remarkable growth and transformation, and Everyrun is at the forefront of these developments. As we look to the future, several trends will shape the industry in 2023 and beyond, highlighting our expertise and vision. Firstly, the rise of virtual running events will continue, offering convenience and flexibility to participants worldwide. We predict that these events will become more immersive and interactive, incorporating advanced tracking technologies. Sustainability will also take center stage as event organizers prioritize eco-friendly practices. From reducing waste to utilizing sustainable materials, the industry will embrace environmentally responsible approaches and forge partnerships with local communities for a positive impact. Moreover, running events will play a crucial role in addressing health challenges. We anticipate that more governments will recognize the effectiveness of running and jogging social events in combatting issues like obesity and loneliness, which contribute to more serious diseases such as heart disease and diabetes. As a result, we predict a surge in government support and integration of running events into social programs worldwide. Everyrun, with its innovative platform, is uniquely positioned to lead the industry forward. By staying ahead of trends, leveraging technology, and fostering inclusivity, we are driving the future of running events. Additionally, we are ready to collaborate with governments, partnering with public health authorities to maximize the impact of running events within comprehensive well-being initiatives. As experts in the field, Everyrun is committed to creating a vibrant global community of runners while addressing societal health challenges. By embracing emerging trends and supporting government-backed initiatives, we are shaping a future where running events are catalysts for positive change, promoting physical health, community engagement, and overall well-being. What word defines the state of Running Events in 2023? The state of running events in 2023 can be defined as dynamic. This term encapsulates the ongoing evolution and transformation within the industry, as it adapts to changing trends, embraces technology, and responds to the needs and preferences of runners and organizers. Running events have become more diverse, inclusive, and accessible, catering to a wide range of interests and abilities. The integration of virtual elements, sustainable practices, and government support further contributes to the dynamic nature of the industry, fostering innovation and creating new opportunities for runners to connect and participate in unique and meaningful experiences. Why we decided to participate in HackerNoon's Startup of the Year awards We decided to participate in HackerNoon's Startup of the Year awards because it presents a fantastic opportunity for Everyrun to gain recognition and exposure within the startup community. Final Thoughts In conclusion, Everyrun is an innovative platform that is reshaping the running events industry. By connecting runners and race organizers, we provide a seamless and inclusive experience that transcends geographical limitations. With our forward-thinking approach and expertise, we are poised to lead the industry into a future marked by virtual events, government support, and advancements in event management technology. We are excited about the possibilities ahead and remain dedicated to empowering runners, inspiring organizers, and making a positive impact on the running community. Join us on this transformative journey, and experience the difference that Everyrun can make in your running adventures. Vote for us today! https://hackernoon.com/startups/europe/europe-tallinn-estonia

Startups of the Year 2023: Everyrun - The Startup That Connects Runners With Race Organizers

A (long) time ago, my first job consisted of implementing workflows using the Staffware engine. In short, a workflow comprises tasks; an automated task delegates to code, while a manual task requires somebody to do something and mark it as done. Then, it proceeds to the next task - or tasks. Here's a sample workflow: The above diagram uses Business Process Model and Notation. You can now design your workflow using the Business Process Model and Notation and run it with compatible workflow engines. Time has passed. Staffware is now part of Tibco. I didn't use workflow engines in later jobs. Years ago, I started to automate my conference submission process. I documented it in parallel. Since then, I changed the infrastructure on which I run the software. This post takes you through the journey of how I leveraged this change and updated the software accordingly, showcasing the evolution of my approach. Generalities I started on Heroku with the free plan, which no longer exists. I found that the idea was pretty brilliant at the time. The offering was based on dynos, something akin to containers. You could have a single one for free; when it was not used for some time, the platform switched it off, and it would spin a new one again when receiving an HTTP request. I believe it was one of the earliest serverless offerings. In addition, I developed a Spring Boot application with Kotlin based on the Camunda platform. Camunda is a workflow engine. One of the key advantages of workflow engines is their ability to store the state of a particular instance, providing a comprehensive view of the process. For example, in the above diagram, the first task, labeled "Request Purchase", would store the requester's identity and the requested item (or service) references. The Purchase Department can examine the details of the requested item in the task after. The usual storage approach is to rely on a database. The initial design At the time, Heroku didn't provide free storage dyno. However, I had to design my initial workflow around this limitation, which posed its own set of challenges. I couldn't store anything permanently, so every run had to be self-contained. My fallback option was to run in memory with the help of H2. Here is my initial workflow in all its glory: As a reminder, everything starts from Trello. When I move a card from one lane to another, Trello sends a request to a previously registered webhook. As you can expect, the hook is part of my app and starts the above workflow. The first task is the most important one: it evaluates the end state from the event payload of the webhook request. The assumption is that the start state is always Backlog. Because of the lack of storage, I designed the workflow to execute and finish in one run. The evaluation task stores the end state as a BPMN variable for later consumption. After the second task extracts the conference from the Trello webhook payload, the flow evaluates the variable: it forwards the flow to the state-related subprocess depending on its value. Two things happened with time: Salesforce bought Heroku and canceled its free plan. At the same time, Scaleway offered their own free plan for startups. Their Serverless Container is similar to Heroku's - nodes start when the app receives a request. I decided to migrate from Heroku to Scaleway. You can read about my first evaluation of Scaleway.
I migrated from H2 to the free Cockroach Cloud plan Refactoring to a new design With persistent storage, I could think about the problems of my existing workflow. First, the only transition available was from the Backlog to another list, i.e., Abandoned, Refused, or Accepted. The thing is, I wanted to account for additional less-common transitions; for example, the talk was accepted but could be later abandoned for different reasons. With the in-place design, I would have to compute the transition, not only the target list. Next, I created tasks to extract data. It was not only unnecessary, it was bad design. Finally, I used subprocesses for grouping. While not an issue per se, the semantics was wrong. With persistent storage, we can pause a process instance after a task and resume the process later. For this, we rely on messages in BPMN parlance. A task can flow to a message event. When the task finishes, the process waits until it receives the message. When it happens, the flow process resumes. If you can send different message types, an event-based gateway helps forward the flow to the correct next step. Yet, the devil lurks in the details: any instance can receive the message, but only one is relevant - the one of the Trello card. Camunda to the rescue: we can send a business key, i.e., the Trello card ID, along with the message. Note that if the engine finds no matching instance, it creates a new one. Messages can trigger start events as well as regular ones. Here's my workflow design: For example, imagine a Trello hook that translates to an Abandoned message. If there's no instance associated with the card, the engine creates a new instance and sends the Abandoned message, which: Starts the flow located at the lower left
Ticks the due date on the Trello card
Finishes the flow If it finds an existing instance, it looks at its current state: it can be either Submitted or Accepted. Depending on the state, it continues the flow. Conclusion In this post, I explained how I first limited my usage of BPMN and then unlocked its true power when I benefited from persistent storage. However, I didn't move from one to the other in one step. My history involves around more than twenty versions. While Camunda keeps older versions by design, I didn't bother with my code. When I move them around, it will fail when handling cards that were already beyond Backlog. Code needs to account for different versions of existing process instances for regular projects. I'm okay with some manual steps until every card previously created is done. To go further: Business Process Model and Notation
Camunda
My evaluation of the Scaleway Cloud provider A (long) time ago, my first job consisted of implementing workflows using the Staffware engine. In short, a workflow comprises tasks ; an automated task delegates to code, while a manual task requires somebody to do something and mark it as done. Then, it proceeds to the next task - or tasks. Here's a sample workflow: workflows tasks The above diagram uses Business Process Model and Notation . You can now design your workflow using the Business Process Model and Notation and run it with compatible workflow engines. Business Process Model and Notation Time has passed. Staffware is now part of Tibco. I didn't use workflow engines in later jobs. Years ago, I started to automate my conference submission process. I documented it in parallel. Since then, I changed the infrastructure on which I run the software. This post takes you through the journey of how I leveraged this change and updated the software accordingly, showcasing the evolution of my approach. I documented it Generalities I started on Heroku with the free plan, which no longer exists. I found that the idea was pretty brilliant at the time. The offering was based on dynos , something akin to containers. You could have a single one for free; when it was not used for some time, the platform switched it off, and it would spin a new one again when receiving an HTTP request. I believe it was one of the earliest serverless offerings. Heroku dynos serverless In addition, I developed a Spring Boot application with Kotlin based on the Camunda platform. Camunda is a workflow engine. Camunda One of the key advantages of workflow engines is their ability to store the state of a particular instance, providing a comprehensive view of the process. For example, in the above diagram, the first task, labeled "Request Purchase", would store the requester's identity and the requested item (or service) references. The Purchase Department can examine the details of the requested item in the task after. The usual storage approach is to rely on a database. The initial design At the time, Heroku didn't provide free storage dyno . However, I had to design my initial workflow around this limitation, which posed its own set of challenges. I couldn't store anything permanently, so every run had to be self-contained. My fallback option was to run in memory with the help of H2 . dyno H2 Here is my initial workflow in all its glory: Here is my initial workflow in all its glory: As a reminder, everything starts from Trello. When I move a card from one lane to another, Trello sends a request to a previously registered webhook. As you can expect, the hook is part of my app and starts the above workflow. The first task is the most important one: it evaluates the end state from the event payload of the webhook request. The assumption is that the start state is always Backlog. Because of the lack of storage, I designed the workflow to execute and finish in one run. The evaluation task stores the end state as a BPMN variable for later consumption. After the second task extracts the conference from the Trello webhook payload, the flow evaluates the variable: it forwards the flow to the state-related subprocess depending on its value. Two things happened with time: Salesforce bought Heroku and canceled its free plan. At the same time, Scaleway offered their own free plan for startups. Their Serverless Container is similar to Heroku's - nodes start when the app receives a request. I decided to migrate from Heroku to Scaleway. You can read about my first evaluation of Scaleway. I migrated from H2 to the free Cockroach Cloud plan Salesforce bought Heroku and canceled its free plan. At the same time, Scaleway offered their own free plan for startups. Their Serverless Container is similar to Heroku's - nodes start when the app receives a request. I decided to migrate from Heroku to Scaleway. You can read about my first evaluation of Scaleway . my first evaluation of Scaleway I migrated from H2 to the free Cockroach Cloud plan Cockroach Cloud Refactoring to a new design With persistent storage, I could think about the problems of my existing workflow. First, the only transition available was from the Backlog to another list, i.e. , Abandoned, Refused, or Accepted. The thing is, I wanted to account for additional less-common transitions; for example, the talk was accepted but could be later abandoned for different reasons. With the in-place design, I would have to compute the transition, not only the target list. i.e. Next, I created tasks to extract data. It was not only unnecessary, it was bad design. Finally, I used subprocesses for grouping. While not an issue per se , the semantics was wrong. per se With persistent storage, we can pause a process instance after a task and resume the process later. For this, we rely on messages in BPMN parlance. A task can flow to a message event . When the task finishes, the process waits until it receives the message. When it happens, the flow process resumes. If you can send different message types, an event-based gateway helps forward the flow to the correct next step. messages message event event-based Yet, the devil lurks in the details: any instance can receive the message, but only one is relevant - the one of the Trello card. Camunda to the rescue: we can send a business key, i.e. , the Trello card ID, along with the message. i.e. Note that if the engine finds no matching instance, it creates a new one. Messages can trigger start events as well as regular ones. Here's my workflow design: Here's my workflow design: For example, imagine a Trello hook that translates to an Abandoned message. If there's no instance associated with the card, the engine creates a new instance and sends the Abandoned message, which: Starts the flow located at the lower left Ticks the due date on the Trello card Finishes the flow Starts the flow located at the lower left Ticks the due date on the Trello card Finishes the flow If it finds an existing instance, it looks at its current state: it can be either Submitted or Accepted. Depending on the state, it continues the flow. Conclusion In this post, I explained how I first limited my usage of BPMN and then unlocked its true power when I benefited from persistent storage. However, I didn't move from one to the other in one step. My history involves around more than twenty versions. While Camunda keeps older versions by design, I didn't bother with my code. When I move them around, it will fail when handling cards that were already beyond Backlog. Code needs to account for different versions of existing process instances for regular projects. I'm okay with some manual steps until every card previously created is done. To go further: To go further: Business Process Model and Notation Camunda My evaluation of the Scaleway Cloud provider Business Process Model and Notation Business Process Model and Notation Camunda Camunda My evaluation of the Scaleway Cloud provider My evaluation of the Scaleway Cloud provider

Transforming Workflow Automation: From Stateless to Stateful

Setup, Run and Debug Cypress Tests: A Quick Guide To Get You Started

This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. Authors: (1) Pascal Baumann, Max Planck Institute for Software Systems (MPI-SWS), Germany; (2) Rupak Majumdar, Max Planck Institute for Software Systems (MPI-SWS), Germany; (3) Ramanathan S. Thinniyam, Max Planck Institute for Software Systems (MPI-SWS), Germany; (4) Georg Zetzsche, Max Planck Institute for Software Systems (MPI-SWS), Germany. Table of Links Introduction Dynamic Networks of Concurret Pushdown Systems (DCPS) Warm-up: Non-Termination Fair Non-Termination From Progressive Runs for VASSB to Reachability Starvation Conclusion, Acknowledgment & References A. Strengthening Fairness to Progressive Runs B. Proofs from Section 4.1 C. Proofs for Section 5 D. Proofs for Section 5.3 E. Proofs for Section 6 3 WARM-UP: NON-TERMINATION In this section, we prove Theorem 2.2. The theorem follows easily from previous results for safety verification [Atig et al. 2011; Baumann et al. 2020]. We recall the main ideas as a step toward the more complex proof for fair termination. DCPS DCFS Downward Closures: From to The DCFS simulates the downward closure of the DCPS by simulating the composition of the automata for each downward closure. The construction is identical to [Atig et al. 2011, Lemma 5.3]. Thus, we can conclude with the following lemma. Lemma 3.1. TheK-bounded non-termination problem for DCPS can be reduced in exponential time to the non-termination problem for DCFS. The resulting DCFS is of size at most exponential in the size of the DCPS. DCFS VASS From Non-Termination to Non-Termination Proof of Theorem 2.2. The 2EXPSPACE upper bound follows by combining Lemmas 3.1, 3.2, and the EXPSPACE upper bound for the non-termination problem for VASS [Rackoff 1978]. The 2EXPSPACE lower bound follows from the observation made already in [Baumann et al. 2020] that the 2EXPSPACE-hardness of K-bounded reachability already holds for terminating DCPS, in which every run is terminating. It is now a simple reduction to take an instance of the 퐾-bounded state reachability problem for a terminating DCPS and add a “gadget” that produces an infinite run whenever the target global state is reached.

Context-Bounded Verification of Liveness: Warm-up: Non-Termination

While creating the Short Ruby Newsletter, I discovered bestgems.org, and I noticed there was an interesting graph that I would like to discuss a bit. Downloads trends of all gems Data points Here is how I read this; first there are two data sets: the total downloads and the daily downloads Total downloads It is a sum of downloads of all gems -> so of course, this will always be increasing. But what I think is interesting is how fast the total downloads are increasing. I think it can be seen with the naked eye that starting with, say 2019/2020, the total downloads are increasing a lot: ~2B downloads increase from 2013 to 2019 ~133 B downloads increase from 2019 to 2023 How do I get to these differences: 1.47B downloads in 2013-07-01 and 3.71B downloads in 2019-07-01 => a difference of about 2.24B 3.71B downloads in 2019-07-01 and 137.53B downloads in 2023-07-01 => a difference of about 133.82B Two orders of magnitude increase in the total downloads in the last 4 years versus the previous 5 years. Conclusion: Daily downloads If total downloads increase, so do the daily downloads: daily downloads in 2013 (data point taken on 2013-07-03) 5.75M daily downloads in 2019 (data point taken on 2019-07-03) 50M daily downloads in 2023 (data point taken on 2023-07-11) 127M : the number of downloads per day is more than double, with some periods from 2019 until 2023 with a higher number of downloads per day (like 160M or 154M). Conclusion What does this mean? Tt means the number of downloaded gems has accelerated since 2019. could be running tests using CI pipelines and containers so that for every run, there is a gems download. One explanation Some data points: GitHub launched its Github Actions in 2018 ( ) source Gitlab launched its first version of CI in 2012 ( ) source Jenkins launched in 2011 ( ) source Circle CI launched in 2011 ( ) source Travis CI launched in 2011 ( ) source Almost 30% of businesses were already using CI/CD in 2013-2014 ( ) source I assume these features took off the next year, so it would be 2019 for GitHub and 2013 for Gitlab and the other major CIs in 2012. It is hard to know if this explanation is the only one. I don't feel it is accounting for all the fast growth since 2019. The only data point that matches that is Github launching their Actions in 2019, but that alone cannot explain the increase of two orders of magnitude since then. could be that Ruby is growing, and the pace is increasing. There could be two root causes for this: Another explanation More frequent version updates for gems result in multiple organizations' teams updating The pace of new projects is increasing Again, it is hard to know exactly which one is the reality. But I add this explanation that Ruby is growing because I see signs of it also in other places (more conferences, more talk on social media, an increased number of articles, more releases, more jobs, more contacts on Linkedin about jobs ...) we have seen since 2019 - maybe the way data is gathered changed, it is more granular or better captured. There can be other causes for the increase I think it is a combination of both explanations - CI being adopted on a large scale while also the Ruby number of projects growing more rapidly in the last 3-4 years. Data validation is not rubygems.org and I could not yet find how they are taking their data. Bestgems.org Still, when looking at the total number of downloads (see the comparison image below), it seems to have the same data, so I wrote this article starting with the assumption that bestgems.org data is valid. On the other hand, ruby-toolbox.com is using bestgems.org as a data source: Maybe a conclusion The rapid increase in Ruby gem downloads since 2019 can be attributed to the widespread adoption of CI/CD pipelines (with a small note that a lot of CI/CD tools were launched years before) and also to the growing popularity of Ruby in new projects. This trend reflects the growing importance of Ruby in the software development ecosystem. I hope you enjoyed this article. Join my for weekly Ruby updates from the community. For more Ruby , visit You can also find me on or or where I post mostly about Ruby. Short Ruby News newsletter learning resources . rubyandrails.info Ruby.social Linkedin Twitter Also published . here

How Ruby Gems Downloads Have Grown from 2013 to 2023

Advertising is one of the most vital forces in the problem of distribution

From London to Baden

Welcome back with another problem to solve! Today’s problem will focus on calculating big exponentials from scratch. This problem is similar to the problem seen in the , so this one will be pretty short. We’ll fast forward a bit over the explanations and direct our attention straight to the code! Daily Coding Problem number 20 If you have problems following along, I highly recommend you check for a much deeper explanation since the concepts involved are the same. Daily Coding Problem number 20 This problem is provided by the wonderful website , an awesome platform to test your math, logic, and coding skills on more than 800 problems. Go check it out; you will not be disappointed! Project Euler We’ll be using Go for this program: headache time! :D The problem Let’s take a look at the problem: 2¹⁵ = 32768, and the sum of its digits is 3+2+7+6+8=26. What is the sum of the digits of the number 2¹⁰⁰⁰? The problem is really simple: we need to calculate 2¹⁰⁰⁰ and sum its digits to give it a result. Simple, isn’t it? Well… Exponentials To give out some simple basics, an exponential number is simply the repetition of that same number a certain number of times. For example, writing 4³ means calculating 4*4*4. What’s really cool about powers (which is also what causes us this problem) is how fast they grow: not the fastest, but still pretty fast. The function we are interested in is the green one: you can easily see how fast it grows. Even if the power function x³ grows faster initially, the exponentiation of 2 catches up pretty quickly. As in the previous article, try with your calculator: you should not be able to calculate over 2³³², which is 8.749002899x10⁹⁹. And yet, with a little bit of reasoning and a simple program, we can calculate that 2³³³ is 17498005798264095394980017816940970922825355447145699491406164851279623993595007385788105416184430592 And with the same approach, 2⁵⁰⁰ is 3273390607896141870013189696827599152216642046043064789483291368096133796404674554883270092325904157150886684127560071009217256545885393053328527589376 Cool right? Let’s see how it’s done then! The approach If there’s one thing computers are good at, . We’ll exploit this ability to repeat a simple task many, many times to iterate over all the exponents from 1 to the desired one and print out the result. The simple operation we are doing is the to increase the exponent. However, we are doing this by multiplying each digit of the starting number by 2: this way, we can manage increasingly big numbers simply by multiplying their digits. Let’s write a multiplication function. it’s repeating the same job multiple times really fast multiplication of a certain number with the number 2 https://gist.github.com/NicolaM94/46ea02bb912e31dfc8baca955b93f7bd?embedable=true#file-multiplication-go As always, let’s explain a bit what’s happening here. We create the function, which takes in two parameters: , the integer we want to multiply, and , the factor we are multiplying it for. After that, we define the variable , which we’ll explain in a moment. multiply stringedInt factor carryover Now we start looping: we loop over the length of and multiply each digit by . stringedInt factor We have some type of conversion to do, however: first off, we use the variable to save our converted digit from the string (with we convert the value to its UNICODE counterpart and then convert it to ) integer stringedInt[n]-'0' rune int then, with the function, we convert the result back to a string and add it to the front of the variable, which will be our result. fmt.Sprintf out Let’s take a moment at the math done here: the possible digits we are multiplying are 0,1,2,3,4,5,6,7,8,9, but the results somehow repeat in a certain manner. For example, . The 1 will be our carryover, which will be added to the next multiplication, If you’re not versed with modulo operations, are some resources to get an idea about it. After multiplying, we just need to add the carryover that could have been stored from the previous multiplication: . 2*2 is 4, and 2*7 is 14, so a 4 with a 1 in front of it so to keep just the unit digit we calculate integer % 5 * 2 . here integer % 5 * 2 + carryover We must store the carry though; that is done in the next block of code, which evaluates if . This is because, for values from 5 to 9, our mudulo will bring us back to the values from 0 to 4, but we need to deal with the carry. so we simply check if : if it is, we have a 1 to carryover and we store it in its variable . integer > 4 We know that the carry can only be 1 at most, integer > 4 carryover for example, if the last number multiplied was an 8, will now start with a 6, but we have a 1 stored in . We must add it to the front of to have the correct result. The final block, from lines 12 to 14, simply adds the last carry possibly left from the last multiplication: out carryover out It’s really basic math, to be honest, but describing it textually could make it worse than it is. So here’s a drawn example of the process: Wrapping up Now we just need to apply that process 1,000 times to calculate the wall of text corresponding to 2¹⁰⁰⁰! Let’s write the simple code: https://gist.github.com/NicolaM94/e13f77c1664abf3dcfa3cd0367ebcb01?embedable=true#file-wrap-go In our function, we define the variable, initially equal to . Then we loop over for 1000 times to update the result. Now, since the problem wants the sum of the digits of 2¹⁰⁰⁰, we simply create the variable and loop over summing up all the digits. main final "1" sum final just change the value in the call or the upper limit in the loop, and you’ll get whatever result you want. For example, running Also, this same algorithm can be used to calculate every exponential of every number: multiply n ...
for n := 0; n < 500; n++ {
  final = multiply(final, 5)
}
... Will calculate 5⁵⁰⁰. As in where the problem was also given by , I won’t give out the solution: you need to build this by yourself, at least, if you want to know it! besides presenting math riddles and problems, . And I love that they are so committed that publishing results and guides for their problems is actually forbidden (this is one of the first 100 problems, so I understand it is permitted). Given this, . the other article ProjectEuler.net ProjectEuler.net is really a lovely project: their main focus is to provide a tool to start learning, thinking, and reasoning about math I don’t feel it would be fair to just give out the solution to copy-paste and get the achievement Have a nice coding, guys! 😎 Time Complexity As always, let’s take a brief moment to discuss the time complexity of this algorithm. The first part of the code runs a number of times equal to the length of the , which, unfortunately, will increase at each loop. Then, we run the multiplier times to reach the nth exponent. So, technically speaking, we’ll have a complexity of , which we can generalize with some approximation to O(n²). stringedInt n O[len(stringedInt)*n] Conclusion Here it is: that’s my solution! I hope you enjoyed following along and reading about this problem. If so, please leave a clap or two: that would make my day! Also, if you are willing and can contribute to the channel, share a Ko-fi. ! Here’s my page As always, thank you so much for reading. Nicola Also published . here

Everyrun

everyrun.world

-- employees

Since n.d.

COMPANY RANKING

EVERYRUN

EVERGREEN INDEX #3977

Everyrun WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

Everyrun

everyrun.world

-- employees

Since n.d.

COMPANY RANKING

EVERYRUN

EVERGREEN INDEX #3977

RELATED COMPANIESRANK

STORIES ABOUT EVERYRUN

Everyrun WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!